Поняття СКБД. Архітектура та проектування реляційних баз даних. Типи даних та зв'язки між таблицями.

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

Проблема плоских таблиць: В одній звичайній таблиці неможливо уникнути дублювання інформації. Якщо записати в один список автобуси та маршрути, відомості про один і той самий маршрут (наприклад, «Маршрут №9, 7,3 км») доведеться багаторазово копіювати для кожного окремого автобуса.

• Чому це небезпечно? Якщо протяжність маршруту зміниться, оператору доведеться вручну змінювати значення в десятках рядків. Варто пропустити хоча б один рядок — виникає суперечливість, і точні дані втрачено.

• База даних — це структура, що гарантує узгодженість і мінімізує надлишковість.

Вихід із цієї кризи запропонував британський математик Едгар Кодд у 1970 році.

• Принцип (Relation): Усі дані зберігаються у вигляді окремих логічних таблиць, які взаємодіють між собою через математичні відношення.

• Головна перевага реляційного підходу: Жодного дублювання. Замість однієї загальної таблиці створюються дві окремі — «Автобуси» та «Маршрути», пов'язані між собою.

• Тепер зміна характеристик маршруту в одній таблиці миттєво відображається для всіх автобусів, що за ним закріплені.

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

4 фундаментальні завдання СКБД:

1. 📐 Створення: Надання інструментів для проектування архітектури та структури таблиць.

2. 🗄️ Зберігання: Надійне розміщення гігантських обсягів інформації.

3. 🔍 Вибірка: Швидкий пошук потрібних записів за допомогою спеціальних запитів (SQL).

4. 🛡️ Захист: Гарантія цілісності, безпеки та відсутності суперечностей у системі.

При роботі з реляційними базами даних використовується чітка система понять:

• Стовпець = ПОЛЕ (Field): Характеризує окрему властивість або параметр об'єкта (наприклад, «Модель автобуса» або «Рік випуску»).

• Рядок = ЗАПИС (Record): Характеризує конкретний об'єкт цілком (наприклад, уся сукупність інформації про автобус «AA3129KH»).

• Клітинка = ЗНАЧЕННЯ (Value): Конкретна неподільна одиниця даних на перетині певного поля та запису (наприклад, число «2010»).

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

• 🛠️ 1. Режим Конструктора (Проектування):

  • Це місце, де працює архітектор.

  • Тут немає самих даних — тут створюються «креслення» таблиці: задаються імена полів, обираються їхні типи та налаштовуються обмеження.

• 📋 2. Режим Подання таблиці (Наповнення):

  • Це місце, де працює користувач.

  • Режим використовується для безпосереднього введення, перегляду та редагування фактичних записів про об'єкти.

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

• Короткий текст: Текстові дані довжиною до 255 символів (наприклад, державний номер «AA3129KH»).

• Автонумерація: СКБД сама генерує послідовні унікальні номери (1, 2, 3...) без участі людини.

• Число: Може приймати значення: Байт, Ціле число або Одинарне значення (Single).

💡 Чому для довжини маршруту (7,3 км) обирають «Одинарне значення», а не «Ціле число»? Тому що тип «Ціле число» взагалі не здатний зберігати дробову частину. СКБД просто відкине десяткові знаки після коми, зруйнувавши точність креслення!

Щоб система працювала стабільно, кожен окремий об'єкт у таблиці повинен мати абсолютний ідентифікатор.

> Первинний ключ (Primary Key, PK) — це поле, значення якого слугує унікальним маркером запису (наприклад, номерний знак для автобуса або номер паспорта для людини).

Два непорушні правила Ключа:

1. ⚡ Стовідсоткова унікальність: Значення первинного ключа ніколи не можуть повторюватися в межах однієї таблиці.

2. 🚫 Заборона порожнечі (Not Null): Клітинка ключа ніколи не може бути порожньою — без ключа СКБД просто «втрачає» об'єкт.

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

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

• Усі зв'язки будуються виключно на основі Первинних ключів.

• У реляційній архітектурі існує три типи таких мостів.

Зв'язок 1:1 («Один-до-одного») (One to One)

• Принцип: Одному запису з першої таблиці відповідає рівно один запис із другої таблиці.

• Архітектурний приклад: [Конкретний Водій] ── 1:1 ── [Посвідчення Водія].

• Застосування: Використовується рідко; зазвичай для поділу занадто великих таблиць або для відокремлення суворо секретних даних (наприклад, ізоляція медичних діагнозів від загальної таблиці пацієнтів).

ONE to MANY

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

• Архітектурний приклад: [Маршрут №9] ── 1:∞ ── [Автобус A, Автобус B, Автобус C]. За одним маршрутом закріплено багато автобусів, але кожен автобус приписаний до одного маршруту.

• Реалізація: Це найпоширеніший тип зв'язку в базах даних. У підлеглу таблицю («Автобуси») додається Зовнішній ключ (Foreign Key, FK) — стовпець, куди записується Первинний ключ із головної таблиці.

MANY to MANY

Зв'язок ∞:∞ («Багато-до-багатьох»)

• Принцип: Багато об'єктів пов'язані з багатьма (наприклад, пасажири та автобуси). Один пасажир їздить різними автобусами, а в кожному автобусі перебуває багато пасажирів.

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

• Рішення архітектора: Оскільки реляційна база не підтримує прямий зв'язок ∞:∞, СКБД вимагає створити третю, проміжну таблицю-посередник (наприклад, таблицю «Квитки»).

• Таблиця-посередник розбиває складний зв'язок на два прості зв'язки «один-до-багатьох» (1:∞):

  • [Пасажири] ── 1:∞ ── [Квитки]

  • [Автобуси] ── 1:∞ ── [Квитки]

СКБД — це не просто пасивне сховище, це суворий контролер.

• Забезпечення цілісності даних (Referential Integrity): Це спеціальний параметр зв'язку, який гарантує, що система фізично заблокує спробу закріпити автобус за неіснуючим маршрутом (наприклад, маршрутом №99) або спробу видалити маршрут, якщо по ньому все ще курсують автобуси.

• Завдяки цілісності даних у системі ніколи не виникає записів-«привидів».