
- •Тема 1: Вступ. Мета та задачі курсу. 3
- •Тема 2. Управління розподіленою інформацією 13
- •Тема 3. Технологія клієнт-сервер в базах даних 19
- •Тема 4. Управління розподіленою інформацією 23
- •Тема 6. Об’єктно-орієнтовані бази даних 32
- •Тема 7. Перспективні технології бази даних 41
- •Тема 1: Вступ. Мета та задачі курсу.
- •1.1. Інформаційні технології та бази даних
- •1.2. Історія розвитку технологій баз даних
- •1.3. Основні тенденції розвитку інформаційних систем
- •1.3.1. Розподіл і децентралізація
- •1.3.2. Неоднорідність
- •1.3.3. Розвиток стандартів
- •1.3.4. Моделювання реального світу
- •1.4. Зв’язок управління інформацією з іншими дисциплінами інформаційних систем
- •1.5. Основні перспективні ідеї в технології баз даних
- •1.5.1. Маніфест систем баз даних третього покоління
- •1.5.2. Маніфест об’єктно-орієнтованих систем баз даних
- •1.5.3. Симпозіум Національної наукової фундації сша
- •Тема 2. Управління розподіленою інформацією
- •2.1. Принципи управління розподіленою інформацією
- •2.2. Моделі розподілених баз даних
- •2.2.1. Однорідні і неоднорідні системи
- •2.2.2. Методи побудови розподілених баз даних „зверху вниз” і „знизу до верху”
- •Тема 3. Технологія клієнт-сервер в базах даних
- •3.1. Основи архітектури клієнт-сервер
- •3.2. Основні принципи і критерії оцінки систем клієнт-сервер
- •3.3. Стандарти архітектури клієнт-сервер в управлінні інформацією
- •3.3.1. Sql Access Group і стандарт drda
- •3.3.2. Стандарти, засновані на інтерфейсі рівня викликів sag
- •3.4. Програмне забезпечення проміжного шару
- •Тема 4. Управління розподіленою інформацією
- •4.1. Принципи побудови сховищ даних
- •4.2. Цифрові бібліотеки і інформаційні магістралі
- •Теми 5. Паралельні системи баз даних
- •5.1. Сучасні підходи до фрагментація і тиражування
- •5.2. Концепції мрр і паралельних систем баз даних
- •5.3. Моделі фрагментації для паралельних систем баз даних
- •5.3. Перспективи розвитку паралельних систем баз даних
- •5.4. Перспективи тиражування
- •Тема 6. Об’єктно-орієнтовані бази даних
- •6.1. Характеристики і мотивація об’єктно-орієнтованих баз даних
- •6.2. Концепції об’єктно-орієнтованих баз даних
- •6.2.1. Індивідуальність об’єктів
- •6.2.2. Атрибути
- •6.3.3. Методи
- •6.3.4. Класи
- •6.3.5. Ієрархії класів і наслідування
- •6.3.6. Довготривале зберігання
- •6.4. Співвідношення гібридного і розширеного реляційного підходів
- •6.5. Об’єктно-орієнтовані механізми управління даними і моделі
- •6.6. Діяльність odmg по стандартизації
- •Тема 7. Перспективні технології бази даних
- •7.1. Бази даних з інтегрованим часом
- •7.2. Основні принципи часових баз даних
- •7.3. Моделі даних з часом
- •7.4. Часові розширення мов баз даних
- •7.5. Об’єктно-орієнтовані часові бази даних
- •7.6. Активні бази даних
- •7.7. Принципи активних систем баз даних
- •7.7.1. Обмеження і твердження
- •7.7.2. Збережувані процедури
- •7.7.3. Тригери
- •7.8. Розширення моделей активних баз даних
- •7.9. Моделі трансакцій і активні бази даних
- •7.10. Штучний інтелект і технологія баз даних
Тема 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. Розподілений запит. Цей крок передбачає можливість виконання запитів, що охоплюють безліч баз даних на різних вузлах. Дещо таких розподілених запитів може бути далі згруповано як трансакція.
Можливості останнього з чотирьох кроків - розподілених запитів - можуть бути істотно розширені відносно распределенности і неоднорідності.