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

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

Управління даними

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

Управління буферами ОПЕРАТИВНОЇ пам'яті

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


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

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

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

Що вони означають?

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

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

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

м'які, які можуть трактуватися як несподівана зупинка роботи комп'ютера (самий поширений випадок – аварійне відключення живлення);

жорсткі, які характеризуються частковою або повною втратою даних, що зберігаються на зовнішніх носіях.

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

Що це і як використовується?

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

Відкат

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

Жорсткі збої

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

Підтримка мов

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

Що він собою являє?

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