UA80540C2 - Спосіб, система, пристрій та носій інформації для перевірки достовірності оновлення для запису у віддаленій базі даних, спосіб перевірки достовірності віддаленої бази даних і достовірності передачі даних через мережу - Google Patents

Abstract

Спосіб, система, пристрій та носій інформації для перевірки достовірності оновлення для запису у віддаленій базі даних, спосіб перевірки достовірності віддаленої бази даних і достовірності передачі даних через мережу стосуються перевірки достовірності оновлень віддаленої бази даних, що здійснюються через мережу зв'язку. Відповідно до винаходу здійснюють порівняння запису локальної бази даних (200) і запису віддаленої бази даних та формують виключення. Кожне виключення описує розходження між записами локальної (200) і віддаленої баз даних. З кожним виключенням зіставляють ідентифікатор виключення, причому ідентифікатор виключення відповідає ідентифікатору запису. З кожною подією в оновленні зіставляють ідентифікатор події, причому ідентифікатор події відповідає ідентифікатору запису. Для визначення, чи є оновлення достовірним, здійснюють порівняння подій і виключень, що відповідають запису.

Description

Опис винаходу

Вимога на пріоритет/перехресне посилання на пов'язані заявки. 2 Дана не попередня заявка заявляє пріоритет попередньої заявки (на патент США з реєстраційним номером 60/330.842 від 1 листопада 2001 року), повністю включеної у даний опис за допомогою посилання, і попередньої заявки (на патент США з реєстраційним номером 60/365.169 від 19 березня 2002 року), повністю включеної у даний опис за допомогою посилання.

Даний винахід відноситься до комп'ютерних баз даних, більш конкретно, до способу і системи для надійної 70 перевірки достовірності оновлень віддаленої бази даних.

Зі збільшенням розміру баз даних і внаслідок їх сильно розподіленої структури стає все в більшій мірі проблематичним забезпечення однакових версій даних у пов'язаних базах даних. Якщо відбуваються істотні зміни в одній базі даних, то може бути потрібне оновлення інших баз даних для включення вказаних змін у найкоротші терміни. Здійснення таких оновлень може спричинити часте переміщення великих об'ємів даних 79 оновлення у декілька баз даних. Потенційно, такий процес може бути надзвичайно складним.

Вказана проблема додатково поєднується з ненадійним зв'язком у системах. У цьому випадку дані можуть бути втрачені при транспортуванні. При цьому потрібна повторна передача даних, і інші бази даних знову оновлюються. Таке повторення істотно знижує ефективність системи і зменшує ділянку, в якій бази даних містять найновіші дані.

Фіг.1 - структурна схема системи, відповідно до варіанту здійснення даного винаходу.

Фіг.2 - структурна схема системи концентратора, відповідно до варіанту здійснення даного винаходу.

Фіг.3 ілюструє можливу передачу оновлень бази даних з локальної бази даних у віддалену базу даних, відповідно до варіанту здійснення даного винаходу.

Фіг.4 ілюструє файл відправки, відповідно до варіанту здійснення даного винаходу. с

Фіг.5 ілюструє файл ініціалізації відправки, відповідно до варіанту здійснення даного винаходу. Ге)

Фіг - часова діаграма, що ілюструє формування файлу відправки та файлу ініціалізації відправки, відповідно до варіанту здійснення даного винаходу.

Фіг.7 - блок-схема варіанту здійснення даного винаходу, в якому можуть бути сформовані файли оновлення локальної бази даних. о

Фіг.8 - блок-схема варіанту здійснення даного винаходу, в якому віддалена база даних може одержувати «Її файли оновлення з локальної бази даних.

Фіг.9 - блок-схема іншого варіанту здійснення даного винаходу, в якому віддалена база даних може о одержувати файли оновлення з локальної бази даних і перевіряти їх достовірність. Га»)

Фіг1ОА - блок-схема варіанту здійснення даного винаходу, в якому може бути перевірена достовірність 3о файлів оновлення. со

Фіг1оВ - блок-схема іншого варіанту здійснення даного винаходу, в якому може бути перевірена достовірність файлів оновлення.

Фіг.11 - ілюстрація перевірки достовірності файлу оновлення, відповідно до варіанту здійснення даного « винаходу. З 50 Варіанти здійснення даного винаходу забезпечують спосіб і системі для перевірки достовірності оновлень с віддаленої бази даних, що здійснюються через мережу зв'язку. Може бути здійснене порівняння запису

Із» локальної бази даних і запису віддаленої бази даних, і можуть бути сформовані виключення. Кожне виключення може описувати "розходження між записами віддаленої і локальної баз даних. З кожним виключенням може бути зіставлений ідентифікатор виключення, причому ідентифікатор виключення може відповідати ідентифікатору запису. З кожною подією в оновленні може бути зіставлений ідентифікатор події, причому ідентифікатор події

Со може відповідати ідентифікатору запису. Для визначення, чи є оновлення достовірним, може бути здійснене ав | порівняння подій і виключень, які відповідають запису.

Фіг.1 - структурна схема, що ілюструє систему, відповідно до варіанту здійснення даного винаходу. В і-й основному система 100 може містити велику резидентну базу даних, через мережу зв'язку одержувати запити на «їз» 20 пошук і забезпечувати відповіді по пошуку. Наприклад, система 100 може являти собою симетричний багатопроцесорний (ЗМР) комп'ютер, наприклад, такий як ІВМ К5З/б60009М80 або 580, що виробляється с компанією ІВМ (АгтопкК, штат Нью-Йорк), Зип Епіегргізетм10000, що виробляється Зип Місгозувіетв (Запіа Сіага, штат Каліфорнія) і т.д. Система 100 також може являти собою багатопроцесорний персональний комп'ютер, наприклад, такий як СотрадРгої! іапі мМІ 530 (ЩО має два процесори Іпіє! РепіїштФ І, 866МГцЦ), що виробляється компанією Неміейк-Раскага (Раю Айо, штат Каліфорнія). Система 100 може також містити

ГФ) багатопроцесорну операційну систему, наприклад, таку як ІВМ АЇХФО 41 5и!п Зоїагіз'м 8 Орегаййпд Епмігоптепі,

Ге Кей Нас і ІМмОхе 6.2, і т.д. Система 100 може одержувати через мережу 124 зв'язку періодичні оновлення, які можуть паралельно включатися у базу даних. Варіанти здійснення даного винаходу можуть досягати дуже во високої продуктивності оновлення і пошуку по базі даних за допомогою включення кожного оновлення у базу даних без використання блокування бази даних або засобів керування доступом.

У варіанті здійснення система 100 може містити, щонайменше, один процесор 102-1, приєднаний до шини 101. Процесор 102-1 може містити внутрішній кеш (наприклад, кеш 11, не зображений). Між процесором 102-1 і шиною 101 може бути резидентно розміщений кеш 103-1 вторинної пам'яті (наприклад, кеш 12, кеші І 2/1 З і т.д.).

У переважному варіанті здійснення система 100 може містити декілька процесорів 102-1...102-Р, приєднаних до б5 шини 101. Між декількома процесорами 102-1...102-Р і шиною 101 також може бути резидентно розміщено декілька кешів 103-1...103-Р вторинної пам'яті (наприклад, архітектура крізного перегляду) або, у вигляді іншого варіанту, до шини 101 може бути приєднаний, щонайменше, один кеш 103-1 вторинної пам'яті (наприклад, архітектура з передісторією). Система 100 може містити пам'ять 104, наприклад, таку як оперативний запам'ятовуючий пристрій (ОЗП), і т.д., приєднану до шини 101 для зберігання інформації та інструкцій, які повинні виконуватися декількома процесорами 102-1...102-Р.

Пам'ять 104 може зберігати велику базу даних, наприклад, для перетворення імен доменів Інтернет в адреси в Інтернет, для перетворення імен або номерів телефонів у мережні адреси, для забезпечення і оновлення даних профілю абонента, для забезпечення і оновлення даних присутності користувача і т.д. Переважно, розмір 7/0 бази даних і кількість перетворень за секунду можуть бути дуже великими. Наприклад, пам'ять 104 може містити, щонайменше, 64Гбайт ОЗП і може містити базу даних імен доменів у 5О0ОМ (тобто, 500х1097) записів, базу даних абонентів у 5О0М записів, базу даних мобільності номерів телефонів у 450М записів і т.д.

У можливій архітектурі 64-бітової системи, наприклад, такої як система, що містить, щонайменше, один 64-бітовий процесор 102-1 зі зворотним порядком байтів, приєднаний, щонайменше, до 64-бітової шини 101, і 75 64-бітову пам'ять 104, 8-байтове значення покажчика може бути записане в адресу (комірки) пам'яті на межі 8-байтів (тобто, адреса пам'яті, що ділиться на вісім, або, наприклад, КМ) з використанням одиночної безперервної операції. В основному, наявність кешу 103-1 вторинної пам'яті може просто затримувати запис 8-байтового покажчика у пам'ять 104. Наприклад, в одному варіанті здійснення, кешем 103-1 вторинної пам'яті може бути кеш крізного перегляду, що діє у режимі крізного запису так, щоб одиночна команда збереження 8-байтів могла переміщувати вісім байтів даних з процесора 102-1 у пам'ять 104 без переривання і всього лише за два такти системних годин. В іншому варіанті здійснення кешем 103-1 вторинної пам'яті може бути кеш крізного перегляду, що діє у режимі зворотного запису так, щоб 8-байтовий покажчик міг бути спочатку записаний у кеш 103-1 вторинної пам'яті, який потім, у більш пізній час, може записати 8-байтовий покажчик у пам'ять 104, наприклад, при запису у пам'ять 104 рядка кешу, в якому зберігається 8-байтавий покажчик (тобто, Га наприклад, коли "скидається у пам'ять" визначений рядок кешу, або повністю кеш вторинної пам'яті).

Зрештою, з точки зору процесора 102-1, як тільки дані фіксуються вихідними контактами процесора 102-1, і9) всі вісім байтів даних записуються у пам'ять 104 в одній постійній, безперервній передачі, яка може бути затримана діями кешу 103-1 вторинної пам'яті, якщо він є у наявності. З точки зору процесорів 102-2... 102-Р, як тільки дані фіксуються вихідними контактами процесора 102-1, всі вісім байтів даних записуються у пам'ять ав! 104 в одній постійній, безперервній передачі, яка вказана протоколом узгодженості кешу по кешах 103-1...103-Р вторинної пам'яті, які можуть затримувати запис у пам'ять 104, якщо є у наявності. М

