НОУ ІНТУЇТ | лекція | Метод моделювання "сутність-зв'язок"

1. Графічна нотація моделі: діаграми "сутність-зв'язок"

Графічна нотація моделі: діаграми "сутність-зв'язок"

Типовою формою документування логічної моделі предметної області при ER-моделюванні є діаграми "сутність-зв'язок", або ER-діаграми (Entity Relationship Diagram). ER-діаграма дозволяє графічно представити всі елементи логічної моделі згідно простим, інтуїтивно зрозумілим, але строго певним правилам - нотаціям.

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

• Integration DEFinition for Information Modeling (IDEF1X). Ця нотація була розроблена для армії США і стала федеральним стандартом США. Крім того, вона є стандартом в ряді міжнародних організацій (НАТО, Міжнародний валютний фонд та ін.).
• Information Engineering (IE). Нотація, розроблена Мартіном (Martin), Фінкельштейном (Finkelstein) і іншими авторами, використовується переважно в промисловості.

Побудова ER-діаграм, як правило, ведеться з використанням CASE-засобів. У даній лекції у всіх прикладах, якщо це не обумовлено, буде використовуватися нотація MS Office Visio 2007.

В прямокутнику перераховуються атрибути сутності, при цьому атрибути, складові унікальний ідентифікатор сутності, підкреслюються ( Мал. 6.4 ).

Кожен екземпляр сутності повинен бути унікальним і відрізнятися від інших атрибутів. Одним з основних комп'ютерних способів розпізнавання сутностей в ІС є присвоєння сутностям ідентифікаторів (entity identifier). Оскільки сутність визначається набором своїх атрибутів, для кожної сутності доцільно виділити таку підмножину атрибутів, яке однозначно ідентифікує дану сутність. Часто ідентифікатор сутності називають первинним ключем (primary key).

Первинний ключ (primary key) - це атрибут або група атрибутів, однозначно ідентифікує екземпляр сутності. Атрибути первинного ключа на діаграмі не вимагають спеціального позначення - це ті атрибути, які знаходяться в списку атрибутів вище горизонтальної лінії ( Мал. 6.3 ).

Вибір первинного ключа може виявитися непростим завданням, рішення якої в змозі вплинути на ефективність майбутньої ІС. В одній сутності можуть виявитися кілька атрибутів або наборів атрибутів, які претендують на роль первинного ключа. Такі претенденти називаються потенційними ключами (candidate key).

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

Розглянемо кандидатів на первинний ключ сутності "співробітник" ( Мал. 6.5 ).

Тут можна виділити наступні потенційні ключі.

1. Табельний номер.
2. Номер паспорта.
3. Прізвище + Ім'я + батькові.

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

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

