Главная Случайная страница


Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






Поняття баз даних та її структурних елементів

Завжди, коли виникає потреба маніпулювати великими масивами даних, використовуються бази даних.

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

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

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

Нині існує досить велика кількість програмних систем, що дозволяють створювати і використовувати локальні {dBASE, FoxPro, Access, Paradox) і мережеві (Interbase, Oracle, Sysbase, Infomix, Microsoft SQL Server) бази даних.

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

СУБД можна визначити як деяку систему управління даними, що має наступні властивості:

· підтримка логічно узгодженого набору файлів;

· забезпечення мови маніпулювання даними;

· відновлення інформації після різного роду збоїв;

· забезпечення паралельної роботи декількох користувачів.

До основних функцій, що виконуються системами управління базами даних, зазвичай відносять наступні:

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

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

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

4. протоколювання;

5. підтримка мов баз даних.

Розглянемо кожну з вказаних функцій детальніше.

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

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

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

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

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

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

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

 

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

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

- м'які збої пов'язані з раптовою зупинкою роботи комп'ютера. Зазвичай є наслідком раптового виключення живлення або "зависання" операційної системи (що особливо характерно для операційних систем Windows);

- жорсткі збої характеризуються втратою інформації на носіях зовнішньої пам'яті.

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

У будь-якому випадку для відновлення інформації в базі даних необхідно мати деяку додаткову інформацію. Таким чином, для підтримки надійності зберігання даних вимагається надмірність даних. Причому та частина інформації, яка використовується для відновлення, повинна зберігатися особливо надійно. Найбільш поширеним методом підтримки такої надлишкової інформації є ведення журналу змін бази даних. Журнал є особливою частиною бази даних, недоступною користувачам СУБД і підтримувану з особливою ретельністю (іноді використовуються дві копії журналу, що розташовуються на різних фізичних дисках), в яку поступають записи про усі зміни основної частини бази даних. У різних СУБД зміни бази даних журналізуються на різних рівнях: іноді запис в журналі відповідає деякій логічній операції зміни бази даних, іноді – мінімальній внутрішній операції модифікації сторінки зовнішньої пам'яті. Можуть також використовуватися одночасно обидва підходи. У усіх випадках дотримуються стратегії "попереджуючого" запису в журнал (так званого протоколу Write Ahead Log – WAL). Образно можна сказати, що ця стратегія полягає в тому, що запис про зміну будь-якого об'єкту бази даних має бути занесений в журнал до того, як буде виконана і зафіксована зміна цього об'єкту. Якщо в СУБД коректно реалізується протокол WAL, то за допомогою журналу можна вирішити усі проблеми відновлення бази даних після будь-якого збою.

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

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

 

Підтримка мов баз даних

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

- мова визначення схем даних (Schema Definition Language, SDL) служить головним чином для визначення логічної структури бази даних;

- мова маніпулювання даними (Data Manipulation Language, DML) містить набір операторів маніпулювання даними, тобто операторів, що дозволяють заносити дані в базу, а також видаляти, модифікувати або вибирати існуючі дані.

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

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

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

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

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


Последнее изменение этой страницы: 2016-06-09

lectmania.ru. Все права принадлежат авторам данных материалов. В случае нарушения авторского права напишите нам сюда...