Однак, якщо 8-байтове значення покажчика записується у невирівняну комірку пам'яті 104, наприклад, адреса ю пам'яті, яка перетинає межу 8-байтів, то всі вісім байтів даних не можуть бути передані з процесора 102-1 з використанням одиночної команди збереження 8-байтів. Замість цього процесор 102-1 може видати дві різні і о окремі команди збереження. Наприклад, якщо адреса пам'яті починається за чотири байти до межі 8-байтів с (наприклад, 8М-4), то перша команда збереження передає у пам'ять 104 чотири старших байти (наприклад, 8-4), у той час як друга команда збереження передає у пам'ять 104 чотири молодших байти (наприклад, 8М).

Істотно, що між цими двома окремими командами збереження процесор 102-1 може одержати переривання, або « процесор 102-1 може звільнити керування шиною 101 для іншого компонента системи (наприклад, процесора 70 102-Р і т.д-). Отже, значення покажчика, що резидентно знаходиться у пам'яті 104, буде недійсним, доки 8 с процесор 102-1 не зможе завершити другу команду збереження. Якщо інший компонент починає одиночне й безперервне зчитування пам'яті у дану комірку пам'яті, то недійсне значення буде повернене, як припустимо и"? дійсне.

Аналогічно, нове 4-байтове значення покажчика може бути записане в адресу пам'яті, що ділиться на чотири (наприклад, 4М), з використанням одиночної безперервної операції. Потрібно зазначити, що у можливому (ее) варіанті, описаному вище, 4-байтове значення покажчика може бути записане у комірку пам'яті 8М-4 з використанням одиночної команди збереження. Безумовно, якщо 4-байтове значення покажчика записується у о комірку, що перетинає межу 4 байтів, наприклад, 4М-2, то всі чотири байти даних не можуть бути передані з ос процесора 102-1 з використанням одиночної команди збереження, і значення покажчика, резидентно розміщене у пам'яті 104, може бути недійсним протягом деякого періоду часу. е Система 100 також може містити постійний запам'ятовуючий пристрій (ПЗП) 106, або інші статичні о запам'ятовуючі пристрої, приєднані до шини 101 для зберігання статичної інформації та інструкцій для процесора 102-1. Для зберігання інформації та команд до шини 101 може бути приєднаний запам'ятовуючий пристрій 108, такий як магнітний або оптичний диск. Система 100 також може містити пристрій 110 відображення (наприклад, монітор на рідких кристалах СО (РДК)) і пристрій 112 введення даних (наприклад, клавіатуру, мишу, кульовий покажчик і т.д.), приєднані до шини 101. Система 100 може містити декілька мережних

Ф, інтерфейсів 114-1...114-О, які можуть передавати і приймати електричні, електромагнітні або оптичні сигнали, ко що несуть потоки цифрових даних, які являють собою різні види інформації. У варіанті здійснення мережний інтерфейс 114-1 може бути приєднаний до шини 101 і до локальної мережі зв'язку ГАМ (ЛМ) 122, у той же час бо мережний інтерфейс 114-О може бути приєднаний до шини 101 і глобальної мережі зв'язку УМАМ (ГМ) 124.

