Побудова ER-діаграм

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

Цілі лекції

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

• читати базові позначення нотацій Чена, Crow's Foot (Мартіна) та IDEF1X;
• перетворювати текстові вимоги на сутності, атрибути, зв'язки, кардинальності й обов'язковість;
• обґрунтовувати кожний елемент ER-моделі посиланням на вимогу;
• перевіряти модель за бізнес-правилами та прикладами;
• знаходити типові помилки моделювання;
• обирати CASE-засіб для побудови й спільного обговорення діаграми.

Передумови та межі

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

Ця лекція завершує концептуальний етап. Ми не перетворюємо сутності на таблиці, не реалізуємо ключі та не виконуємо нормалізацію. Це окремі наступні теми. Тут важливо правильно описати зміст предметної області незалежно від конкретної СКБД.

1. Одна модель, різні нотації

Нотація - це система графічних правил. Вона змінює спосіб зображення моделі, але не повинна змінювати її зміст. Бізнес-правило «один викладач може проводити багато навчальних пропозицій» залишається тим самим у Чена, Crow's Foot та IDEF1X.

Нотація Чена

Класична нотація Пітера Чена візуально розділяє складові моделі:

Кардинальність біля сторін зв'язку часто позначають 1, N або M. Нотація Чена корисна для навчання та раннього аналізу: ромб змушує явно назвати зміст зв'язку, а атрибути добре видно як окремі елементи. Недолік - велика діаграма швидко займає багато місця.

Умовний запис фрагмента:

[ВИКЛАДАЧ] -- 1 -- <ПРОВОДИТЬ> -- N -- [НАВЧАЛЬНА_ПРОПОЗИЦІЯ]

Кутові дужки тут лише текстово нагадують ромб, а не утворюють нову нотацію.

Нотація Crow's Foot, або нотація Мартіна

У Crow's Foot сутність зазвичай показують прямокутником із назвою та списком атрибутів. На кожному кінці лінії зв'язку два символи задають мінімальну й максимальну кількість пов'язаних екземплярів:

O означає нуль, риска | - один, а «лапка» < - багато. У різних редакторах напрямок символів може відрізнятися через орієнтацію лінії, тому читайте символи біля конкретного кінця, а не запам'ятовуйте вигляд усієї лінії.

Crow's Foot компактна й поширена в CASE-засобах. Вона добре показує сутності, їхні атрибути та діапазони участі на одній схемі. Головна небезпека - поставити символи механічно, не сформулювавши два перевірочні запитання до зв'язку.

IDEF1X

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

Для цієї лекції достатньо вміти:

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

IDEF1X корисна для строгого документування та моделей, де важливі залежності ідентичності. Водночас вона складніша для першої розмови із замовником. Деталі реалізації ідентифікаторів належать до логічного й фізичного проєктування, а не до поточного заняття.

Як обрати нотацію

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

2. Від вимог до ER-моделі

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

Крок 1. Визначте мету й межі

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

Не додавайте об'єкти лише тому, що вони існують у реальному світі. Якщо система не керує оплатою, сутність ПЛАТІЖ не належить до поточної моделі.

Крок 2. Випишіть кандидатні сутності

Іменники у вимогах є підказками, але не готовою відповіддю. Для кожного кандидата запитайте:

1. Чи існує багато екземплярів цього типу?
2. Чи потрібно зберігати про них окремі факти?
3. Чи бере кандидат участь у важливих зв'язках?
4. Чи це не атрибут, роль, екран або звіт?

Назви сутностей формулюйте в однині: СТУДЕНТ, КУРС, ВИКЛАДАЧ.

Крок 3. Додайте лише потрібні атрибути

Атрибут має описувати одну властивість сутності або, якщо це обґрунтовано, зв'язку. Для СТУДЕНТА можуть бути потрібні ім'я та контактна адреса; для КУРСУ - назва й короткий опис.

Перевірте кожний атрибут:

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

Крок 4. Сформулюйте зв'язки реченнями

