Спеціальні оператори мови 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. Таким чином, система природно розділяється на два