Декілька мережних інтерфейсів 114-1...114-0 можуть підтримувати різні мережні протоколи, включаючи, наприклад, Сідабії Е(Пегпеї (наприклад, ІЕЕЄ Стандарт 802.3-2002, виданий у 2002), Рірег Спаппеї! (наприклад,

АМЗ5І Стандарт Х.3230-1994, виданий у 1994) і т.д. До ЛМ 122 і ГМ 124 може бути приєднано декілька мережних комп'ютерів 120-1...120-М. В одному варіанті здійснення ЛМ 122 ії ГМ 124 можуть бути фізично окремими 65 мережами зв'язку, у той же час в іншому варіанті здійснення ЛМ 122 і ГМ 124 можуть бути з'єднані через мережний шлюз або маршрутизатор (для зручності не зображені). Як інший варіант, ЛМ 122 і ГМ 124 можуть бути однією і тією ж мережею.

Як зазначено вище, система 100 може забезпечувати послуги розрізнення ОМ5 (служба імен доменів). У варіанті здійснення для розрізнення (процесу визначення адрес) ОМЗ послуги розрізнення ОМ в основному

Можуть бути розділені між транспортуванням по мережі і функціями пошуку даних. Наприклад, система 100 може бути механізмом пошуку (ЦЕ) для сервера, оптимізованим для пошуку даних по великих наборах даних, у той же час множина мережних комп'ютерів 120-1...120-М може бути множиною механізмів протоколу (РЕ) клієнта, оптимізованих для обробки мережі зв'язку і транспортування. | ШЕ може бути потужним багатопроцесорним сервером, який зберігає у пам'яті 104 весь набір записів ОМ5, щоб сприяти високошвидкісному 7/0 високопродуктивному пошуку і оновленню. В іншому варіанті здійснення послуги розрізнення ОМ можуть забезпечуватися множиною потужних багатопроцесорних серверів, або множиною І ШОЕ, кожний з яких зберігає у пам'яті підмножину всього набору записів ОМ, щоб сприяти високошвидкісному високопродуктивному пошуку і оновленню.

Навпаки, множина РЕ може бути звичайними вузькоспеціалізораними пристроями, які базуються на РС, що /5 Виконують ефективну багатозадачну операційну систему (наприклад, Кеа Наї МОХ 6.2), які мінімізують транспортне навантаження обробки мережі зв'язку на | ШЕ для максимізації доступних ресурсів для розрізнення

ОМ. Пристрої РЕ можуть обробляти нюанси протоколу ОМ5 провідної лінії зв'язку, реагувати на недійсні запити

РМЗ і мультиплексувати дійсні запити ОМЗ в (ШОЕ через ЛМ 122. В іншому варіанті здійснення, що містить множину ШЕ, які зберігають підмножини записів ОМ5, РЕ можуть визначати, який пристрій | ОЕ повинен 2о одержати кожний дійсним запит ОМ5, і мультиплексувати дійсні запити ОМ у відповідні І ШЕ. Кількість РЕ для одного (ШОЕ може визначатися, наприклад, кількістю запитів ОМ, яка повинна оброблятися за секунду, і робочими характеристиками конкретної системи. Для визначення співвідношень відповідності і режимів також можуть використовуватися інші показники.

У загальному випадку, можуть підтримуватися інші варіанти здійснення великого об'єму, що базуються на сч об Запитах, які включають, наприклад, розрізнення номерів телефонів, обробку сигналізації 557, визначення для встановлення відповідності номера телефону з абонентом, визначення місцеположення і присутності абонента і і) т.д.

У варіанті здійснення центральний сервер 140-1 оперативної обробки транзакцій (ОЇ ТР) може бути приєднаний до ГМ 124 і одержувати з різних джерел додатки, зміни і видалення (тобто, трафік оновлення) для о зо бази даних 142-1. ОЇ ТР сервер 140-1 може передавати оновлення через ГМ 124 у систему 100, яка містить локальну копію бази даних 142-1. ОЇ ТР сервер 140-1 може бути оптимізований для обробки трафіку оновлення у - різних форматах і протоколах, включаючи, наприклад, Протокол Передачі Гіпертекстових файлів (НТТР), ю

Протокол Реєстратора Запису (ККР), Нарощуваний Протокол |Ініціалізації (ЕРР), Систему Керування

Службами/Механізований Загальний Інтерфейс (МО) 800, та інші оперативні протоколи ініціалізації. Сукупність о

ІОЕ тільки для читання може бути розгорнена в архітектурі типу концентратора і спиці (лінії, що йде від со центра до периферії) для забезпечення можливості високошвидкісного пошуку, що супроводжується об'ємними додатковими оновленнями з ОЇ ТР сервера 140-1.

В альтернативному варіанті здійснення дані можуть бути розподілені по декількох ОЇТР серверах 140-1...140-5, кожний з яких може бути приєднаний до ГМ 124. ОЇ ТР сервера 140-1...140-5 можуть одержувати з « різних джерел додатки, зміни і видалення (тобто, трафік оновлення) для баз даних, що відповідають їм, з с 142-1...142-5 (не зображені для зручності). ОЇ ТР сервера 140-1...140-5 можуть передавати оновлення через ГМ 124 у систему 100, яка може містити копії баз даних 142-1...142-5, інші дані, що динамічно створюються, і ;» т.д. Наприклад, у варіанті здійснення для геолокації, ОЇ ТР сервера 140-1...140-5 можуть одержувати трафік оновлення з груп віддалених датчиків. В іншому альтернативному варіанті здійснення множина мережних комп'ютерів 120-1...120-М також може одержувати через ГМ 124 або ЛМ 122 додатки, зміни і видалення (тобто,

Го! трафік оновлення) з різних джерел. У цьому варіанті здійснення множина мережних комп'ютерів 120-1...120-М може передавати у систему 100 оновлення, а також запити. о У варіанті здійснення система 100 може містити віддалену базу даних (наприклад, віддалена база даних с 210). З ОЇ ТР сервера 140-1 через ГМ 124, наприклад, може бути одержана нова інформація, або трафік 5р оновлення. У варіанті здійснення нова інформація може містити зміни, щонайменше, одного елемента, який існує ве у віддаленій базі даних. Система 100 на основі нової інформації, одержаної через мережу зв'язку, може о створити новий елемент віддаленої бази даних, і без обмеження доступу до віддаленої бази даних для пошуку, записати у віддалену базу даних покажчик на новий елемент з використанням одиночної безперервної операції, наприклад, такої як інструкція збереження. У варіанті здійснення, процесор 102-1 може містити розмір слова, щонайменше, у п-байтів, пам'ять 104 може мати розрядність, щонайменше, у п-байтів, та інструкція збереження може записувати п-байтів у віддалену адресу пам'яті, розміщену на межі п-байтів. В іншому варіанті здійснення (Ф) система 100 може фізично видалити з пам'яті 104 існуючий елемент, що відповідає новому елементу, після ка запису покажчика у віддаленій базі даних.

У варіанті здійснення розрізнення ЮОМ5 кожний РЕ (наприклад, кожний з декількох мережних комп'ютерів во 120-1...120-М) може комбінувати, або мультиплексувати, декілька повідомлень запитів ОМ5, одержаних через глобальну мережу зв'язку (наприклад, ГМ 124), в одиночний СуперПакет Запиту і передавати СуперПакет Запиту через локальну мережу зв'язку (наприклад, ЛМ 122) в ШЕ (наприклад, систему 100). | ОЕ може комбінувати, або мультиплексувати, декілька відповідей на повідомлення-запити ЮОМ5 в одиночний СуперПакет Відповіді і передавати СуперПакет Відповіді через локальну мережу зв'язку у відповідний РЕ. В основному, максимальний 65 розмір СуперПакета Відповіді або Запиту може бути обмежений максимальним блоком передачі (МТ) фізичного мережного рівня (наприклад, Сідабії Е(Пегпе). Наприклад, стандартні розміри повідомлення запиту і відповіді ОМ5, що не перевищують 100 байтів і 200 байтів, відповідно, дозволяють мультиплексувати більше 30 запитів в одиночний СуперПакет Запиту, а також мультиплексувати більше 15 відповідей в одиночний

СуперПакет Відповіді. Однак, в одиночний СуперПакет Запиту може бути включена менша кількість запитів (наприклад, 20 запитів), щоб при формуванні відповіді уникнути переповнення МТИ (наприклад, у 10 відповідей).

Для МТ більшого розміру кількість мультиплексованих запитів і відповідей, відповідно, може бути збільшена.

Кожний багатозадачний РЕ може мати вхідний потік і вихідний потік для керування запитами і відповідями р, відповідно. Наприклад, вхідний потік може демаршалінгувати (розпаковувати) компоненти запиту ОМ5 з вхідних; пакетів запитів ЮОМ5, одержаних Через глобальну мережу зв'язку, і мультиплексувати декілька 7/о Мілісекунд запитів в одиночний СуперПакет Запиту. Потім вхідний потік може передавати СуперПакет Запиту через локальну мережу зв'язку в | ШЕ. Навпаки, вихідний потік може одержувати СуперПакет Відповіді з І ОЕ, демультиплексувати відповіді, що містяться в ньому, і маршалінгувати (упаковувати у стандартний формат) різні поля у дійсну відповідь ОМ, яка потім може бути передана через глобальну мережу зв'язку. В основному, як зазначено вище, можуть підтримуватися інші варіанти здійснення великого об'єму, що базуються на запитах.

У варіанті здійснення СуперПакет Запиту може також містити інформацію про стан, яка відповідає кожному запиту ОМ5, наприклад, таку як вихідна адреса, вид протоколу і т.д. | ОЕ може включати у СуперПакет Відповіді інформацію про стан і відповідні відповіді ОМ. Потім кожний РЕ може формувати і повертати повідомлення дійсних відповідей ОМ5 з використанням інформації, переданої з (ШЕ. Отже, кожний РЕ може, переважно, функціонувати як пристрій, що не змінює свого стану у процесі виконання, тобто, дійсні відповіді ОМ5 можуть бути сформовані з інформації, що міститься у СуперПакеті Відповіді. В основному, (ШЕ може повертати

СуперПакет Відповіді в РЕ, з якого виходив вхідний СуперПакет, однак, очевидні інші можливі варіанти.

В альтернативному варіанті здійснення кожний РЕ може підтримувати інформацію про стан, яка відповідає кожному запиту ОМ, і включати у СуперПакет Запиту посилання, або дескриптор, на інформацію про стан. І ОЄЕ може включати у СуперПакет Відповіді посилання на інформацію про стан і відповідні відповіді ОМ. Потім сч кожний РЕ може формувати і повертати повідомлення дійсних відповідей ОМ5 з використанням посилань на інформацію про стан, переданих з ШОЕ, а також підтримуваної ним інформації про стан. У цьому варіанті і) здійснення | ШЕ може повертати СуперПакет Відповіді в РЕ, з якого виходив вхідний СуперПакет.

На Фіг.2 представлена структурна схема архітектури тину концентратора і спиць (зіркоподібної топології) відповідно до варіанту здійснення даного винаходу. В основному, система може містити локальну базу даних 200 о зо (яка може знаходитися у центральному ОГТР концентраторі 140) і одну або більшу кількість віддалених баз даних 210 (які можуть знаходитися у пристроях І ШЕ 100), з'єднаних з локальною базою даних 200 за допомогою « будь-якого механізму з'єднання, наприклад, Інтернету або ЛМ 122. Бази даних можуть передавати і одержувати ю дані оновлення.

Відповідно до Фіг.3, у варіантах здійснення даного винаходу локальна база даних 200 передає у віддалену о базу даних 210 Р файлів 300-1...300-Е відправки та файл ініціалізації 310 відправки для оновлення віддаленої со бази даних 210. Файли оновлення можуть передаватися індивідуально або у пакетах, наприклад, множина файлів 300 відправки, один файл 300 відправки і один файл ініціалізації 310 відправки, множина файлів 300 відправки і один файл ініціалізації 310 відправки, одиночний файл 300 відправки, або одиночний файл ініціалізації 310 відправки. «

У варіанті здійснення даного винаходу процесор 104 може одержувати з локальної бази даних 200 файл 300 пт») с відправки і/або файл ініціалізації 310 відправки, що містить дані оновлення. Система 150 може одержувати файл

З00 відправки та файл ініціалізації 310 відправки у віддаленій базі даних 210 через інтерфейс 118 зв'язку. ;» Потім процесор 104 може порівняти дані оновлення у файлі З00 відправки або в файлі ініціалізації 310 відправки з відповідними даними у віддаленій базі даних 210. Якщо у віддаленій базі даних 210 дані інші, то процесор 104 може застосувати файл 300 відправки або файл ініціалізації 310 відправки до віддаленої бази

Го! даних 210. Відповідно, згодом віддалена база даних 210 може бути оновлена даними, що відповідають даним оновлення у локальній базі даних 200. о Фіг.А4 ілюструє файл 300 відправки, відповідно до варіанту здійснення даного винаходу. Поля файлу 300 с можуть включати в себе, наприклад, ідентифікатор 400 файлу, час 402 формування файлу, кількість 404 транзакцій М у файлі, повний розмір 406 файлу, контрольну суму 408 або будь-який подібний індикатор контролю ве помилок і транзакції 410-1...410-М (що містять ідентифікатори транзакцій). Вказані поля файлу відправки є о можливими варіантами, призначеними для ілюстрації, але не для обмеження контексту варіантів здійснення даного винаходу. У файл 300 відправки може бути включене будь-яке поле, яке може бути корисним.

Файл 300 відправки містить зміни у локальній базі даних 200 між двома моментами часу. Ці зміни можуть ов Включати в себе, наприклад, додавання нових ідентифікаторів (тобто, ідентифікаторів записів даних), видалення існуючих ідентифікаторів, зміни одного або більшої кількості записів даних, що відповідають ідентифікатору,

Ф) перейменування ідентифікатора, холосту команду і т.д. Одна або більша кількість вказаних змін може ка здійснюватися послідовно і може називатися транзакціями. Файл 300 відправки може містити унікальні ідентифікатори даних транзакцій. Транзакції можуть бути записані у файлі З00О відправки у тому порядку, в бо якому вони здійснені у локальній базі даних 200. Додатково, для транзакцій, що містять більше однієї зміни, зміни можуть бути записані всередині транзакції у тому порядку, в якому вони здійснені у локальній базі даних 200.

В основному, ідентифікатори транзакцій можуть призначатися транзакціям у випадковому порядку. Тобто, ідентифікатори транзакцій не обов'язково монотонно зростають у часі. Наприклад, дві послідовні транзакції б5 Можуть мати ідентифікатори транзакцій 10004 і наступний за ним 10002. Відповідно, черговість здійснення транзакції може бути визначена її розміщенням у поточному файлі 300-Е або її розміщенням у попередньому файлі 300-(Е-1). В основному, для повного завершення оновлення віддаленої бази даних із застосуванням одноп файлу відправки, транзакції не можуть охоплювати сусідні файли 300. Це запобігає перериванню оновлення через мережну затримку, яка може привести до помилкових даних у віддаленій базі даних 210.

Фіг.5 ілюструє файл ініціалізації 310 відправки, відповідно до варіанту здійснення даного винаходу. Поля файлу ініціалізації 310 відправки можуть включати в себе, наприклад, ідентифікатор 500 файлу, час 502 формування файлу, кількість 504 транзакцій М у файлі, повний розмір 506 файлу, контрольну суму 508 або будь-який подібний індикатор контролю помилок і копію 516 (даних) повної локальної бази даних. Файл ініціалізації 310 відправки може додатково містити поле 510, що є ідентифікатором 400 файлу останнього файлу 70 300 відправки, сформованого до формування файлу 310, і поле 512, що є ідентифікатором останньої транзакції, фіксованої у локальній базі даних 200 до формуванні файлу ініціалізації 310 відправки. Дані у локальній і віддаленій базах даних 200, 210 можуть бути розподілені по таблицях, що резидентно зберігаються у базах даних 200, 210. Бази даних 200, 210 можуть підтримувати довільну кількість таблиць. Отже, коли база даних має таблиці, файл ініціалізації 310 відправки може містити для кожної таблиці поле, яке вказує кількість записів, зроблених у таблиці. Наприклад, база даних імен доменів може містити таблицю доменів і таблицю серверів доменних імен. Отже, файл ініціалізації відправки може містити поле, яке вказує кількість записів у таблиці доменів і поле, яке вказує кількість записів у таблиці серверів доменних імен. Поле може визначати, наприклад, ім'я таблиці, ключ, що використовується для індексування записів у таблиці, і кількість записів у таблиці. Додатково, файл ініціалізації 310 відправки може містити поле, яке вказує версію файлу ініціалізації

З10 відправки, звичайно 1.0. Вказані поля файлу ініціалізації відправки є можливими варіантами, призначеними для ілюстрації, але не обмеження, контексту варіантів здійснення даного винаходу. В файл ініціалізації 310 відправки може бути включене будь-яке поле, яке може бути корисним.

Як зазначено вище, файл ініціалізації 310 відправки може містити, наприклад, копію повної локальної бази даних 200, уніфіковану за зчитуванням даних. Файл ініціалізації 310 відправки може стати уніфікованим з сч ов локальною базою даних 200 у момент часу ї між ів і Є, де із є часом початку формування файлу ініціалізації 310 відправки, а її є часом завершення формування. По суті, єдиною операцією, яка може з'явитися в файлі і) ініціалізації 310 відправки, є операція "додавання" Тобто, при формуванні файлу ініціалізації 310 відправки в нього можуть бути записані копії повної локальної бази даних 200 у момент часу Її. Отже, для запису локальної бази даних 200 в файл ініціалізації 310 відправки може бути виконана операція "додавання". Ідентифікатори о зо Можуть бути записані в файл ініціалізації 310 відправки у випадковому порядку. В іншому варіанті, за наявності зовнішніх ідентифікаторів, записи даних, на які є посилання, можуть бути записані до запису даних, « що має посилання. ю

Додавання полів 510 і 512 може забезпечувати файл ініціалізації 310 відправки деякою інформацією про файли 300 відправки, які можуть бути сформовані і передані у віддалену базу даних 210 під час формування о файлу ініціалізації 310 відправки. Однак, формування файлу 300 відправки і формування файлу ініціалізації 310 со відправки можуть бути не пов'язані один з одним відносно відсутності залежності між ними при формуванні. Така структура і процес можуть запобігти менш ефективному підходу, при якому формування і застосуванні файлу відправки може бути припинене до завершення формування файлу ініціалізації відправки. При продовженні формування і застосування файлів 300 відправки під час формування файлу ініціалізації 310 відправки, як у « варіанті здійснення даного винаходу, може здійснюватися суворий контроль помилок файлів З00 відправки, а з с також накладення обмежень на віддалену базу даних 210, наприклад, можуть бути зроблені обмеження відносно однозначності або обмеження на зовнішні ідентифікатори. Накладення обмежень може захищати цілісність ;» даних у віддаленій базі даних 210 за допомогою відхилення транзакцій, що порушують реляційні моделі віддаленої бази даних 210. Наприклад, обмеження відносно однозначності може перешкоджати повторному збереженню у базі даних 210 одного і того ж ключа.

Го! На Фіг.б6 представлена часова діаграма, що ілюструє формування файлу відправки та файлу ініціалізації відправки, відповідно до варіанту здійснення даного винаходу. Згідно з Фіг.б, файли 300 відправки (з 81-1 по о 8-21) формуються з регулярними інтервалами часу. В альтернативному варіанті здійснення файли 300 відправки с можуть формуватися з нерегулярними інтервалами часу. У загальному випадку, формування файлу відправки 5о не займає інтервал часу повністю. Наприклад, якщо файли формуються у 5-хвилинні інтервали часу, то для ве завершення формування файлу не потрібно повністю 5 хвилин. Додатково, якщо у локальній базі даних 200 о проводяться зміни під час формування файлу З00 відправки, то дані зміни будуть зібрані у наступному файлі 300 відправки. Наприклад, якщо формування файлу відправки 1-4 починається о 12:05:00 і завершується о 12:05:02, то будь-які зміни у локальній базі даних 200, здійснені між 12:05:00 і 12:05:02, збираються у файл відправки дв 8-5 (наприклад, З00-5), який охоплює інтервал часу з 12:05:00 до 12:10:00.

Фігб ілюструє файли 300-5 і 300-19 відправки. У вказаних файлах, серед інших полів, зображені

Ф) ідентифікатор 601 файлу (51-5, 8і-19), час 603 формування файлу, та ідентифікатори 605 транзакцій (наприклад, ка 10002). Потрібно зазначити, що ідентифікатори транзакцій можуть бути не впорядкованими монотонно. Як згадано вище, ідентифікатори транзакцій можуть мати довільні значення. Однак, безпосередньо відповідні бо транзакції записані у файл 300 відправки у порядку, в якому вони здійснені у локальній базі даних 200.

Оскільки формування файлу ініціалізації 310 відправки і формуванню файлу 300 відправки можуть бути не пов'язані, то файл ініціалізації 310 відправки може формуватися у будь-який момент часу. Наприклад, файл ініціалізації 310 відправки може формуватися до, протягом або після формування файлу 300 відправки. Фіг.б ілюструє файл ініціалізації 310 відправки, що формується у проміжок часу між формуванням четвертого і п'ятого 65 файлів відправки (наприклад, 1-4 і 8-5).

У варіанті здійснення файл ініціалізації 310 відправки може, серед інших полів, містити ідентифікатор 610 файлу (іві-І), ідентифікатор 615 файлу для останнього файлу відправки, сформованого перед формуванням файлу ініціалізації відправки, та ідентифікатор 620 транзакції для останньої транзакції, завершеної перед формуванням файлу ініціалізації відправки. У даному можливому варіанті останнім сформованим файлом відправки є файл відправки 5/-4, а останньою завершеною транзакцією є транзакція 10001. Формування файлу ініціалізації 310 відправки починається 611 о 12:07:29. Коли починається формування файлу ініціалізації 310 відправки, перша половина транзакцій у файлі 300-5 відправки (1-5), транзакції 10002, 10005 і 10001 були вже завершені у локальній базі даних 200. Відповідно, файл ініціалізації 310 відправки може мати інформацію про ці транзакції і може зібрати ці транзакції в файлі ініціалізації 310 відправки. Однак, файл ініціалізації 310 7/0 Відправки не може мати інформації про подальші транзакції 10003 ї 10004, які здійснюються після початку формування файлу ініціалізації відправки.

При формуванні файлу ініціалізації 310 відправки файли відправки, починаючи з файлу 300-5 відправки, можуть продовжувати формуватися з регулярними інтервалами часу. Дані файли можуть передаватися віддаленій базі даних 210 і застосовуватися.

Формування файлу ініціалізації 310 відправки може бути завершене о 1:15:29, у проміжку часу між формуванням 18-го і 19-го файлів З00 відправки (51-18 і 81-19), ії не може впливати на формування 19-го файлу 300-19 відправки.

Після одержання і завантаження у віддаленій базі даних 210 файлу ініціалізації 310 відправки віддалена база даних 210 може не враховувати файли відправки сформовані до формування файлу ініціалізації 310 2о Відправки. Це можливо, наприклад, внаслідок того, що файл ініціалізації 310 відправки містить всі зміни у локальній базі даних 200, які були записані у попередні файли 300 відправки. У цьому можливому варіанті віддаленій базі даних 210 може не бути потрібно враховувати файли відправки з першого по четвертий (з 51-1 по 8-4). Зміни, записані у даних файлах відправки, з 5-1 по 51-4, також можуть бути записані в файлі ініціалізації 310 відправки. Вказані попередні файли відправки (з 51-1 по 51-4)д можуть бути видалені або, в сч ов іншому варіанті, заархівовані.

Аналогічно, віддалена база даних 210 може не враховувати транзакції, завершені до формування файлу і) ініціалізації 310 відправки, які були включені у файл 300 відправки, сформований згодом. Дані транзакції можуть бути включені в файл ініціалізації 310 відправки при його формуванні. Наприклад, тому віддаленій базі даних 210 може не бути потрібно враховувати перші три транзакції 10002, 10005, 10001 з файлу відправки в1/-5. о зо Дані транзакції, записані у файл відправки з51-5, можуть також бути записані в файл |ініціалізацій 310 відправки. Дані завершені транзакції можуть бути видалені, або в іншому варіанті, заархівовані. -

На Фіг.7 представлена блок-схема варіанту здійснення даного винаходу, в якому можуть бути сформовані ю файли оновлення локальної бази даних. Система може формувати (705) декілька періодичних оновлень, що базуються на додаткових змінах у локальній базі даних. Кожне оновлення може містити одну або більшу кількість о транзакцій. Потім система може передати (710) періодичні оновлення у віддалену базу даних. При формуванні со періодичних оновлень, система може почати формувати (715) оновлення ініціалізації у момент часу запуску.

Оновлення ініціалізації може містити версію повної локальної бази даних. Система може визначити (720) останнє періодичне оновлення, сформоване до моменту часу запуску, і останню транзакцію, завершену до моменту часу запуску. Потім система може передати (725) оновлення ініціалізації у віддалену базу даних. Оновлення « ініціалізації може містити ідентифікатор оновлення, що відповідає останньому сформованому періодичному з с оновленню, та ідентифікатор транзакції, що відповідає останній завершеній транзакції.

Наприклад, ОЇ ТР 140 може формувати (705) файли 300 відправки з деяким регулярним або нерегулярним ;» інтервалом часу. Потім ОЇ ТР 140 може передати (710) файли 300 відправки у віддалену базу даних 210. При формуванні файлів З00 відправки, ОЇ ТР 140 може почати формування (715) файлу ініціалізації 310 відправки у

Момент часу запуску 611. Файл ініціалізації 310 відправка може містити копію повної локальної бази даних 200.

Го! Потім ОГТР 140 може визначити (720) останній файл З00 відправки, сформований до часу запуску 611 для формування файлу ініціалізації 310 відправки, і останню транзакцію, завершену до часу запуску 611 для о формування файлу ініціалізації 310 відправки. Потій ОЇ ТР 140 може передати (725) файл ініціалізації 310 с відправки у віддалену базу даних 210. Файл ініціалізації 310 відправки може містити ідентифікатор 615 файлу Відправки, що відповідає останньому сформованому файлу 300 відправки, і ідентифікатор транзакції 620, що ве відповідає останній завершеній транзакції. о На Фіг.8 представлена блок-схема варіанту здійснення даного винаходу, в якому віддалена база даних може одержувати файли оновлень з локальної бази даних. Система може одержати (805) декілька періодичних оновлень. Кожне оновлення може містити одну або більшу кількість транзакцій. Періодичні оновлення можуть бути одержані окремо або у пакетах. У деякий момент часу система може одержати (810) оновлення ініціалізації.

Оновлення ініціалізації може містити версію повної локальної бази даних. Система може зчитати (815) з

Ф) оновлення ініціалізації ідентифікатор останнього періодичного оновлення і ідентифікатор останньої транзакції. ка Потім система може визначити (820) останнє періодичне оновлення, що відповідає ідентифікатору оновлення, і останню транзакцію, що відповідає ідентифікатору транзакції. Періодичне оновлення і транзакція можуть бути, бо Відповідно, останнім сформованим оновленням і останньою завершеною транзакцією до формування оновлення ініціалізації. Система може застосувати (825) до віддаленої бази даних незавершені транзакції, що залишилися у відповідному періодичному оновленні. Потім системі може застосувати (830) до віддаленої бази даних періодичні оновлення, що залишилися, сформовані після останнього періодичного оновлення. Застосування оновлення ініціалізації, переважно, заповнює будь-які раніше втрачені періодичні оновлення. 65 Наприклад, ШЕ 100 може одержати (805) файли 300 відправки з деяким регулярним або нерегулярним інтервалом часу. Файли 300 відправки можуть бути одержані окремо або у пакетах. У деякий момент часу І ОЕ

