Логічна та фізична моделі в erwin data modeler. Встановлення зв'язків між сутностями Що таке роль атрибуту в erwin

Створення сучасних інформаційних систем є найскладнішим завданням, вирішення якого вимагає застосування спеціальних методик та інструментів. Не дивно, що останнім часом серед системних аналітиків та розробників значно зріс інтерес до CASE (Computer-Aided Software/System Engineering) - технологій та інструментальних CASE-засобів, що дозволяють максимально систематизувати та автоматизувати всі етапи розробки програмного забезпечення.

Пропонована читачеві книга є практичним посібником зі створення інформаційних систем за допомогою ефективних інструментів аналізу, проектування та кодогенерації фірми PLATINUM technology - BPwin та ERwin. Вона містить також опис методів структурного аналізу та проектування моделей даних в обсязі, необхідному для практичної роботи. Застосування методів ілюструється прикладами.

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

Книга:

Зв'язок є логічним співвідношенням між сутностями. Кожен зв'язок має іменуватися дієсловом або дієслівною фразою (Relationship Verb Phrases) (рис. 2.20). Ім'я зв'язку висловлює деяке обмеження або бізнес-правило та полегшує читання діаграми, наприклад:

Кожен КЛІЄНТ <размещает> ЗАМОВЛЕННЯ;

Кожен ЗАМОВЛЕННЯ <выполняется> СПІВРОБІТНИКОМ.

Мал. 2.20. Ім'я зв'язку - Relationship Verb Phrases

Зв'язок показує, які замовлення розмістив клієнт і який саме співробітник виконує замовлення. За промовчанням ім'я зв'язку на діаграмі не відображається. Для відображення імені слід у контекстному меню, яке з'являється, якщо клацнути лівою кнопкою миші за будь-яким місцем діаграми, не зайнятим об'єктами моделі, вибрати пункт Display Options/Relationship і потім увімкнути опцію Verb Phrase.

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

У IDEF1X розрізняють залежні та незалежні сутності. Тип сутності визначається її зв'язком із іншими сутностями. Ідентифікуючий зв'язок встановлюється між незалежною (батьківський кінець зв'язку) та залежною (дочірній кінець зв'язку) сутностями. Коли малюється ідентифікуючий зв'язок, ERwin автоматично перетворює дочірню сутність у залежну. Залежна сутність зображується прямокутником із округленими кутами (сутність Замовлення на рис. 2.21). Примірник залежної сутності визначається лише через ставлення до батьківської сутності, тобто у структурі на рис. 2.21 інформація про замовлення не може бути внесена та не має сенсу без інформації про клієнта, який його розміщує. При встановленні ідентифікуючого зв'язку атрибути первинного ключа батьківської сутності автоматично переносяться до первинного ключа дочірньої сутності. Ця операція доповнення атрибутів дочірньої сутності під час створення зв'язку називається міграцією атрибутів. У дочірній сутності нові атрибути позначаються як ключ - (FK).

Мал. 2.21. Ідентифікуючий зв'язок між незалежною та залежною таблицею

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

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

Мал. 2.22. Неідентифікуючий зв'язок

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

Ідентифікуючий зв'язок показується на діаграмі суцільною лінією з жирною точкою на дочірньому кінці зв'язку (див. рис. 2.21), неідентифікуючий - пунктирний (рис. 2.22).

Для створення нового зв'язку слід:

