При асинхронному режимі зміни запам'ятовуються, а момент їх пере­дачі вибирають за якимось певним правилом. При такому способі підтрим­ки логічної цілісності розподіленої бази даних спостерігається деяка роз-синхронізація стану локальних баз даних, яка полягає в тому, що зміни, внесені до деяких локальних баз, відстають за часом їх внесення одна від одної. Інтервал часу, через який поновлюються дані в інших вузлах, має уз­годжуватися з інтервалом розв'язання задачі в цих вузлах. Асинхронне ду­блювання має недолік, оскільки не забезпечує виконання процедур понов­лення даних у масштабі реального часу. Цей режим  можна використовувати в таких інформаційних системах, у яких складно підтри­мувати постійний зв'язок між серверами, і термін тимчасової неузгоджено­сті стану бази даних не конфліктує з періодичністю розв'язання задач у цій системі.

Стратегія дублювання для багатьох фірм-виробників ПО стає домінуючою в розподілених СУБД, оскільки воно дозволяє виконати ту са­му роботу, але з меншими затратами, ніж при двофазній фіксації транзак­цій. Можливості дублювання мають такі системи, як Oracle 7, Informix-Online і Open-Ingres.

Порівняння двох методів підтримки транзакцій в розподілених базах даних наведено в табл. 6.1.

Таблиця 6.1

ПОРІВНЯЛЬНА ТАБЛИЦЯ ДВОХ МЕТОДІВ ПІДТРИМКИ ТРАНЗАКЦІЙ В РОЗПОДІЛЕНІЙ БАЗІ ДАНИХ

У розподілених системах важливим моментом є проблеми проектуван­ня розподіленої бази даних та її адміністрування. Насамперед потрібно ви­брати архітектуру розподіленої бази даних і визначити правила доступу до даних і правила її адміністрування. Встановлення правил адміністрування гарантує коректність роботи системи.

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

Другим варіантом архітектури, який також гарантує, що конфлікти не виникнуть, є динамічна передача права модифікації від сервера до сервера. При цій архітектурі кожний елемент даних має спеціальний додатковий ат­рибут, у якому можна вказати дозвіл на внесення змін при передаванні да­них між серверами. Цей варіант можна проілюструвати на прикладі бази даних торговельної організації. Наприклад, замовлення на товар було вико­нано, і він найдійшов на склад; інформацію про це можна передати на сер­вер відділу продажу з правом внесення змін у ці дані.

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

Обидва механізми підтримки транзакцій є коректними, кожний з них має певні переваги й недоліки і може використовуватися залежно від спе­цифіки задач. Тому в СУБД обидва варіанти повинні підтримуватись.

ПИТАННЯ ДЛЯ САМОПЕРЕВІРКИ

     1. Що таке розподілена база даних? 2. Які є стратегії розподілу даних?     

3. Які із стратегій розподілу даних найбільш поширені на практиці?

4. Особливості технології роботи з розподіленою базою даних.

5. Якими суттєвими відмінностями характеризуються синхронний та асинхронний режими тиражування змін в розподіленій базі даних?

6. Що таке транзакція? Які можуть виникнути ускладнення під час ро­боти з розподіленою базою даних за відсутності механізму підтримки тран­закцій?

7. Чому підтримку транзакцій можна назвати механізмом підтримки ці­лісності розподіленої бази даних?

8. Суть двофазної фіксації транзакції.