СИСТЕМА УПРАВЛІННЯ БАЗОЮ ДАНИХ

Система управління базою даних (СКБД) являє собою програмне забезпечення, яке керує всім доступом до бази даних Концептуально це відбувається таким чином (див рис 23)

1 Користувач видає запит на доступ до даних, застосовуючи певний підйом зик даних (зазвичай це мова SQL)

2 СУБД перехоплює цей запит і аналізує його

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

4 СУБД виконує необхідні операції в збереженої базі даних

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

Звичайно, опис попереднього прикладу вельми спрощено зокрема, в даному випадку передбачається, що весь процес заснований на інтерпретації (Тобто аналіз запиту,

перевірка різних схем і інші процедури здійснюються безпосередньо під час

виконання) Однак інтерпретація зазвичай характеризується невисокою продуктивністю, оскільки на її виконання витрачається багато часу На практиці зазвичай існує можливість попередньо  відкомпілювати запит на доступ до даних до початку його виконання зокрема, в сучасних системах SQL застосовується саме такий підхід (див анотації до [4131 і [4271 в розділі 4)

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

Рис 24 Основні функції і компоненти типової СУБД

■&nbsp&nbsp&nbsp&nbsp Визначення даних

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

■&nbsp&nbsp&nbsp&nbsp Маніпулювання даними

СУБД повинна бути здатна обробляти запити користувача на вибірку, зміна або видалення даних, вже існуючих в базі, або на додавання в неї нових даних Іншими словами, СУБД повинна включати в себе компонент процесора ЯМД або компілятора ЯМД, забезпечує підтримку мови маніпулювання даними (ММД)

В цілому, запити ЯМД поділяються на плановані і неплановані

а) Планований запит – Це запит, необхідність виконання якого була передбачена заздалегідь Адміністратор бази даних, можливо, повинен буде розробити фізичний проект бази даних таким чином, щоб гарантиро вать достатню швидкодію виконання подібних запитів

б) Непланованої запит – Це, навпаки, деякий довільний запит на ви вибірку або (що менш ймовірно) на оновлення, необхідність виконання до торого не була передбачена заздалегідь і виникла з якоїсь особливої ​​причини Фізичний проект бази даних може забезпечувати успішне виконання кон кретного довільного запиту, або може виявитися не зовсім відповідним

Згідно термінології, введеної в розділі 1 (розділ 13), плановані запити більш характерні для операційних, або виробничих додатків, а неплановані – для додатків підтримки прийняття рішень Більш того, плановані запити зазвичай надходять із заздалегідь підготовлених додатків, а неплановані запити за визначенням вводяться інтерактивно, за допомогою процесора мови запитів (В розділі 1 вже зазначалося, що насправді процесор мови запитів – це вбудоване інтерактивне додаток, а не якась частина самої СУБД Ми показали цей компонент на рис 24 виключно заради створення повної картини)

■&nbsp&nbsp&nbsp&nbsp Оптимізація і виконання

Запити ЯМД, плановані або неплановані, повинні бути оброблені таким компонентом, як оптимізатор, призначення якого полягає в пошуку досить ефективного способу виконання кожного з запросов7 Оптимізація детально

7 У всій цій книзі термін оптимізація відноситься виключно до оптимізації запитів ЯМД, якщо явно не вказано інше

обговорюється в главі 18 Потім оптимізовані запити виконуються під управлінням диспетчера етапу прогону (Run-time manager) На практиці диспетчер етапу прогону для отримання доступу до збережених даних, можливо, буде використовувати щось подібне диспетчеру доступу до файлів (Останній компонент коротко обговорюється в кінці даного розділу)

■&nbsp&nbsp&nbsp&nbsp Захист та підтримка цілісності даних

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

■&nbsp&nbsp&nbsp&nbsp Відновлення даних і підтримка паралельності

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

■&nbsp&nbsp&nbsp&nbsp Словник даних

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

Слід зазначити, що тут ми торкнулися області, в якій може виникнути плутанина через недосконалість використовуваної термінології Те, що ми називаємо словником(Dictionary), іноді називаютьдовідником(Directory) абокаталогом (Catalog), тому що довідники та каталоги вважаються в певному сенсі менш важливими в порівнянні з справжніми словниками, а термін словник застосовують для позначення спеціального (більш важливого) виду інструментів розробки додатків Також зустрічаються й інші терміни – репозитарій даних (Глава 14) і енциклопедія даних

■&nbsp&nbsp&nbsp Продуктивність

Очевидно, що СУБД повинна виконувати всі зазначені функції з максимально можливою ефективністю

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

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

знищувати збережені файли, а також виконувати прості операції вибірки та оновлення збережених записів у створених ним файлах Проте, порівняно з СУБД, системі управління файлами властиві такі недоліки

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

■ Як правило, подібні системи надають слабку підтримку обмежень захисту і підтримки цілісності даних або ж взагалі її не надають

■ Зазвичай такі системи надають недостатню підтримку управління вос становленням даних і паралельним доступом до них або ж не надають її зовсім

■ На рівні диспетчера файлів не існує концепції справжнього словника даних

■ Взагалі кажучи, ці системи забезпечують незалежність від даних набагато гірше в порівнянні з СУБД

■ Як правило, окремі файли не є інтегрованими або розділяються в тому сенсі, який вкладається в ці поняття стосовно до баз даних (Зазвичай вони є власними файлами користувача або програми)

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*