Розробка та експлуатація віддалених баз даних
План
1. Термінологія УБС
2. Дворівневі моделі
3. Моделі серверів баз даних
4. Типи паралелізму
5. Моделі транзакцій
Список літератури
1. Термінологія УБС
Користувач БД - це програма або людина, які звертаються до БД на мові маніпулювання даними.
Запит - це процес звернення користувача до БД з метою введення, отримання або зміни інформації у БД.
Транзакція - це послідовність операцій модифікації даних в БД, яка переводить БД з одного несуперечливого стану в інший несуперечливе стан.
Логічна структура БД - Це визначення БД на фізично незалежному рівні, ближче всього відповідному концептуальної моделі БД.
Топологія БД (структура РБД) - це схема розподілу фізичних БД по мережі. Локальна автономність означає приналежність локального власнику інформації локальної БД і пов'язаних з нею певних даних.
Віддалений запит - це запит, який виконується з використанням модемного зв'язку.
Можливість реалізації віддаленої транзакції - це обробка однієї транзакції, що складається з безлічі SQL-запитів, на одному віддаленому вузлі.
Підтримка розподіленої транзакції допускає обробку транзакції, що складається з декількох SQL-запитів, які виконуються на декількох вузлах мережі (Віддалених чи локальних), але кожен запит в цьому випадку обробляється тільки на одному вузлі, тобто запити не є розподіленими. При обробці однієї розподіленої транзакції різні локальні запити можуть оброблятися в різних вузлах мережі.
2. Дворівневі моделі
Ці моделі фактично є розподілом п'яти зазначених функцій між двома процесами, які виконуються на двох платформах - клієнті і сервері.
Модель віддаленого керування даними (модель файлового сервера). У цій моделі BL і PL розташовуються на клієнті. На сервері розташовуються файли з даними і доступ до ним. Функції управління інформаційними ресурсами в цій моделі знаходяться на клієнті.
Модель файл-сервера. У цій моделі файли БД зберігаються на сервері, клієнт звертається до сервера з файловими командами, а механізм управління всіма інформаційними ресурсами (база метаданих (БМД)) знаходиться на клієнті.
Переваги: поділ монопольного додатки на два взаємодіючих процесу. Сервер може обслуговувати безліч клієнтів, які звертаються до нього із запитами. Алгоритм виконання запиту клієнта. Запит клієнта формується в командах ЯМД. СУБД переводить цей запит в послідовність файлових команд. Кожна файлова команда викликає перекачування блоку інформації на клієнта. Далі на клієнті СУБД аналізує отриману інформацію і якщо в отриманому блоці не міститься відповідь на запит, то приймається рішення про перекачування наступного блоку інформації до тих пір, поки не буде знайдено відповіді на запит.
Модель віддаленого доступу до даних. У моделі віддаленого доступу (RDA) база даних зберігається на сервері. На ньому ж знаходиться і ядро ​​СУБД. На клієнті розташовуються PL і BL додатка. Клієнт звертається до сервера із запитами на мові SQL.
Переваги: перенесення компонента уявлення і прикладного компонента на клієнтський ПК істотно розвантажує сервер БД, зводячи до мінімуму загальне число процесів в ОС. Процесор сервера цілком завантажується операціями обробки даних, запитів і транзакцій. Різко зменшується завантаження мережі, запити на ввід-висновок і на SQL зменшуються в об'ємі, тобто у відповідь на запити клієнт отримує тільки дані, задовольняють даному запиту.
Уніфікація інтерфейсу клієнт-сервер. Стандартним при зверненні програми клієнта і сервера стає мова SQL.
Недоліки:
Запити на SQL при інтерактивній роботі клієнта можуть істотно завантажити мережу. На клієнті розташовуються PL і BL, і якщо при повторенні аналогічних функцій в різних додатках (інших клієнтів) їх код повинен бути повторений для кожного клієнтського додатку, отже, дублювання коду програми. Сервер в цієї моделі грає пасивну роль, тому функції управління інформаційними ресурсами повинні виконуватися на клієнті => це ускладнює клієнтський додаток.
Модель сервера баз даних. Для того, щоб позбутися недоліків моделі віддаленого доступу повинні бути дотримані наступні умови. Дані, які зберігаються в БД в кожен момент часу повинні бути несуперечливі. БД повинна відображати деякі правила ПЗ, закони ПЗ. Необхідний постійний контроль за станом БД, відслідковування всіх змін та адекватна реакція на них. Виникнення деякої ситуації в БД чітко і оперативно повинно впливати на хід виконання прикладної задачі. Однією з важливих проблем СУБД є контроль типів даних через мову опису даних (МОД).
Модель активного сервера. Дану модель підтримують більшість сучасних СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server.
Основу даної моделі становить механізм збережених процедур (як засоби програмування SQL-сервера), механізм тригерів (як механізм відстеження поточного стану інформаційного сховища) і механізм обмежень на користувальницькі типи даних (який іноді називається механізмом підтримки доменної структури).
В цієї моделі бізнес логіка розділена між клієнтом і сервером. На сервері бізнес логіка реалізована у вигляді збережених процедур - спеціальних програмних модулів, які зберігаються в БД і управляються безпосередньо СУБД. Клієнтське додаток звертається до сервера з командою запуску збереженої процедурою, а сервер виконує цю процедуру і реєструє всі зміни в БД, які в ній передбачені. Сервер повертає клієнту дані, релевантні його запиту. Трафік обміну інформацією між клієнтом і сервером різко зменшується.
Централізований контроль в даній моделі виконується з використанням механізму тригерів, які є частиною БД.
Тригер - Механізм відстеження спеціальних подій, які пов'язані зі станом БД. Тригер в БД є як би деяким тумблером, який спрацьовує при виникненні певної події в БД. Ядро СУБД проводить моніторинг всіх подій, які викликають створені і описані тригери в БД, і при виникненні відповідного події сервер запускає відповідний тригер => Тригер - це програма, яка виконується над БД і викликає збережені процедури. Дана модель сервера є активною, тому що не тільки клієнт, але і сам сервер використовують механізм тригерів.
Переваги: Збережені процедури і тригери зберігаються в словнику БД і можуть бути використані декількома клієнтами => зменшується дублювання алгоритмів обробки даних у різних клієнтських додатках.
Недоліком є дуже велике завантаження сервера. Функції сервера здійснює моніторинг подій, пов'язаних з описаними тригерами; Забезпечує автоматичне спрацьовування тригерів при виникненні пов'язаних з ними подій; Забезпечує виконання внутрішньої програми кожного тригера; Запускає збережені процедури по запитам користувачів; Запускає збережені процедури з тригерів; Повертає необхідні дані клієнта; Забезпечує всі функції СУБД: доступ до даних, контроль і підтримка цілісності даних в БД, контроль доступу, забезпечення коректної роботи всіх користувачів з єдиної БД.
Для розвантаження сервера була запропонована 3-рівнева модель сервера: Ця модель є розширенням дворівневої моделі, тобто вводиться додатковий проміжний рівень між клієнтом і сервером. У цій моделі компоненти додатка діляться між трьома виконавцями:
Клієнт - Забезпечує логіку уявлення, включаючи графічний користувальницький інтерфейс, локальні редактори.
Сервери додатків - складають новий, проміжний рівень архітектури.
Вони спроектовані як виконання загальних не завантажується функцій для клієнтів, підтримують функції клієнтів, підтримують мережеву доменну операційну середовище, зберігають і виконують загальні правила бізнес логіки, підтримують каталоги з даними, забезпечують обмін повідомленнями і підтримку запитів. Сервери цієї моделі займаються виключно функціями СУБД, функ...