Компактність. Складний можливий ключ не повинен містити жодного атрибута, видалення якого не приводило б до втрати унікальності. Для забезпечення унікальності ключа (Прізвище + Ім'я + батькові) доповнимо його атрибутами Дата народження і Колір очей. Якщо бізнес-правила говорять, що поєднання атрибутів Прізвище + Ім'я + батькові + Дата народження досить для однозначної ідентифікації співробітника, то Колір очей виявляється зайвим, т. Е. Ключ Прізвище + Ім'я + батькові + Дата народження + Колір очей не є компактним.

При виборі первинного ключа перевага повинна віддаватися більш простим ключам, т. Е. Ключам, що містить меншу кількість атрибутів. У прикладі ключі № 1 і № 2 краще ключа № 3.

Атрибути ключа не повинні містити нульових значень. Якщо допускається, що співробітник може не мати паспорта або замість паспорта мати будь-яке інше посвідчення особи, то ключ № 2 не підійде на роль первинного ключа. Якщо для забезпечення унікальності необхідно доповнити потенційний ключ додатковими атрибутами, то вони не повинні містити нульових значень. При доповненні ключа № 3 атрибутом Дата народження потрібно переконатися в тому, що дати народження відомі для всіх співробітників.

Значення атрибутів ключа не повинно змінюватися протягом усього часу існування екземпляра сутності. Співробітниця організації може вийти заміж і змінити як прізвище, так і паспорт. Тому ключі № 2 і 3 не підходять на роль первинного ключа.

Кожна сутність повинна мати, принаймні, один потенційний ключ. Багато сутностей мають тільки один потенційний ключ. Такий ключ стає первинним. Деякі суті можуть мати більше одного можливого ключа. Тоді один з них стає первинним, а інші - альтернативними ключами. Альтернативний ключ (Alternate Key) - це потенційний ключ, який не став первинним.

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

Домени призначаються аналітиками і фіксуються в спеціальному документі - словнику даних (Data Dictionary). При створенні логічної моделі домени можуть бути специфіковані в сутності на ER-діаграмі.

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

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

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

• для реалізації реляційного ХД потрібно використовувати реляційну або об'єктно-реляційну СУБД, наприклад, MS SQL Server 2008;
• в більшості реляційних СУБД в якості мови маніпулювання і опису даних використовується SQL, що підтримує певні стандарти, наприклад, ANSI SQL-92.

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

В MS Office Visio ім'я зв'язку, ступінь зв'язку (потужність) і клас приналежності сутності до зв'язку визначається на вкладці "Властивості бази даних", як показано на Мал. 6.7 . Стрілка на лінії зв'язку вказує на батьківську таблицю.

При виділенні зв'язків акцент робиться на виявлення їх характеристик. Зв'язок є взаємовідношення між двома або більше сутностями. Кожна зв'язок реалізується через значення атрибутів сутностей, наприклад, екземпляр сутності "Співробітник" ( Мал. 6.6 ) Пов'язаний з екземпляром сутності "Освіта" за однаковими значеннями атрибутів Табельний номер. Іншими словами, при створенні зв'язку в одній з сутностей, званої дочірньої сутністю, створюється новий атрибут, званий зовнішнім ключем (Foreign Key, FK) (на Мал. 6.6 це атрибут Табельний номер). Іноді атрибути зовнішнього ключа позначаються символом (FK) після свого імені.

Зв'язок є логічним співвідношенням між сутностями. Кожна зв'язок має іменуватися дієсловом або дієслівної фразою Ім'я зв'язку (Verb Phrase) - фраза, що характеризує відношення між батьківської та дочірньої сутностями. Ім'я зв'язку висловлює деяке обмеження або бізнес-правило і полегшує читання діаграми. на Мал. 6.8 показано привласнення зв'язку імені.

Існують різні типи зв'язків: ідентифікує зв'язок (identifying relationship) "один до багатьох", зв'язок "багато до багатьох" і неідентіфіцірующей зв'язок (non-identifying relationship) "один до багатьох". З типами зв'язків пов'язують і різні типи сутностей.

Розрізняють два типу сутностей: залежні (Dependent entity) і незалежні (Independent entity). Тип суті визначається її зв'язком з іншими сутностями. Идентифицирующая зв'язок встановлюється між незалежною (батьківський кінець зв'язку) і залежною (дочірній кінець зв'язку) сутностями.

Примірник залежною суті визначається тільки через ставлення до батьківської сутності, т. Е. В структурі на Мал. 6.8 інформація про спеціальності не може бути внесена і не має сенсу без інформації про співробітника, який має спеціальність за дипломом про освіту. При встановленні ідентифікує зв'язку (на малюнку безперервна лінія) атрибути первинного ключа батьківської суті автоматично переносяться до складу первинного ключа дочірньої сутності (безперервна лінія). Ця операція доповнення атрибутів дочірньої суті при створенні зв'язку називається міграцією атрибутів. У дочірньої сутності такий атрибут вважається зовнішнім ключем.

Якщо модель створюється за допомогою CASE-засобів, то при генерації схеми БД атрибути первинного ключа отримають ознака NOT NULL, що означає неможливість внесення запису в таблицю "Співробітники" без інформації про табельний номер співробітника.

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

Примірник сутності "Співробітник" може існувати безвідносно до будь-якого екземпляру сутності "Відділ", т. Е. Співробітник може працювати в організації і не числиться в будь-якому відділі.

Идентифицирующая зв'язок показується на діаграмі суцільною лінією з жирною крапкою на дочірньому кінці зв'язку (див. Мал. 6.8 ), Неідентіфіцірующей - пунктирною (див. Мал. 6.9 ).

Зв'язок "багато до багатьох" (many-to-many relationship) може бути створена тільки на рівні логічної моделі. на Мал. 6.10 показаний приклад визначення зв'язку "багато до багатьох". Лікар може приймати багато пацієнтів, пацієнт може лікуватися у кількох лікарів. Такий зв'язок позначається суцільною лінією з двома стрілочками на кінцях.

Зв'язок "багато до багатьох" повинна іменуватися двома фразами - в обидві сторони (в прикладі "приймає / лікується"). Це полегшує читання діаграми. зв'язок на Мал. 6.10 слід читати так: Лікар <приймає> Пацієнта, Пацієнт <лікується> у Лікаря.

Як було зазначено вище, зв'язку визначають, чи є сутність незалежної або залежної. Розрізняють декілька типів залежних сутностей.

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

Асоціативна - сутність, пов'язана з декількома батьківськими сутностями. Така сутність містить інформацію про зв'язки сутностей.

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

Категоріально - дочірня сутність в ієрархії успадкування.

Ієрархія наслідування (subtype relationship), або ієрархія категорій, являє собою особливий тип об'єднання сутностей, які поділяють спільні характеристики. Наприклад, в організації працюють службовці, зайняті повний робочий день (штатні службовці), і сумісники. З їхніх спільних властивостей можна сформувати узагальнену сутність (родовий предок) "Співробітник" (див. Мал. 6.11 ), Щоб представити інформацію, загальну для всіх типів службовців. Специфічна для кожного типу інформація може бути розташована в категоріальних сутності (нащадках) "Штатний співробітник" і "Сумісник".

Зазвичай ієрархію спадкування створюють, коли кілька сутностей мають загальні за змістом атрибути або коли сутності мають загальні за змістом зв'язку (наприклад, якби "Штатний співробітник" і "Сумісник" мали подібну за змістом зв'язок "працює в" з сутністю "Організація"), або коли це диктується бізнес-правилами.

