Функції СУБД

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

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

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

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

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

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

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

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

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

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

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

У всіх випадках дотримуються стратегії «попереджуючої» запису в журнал (так званого протоколу Write Ahead Log – WAL). Ця стратегія полягає в тому, що запис про зміну будь-якого об'єкта БД повинна попасти у зовнішню пам'ять журналу раніше, ніж змінений об'єкт попаде у зовнішню пам'ять основної частини БД. Відомо, що якщо в СУБД коректно дотримується протокол WAL, то з допомогою журналу можна вирішити всі проблеми відновлення БД після будь-якого збою.

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