Розподілена обробка даних

План
1. Основні поняття і визначення
2. Управління паралельною обробкою
3. Багатокористувацькі СУБД.
4. Проектування багатокористувацьких баз даних
5. Проектування розподілених баз даних
6. Стандартні інтерфейси доступу до серверів баз даних
Основні поняття і визначення
Режими використання БД у загальному вигляді показані на рис. 10.1.
Якщо з БД працюють одночасно декілька користувачів, то в цьому випадку СУБД повинна забезпечувати коректну паралельну роботу всіх користувачів над одними і тими ж даними. Розрізняють розподілену обробку і розподілені БД.
Розподілена обробка - це обробка з використанням централізованої бази даних, доступ до якої може виконуватись з різних комп'ютерів мережі (рис. 10.2, a). Ця топологія часто називається "клієнт-сервер". В цій системі одні вузли - клієнти, а інші - сервери.
Сервер - комп'ютер, який надає деякі послуги іншим комп'ютерам, обмін повідомленнями з якими здійснюється за допомогою мережі, що їх з'єднує. Послуги полягають у наданні комп'ютеру, який звертається, ресурсів сервера (файлів, обчислювальних ресурсів і т.ін.) шляхом виконання вказаної програми і видачі результатів її роботи.
Клієнт - це процес, який посилає запит на обслуговування.
Розподілена база даних - це набір логічно зв'язаних між собою роздільних даних і їх описів, які фізично розподілені в деякій комп'ютерній мережі (рис. 10.2, б). Розподілена СУБД, в якій управління кожним із вузлів виконується зовсім автономно називається мультибазовою системою.
Розподілена СУБД - це програмна система, яка призначена для управління розподіленими базами даних і яка
забезпечує прозорий доступ користувачів до розподіленої інформації.
Якщо всі вузли розподіленої системи використовують той самий тип СУБД, то така система називається гомогенною. Якщо вузли розподіленої системи використовують різні типи СУБД, які обробляють різні моделі даних, то така система називається гетерогенною.
Управління паралельною обробкою
В багатокористувацьких системах з БД одночасно можуть працювати декілька користувачів або прикладних програм. Для збереження цілісності даних і забезпечення безпеки БД в цих умовах застосовуються транзакції, які забезпечують роботу кожного користувача з узгодженим станом БД.
Транзакція - неподільна з точки зору впливу на БД послідовність операторів маніпулювання даними, яка розглядається СУБД як єдине ціле. Або транзакція успішно
виконується, і СУБД фіксує зміни БД, які були зроблені цією транзакцією, у зовнішній пам'яті, або, у разі невдачі, жодна зміна не відображається на стані БД. Транзакція розглядається як логічна одиниця роботи з БД. Для того, щоби використання механізмів обробки транзакцій дозволило забезпечити цілісність даних й ізольованість користувачів, транзакція повинна мати такі властивості: атомарність (Atomicity), узгодженість (Cosistency), ізольованість (Isolation), довготерміновість (Durability). Транзакції, які мають ці властивості називаються ACID-транзакціями. Властивості транзакції означають таке:
- атомарність означає, що транзакція виконується, як єдина операція доступу до БД і виконується або повністю або не виконується зовсім;
- узгодженість гарантує взаємну цілісність даних, тобто виконання обмежень цілісності БД після завершення роботи транзакції;
- ізольованість означає, що транзакції, які конкурують за доступ до БД, фізично обробляються послідовно, ізольовано одна від одної, але для користувачів це виглядає так, ніби вони виконуються паралельно;
- довготерміновість означає, що коли транзакція виконана успішно, то всі зміни, які вона зробила в даних, не будуть втрачені ні за яких обставин.
Для обробки паралельних транзакцій застосовується серіалізація транзакцій і метод тимчасових міток.
Серіалізація транзакцій - процедура, яка забезпечує підтримку незалежного виконання трансакцій. Це означає, що дія двох паралельно діючих транзакцій буде така сама, як і їх послідовна дія: спочатку перша, а потім друга, або навпаки - спочатку друга, а потім перша. У ході виконання транзакції користувач бачить тільки узгоджені дані і не бачить неузгоджених проміжних даних. Для підтримки паралельної роботи складається спеціальний план.
Для реалізації серіалізації транзакцій застосовується механізм блокувань. Блокування передбачає встановлення режиму доступу (монопольного або сумісного) до деякого ресурсу даних, що дозволяє виключити доступ до нього одночасно з даною транзакцією інших транзакцій, в результаті якого може бути порушена логічна цілісність даних БД. Об'єктом блокування може бути вся БД, окремі таблиці, сторінки, рядки.
Для підвищення ступеня паралельності доступу декількох користувачів до однієї БД використовуються такі блокування:
- нежорстке блокування або роздільне блокування (Shared - S-блокування); об'єкт блокується для виконання операції читання; об'єкти в цьому випадку не змінюються у ході виконання транзакції і доступні іншим транзакціям також, але тільки в режимі читання;
- жорстке блокування або монопольне (exclusive - X-блокування); об'єкт блокується для виконання операції запису, модифікації або вилучення. В цьому випадку виконується монопольне блокування об'єкта і об'єкт залишається недоступним іншим транзакціям до моменту завершення роботи даної транзакції.
Застосування різних типів блокувань призводить до тупиків. Тупикова ситуація виникає тоді, коли дві і більш транзакції одночасно знаходяться у стані очікування, причому для продовження роботи кожна з транзакцій очікує завершення роботи іншої транзакції.
Приклад. Нехай транзакція 1 в момент часу t1 блокує ресурс A, а транзакція 2 в момент часу t2 блокує ресурс B (рис.10.3). В момент часу t3 транзакції 1 потрібен ресурс B і вона очікує його звільнення транзакцією 2. В момент часу t4 транзакції 2 потрібен ресурс A і вона очікує його звільнення
Основою визначення тупикових ситуацій є побудова графа очікування транзакцій. Алгоритм виходу із тупика передбачає визначення транзакції-жертви. Після вибору такої транзакції виконується її відкат.
Для серіалізації транзакцій також застосовується двофазне блокування, яке полягає у такому:
- перед виконанням операцій з будь-яким об'єктом транзакція блокує цей об'єкт (накопичення захватів);
- після зняття блокування транзакція не повинна накладувати ніяких інших блокувань (вивільнення захватів).
Багатокористувацькі СУБД
В якості сервера може розглядатися програма, яка надає деякі послуги по запитах інших програм, що називаються клієнтами. Взаємодія між клієнтами і сервером здійснюється за допомогою передачі повідомлень відповідно до заданого протоколу.
В технології роботи з БД виділяють функції:
транзакцією 1. Транзакція 1 чекає транзакцію 2, транзакція 2 чекає транзакцію 1.
- вводу і відображення даних (представлення даних);
- прикладні функції, які визначають основні алгоритми розв'язання прикладних задач (застосування);
- обробки даних у застосуваннях;
- управління інформаційними ресурсами (СУБД).
Представлення даних визначає те, що користувач бачить
на своєму екрані. Тут визначаються екранні зображення, операції читання і запису даних, управління діалогом.
Прикладні функції (бізнес-логіка) визначають логіку роботи прикладних програм застосувань. Код застосування пишеться з використанням процедурних мов програмування.
Функції обробки даних пов'язані з обробкою даних всередині застосувань. Даними керує СУБД. Для забезпечення доступу до даних використовується мова SQL, яка найчастіше вбудовується в мови, які використовуються для створення коду застосування.
Функції управління інформаційними ресурсами - це СУБД, яка забезпечує зберігання і управління БД.
Залежно від того, де розташовані ці компоненти по відношенню одна до одної розрізняють монолітне виконання (найчастіше для персональних БД), дво- і трирівневе.
Дворівнева архітектура характеризується тим, що всі функції розподіляються між двома процесами, які виконуються на двох платформах: на клієнті і на сервері. В дворівневій архітектурі в свою чергу можлива реалізація таких моделей:
- модель файлового сервера;
- модель віддаленого доступу до даних;
- модель сервера бази даних.
У моделі файлового сервера (рис. 10.4) застосування розташовуються і виконуються на робочих станціях. На файловому сервері зберігаються тільки файли БД (файли даних, індекси і т.ін.) і деякі технологічні файли, які необхідні для роботи застосувань і самої СУБД. Клієнт звертається до СУБД на мові SQL, СУБД перекладає запит у послідовність файлових команд і передає файловому серверу. На кожну команду сервер передає блок даних. Обробка інформації виконується на робочій станції за допомогою СУБД. Системи цього класу коштують недорого, прості в установці й освоєнні. До недоліків можна віднести таке:
- на кожній робочій станції знаходиться копія СУБД;
- низька продуктивність систем, оскільки всі проміжні дані передаються по мережі, а обробка виконується на робочих станціях, потужність яких значно поступається потужності сервера;
- складність розподіленої обробки.
У моделі віддаленого доступу до даних (рис. 10.5) БД і СУБД знаходяться на сервері, застосування розташовуються і виконуються на робочих станціях. Клієнт звертається до серверу на мові SQL. В цій архітектурі сервер виконує функції обробки транзакцій, даних і запитів. Сервер не перевантажений виконанням застосувань. Значно зменшується завантаження мережі у порівнянні з сервером файлів, оскільки по мережі від клієнта до сервера передаються команди на мові SQL, а не файлові команди, обсяг яких значно більший. Від сервера до клієнта передаються дані, які відповідають запиту, а не блоки файлів. Недоліками моделей є таке:
- запити на мові SQL при інтенсивній роботі можуть значно завантажити мережу;
- прикладні функції застосувань необхідно повторювати для кожного клієнтського комп'ютера;
- сервер виконує пасивну роль і тому функції управління інформаційними ресурсами повинні виконуватись клієнтом.
Модель сервера бази даних (рис. 10.6) є подальшим розвитком моделі віддаленого доступу. Ця модель розширена механізмами процедур, що зберігаються і механізмами тригерів, які створюються на розширенні мови SQL.


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


