ER-модель: сутності, атрибути та зв’язки

Перш ніж створювати таблиці, розробник має зрозуміти, про що система зберігатиме дані, які властивості важливі та як об’єкти пов’язані між собою. Для цього використовують концептуальну ER-модель: вона описує предметну область мовою сутностей, атрибутів і зв’язків, не прив’язуючись до конкретної СКБД.

Цілі лекції

Після опрацювання матеріалу ви зможете:

• пояснити місце концептуального проєктування серед етапів створення бази даних;
• визначати межі предметної області та формулювати інформаційні потреби;
• розрізняти сутність, тип сутності й екземпляр сутності;
• класифікувати прості, складені, однозначні, багатозначні, похідні та ключові атрибути;
• визначати учасників і ступінь зв’язку;
• обґрунтовувати кардинальності 1:1, 1:N і M:N;
• встановлювати обов’язкову або необов’язкову участь сутності у зв’язку.

Передумови

Потрібно розуміти поняття бази даних, СКБД, моделі даних і предметної області. Знання SQL або правил графічного оформлення ER-діаграм не потрібні.

1. Від потреб організації до структури бази даних

Базу даних не варто починати з випадкового переліку таблиць. Проєктування зазвичай проходить кілька пов’язаних етапів.

Поділ не означає, що команда проходить етапи лише один раз. Під час перевірки моделі можуть виявитися пропущені вимоги, тому доведеться повернутися до аналізу. Важливо інше: рішення різних рівнів не слід змішувати. На концептуальному рівні ми з’ясовуємо, що означає «бронювання аудиторії» для коледжу, а не обираємо тип стовпця чи індекс PostgreSQL.

Предметна область і межі системи

Предметна область - частина реального світу, факти про яку потрібні системі. Її визначає не назва організації, а мета конкретної інформаційної системи.

Наприклад, система бронювання аудиторій коледжу може охоплювати:

• аудиторії та їхню місткість;
• працівників, які створюють заявки;
• часові інтервали;
• бронювання та їхні статуси;
• обладнання, потрібне для заняття.

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

Щоб уточнити предметну область, ставлять змістові запитання:

1. Хто користується системою і які дії виконує?
2. Які об’єкти потрібно розрізняти?
3. Які події та зміни потрібно зберігати?
4. На які запитання система має відповідати?
5. Які правила не можна порушити?
6. Чи потрібна історія, чи достатньо поточного стану?

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

2. Сутність і екземпляр сутності

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

Для системи бронювання можливі типи сутностей:

• Аудиторія;
• Працівник;
• Бронювання;
• Обладнання.

Екземпляр сутності - один конкретний представник типу сутності. Аудиторія є типом сутності, а «аудиторія 305 місткістю 28 місць» - її екземпляром. Бронювання є типом, а «бронювання BR-2026-081 від 26 серпня на 10:00» - екземпляром.

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

Корисна перевірка: чи потрібно зберігати кілька екземплярів цього поняття, розрізняти їх і фіксувати власні властивості або зв’язки? Якщо так, це кандидат на сутність. Остаточне рішення залежить від вимог, а не від граматичної форми слова.

Типові помилки під час пошуку сутностей

• Перетворити кожен іменник на сутність. У вимозі «зберігати номер аудиторії» слово «номер» є властивістю, а не самостійним об’єктом.
• Назвати екземпляр замість типу. Аудиторія 305 - екземпляр; тип краще назвати Аудиторія.
• Моделювати екран або звіт замість предметної області. Форма бронювання може бути елементом інтерфейсу, але не обов’язково сутністю даних.
• Об’єднати різні поняття. ВикладачАудиторія приховує два об’єкти та зв’язок між ними.
• Додати сутність без інформаційної потреби. Якщо система не зберігає дані про виробників обладнання і не використовує їх, сутність Виробник зайва.

3. Атрибути та їхні види

Атрибут - значуща властивість сутності або зв’язку, яку потрібно зберігати чи визначати. Для Аудиторії атрибутами можуть бути номер, корпус, місткість і призначення. Для Бронювання - номер заявки, дата створення, початок, завершення та статус.

Назва атрибута повинна бути однозначною в контексті. Дата надто нечітка, якщо бронювання має дату створення, дату проведення і дату скасування. Краще використовувати змістові назви.

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

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

Складений атрибут можна змістовно поділити на компоненти, які система використовує окремо. Адреса може складатися з населеного пункту, вулиці, номера будинку та поштового індексу. ПІБ може бути поділене на прізвище, ім’я та по батькові, якщо потрібні сортування, звертання або пошук за компонентами.

