Концептуальне моделювання: Мистецтво розуміння предметної області

Вступ: Коли код — не перший крок

Уявіть: ви отримали технічне завдання. Замовник хоче платформу для прослуховування аудіокниг. Є користувачі, є книги, є автори, є якийсь «прогрес прослуховування» і «особисті колекції». Перший інстинкт більшості розробників — відкрити IDE та почати писати класи. Або, у кращому разі, відкрити pgAdmin і почати малювати таблиці.

Це помилка.

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

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

Цей процес і є концептуальним моделюванням (Conceptual Modeling) — темою цієї статті.

Три рівні абстракції: Загальна карта

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

graph TD
    A["🧠 Концептуальний рівень<br/>(Conceptual Level)<br/>ЩО існує у предметній області?"]
    B["🔗 Логічний рівень<br/>(Logical Level)<br/>ЯК ці речі структуровані?"]
    C["💾 Фізичний рівень<br/>(Physical Level)<br/>ДЕ і ЯК це зберігається на диску?"]

    A -->|"Трансформація ER → Таблиці"| B
    B -->|"Матеріалізація: DDL, Індекси"| C

    style A fill:#3b82f6,stroke:#1d4ed8,color:#ffffff
    style B fill:#f59e0b,stroke:#b45309,color:#ffffff
    style C fill:#64748b,stroke:#334155,color:#ffffff

Концептуальний рівень — найвища, найабстрактніша точка зору. На цьому рівні ми не думаємо про таблиці, стовпці чи типи даних. Ми думаємо про сутності реального світу (автор, аудіокнига, користувач) та зв'язки між ними (автор написав аудіокнигу, користувач слухає аудіокнигу). Концептуальна модель — це мова домену, однаково зрозуміла розробнику та бізнес-аналітику, який ніколи не писав SQL.

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

Фізичний рівень — конкретна реалізація: DDL-скрипти, індекси, типи даних конкретної СУБД, внутрішня організація зберігання на диску.

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

Концептуальна модель: Агностична карта домену

Термін «концептуальна модель» (Conceptual Model, або Conceptual Schema) у контексті баз даних точніше за все описується так: це формальне представлення знань про предметну область, незалежне від будь-якої технології зберігання. Ключові слова тут — «формальне» та «незалежне».

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

«Незалежне» означає, що у концептуальній моделі немає жодних слідів технічних рішень. Немає VARCHAR(64), немає FOREIGN KEY, немає ON DELETE CASCADE. Є лише бізнес-поняття та їхні зв'язки.

Аналогія: Архітектурний план

Архітектор, проектуючи будинок, спочатку малює концептуальний план (ескіз): де кімнати, де коридори, де вхід, де вікна. Цей план зрозумілий замовнику і не містить деталей про марку цегли, тип бетону чи характеристики кабелів електропроводки.

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

Якщо замовник захоче змінити розташування стіни — це легко зробити на рівні ескізу. Але якщо будівництво вже почалося і несучу стіну вже зведено — переробка коштуватиме на порядок більше.

Те саме справедливо для баз даних.

Найпоширеніший інструмент: ER-діаграми

Найвідомішим і найширше розповсюдженим методом концептуального моделювання є діаграми «сутність-зв'язок» (Entity-Relationship Diagrams, або ER-діаграми). Метод запропонований Пітером Ченом (Peter Chen) у 1976 році у статті «The Entity-Relationship Model — Toward a Unified View of Data» — одній із найбільш цитованих робіт в історії інформатики.

Метод ґрунтується на трьох ключових поняттях: сутність (Entity), атрибут (Attribute) та зв'язок (Relationship). Розглянемо кожен з них детально на прикладі нашої аудіоплатформи.

Сутності: Об'єкти реального світу

Сутність (Entity) — це будь-який чітко ідентифікований об'єкт або явище реального світу, що має значення для системи, що розробляється. Кожна сутність може існувати у багатьох екземплярах (instances), і кожен екземпляр повинен бути відмінним від інших.

Зверніть увагу на слово «ідентифікований»: якщо не можна однозначно відрізнити один екземпляр від іншого — це не сутність у моделі ER. Наприклад, «літр води в океані» чи «кілограм пшениці з поля» не є сутностями в цьому розумінні, бо ми не можемо ідентифікувати конкретний літр або конкретний кілограм.

Виявлення сутностей аудіоплатформи

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

Бізнес-вимоги нашої аудіоплатформи:

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

Виділимо кандидатів у сутності:

«Прогрес прослуховування» — цікавий випадок: це не просто зв'язок між двома сутностями, а зв'язок, що має власні дані (позиція та дата останнього прослуховування). У теорії ER це моделюється як зв'язок з атрибутами (Relationship with Attributes), що ми розглянемо у розділі про зв'язки.

Сильні та слабкі сутності

В ER-моделі розрізняють сильні (Strong Entities) та слабкі (Weak Entities) сутності.

