Елементи моделі сутність-зв’язок - Програмні продукти
У реальному проектуванні структури бази даних застосовується метод - так зване, семантичне моделювання. Семантичне моделювання є моделювання структури даних, спираючись на зміст цих даних. Як інструмент семантичного моделювання використовуються різні варіантидіаграм сутність-зв'язок(ER - Entity-Relationship).
Ми опишемо роботу з ER-діаграмами близько до нотації Баркера як досить легкої у розумінні основних ідей. Цей розділ є скоріш ілюстрацією методів семантичного моделювання, ніж повноцінним запровадженням у цю область.
Основні поняття ER-діаграм
Визначення 1:Сутність- це клас однотипних об'єктів, інформація про які має бути врахована в моделі. Кожна сутність повинна мати найменування, виражене іменником в однині. Прикладами сутностей може бути такі класи об'єктів як " Постачальник " , " Співробітник " , " Накладна " . Кожна сутність моделі зображується у вигляді прямокутника з найменуванням:
Визначення 2:Примірник сутності- це конкретний представник даної сутності. Наприклад, представником сутності "Співробітник" може бути "Співробітник Іванов". Примірники сутностей мають бути помітні, тобто. сутності повинні мати деякі властивості, які є унікальними для кожного екземпляра цієї сутності.
Визначення 3:Атрибут сутності- це іменована характеристика, яка є деякою властивістю сутності. Прикладами атрибутів сутності "Співробітник" можуть бути такі атрибути як "Табельний номер", "Прізвище", "Ім'я", "По батькові","Посада", "Зарплата" тощо. Атрибути зображуються в межах прямокутника, що визначає сутність:

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

Визначення 5:Зв'язок- це деяка асоціація між двома сутностями. Одна сутність може бути пов'язана з іншою сутністю або сама з собою. Зв'язки дозволяють по одній сутності знаходити інші сутності, пов'язані з нею. Наприклад, зв'язки між сутностями можуть висловлюватися наступними фразами - "СПІВРОБІТНИК може мати кілька ДІТЕЙ", "кожен СПІВРОБІТНИК зобов'язаний числитися рівно в одному ВІДДІЛІ". Графічно зв'язок зображується лінією, що з'єднує дві сутності:
Кожна зв'язок має два кінці та одне або два найменування. Найменування зазвичай виявляється у невизначеної дієслівної формі: "мати", "належати" і т.п. Кожне з найменувань належить до кінця зв'язку. Іноді найменування не пишуться через їхню очевидність.
Кожний зв'язок може мати один з наступних типів зв'язку:
Зв'язок типуодин-до-одномуозначає, що один екземпляр першої сутності (лівий) пов'язаний з одним екземпляром другої сутності (правою). Зв'язок один до одного найчастіше свідчить про те, що насправді ми маємо всього одну сутність, неправильно розділену на дві.
Зв'язок типуодин-багатьомозначає, що один екземпляр першої сутності (лівий) пов'язаний з декількома екземплярами другої сутності (правою). Це тип, що найчастіше використовуєтьсязв'язку. Ліва сутність (з боку "один") називаєтьсябатьківської, права (з боку "багато") -дочірньої. Характерний приклад такого зв'язку наведено на Мал. 4.
Зв'язок типубагато-багатьомозначає, що кожен екземпляр першої сутності може бути пов'язаний з декількома екземплярами другої сутності, і кожен екземпляр другої сутності може бути пов'язаний з декількома екземплярами першої сутності. Тип зв'язку багатьом є тимчасовим типом зв'язку, допустимим на ранніх етапах розробки моделі. Надалі цей тип зв'язку повинен бути замінений двома зв'язками типу одним-багатьом шляхом створення проміжної сутності.
Кожен зв'язок може мати одну з двох модальностей зв'язку:
Зліва направо: "кожен співробітник може мати кілька дітей". Справа наліво: "Кожна дитина зобов'язана належати рівно одному співробітнику".
Приклад розробки простої ER-моделі
Під час розробки ER-моделей ми маємо отримати таку інформацію про предметної області:
- Список сутностей предметної галузі.
- Список атрибутів сутності.
- Опис взаємозв'язків між сутностями.
ER-діаграми зручні тим, що процес виділення сутностей, атрибутів та зв'язків є ітераційним. Розробивши перший наближений варіант діаграм, ми уточнюємо їх, опитуючи експертів предметної галузі. При цьому документацією, в якій фіксуються результати розмов, є ER-діаграми.
Припустимо, що маємо завдання розробити інформаційну систему на замовлення деякої оптової торгової фірми. Насамперед ми повинні вивчити предметну область та процеси, що відбуваються в ній. І тому ми опитуємо співробітників фірми, читаємо документацію, вивчаємо форми замовлень, накладних тощо.
Наприклад,під час розмови з менеджером з продажу, з'ясувалося, що він (менеджер) вважає, що проектована система повинна виконувати такі дії:
- Зберігати інформацію про покупців.
- Друкувати накладні на відпущені товари.
- Слідкувати за наявністю товарів на складі.
Виділимо всі іменники у цих пропозиціях - це будуть потенційні кандидати на сутності та атрибути, і проаналізуємо їх (незрозумілі терміни виділятимемо знаком питання):
- Покупець – явний кандидат на сутність.
- Накладна – явний кандидат на сутність.
- Товар – явний кандидат на сутність
- (?) Склад – а взагалі, скільки складів має фірма? Якщо кілька, то це буде кандидатом на нову сутність.
- (?) Наявність товару - це, швидше за все, атрибут, але атрибут якоїсь сутності?
Відразу виникає очевидний зв'язок між сутностями - "покупці можуть купувати багато товарів" та "товари можуть продаватися багатьом покупцям". Перший варіант діаграми виглядає так:

Поставивши додаткові питання менеджеру, ми з'ясували, що фірма має кілька складів. Причому кожен товар може зберігатися на кількох складах і бути проданим з будь-якого складу.
Куди помістити сутності "Накладна" та "Склад" і з чим їх пов'язати? Запитаємо себе, як пов'язані ці сутності між собою та з сутностями "Покупець" та "Товар"? Покупці купують товари, отримуючи при цьому накладні, в які внесені дані про кількість та ціну купленого товару. Кожен покупець може одержати кілька накладних. Кожна накладна повинна виписуватися однією покупця. Кожна накладна повинна містити кілька товарів (не буває порожніх накладних). Кожен товар, у свою чергу, може бути проданий декількомпокупцям за кілька накладних. Крім того, кожна накладна має бути виписана з певного складу, і з будь-якого складу може бути виписано багато накладних. Таким чином, після уточнення, діаграма буде виглядати так:

Настав час подумати про атрибути сутностей. Розмовляючи зі співробітниками фірми, ми з'ясували таке:
У ході додаткової розмови з менеджером удалося прояснити різні поняття цін. Виявилося, кожен товар має деяку поточну ціну. Ця ціна, за якою товар продається зараз. Звичайно, ця ціна може змінюватися з часом. Ціна одного й того самого товару в різних накладних, виписаних у різний час, може бути різною. Таким чином, є дві ціни - ціна товару у накладній та поточна ціна товару.
З поняттям "Список товарів у накладній" все досить ясно. Сутності "Накладна" і "Товар" пов'язані один з одним ставленням типу багатьом. Такий зв'язок, як ми зазначали раніше, повинен бути розщеплений на два зв'язки типу одним-багатьом. Для цього потрібна додаткова сутність. Цією сутністю і буде сутність "Список товарів у накладній". Зв'язок її з сутностями "Накладна" і "Товар" характеризується такими фразами - "кожна накладна повинна мати кілька записів зі списку товарів у накладній", "кожний запис зі списку товарів у накладній повинен включатися рівно в одну накладну", "кожен товар може включатися у кілька записів зі списку товарів у накладній " , " кожен запис зі списку товарів у накладної має бути пов'язана з одним товаром " . Атрибути "Кількість товару в накладній" та "Ціна товару в накладній" є атрибутами сутності "Список товарів у накладній".
Так само надійдемо зі зв'язком, що з'єднує сутності "Склад" і "Товар". Введемододаткову сутність "Товар на складі". Атрибутом цієї сутності буде "Кількість товару на складі". Таким чином, товар буде значитися на будь-якому складі і кількість його на кожному складі буде своєю.
Тепер можна внести все це у діаграму:

Концептуальні та фізичні ER-моделі
Розроблений вище приклад ER-діаграми є прикладомконцептуальної діаграми. Це означає, що діаграма не враховує особливостей конкретної СУБД. За цією концептуальною діаграмою можна побудуватифізичну діаграму, яка вже будуть враховуватися такі особливості СУБД, як допустимі типи та найменування полів та таблиць, обмеження цілісності тощо. Фізичний варіант діаграми, наведеної на рис. 9 може виглядати, наприклад, наступним чином:

На даній діаграмі кожна сутність є таблицею бази даних, кожен атрибут стає колонкою відповідної таблиці. Звертаємо увагу на те, що в багатьох таблицях, наприклад, "CUST_DETAIL" та "PROD_IN_SKLAD", що відповідають сутностям "Запис списку накладної" та "Товар на складі", з'явилися нові атрибути, яких не було в концептуальній моделі - це ключові атрибути батьківських таблиць ,мігрувалив дочірні таблиці для того, щоб забезпечити зв'язок між таблицями за допомогою зовнішніх ключів.
Легко помітити, що отримані таблиці відразу перебувають у 3НФ.
Реальним засобом моделювання даних є не формальний метод нормалізації відносин, а так зване семантичне моделювання.
Як інструмент семантичного моделювання використовуються різні варіантидіаграм сутність-зв'язок(ER - Entity-Relationship).
Діаграми сутність-зв'язок дозволяють використовувати наочні графічніпозначення для моделювання сутностей та їх взаємозв'язків.
РозрізняютьконцептуальнітафізичніER-діаграми. Концептуальні діаграми не враховують особливостей конкретних СУБД. Фізичні діаграми будуються за концептуальними і є прообразом конкретної бази даних. Сутності, визначені в концептуальній діаграмі стають таблицями, атрибути стають колонками таблиць (при цьому враховуються допустимі для даної СУБД типи даних та найменування стовпців), зв'язки реалізуються шляхомміграціїключових атрибутів батьківських сутностей та створення зовнішніх ключів.
При правильному визначенні сутностей, отримані таблиці відразу перебувати у 3НФ. Основна перевага методу полягає в тому, що модель будується методом послідовних уточнень початкових діаграм.
У цьому розділі, що є ілюстрацією до методів ER-моделювання, не розглянуті складніші аспекти побудови діаграм, такі як підтипи, ролі, що виключають зв'язки, нестерпні зв'язки, що ідентифікують зв'язки і т.п.