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

Колись давно, коли динозаври були великими… точніше, у 1970 році, один чувак на ім’я Едгар Кодд вирішив, що хаос у даних вже переріс творчий безлад і більше схожий на чорну діру, яка поглинає час і ресурси. Едгар довго думав і вигадав спосіб усе впорядкувати, а заодно — заклав фундамент цілого світу, де дані складаються в акуратні таблички, наче книжки на полиці в ідеальній бібліотеці. Рядки, стовпці, порядок — і ніяких тобі «і так зійде» чи «ну, і так же все зрозуміло».

Реляційна модель базується на представленні даних у вигляді таблиць, де кожна таблиця складається з рядків і стовпців. Інтуїтивно все зрозуміло: рядки — це записи, стовпці — це властивості або атрибути запису. Такий підхід спрощує обробку та маніпуляцію даними.

Уяви собі, що ти робиш замовлення в інтернет-магазині. Щоб це замовлення було успішно оброблене й доставлене, системі треба врахувати купу деталей: хто ти (покупець), яку службу доставки ти вибрав, куди доставити, і як відстежувати статус посилки.

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

На цій схемі показано приклад організації даних для процесу відстеження доставок:

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

Стрілки показують, як записи з таблиці Доставка замовлення пов’язані із записами в таблицях Покупці та Служби доставки.

Умовний приклад таблиці Доставка замовлення:

Переваги такого підходу:

• Інформація про клієнтів чи служби доставки зберігається один раз, що дозволяє уникнути повторів у кожному окремому записі про доставку.
• Зв’язки через унікальні номери (їх ще називають ключі) допомагають гарантувати, що не буде, наприклад, доставок без існуючого клієнта або через неіснуючу службу.
• Легко комбінувати дані з різних таблиць для отримання складних звітів чи конкретних вибірок.
• Зміна даних відбувається в одному місці й одразу стає доступною для всіх пов’язаних операцій (наприклад, телефон служби доставки).

Структура реляційної бази даних

Ядром реляційної бази даних є таблиці. Кожна таблиця має:

• Ім’я (Table Name), щоб ми могли її ідентифікувати — наприклад, customers.
• Набір стовпців (Columns/Attributes), які визначають властивості об’єкта.
  • При іменуванні стовпців, які служать унікальними номерами (первинними ключами), часто використовуємо шаблон ім’я_id. Суфікс _id тут означає "identifier". Приклад: Номер Покупця стане customer_id.
  • Наприклад, для таблиці customers: це можуть бути customer_id, first_name, email і так далі.
• Дані в рядках (Rows/Records) — один рядок у таблиці customers міститиме повну інформацію про одного конкретного покупця (101, Alex Song і так далі).

Розглянемо приклад таблиці — customers:

Ключі таблиць

Щоб унікально визначити кожен рядок у таблиці, використовується первинний ключ (Primary Key, PK). Це стовпець (або кілька), значення якого унікальні для кожного рядка і не можуть бути порожніми. Уяви його як унікальний номер для кожного запису, наприклад, customer_id у нашій таблиці customers: однозначно ідентифікує кожного покупця.

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

Для встановлення зв’язків між таблицями використовується зовнішній ключ (Foreign Key, FK). Це стовпець в одній таблиці, який посилається на первинний ключ в іншій таблиці. Зовнішні ключі — це "місточки" між таблицями. Часто ім’я стовпця зовнішнього ключа збігається з ім’ям первинного ключа, на який він посилається. Наприклад, у таблиці deliveries стовпець customer_id буде зовнішнім ключем, що зберігає значення зі стовпця customer_id таблиці customers, таким чином зв’язуючи доставку з покупцем.

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

• Таблиця customers містить інформацію про клієнтів; її первинний ключ — customer_id.
• Таблиця delivery_services зберігає дані про служби доставки; її первинний ключ — service_id.
• Таблиця orders (показана для повноти, бо на неї є посилання order_id з таблиці доставок) призначена для інформації про замовлення, з первинним ключем order_id.
• Таблиця deliveries є центральною для відстеження операцій доставки. Вона має:
  • Власний первинний ключ: delivery_id.
  • Три зовнішніх ключі для встановлення зв’язків:
    • customer_id (FK): зв’язує доставку з конкретним покупцем із таблиці customers.
    • service_id (FK): зв’язує доставку з обраною службою з таблиці delivery_services.
    • order_id (FK): зв’язує доставку з відповідним замовленням із таблиці orders.
  • Поле created_date вказує на дату й час створення запису про доставку.

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

Переваги реляційної моделі

Реляційна модель має купу суттєвих плюсів, які роблять її лідером серед інших підходів:

1. Простота структури. Таблиці зі стовпцями й рядками зрозумілі й прості.
2. Гнучкість у роботі з даними. Можна легко додавати нові дані чи змінювати їх, не порушуючи цілісність.
3. Підтримка складних запитів. За допомогою SQL можна витягати дані з багатьох таблиць, комбінувати їх, фільтрувати й робити практично все, чого вимагає твоя задача. Наприклад, знайти всіх студентів, записаних на конкретний курс — легко!
4. Цілісність даних через ключі. Використання первинних і зовнішніх ключів гарантує, що дані в базі будуть узгодженими. Не можна, наприклад, додати запис про студента на курс, якщо такого курсу не існує.

Реляційна модель даних — це фундамент сучасних баз даних. Вона проста, потужна й чудово підходить для зберігання структурованих даних. Як казав Едгар Кодд: "Упорядковуй або помри!" (ну, він сказав трохи інакше, але сенс приблизно такий...). У наступній лекції ми дізнаємось, чим реляційна модель відрізняється від інших типів баз даних (наприклад, NoSQL) і де їх краще застосовувати.