100 може одержати (810) файл ініціалізації 310 відправки. (ШОЕ 100 може зчитати (815) з файлу ініціалізації 310 відправки ідентифікатор 615 файлу відправки і ідентифікатор 620 транзакції. Потім | СЕ 100 може визначити (820) файл 300 відправки, що відповідає ідентифікатору 615 файлу відправки, і транзакцію 605, що відповідає ідентифікатору 620 транзакції. Файл відправки і транзакція можуть бути, відповідно, останнім сформованим файлом відправки і останньою завершеною транзакцією до формування файлу ініціалізації 310 відправки. ШОЕ 100 може застосувати (825) до віддаленої бази даних 210 незавершені транзакції 605, що залишилися, у відповідному файлі З00 відправки. Потім | СЕ 100 може застосувати (830) до віддаленої бази даних 210 файли

З00 відправки, що залишилися, які йдуть за останнім файлом відправки зві-4. 70 В альтернативному варіанті здійснення, наприклад, (ШЕ 100 може відкинути або заархівувати файли 300 відправки, які не були застосовані до віддаленої бази даних 210, і/або мають час формування 603 до часу формування 611 файлу ініціалізації відправки. Відкинуті або заархівовані файли 300 відправки можуть включати в себе файл відправки 51-4, що відповідає ідентифікатору 61 І файлу відправки.

Зрозуміло що після застосування файлу ініціалізації 310 відправки будь-які більш пізні файли 300 відправки, які могли бути вже застосовані до віддаленої бази даних 210, можуть не зберегтися, оскільки віддалена база даних 210 може стати уніфікованою за зчитуванням з файлом ініціалізації 310 відправки.

Відповідно, ці більш пізні файли 300 відправки можуть бути застосовані повторно.

У варіанті здійснення даного винаходу файли З00 відправки та файл ініціалізації 310 відправки можуть передаватися з локальної бази даних 200 у віддалену базу даних 210 без повідомлення (про успішне одержання го даних, тобто, без сигналу АСК/МАСК для вказування того, що файли були успішно одержані. Це, переважно, скорочує додаткову службову сигналізацію, яку може створювати сигнал АСК/МАСК.

В альтернативному варіанті здійснення з віддаленої бази даних 210 може передаватися сигнал АСК/МАСК для вказування того, що файли успішно одержані. У цьому варіанті здійснення сигнал АСК/МАСК може передаватися у системах з ненадійним зв'язком. с

На Фіг.9 представлена блок-схема іншого варіанту здійснення даного винаходу, в якому система може перевіряти достовірність файлів оновлення, переданих з локальної бази диких і одержаних у віддаленій базі (8) даних. Тут, система може передати (905) множину періодичних оновлень. Кожне оновлення може містити одну або більшу кількість транзакцій. Періодичні оновлення можуть бути передані окремо або у пакетах. У деякий момент часу система може передати (910) оновлення ініціалізації і застосувати оновлення ініціалізації до о зо віддаленої бази даних. Оновлення ініціалізації може містити версію повної локальної бази даних. Спочатку система, за допомогою порівняння баз даних, може ідентифікувати (915) розходження між локальною і « віддаленою базами даних. Система може визначити (920), чи є розходження дійсними або помилковими. Потім ю система може застосувати (925) до віддаленої бази даних періодичні оновлення, відповідно до варіанту здійснення даного винаходу. Даний варіант здійснення, переважно, може забезпечувати відсутність помилок у о віддаленій базі даних, що є результатом одержання оновлень з локальної бази даних. со

Наприклад, ОЇ ТР 140 може передати (905) у віддалену базу даних 210 файли 300 відправки з деяким регулярним або нерегулярним інтервалом часу. Файли 300 відправки можуть бути передані окремо або у пакетах. У деякий момент часу ОЇ ТР 140 може передати (910) файл ініціалізації 310 відправки в ГЕ 100, і ГОє 100 може застосувати файл ініціалізації 310 відправки до віддаленої бази даних 210. ОЇ ТР 140 може порівняти « локальну базу даних 200 з віддаленою базою даних 210 та ідентифікувати (915) розходження між ними. Потім пт») с ОГТР 140 може визначити (920), чи є розходження дійсними або помилковими. Потім ОЇТР 143 може поінформувати ШЕ 100 для застосування (925) до віддаленої бази даних 210 файлів 300 відправки, відповідно з до варіанту здійснення даного винаходу. Потім (ШОЕ 100 може застосувати файли 300 відправки до віддаленої бази даних 210.

В альтернативному варіанті здійснення система може застосовувати файли відправки та файл ініціалізації

Го! відправки до ідентифікації і перевірки достовірності розходжень. У вигляді іншого варіанту система може застосовувати файли відправки та файл ініціалізації відправки після ідентифікації і перевірки достовірності о розходжень. с Зрозуміло, що процес перевірки достовірності може бути виконаний на будь-яких даних, переданих з джерела в адресат через мережу зв'язку для застосування переданих даних до адресата. ве На Фіг10А представлена блок-схема варіанту здійснення перевірки достовірності файлу відправки та файлу о ініціалізації відправки, відповідно до даного винаходу. Після передачі у віддалену базу даних декількох періодичних оновлень та оновлення ініціалізації система може перевірити достовірність цих оновлень. Кожне оновлення може містити одну або більшу кількість транзакцій, виконаних у локальній базі даних. Кожна 5Б транзакція може містити одну або більшу кількість подій. Подія є дією або можливим здійсненням у базі даних, наприклад, додавання, зміни, видалення і т.д., відносно даних у базі даних.

Ф) Спочатку система може порівняти (1000) запис у віддаленій базі даних з відповідним записом у локальній ка базі даних. Система може сформувати (1005) виключення, що описує розходження між записами віддаленої і локальної баз даних, причому виключення може бути сформоване для кожного розходження. Розходженням бо може бути будь-яка відмінність, щонайменше, в одному значенні даних між двома версіями одного запису.

Наприклад, у локальній базі даних може бути запис даних (12345, хуг.сот, 123.234.345). Відповідний запис даних у віддаленій базі даних, яка передбачається ідентичною, може відповідати (12345, арс.сот, 123.234.345).

Відповідно, у другому значенні даних запису є розходження. Отже, варіант здійснення даного винаходу може сформувати виключення, яке описує вказане розходження. Виключення може описувати розходження, просто 65 Вказуючи на те, що є розходження; визначаючи місцеположення розходження; описуючи відмінність між двома значеннями даних при розходженні і т.д. Запис даних у локальній базі даних відповідає запису даних у віддаленій базі даних (і навпаки), якщо два записи обов'язково містять ідентичні дані.

Зрозуміло, що розходження може відноситися до відмінності в одному або більшій кількості значень даних у записі або до запису загалом.

Система може зіставити, (1010) кожному виключенню ідентифікатор виключення, причому ідентифікатор виключення може відповідати ідентифікатору запису. Наприклад, запис даних (12345, хул.сот, 123.234.345) може мати ідентифікатор 410. Відповідно, ідентифікатором виключення може бути також 410. Кожне виключення може бути класифіковане як таке, що належить будь-якому з декількох видів виключень (або розходжень). Може бути сформований список виключень для включення у нього видів виключень та ідентифікатора виключення для 7/0 згрупованих там виключень. Список виключень і різні види виключень детально описані нижче. Система також може зіставити (1015) кожній події в оновленні ідентифікатор події, причому ідентифікатор події може відповідати ідентифікатору запису. Наприклад, запис даних (12345, хул.сот, 123.234.345) може мати ідентифікатор 410. Відповідно, ідентифікатором події може бути також а10. Кожна подія в оновленні може бути виявлена з передісторії подій. Передісторією подій може бути лістинг і т.д. подій, виконаних на записах локальної бази даних за деякий період часу. Передісторія подій детально описана нижче.

Потім система може визначити (1020), чи є оновлення запису достовірним. На Фіг.10В8 представлена блок-схема варіанту здійснення визначення перевірки достовірності. Дане визначення може бути здійснене наступним чином. Може бути здійснене порівняння (1022) кожної події з кожним виключенням. Якщо кожне виключення підтверджене (1024) подією, то оновлення може бути визначене (1026), як достовірне, і дане оновлення може бути застосоване до віддаленої бази даних. Інакше, якщо кожне виключення не підтверджене (1024) подією, то оновлення може бути визначене (1028), як недостовірне, і виключення можуть реєструватися як помилки. Виключення може бути підтвердженим, коли ідентифікатору виключення відповідає ідентифікатор події, і відповідні подія відповідає достовірній послідовності подій, що відповідають виду виключення. Достовірні послідовності детально описані нижче. Якщо виключення підтверджене, то система може видалити с ідентифікатор виключення зі списку виключень. Підтверджене виключення може вказувати, що розходження є достовірним, наприклад, віддалена база даних ще не одержала оновлення, але при одержанні оновлення дійсно о буде. відповідати локальній базі даних.

При перевірці достовірності система може ідентифікувати приховані помилки або збої у періодичному оновленні та оновленні ініціалізації Система може забезпечувати можливість структурної і семантичної «з коректності даних оновлення, можливість успішного застосування даних оновлення, яке не спричиняє формування виключень або іншої небажаної зупинки, можливість очного виявлення помилок при порівнянні в локальної і віддаленої баз даних між собою, і неможливість випадкового видалення значимих даних. Система ю може забезпечувати можливість успішного застосування до віддаленої бази даних періодичного оновлення та оновлення ініціалізації. -

Переважно, при перевірці достовірності може бути виявлено багато помилок, що виникають при спробі Ге) застосування оновлення до віддаленої бази даних. Наприклад, при спробі застосування можуть виявлятися помилки централізації даних, попередження про те, що об'єкт вже існує у віддаленій базі даних, або попередження про те, що є порушення зовнішнього ідентифікатора. Отже, після виконання процесу перевірки достовірності відповідно до варіанту здійснення даного винаходу, система може зробити спробу застосування « вказаних оновлень до віддаленої бази даних. Спроба може бути неуспішною, що може вказувати на наявністьв с оновленнях додаткових помилок, які роблять оновлення недостовірним. Відповідно, додаткові спроби й застосування вказаних оновлень до віддаленої бази даних не можуть бути здійснені. «» В альтернативному варіанті здійснення до виконання перевірки достовірності може бути зроблена спроба застосувати, щонайменше, одне з оновлень. Якщо спроба є неуспішною, то перевірка достовірності може бути опущена і оновлення відкинуто. З іншого боку, якщо спроба є успішною, то може бути виконана перевірка о достовірності, і достовірне оновлення зберігається, а для недостовірного оновлення реєструються розходження.

У можливому варіанті здійснення ОЇ ТР 140 може здійснювати перевірку достовірності файлів З00 відправки - та файлів ініціалізації 310 відправки для забезпечення успішного застосування до віддаленої бази даних 210 с файлів 300 відправки та файлів ініціалізації 310 відправки.

В альтернативних варіантах здійснення перевірку достовірності можуть виконувати мережні комп'ютери 121, ть І ОЕ 100 або будь-яка комбінація існуючих систем. о Відповідно до Фіг.10А, ОЇ ТР 140 може порівняти локальну базу даних 200 і віддалену базу даних 210 для визначення будь-яких виключень (або розходжень) між ними. Виключення можуть включати три види: у віддаленій базі даних 210 можуть існувати дані, які відсутні у локальній базі даних 200; у локальній базі даних 200 можуть існувати дані, які відсутні у віддаленій базі даних 210; або відповідні дані можуть існувати і у локальній базі даних 200, і у віддаленій базі даних 210, але дані можуть відрізнятися. Безумовно, (Ф, відповідні дані можуть існувати і у локальній базі даних 200, і у віддаленій базі даних 210, і дані можуть ко бути ідентичними, у цьому випадку дані можуть вважатися достовірними, отже, від ОЇ ТР 140 не потрібно ніякої додаткової обробки. во Зрозуміло, що розходження може відноситися до однієї або більшої кількості значень даних у записі або до запису загалом.

Відповідно, ОЇ ТР 140 може порівняти (1000) відповідні записи у лої сальній базі даних 200 і віддаленій базі даних 210. ОЇ ТР 140 може сформувати (1005) виключення, яке описує розходження між записом у віддаленій базі даних 210 і записом у локальній базі даних 200, причому виключення може бути сформоване для 65 Кожного розходження. ОСІ ТР 140 може зіставити (1010) кожному виключенню ідентифікатор виключення, причому ідентифікатор виключення може відповідати ідентифікатору запису. Може бути сформований список виключень для включення видів виключень та ідентифікатора виключення для виключення, що належить до даного виду виключення. У варіанті здійснення виключення може бути визначене, як виключення (або розходження) "Списку 1", якщо виключення належить до першого виду виключень, виключення "Списку 2", якщо виключення належить до другого виду виключень, або виключення "Списку 3", якщо виключення не лежить до третього виду виключень. Фіг.11 ілюструє можливий список 1140 виключень.

Зрозуміло, що наявність ідентифікатора виключення у списку виключень не означає, що файл 300 відправки або файл ініціалізації 310 відправки не придатний, оскільки, наприклад, всі три види виключень можуть виникати обгрунтовано через затримку у часі між змінами у локальній базі даних 200 і оновленнями, що /о застосовуються до віддаленої бази даних 310. Така затримка, наприклад, може бути викликана перевантаженням мережі зв'язку. По суті, перевірка достовірності може забезпечувати механізм для виключення обгрунтованих виключень з помилкових даних.

Для файлу ініціалізації 310 відправки, ОЇ ТР 140 може порівняти локальну базу даних 200 і віддалену базу даних 210 за допомогою виконання двонаправленого перегляду всіх таблиць в обох базах даних 200, 210. То /5 ЗО, всі дані у локальній базі даних 200 можуть порівнюватися відносно всіх даних у віддаленій базі даних 210. Потім всі дані у віддаленій базі даних 210 можуть порівнюватися відносно всіх даних у локальній базі даних 200. Це, переважно, забезпечує всебічне порівняння баз даних 200,210 для виявлення всіх розходжень.

Для файлу 300 відправки ОЇ ТР 140 може порівняти тільки ті записи даних у локальній базі даних 200 і віддаленій базі даних 210, які записані у файлі З00 відправки. Це, переважно, забезпечує швидкодіючий запит 2о для виявлення заданих розходжень.

В іншому варіанті може бути здійснена випадкова вибірка даних в файлі ініціалізації 310 відправки і/або файлі 300 відправки. Потім ОЇ ТР 140 може порівняти дані, вибрані випадковим чином, у локальній базі даних 200 і віддаленій базі даних 210.

Список 1140 виключень може відповідати відсутнім подіям, наприклад, додавання (ада), зміни (тод) і сч ов видалення (деї) для локальної бази даних 200, які не узгоджуються з віддаленою базою даних 210. Отже, для ідентифікації таких подій-кандидатів, ОЇ ТР 140 може дослідити останні транзакції, фіксовані у локальній базі (8) даних 200. В основному, у таблиці реєстрації, яка зберігається у локальній базі даних 200, може бути сформований елемент для кожної фіксованої транзакції. Елемент може містити ідентифікатор запису, що був змінений, транзакцію (або подію), що змінила запис (наприклад, ада, тод і/або деї), порядковий номер о зо реєстрації, що вказує черговість транзакції і т.д.

Можлива таблиця 1100 реєстрації зображена на Фіг.11. У цьому можливому варіанті файл 300 відправки - містить транзакції 1108-1114, зображені у таблиці реєстрації 1100. Перший елемент 1101 вказує, що у першій ю транзакції 1108 дані (сервера доменних імен) п! і п2 були додані до даних (домен), що відповідають ідентифікатору 41. Отже, ідентифікатором є а1, подією є додавання "ада", а порядковим номером реєстрації є о 11526. Аналогічно, другий елемент 1102 вказує, що у другій транзакції 1109 дані п8 і пО були додані до даних, со що відповідають ідентифікатору а2. Третій елемент 1103 вказує, що у третій транзакції 1110 дані, що відповідають ідентифікатору 43, були видалені. Четвертий елемент 1104 вказує, що у четвертій транзакції 1111, дані, що відповідають ідентифікатору 41, були змінені для додавання даних по. Для п'ятої транзакції 1112 п'ятий елемент 1105 вказує, що дані пб і п7 були додані до даних, що відповідають ідентифікатору аз. Для « шостої транзакції 1113 шостий елемент 1106 вказує, що дані, які відповідають ідентифікатору 44, були змінені пт») с для видалення даних п3. Кк ий елемент 1107 в й транзакції 1114 вказує, що дані, які відповідають ц ідентифікатору д5, були видалені. и"? Відповідно, згідно з Фіг1ОА, ОЇ ТР 140 може зіставити (1015) кожній події в оновленні ідентифікатор події, причому ідентифікатор події може відповідати ідентифікатору запису. Кожна подія в оновленні може бути 5 знайдена з передісторії подій. Передісторія подій, індексована і впорядкована за ідентифікатором події, може (ее) бути сформована з таблиці 1100 реєстрації. Можлива передісторія 1120 подій зображена на Фіг.11. Тут, перший і четвертий елементи 1101, 1104 у таблиці 1100 реєстрації вказують зміни для даних, що відповідають о ідентифікатору а1. Отже, передісторія 1120 подій містить ідентифікатор 491 1121 і дві події 1126, додавання ос "ада" ії подальшу зміну "той", виконані на даних, що відповідають ідентифікатору 41. Другий елемент 1102 вказує зміни для даних, що відповідають ідентифікатору 42. Отже, передісторія 1120 подій містить ть ідентифікатор 42 1122 і подію 1127 додавання "ада". Передісторія 1120 подій містить ідентифікатор 43 1123 і о діві події 1128, видалення "де!" з подальшою зміною "той", що вказуються третім і п'ятим елементами 1103, 1105, які містять зміни для даних, що відповідають ідентифікатору 43. Шостий елемент 1106 вказує зміни для даних, що відповідають ідентифікатору 44. Відповідно, передісторія 1120 подій містить ідентифікатор 44 1124 і подію 1129 зміни "той". ВИЙ елемент 1107 вказує зміни для даних, що відповідають ідентифікатору 5, і передісторія 1120 подій містить ідентифікатор 45 1125 і подію 1130 видалення "ае!". Ідентифікатори 1121-1125

