Зв'язок є логічним співвідношенням між сутностями. Кожна зв'язок має іменуватися дієсловом чи дієслівною фразою. Ім'я зв'язку висловлює певне обмеження чи бізнес-правило та полегшує читання діаграми. За промовчанням ім'я зв'язку на діаграмі не відображається. На логічному рівні можна встановити ідентифікуючий зв'язок "один-до-багатьом", зв'язок "багато-до-багатьох" і неідентифікуючий зв'язок "один-до-багатьом". Зв'язок - це поняття логічного рівня, якому відповідає зовнішній ключ фізично. У ERwin зв'язку представлені п'ятьма основними елементами інформації:
● тип зв'язку (ідентифікуючий, неідентифікуючий, повна/неповна категорія, неспецифічний зв'язок);
● батьківська сутність;
● дочірня (залежна) сутність;
● потужність зв'язку (cardinality);
● допустимість порожніх (null) значень.
У IDEFIX розрізняють залежні та незалежні сутності. Тип сутності визначається її зв'язком із іншими сутностями. Ідентифікуючий зв'язок встановлюється між незалежною (батьківською) та залежною (дочірньою) сутностями. Залежна сутність зображується прямокутником із округленими кутами. При встановленні ідентифікуючого зв'язку атрибути первинного ключа батьківської сутності автоматично переносяться до первинного ключа дочірньої сутності. Ця операція доповнення атрибутів дочірньої сутності під час створення зв'язку називається міграцією атрибутів. У дочірній сутності нові атрибути позначаються як ключ - FK.
При встановленні неідентифікуючого зв'язку дочірня сутність залишається незалежною, а атрибути первинного ключа батьківської сутності належать до неключових атрибутів дочірньої сутності. Неідентифікуючий зв'язок служить зв'язування незалежних сутностей. Для визначення зв'язків ERwin вибирається тип зв'язку, потім мишею вказується батьківська та дочірня сутність. Ідентифікуючий зв'язок зображується суцільною лінією; що не ідентифікує - пунктирною лінією. Лінії закінчуються точкою із боку дочірньої сутності.
Потужність зв'язків (Cardinality) - служить для позначення відношення числа екземплярів батьківської сутності до екземплярів дочірньої.
Розрізняють чотири типи сутності:
· загальний випадок, коли одному примірнику батьківської сутності відповідають 0, 1 або багато екземплярів дочірньої сутності; не позначається будь-яким символом;
· Символом Р позначається випадок, коли одному примірнику батьківської сутності відповідають 1 або багато екземплярів дочірньої сутності (виключено нульове значення);
· Символом Z позначається випадок, коли одному примірнику батьківської сутності відповідають 0 або 1 екземпляр дочірньої сутності (виключені множинні значення);
· Цифрою позначається випадок точної відповідності, коли одному примірнику батьківської сутності відповідає заздалегідь задане число примірників дочірньої сутності.
· Допустимість порожніх (NULL) значень в не ідентифікуючих зв'язках ERwin зображує порожнім ромбиком на дузі зв'язку з боку батьківської сутності.
Ім'я зв'язку на логічному рівні є дієсловом, що зв'язує сутності. Фізичне ім'я зв'язку (яке може відрізнятись від логічного) для ERWin означає ім'я обмеження або індексу. Для відображення імені зв'язку виберіть опцію в меню: Format/Relationship Display/Verb phrase.
Деякі сутності визначають цілу категорію об'єктів одного типу. У ERwin у разі створюється сутність визначення категорії й у кожного елемента категорії, та був вводиться їм зв'язок категоризації. Батьківська сутність категорії називається супертипом, а дочірні – підтипом.
Наприклад, сутність "вхідний документ" може бути як запитом, так і розпорядженням. Перші і другі мають різні набори атрибутів, що частково перетинаються (мінімальне перетинання підтипів становить первинний ключ). Загальна частина цих атрибутів, включаючи первинний ключ, міститься в сутність-супертип «вхідний документ». Різна частина (наприклад, дані про зміст, відправник) міститься в сутності-підтипи.
У сутності-супертипі вводиться атрибут-дискримінатор, що дозволяє розрізняти конкретні екземпляри сутності – підтипу.
Залежно від того, чи всі можливі сутності-підтипи включені в модель, категорійний зв'язок є повним або неповним.
Рисунок 1.4 - Приклад неповної множини категорій
Рисунок 1.5 - Приклад повної множини категорій
3. Сутність може бути загальною сутністю у будь-якій кількості відносин категоризації.
4. Атрибути первинного ключа сутності-категорії повинні збігатися з атрибутами первинного ключа загальної сутності.
5. Усі екземпляри сутності-категорії мають те саме значення дискримінатора, і всі екземпляри інших категорій повинні мати інші значення дискримінатора (див. рис. 4 і рис.5).
Ролі.
Ім'я ролі (функціональне ім'я) – це синонім атрибута зовнішнього ключа, який показує, яку роль грає атрибут у дочірній сутності. За промовчанням у списку атрибутів відображається лише ім'я ролі. Для відображення повного імені атрибута (як функціонального імені, так і імені ролі) слід у контекстному меню вибрати пункт Format/ Entity Display і потім увімкнути опцію Rolename/Attribute. Повне ім'я відображається як функціональне ім'я та базове ім'я, розділені точкою. Ім'я ролі задається на вкладці Rolename діалогового вікна Relationship. Це вікно викликається подвійним клацанням миші лінії зв'язку.
Обов'язковим є застосування імен ролей у тому випадку, коли два або більше атрибутів однієї сутності визначені по одній і тій самій області, тобто. вони мають однакову область значень, але різний зміст.
Уявлення.
Уявлення (view), чи, як їх іноді називають, тимчасові чи похідні таблиці, є об'єкти БД, дані у яких зберігаються постійно, як і таблиці, а формуються динамічно при зверненні до представлення. Уявлення неспроможна існувати саме собою, а визначається лише термінах однієї чи кількох таблиць. Застосування уявлень дозволяє розробнику БД забезпечити кожному користувачеві чи групі користувачів свій погляд на дані, що вирішує проблеми простоти використання та безпеки даних.
Розглянемо цикл розробки з прикладу, наведеному у статті Кодда .
Коротко нагадаємо змістовну сторону завдання. Ведеться облік службовців. Для кожного службовця зберігається інформація про дітей і про список посад, що займалися цим службовцем. Для посад зберігається інформація щодо встановлених посадових окладів.
Спочатку створимо логічний рівень моделі. Для цього задамо режим відображення сутностей (Display/Entity Level). Створимо з допомогою лінійки інструментів сутності " службовець " , " діти " , " історія роботи " , " історія зарплати " . Будемо називати сутності російською мовою.
Вибравши кожну сутність, задамо для неї докладний опис російською в редакторі "Entity Definition". Цей опис з'явиться у звітах ERwin і може відображатися на діаграмі.
Вкажемо зв'язок між сутностями. Наприклад, "службовець" пов'язаний ідентифікуючим зв'язком "є батьком" з сутністю "діти". Опис зв'язку вводиться у редакторі "Editor/Relationship".
Результат роботи відображено на діаграмі ERwin (рис. 2).
Мал. 2. Діаграма рівня сутності
Тепер перейдемо в режим завдання атрибутів (Display/Atribute Level). У редакторі "Entity/Attribute" задамо російською мовою імена ключових та неключових атрибутів. Зауважимо, що з дочірньої сутності " діти " ключовий атрибут " номер службовця " вказується вручну. ERwin забезпечує його міграцію із батьківської сутності. Те саме відбувається з іншими дочірніми сутностями.
Для атрибуту "ім'я" сутності "службовець" вкажемо, що він є альтернативним ключем (вважатимемо, що у всіх службовців унікальні імена/прізвища). Для цього після імені атрибута помістимо покажчик AK1 у дужках.
Результат роботи відображено на діаграмі ERwin (рис. 3) у нотації IDEF1X.
Мал. 3. Діаграма рівня атрибутів у нотації IDEF1X
Вигляд тієї ж діаграми в нотації IE (Information Engineering) показано на рис.4.
Мал. 4. Діаграма рівня атрибутів у нотації IE
Так як імена атрибутів і сутностей задавалися нами російською мовою, для переходу до фізичного рівня моделі слід поставити їм у відповідність ідентифікатори таблиць, колонок і обмежень, що задовольняють правила цільової СУБД (зазвичай це означає використання латинських літер, цифр і деяких спеціальних символів).
У редакторі "Database Schema" вказуємо для кожної сутності відповідне ім'я таблиці. Потім у редакторі "Attribute Definition" задаємо імена колонок таблиць, що відповідають атрибутам сутностей. ERwin і тут забезпечує міграцію імен колонок у підлеглі таблиці.
На цьому етапі можна скористатися і редактором Extended Attributes для визначення розширених атрибутів PowerBuilder (формату відображення, маски редагування, правила контролю, вирівнювання, заголовків та коментарів).
У редакторі " Relationship Definitions " вказується фізичне ім'я зв'язку, яке відповідає імені обмеження (constraint), створюваного ERwin у базі даних.
Тепер усе готове до створення БД і потрібно вибрати цільову СУБД (якщо цього не було зроблено раніше). Виберемо, наприклад, Sybase System 10.
У редакторі SYBASE Database Schema задаємо типи даних для колонок таблиць.
Діалог, у якому відбувається вибір типу даних, наведено на рис.5.
Мал. 5. Визначення фізичної моделі
Тепер можна перейти до створення бази даних. Для цього виконується команда Sybase schema generation. ERwin побудує пакет SQL-пропозицій для генерації бази даних. На рис.6 показаний діалог вибору параметрів генерації пакета для генерації БД. На малюнку видно, що може бути заданий фільтр (генерація не всіх таблиць), пакет SQL-пропозицій можна переглянути (preview), роздрукувати, зберегти файл (report), виконати генерацію (generate).
Мал. 6. Вибір параметрів створення бази даних
Розширені функції ERwin
Можливі дві точки зору на інформаційну модель і, відповідно, два рівні моделі. Перший - логічний рівень (точка зору користувача) означає пряме відображення фактів із реального життя. Наприклад, люди, столи, відділи, собаки та комп'ютери є реальними об'єктами. Вони називаються природною мовою, з будь-якими роздільниками слів (прогалини, коми і т.д.). Фізично моделі розглядається використання конкретної СУБД, визначаються типи даних (наприклад, ціле чи речове число), індекси для таблиць.
ERwin надає можливості створювати та керувати цими двома різними рівнями представлення однієї діаграми (моделі), так само як і мати багато варіантів відображення на кожному рівні. Термін "логічний рівень" у ERwin відповідає концептуальній моделі.
Етапи побудови інформаційної моделі:
· Визначення сутностей;
· Визначення залежностей між сутностями;
· Завдання первинних та альтернативних ключів;
· Визначення атрибутів сутностей;
· Приведення моделі до необхідного рівня нормальної форми;
· Перехід до фізичного опису моделі: призначення відповідностей ім'я сутності – ім'я таблиці, атрибут сутності – атрибут таблиці;
· Завдання тригерів, процедур та обмежень;
· генерація бази даних.
Erwin створює візуальне уявлення (модель даних) для розв'язуваного завдання. Це подання може використовуватися для детального аналізу, уточнення та розповсюдження документації, необхідної у циклі розробки. Однак ERwin не тільки інструмент для малювання. ERwin автоматично створює базу даних (таблиці, індекси, процедури, що зберігаються, тригери для забезпечення посилальної цілісності та інші об'єкти, необхідні для управління даними).
Створення сутності.
Для внесення сутності в модель необхідно клацнути по кнопці сутності на панелі інструментів (Erwin Toolbox), потім - по тому місцю діаграми, де необхідно розмістити нову сутність. Клацнувши правою кнопкою миші по суті та вибравши з спливаючого меню пункт Entity Editor, можна викликати діалог Entity Editor, у якому визначаються ім'я, опис та коментарі сутності.
Кожна сутність має бути повністю визначена за допомогою текстового опису закладці Definition. Ці визначення корисні як на логічному рівні, оскільки дозволяють зрозуміти, що це за об'єкт, так і на фізичному рівні, оскільки їх можна експортувати як частину схеми та використовувати в реальній БД (CREATE COMMENT on entity_name). Закладки Note, Note2, Note3, UDP (User Defined Properties – Властивості, визначені користувачем) служать для внесення додаткових коментарів та визначень до суті.
У закладці Icon кожної сутності можна поставити у відповідність зображення, яке відображатиметься в режимі перегляду моделі на рівні іконок та зображення, яке відображатиметься на всіх інших рівнях.
Закладка UDP діалогу Entity Editor служить визначення властивостей, визначених користувачем (User - Defined Properties). При натисканні кнопки цієї закладки викликається діалог User - Defined Property Editor (також викликається з меню Edit/UDPs). У ньому необхідно вказати вид об'єкта, для якого заводиться UDP (діаграма в цілому, сутність, атрибут і т.д.) та тип даних. Для внесення нової властивості слід клацнути в таблиці за кнопкою та внести ім'я, тип даних, значення за промовчанням та визначення.
Створення атрибутів
Для опису атрибутів слід, клацнувши правою кнопкою по суті, вибрати в меню пункт Attribute Editor. З'явиться діалог Attribute Editor.
Якщо клацнути по кнопці New, то в діалозі New Attribute, що з'явився, можна вказати ім'я атрибута, ім'я відповідної йому у фізичній моделі колонки і домен. Домен атрибута буде використовуватися для визначення типу колонки на рівні фізичної моделі.
Для атрибутів первинного ключа у закладці General діалогу Attribute Editor необхідно зробити позначку у вікні вибору Primary Key.
Закладки Definition, Note і UDP несуть ті ж функції, що й щодо сутності, але рівні атрибутів.
Для наочності діаграми кожен атрибут можна пов'язати з іконкою. Це можна зробити за допомогою списку вибору Icon у закладці General.
Дуже важливо надати атрибуту правильне ім'я. Атрибути повинні іменуватися в однині і мати чітке значення.
Згідно з синтаксисом IDEF1X, ім'я атрибута має бути унікальним у рамках моделі (а не лише в рамках сутності!). За замовчуванням при спробі внесення існуючого імені атрибута ERwin перейменовує його. Наприклад, якщо атрибут Коментар вже існує в моделі, інший атрибут (в іншій сутності) буде названий Коментар/2, потім Коментар/3 і т.д.
При перенесенні атрибутів усередині та між сутностями можна скористатися технікою drag&drop, вибравши кнопку на панелі інструментів.
Створення зв'язку.
Для створення нового зв'язку слід вибрати ідентифікуючий або неідентифікуючий зв'язок у панелі інструментів (ERwin Toolbox), клацнути спочатку батьківською, а потім дочірньою сутністю.
На панелі інструментів кнопка відповідає ідентифікуючого зв'язку, кнопка зв'язку багато-багатьом і кнопка відповідає неідентифікуючого зв'язку. Для редагування властивостей зв'язку слід клацнути правою кнопкою миші і вибрати на контекстному меню пункт Relationship Editor.
У закладці General діалогу, що з'явився, можна задати потужність, ім'я і тип зв'язку.
Потужність зв'язку (Cardinality)- служить для позначення відношення числа екземплярів батьківської сутності до екземплярів дочірньої.
Розрізняють чотири типи потужності:
загальний випадок, коли одному примірнику батьківської сутності відповідають 0, 1 або багато екземплярів дочірньої сутності, не позначається будь-яким символом;
символом P позначається випадок, коли одному екземпляру батьківської сутності відповідають 1 або багато екземплярів дочірньої сутності (виключено нульове значення);
символом Z позначається випадок, коли одному примірнику батьківської сутності відповідають 0 або 1 екземпляр дочірньої сутності (виключені множинні значення);
цифрою позначається випадок, коли одному примірнику батьківської сутності відповідає заздалегідь задане число примірників дочірньої сутності.
За промовчанням символ, що позначає потужність зв'язку, не відображається на діаграмі. Для відображення імені слід у контекстному меню, яке з'являється, якщо клацнути правою кнопкою миші на будь-якому місці діаграми, не зайнятому об'єктами моделі, вибрати пункт Display Options/Relationship і потім увімкнути опцію Cardinality.
Тип зв'язку (ідентифікуючий/неідентифікуючий).
У IDEF1X розрізняють залежні та незалежні сутності. Тип сутності визначається її зв'язком із іншими сутностями. Ідентифікуючий зв'язок встановлюється між незалежною (батьківський кінець зв'язку) та залежною (дочірній кінець зв'язку) сутностями. Коли малюється ідентифікуючий зв'язок, ERwin автоматично перетворює дочірній зв'язок у залежний. Залежна сутність зображується прямокутником із округленими кутами.
Примірник залежної сутності визначається лише через ставлення до батьківської сутності. При встановленні ідентифікуючого зв'язку атрибути первинного ключа батьківської сутності автоматично переносяться до первинного ключа дочірньої сутності. Ця операція доповнення атрибутів дочірньої сутності під час створення зв'язку називається міграцією атрибутів. У дочірній сутності нові атрибути позначаються як ключі - (FK).
При встановленні неідентифікуючого зв'язку дочірня сутність залишається незалежною, а атрибути первинного ключа батьківської сутності мігрують до складу неключових компонентів дочірньої. Неідентифікуючий зв'язок служить зв'язку незалежних сутностей.
Ідентифікуючий зв'язок показується на діаграмі суцільною лінією з жирною точкою на дочірньому кінці зв'язку, що не ідентифікує - пунктирною.
Для неідентифікуючого зв'язку можна вказати обов'язковість (Nulls в закладці General діалогу Relationship Editor). У разі обов'язкового зв'язку (No Nulls) при генерації схеми БД атрибут зовнішнього ключа отримає ознаку NOT NULL, незважаючи на те, що зовнішній ключ не увійде до первинного ключа дочірньої сутності. У разі необов'язкового зв'язку (Nulls Allowed) зовнішній ключ може набувати значення NULL. Необов'язковий неідентифікуючий зв'язок позначається прозорим ромбом з боку батьківської сутності
Ім'я зв'язку (Verb Phrase)- фраза, що характеризує відношення між батьківською та дочірньою сутностями. Для зв'язку однією з багатьох ідентифікуючих або неідентифікуючих достатньо вказати ім'я, що характеризує відношення від батьківської до дочірньої сутності (Parent-to-Child). Для зв'язку багатьом слід вказувати імена як Parent-to-Child, так і Child-to-Parent. Для відображення імені слід у контекстному меню, яке з'являється, якщо клацнути правою кнопкою миші на будь-якому місці діаграми, не зайнятому об'єктами моделі, вибрати пункт Display Options/Relationship і потім увімкнути опцію Verb Phrase.
Ім'я ролі або функціональне ім'я (Rolename)- це синонім атрибута зовнішнього ключа, який показує, яку роль грає атрибут у дочірній сутності. Задати ім'я ролі можна на вкладці Rolename/RI Actions діалогу Relationship Editor.
Рис.1. Імена ролей зовнішніх ключів
У прикладі, наведеному на рис. 1, по суті Співробітник зовнішній ключ Номер відділу має ім'я ролі "Де працює", яке показує, яку роль відіграє цей атрибут по суті. За промовчанням у списку атрибутів відображається лише ім'я ролі. Для відображення повного імені атрибута (як функціонального імені, так і імені ролі) слід у контекстному меню, яке з'являється, якщо клацнути правою кнопкою миші на будь-якому місці діаграми, не зайнятому об'єктами моделі, вибрати пункт Display Options/Entities і потім увімкнути опцію Rolename/ Attribute. Повне ім'я відображається як функціональне ім'я та базове ім'я, розділені точкою (рис. 1).
Обов'язковим є застосування імен ролей у тому випадку, коли два або більше атрибутів однієї сутності визначені по одній і тій самій області, тобто. вони мають ту саму область значень, але різний зміст.
Рис.2. Випадок обов'язковості імен ролей
На рис.2 сутність Продаж валюти містить інформацію про акт обміну валюти, у якому беруть участь дві валюти - продана і куплена. Інформація про валюти міститься власне Валюта. Отже, сутність продажу валюти і валюти повинні бути пов'язані двічі, і первинний ключ - номер валюти повинен двічі мігрувати в сутність валюти як зовнішній ключ. Необхідно розрізняти ці атрибути, які містять інформацію про номер проданої та купленої валюти (мають різний зміст), але посилаються на ту саму сутність Валюта (мають загальну область значень). У прикладі на рис.2 атрибути отримали імена ролей Продана та Куплена.
Іншим прикладом обов'язкового застосування імен ролей є рекурсивні зв'язки, коли та сама сутність є і батьківської і дочірньої одночасно.
Правила цілісності посилання (Referential Integrity (RI))- логічні конструкції, які виражають бізнес-правила використання даних і є правилами вставки, заміни та видалення. Задати правила цілісності посилання можна в закладці Rolename/RI Actions діалогу Relationship Editor.
При генерації схеми БД на основі опцій логічної моделі будуть згенеровані правила декларативної цілісності посилань, які повинні бути приписані для кожного зв'язку, і тригери, що забезпечують цілісність посилань.
Рис.3. Міграція імен ролей
На рис.3 існує ідентифікуючий зв'язок між сутностями Команда та Гравець. Що буде, якщо видалити команду? Екземпляр сутності Гравець не може існувати без команди (атрибут первинного ключа У якій команді грає? Номер командине може приймати значення NULL), отже потрібно або заборонити видалення команди, поки в ній числиться хоча б один гравець, або видаляти разом із командою та всіх її гравців. Такі правила видалення (Parent Delete) називаються Parent Restrict (обмеження) та Parent Cascade (каскад). Сутності Гравець і Гол, у свою чергу, теж пов'язані ідентифікуючим зв'язком і якщо на видалення гравця накладено правило каскадного видалення всіх записів про його голи, то при видаленні команди будуть видалені всі гравці команди і всі голи, забиті цими гравцями.
Зв'язок багатьом можливий тільки на рівні логічної моделі даних. Такий зв'язок позначається суцільною лінією із двома точками на кінцях. Для внесення зв'язку слід спочатку натиснути кнопку на панелі інструментів (ERwin Toolbox), а потім по черзі клацнути по обох пов'язаних сутностях.
Зв'язок багато-багатьом має іменуватися (Verb Phrase) двома фразами - в обидві сторони. Це полегшує читання діаграми.
Створення ключів.
Кожен екземпляр сутності має бути унікальним і відрізнятися від інших атрибутів.
Первинний ключ (primary key)- це атрибут або група атрибутів, які однозначно ідентифікують екземпляр сутності. Атрибути первинного ключа на діаграмі не вимагають спеціального позначення - це атрибути, які знаходяться в списку атрибутів вище горизонтальної лінії. При внесенні нового атрибута в діалозі Attribute Editor для того, щоб зробити його атрибутом первинного ключа, потрібно увімкнути прапорець Primary Key у нижній частині закладки General. На діаграмі ключового атрибута можна внести до складу первинного ключа, скориставшись режимом перенесення атрибутів (кнопка на панелі інструментів).
В одній сутності може бути кілька атрибутів або наборів атрибутів, які претендують на роль первинного ключа. Такі претенденти називаються потенційними ключами (candidate key).
Ключі може бути складними, тобто. містять кілька атрибутів. Складні первинні ключі не вимагають спеціального позначення - це список атрибутів вище за горизонтальну лінію. При виборі первинного ключа перевага має надаватися простішим ключам, тобто. ключів, що містять меншу кількість атрибутів.
Багато сутностей мають лише один потенційний ключ. Такий ключ стає первинним. Деякі сутності можуть мати більше одного можливого ключа. Тоді один із них стає первинним, а решта - альтернативними ключами.
Альтернативний ключ (Alternative Key)- це потенційний ключ, який не став первинним.
Кожному ключу відповідає індекс, ім'я якого також надається автоматично. Імена ключа та індексу за бажання можна змінити вручну.
На діаграмі атрибути альтернативних ключів позначаються як (Akn.m.), де n – порядковий номер ключа, m – порядковий номер атрибута в ключі. Коли альтернативний ключ містить кілька атрибутів (Akn.m.) ставиться після кожного.
Рис.4. Сутність "Співробітник" з відображенням ключів
Зовнішні ключі (Foreign Key)створюються автоматично, коли зв'язок з'єднує сутності: зв'язки утворюють посилання на атрибути первинного ключа дочірньої сутності і ці атрибути утворюють зовнішній ключ дочірньої сутності (міграція ключа). Атрибути зовнішнього ключа позначаються символом (FK) після імені (рис.4). Атрибути зовнішнього ключа Де працює. Номер відділу ("Де працює" - ім'я ролі) сутності Співробітник є атрибутом первинного ключа (PK) по суті Відділ.
Залежна сутність може мати той самий ключ із кількох батьківських сутностей. Сутність може також отримати один і той самий зовнішній ключ кілька разів від одного і того ж батька через кілька різних зв'язків. Коли ERwin виявляє одну з цих подій, він розпізнає, що два атрибути однакові і поміщає атрибути зовнішнього ключа в залежній сутності лише один раз. Це комбінування чи поєднання ідентичних атрибутів називається уніфікацією.
Є випадки, коли уніфікація є небажаною. Наприклад, коли два атрибути мають однакові імена, але насправді вони відрізняються за змістом, і необхідно, щоб ця відмінність відображалася в діаграмі. І тут необхідно використовувати імена ролей зовнішнього ключа (рис.2).
Домени.
Домен можна визначити як сукупність значень, у тому числі беруться значення атрибутів. Кожен атрибут може бути визначений лише одному домені, але кожному домені може бути визначено безліч атрибутів. У поняття домену входить як тип даних, а й область значень даних. Наприклад, домен "Вік" можна визначити як позитивне ціле число і визначити атрибут "Вік співробітника", який належить до цього домену.
У ERwin домен може бути визначений лише один раз і використовуватись як у логічній, так і у фізичній моделі.
На логічно домени можна описати без конкретних фізичних властивостей. Фізично вони отримують специфічні властивості, які можна змінити вручну. Так, домен "Вік" може мати логічно тип Number, фізично домену буде присвоєний тип INTEGER.
Для створення домену у логічній моделі служить діалог Domain Dictionary Editor. Його можна викликати з меню Edit/Domain Dictionary за кнопкою, розташованою у верхній лівій частині закладки General діалогу Attribute Editor. Для створення нового домену в діалозі Domain Dictionary Editor слідує:
· Клацнути по кнопці New. З'являється діалог New Domain;
· Вибрати батьківський домен зі списку Domain Parent. Новий домен можна створити на основі вже створеного користувачем домену, або на основі існуючого. За замовчуванням Erwin має чотири визначені домени (String, Number, Blob, Datetime). Новий домен успадковує всі властивості батьківського домену. Ці властивості надалі можна перевизначити;
· Набрати ім'я домену в полі Logical Name. Можна також вказати ім'я домену фізично в полі Physical Name. Якщо фізичне ім'я не вказано, за умовчанням воно набуває значення логічного імені;
· Клацнути по кнопці OK;
У діалозі Domain Dictionary Editor можна зв'язати домен з іконкою, з якою він відображатиметься в списку доменів (Domain Icon), іконкою, з якою атрибут, визначений на домені, буде відображатися в моделі (Icon Inherited by Attribute).
Кожен домен може бути описаний в закладці Definition, з коментарем в закладці Note або властивістю певним користувачем в закладці UDP.
ERwin має спеціальний інструмент, який значно полегшує створення нових атрибутів у моделі, використовуючи опис доменів - Independent Attribute Browser. Цей діалог викликається (і ховається) за гарячим ключем CTRL+B. З його допомогою можна вибрати в списку домен і методом drag&drop перенести його в будь-яку сутність. У ній буде створено новий атрибут з ім'ям, яке слід встановити у вікні Name Inherited by Attribute діалогу Domain Dictionary Editor. Якщо значення поля не встановлено, за промовчанням приймається ім'я домену.
Фізично діалог Domain Dictionary Editor дозволяє редагувати фізичні властивості домену. Назва закладки залежить від вибраного сервера бази даних. На ній можна задати конкретний тип даних, що відповідають домену, правила надання NULL - значень, правила валідації (правила перевірки допустимих значень) та завдання значення за замовчуванням. Правила валідації та значення за промовчанням мають бути попередньо описані та іменовані. Для виклику діалогів редагування правил валідації та значень за промовчанням служать кнопки праворуч від відповідного списку вибору (Valid та Default).
Функції інших закладок діалогу Domain Dictionary Editor:
General.Завдання батьківського домену (Domain Parent) та імені, що присвоюється колонці під час її створення за допомогою Independent Column Browser. За допомогою опції Phisical Only домен можна визначити лише на рівні фізичної моделі.
Comment.Внесення коментарів до атрибуту.
UDP. Властивості, що визначаються користувачем.
Visual Basic- PowerBuilder. Завдання спеціальних властивостей домену для кодогенерації клієнтської програми.
Завдання виконання.
На основі раніше створеної функціональної моделі та опису предметної області створити логічну модель з використанням пакету ERwin.
Лабораторна робота №7.
Основи роботи у Erwin. Підготовка фізичної моделі даних для створення БД
1. Мета роботи:освоєння принципів підготовки фізичної моделі даних для створення системного каталогу БД.
Опис інтерфейсу ERwin.Інтерфейс CASE - засоби ERwin складається з трьох основних частин. Перша - це головне меню та панелі інструментів.
Кнопки на панелі інструментів повторюють деякі основні команди у головному меню. Зберегти, відкрити, створити новий файл, панель з кнопками збільшення або зменшення масштабу відображення моделі, перемикач між фізичною та логічною моделлю, перемикач між збереженими відображеннями, панель для редагування стилю, розміру та кольору шрифтів, панель з інструментами для побудови геометричних фігур та кілька допоміжних панелей інструментів (рис. 5.3).
Мал. 5.3.
Друга – це Model Explorer. Вона містить три закладки: Model, Subject Areas та Domains. Найчастіше в Model Explorer застосовується закладка Domains або Model (яка містить усі об'єкти та моделі). У Domains відображаються відповідно домени, в Subject Areas - області, що відображаються (рис. 5.4).
Мал. 5.4.
І третя - безпосередньо область, відведена до створення моделі об'єктів, у якій створюються і редагуються все об'єкти моделі. Знизу з'являються закладки з іменами запам'ятованих збережених відображень (Stored Displays) (рис. 5.5).
Мал. 5.5.
ERwin має два рівні представлення даних моделі: логічний та фізичний. Логічний рівень- це абстрактний погляд на дані, на ньому дані подаються так, як виглядають у реальному світі, наприклад, «Замовник», «Цех» або «Прізвище співробітника». Об'єкти моделі, що подаються на логічному рівні, називаються сутностями та атрибутами. Логічна модель даних може бути побудована на основі іншої логічної моделі, наприклад, моделі процесів. Логічна модель даних є універсальною і не пов'язана з конкретною реалізацією СУБД.
Фізична модельданих, навпаки, залежить від конкретної СУБД, фактично як відображення системного каталогу. У фізичній моделі міститься інформація про всі об'єкти БД. Оскільки стандартів на об'єкти БД немає (наприклад, немає стандарту типи даних), фізична модель залежить від конкретної реалізації СУБД. Отже, однієї й тієї ж логічної моделі можуть відповідати кілька різних фізичних моделей. Якщо в логічній моделі не має значення, який конкретно тип даних має атрибут, то у фізичній моделі важливо описати всю інформацію про конкретні фізичні об'єкти - таблиці, колонки, індекси, процедури і т. д. Поділ моделі на логічні та фізичні дозволяє вирішити багато важливих задач.
ERwin має кілька рівнів відображення діаграми: рівень сутностей, рівень атрибутів, рівень визначень, рівень первинних ключів та рівень ікон. Переключитися між першими трьома рівнями можна за допомогою кнопок панелі інструментів. Переключитися на інші рівні відображення можна за допомогою контекстного меню, яке з'являється, якщо «клікнути» за будь-яким місцем діаграми, не зайнятим об'єктами моделі. У контекстному меню слід вибрати пункт Display Level, а потім необхідний рівень відображення. ERwin дозволяє пов'язати з сутністю велику та малу іконки. При перемиканні на рівень іконок відображається велика іконка. Для відображення малої іконки слід вибрати пункт Entity Display/Entity Icon у контекстному меню. Маленька іконка буде показана зліва від імені сутності на всіх рівнях відображення моделі.
Встановлення кольору та шрифту.Встановити шрифт та колір об'єктів у ERwin можна кількома способами. По-перше, для встановлення кольору та шрифту об'єкта служить Font and Color Toolbar, яка знаходиться під основною панеллю. Для редагування шрифту та кольору конкретного об'єкта слід, клацнувши правою кнопкою миші по суті або зв'язку та вибравши з спливаючого меню пункт Object Font & Color..., викликати діалог Font/Color Editor, у якому визначаються ім'я, опис та коментарі сутності. У діалозі Font/Color Editor можна вибрати шрифт і встановити його розмір, стиль та колір, встановити колір заливки (властивість Fill Color, тільки для сутностей) та колір ліній (властивість Outline Color, тільки для сутностей).
При створенні реальних моделей даних кількість сутностей та атрибутів може обчислюватися сотнями. Для зручнішої роботи з великими моделями в ERwin передбачені підмножини моделі (Subject Areas),які можна включити тематично загальні сутності. До підмножини моделі може входити довільний набір сутностей, зв'язків та текстових коментарів. Для створення, видалення або редагування підмножин моделі потрібно викликати діалог Subject Areas (меню Model/Subject Areas...), в якому вказується ім'я підмножини та сутності, що входять до неї. Усі зміни, зроблені у будь-якій Subject Area, автоматично відображаються на загальній моделі. Одна й та сама сутність може входити у кілька Subject Area.
Зберігання (Stored Display)- Подання підмножини моделі, що відображає специфічний аспект структури даних. Одна Subject Area може включати кілька збережених відображень. У відображення, що зберігається, входять ті ж самі сутності і зв'язки, що і в Subject Area, але вони можуть по-різному розташовуватися на екрані, мати різні рівні, різний масштаб і колір об'єктів або фону.
Для створення відображення, що зберігається, служить діалог Stored Displays (меню Format/Stored Display Settings ...). Для перемикання між відображеннями, що зберігаються, служать закладки в нижній частині діаграми.
Основні компоненти діаграми ERwin – це сутності, атрибути та зв'язки. Кожна сутність є безліччю подібних індивідуальних об'єктів, званих екземплярами. Кожен екземпляр індивідуальний і має відрізнятися від решти екземплярів. Атрибут виражає певну властивість об'єкта. З погляду БД (фізична модель) сутності відповідає таблиця, екземпляру сутності - рядок у таблиці, а атрибуту - колонка таблиці.
Створення логічної моделі даних предметної області «Меблі на замовлення».Створювана логічна модель повторює структуру проектованої ІВ. Для того щоб створити сутність в області для створення моделей об'єктів, необхідно (переконавшись попередньо, що ви знаходитесь на рівні логічної моделі: перемикачем між логічною і фізичною моделлю служить список, що розкривається, в правій частині панелі інструментів) «клікнути» по кнопці сутності на панелі інструментів ( ERwin Toolbox) Q , потім "клікнути" по тому місцю на діаграмі, де необхідно розмістити нову сутність. Клацнувши правою кнопкою миші по суті та вибравши з спливаючого меню пункт Entity Properties..., можна викликати діалог Entities, у якому визначаються ім'я, опис та коментарі сутності (наприклад, ім'я сутності – постачальник, опис – дані про постачальника). Кожна сутність визначається за допомогою текстового опису закладці Definition. Закладки Note, Note 2, Note 3, UDP (User Defined Properties – Властивості, визначені користувачем) служать для внесення додаткових коментарів до суті. Наступним кроком є створення атрибутів сутності. Як було зазначено вище, кожен атрибут зберігає інформацію про певну властивість сутності, а кожен екземпляр сутності має бути унікальним. Атрибут або група атрибутів, що ідентифікують суть, називається первинним ключем. Для створення атрибутів слід, «клікнувши» правою кнопкою по суті, вибрати в меню пункт Attributes.... З'являється діалог Attributes. Якщо клацнути по кнопці New..., то в діалозі New Attribute, що з'явився, вказуємо ім'я атрибута, ім'я відповідної йому у фізичній моделі колонки і домен (наприклад, ім'я атрибута - найменування постачальника). Домен атрибута буде використовуватися для визначення типу колонки на рівні фізичної моделі. Для атрибутів первинного ключа у закладці General діалогу Attributes необхідно зробити позначку у вікні вибору Primary Key.
Для відображення іконки атрибута слід вибрати в контекстному меню пункт Entity Display та у каскадному меню увімкнути опцію Attribute Icon. Мінімальна іконка буде показана зліва від імені атрибута на рівні атрибутів відображення моделі. Ім'я сутності показується над прямокутником, що зображає сутність, список атрибутів сутності – усередині прямокутника. Список розділений горизонтальною рисою, вище за яку розташовані атрибути первинного ключа, нижче - неключові атрибути. Атрибути повинні іменуватися в однині і мати чітке значення. Дотримання цього правила дозволяє частково вирішити проблему нормалізації даних на етапі визначення атрибутів. Наприклад, створення по суті Постачальник атрибута Телефони постачальника суперечить вимогам нормалізації, оскільки атрибут має бути атомарним, тобто не містити множинних значень. Згідно з синтаксисом IDEF1X ім'я атрибута має бути унікальним у рамках моделі (а не тільки в рамках сутності!). Кожен екземпляр сутності має бути унікальним і відрізнятися від інших атрибутів. Наступним кроком створення моделі є встановлення зв'язків між сутностями. Кожен зв'язок має іменуватися дієсловом або дієслівною фразою (Relationship Verb Phrases рис. 5.6). Ім'я зв'язку висловлює деяке обмеження або бізнес-правило та полегшує читання діаграми, наприклад:
Кожен ЗАМОВНИК ЗАМОВЛЕННЯ;
Кожен ЗАМОВЛЕННЯ ДИЗАЙН.
Мал. 5.В.Ім'я зв'язку - Relationship Verb Phrases
Для створення нового зв'язку слід:
- встановити курсор на потрібній кнопці на панелі інструментів (ідентифікуючий або неідентифікуючий зв'язок) і натиснути ліву кнопку миші;
- клацнути спочатку по батьківській, а потім по дочірній сутності. При встановленні зв'язків між сутностями атрибути первинного ключа батьківської сутності мігрують як зовнішні ключі в дочірню сутність. За промовчанням ім'я зв'язку на діаграмі не відображається. Для відображення імені слід у контекстному меню, яке з'являється, якщо клацнути лівою кнопкою миші за будь-яким місцем діаграми, не зайнятим об'єктами моделі, вибрати пункт Relationship Display та в контекстному меню увімкнути опцію Verb Phrase.
Логічна модель даних предметної області «Меблі на замовлення» наведено на рис. 5.7.
Мал. 5.7.
Повна атрибутивна модель представляє дані у третій нормальній формі і включає всі сутності атрибути та зв'язку та представлена на рис. 5.8.
На рівні сутностей модель представлена на рис. 5.9.
На рис. 5.10 представлено модель даних на рівні визначень.
Мал. 5.8.
Мал. 5.Е.Рівень сутності моделі даних
Зв'язок - це функціональна залежність між двома сутностями (зокрема, можливий зв'язок сутності із самою собою). Наприклад, важливо знати прізвище співробітника і не менш важливо знати, в якому відділі він працює. Таким чином, між сутностями "відділ" та "співробітник" існує зв'язок "складається з" (відділ складається зі співробітників). Зв'язок - це поняття логічного рівня, якому відповідає зовнішній ключ фізично. У ERwin зв'язку представлені п'ятьма основними елементами інформації:
· Тип зв'язку (ідентифікуючий, неідентифікуючий, повна / неповна категорія, неспецифічний зв'язок);
· Батьківська сутність;
· Дочірня (залежна) сутність;
· Потужність зв'язку (cardinality);
· Допустимість порожніх (null) значень.
Зв'язок називається ідентифікуючим, якщо екземпляр дочірньої сутності ідентифікується через його зв'язок із батьківською сутністю. Атрибути, що становлять первинний ключ батьківської сутності, при цьому входять до первинного ключа дочірньої сутності. Дочірня сутність за ідентифікуючого зв'язку завжди є залежною.
Зв'язок називається неідентифікуючим, якщо екземпляр дочірньої сутності ідентифікується інакше, ніж через зв'язок із батьківською сутністю. Атрибути, що є первинним ключем батьківської сутності, при цьому входять до складу неключових атрибутів дочірньої сутності.
Для визначення зв'язків ERwin вибирається тип зв'язку, потім мишею вказується батьківська та дочірня сутність. Ідентифікуючий зв'язок зображується суцільною лінією; неідентифікуюча – пунктирною лінією. Лінії закінчуються точкою із боку дочірньої сутності.
При визначенні зв'язку відбувається міграція атрибутів первинного ключа батьківської сутності відповідну область атрибутів дочірньої сутності. Тому такі атрибути не запроваджуються вручну.
Атрибути первинного ключа батьківської сутності за умовчанням мігрують зі своїми іменами. ERwin дозволяє запровадити їм ролі, тобто. нові імена, під якими мігруючі атрибути будуть представлені у дочірній сутності. У разі неодноразової міграції атрибуту таке перейменування необхідне. Наприклад, сутність "посередницька угода" має атрибут "код підприємства-продавця" та "код підприємства-покупця". У разі первинний ключ сутності " підприємство " ( " код підприємства " ) має дві ролі у дочірній сутності.
Фізично ім'я ролі - це ім'я колонки зовнішнього ключа в дочірній таблиці.
Потужність зв'язку є відношенням кількості екземплярів батьківської сутності до відповідної кількості екземплярів дочірньої сутності. Для будь-якого зв'язку, крім неспецифічного, цей зв'язок записується як 1:n.
ERwin відповідно до методології IDEF1X надає 4 варіанти для n, які зображуються додатковим символом у дочірньої сутності: нуль, один або більше (за замовчуванням); нуль чи один; рівно N, де N – конкретне число.
Допустимість порожніх (NULL) значень у неідентифікуючих зв'язків ERwin зображує порожнім ромбиком на дузі зв'язку з боку батьківської сутності.
Позначення потужності відповідно нуль, один або більше, один або більше, нуль або один в нотації IE наведено на рис. 1.
Рис.1. Позначення потужності зв'язку в нотації IE
Ім'я зв'язку на логічному рівні є "дієсловом", що зв'язує сутності. Фізичне ім'я зв'язку (яке може відрізнятись від логічного) для ERwin означає ім'я обмеження (constraint) або індексу.