Сильна сутність (Strong Entity) — існує самостійно і може бути однозначно ідентифікована власними атрибутами. У нашій платформі сильними є: Author, Genre, User.

Слабка сутність (Weak Entity) — не може існувати без прив'язки до іншої сутності (її «власника») і не може бути однозначно ідентифікована без посилання на неї. Слабкі сутності нашої платформи:

• AudiobookFile — не може існувати без Audiobook. Якщо аудіокнигу видалено, усі її файли зникають разом з нею. Файл ідентифікується через комбінацію власного ідентифікатора та ідентифікатора батьківської аудіокниги.
• Collection — не може існувати без User. Колекція без власника позбавлена сенсу.

Слабкість сутності має пряме практичне значення: при виборі стратегії каскадного видалення (ON DELETE CASCADE) ми спираємося саме на факт залежності слабкої сутності від сильної. Більш детально ця тема розкривається у статті про фізичну схему.

Атрибути: Деталізація сутностей

Атрибут (Attribute) — це характеристика або властивість сутності, що описує або уточнює її. Кожен екземпляр сутності має конкретне значення кожного атрибуту (або спеціальне значення «невизначено» — NULL).

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

Прості та складені атрибути

Простий атрибут (Simple Attribute) — неподільна одиниця: duration (тривалість аудіокниги в секундах), release_year (рік виходу).

