Класифікація та архітектура СКБД

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

Цілі лекції

Після опрацювання матеріалу ви зможете:

• класифікувати СКБД за кількістю користувачів, призначенням, навантаженням, розміщенням і моделлю даних;
• порівнювати локальну, файл-серверну, клієнт-серверну та розподілену архітектури;
• пояснювати три рівні ANSI/SPARC (ANSI — англ. American National Standards Institute, Американський національний інститут стандартів; SPARC — англ. Standards Planning and Requirements Committee, комітет планування стандартів і вимог);
• розрізняти логічну й фізичну незалежність даних;
• впізнавати основні моделі даних і добирати їх до простих сценаріїв.

Передумови

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

1. Класифікація: спочатку критерій

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

Операційне й аналітичне навантаження

Операційна система виконує багато коротких повсякденних дій: зареєструвати оплату, змінити статус посилки, виставити оцінку. Аналітична система опрацьовує великі набори даних для звітів і пошуку закономірностей. Змішана система має обидва види роботи.

Клас не є оцінкою якості. Аналітична СКБД не «краща» за операційну: вона оптимізована для іншого навантаження. Так само відкрита ліцензія не гарантує простого супроводу, а власницька ліцензія не гарантує кращої продуктивності.

2. Архітектури роботи з базою даних

Архітектура показує, де розміщені дані, де працює СКБД, де виконується запит і як взаємодіють компоненти.

2.1. Локальна архітектура

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

[Застосунок + СКБД + дані]
          один комп'ютер

Приклад: студентський застосунок використовує SQLite і зберігає навчальні нотатки на ноутбуці.

Переваги: просте розгортання, автономність, відсутність мережевої затримки. Обмеження: складно організувати спільну роботу, централізований контроль і доступ із різних пристроїв.

2.2. Файл-серверна архітектура

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

[Клієнт 1: опрацювання] ---\
                              [Файловий сервер: файли БД]
[Клієнт 2: опрацювання] ---/

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

2.3. Клієнт-серверна архітектура

Сервер СКБД централізовано зберігає дані, виконує запити, перевіряє права й правила та повертає клієнту результат. Клієнтом може бути настільна програма, вебсервер, мобільний застосунок або адміністративний інструмент.

[Клієнт] -- запит --> [Сервер СКБД] --> [Дані]
[Клієнт] <-- результат -- [Сервер СКБД]

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

Переваги: централізоване керування, менший зайвий мережевий обмін, надійніший багатокористувацький доступ, єдині правила захисту й резервування. Обмеження: сервер потребує адміністрування; його відмова без належного резервування може зробити систему недоступною.

У трирівневому вебзастосунку браузер зазвичай не звертається до СКБД напряму:

[Браузер] <--> [Сервер застосунку] <--> [Сервер СКБД]

Сервер застосунку реалізує правила предметної області, а сервер СКБД керує операціями з даними.

2.4. Розподілена архітектура

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

[Вузол Київ] <--> [Вузол Львів] <--> [Вузол Дніпро]
       \________ узгодження даних ________/

Дані можна реплікувати, тобто підтримувати копії на кількох вузлах, або фрагментувати, тобто розподіляти різні частини між вузлами. Наприклад, мережа магазинів може зберігати локальні продажі у філіях і передавати їх до центральної системи.

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

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

Порівняння архітектур

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

3. Три рівні ANSI/SPARC

Архітектура ANSI/SPARC описує не комп'ютери, а рівні подання даних. Вона відокремлює те, що бачать користувачі, від загальної логічної структури й фізичного зберігання.

Зовнішній рівень

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

Концептуальний рівень

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

Внутрішній рівень

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

Зовнішній рівень:     [подання студента] [подання викладача]
                                  |
Концептуальний рівень:     [єдина логічна схема]
                                  |
Внутрішній рівень:       [файли, сторінки, індекси]

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

Відображення між рівнями дають змогу змінювати зберігання або логічну схему без переписування всіх представлень.

4. Незалежність даних

Розділення рівнів дає змогу змінювати одну частину системи з меншим впливом на інші.

Фізична незалежність даних - можливість змінювати внутрішню організацію без зміни концептуальної схеми й програм. Адміністратор створив індекс або переніс файли на інший диск, але запит «показати оцінки студента» залишився тим самим.

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

Логічну незалежність зазвичай забезпечити складніше: зміна змісту та структури даних частіше впливає на програми, ніж заміна фізичного способу доступу.

