Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
морозов_лекц .doc
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
565.25 Кб
Скачать

Тема 2. Управління розподіленою інформацією

2.1. Принципи управління розподіленою інформацією

"Ядром" системи управління розподіленими інформаційними ресурсами є розподілена база даних (РоБД) і система управління розподіленою базою даних (РоСУБД). Тому визначимо спочатку ці поняття.

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

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

Ці визначення можна доповнити, якщо розглянути також різні характеристики РоБД і РоСУБД. В 1987 році До. Дейт опублікував 12 правил для розподілених баз даних.

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

2. Ніякий конкретний сервіс не повинен покладатися на який-небудь спеціально виділений центральний вузол. Дотримання цього правила, тобто принципу децентрацізації функцій РоСУБД, дозволяє уникнути вузьких місць.

3. Безперервність функціонування. Система не повинна зупинятися у разі потреби додавання нового вузла або видалення в розподіленому середовищі деяких даних, зміни визначення метаданих і навіть (що досить складно) здійснення переходу до нової версії СУБД на окремому вузлі.

4. Незалежність від розташування. Користувачі і додатки не зобов’язані знати про те, де фізично розташовуються дані.

5. Незалежність від фрагментації. Фрагменти (звані також розділами) даних повинні підтримуватися і оброблятися засобами РоСУБД так, щоб користувачі або додатки могли б взагалі нічого не знати про це. Більш того, РоСУБД повинна уміти обходити при обробці запитів фрагменти, що не мають до них відношення (наприклад, РоСУБД повинна бути достатньо інтелектуальною, для того, щоб визначати, чи можна виключити при обробці запиту той або інший фрагмент внаслідок того, що запит не містить посилань на стовпці, що зберігаються в цьому фрагменті).

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

7. Розподілена обробка запитів. Обробка запитів повинна проводитися розподіленим чином.

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

9. Незалежність від устаткування. Одне і те ж програмне забезпечення РоСУБД повинно виконуватися на різних апаратних платформах і функціонувати в системі як рівноправний партнер. Як вже обговорювалося вище, на практиці досягти цього виключно складно, оскільки багато постачальників підтримують безліч платформ. Це обмеження долається за допомогою моделі середовищ з багатьма продуктами.

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

11. Незалежність від мережі. Вузли можуть бути зв’язані між собою за допомогою різноманітних мережних і комунікаційних засобів. Багаторівнева модель, властива багатьом сучасним інформаційним системам (наприклад, семирівнева модель OSI, модель TCP/IP, рівні SNA і DECnet), забезпечує рішення цієї проблеми не тільки в середовищі РоБД, але і для інформаційних систем взагалі.

12. Незалежність від СУБД. Локальні СУБД повинні мати змогу брати участь у функціонуванні РоСУБД.

Очевидно, що, хоча було украй бажано мати системи, що задовольняють всім 12 правилам, нереально чекати реалізації цих вимог в рамках хоча б одного продукту навіть в найближчі роки. І дійсно, за час, що пройшов з моменту публікації правил Дейта, ця мета так і не була досягнута.

Частково з цієї причини постачальники, що орієнтуються на ринок розподілених баз даних, дотримуються багато-етапного підходу до упровадження засобів розподілення в свої продукти. Однією з самих відомих пропозицій в цій області є висунута в 1989 р. компанією IBM програма, де були визначено чотири кроки, необхідні для переходу до управління розподіленими базами даних і покликаних забезпечити наступні можливості:

1.  Видалений запит. Ця парадигма еквівалентна базовій моделі видаленого доступу. Виконується підключення до видаленого вузла і проводиться читання або зміна даних на цьому вузлі. Результат поступає на початковий вузол, після чого трансакція завершується. Практично будь-яка комерційна СУБД в даний час підтримує видалені запити, і така можливість надається вже протягом деякого часу.

2.  Видалена одиниця роботи. Це означає, що на видаленому вузлі можна виконати групу запитів як атомарну одиницю (трансакцію). Додаток, взагалі кажучи, може одержувати і модифікувати дані багатьох вузлів, але кожна трансакція зачіпає дані тільки одного вузла.

3.  Розподілена одиниця роботи. При цьому кожний запит відноситься тільки до одного вузла, але запити, що становлять розподілену одиницю роботи(трансакцію), можуть виконуватися спільно на декількох вузлах. Вся група запитів при цьому фіксується або відкатується як одне ціле.

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

Можливості останнього з чотирьох кроків - розподілених запитів - можуть бути істотно розширені відносно распределенности і неоднорідності.