ІФ) впорядковані з а1 по 45. іме) Відповідно до Фіг.10А, ОЇ ТР 140 може визначити (1020), чи є оновлення достовірним. Дане визначення може бути виконане, наприклад, відповідно до варіанту здійснення за Фіг.10В. Спочатку ОЇ ТР 140 може порівняти 60 (1022) ідентифікатори 1121-1125 подій з ідентифікаторами 1140 виключень для визначення, які ідентифікатори мають відповідність. Наприклад, відповідно до Фіг.11, ідентифікатор 1121 події й1 у хронології 1120 подій відповідає ідентифікатору виключення а1 у "Списку 2" списку 1140 виключень Після виявлення відповідних події і виключення, ОЇ ТР 140 може визначити (1024), чи підтверджене виключення подією. Підтвердження може бути виконане наступним чином. Для кожного ідентифікатора 1121-1125 події у хронології 1120 подій, ОЇ ТР 140 може 65 визначити, чи є достовірною кожна послідовність подій 1126-1130 у хронології 1120 подій. Це може бути здійснено, наприклад, шляхом дослідження списку 1140 виключень для того, щоб визначити, до якого виду виключень належить кожний ідентифікатор виключення, визначення, якою повинна бути достовірна послідовність подій для цього виду виключень, і потім по луку у передісторії 1120 подій відповідного ідентифікатора події і послідовності подій для ідентифікатора події. Достовірні послідовності для кожного виду виключень детально описані нижче. Якщо послідовність подій 1126-1130 у хронології 1120 подій відповідає достовірній послідовності, то відповідний ідентифікатор події 1121-4125 має достовірну послідовність. По суті, виключення, що відповідає ідентифікатору виключення, може бути підтверджене. І, відповідна транзакція 1108-1114, що містить вказаний ідентифікатор події, є обгрунтованою, а не помилковою. У цьому випадку ОЇ ТР 140 може видалити ідентифікатор виключення зі списку 1140 виключень. 70 Для виду виключень "Списку 1" достовірною послідовністю подій може бути (тод) (аеї). Дана послідовність може містити послідовність з нульової або більшої кількості подій зміни "той", за якими йде подія видалення "де", за якою йде довільна подія. Вид виключень "Списку 1" може відповідати даним, які можуть існувати у віддаленій базі даних 210, але бути відсутнім у локальній базі даних 200. У цьому випадку дані, можливо, були нещодавно видалені з лекальної бази даних 200 і транзакція ще не була записана у файл 300 відправки. Отже, файл 300 відправки ще не міг бути застосований до віддаленої бази даних 210. Значить, ці дані можуть ще залишатися у віддаленій базі даних 210. Це може вважатися обгрунтованим розходженням, оскільки передбачається, що у деякий момент часу файл 300 відправки буде сформований і застосований до віддаленої бази даних 210. Отже, якщо для ідентифікатора виключення у Списку 1 зі списку 1140 виключень у хронології 1120 подій виявлена будь-яка така послідовність 1126-1130, то відповідна транзакція може вважатися достовірною.