Подільність залежить від вимог. Для простого підпису «місце проведення: Київ, вул. Хрещатик, 10» адреса може сприйматися як одне значення. Для доставлення й пошуку за містом потрібні компоненти. Складеність є властивістю моделі, а не самого слова.

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

Однозначний атрибут має одне значення для одного екземпляра в певний момент. Наприклад, поточна місткість аудиторії дорівнює 28.

Багатозначний атрибут може мати кілька значень для одного екземпляра. У працівника може бути кілька контактних номерів, а аудиторія може підтримувати кілька видів обладнання.

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

Збережені та похідні атрибути

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

Похідний атрибут можна обчислити з інших значень. Вік отримують із дати народження та поточної дати; середній бал - з оцінок; тривалість бронювання - з часу початку і завершення.

Похідне значення не обов’язково треба зберігати. Якщо зберегти і дату народження, і поточний вік, вік стане неактуальним. Однак у деяких системах обчислений результат свідомо фіксують, наприклад суму рахунку на момент продажу. Це окреме проєктне рішення. У концептуальній моделі потрібно принаймні позначити, що значення можна або потрібно отримати за правилом.

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

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

Якісний ключ має бути:

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

Прізвище не є надійним ключем студента, бо повторюється і може змінитися. Номер аудиторії може бути унікальним лише в межах корпусу, тому ключем може бути поєднання корпус + номер. Такий ключ називають складеним ключем, бо він містить кілька атрибутів.

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

Один атрибут може мати кілька характеристик

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

4. Зв’язки між сутностями

Зв’язок - змістова асоціація між екземплярами одного або кількох типів сутностей, важлива для предметної області.

Приклади:

• Викладач створює Бронювання;
• Бронювання стосується Аудиторії;
• Студент вивчає Дисципліну;
• Працівник керує Працівником.

Назва зв’язку має передавати зміст. Дієслово або коротка дієслівна фраза допомагає прочитати правило в обох напрямках: «клієнт оформлює замовлення», «замовлення оформлене клієнтом».

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

Ступінь зв’язку

Ступінь зв’язку - кількість ролей типів сутностей, що беруть участь у зв’язку.

• Унарний, або рекурсивний, зв’язок охоплює один тип сутності в різних ролях. Наприклад, працівник керує іншим працівником.
• Бінарний зв’язок поєднує два типи сутностей. Наприклад, клієнт оформлює замовлення.
• Тернарний зв’язок одночасно поєднує три типи сутностей. Наприклад, викладач проводить заняття з дисципліни для групи. Зміст тут належить саме поєднанню трьох учасників.

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

5. Кардинальність зв’язку

Кардинальність показує максимальну кількість екземплярів однієї сутності, з якими може бути пов’язаний один екземпляр іншої сутності відповідно до бізнес-правила.

Один до одного (1:1)

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

Приклад: у компанії кожен автомобіль має не більше одного чинного паркувального дозволу, а кожен чинний дозвіл виданий не більше ніж одному автомобілю. Це 1:1 за умови, що моделюється саме чинний дозвіл, а не вся історія дозволів.

Зв’язок 1:1 варто обґрунтувати правилом. Те, що зараз кожен менеджер веде одного клієнта, не доводить, що система забороняє менеджеру мати кількох клієнтів.

Один до багатьох (1:N)

Одному екземпляру першої сутності може відповідати багато екземплярів другої, але кожен екземпляр другої пов’язаний не більше ніж з одним екземпляром першої.

Приклад: один клієнт може оформити багато замовлень, кожне замовлення належить одному клієнту. З боку клієнта до замовлень маємо 1:N.

Напрям важливий. Те саме правило можна прочитати як N:1 від замовлення до клієнта. Запис 1:N без назв учасників не пояснює, де саме «один» і де «багато».

Багато до багатьох (M:N)

Одному екземпляру першої сутності може відповідати багато екземплярів другої, і навпаки.

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

Кардинальність визначають не за кількістю наявних записів, а за дозволеним правилом. Якщо сьогодні в базі лише одне замовлення клієнта, зв’язок усе одно може бути 1:N, бо система допускає наступні замовлення.

6. Участь і обов’язковість

Кардинальність «один» або «багато» описує максимум, але не відповідає, чи може екземпляр не мати зв’язку взагалі. Для цього визначають мінімальну участь, або обов’язковість.

• Обов’язкова, або повна, участь означає, що кожен екземпляр сутності повинен брати участь у зв’язку хоча б один раз. Мінімум дорівнює 1.
• Необов’язкова, або часткова, участь означає, що екземпляр може не брати участі у зв’язку. Мінімум дорівнює 0.