Подальшим розвитком моделі сервера бази даних є трирівнева архітектура (рис.10.7). Ця архітектура ще називається моделлю із сервером застосувань.
Сервер застосувань - в триланковій архітектурі "клієнт- сервер" компонент прикладної системи, який розташовується між клієнтом і сервером БД і реалізує логіку застосування.
У цій моделі клієнт виконує тільки представлення інформації, сервер БД - виконує функції управління інформаційними ресурсами БД, забезпечує функції створення і ведення БД, підтримує цілісність БД. Сервер застосувань виконує загальні функції для клієнтів, забезпечує обмін повідомленнями, підтримує запити, зберігає і виконує найбільш загальні правила бізнес-логіки.
Перевагою моделі із сервером застосувань є гнучкість і універсальність внаслідок розділення функцій на три незалежні складові. Головним недоліком є більш високі витрати ресурсів комп'ютера на обмін інформацією між компонентами застосування у порівнянні з дворівневими моделями.
Проектування багатокористувацьких баз даних
Багатокористувацька БД передбачає, що у визначенні вимог до БД задіяні декілька користувачів. Залежно від того, як враховуються вимоги користувачів, розрізняють централізований підхід й інтеграцію представлень користувачів. Централізований підхід передбачає, що вимоги до кожного представлення користувача об'єднуються в загальний набір вимог (рис. 10.8).
На етапі проектування БД створюється глобальна модель даних, яка відповідає загальному представленню. Глобальна модель також перевіряється, як і локальні моделі. Коректність глобальної моделі перевіряється за допомогою правил нормалізації, що дозволяє переконатися в структурній узгодженості, логічній цілісності і мінімальній збитковості прийнятої моделі даних. Модель також перевіряється з метою виявлення можливостей виконання транзакцій, які будуть задаватися користувачами.
Інтеграція представлень користувачів передбачає, що вимоги до кожного представлення користувача застосовуються для створення окремої моделі даних, яка відповідає цьому представленню користувача. У подальшому, на етапі проектування БД, моделі даних, що отримані об'єднуються в єдину глобальну модель даних (рис. 10.9).
Після завершення об'єднання локальних моделей може виникнути необхідність перевірити вірність отриманої глобальної моделі, як у відношенні правил нормалізації, так і у відношенні можливості виконання транзакцій, передбачених специфікаціями всіх представлень користувачів. Це викликано тим, що між окремими моделями може існувати несумісність або взаємне перекриття. Простий підхід до об'єднання декількох моделей передбачає, що спочатку об'єднуються дві моделі для отримання нової моделі, а потім до них послідовно додаються інші локальні моделі.
Проектування розподілених баз даних
На рис. 10.10 показана архітектура розподіленої СУБД.
Існують такі схеми розміщення даних в системі:
- централізоване;
- фрагментоване;
- з повною реплікацією;
- з вибірковою реплікацією.
Централізоване розміщення передбачає, що на одному з вузлів створюється і зберігається єдина БД. Доступ до цієї БД мають всі користувачі мережі.
Фрагментоване розміщення передбачає, що БД ділиться на неперетинні фрагменти, кожен з яких розміщується в одному з вузлів системи.
Розміщення з повною реплікацією передбачає, що повна копія БД розміщується на кожному вузлі системи.
Розміщення з вибірковою реплікацією являє собою комбінацію методів фрагментування, реплікації й централізації. Одні масиви даних поділяються на фрагменти, інші реплікуються, останні зберігаються централізовано.
Реплікація це процес генерації і відтворювання декількох копій даних, які розміщуються на одному або декількох вузлах. Використання реплікацій дозволяє досягнути багатьох переваг (продуктивність, надійність зберігання даних, відновлення даних і т.ін.).


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