Наприклад, відповідно до Фіг.11, ідентифікатор а5 1125 і відповідні йому дані були видалені з локальної бази даних 200, як ілюструє В й елемент 1114 таблиці 1100 реєстрації і вказує хронологія 1120 подій. Під час перевірки достовірності 45 був видалений з локальної бази даних 200, але не видалений з віддаленої бази даних 210. Отже, список 1140 виключень містить ідентифікатор 45 у Списку 1. Згідно з хронологією 1120 подій, подією Га 1130, що відповідає ідентифікатору 45 1125, є видалення "де". ОГТР 140 може порівняти достовірну послідовність виду виключень "Списку 1", тобто (тод)(ае!), з подією 45 1130 у хронології 1120 подій. і9)

Оскільки достовірна послідовність "Списку 1" і подія 1130 відповідають, то транзакція 1114 видалення, що відповідає ідентифікатору 45, може вважатися обгрунтованою і не є помилкою. Відповідно, ідентифікатор а5 може бути видалений зі списку 1140 виключень. ав!

Достовірною послідовністю подій для виду виключень "Списку 2" може бути (ад4а). Дана послідовність може містити подію додавання "ада", за якою йде довільна подія. Вид виключень "Списку 2" може відповідати даним, в які існують у локальній базі даних 200, але не існують у віддаленій базі даних 210. У цьому випадку дані ю могли бути нещодавно додані у локальну базу даних 200, і транзакція ще не була записана у файл З00 відправки. Отже, файл 300 відправки міг бути ще не застосований до віддаленої бази даних 210. Отже, дані - можуть не існувати у віддаленій базі даних 210. Це також може вважатися обгрунтованим розходженням, с оскільки, очікується, що у деякий момент часу файл З00 відправки буде сформований і застосований до віддаленої бази даних 210. Відповідно, якщо для ідентифікатора виключення у Списку 2 зі списку 1140 виключень виявлена будь-яка така послідовність 1126-1130 у хронології 1120 подій, то відповідна транзакція « може вважатися достовірною.

