Основні функції субд

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

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

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

Управління буферами ОЗУ

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

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

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

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

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

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

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

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

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

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

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

• м`які, які можуть трактуватися як несподівана зупинка роботи комп`ютера (найпоширеніший випадок - аварійне відключення живлення);
• жорсткі, які характеризуються часткової або повної втрати записів на зовнішніх носіях.

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

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

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

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

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

відкат

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

Відео: Системи управління базами даних

При виникненні м`якого збою зовнішня пам`ять бази даних може включати в себе різні об`єкти, які були модифіковані транзакціями, що не закінченими до моменту виникнення збою, а також можуть бути відсутніми різні об`єкти, модернізовані тими, які успішно завершилися до несправності за рахунок використання буферів оперативної пам`яті, вміст яких повністю зникає при виникненні подібні проблем. Якщо буде дотримуватися протокол, який передбачає використання локальних журналів, у зовнішній пам`яті обов`язково залишаються записи, які відносяться до модифікації будь-яких таких об`єктів.

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

жорсткі збої

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

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

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

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

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

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

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

Відео: Вивчаємо мову запитів SQL. Курс по реляційних баз даних на прикладі бібліотеки SQLite. Уроки для початківців.

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