Моделювання даних: концептуальна/логічна/фізична моделі; ER-модель і нотації

📌 Про що ця тема

Тут перевіряють, чи вмієш ти описати структуру майбутньої бази даних ДО її створення. Ключове поняття — модель даних: формалізований опис того, які дані зберігаються, як вони повʼязані й за якими правилами. Головний інструмент — ER-модель (модель «сутність–звʼязок»).

📖 Головне

• Рівні моделювання йдуть від абстрактного до технічного: концептуальна → логічна → фізична. Це послідовність деталізації одного й того самого.

• Концептуальна модель — найзагальніша: лише головні сутності та звʼязки між ними, без атрибутів чи типів даних. Зрозуміла замовнику, не привʼязана до СКБД.

• Логічна модель — деталізація: усі сутності, їхні атрибути, ключі (первинні й зовнішні), типи звʼязків. Ще НЕ залежить від конкретної СКБД.

• Фізична модель — реалізація під конкретну СКБД: таблиці, стовпці з типами даних (INT, VARCHAR), індекси, обмеження, імена об'єктів.

• Сутність (entity) — об'єкт, про який зберігають дані (Студент, Книга). У таблиці стає таблицею.

• Атрибут — властивість сутності (прізвище, рік). Стає стовпцем.

• Екземпляр сутності — один конкретний об'єкт (один студент). Стає рядком.

• Первинний ключ (PK) — атрибут(и), що однозначно ідентифікують екземпляр. Унікальний, не порожній.

• Зовнішній ключ (FK) — атрибут, що посилається на PK іншої сутності; саме він реалізує звʼязок.

• Типи звʼязків за кратністю: 1:1 (один-до-одного), 1:N (один-до-багатьох), M:N (багато-до-багатьох).

• Звʼязок M:N у реляційній БД прямо не реалізується — його розбивають через проміжну (звʼязкову) таблицю з двома FK.

• Нотації ER: Чена (сутність — прямокутник, атрибут — овал, звʼязок — ромб) та «вороняча лапка» / Crow's Foot (кратність показують символами на кінці лінії: одинарна риска = один, «лапка» = багато, кружечок = нуль/необов'язково).

🔢 Як це працює на прикладі

Завдання: студенти і курси; студент може слухати багато курсів, курс — мати багато студентів.

Крок 1 (концептуальна): дві сутності Студент і Курс, між ними звʼязок «слухає».

Крок 2 (логічна): визначаємо кратність — M:N. Це означає, що потрібна третя сутність Запис. Студент(ID_студента PK, ПІБ), Курс(ID_курсу PK, Назва), Запис(ID_студента FK, ID_курсу FK, оцінка).

Крок 3 (фізична): таблиця Student (id INT PK, name VARCHAR(100)); Course (id INT PK, title VARCHAR(100)); Enrollment (student_id INT FK, course_id INT FK, grade INT).

Результат: M:N перетворено на два звʼязки 1:N через проміжну таблицю.

⚠️ Типові помилки

• Плутають рівні моделей: приписують концептуальній типи даних (це вже фізична) або «забувають» ключі в логічній.

• Намагаються реалізувати M:N одним зовнішнім ключем — це неможливо, потрібна звʼязкова таблиця.

• Плутають сутність і екземпляр: «Студент Іваненко» — це екземпляр, а не окрема сутність.

• Вважають, що фізична модель не залежить від СКБД — залежить саме вона (типи, індекси різні).

• У нотації Crow's Foot неправильно читають кінці лінії: кратність показує той символ, що БІЛЯ сутності, а не посередині.

🎯 Що завчити напамʼять

• Порядок рівнів: концептуальна → логічна → фізична (загальне → деталі → під СКБД).

• Що додається на кожному рівні: атрибути/ключі — у логічній; типи даних/індекси — у фізичній.

• Три кратності: 1:1, 1:N, M:N.

• M:N = обов'язково проміжна таблиця з двома FK.

• PK — унікальний і не порожній; FK — посилання на PK іншої таблиці.

🧠 Перевір себе

1. На якому рівні з'являються типи даних стовпців?

2. Як реалізувати звʼязок M:N у реляційній БД?

3. Чим сутність відрізняється від екземпляра?

4. Що в нотації Crow's Foot показує «вороняча лапка»?

Відповіді: 1 — на фізичному; 2 — через проміжну (звʼязкову) таблицю з двома зовнішніми ключами, що розбиває M:N на два 1:N; 3 — сутність це тип об'єкта (таблиця), екземпляр це один конкретний об'єкт (рядок); 4 — кратність «багато» на цьому кінці звʼязку.