Відповідно до Фіг.11, ідентифікатори 41 ї а2 1121, 1123 можуть бути зіставлені з даними, які, наприклад, 8 с спочатку були додані у локальну базу даних 200. Оскільки послідовності подій 1126, 1127 для них починаються з ц події додавання "ада", то ідентифікатори а1 і 42 1121, 1123 відповідають достовірним послідовностям для виду и"? виключень "Списку 2". Відповідно, транзакції 1108, 1109, що містять вказані ідентифікатори, можуть вважатися достовірними, і ідентифікатори 41 і а2 можуть бути видалені зі списку 1140 виключень. Потрібно зазначити, що ідентифікатор а3 1123 також у своїй послідовності 1128 містить подію додавання "ада". Однак, подія додавання (ее) "ада" не є першою у послідовності 1128. Відповідно, послідовність 1128 не відноситься до виду "Списку 2".

Додатково, оскільки 43 не позначений у Списку 2 списку 1140 виключень, то ОЇ ТР 140 не може здійснити його о перевірку по достовірній послідовності для Списку 2. ос Достовірними послідовностями подій для виду виключень "Списку З" можуть бути (аеї), (ада) або (тод). Дані послідовності можуть містити подію видалення "деї", за якою йде подія додавання "аада", за якою йде довільна ть подія, або подія зміни "той", за якою йде довільна подія. Вид виключень "Списку 3" може відповідати даним, о які існують в обох базах даних 200, 210, але відмінні. У цьому випадку дані могли бути нещодавно змінені у локальній базі даних 200, і транзакція ще не була записана у файл 300 відправки. Отже, файл 300 відправки ще не міг бути застосований до віддаленої бази даних 210. Отже, дані, що відповідають ідентифікатору, можуть бути ще не змінені у віддаленій базі даних 210. Знову, це може вважатися обгрунтованим розходженням, оскільки очісується, що у деякий момент часу файл 300 відправки буде сформований і застосований до іФ) віддаленої бази даних 210. Відповідно, якщо для ідентифікатора виключення у Списку З зі списку 1140 ко виключень виявлена будь-яка така послідовність 1126-1130 у хронології 1120 подій, то відповідна транзакція може вважатися достовірною. во Наприклад, відповідно до Фіг.11, ідентифікатори 43 ії 44 1123, 1124 можуть бути зіставлені з даними, які були змінені у локальній базі даних 200. У випадку ідентифікатора аз 1123, ідентифікатор 43 1123 і його дані спочатку були видалені, а потім додані зворотно з новими даними, так що послідовність подій 1118 може містити видалення "деї", за яким йде додавання "ада". У випадку ідентифікатора а4 1124, дані 44 були змінені для видалення даних, так що послідовність подій 1129 може містити зміну "той". Оскільки вказані послідовності 65 подій 1128, 1129 відповідають достовірним послідовностям для виду виключень "Списку 3", то відповідні їм транзакції 1110, 1112, 1113 можуть вважатися достовірними, і ідентифікатори 43 і д4 можуть бути видалені зі списку 1140 виключень.

Відповідно до Фіг.10В, якщо всі виключення, позначені у списку 1140 виключень своїми ідентифікаторами, були підтверджені (1024) подіями, наприклад, якщо список 1140 виключень є пустим, то ОЇ ТР 140 може визначити (1026) файл 300 відправки або файл ініціалізації 310 відправки, як достовірний, і поінформувати І ОЄЕ 100 для застосування файлу 300 відправки або файлу ініціалізації 310 відправки до віддаленої бази даних 210.

Потім ГОЕ 100 може застосувати файл 300 відправки або файл ініціалізації 310 відправки до віддаленої бази даних 210.

Ї навпаки, якщо всі виключення не були підтверджені (1024) подіями, наприклад, якщо список 1140 виключень 7/0 Не є пустим, то виключення, що залишилися можуть вказувати на помилки у файлі 300 відправки або файлі ініціалізації 310 відправки. Відповідно, ОЇ ТР 140 може визначити (1028) файл 300 відправки або файл ініціалізації 310 відправки, як недостовірний, і зареєструвати помилки у файлі помилок.

В альтернативному варіанті здійснення, якщо, наприклад, файл 300 відправки або файл ініціалізації 310 відправки був визначений як недостовірний, то після заздалегідь визначеного періоду часу ОЇ ТР 140 може 7/5 повторити процес перевірки достовірності відносно недостовірного файлу 300 відправки або файлу ініціалізації 310 відправки для підтвердження того, що розходження дійсно є помадками. Вказана заздалегідь визначена затримка забезпечує мережі більший час для передачі якого-небудь повільного файлу 300, 310 відправки, і більший час на те, щоб бази даних 200, 210 стали уніфікованими за зчитуванням.

У варіанті здійснення даного винаходу дані у віддаленій базі даних 210 можуть "відставати" від даних у локальній базі даних 200 на значний інтервал часу. Відповідно, для порівняння баз даних 200, 210 їі для виявлення помилок, бази даних 200, 210 можуть бути зроблені уніфікованими за зчитуванням у той момент часу, коли вони стануть точними копіями одна одної. В основному, віддалена база даних 210 може бути приведена, з повторенням всіх завершених транзакцій, до лекальної бази даних 200, причому дані у віддаленій базі даних 210 можуть бути зроблені по суті ідентичними даним у локальній базі даних 200. с

Відповідно, для прискорення перевірки достовірності, будь-який сформований у поточний час файл ініціалізації 310 відправки і наступні файли 300 відправки можуть бути застосовані до віддаленої бази даних і) 210 до початку перевірки достовірності. По суті, кількість розходжень може бути істотно зменшена. Така пакетна обробка файлів 300, 310 відправки може бути визначена як утворення блоків. Перший і останній з цих файлів 300, 310 відправки у блоці може бути названий нижнім і верхнім "водяним знаком" відповідно. Перший о зо блок, що називається початковим блоком, може містити файл ініціалізації 310 відправки. Всі наступні блоки, що називаються кінцевими блоками, можуть містити тільки файли 300 відправки. -

Утворення блоків може забезпечувати перевірку достовірності групи замість перевірки достовірності окремо. ю

Відповідно, при виявленні у блоці помилки, недостовірним може бути позначений весь блок, а не тільки файл

З00 відправки або файл ініціалізації 310 відправки, де виникла помилка. о

Механізми і способи, що відповідають варіантам здійснення даного винаходу, можуть бути реалізовані з со використанням універсального мікропроцесора, запрограмованого згідно з варіантами здійснення винаходу.

Отже, варіанти здійснення даного винаходу також включають носій інформації, що зчитується комп'ютером, який може містити інструкції, що можуть використовуватися для програмування процесора для виконання способу, який відповідає варіантам здійснення даного винаходу. Вказаний носій може включати в себе будь-який вид « диска, включаючи гнучкий диск, оптичний диск, компакт-диски СО-КОМ і т.д. з с Вище детально описано і проілюстровано декілька варіантів здійснення даного винаходу. Однак, має бути . очевидно, що без відхилення від суті об'єму даного винаходу можуть бути здійснені зміни і модифікації ит винаходу, що охоплюються наведеним вище описом і доданою формулою винаходу.