Складений атрибут (Composite Attribute) — що складається з кількох компонентів, кожен з яких має самостійне значення. Класичний приклад — Name (повне ім'я), що складається з FirstName і LastName. У нашій аудіоплатформі автор (Author) має саме такий атрибут.

Ключові атрибути

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

Для кожної сутності нашої платформи:

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

Похідні та багатозначні атрибути

Похідний атрибут (Derived Attribute) — значення якого обчислюється з інших атрибутів. Наприклад, якщо знаємо duration (тривалість у секундах), то duration_hours (тривалість у годинах) є похідним атрибутом. Зберігати похідні атрибути в базі — зазвичай надмірність. На ER-діаграмі вони позначаються пунктирним овалом.

Багатозначний атрибут (Multivalued Attribute) — атрибут, що може мати кілька значень для одного екземпляру сутності. Наприклад, якби платформа підтримувала кілька мов озвучення однієї аудіокниги — language став би багатозначним атрибутом. У нашій поточній моделі це реалізовано через окрему сутність AudiobookFile, де кожен файл може мати свій формат.

Повний перелік атрибутів сутностей аудіоплатформи

Зв'язки: Бізнес-правила між сутностями

Зв'язок (Relationship) — асоціація або залежність між двома чи більше сутностями, що відображає факти предметної області. Якщо сутності — це «іменники» бізнесу, то зв'язки — це «дієслова»: автор написав книгу, користувач слухає книгу, колекція містить аудіокниги.

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

Кардинальність: Скільки до скількох?

Кардинальність (Cardinality) визначає кількісне співвідношення між екземплярами двох сутностей у зв'язку. Розрізняють три базові типи:

Модальність: Обов'язково чи ні?

Модальність (Modality), або участь (Participation), визначає, чи є участь сутності у зв'язку обов'язковою. Розрізняють:

• Повну участь (Total Participation) — кожен екземпляр сутності обов'язково бере участь у зв'язку. Наприклад, кожна аудіокнига обов'язково має автора (не може існувати аудіокнига без автора).
• Часткову участь (Partial Participation) — деякі екземпляри можуть не брати участі у зв'язку. Наприклад, автор може не мати жодної аудіокниги на платформі (щойно зареєстрований або запрошений автор).

У нотації Crow's Foot модальність позначається символами на кінці лінії зв'язку:

• Обов'язковий кінець: вертикальна риска |
• Необов'язковий кінець: кружечок o

Аналіз зв'язків аудіоплатформи

Розберемо кожен зв'язок докладно, формулюючи бізнес-правила:

Author → Audiobook (writes)

• Один автор написав одну або більше аудіокниг? Ні — автор може бути на платформі без книг (часткова участь з боку Author).
• Одна аудіокнига написана рівно одним автором? Так, і без автора існувати не може (повна участь з боку Audiobook).
• Тип: 1:N (один Author до багатьох Audiobook). FK розміщується на стороні Audiobook.

Genre → Audiobook (categorizes)

• Один жанр охоплює нуль або більше аудіокниг.
• Одна аудіокнига належить рівно одному жанру (повна участь).
• Тип: 1:N. FK розміщується на стороні Audiobook.

User → Collection (owns)

• Один користувач може мати нуль або більше колекцій (часткова участь з боку User).
• Одна колекція належить рівно одному користувачу (повна участь; слабка сутність).
• Тип: 1:N. FK розміщується на стороні Collection.

Collection ↔ Audiobook (includes)

• Одна колекція може містити нуль або більше аудіокниг.
• Одна аудіокнига може бути у нуль або більше колекціях.
• Тип: M:N. Вимагає проміжної таблиці audiobook_collection.

Audiobook → AudiobookFile (consists of)

• Одна аудіокнига має один або більше файлів (принаймні один файл обов'язковий; повна участь AudiobookFile).
• Один файл належить рівно одній аудіокнизі (слабка сутність).
• Тип: 1:N. FK розміщується на стороні AudiobookFile.

User ↔ Audiobook через ListeningProgress (listens to)

• Один користувач може мати прогрес для нуль або більше аудіокниг.
• Одна аудіокнига може мати прогреси для нуль або більше користувачів.
• Тип: M:N з атрибутами (position, last_listened). Цей зв'язок особливий — він є не просто проміжною таблицею, а повноцінною сутністю-зв'язком із власними даними.

Концептуальна ER-діаграма аудіоплатформи

Тепер ми можемо зобразити повну концептуальну модель. Використовуємо нотацію Crow's Foot як більш наочну для відображення кардинальності та модальності:

erDiagram
    AUTHOR ||--o{ AUDIOBOOK : "написав"
    GENRE  ||--o{ AUDIOBOOK : "класифікує"
    AUDIOBOOK ||--|{ AUDIOBOOK_FILE : "складається з"
    USER   ||--o{ COLLECTION : "володіє"
    COLLECTION }o--o{ AUDIOBOOK : "містить"
    USER   }o--o{ AUDIOBOOK : "слухає (через прогрес)"

    AUTHOR {
        id Key
        first_name атрибут
        last_name атрибут
        bio атрибут
        image_path атрибут
    }
    AUDIOBOOK {
        id Key
        title атрибут
        duration атрибут
        release_year атрибут
        description атрибут
    }
    GENRE {
        id Key
        name атрибут
        description атрибут
    }
    USER {
        id Key
        username атрибут
        password_hash атрибут
        email атрибут
    }
    COLLECTION {
        id Key
        name атрибут
        created_at атрибут
    }
    AUDIOBOOK_FILE {
        id Key
        file_path атрибут
        format атрибут
        size атрибут
    }

Нотації ER-діаграм: Chen vs Crow's Foot

Концептуальні моделі можна зображати у різних нотаціях — стандартизованих системах позначень. Розглянемо дві найпоширеніші.

Нотація Пітера Чена (Chen Notation, 1976)

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

Основні позначення:

• Прямокутник — сутність (подвійний прямокутник для слабкої сутності)
• Ромб — зв'язок (подвійний для ідентифікуючого зв'язку з слабкою сутністю)
• Еліпс — атрибут (підкреслений — ключовий; пунктирний — похідний; подвійний — багатозначний)
• Лінії зі значками 1 та M — кардинальність

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

Нотація Crow's Foot (1976, Gordon Everest)

Запропонована Гордоном Евересом (Gordon Everest) під назвою «Inverted Arrow» («обернена стрілка»). Пізніше отримала назву Crow's Foot («вороняча лапка») або Fork («виделка») через вигляд символу множинності.

Основні позначення:

• Прямокутник — сутність (атрибути всередині)
• Лінія — зв'язок
• Символи на кінцях ліній для кардинальності та модальності:

[Author] —— <writes> —— [Audiobook]
   |                         ||
(Id)                       (Id)
(Name)                   (Title)
(Bio)                  (Duration)

AUTHOR ||--o{ AUDIOBOOK : "написав"

Ієрархії та спеціалізація

ER-модель підтримує концепції узагальнення (Generalization) та спеціалізації (Specialization) — механізми, аналогічні успадкуванню в об'єктно-орієнтованому програмуванні.

Супертип (Supertype) — загальна сутність, що об'єднує спільні атрибути. Підтип (Subtype) — спеціалізована сутність, що успадковує атрибути супертипу та додає власні.

Уявімо, що наша платформа планує ввести преміум-підписку. Тоді User стає супертипом, а FreeUser та PremiumUser — підтипами:

• Обидва мають id, username, email (успадковані від User)
• PremiumUser додатково має subscription_expires (власний атрибут)
• FreeUser може мати обмежений доступ до каталогу

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

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

Підсумок

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

Ключові поняття, яких ми торкнулися:

• Сутність — ідентифікований об'єкт реального світу; сильні та слабкі сутності.
• Атрибут — характеристика сутності; прості, складені, ключові, похідні, багатозначні.
• Зв'язок — асоціація між сутностями; кардинальність (1:1, 1:N, M:N) та модальність (повна/часткова участь).
• Зв'язок з атрибутами — M:N-зв'язок із власними даними (ListeningProgress).
• Нотації: Chen (академічна) та Crow's Foot (індустріальна); далі використовуємо Crow's Foot.
• Агностичність — концептуальна модель не залежить від технологій реалізації.

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