Елементи моделі "сутність-зв'язок", Інтеграція додатків і даних, Бази даних, статті

У реальному проектуванні структури бази даних застосовується метод – так зване, семантичне моделювання. Семантичне моделювання є моделювання структури даних, спираючись на зміст цих даних. Як інструмент семантичного моделювання використовуються різні варіанти діаграм сутність-зв'язок (ER – Entity-Relationship).

Перший варіант моделі сутність-зв'язок був запропонований у 1976 р. Пітером Пін-Шен Ченом. Надалі багатьма авторами були розроблені свої варіанти подібних моделей (нотація Мартіна, нотація IDEF1X, нотація Баркера та ін.) Крім того, різні програмні засоби, що реалізують одну й ту ж нотацію, можуть відрізнятися своїми можливостями. По суті, всі варіанти діаграм сутність-зв'язок виходять з однієї ідеї – Малюнок завжди наочніше текстового опису. Всі такі діаграми використовують графічне зображення сутностей предметної області, їх властивостей (атрибутів), і взаємозв'язків між сутностями.

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


Основні поняття ER-діаграм

Визначення 1: Сутність – Це клас однотипних об'єктів, інформація про яких повинна бути врахована в моделі.
Кожна сутність повинна мати найменування, виражене іменником в однині. Прикладами сутностей можуть бути такі класи об'єктів як "Постачальник", "Співробітник", "Накладна". Кожна сутність в моделі зображується у вигляді прямокутника з найменуванням:

Рис. 1

Визначення 2: Примірник сутності – Це конкретний представник даної сутності.
Наприклад, представником сутності "Співробітник" може бути "Співробітник Іванов". Екземпляри сутностей повинні бути помітні, тобто сутності повинні мати деякі властивості, унікальні для кожного екземпляра цієї сутності.

Визначення 3: Атрибут сутності – Це іменована характеристика, що є деяким властивістю сутності.
Найменування атрибута має бути виражене іменником в однині (можливо, з характеризують прикметниками). Прикладами атрибутів сутності "Співробітник" можуть бути такі атрибути як "Табельний номер "," Прізвище "," Ім'я "," По батькові "," Посада "," Зарплата "і т.п. Атрибути зображуються в межах прямокутника, що визначає сутність:

Рис. 2

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

Рис. 3

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

Рис. 4

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

Кожна зв'язок може мати один з наступних типів зв'язку :

Рис. 5

Зв'язок типу один-до-одного означає, що один примірник першої сутності (лівої) пов'язаний з одним примірником другий сутності (правої). Зв'язок один-до-одного найчастіше свідчить про те, що насправді ми маємо всього одну сутність, неправильно розділену на дві.

Зв'язок типу один-до-багатьох означає, що один примірник першої сутності (лівої) пов'язаний з декількома екземплярами другий сутності (правої). Це найбільш часто використовуваний тип зв'язку. Ліва сутність (з боку "один") називається батьківського, Права (з боку "багато") – дочірньої. Характерний приклад такого зв'язку наведено на Рис. 4.

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

Кожна зв'язок може мати одну з двох модальностей зв'язку:

Рис. 6

Модальність "може"Означає, що екземпляр однієї суті може бути пов'язаний з одним або кількома екземплярами іншої сутності, а може бути і не пов'язаний ні з одним екземпляром.
Модальність "повинен"Означає, що примірник однієї сутності зобов'язаний бути пов'язаний не менш ніж з одним примірником іншої сутності.
Зв'язок може мати різну модальність з різних кінців (як на Рис. 4). Описаний графічний синтаксис дозволяє однозначно читати діаграми, користуючись наступною схемою побудови фраз:

<Кожен примірник СУТНОСТІ 1> <Модальні ЗВ'ЯЗКУ> <НАЙМЕНУВАННЯ ЗВ'ЯЗКУ> <ТИП ЗВ'ЯЗКУ> <примірник СУТНОСТІ 2>

Кожна зв'язок може бути прочитана як зліва направо, так і справа наліво. Зв'язок на Рис. 4 читати так:

Зліва направо: "кожен співробітник може мати кілька дітей".
Справа наліво: "Кожна дитина зобов'язаний належати рівно одному співробітнику".


Приклад розробки простий ER-моделі

При розробці ER-моделей ми повинні отримати наступну інформацію про предметної області:



  1. Список сутностей предметної області.
  2. Список атрибутів сутностей.
  3. Опис взаємозв'язків між сутностями.

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

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

Наприклад, в ході бесіди з менеджером з продажу, з'ясувалося, що він (менеджер) вважає, що проектована система повинна виконувати наступні дії:


Виділимо всі іменники в цих пропозиціях – це будуть потенційні кандидати на сутності й атрибути, і проаналізуємо їх (незрозумілі терміни будемо виділяти знаком питання):


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

Рис. 7

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

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

Рис. 8

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


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

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

Точно також поступимо зі зв'язком, що з'єднує сутності "Склад" та "Товар". Введемо додаткову сутність "Товар на складі". Атрибутом цієї сутності буде "Кількість товару на складі". Таким чином, товар буде значитися на будь-якому складі і кількість його на кожному складі буде своє.

Тепер можна внести все це в діаграму:

Рис. 9


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

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

Рис. 10

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

Легко помітити, що отримані таблиці відразу знаходяться в 3НФ.


Висновки

Реальним засобом моделювання даних є не формальний метод нормалізації відносин, а так зване семантичне моделювання.

Як інструмент семантичного моделювання використовуються різні варіанти діаграм сутність-зв'язок (ER – Entity-Relationship).

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

Розрізняють концептуальні і фізичні ER-діаграми. Концептуальні діаграми не враховують особливостей конкретних СУБД. Фізичні діаграми будуються за концептуальним і являють собою прообраз конкретної бази даних. Сутності, визначені в концептуальній діаграмі стають таблицями, атрибути стають колонками таблиць (при цьому враховуються допустимі для даної СУБД типи даних і найменування стовпців), зв'язку реалізуються шляхом міграції ключових атрибутів батьківських сутностей і створення зовнішніх ключів.

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

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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*