що оновлення реплікованих даних виконується із затримкою відносно оновлення вихідних даних.
Система підтримує фрагментацію, якщо дане відношення може бути поділене на частини або фрагменти при організації його фізичного зберігання. Фрагментація бажана для підвищення ефективності системи. В цьому випадку дані можуть зберігатися в тому місці, де вони найчастіше використовуються. Це дозволяє досягнути локалізації більшості операцій і зменшити трафік мережі. Крім того, виключається зберігання даних, які не використовуються локальними застосуваннями, що сприяє підвищенню захисту в системі. Для коректності фрагментації необхідно виконати правила:
- повнота - це означає, що кожен елемент даних з вихідного відношення, повинен бути присутнім щонайменше в одному фрагменті;
- підновленість - це означає, що вихідне відношення може бути відновлено з його фрагментів за допомогою реляційної алгебри;
- неперетинність - це означає, що один елемент не повинен бути присутнім в двох і більше фрагментах.
Фрагментація може бути вертикальна (по атрибутах) і горизонтальна (по кортежах).
На рис.10.11 показана послідовність проектування розподілених БД. Відмінність проектування від централізованих БД полягає в застосуванні фрагментації відношень, реплікації фрагментів і розподілі фрагментів по вузлах мережі. Визначення і розміщення фрагментів повинно виконуватися з урахуванням особливостей використання БД. Під цим розуміється виконання аналізу транзакцій, необхідна продуктивність системи, підтримка цілісності даних і т.ін.
Згідно з правилами Дейта розподілена СУБД повинна відповідати таким вимогам:
- розподілена система повинна виглядати з точки зору користувача, як звичайна нерозподілена система;
- вузли в розподіленій системі повинні бути незалежні або автономні;
- в системі не повинно бути жодного вузла, без якого система не може функціонувати;
- повинна виконуватись умова незалежності від розташування і користувач може отримувати доступ до БД з будь-якого вузла;
- незалежність від фрагментації - це означає, що користувач може отримати доступ до даних незалежно від засобу їх фрагментації;
- незалежність від реплікації - це означає, що користувач не має засобів доступу до конкретної копії даних і не займається питаннями оновлення всіх копій в БД;
- підтримка обробки розподілених запитів;
- підтримка управління розподіленими транзакціями;
- апаратна, програмна, мережна незалежність, а також незалежність від типу СУБД;
- забезпечення безперервного функціонування.
Стандартні інтерфейси доступу до серверів баз даних
Для доступу до БД застосовують такі інтерфейси:
- інтерфейс прикладного програмування (API, Application Programming Interface);
- інтерфейс рівня викликів (SQL/CLI, SQL/Call Level Interface);
- відкритий інтерфейс для підключення до БД (ODBC, Open Database Connectivity);
- інтерфейс прикладного програмування для мови Java (JDBC, Java Database Connectivity);
- об'єктно-орієнтований інтерфейс OLE DB (Object Linking and Embedding for DataBase);
- високорівневий об'єктно-орієнтований інтерфейс ADO (ActiveX Data Objects);
- високорівневий об'єктно-орієнтований інтерфейс ADO.NET (ActiveX Data Objects.NET) для доступу в платформі .NET.
Інтерфейс прикладного програмування - сукупність програмних засобів, які забезпечують прикладній програмі на традиційній мові програмування доступ до систем БД, який підтримується у середовищі конкретної СУБД. Реалізація API являє собою інтерфейс рівнів викликів. Вона включає бібліотеку функцій або процедур, які забезпечують зв'язок прикладної програми і СУБД.
Інтерфейс рівня викликів CLI - стандартизований інтерфейс прикладного програмування в SQL-серверах БД.
Стандарт ODBC - це інтерфейс, за допомогою якого прикладні програми можуть звертатися до SQL-баз даних і обробляти їх незалежним від СУБД засобом. Застосування може звертатися до БД, які підтримують різні СУБД, без необхідності його змінювати і перекомпільовувати (рис. 10.12).
Ошибка! Объект не может быть создан из кодов полей редактирования.
Рис. 10.12. Використання стандарту ODBC для доступу до даних
Стандарт JDBC - це інтерфейс, за допомогою якого прикладні програми на мові Java можуть звертатися до SQL-баз даних і обробляти їх незалежним від СУБД засобом. Цей стандарт є основою для створення інструментальних засобів і інтерфейсів більш високого рівня.
Стандарт OLE DB - це об'єктно-орієнтований інтерфейс, який дозволяє застосуванням сумісно використовувати і управляти наборами даних як об'єктами. OLE DB являє собою набір спеціалізованих об'єктів COM (СотропеП Object Model), які включають в себе стандартні функції обробки даних і спеціалізовані функції конкретних джерел даних і інтерфейсів, які забезпечують передачу даних між об'єктами. Технологія OLE DB забезпечує доступ на низькому рівні до будь-яких джерел даних.
Стандарт ADO - це технологія, яка забезпечує механізми взаємодії об'єктів з даними і застосуваннями. ADO також виконує роль інтерфейса прикладного рівня з механізмами OLE DB (рис. 10.13).


