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

Як було показано в першій лекції, традиційних можливостей файлових систем виявляється недостатньо для побудови навіть простих інформаційних систем. Ми виявили декілька потреб, які не покриваються можливостями систем управління файлами: підтримка логічно узгодженого набору файлів; забезпечення мови маніпулювання даними; відновлення інформації після різного роду збоїв; реально паралельна робота декількох користувачів. Можна вважати, що якщо прикладна інформаційна система спирається на деяку систему управління даними, що володіє цими властивостями, то ця система управління даними є системою управління базами даних (СУБД).
2.1. Основні функції СУБД
Більш точно, до числа функцій СУБД прийнято відносити наступні:
2.1.1. Безпосереднє управління даними у зовнішній пам'яті
Ця функція включає забезпечення необхідних структур зовнішньої пам'яті як для зберігання даних, що безпосередньо входять в БД, так і для службових цілей, наприклад, для прискорення доступу до даних в деяких випадках (звичайно для цього використовуються індекси). У деяких реалізаціях СУБД активно використовуються можливості існуючих файлових систем, в інших робота проводиться аж до рівня пристроїв зовнішньої пам'яті. Але підкреслимо, що в розвиненій СУБД користувачі в будь-якому випадку не зобов'язані знати, чи використовує СУБД файлову систему, і якщо використовує, то як організовані файли. Зокрема, СУБД підтримує власну систему іменування об'єктів БД.
2.1.2. Управління буферами оперативної пам'яті
СУБД звичайно працює з БД значного розміру; принаймні цей розмір звичайно істотно більше доступного об'єму оперативної пам'яті. Зрозуміло, що якщо при зверненні до будь-якого елемента даних буде проводитися обмін із зовнішньою пам'яттю, то вся система буде працювати з швидкістю пристрою зовнішньої пам'яті. Практично єдиним способом реального збільшення цієї швидкості є буферизація даних в оперативній пам'яті. При цьому, навіть якщо операційна система проводить загальносистемну буферизацію (як у разі ОС UNIX), цього недостатньо для цілей СУБД, яка має в своєму розпорядженні набагато більшу інформацію про корисність буферизації тієї або іншої частини БД. Тому в розвиненій СУБД підтримується власний набір буферів оперативної пам'яті з власною дисципліною заміни буферів.
Помітимо, що існує окремий напрям СУБД, який орієнтований на постійну присутність в оперативній пам'яті всієї БД. Цей напрям засновується на припущенні, що в майбутньому об'єм оперативної пам'яті комп'ютерів буде настільки великий, що дозволить не турбуватися про буферизацію. Поки ці роботи перебувають в стадії досліджень.
2.1.3. Управління транзакціями
Транзакція - це послідовність операцій над БД, що розглядається СУБД як єдине ціле. Або транзакція успішно виконується, і СУБД фіксує (COMMIT) зміни БД, зроблені цією транзакцією, у зовнішній пам'яті, або жодна з цих змін ніяк не відбивається на стані БД. Поняття транзакції необхідне для підтримки логічної цілісності БД. Якщо пригадати наш приклад інформаційної системи з файлами СПІВРОБІТНИКИ і ВІДДІЛИ, то єдиним способом не порушити цілісність БД при виконанні операції прийому на роботу нового співробітника є об'єднання елементарних операцій над файлами СПІВРОБІТНИКИ і ВІДДІЛИ в одну транзакцію. Таким чином, підтримка механізму транзакцій є обов'язковою умовою навіть однокористувацьких СУБД (якщо, звичайно, така система заслуговує назви СУБД). Але поняття транзакції набагато більш важливе в багатокористувацькій СУБД.
Та властивість, що кожна транзакція починається при цілісному стані БД і залишає цей стан цілісним після свого завершення, робить дуже зручним використання поняття транзакції як одиниці активності користувача по відношенню до БД. При відповідному управлінні транзакціями, що паралельно виконуються з боку СУБД кожний з користувачів може в принципі відчувати себе єдиним користувачем СУБД (насправді, це декілька ідеалізоване уявлення, оскільки в деяких випадках користувачі багатокористувацької СУБД можуть відчути присутність своїх колег).
З управлінням транзакціями в багатокористувацькій СУБД пов'язані важливі поняття серіалізації транзакцій і серіального плану виконання суміші транзакцій. Під серіалізацій транзакцій, що паралельно виконуються розуміється такий порядок планування їх роботи, при якому сумарний ефект суміші транзакцій еквівалентний ефекту їх деякого послідовного виконання. Серіальний план виконання суміші транзакцій - це такий план, який приводить до серіалізації транзакцій. Зрозуміло, що якщо вдається добитися дійсно серіального виконання суміші транзакцій, то для кожного користувача, з ініціативи якого утворена транзакція, присутність інших транзакцій буде непомітна (якщо не вважати деякого сповільнення роботи в порівнянні з однокористувацьким режимом).
Існує декілька базових алгоритмів серіалізації транзакцій. У централізованій СУБД найбільш поширені алгоритми, засновані на синхронізаційних захопленнях об'єктів БД. При використанні будь-якого алгоритму серіалізації можливі ситуації конфліктів між двома або більш транзакціями по доступу до об'єктів БД. У цьому випадку для підтримки серіалізації необхідно виконати відкат (ліквідувати всі зміни, зроблені в БД) однієї або більше за транзакції. Це один з випадків, коли користувач багатокористувацької СУБД може реально (і досить неприємно) відчути присутність в системі транзакцій інших користувачів.
2.1.4. Журналізація
Однією з основних вимог до СУБД є надійність зберігання даних у зовнішній пам'яті. Під надійністю зберігання розуміється те, що СУБД повинна спромогтися відновити останній узгоджений стан БД після будь-якого апаратного або програмного збою. Звичайно розглядаються два можливих вигляду апаратних збоїв: так звані м'які збої, які можна трактувати як раптову зупинку роботи комп'ютера (наприклад, аварійне вимкнення живлення), і жорсткі збої, що характеризуються втратою інформації на носіях зовнішньої пам'яті. Прикладами програмних збоїв можуть бути: аварійне завершення роботи СУБД (внаслідок помилки в програмі або внаслідок деякого апаратного збою) або аварійне завершення призначеної для користувача програми, внаслідок чого деяка транзакція залишається незавершеною. Першу ситуацію можна розглядати як особливий вигляд м'якого апаратного збою; при виникненні останньою потрібно ліквідувати наслідки тільки однієї транзакції.
Зрозуміло, що в будь-якому випадку для відновлення БД треба мати в своєму розпорядженні деяку додаткову інформацію. Іншими словами, підтримка надійності зберігання даних в БД вимагає надмірності зберігання даних, причому та частина даних, яка використовується для відновлення, повинна зберігатися особливо надійно. Найбільш поширеним методом підтримки такої надмірної інформації є ведення журналу змін БД.
Журнал - це особлива частина БД, недоступна користувачам СУБД і що підтримується з особливою ретельністю (іноді підтримуються дві копії журналу, що розташовуються на різних фізичних дисках), в яку поступають записи про всі зміни основної частини БД. У різній СУБД зміни БД журналізуються на різних рівнях: іноді запис в журналі відповідає деякій логічній операції зміни БД (наприклад, операції видалення рядка з таблиці реляційної БД), іноді - мінімальної внутрішньої операції модифікації сторінки зовнішньої пам'яті; в деяких системах одночасно використовуються обидва підходи.
У всіх випадках дотримуються стратегії "попереджуючого" запису в журнал (так званого протоколу Write Ahead Log - WAL). Грубо кажучи, ця стратегія полягає в тому, що запис про зміну будь-якого об'єкта БД повинен попасти у зовнішню пам'ять журналу раніше, ніж змінений об'єкт попаде у зовнішню пам'ять основної частини БД. Відомо, що якщо в СУБД коректно дотримується протокол WAL, то за допомогою журналу можна вирішити всі проблеми відновлення БД після будь-якого збою.
Сама проста ситуація відновлення - індивідуальний відкат транзакції. Суворо кажучи, для цього не потрібний загальносистемний журнал змін БД. Досить для кожної транзакції підтримувати локальний журнал операцій модифікації БД, виконаних в цій транзакції, і проводити відкат транзакції шляхом виконання зворотних операцій, слідуючи від кінця локального журналу. У деякій СУБД так і роблять, але в більшості систем локальні журнали не підтримують, а індивідуальний відкат транзакції виконують за загальносистемним журналом, для чого всі записи від однієї транзакції зв'язують зворотним списком (від кінця до початку).
При м'якому збої у зовнішній пам'яті основної частини БД можуть знаходитися об'єкти, модифіковані транзакціями, що не закінчилися до моменту збою, і можуть бути відсутнім об'єкти, модифіковані транзакціями, які до моменту збою успішно завершилися (внаслідок використання буферів оперативної пам'яті, вміст яких при м'якому збої пропадає). При дотриманні протоколу WAL у зовнішній пам'яті журналу повинні гарантовано знаходитися запису, що відносяться до операцій модифікації обох видів об'єктів. Метою процесу відновлення після м'якого збою є стан зовнішньої пам'яті основної частини БД, який виник би при фіксації у зовнішній пам'яті змін всіх транзакцій, що завершилися і яке не містило б ніяких слідів незавершених транзакцій. Для того, щоб цього добитися, спочатку проводять відкат незавершених транзакцій (undo), а потім повторно відтворюють (redo) ті операції завершених транзакцій, результати яких не відображені у зовнішній пам'яті. Цей процес містить багато тонкості, пов'язаної із загальною організацією управління буферами і журналом. Більш детально ми розглянемо це у відповідній лекції.
Для відновлення БД після жорсткого збою використовують журнал і архівну копію БД. Грубо кажучи, архівна копія - це повна копія БД до моменту початку заповнення журналу (є багато варіантів більш гнучкого трактування значення архівної копії). Звичайно, для нормального відновлення БД після жорсткого збою необхідно, щоб журнал не пропав. Як вже відмічалося, до збереження журналу у зовнішній пам'яті в СУБД пред'являються особливо підвищені вимоги. Тоді відновлення БД полягає в тому, що виходячи з архівної копії по журналу відтворюється робота всіх транзакцій, які закінчилися до моменту збою. У принципі, можна навіть відтворити роботу незавершених транзакцій і продовжити їх роботу після завершення відновлення. Однак в реальних системах це звичайно не робиться, оскільки процес відновлення після жорсткого збою є досить тривалим.
2.1.5. Підтримка мов БД
Для роботи з базами даних використовуються спеціальні мови, загалом звані мовами баз даних. У ранній СУБД підтримувалося декілька спеціалізованих по своїх функціях мов. Частіше за все виділялися дві мови - мова визначення схеми БД (SDL - Schema Definition Language) і мова маніпулювання даними (DML - Data Manipulation Language). SDL служив головним чином для визначення логічної структури БД, тобто тієї структури БД, якої вона представляється користувачам. DML містив набір операторів маніпулювання даними, тобто операторів, що дозволяють занести дані в БД, видаляти, модифікувати або вибирати існуючі дані. Ми розглянемо більш детально мови ранньої СУБД в наступній лекції.
У сучасній СУБД звичайно підтримується єдина інтегрована мова, що містить всі необхідні засоби для роботи з БД, починаючи від її створення, і для забезпечення базового інтерфейсу користувача з базами даних. Стандартною мовою найбільш поширеної в цей час реляційних СУБД є мова SQL (Structured Query Language). У декількох лекціях цього курсу мова SQL буде розглядатися досить детально, а поки ми перерахуємо основні функції реляційної СУБД, що підтримуються на "мовному" рівні (тобто функції, що підтримуються при реалізації інтерфейсу SQL).
Передусім, мова SQL поєднує засоби SDL і DML, тобто дозволяє визначати схему реляційної БД і маніпулювати даними. При цьому іменування об'єктів БД (для реляційної БД - іменування таблиць і їх стовпців) підтримується на язиковому рівні в тому значенні, що компілятор мови SQL проводить перетворення імен об'єктів в їх внутрішні ідентифікатори на основі службових таблиць-каталогів, що спеціально підтримуються. Внутрішня частина СУБД (ядро) взагалі не працює з іменами таблиць і їх стовпців.
Мова SQL містить спеціальні засоби визначення обмежень цілісності БД. Знову ж, обмеження цілісності зберігаються в спеціальних таблицях-каталогах, і забезпечення контролю цілісності БД проводиться на язиковому рівні, тобто при компіляції операторів модифікації БД компілятор SQL на основі обмежень цілісності, що є в БД генерує відповідний програмний код.
Спеціальні оператори мови SQL дозволяють визначати так звані представлення БД, що фактично є запитами (результатом будь-якого запиту до реляційної БД є таблиця), що зберігаються в БД з іменованими стовпцями. Для користувача представлення є такою ж таблицею, як будь-яка базова таблиця, що зберігається в БД, але за допомогою представлень можна обмежити або навпаки розширити видимість БД для конкретного користувача. Підтримка представлень проводиться також на мовному рівні.
Нарешті, авторизація доступу до об'єктів БД проводиться також на основі спеціального набору операторів SQL. Ідея полягає в тому, що для виконання операторів SQL різного вигляду користувач повинен володіти різними повноваженнями. Користувач, що створив таблицю БД, володіє повним набором повноважень для роботи з цією таблицею. У число цих повноважень входить повноваження на передачу всіх або частини повноважень іншим користувачам, включаючи повноваження на передачу повноважень. Повноваження користувачів описуються в спеціальних таблицях-каталогах, контроль повноважень підтримується на мовному рівні.
Більш точний опис можливих реалізацій цих функцій на основі мови SQL буде приведений в лекціях, присвячених мові SQL і його реалізації.
2.2. Типова організація сучасної СУБД
Природно, організація типової СУБД і склад її компонентів відповідає розглянутому нами набору функцій. Нагадаємо, що ми виділили наступні основні функції СУБД:
управління даними у зовнішній пам'яті;
управління буферами оперативної пам'яті;
управління транзакціями;
журналізація і відновлення БД після збоїв;
підтримка мов БД.
Логічно в сучасній реляційної СУБД можна виділити найбільш внутрішню частину - ядро СУБД (часто його називають Data Base Engine), компілятор мови БД (звичайне SQL), підсистему підтримки часу виконання, набір утиліт. У деяких системах ці частини виділяються явно, в інших - немає, але логічно таке розділення можна провести у всій СУБД.
Ядро СУБД відповідає за управління даними у зовнішній пам'яті, управління буферами оперативної пам'яті, управління транзакціями і журналізацію. Відповідно, можна виділити такі компоненти ядра (принаймні, логічно, хоч в деяких системах ці компоненти виділяються явно), як менеджер даних, менеджер буферів, менеджер транзакцій і менеджер журналу. Як можна було зрозуміти з першої частини цієї лекції, функції цих компонентів взаємопов'язані, і для забезпечення коректної роботи СУБД всі ці компоненти повинні взаємодіяти по ретельно продуманим і перевіреним протоколам. Ядро СУБД володіє власним інтерфейсом, не доступним користувачам напряму і що використовується в програмах, що проводяться компілятором SQL (або в підсистемі підтримки виконання таких програм) і утилітах БД. Ядро СУБД є основною резидентною частиною СУБД. При використанні архітектури "клієнт-сервер" ядро є основною складовою серверної частини системи.
Основною функцією компілятора мови БД є компіляція операторів мови БД в деяку програму, що виконується. Основною проблемою реляційних СУБД є те, що мови цих систем (а це, як правило, SQL) є не процедурними, тобто в операторі такої мови специфікується деяка дія над БД, але ця специфікація не є процедурою, а лише описує в деякій формі умови здійснення бажаної дії (пригадайте приклади з першої лекції). Тому компілятор повинен вирішити, яким чином виконувати оператор мови раніше, ніж зробити програму. Застосовуються досить складні методи оптимізації операторів, які ми детально розглянемо в наступних лекціях. Результатом компіляції є програма, що виконується, що представляється в деяких системах в машинних кодах, але більш часто у внутрішньому машинно-незалежному коді, що виконується. У останньому випадку реальне виконання оператора проводиться із залученням підсистеми підтримки часу виконання, що являє собою, по суті справи, інтерпретатор цієї внутрішньої мови.
Нарешті, в окремі утиліти БД звичайно виділяють такі процедури, які дуже накладно виконувати з використанням мови БД, наприклад, завантаження і вивантаження БД, збір статистики, глобальна перевірка цілісності БД і т.д. Утиліти програмуються з використанням інтерфейсу ядра СУБД, а іноді навіть з проникненням всередину ядра.
2.3. Приклад: System R
Основними цілями розробників System R були наступні:
забезпечити ненавігаційний інтерфейс високого рівня користувача з системою, що дозволяє досягнути незалежності даних і дати можливість користувачам працювати максимально ефективно;
забезпечити різноманіття допустимих способів використання СУБД, включаючи транзакції, що програмуються, діалогові транзакції і генерацію звітів;
підтримувати динамічно змінну середовище баз даних, в якій відносини, індекси, представлення, транзакції і інші об'єкти можуть легко додаватися і знищуватися без припинення нормального функціонування системи;
забезпечити можливість паралельної роботи з однією базою даних багатьох користувачів з допущенням паралельної модифікації об'єктів бази даних при наявності необхідних коштів захисту цілісності бази даних;
забезпечити засоби відновлення узгодженого стану баз даних після різного роду збоїв апаратури або програмного забезпечення;
забезпечити гнучкий механізм, що дозволяє визначати різні представлення даних, що зберігаються, і обмежувати цими уявленнями доступ користувачів до бази даних по вибірці і модифікації на основі механізму авторизації;
забезпечити продуктивність системи при виконанні згаданих функцій, порівнянну з продуктивністю існуючої СУБД низького рівня.
Структурна організація System R цілком узгодиться з поставленими при її розробці цілями. Основними структурними компонентами System R є система управління реляційної пам'яттю (Relational Storage System - RSS) і компілятор запитів мови SQL. RSS забезпечує інтерфейс досить низького, але достатнього для реалізації SQL рівня для доступу до даних, що зберігаються в базі. Синхронізація транзакцій, журналізація змін і відновлення баз даних після збоїв також відносяться до числа функцій RSS. Компілятор запитів використовує інтерфейс RSS для доступу до різноманітної довідкової інформації (каталогам відносин, індексів, прав доступу, умов цілісності, умовних впливів і т.д.) і виробляє робочі програми, що виконуються надалі також з використанням інтерфейсу RSS. Таким чином, система природно розділяється на два рівні - рівень управління пам'яттю і синхронізацією, фактично, що не залежить від базової мови запитів системи, і язикової рівень (рівень SQL), на якому вирішується більшість проблем System R. Помітимо, що ця незалежність швидше умовна, чим абсолютна: мову SQL можна замінити на іншу мову, але він повинен володіти приблизно такою ж семантикою.

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

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

Скачать