У крупних САПР, побудованих на основі корпоративних мереж, не завжди вдається організувати централізоване розміщення всіх баз даних і СУБД на одному вузлі мережі. В цьому випадку створюють розподілені БД (РБД) [1].
При побудові РБД доводиться вирішувати ряд складних проблем, пов'язаних з мінімізацією трафіку, забезпеченням інтероперабельності обробки даних і цілісності даних.
Мінімізація трафіку потрібна у зв'язку з тим, що при обслуговуванні запиту можуть потрібно дані з багатьох вузлів, що пересилаються по мережі. Можливості мінімізації видно з прикладу обробки даних декількох таблиць з різних вузлів. Очевидно, що доцільна одноразова пересилка таблиць (причому таблиць саме меншого розміру) на один вузол, на якому і оброблятиметься запит.
Інтероперабельність виражає здатність взаємодії програм, що працюють в гетерогенних мережах (у різних операційних середовищах або з різними СУБД). Інтероперабельність забезпечується або за допомогою програм-шлюзів (конверторів) (для кожної пари тих, що взаємодіють) середовищ, або за допомогою єдиної уніфікованої мови взаємодії. Такою мовою для доступу до БД є мова SQL, інтероперабельність на його основі має місце в системі ODBC, приклад реалізації якої показаний на рис.16.2 У прикладі СУБД FoxPro знаходиться в локальному вузлі, а СУБД Ingres і Informix - у видалених вузлах. Прикладна програма має ODBC-інтерфейс, не залежний від особливостей різних СУБД. Менеджер драйверів реалізує на базі уніфікованої мови SQL всі нюанси доступу до БД, загальні для різних СУБД. Драйвер конкретної СУБД перетворить інваріантні до СУБД запити у форму, прийняту в даній СУБД.
Рис.16.2 Структура ODBC
Забезпечення цілісності в РБД набагато складніше, ніж в одновузлових БД. Розрізняють два підходи до побудови РБД:
1) тиражування (реплікація), при якому на декількох серверах (вузлах) мережі розташовані копії БД;
2) повномасштабна розподіленість, при якій різні частини БД знаходяться на різних серверах мережі (класична розподіленість).
Застосовують два способи тиражування.
Спосіб, званий реплікацією першої копії, заснований на виділенні серед серверів з копіями БД одного первинного сервера (реплікатора). Внесення змін користувачами можливо тільки в БД первинного сервера, який надалі здійснює тиражування. Тиражування - це перенесення змін БД з первинного сервера у всі вторинні (локальні) сервери, які використовуються клієнтами тільки для читання даних. Реплікатор реагує на події, що фіксуються трігерами, періодично пересилає оновлені дані в копії БД. Недолік способу - невисока надійність, властива будь-яким централізованим структурам.
Надійність підвищується при використанні способу голосування. Тут зміни посилаються не в один первинний, а в деякі N серверів. При цьому будь-який запит на читання прямує до деяких М серверів, причому N + М > К, де К - загальне число серверів. Приймається остання за часом оновлення версія відповіді.
Тиражування вносить надмірність в дані, що зберігаються, з'являються труднощі з вирішенням конфліктів із-за можливих неузгодженіх змін в локальних БД. Проте в порівнянні з класичними РБД, в яких дані не дублюються, при тиражуванні помітно зменшується трафік, надійніше і простіше здійснюється робота з локальними БД.
У класичних розподілених СУБД (РСУБД) необхідно управляти одночасним доступом, що повинне гарантувати цілісність БД. Найширше використовуються алгоритми управління, засновані на механізмі блокування. При цьому блокуванням називають ситуацію, при якій деяка транзакція оголосила про бажання отримати повноваження на доступ до сторінки пам'яті і, отже, інші транзакції не мають права займати цей ресурс.
Одним із способів управління є централізоване блокування, при якому на одному з вузлів підтримується єдина таблиця блокувань. Такий вузол встановлює черговість виконання транзакцій, що виключає конфлікти. Проте при централізованому управлінні невисока надійність і потрібний могутній сервер.
У РСУБД з реплікацією немає проблеми узгодження при записі дій багатьох вузлів. Власне тиражування найчастіше виконується за правилом повної еквівалентності - оновлені дані відразу ж після транзакції, що змінила їх, розсилаються по всіх локальних БД. Читання ж виконується з БД одного конкретного вузла, найбільш близького до користувача у функціональному або географічному сенсі.
Складніше вирішувати проблеми розподіленого управління, що потрібний в РСУБД без тиражування. Одним з поширених протоколів розподіленого управління є протокол двофазної фіксації транзакцій. На першій фазі ініціатор транзакції (координатор) розсилає учасникам виконання транзакції сповіщення про блокування. У відповідь вузли повідомляють про свою готовність або неготовність. На другій фазі координатор повідомляє або про «глобальну фіксацію», тобто про виконання транзакції, або про відкіт транзакції. Неприємності можливі при збоях, які можуть залишити деякий вузол в заблокованому стані, при якому він не може ні виконувати транзакцію, ні відміняти її в односторонньому порядку.
Розвитком РСУБД є розподілені сховища даних, що використовують єдину логічну модель з безліччю фізичних місць розташування. Дані логічно розділяються на домени (наприклад, всі записи, що відносяться до конкретного регіону, до всіх даних клієнтів з одного місця і т.п.) і розподіляються без дубльованих записів по різних крапках (locations). Причин для використання такого підходу множина - починаючи від створення фізичних зон безпеки даних і закінчуючи аналітичними операціями, що ґрунтуються на часових зонах.