Не залишайте безіменних ліній. Запишіть зв'язок у двох напрямках:

• ВИКЛАДАЧ проводить НАВЧАЛЬНУ_ПРОПОЗИЦІЮ;
• НАВЧАЛЬНА_ПРОПОЗИЦІЯ проводиться ВИКЛАДАЧЕМ.

Дієслово допомагає перевірити, чи має лінія зміст.

Крок 5. Визначте мінімум і максимум з обох боків

Для кожного кінця зв'язку поставте два питання:

1. Мінімум: чи може один екземпляр існувати без пов'язаного екземпляра?
2. Максимум: з одним чи з багатьма екземплярами він може бути пов'язаний?

Відповіді дають один із діапазонів: 0..1, 1..1, 0..N, 1..N. Слово «може» часто підказує необов'язковість, але остаточне рішення має підтвердити власник вимог. Наприклад, «викладач може проводити багато пропозицій» не пояснює, чи дозволено викладачу не проводити жодної.

Крок 6. Перевірте зв'язки, що мають власні факти

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

Наприклад, між студентом і навчальною пропозицією виникає РЕЄСТРАЦІЯ з датою та статусом. Це концептуальне рішення: ми визнаємо реєстрацію окремою подією. Воно ще не описує майбутні таблиці.

Крок 7. Зафіксуйте припущення й невирішені питання

Якщо вимога неоднозначна, не маскуйте припущення символом на діаграмі. Додайте примітку: «Потрібно уточнити, чи може пропозиція існувати до призначення викладача». Після відповіді оновіть діаграму.

3. Наскрізний приклад: реєстрація на курси

Початкові вимоги

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

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

Отримуємо п'ять сутностей:

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

Зв'язки та діапазони

У текстовому вигляді модель можна прочитати так:

КУРС 0..N -------- 1..1 НАВЧАЛЬНА_ПРОПОЗИЦІЯ 1..1 -------- 0..N ВИКЛАДАЧ
                              |
                            0..N
                              |
                            1..1
                         РЕЄСТРАЦІЯ
                              |
                            1..1
                              |
                            0..N
                           СТУДЕНТ

Підписи й таблиця вище є обов'язковими для точного читання текстової схеми. У CASE-засобі зв'язки потрібно назвати, а символи діапазонів поставити біля відповідних кінців.

Чому РЕЄСТРАЦІЯ є сутністю

Без РЕЄСТРАЦІЇ ми бачимо лише загальний зв'язок «студенти обирають пропозиції». Але дата і статус належать не студентові взагалі й не пропозиції взагалі. Вони описують конкретний факт: конкретний студент подав заявку на конкретну пропозицію. Отже, подія має власні атрибути та життєвий цикл.

Перевірка сценаріями

1. Новий студент ще нічого не обрав. Діапазон 0..N дозволяє студентові не мати реєстрацій.
2. Щойно опублікована пропозиція не має заявок. Її участь у реєстраціях також 0..N.
3. Реєстрацію створено. Вона не може існувати без рівно одного студента та рівно однієї пропозиції.
4. Викладача ще не призначено. Поточна модель це забороняє, бо для пропозиції встановлено 1..1. Якщо бізнес-процес вимагає чернетки без викладача, вимогу й мінімум потрібно змінити на 0..1.
5. Один курс проводять кілька разів. Курс може мати багато навчальних пропозицій, а кожна пропозиція стосується рівно одного курсу.

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

4. Як валідувати ER-діаграму

Перевірка сутностей

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

Перевірка атрибутів

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

Перевірка зв'язків

• Кожна лінія читається як речення в обох напрямках.
• Для обох кінців визначено мінімум і максимум.
• Кардинальність підтверджена прикладом, а не здогадом.
• Обов'язковість відповідає моменту життєвого циклу: створенню, чернетці, архівуванню.
• Якщо зв'язок має атрибути або власний стан, перевірено потребу в асоціативній сутності.

Перевірка з представниками предметної області