встановити курсор на потрібній кнопці на панелі інструментів (ідентифікуючий або неідентифікуючий зв'язок) і натиснути ліву кнопку миші (рис. 2.2);

клацнути спочатку по батьківській, а потім по дочірній сутності.

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

На панелі інструментів кнопка

Відповідає ідентифікаційний зв'язок, кнопка

Зв'язки багато-багатьом і кнопка

Відповідають неідентифікуючий зв'язок.

Для редагування властивостей зв'язку слід "клікнути" правою кнопкою миші по зв'язку та вибрати на контекстному меню пункт Relationship Editor.

У закладці General діалогу, що з'явився, можна задати потужність, ім'я і тип зв'язку (рис. 2.23).

Потужність зв'язку (Cardinality) -служить для позначення відношення числа екземплярів батьківської сутності до екземплярів дочірньої.

Розрізняють чотири типи потужності (рис. 2.24):

загальний випадок, коли одному екземпляру батьківської сутності відповідають 0, 1 або багато екземплярів дочірньої сутності не позначається будь-яким символом;

символом Р позначається випадок, коли одному екземпляру батьківської сутності відповідають 1 або багато екземплярів дочірньої сутності (виключено нульове значення);

символом Z позначається випадок, коли одному примірнику батьківської сутності відповідають 0 або 1 екземпляр дочірньої сутності (виключені множинні значення);

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

Мал. 2.23. Діалог Relationship Editor

За промовчанням символ, що позначає потужність зв'язку, не відображається на діаграмі. Для відображення імені слід у контекстному меню, яке з'являється, якщо клацнути лівою кнопкою миші за будь-яким місцем діаграми, не зайнятим об'єктами моделі, вибрати пункт Display Options/Relationship і потім увімкнути опцію Cardinality.

Мал. 2.24. Позначення потужності

Тип зв'язку (ідентифікуючий/неідентифікуючий).Для неідентифікуючого зв'язку можна зазначити обов'язковість (Nulls). У разі обов'язкового зв'язку (No Nulls) при генерації схеми БД атрибут зовнішнього ключа отримає ознаку NOT NULL, незважаючи на те, що зовнішній ключ не увійде до первинного ключа дочірньої сутності. У разі необов'язкового зв'язку (Nulls Allowed) зовнішній ключ може набувати значення NULL. Необов'язковий зв'язок, що не ідентифікує, позначається прозорим ромбом з боку батьківської сутності (див. рис. 2.22).

Мал. 2.25. Закладка Rolename/RI Actions діалогу Relationship Editor

В закладці Definition можна дати більш повне визначення зв'язку для того, щоб надалі мати можливість посилатися на нього.

В закладці Rolename/RI Actions можна задати ім'я ролі та правила цілісності посилання.

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

Мал. 2.26. Імена ролей зовнішніх ключів

У прикладі, наведеному на рис. 2.26, по суті Співробітник зовнішній ключ Номер відділу має функціональне ім'я "Де працює", яке показує, яку роль грає цей атрибут по суті. За промовчанням у списку атрибутів відображається лише ім'я ролі. Для відображення повного імені атрибута (як функціонального імені, так і імені ролі) слід у контекстному меню, яке з'являється, якщо клацнути лівою кнопкою миші за будь-яким місцем діаграми, не зайнятим об'єктами моделі, вибрати пункт Display Options/Entities і потім увімкнути опцію Rolename/ Attribute (рис. 2.25). Повне ім'я відображається як функціональне ім'я та базове ім'я, розділені точкою (див. рис. 2.26).

Обов'язковим є застосування імен ролей у тому випадку, коли два або більше атрибутів однієї сутності визначені за однією і тією ж областю, тобто вони мають однакову область значень, але різний зміст. На рис. 2.27 сутність Продаж валюти містить інформацію про акт обміну валюти, у якому беруть участь дві валюти - продана та куплена. Інформація про валюти міститься по суті Валюта. Отже, сутності Продаж валюти і Валюта повинні бути пов'язані двічі та первинний ключ - Номер валюти повинен двічі мігрувати по суті Валюта як зовнішній ключ. Необхідно розрізняти ці атрибути, які містять інформацію про номер проданої та купленої валюти (мають різний зміст), але посилаються на ту саму сутність. Валюта (мають спільну область значень). У прикладі на рис. 2.27 атрибути отримали імена ролей Продана і Куплена.

Мал. 2.27. Випадок обов'язковості імен ролей

Іншим прикладом обов'язковості присвоєння імен ролей є рекурсивні зв'язки(іноді їх називають "рибальський гачок" - fish hook), коли одна і та ж сутність є і батьківською і дочірньою одночасно. При заданні рекурсивного зв'язку атрибут повинен мігрувати як зовнішній ключ до складу неключових атрибутів тієї ж сутності. Атрибут не може з'явитися двічі в одній сутності під одним ім'ям, тому обов'язково має отримати ім'я ролі. На рис. 2.26 сутність Співробітник містить атрибут первинного ключа Табельний номер. Інформація про керівника співробітника міститься у тій самій сутності, оскільки керівник працює у тій самій організації. Щоб послатися на керівника співробітника, слід створити рекурсивний зв'язок (на рис. 2.26 зв'язок керує/підпорядковується) і присвоїти ім'я ролі ("Керівник"). Зауважимо, що рекурсивний зв'язок може бути лише неідентифікуючим. В іншому випадку зовнішній ключ повинен був би увійти до складу первинного ключа і отримати при генерації схеми ознаку NOT NULL. Це унеможливило б побудова ієрархії - у дерева підпорядкованості має бути корінь - співробітник, який нікому не підпорядковується рамках цієї організації.

Зв'язок керує/підпорядковується на рис. 2.26 дозволяє зберігати деревоподібну ієрархію підпорядкованості працівників. Такий вид рекурсивного зв'язку називається ієрархічною рекурсією (hierarchical recursion)і задає зв'язок, коли керівник (примірник батьківської сутності) може мати безліч підлеглих (примірників дочірньої сутності), але підлеглий має лише одного керівника (рис. 2.28).

Ієрархічна рекурсія Мережева рекурсія

Мал. 2.28. Підпорядкованість екземплярів сутності в ієрархічній та мережній рекурсії

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

Мал. 2.29. Приклад реалізації мережевої рекурсії

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

Якщо атрибут мігрує як зовнішній ключ більш ніж один рівень, то першому рівні відображається повне ім'я зовнішнього ключа (ім'я ролі + базове ім'я атрибута), другою і більше - лише ім'я ролі. На рис. 2.30 зображено структуру даних, що містить сутність Команда, сутність Гравець, в якій зберігається інформація про гравців кожної команди, та сутність Гол, містить інформацію та голи, які забиває кожен гравець. Атрибут зовнішнього ключа Номер команди сутності Гравець має ім'я ролі "У якій команді грає".

Мал. 2.30. Міграція імен ролей

На наступному рівні, по суті Гол, відображається лише ім'я ролі відповідного атрибута зовнішнього ключа (У якій команді грає).

Правила цілісності посилання (referential integrity, RI) - логічні конструкції, які виражають бізнес-правила використання даних і являють собою правила вставки, заміни та видалення. При генерації схеми БД на основі опцій логічної моделі, що задаються в закладці Rolename/RI Actions, будуть згенеровані правила декларативної цілісності посилань, які повинні бути приписані для кожного зв'язку, і тригери, що забезпечують цілісність посилань. Тригери являють собою програми, що виконуються щоразу під час виконання команд вставки, заміни чи видалення (INSERT, UPDATE чи DELETE). На рис. 2.30 існує ідентифікуючий зв'язок між сутностями Команда і Гравець. Що буде, якщо видалити команду? Примірник сутності Гравець не може існувати без команди (атрибут первинного ключа У якій команді грає? Номер команди не може приймати значення NULL), отже, потрібно або заборонити видалення команди, поки в ній є хоча б один гравець (для видалення команди спочатку потрібно видалити всіх гравців), або відразу видаляти разом з командою всіх її гравців. Такі правила видалення називаються "обмеження" та "каскад" (Parent RESTRICT та Parent CASCADE, див. рис. 2.25). Зауважимо, що сутності Гравець і Гол, у свою чергу, теж пов'язані ідентифікуючим зв'язком і у разі видалення каскадом команди будуть видалені всі гравці команди та всі голи, які вони забивали. Виконання команди видалення одного рядка реально може призвести до видалення тисячі рядків у БД, тому використовувати правило видалення каскадом слід з обережністю. У випадку, якщо встановлено правило обмеження видалення, при спробі виконати видалення команди, в якій є хоча б один гравець, сервер реляційної СУБД поверне помилку.

На рис. 2.26 встановлено необов'язковий неідентифікуючий зв'язок між сутностями Відділ і Співробітник. Примірник сутності Співробітник може існувати без посилання на відділ (атрибут зовнішнього ключа Де працює. Номер відділу може набувати значення NULL). У цьому випадку можливе встановлення правила встановлення на нуль - SET NULL. При видаленні відділу атрибут зовнішнього ключа сутності Співробітник – Де працює. Номер відділу набуде значення NULL. Це означає, що при видаленні відділу співробітник залишається працювати в організації, не будучи приписаний до будь-якого відділу і інформація про нього зберігається.

Можливе встановлення ще двох правил видалення (якщо такі підтримуються СУБД):

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

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

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

Задати потужність зв'язку між сутностями Команда і Гравець, рівну "One or more" - 1 або більше (тип Р). Передбачається, що встановлено ідентифікуючий зв'язок.

Присвоїти дію RI-тригера "Parent Insert-CASCADE" для того, щоб при створенні нового рядка в таблиці Команда автоматично створювався хоча б один рядок у дочірній таблиці Гравець.

Присвоїти зв'язку дію RI-тригера "Parent Delete-CASCADE" для того, щоб при видаленні рядка з таблиці Команда відповідний рядок або рядки з таблиці Гравець теж віддалялися.

ERwin автоматично надає кожному зв'язку значення цілісності, що встановлюється за умовчанням, перш ніж додати її в діаграму. Режими RI, які присвоюються ERwin за умовчанням (наведені в табл. 2.4), можуть бути змінені в редакторі Referential Integrity Default, який викликається, якщо клацнути на кнопці RI Defaults діалогу Target Server (меню Server/Target Server).

Таблиця 2.4. Значення RI, що присвоюються в ERwin no замовчуванням, а також можливі ожижі для кожного типу зв'язку

Ідентифікуючий зв'язок	Неідентифікуючий зв'язок (Nulls Allowed)	Неідентифікуючий зв'язок (No Nulls)	Категоріальний зв'язок
Child Delete Можливі режими	RESTRICT, CASCADE, NONE	RESTRICT, CASCADE, NONE, SET NULL, SET DEFAULT		RESTRICT, CASCADE,
NONE
Child Delete Режими за замовчуванням	NONE	NONE	NONE	NONE
Child Insert Можливі режими	RESTRICT, CASCADE,		RESTRICT, CASCADE, NONE, SET DEFAULT	RESTRICT, CASCADE,
NONE	NONE
Child Insert Режими за замовчуванням	RESTRICT	SET NULL	RESTRICT	RESTRICT
Child Update Можливі режими	RESTRICT, CASCADE, NONE	RESTRICT, CASCADE, NONE, SET NULL, SET DEFAULT	RESTRICT, CASCADE, NONE, SET DEFAULT	RESTRICT, CASCADE, NONE
Child Update Стандартні режими	RESTRICT	SET NULL	RESTRICT	RESTRICT
Parent Delete Можливі режими	RESTRICT, CASCADE, NONE	RESTRICT, CASCADE, NONE, SET NULL, SET DEFAULT	RESTRICT, CASCADE, NONE, SET DEFAULT	RESTRICT, CASCADE,
NONE
Parent Delete Стандартні режими	RESTRICT	SET NULL	RESTRICT	CASCADE
Parent Insert Можливі режими	RESTRICT, CASCADE, NONE	RESTRICT, CASCADE, NONE, SET NULL, SET DEFAULT	RESTRICT, CASCADE, NONE, SET DEFAULT	RESTRICT, CASCADE, NONE
Parent Insert Стандартні режими	NONE	NONE	NONE	NONE
Parent Update Можливі режими	RESTRICT, CASCADE, NONE	RESTRICT, CASCADE, NONE, SET NULL, SET DEFAULT	RESTRICT, CASCADE, NONE, SET DEFAULT	RESTRICT, CASCADE, NONE
Parent Update Стандартні режими	RESTRICT	SET NULL	RESTRICT	CASCADE

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

Розглянемо цикл розробки з прикладу, наведеному у статті Кодда .
Коротко нагадаємо змістовну сторону завдання. Ведеться облік службовців. Для кожного службовця зберігається інформація про дітей і про список посад, що займалися цим службовцем. Для посад зберігається інформація щодо встановлених посадових окладів.
Спочатку створимо логічний рівень моделі. Для цього задамо режим відображення сутностей (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, вибравши кнопку на панелі інструментів.

Створення зв'язку.

На панелі інструментів кнопка відповідає ідентифікуючого зв'язку, кнопка зв'язку багато-багатьом і кнопка відповідає неідентифікуючого зв'язку. Для редагування властивостей зв'язку слід клацнути правою кнопкою миші і вибрати на контекстному меню пункт Relationship Editor.

У закладці General діалогу, що з'явився, можна задати потужність, ім'я і тип зв'язку.

Потужність зв'язку (Cardinality)- служить для позначення відношення числа екземплярів батьківської сутності до екземплярів дочірньої.

Розрізняють чотири типи потужності:

загальний випадок, коли одному примірнику батьківської сутності відповідають 0, 1 або багато екземплярів дочірньої сутності, не позначається будь-яким символом;

символом P позначається випадок, коли одному екземпляру батьківської сутності відповідають 1 або багато екземплярів дочірньої сутності (виключено нульове значення);

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

За промовчанням символ, що позначає потужність зв'язку, не відображається на діаграмі. Для відображення імені слід у контекстному меню, яке з'являється, якщо клацнути правою кнопкою миші на будь-якому місці діаграми, не зайнятому об'єктами моделі, вибрати пункт Display Options/Relationship і потім увімкнути опцію Cardinality.

Тип зв'язку (ідентифікуючий/неідентифікуючий).

Примірник залежної сутності визначається лише через ставлення до батьківської сутності. При встановленні ідентифікуючого зв'язку атрибути первинного ключа батьківської сутності автоматично переносяться до первинного ключа дочірньої сутності. Ця операція доповнення атрибутів дочірньої сутності під час створення зв'язку називається міграцією атрибутів. У дочірній сутності нові атрибути позначаються як ключі - (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. Мета роботи:освоєння принципів підготовки фізичної моделі даних для створення системного каталогу БД.

Лабораторна робота №3. Моделювання баз даних засобами Erwin

Мета роботи– набуття студентами практичних навичок створення логічних та фізичних моделей даних за допомогою CASE – засобів розробки інформаційних систем.

Основні відомості

Система ERwin підтримує пряме та зворотне моделювання баз даних. При прямому моделюванні схема бази даних описується у прямому вигляді з використанням діаграми сутність-зв'язок. Сутності на діаграмі є прямокутниками. Кожен прямокутник може мати різні візуальні атрибути. Кожній сутності має бути присвоєно унікальне ім'я. Імена сутностей необхідно ставити в однині. Це визначається тим, що система завжди оперує окремими екземплярами сутності. У цьому окремі екземпляри сутності розглядаються як об'єкти, а сутності – як об'єктів. Якщо сутності були описані при моделюванні в BPwin, їх можна просто імпортувати в ERwin. Приклад діаграми зі створеними сутностями наведено малюнку.

Рисунок 4 - Приклад діаграми із створеними сутностями

Побудова моделей у ERwin

Етапи побудови інформаційної моделі.

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

Створення сутності.

Кожна сутність має бути повністю визначена за допомогою текстового опису закладці Definition. Ці визначення корисні як на логічному рівні, оскільки дозволяють зрозуміти, що це за об'єкт, так і на фізичному рівні, оскільки їх можна експортувати як частину схеми та використовувати в реальній БД ( CREATE COMMENT on entity_name). Закладки Note, Note2, Note3, UDP (User Defined Properties – Властивості, визначені користувачем) служать для внесення додаткових коментарів та визначень до суті.

Створення атрибутів.

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

Малюнок 5 - Створення нового домену	Рисунок 6 - Вказівка властивостей нового домену

Малюнок 7 - Значення за замовчуванням для нового домену

Рисунок 8 - Використання домену для визначення типу даних атрибуту.

Для атрибутів первинного ключа у закладці General діалогу Attribute Editor необхідно зробити позначку у вікні вибору Primary Key.
Закладки Definition, Note і UDP несуть ті ж функції, що й щодо сутності, але рівні атрибутів.

Дуже важливо надати атрибуту правильне ім'я. Атрибути повинні іменуватися в однині і мати чітке значення.

Для створення нового зв'язку слід вибрати ідентифікуючий або неідентифікуючий зв'язок у панелі інструментів (ERwin Toolbox), клацнути спочатку батьківською, а потім дочірньою сутністю.
На панелі інструментів кнопка відповідає ідентифікуючого зв'язку, кнопка зв'язку багато-багатьом і кнопка відповідає неідентифікуючого зв'язку. Для редагування властивостей зв'язку слід клацнути правою кнопкою миші і вибрати на контекстному меню пункт Relationship Editor.

У закладці General діалогу, що з'явився, можна задати потужність, ім'я і тип зв'язку.

Потужність зв'язку (Cardinality)- служить для позначення відношення числа екземплярів батьківської сутності до екземплярів дочірньої.
Розрізняють чотири типи потужності:

· загальний випадок, коли одному примірнику батьківської сутності відповідають 0, 1 або багато екземплярів дочірньої сутності, не позначається будь-яким символом;

· Символом P позначається випадок, коли одному примірнику батьківської сутності відповідають 1 або багато екземплярів дочірньої сутності (виключено нульове значення);

· Символом Z позначається випадок, коли одному примірнику батьківської сутності відповідають 0 або 1 екземпляр дочірньої сутності (виключені множинні значення);

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

Тип зв'язку (ідентифікуючий/неідентифікуючий).

Створення ключів.

Кожен екземпляр сутності має бути унікальним і відрізнятися від інших атрибутів.

Альтернативний ключ (Alternative Key)- це потенційний ключ, який не став первинним.

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

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

Після вказівки всім атрибутам формату даних необхідно створену логічну модель перетворити на фізичну. Для цього необхідно в Toolsвибрати Derive New Model, де в якості Target Databases виберіть ODBC/Generic(Для використання в СУБД MySQL) див. Малюнок 9. Наша модель (див. Малюнок 4) буде перетворена до виду див. Малюнок 11.

Малюнок 9 - Перетворення логічної моделі на фізичну

Рисунок 10 – Фізична модель із зазначенням формату даних.

Малюнок 11 - Генерація коду SQL

Завдання

1. Виконайте побудову діаграми із заданими сутностями (пряме моделювання) для заданої предметної області.

2. Встановіть атрибути для кожної певної сутності. Використовуйте домени під час встановлення атрибутів.

3. Введіть зв'язок між сутностями. Надайте зв'язкам унікальні імена.

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

5. Звіт повинен містити концептуальну модель та фізичну базу даних у СУБД MYSQL.

Контрольні питання

1. У чому полягає відмінність логічного та фізичного рівнів представлення моделей даних за допомогою ERwin?

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

3. Які основні компоненти містять моделі даних, наведені за методологією IDEF1X?

Перелік типів даних, що підтримуються СУБД, необхідно уточнити у виробника

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

· Тип зв'язку (ідентифікуючий, неідентифікуючий, повна / неповна категорія, неспецифічний зв'язок);

· Батьківська сутність;

· Дочірня (залежна) сутність;

· Потужність зв'язку (cardinality);

· Допустимість порожніх (null) значень.

Зв'язок називається ідентифікуючим, якщо екземпляр дочірньої сутності ідентифікується через його зв'язок із батьківською сутністю. Атрибути, що становлять первинний ключ батьківської сутності, при цьому входять до первинного ключа дочірньої сутності. Дочірня сутність за ідентифікуючого зв'язку завжди є залежною.
Зв'язок називається неідентифікуючим, якщо екземпляр дочірньої сутності ідентифікується інакше, ніж через зв'язок із батьківською сутністю. Атрибути, що є первинним ключем батьківської сутності, при цьому входять до складу неключових атрибутів дочірньої сутності.
Для визначення зв'язків ERwin вибирається тип зв'язку, потім мишею вказується батьківська та дочірня сутність. Ідентифікуючий зв'язок зображується суцільною лінією; неідентифікуюча – пунктирною лінією. Лінії закінчуються точкою із боку дочірньої сутності.
При визначенні зв'язку відбувається міграція атрибутів первинного ключа батьківської сутності відповідну область атрибутів дочірньої сутності. Тому такі атрибути не запроваджуються вручну.
Атрибути первинного ключа батьківської сутності за умовчанням мігрують зі своїми іменами. ERwin дозволяє запровадити їм ролі, тобто. нові імена, під якими мігруючі атрибути будуть представлені у дочірній сутності. У разі неодноразової міграції атрибуту таке перейменування необхідне. Наприклад, сутність "посередницька угода" має атрибут "код підприємства-продавця" та "код підприємства-покупця". У разі первинний ключ сутності " підприємство " ( " код підприємства " ) має дві ролі у дочірній сутності.
Фізично ім'я ролі - це ім'я колонки зовнішнього ключа в дочірній таблиці.
Потужність зв'язку є відношенням кількості екземплярів батьківської сутності до відповідної кількості екземплярів дочірньої сутності. Для будь-якого зв'язку, крім неспецифічного, цей зв'язок записується як 1:n.
ERwin відповідно до методології IDEF1X надає 4 варіанти для n, які зображуються додатковим символом у дочірньої сутності: нуль, один або більше (за замовчуванням); нуль чи один; рівно N, де N – конкретне число.
Допустимість порожніх (NULL) значень у неідентифікуючих зв'язків ERwin зображує порожнім ромбиком на дузі зв'язку з боку батьківської сутності.
Позначення потужності відповідно нуль, один або більше, один або більше, нуль або один в нотації IE наведено на рис. 1.

Рис.1. Позначення потужності зв'язку в нотації IE

Ім'я зв'язку на логічному рівні є "дієсловом", що зв'язує сутності. Фізичне ім'я зв'язку (яке може відрізнятись від логічного) для ERwin означає ім'я обмеження (constraint) або індексу.