Для кожної категорії можна вказати дискримінатор (discriminator) - атрибут родового предка, який показує, як відрізнити одну категоріальну сутність від іншої (атрибут Тип на Мал. 6.11 ).

Ієрархії категорій діляться на 2 типу - повні і неповні. Повною ієрархії категорій (Complete subtype relationship) одному примірнику родового предка (сутність "Співробітник", Мал. 6.12 ) Обов'язково відповідає екземпляр в будь-якому нащадку, т. Е. В цьому прикладі службовець обов'язково є або сумісником, або консультантом, або постійним співробітником.

Якщо категорія ще не вибудувана повністю і в родовому предка можуть існувати екземпляри, які не мають відповідних примірників в нащадках, то така категорія буде неповною (Incomplete subtype relationship). на Мал. 6.11 показана неповна категорія - співробітник може бути не тільки постійним або сумісником, а й консультантом, однак сутність "Консультант" ще не внесена в ієрархію наслідування.

на Мал. 6.12 показаний приклад повної категорії.

Повна категорія позначається символом , Неповна - .

Можлива комбінація повної і неповної категорій. Крім постійних співробітників і сумісників можуть бути і консультанти, які можуть бути не відображені в ієрархії (неповна категорія), але кожен постійний співробітник або чоловік, або жінка (повна категорія).

Розглянемо можливі стадії побудови ієрархії успадкування.

1. Визначення сутностей із загальними (за визначенням) атрибутами.

   Припустимо, в процесі проектування створені суті "Штатний співробітник" і "Сумісник" ( Мал. 6.13 ). Можна помітити, що частина атрибутів у цих сутностей (Прізвище, Ім'я, По батькові, Дата народження, посада) має однаковий сенс.

   
   Мал. 6.13. Сутності з загальними за змістом атрибутами
2. Перенесення загальних атрибутів в сутність - родовий предок. У разі виявлення співпадаючих за змістом атрибутів слід створити нову сутність "Співробітник" - родовий предок, і перенести в неї загальні атрибути (Прізвище, Ім'я, По батькові, Дата народження, посада).
3. Створення неповної структури категорій. Створюється категоріальна зв'язок від нової сутності - родового предка до старих сутностей-нащадкам. Нова сутність доповнюється атрибутом - дискримінатором категорії (Тип) (див. Мал. 6.11 ).
4. Створення повної структури категорій. Проводиться додатковий пошук сутностей, що мають спільні за змістом атрибути з родовим предком. У прикладі це сутність "Консультант" ( Мал. 6.14 ).
   Мал. 6.14. Додаткова сутність із загальними за змістом атрибутами Загальні атрибути переносяться в родового предка, і категорія перетворюється в повну. Сутність "Консультант" не має атрибута Посада, тому в родовому предка значення цього атрибута в разі консультанта буде NULL. Залежно від бізнес-правил атрибут Посада може бути перенесений назад з родового предка по суті-нащадки "Штатний співробітник" і "Сумісник".
5. Комбінації повної і неповної структур категорій. При необхідності створення ієрархії категорій можна продовжити. Для кожного нащадка може знайтися сутність із загальними атрибутами, тоді сутність-нащадок стає родовим предком для нових нащадків і т. Д.