Розглянемо правило: «студент може ще не мати оцінок; кожна оцінка обов’язково виставлена одному студенту».

• для одного студента кількість оцінок становить від нуля до багатьох: 0..N;
• для однієї оцінки кількість студентів дорівнює рівно одному: 1..1.

Отже, участь Студента у зв’язку з оцінкою необов’язкова, а участь Оцінки обов’язкова. Не слід казати, що «студент необов’язковий». Необов’язковим є не існування студента, а його участь у конкретному зв’язку.

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

Для кожного зв’язку корисно поставити чотири запитання:

1. Скільки щонайбільше об’єктів B може бути пов’язано з одним A?
2. Скільки щонайбільше об’єктів A може бути пов’язано з одним B?
3. Чи може A існувати без цього зв’язку?
4. Чи може B існувати без цього зв’язку?

Відповіді мають спиратися на вимоги. Якщо вимога мовчить, не треба вгадувати: слід поставити запитання замовнику.

7. Наскрізний приклад: бронювання аудиторій

Зведемо поняття в короткий словесний фрагмент концептуальної моделі.

Вимоги: працівник створює заявки на бронювання аудиторій. Працівник може ще не створити жодної заявки. Кожне бронювання створене рівно одним працівником і стосується рівно однієї аудиторії. Аудиторія може існувати без бронювань. Одне бронювання може вимагати кілька видів обладнання, а один вид обладнання може бути потрібний у багатьох бронюваннях.

Кандидати на сутності:

• Працівник: ключ табельний номер, атрибути ПІБ, електронна пошта;
• Аудиторія: складений ключ корпус + номер, атрибути місткість, призначення;
• Бронювання: ключ номер заявки, атрибути початок, завершення, статус, похідний атрибут тривалість;
• Вид обладнання: ключ код виду, атрибут назва.

Зв’язки та обмеження:

Це ще не повна діаграма і не схема таблиць. Ми навмисно описали семантику словами й діапазонами. Спосіб графічного позначення сутностей, атрибутів, кардинальностей і участі в нотаціях Чена, Crow’s Foot та IDEF1X буде темою наступної лекції.

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

Завдання 1. Відокремте сутності від властивостей

Для сервісу доставки задано поняття: клієнт, номер телефону клієнта, посилка, трек-номер, кур’єр, ім’я кур’єра, статус доставки, адреса одержання.

1. Визначте три типи сутностей.
2. Розподіліть решту понять як їхні атрибути.
3. Для кожної сутності наведіть один конкретний екземпляр.

Завдання 2. Класифікуйте атрибути

Продовжте модель сервісу доставки. Для клієнта потрібно зберігати код клієнта, ПІБ, адресу з окремим пошуком за містом і вулицею, кілька номерів телефону та дату народження. Система показує поточний вік, обчислений із дати народження.

1. Визначте прості та складені атрибути.
2. Визначте однозначні й багатозначні атрибути.
3. Визначте збережені, похідні та ключові атрибути.
4. Поясніть, чому один атрибут може належати одразу до кількох видів.

Завдання 3. Сформулюйте зв’язки й обмеження

Доповніть модель такими правилами:

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

Для кожного зв’язку:

1. назвіть учасників і зміст зв’язку;
2. визначте ступінь;
3. установіть кардинальність 1:1, 1:N або M:N;
4. запишіть мінімальну й максимальну участь кожної сторони у вигляді 0..1, 1..1, 0..N або 1..N;
5. визначте, до чого належать час прибуття і час вибуття.

Підсумок

• Проєктування бази починається з аналізу вимог, а концептуальна модель передує логічній схемі та фізичним рішенням.
• Предметна область має конкретні межі, визначені задачами користувачів і бізнес-правилами.
• Сутність описує тип значущих об’єктів, а екземпляр є одним конкретним представником цього типу.
• Атрибути бувають простими або складеними, однозначними або багатозначними, збереженими або похідними; ключові атрибути ідентифікують екземпляри.
• Зв’язок фіксує важливу асоціацію між сутностями, а його ступінь визначається кількістю ролей учасників.
• Кардинальності 1:1, 1:N і M:N описують максимальну кількість пов’язаних екземплярів.
• Обов’язковість описує мінімальну участь: нуль для необов’язкової та один для обов’язкової.
• Кардинальність і участь визначають за правилами предметної області, а не за випадковою кількістю наявних даних.
• Графічні нотації й детальний процес побудови ER-діаграм розглядатимуться в наступній лекції.