5. Огляд моделей даних

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

Ієрархічна модель

Дані організовано як дерево «батько - нащадки». Кожен дочірній запис має одного батьківського. Наприклад: коледж → відділення → група → студент. Модель природна для суворих ієрархій, але незручна, якщо об'єкт повинен належати до кількох гілок.

Мережева модель

Записи утворюють мережу зв'язків і можуть мати кількох «батьків». Це гнучкіше за дерево: студент може бути пов'язаний із групою, гуртками та проєктами. Проте навігація зв'язками та супровід структури можуть бути складними.

Реляційна модель

Дані подано у відношеннях, які на практиці сприймають як таблиці з рядками та стовпцями. Зв'язки виражають через спільні значення ключів. Модель має чітку математичну основу й широко використовує SQL (англ. Structured Query Language — мова структурованих запитів). Детально її розглядатимемо в наступних лекціях.

Об'єктно-орієнтована модель

Дані зберігаються як об'єкти з ідентичністю, станом, типами, успадкуванням і, залежно від системи, поведінкою. Модель зручна для складних об'єктних структур, але менш поширена як універсальна основа бізнес-систем.

Об'єктно-реляційна модель

Реляційну основу доповнено об'єктними можливостями: складними користувацькими типами, масивами, успадкуванням або іншими розширеннями. PostgreSQL часто характеризують як об'єктно-реляційну СКБД. Це не те саме, що ORM: ORM є програмним засобом відображення об'єктів застосунку на структури бази.

Документна модель

Один об'єкт подано як документ із полями та вкладеними структурами, часто у формі, подібній до JSON (англ. JavaScript Object Notation — формат обміну даними). Картка товару може містити назву, характеристики й масив фотографій в одному документі.

{
  "course": "Бази даних",
  "student": "Олена",
  "grades": [10, 8, 11]
}

Документна модель зручна для об'єктів зі змінним набором властивостей і читання цілісного документа. Вона не скасовує потреби продумувати структуру, цілісність і зв'язки.

Модель ключ-значення

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

Ключ: session:8f31
Значення: { userId: 42, expiresAt: "2026-08-26T14:00:00Z" }

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

Стисле порівняння

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

Одна предметна область може мати різне подання: вибір моделі залежить від структури зв’язків і типових операцій.

Практичні завдання

Завдання 1. Визначте архітектуру

Для кожного випадку назвіть архітектуру й одну ознаку, що підтверджує вибір:

1. Застосунок нотаток зберігає SQLite-файл на ноутбуці й працює без мережі.
2. Робочі станції відкривають спільний файл бази з мережевого диска й опрацьовують записи локально.
3. Вебсервер надсилає запити PostgreSQL, а PostgreSQL повертає лише результати.
4. Дані сервісу розміщено на кількох узгоджених вузлах у різних регіонах.

Завдання 2. Розкладіть зміни за рівнями

Для системи електронного журналу визначте рівень ANSI/SPARC і вид незалежності, якщо він проявляється:

1. Для студента створили подання лише його оцінок.
2. До логічної схеми додали відомості про консультації.
3. Адміністратор створив індекс, не змінюючи запитів застосунку.
4. Адресу розділили на поля, але старий звіт і далі отримує один рядок через подання.

Завдання 3. Спроєктуйте набір сховищ

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

1. Запропонуйте модель для кожного з трьох наборів даних.
2. Обґрунтуйте кожен вибір через структуру та операції, а не через назву продукту.
3. Запропонуйте архітектуру доступу для тисяч користувачів.
4. Назвіть один ризик використання кількох сховищ.

Підсумок

• Класифікація має сенс лише разом із критерієм; одна СКБД належить до кількох класів.
• Локальна, файл-серверна, клієнт-серверна та розподілена архітектури відрізняються розміщенням даних і місцем виконання запитів.
• ANSI/SPARC розділяє зовнішній, концептуальний і внутрішній рівні подання.
• Фізична незалежність приховує зміни зберігання, а логічна - зміни концептуальної схеми.
• Модель даних описує логічну форму організації даних, а не фізичне розташування серверів.
• Ієрархічна, мережева, реляційна, об'єктно-орієнтована, об'єктно-реляційна, документна та ключ-значення моделі мають різні сильні сценарії.
• Вибір СКБД і моделі починається з вимог до даних та операцій, а не з популярності технології.