Функції СУБД. Типова організація СУБД. Приклади

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

2.1. Основні функції СУБД

Більш точно, до числа функцій СУБД прийнято відносити наступні:

2.1.1. Безпосереднє управління даними у зовнішній пам'яті

Ця функція включає забезпечення необхідних структур зовнішньої пам'яті як для зберігання даних, що безпосередньо входять в БД, так і для службових цілей, наприклад, для прискорення доступу до даних в деяких випадках (звичайно для цього використовуються індекси). У деяких реалізаціях СУБД активно використовуються можливості існуючих файлових систем, в інших робота проводиться аж до рівня пристроїв зовнішньої пам'яті. Але підкреслимо, що в розвиненій СУБД користувачі в будь-якому випадку не зобов'язані знати, чи використовує СУБД файлову систему, і якщо використовує, то як організовані файли. Зокрема, СУБД підтримує власну систему іменування об'єктів БД.

2.1.2. Управління буферами оперативної пам'яті

СУБД звичайно працює з БД значного розміру; принаймні цей розмір звичайно істотно більше доступного об'єму оперативної пам'яті. Зрозуміло, що якщо при зверненні до будь-якого елемента даних буде проводитися обмін із зовнішньою пам'яттю, то вся система буде працювати з швидкістю пристрою зовнішньої пам'яті. Практично єдиним способом реального збільшення цієї швидкості є буферизація даних в оперативній пам'яті. При цьому, навіть якщо операційна система проводить загальносистемну буферизацію (як у разі ОС UNIX), цього недостатньо для цілей СУБД, яка має в своєму розпорядженні набагато більшу інформацію про корисність буферизації тієї або іншої частини БД. Тому в розвиненій СУБД підтримується власний набір буферів оперативної пам'яті з власною дисципліною заміни буферів.

Помітимо, що існує окремий напрям СУБД, який орієнтований на постійну присутність в оперативній пам'яті всієї БД. Цей напрям засновується на припущенні, що в майбутньому об'єм оперативної пам'яті комп'ютерів буде настільки великий, що дозволить не турбуватися про буферизацію. Поки ці роботи перебувають в стадії досліджень.

2.1.3. Управління транзакціями

Транзакція - це послідовність операцій над БД, що розглядається СУБД як єдине ціле. Або транзакція успішно виконується, і СУБД фіксує (COMMIT) зміни БД, зроблені цією транзакцією, у зовнішній пам'яті, або жодна з цих змін ніяк не відбивається на стані БД. Поняття транзакції необхідне для підтримки логічної цілісності БД. Якщо пригадати наш приклад інформаційної системи з файлами СПІВРОБІТНИКИ і ВІДДІЛИ, то єдиним способом не порушити цілісність БД при виконанні операції прийому на роботу нового співробітника є об'єднання елементарних операцій над файлами СПІВРОБІТНИКИ і ВІДДІЛИ в одну транзакцію. Таким чином, підтримка механізму транзакцій є обов'язковою умовою навіть однокористувацьких СУБД (якщо, звичайно, така система заслуговує назви СУБД). Але поняття транзакції набагато більш важливе в багатокористувацькій СУБД.

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

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

Існує декілька базових алгоритмів серіалізації транзакцій. У централізованій СУБД найбільш поширені алгоритми, засновані на синхронізаційних захопленнях об'єктів БД. При використанні будь-якого алгоритму серіалізації можливі ситуації конфліктів між двома або більш транзакціями по доступу до об'єктів БД. У цьому випадку для підтримки серіалізації необхідно виконати відкат (ліквідувати всі зміни, зроблені в БД) однієї або більше за транзакції. Це один з випадків, коли користувач багатокористувацької СУБД може реально (і досить неприємно) відчути присутність в системі транзакцій інших користувачів.

2.1.4. Журналізація

Однією з основних вимог до СУБД є надійність зберігання даних у зовнішній пам'яті. Під надійністю зберігання розуміється те, що СУБД повинна спромогтися відновити останній узгоджений стан БД після будь-якого апаратного або програмного збою. Звичайно розглядаються два можливих вигляду апаратних збоїв: так звані м'які збої, які можна трактувати як раптову зупинку роботи комп'ютера (наприклад, аварійне вимкнення живлення), і жорсткі збої, що характеризуються втратою інформації на носіях зовнішньої пам'яті. Прикладами програмних збоїв можуть бути: аварійне завершення роботи СУБД (внаслідок помилки в програмі або внаслідок деякого апаратного збою) або аварійне завершення призначеної для користувача програми, внаслідок чого деяка транзакція залишається незавершеною. Першу ситуацію можна розглядати як особливий вигляд м'якого апаратного збою; при виникненні останньою потрібно ліквідувати наслідки тільки однієї транзакції.

Зрозуміло,