Моделювання даних

📐 Рівні моделювання даних

Концептуальна модель

Високорівневе представлення бізнес-логіки:

Мета: Описує, що потрібно, без технічних деталей. Фокус на бізнес-вимогах.

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

Аудиторія: Бізнес-аналітики, стейкхолдери, архітектори. Легко зрозуміти не-технічним людям.

Інструменти: ER-діаграми високого рівня, концептуальні схеми, словники даних.

Логічна модель

Детальна структура даних без залежності від СКБД:

Мета: Визначає структуру даних, атрибути, типи даних, зв'язки. Незалежна від конкретної СКБД.

Компоненти: Таблиці, колонки, типи даних, первинні та зовнішні ключі, нормалізація до 3NF або BCNF.

Аудиторія: Базісти даних, розробники, архітектори систем. Технічна деталізація.

Процес: Трансформація концептуальної моделі в логічну структуру з нормалізацією.

Фізична модель

Реалізація в конкретній системі управління базою даних (СКБД):

Мета: Конкретна реалізація з урахуванням особливостей СКБД (PostgreSQL, MySQL, MongoDB тощо).

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

Аудиторія: DBA (адміністратори БД), розробники, які впроваджують схему.

Оптимізація: Фізична модель може де-normalize для покращення продуктивності, якщо потрібно.

🔗 ER-модель (Entity-Relationship)

Компоненти ER-моделі

Сутність (Entity): Об'єкт або концепція з реального світу (Клієнт, Замовлення, Товар). Представляється прямокутником.

Атрибут (Attribute): Властивість сутності (ім'я, email, дата). Простий атрибут, складений (адреса = вулиця + місто), багатозначний (телефони).

Зв'язок (Relationship): Взаємозв'язок між сутностями (Клієнт "робить" Замовлення). Представляється ромбом. Кардинальність: 1:1, 1:багато, багато:багато.

Ключ: Первинний ключ (унікально ідентифікує сутність), зовнішній ключ (посилається на іншу сутність).

Типи зв'язків

Один до одного (1:1): Кожен екземпляр однієї сутності пов'язаний з одним екземпляром іншої. Наприклад, Людина - Паспорт.

Один до багатьох (1:N): Один екземпляр пов'язаний з багатьма іншими. Наприклад, Департамент - Співробітники.

Багато до багатьох (M:N): Багато екземплярів однієї сутності пов'язані з багатьма екземплярами іншої. Потребує проміжної таблиці. Наприклад, Студенти - Курси.

Умови: Обов'язковість зв'язку (обов'язковий/опціональний). Участь сутності може бути повною або частковою.

📊 Нормалізація даних

Перша нормальна форма (1NF)

Базові вимоги до структури:

Вимоги: Кожна комірка містить атомарне значення (не ділиться далі). Немає повторюваних груп. Унікальні рядки.

Проблема до нормалізації: Таблиця з повторюваними групами (наприклад, кілька телефонів в одному полі).

Рішення: Винести повторювані дані в окремі рядки або таблицю. Кожен атрибут має одне значення.

Друга нормальна форма (2NF)

Усунення часткових залежностей:

Вимоги: Має бути в 1NF. Всі неключові атрибути повністю залежать від первинного ключа.

Проблема: Часткова залежність — атрибут залежить тільки від частини складеного ключа.

Рішення: Виділити атрибути, що залежать тільки від частини ключа, в окрему таблицю.

Третя нормальна форма (3NF)

Усунення транзитивних залежностей:

Вимоги: Має бути в 2NF. Немає транзитивних залежностей — неключові атрибути не залежать від інших неключових атрибутів.

Проблема: Якщо A → B і B → C, то є транзитивна залежність A → C через B.

Рішення: Виділити транзитивні залежності в окремі таблиці.

BCNF (Boyce-Codd Normal Form)

Підсилена третя нормальна форма:

Вимоги: Кожен детермінант (ліва частина функціональної залежності) є потенційним ключем.

Приклад: Якщо є залежність "Викладач → Курс" і "Курс → Викладач", але Викладач не є ключем, потрібна нормалізація.

Переваги: Усуває більше аномалій, ніж 3NF, забезпечує кращу цілісність даних.

🗃️ Типи баз даних

Реляційні бази даних (RDBMS)

Традиційний підхід з таблицями та зв'язками:

Структура: Дані організовані в таблиці (relations) з рядками (tuples) та колонками (attributes).

ACID: Atomicity (атомарність), Consistency (узгодженість), Isolation (ізоляція), Durability (стійкість). Гарантії транзакцій.

Приклади: PostgreSQL, MySQL, Oracle, SQL Server. Надійні для структурованих даних.

SQL: Мова структурованих запитів для роботи з даними. Стандартизована, потужна.

NoSQL бази даних

Гнучкі альтернативи для різних потреб:

Документні (MongoDB, CouchDB): Зберігають документи (JSON, BSON). Гнучкі схеми, добре для контенту.

Колонкові (Cassandra, HBase): Організовані по колонкам. Добре для аналітики, time-series даних.

Ключ-значення (Redis, DynamoDB): Проста структура. Швидкі, добре для кешування, сесій.

Графові (Neo4j, ArangoDB): Зберігають зв'язки між даними. Ідеальні для соціальних мереж, рекомендацій.

🔑 Ключі та індекси

Типи ключів

Первинний ключ (PK): Унікально ідентифікує кожен рядок. Не може бути NULL. Може бути простим (одна колонка) або складеним (кілька колонок).

Зовнішній ключ (FK): Посилається на первинний ключ іншої таблиці. Забезпечує цілісність даних, референсну цілісність.

Унікальний ключ: Забезпечує унікальність, але може містити NULL (один раз). Може бути кілька на таблицю.

Альтернативний ключ: Кандидат на первинний ключ, який не був обраний.

Індекси

Структури для покращення швидкості запитів:

B-tree індекси: Найпоширеніші. Ефективні для діапазонів та сортування. Автоматично створюються для PK та унікальних ключів.

Hash індекси: Швидкі для точних збігів (equality), але не підтримують діапазони. Тільки для = операцій.

Composite індекси: Індекси на кілька колонок. Порядок колонок важливий для ефективності.

Covering індекс: Містить всі дані для запиту, уникаючи звернення до таблиці.

Вартість: Індекси покращують читання, але сповільнюють вставку/оновлення (потрібно підтримувати індекс).

📚 Гайд з прикладів

Приклад 1: ER-модель для бібліотеки

Сутності:

Читач: id (PK), ім'я, email, телефон

Книга: isbn (PK), назва, автор, рік

Видача: id (PK), reader_id (FK), book_isbn (FK), дата_видачі, дата_повернення

Зв'язки: Читач має багато видач (1:N), Книга може бути у багатьох видачах (1:N через таблицю Видача).

Приклад 2: Нормалізація таблиці Замовлення

До нормалізації (1NF): Замовлення (id, клієнт, товар1, кількість1, товар2, кількість2) — повторювані групи.

Після 1NF: Окремі таблиці Замовлення та Позиції_замовлення. Кожна позиція в окремому рядку.

Після 2NF: Виділення даних про клієнта (якщо вони залежать тільки від id клієнта) в таблицю Клієнт.

Після 3NF: Виділення даних про товар в таблицю Товар для усунення транзитивних залежностей.

Спробуйте наживо

Усе, що вище, працює прямо у вашому браузері — відкрийте Dimensionality Reduction: PCA, t-SNE & UMAP і змінюйте параметри під час роботи. Нічого не встановлюється, нічого не завантажується на сервер, уся модель живе в одній вкладці.