Покажіть не лише діаграму, а й короткі твердження:

• «Чи правда, що кожна пропозиція завжди має одного викладача?»
• «Чи може студент існувати в системі до першої реєстрації?»
• «Чи потрібно зберігати скасовану реєстрацію як подію?»

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

5. Типові помилки

1. Сутності взято прямо з усіх іменників. Слова «список», «сторінка» або «система» не обов'язково є сутностями.
2. Атрибут подано як сутність без причини. Окрема сутність потрібна, коли поняття має власні факти, багато екземплярів або важливі зв'язки.
3. Подію заховано у зв'язку. Якщо реєстрація має дату й статус, безіменної лінії недостатньо.
4. Вказано лише 1:N, але не мінімум. 0..N і 1..N дозволяють різні стани.
5. Кардинальності визначено за одним прикладом. Один викладач у тестових даних не доводить правило 1..1.
6. Обов'язковість переплутано з бажаністю. «Має бути призначений до початку навчання» не завжди означає «має бути призначений у момент створення чернетки».
7. Змішано нотації. Овал Чена поруч із «курячою лапкою» без легенди ускладнює читання.
8. Діаграма моделює інтерфейс. Кнопки та форми змінюються; концептуальна модель описує сталі поняття й правила.
9. Додано майбутні можливості без вимог. Надмірна модель складніша для перевірки й може закріпити хибні припущення.
10. Почато реалізацію до перевірки змісту. Технічно акуратна структура не виправить неправильну кардинальність або пропущену подію.

6. CASE-засоби

Draw.io (diagrams.net) зручний для безкоштовної роботи, довільного компонування й експорту. У бібліотеці фігур потрібно ввімкнути Entity Relation. Інструмент не перевірить бізнес-правила автоматично: автор відповідає за правильність символів.

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

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

Незалежно від засобу:

1. виберіть одну нотацію;
2. створіть легенду, якщо символи неочевидні;
3. назвіть сутності в однині, а зв'язки - дієсловами;
4. вирівняйте лінії та зменште кількість перетинів;
5. перевірте символи на обох кінцях кожного зв'язку;
6. збережіть вихідний файл і експорт для обговорення;
7. ведіть короткий список припущень і відкритих питань.

CASE-засіб прискорює малювання та обговорення, але не замінює аналіз вимог.

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

Завдання 1. Прочитайте позначення

Для кожного діапазону Crow's Foot запишіть мінімальну та максимальну участь: O|, ||, O<, |<. Потім поясніть словами вимогу: «Кожна навчальна пропозиція належить рівно одному курсу; курс може поки не мати жодної або мати багато пропозицій».

Завдання 2. Доповніть модель вимогою

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

1. Визначте нову сутність та 2-3 доречні атрибути.
2. Назвіть зв'язок у двох напрямках.
3. Установіть мінімум і максимум для обох сторін.
4. Запишіть припущення, яке потрібно уточнити щодо дистанційних пропозицій.

Завдання 3. Побудуйте й перевірте власну ER-діаграму

У Draw.io, Lucidchart або ERDPlus побудуйте концептуальну модель сервісу прокату обладнання за вимогами:

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

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

Підсумок

• Нотації Чена, Crow's Foot і IDEF1X по-різному зображають той самий зміст моделі.
• Якісна ER-діаграма починається з мети, меж і уточнених бізнес-правил.
• Сутності, атрибути та зв'язки мають бути простежуваними до вимог.
• Мінімальну й максимальну участь визначають окремо для обох кінців кожного зв'язку.
• Взаємодію з власними атрибутами або станом доцільно моделювати як асоціативну сутність.
• Валідація сценаріями виявляє помилки кардинальності й обов'язковості до реалізації.
• Draw.io, Lucidchart та ERDPlus допомагають будувати й обговорювати діаграми, але не приймають змістові рішення замість аналітика.
• Наступні етапи - перетворення ER-моделі на реляційну схему, реалізація ключів і нормалізація - свідомо не входять до цієї лекції.