Claims (28)

1. Формула винаходу (ее) («в 1. Спосіб перевірки достовірності оновлення для запису у віддаленій базі даних, що здійснюється Через с мережу, причому оновлення містить щонайменше одну подію, який включає в себе: порівняння запису у віддаленій базі даних з відповідним записом у локальній базі даних, - формування виключення, що описує розходження між записом віддаленої бази даних і записом локальної о бази даних, для кожного розходження, зіставлення з кожним виключенням ідентифікатора виключення, причому кожний ідентифікатор виключення відповідає ідентифікатору запису, зіставлення з кожною подією в оновленні ідентифікатора події, причому кожний ідентифікатор події відповідає ідентифікатору запису, (Ф; визначення, чи є оновлення достовірним, за допомогою порівняння подій і виключень, що відповідають ГІ запису.
2. 2. Спосіб за п. 1, в якому оновлення для запису є достовірним, якщо кожне виключення, що відповідає бо Запису, підтверджене подією, що відповідає запису.
3. 3. Спосіб за п. 2, в якому види виключень включають в себе: перший вид виключень, в якому запис існує у віддаленій базі даних і відсутній у локальній базі даних, другий вид виключень, в якому запис існує у локальній базі даних і відсутній у віддаленій базі даних, і третій вид виключень, в якому запис існує і у локальній базі даних, і у віддаленій базі даних, але 65 значення поля запису у локальній базі даних відрізняється від значення ідентичного поля запису у віддаленій базі даних.
4. 4. Спосіб за п. 3, в якому подія підтверджує виключення, якщо: подія являє собою видалення запису з локальної бази даних, і виключення належить до першого виду виключень, подія являє собою додавання запису у локальну базу даних, і виключення належить до другого виду виключень, подія являє собою зміну запису у локальній базі даних, і виключення належить до третього виду виключень, або подія являє собою видалення запису з локальної бази даних з подальшим додаванням запису у локальну 70 базу даних, виключення належить до третього виду виключень.
5. 5. Спосіб за п. 1, що додатково включає: повторення способу перевірки достовірності оновлення через заданий час після того, як оновлення було визначене недостовірним, при визначенні оновлення недостовірним.
6. 6. Спосіб за п. 1, в якому порівняння включає: порівняння повної локальної бази даних з повною віддаленою базою даних.
7. 7. Спосіб перевірки достовірності віддаленої бази даних, що включає: передачу у віддалену базу даних множини періодичних оновлень, що базуються на додаткових змінах у локальній базі даних, кожне з множини періодичних оновлень містить щонайменше одну транзакцію, передачу у віддалену базу даних ініціалізуючого оновлення, що містить версію локальної бази даних у вигляді локальної бази даних на момент часу запуску, при цьому ініціалізуюче оновлення застосовується до віддаленої бази даних, ідентифікацію розходжень між локальною базою даних і віддаленою базою даних, визначення, чи є розходження достовірними, с поінформування віддаленої бази даних для застосування періодичних оновлень, час запуску яких більш о пізній, ніж час запуску ініціалізуючого оновлення.
8. 8. Спосіб за п. 1, що додатково включає: повторення способу перевірки достовірності оновлення через заданий час після того, як оновлення було визначене недостовірним, при визначенні оновлення недостовірним. о зо
9. 9. Спосіб за п. 7, в якому розходження включають в себе: перший вид розходжень, в якому запис існує у віддаленій базі даних і відсутній у локальній базі даних, « другий вид розходжень, в якому запис існує у локальній базі даних і відсутній у віддаленій базі даних, і ю третій вид розходжень, в якому запис існує і у локальній базі даних, і у віддаленій базі даних, але значення поля запису у локальній базі даних відрізняється від значення ідентичного поля запису у віддаленій о базі даних. со
10. 10. Система для перевірки достовірності оновлення для запису у віддаленій базі даних, що здійснюється через мережу зв'язку, в якій оновлення містить щонайменше одну подію, система включає: щонайменше один процесор, приєднаний до мережі зв'язку, і пам'ять, з'єднану з процесором, пам'ять містить базу даних і команди, адаптовані для виконання « процесором, для реалізації перевірки достовірності оновлення запису у віддаленій базі даних, яке здійснюється з с через мережу зв'язку, причому команди забезпечують виконання процессором порівняння запису у віддаленій базі даних з відповідним записом у локальній базі даних, ;» формування виключення, що описує розходження між записом віддаленої бази даних і записом локальної бази даних, для кожного розходження, зіставлення з кожним виключенням ідентифікатора виключення, причому кожний ідентифікатор виключення Го! відповідає ідентифікатору запису, зіставлення з кожною подією в оновленні ідентифікатора події, причому кожний ідентифікатор події о відповідає ідентифікатору запису, і с визначення, чи є оновлення достовірним, за допомогою порівняння подій і виключень, що відповідають Запису. пи
11. 11. Система за п. 10, в якій оновлення для запису є достовірним, якщо кожне виключення, що відповідає о запису, підтверджене подією, що відповідає запису.
12. 12. Система за п. 11, в якій види виключень включають в себе: перший вид виключень, в якому запис існує у віддаленій базі даних і відсутній у локальній базі даних, 5Б другий вид виключень, в якому запис існує у локальній базі даних і відсутній у віддаленій базі даних, третій вид виключень, в якому запис існує і у локальній базі даних, і у віддаленій базі даних, але (Ф) значення поля запису у локальній базі даних відрізняється від значення ідентичного поля запису у віддаленій ка базі даних.
13. 13. Система за п. 12, в якій подія підтверджує виключення, якщо: 60 подією є видалення запису з локальної бази даних, і виключення належить до першого виду виключень, подією є додавання запису у локальну базу даних, і виключення належить до другого виду виключень, подією є зміна запису у локальній базі даних, і виключення належить до третього виду виключень, або подією є видалення запису з локальної бази даних з подальшим додаванням запису у локальну базу даних, і виключення належить до третього виду виключень. 65
14. 14. Система за п. 10, в якій, при визначенні оновлення недостовірним, процесор повторює виконання команд для перевірки достовірності оновлення через заданий час після того, як оновлення було визначене недостовірним.
15. 15. Система за п. 11, в якій процесор порівнює повну локальну базу з повною віддаленою базою даних.
16. 16. Система за п. 10, що додатково містить: щонайменше один віддалений процесор, приєднаний до мережі зв'язку, і віддалену пам'ять, з'єднану з віддаленим процесором, у віддаленій пам'яті зберігаються віддалена база даних і команди, адаптовані для виконання віддаленим процесором, для: створення нового елемента на основі нової інформації, одержаної через мережу з бази даних, і запису покажчика на новий елемент у віддалену базу даних з використанням одиночної безперервної 70 операції, без обмеження доступу до віддаленої бази даних для здійснення пошуку.
17. 17. Система за п. 16, в якій команди додатково адаптовані для фізичного видалення існуючого елемента після запису покажчика у базу даних.
18. 18. Система за п. 16, в якій одиночною безперервною операцією є команда збереження.
19. 19. Система за п. 18, в якій віддалений процесор має розмір слова щонайменше у п-байтів, віддалена /5 пам'ять має розрядність щонайменше у п-байтів та команда збереження записує п-байтів в адресу віддаленої пам'яті, розміщену на межі п-байтів.
20. 20. Машинозчитуваний носій інформації, який містить програмні команди, адаптовані для виконання процесором, для перевірки достовірності оновлення для запису у віддаленій базі даних, що здійснюється Через мережу зв'язку, причому оновлення містить щонайменше одну подію, при цьому команди забезпечують 2о виконання процесором: порівняння запису у віддаленій базі даних з відповідним записом у локальній базі даних, формування виключення, що описує розходження між записом віддаленої бази даних і записом локальної бази даних, для кожного розходження, зіставлення з кожним виключенням ідентифікатора виключення, причому кожний ідентифікатор виключення сч відповідає ідентифікатору запису, зіставлення з кожною подією в оновленні ідентифікатора події, причому кожний ідентифікатор події (8) відповідає ідентифікатору запису, і визначення, чи є оновлення достовірним, за допомогою порівняння подій і виключень, що відповідають запису. о зо
21. 21. Машинозчитуваний носій інформації за п. 20, в якому, при визначенні оновлення недостовірним, команди забезпечують повторення перевірки достовірності оновлення через заданий час після того, як оновлення було « визначене недостовірним. ю
22. 22. Машинозчитуваний носій інформації за п. 20, в якому оновлення для запису є достовірним, якщо кожне виключення, що відповідає запису, підтверджене подією, що відповідає запису. о
23. 23. Машинозчитуваний носій інформації за п. 20, в якому види виключень включають в себе: со перший вид виключень, в якому запис існує у віддаленій базі даних і відсутній у локальній базі даних, другий вид виключень, в якому запис існує у локальній базі даних і відсутній у віддаленій базі даних, і третій вид виключень, в якому запис існує і у локальній базі даних, і у віддаленій базі даних, але значення поля запису у локальній базі даних відрізняється від значення ідентичного поля запису у віддаленій « базі даних. в с 24. Спосіб перевірки достовірності передачі даних через мережу, що включає: ідентифікацію розходжень
24. . даних між джерелом і адресатом, ідентифікацію змін даних у джерелі, які були включені у передачу, і ит порівняння розходжень зі змінами для визначення, чи є передача достовірною.
25. 25. Спосіб за п. 24, в якому джерелом і адресатом є сервери доменних імен.
26. 26. Спосіб за п. 24, в якому розходження включають в себе: ім'я домену, яке існує у джерелі і відсутнє в о адресаті, ім'я домену, яке існує в адресаті і відсутнє у джерелі, і о відповідні імена доменів, які відрізняються у джерелі та в адресаті. с
27. 27. Спосіб за п. 24, в якому зміни містять щонайменше одне з додавання імені домену у сервер доменних імен, видалення імені домену з сервера доменних імен і зміни імені домену у сервері доменних імен. ве
28. 28. Пристрій для перевірки достовірності оновлення для запису у віддаленій базі даних, що містить: о засіб ідентифікації розходжень даних між джерелом і адресатом, засіб ідентифікації змін даних у джерелі, які були включені у передачу, і засіб порівняння розходжень зі змінами для визначення, чи є передача достовірною. (Ф) ко бо б5