Стандарт ADO.NET - це нова версія технології ADO. ADO.NET являє собою набір класів, який використовується для доступу до джерел даних в платформі .NET. ADO.NET використовує в якості стандарта мову XML для передачі даних.
Література
1. Гайдамакин Н.А. Автоматизированные информационные системы, базы и банки данных. Вводный курс. - М.: Гелиос АРВ, 2002. - 368 с.
2. Гайна Г.А. Організація баз даних і знань. Мови баз даних: Конспект лекцій.-К .:КНУБА, 2002. - 64 с.
3. Гайна Г.А., Попович Н.Л. Організація баз даних і знань. Організація реляційних баз даних: Конспект лекцій. - К.:КНУБА, 2000. - 76 с.
4. Гарсиа-Молина Г., Ульман Д., Уидом Д. Системы баз данных.-М.: Издательский дом "Вильямс", 2003. - 1088 с.
5. Григорьев Ю.А., Ревунков Г.И. Банки данных.-М.: Изд-во МГТУ им. Н.Э.Баумана, 2002. - 320 с.
6. Грофф Дж., Вайнберг П. Энциклопедия SQL. - СПб.: Питер, 2003. - 896 с.
7. Дейт К.Дж. Введение в системы баз данных. - К.: Диалектика, 1998. - 784 с.
8. Диго С.М. Проектирование и использование баз данных.-М.: Финансы и статистика, 1995. - 208 с.
9. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2001. - 304 с.
10. Когаловский М.Р. Энциклопедия технологий баз данных.- М.: Финансы и статистика, 2002. - 800 с.
11. Конноли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. - М.: Издательский дом "Вильямс", 2003. - 1440 с.
12. Кренке Д. Теория и практика построения баз данных. - СПб.: Питер, 2003. - 800 с.
13. Малыхина М.П. Базы данных: основы, проектирование, использование. - СПб.: БХВ-Петербург, 2004. - 512 с.
14. Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление. - СПб.: БХВ-Петербург, 2004. - 1040 с.

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать