
- •Тема 3. Архітектура субд
- •Тема 3. Архітектура субд 1
- •3.1. Використання та типові складові субд
- •3.1.1. Огляд варіанту структури субд
- •3.1.1.1. Команди мови визначення даних та обробки запитів
- •Обробка запитів
- •3.1.1.2. Процесор запитів
- •3.1.1.3. Збереження файлів на диску
- •3.1.1.4. Менеджери буферів та зберігання даних
- •3.1.1.5. Обробка транзакцій
- •3.1.1.6. Acid - властивості транзакцій
- •3.2. Субд навігаційного типу. Ієрархічні. Сітьові.
- •3.2.1. Навігаційні бази даних
- •3.2.2. Ієрархічні бази даних
- •3.2.2.1. Керуюча частина ієрархічної моделі
- •3.2.2.2. Приклади типових операторів пошуку даних
- •3.2.2.5. Відомі ієрархічні субд
- •3.2.3. Сітьові бази даних
- •3.2.3.1. Керуюча частина мережевої моделі
- •3.2.3.1. Приклади мережевих скбд
- •3.3. Субд реляційного типу.
- •3.3.1. Реляційна база даних
- •3.3.2. Відношення
- •3.3.3. Нормалізація
- •3.4. Об’єктно-орієнтовані бд.
- •3.4.2. Об'єктно-орієнтовані бд
- •3.4.2. Об'єктно-реляційні бд
- •3.4.3. Переваги моделі ообд
- •1. Визначення призначених для користувача абстракцій
- •2. Полегшене проектування деяких зв'язків
- •3. Відсутність потреби у визначенні ключів
- •4. Наявність предикатів порівняння
- •5. Менша потреба в з'єднаннях
- •6. Виграш в продуктивності -?
- •7. Підтримка версій і тривалих транзакцій
- •8. Об'єктна алгебра
- •3.4.4. Недоліки моделі ообд
- •1. Відсутність інтероперабельності між рбд і ообд
- •2. Недостатність засобів для оптимізації запитів
- •3. Відсутність засобів забезпечення запитів
- •4. Відсутність підтримки подань
- •3.4.6. Стандарт odmg.
- •3.4.7. Об'єктні розширення реляційних субд. Мова Sql-3.
- •3.4.8. Об'єктно-реляційні субд
3.1.1.5. Обробка транзакцій
Запити та інші команди мови управління даними групуються в транзакції (transactions) – процеси, які мають виконуватись атомарним чином (atomically) та ізольовано (in isolation) одна від одної. Зазвичай кожний окремий запит або операція зміни даних є самостійною транзакцією. Транзакція повинна мати властивість стійкості (durability). Це означає, що результат кожної завершеної транзакції має бути зафіксований навіть у таких ситуаціях, коли після завершення транзакції система з певних причин виходить з ладу. На рис.3.2 процесор транзакцій (transaction processor) має 2 основні компоненти:
Планувальник завдань (sheduler) або менеджер паралельних завдань (concurrency control manager), відповідальний за забезпечення атомарності та ізольованості транзакцій.
Менеджер протоколювання та відновлення (logging and recovery manager), який гарантує стійкість транзакцій.
Менеджер транзакцій (transaction manager) сприймає від доданку команди транзакцій (transaction commands), які свідчать про початок і завершення транзакції (зазвичай 3 команди – почати, завершити записом на диск, відкотити). Функції процесора транзакцій (transaction processor):
Протоколювання (logging). Для дотримання вимоги стійкості транзакцій кожна зміна фіксується у спеціальних дискових файлах. Менеджер протоколювання (logging manager) керується одною з кількох стратегій, покликаних виключити шкідливі наслідки системних збоїв під час виконання транзакції. Менеджер відновлення (recovery manager) у таких ситуаціях здатний зчитати протокол змін і привести базу в певний коректний стан. Інформація протоколу спочатку зберігається в буферах; затим менеджер протоколювання в певні моменти часу взаємодіє з менеджером буферів, контролюючи, чи дійсно зміст буферів збережено на диску (де дані надійно захищені в разі краху системи).
Управління паралельними завданнями (concurrency control). Транзакції повинні виконуватись в повній ізоляції одна від одної. Але насправді одночасно можуть діяти кілька процесів-транзакцій. Планувальник завдань (sheduler), або менеджер паралельних завдань (concurrency control manager), повинен забезпечити такий режим роботи системи, щоб результат окремих операцій численних транзакцій, які перетинаються в часі, виявився таким, мовби транзакції ініціювались, протікали та повністю завершувались у суворій послідовності, не „перетинаючись” одна з одною. Типовий планувальник завдань для цього встановлює блокування (lock) на відповідні фрагменти змісту БД. Блокування перешкоджають одночасному звертанню кількох транзакцій до порції даних способами, які погано узгоджені один з одним. Ознаки блокувань зазвичай зберігаються в таблиці блокувань (lock table) в ОП (рис.1.13). Планувальник завдань впливає на виконання запитів та інших операцій, забороняючи виконуючій машині звертатися до заблокованих порцій даних.
Розв’язання взаємоблокувань (deadlock resolution). Оскільки транзакції змагаються за ресурси, які можуть бути заблоковані планувальником завдань, можливе виникнення такого стану, коли жодна транзакція не може виконати роботу, оскільки їй необхідний ресурс, заблокований іншою транзакцією. Менеджер транзакцій має право втручатися і переривати (відкочувати – rollback) одну або кілька транзакцій, аби дозволити іншим продовжити роботу.
Рис.3.6. – Діаграма діяльності по виконанню транзакції