Зв'язок один до багатьох erwin. Основи роботи у Erwin. Побудова логічної моделі даних. Завдання правил валідації

02.05.2022

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

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

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

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

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

Побудова моделей у 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 (діаграма в цілому, сутність, атрибут і т.д.) та тип даних. Для внесення нової властивості слід клацнути в таблиці за кнопкою та внести ім'я, тип даних, значення за промовчанням та визначення.

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

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

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

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

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

Для опису атрибутів слід, клацнувши правою кнопкою по суті, вибрати в меню пункт 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.

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

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

Первинний ключ (primary key)- це атрибут або група атрибутів, які однозначно ідентифікують екземпляр сутності. Атрибути первинного ключа на діаграмі не вимагають спеціального позначення - це атрибути, які знаходяться в списку атрибутів вище горизонтальної лінії. При внесенні нового атрибута в діалозі Attribute Editor для того, щоб зробити його атрибутом первинного ключа, потрібно увімкнути прапорець Primary Key у нижній частині закладки General. На діаграмі ключового атрибута можна внести до складу первинного ключа, скориставшись режимом перенесення атрибутів (кнопка на панелі інструментів).

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

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

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

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

Кожному ключу відповідає індекс, ім'я якого також надається автоматично. Імена ключа та індексу за бажання можна змінити вручну.

На діаграмі атрибути альтернативних ключів позначаються як (Akn.m.), де n – порядковий номер ключа, m – порядковий номер атрибута в ключі. Коли альтернативний ключ містить кілька атрибутів (Akn.m.) ставиться після кожного.

Зовнішні ключі (Foreign Key)створюються автоматично, коли зв'язок з'єднує сутності: зв'язки утворюють посилання на атрибути первинного ключа дочірньої сутності і ці атрибути утворюють зовнішній ключ дочірньої сутності (міграція ключа). Атрибути зовнішнього ключа позначені символом (FK) після свого імені.

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

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

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

Після вказівки всім атрибутам формату даних необхідно створену логічну модель перетворити на фізичну. Для цього необхідно в 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?

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

6. Моделювання в ERwin

Місце ERwin в інформаційному моделюванні
Процес побудови інформаційної моделі складається з наступних кроків:

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

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

Відображення логічного та фізичного рівня моделі даних у ERwin

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

Компоненти діаграми ERwin та основні види уявлень діаграми

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

Режим "сутності" – усередині прямокутників відображається ім'я сутності (для логічної моделі) або ім'я таблиці (для фізичного подання моделі); служить для зручності огляду великої діаграми чи розміщення прямокутників сутностей діаграмі.
Режим визначення сутності служить для презентації діаграми іншим людям.
Режим "атрибути". При переході від предметної області до моделі потрібно вводити інформацію, що становить сутність. Ця інформація вводиться шляхом завдання атрибутів (фізично - колонок таблиць). У цьому режимі прямокутник-сутність ділиться лінією на дві частини - у верхній частині відображаються атрибути (колонки), що становлять первинний ключ, а в нижній - інші атрибути. Цей режим є основним під час проектування на логічному та фізичному рівнях.
Режим "первинні ключі" - усередині прямокутників - сутностей показуються лише атрибути/колонки, що становлять первинний ключ.
Режим "піктограми". Для презентаційних цілей кожної таблиці може бути поставлена у відповідність піктограма (bitmap).
Режим "показ дієслівної фрази". На дугах зв'язків з'являються дієслівні фрази, що пов'язують сутності (для логічного рівня) або імена зовнішніх ключів (для фізичного рівня).

Діаграма може займати більш ніж один екран і більше одного листа під час друку. Для огляду моделі передбачені, крім прокручування екрана, режими зменшення/збільшення зображення, відображення всієї моделі, відображення виділеної частини моделі.

Інструменти для створення моделі в ERwin

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

редактори, пов'язані з сутністю в цілому (визначення сутності, додаткова інформація, тригери, індекси, характеристики таблиці, процедури, що зберігаються, пов'язані з таблицею);
редактори атрибутів (визначення атрибутів, колонки таблиці у фізичному поданні моделі, репозитарій засобу 4GL, наприклад, розширені атрибути PowerBuilder).

Ідентифікація сутностей. Сутності у ERwin

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

атрибути, що становлять первинний ключ;
неключові атрибути;
тип сутності (незалежна/залежна).

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

Зв'язки (relationships) у ERwin

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

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

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

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

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

Графічне редагування моделі

Усі об'єкти моделі ERwin можуть редагуватися засобами, прийнятими у Windows - угруповання, копіювання, видалення, переміщення, використання системного буфера. Установка кольорів та шрифтів здійснюється у зручних діалогах.
Компоненти моделі, представлені текстом (імена сутностей, атрибутів, текстові елементи), можуть редагуватися безпосередньо на екрані.

Альтернативні ключі

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

Інвертовані індекси

Атрибути, що становлять альтернативний ключ, однозначно (унікально) ідентифікують екземпляри сутності. У ERwin можна також складати групи атрибутів, які не ідентифікують унікально екземпляри сутності, але часто використовуються для доступу до даних. Для кожної групи атрибутів ERwin створює неунікальні індекси.
Одні й самі атрибути сутності можуть входити у кілька різних груп ключів.

Уніфікація атрибутів

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

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

Реалізація цілісності посилання за допомогою ERwin

Посилочна цілісність - це забезпечення вимоги, щоб значення зовнішнього ключа екземпляра дочірньої сутності відповідали значенням первинного ключа батьківської сутності. Цельність посилань може контролюватись при всіх операціях, що змінюють дані (INSERT/UPDATE/DELETE). Засоби контролю цілісності посилання в ERwin включають автоматичну генерацію тригерів і використання механізмів декларативної цілісності посилання (для тих СУБД, які підтримують дані механізми).
Для кожного зв'язку на логічному рівні можуть бути задані вимоги щодо обробки операцій INSERT/UPDATE/DELETE для батьківської та дочірньої сутності. ERwin представляє такі варіанти обробки цих подій:

відсутність перевірки;
перевірка допустимості;
заборона операції;
каскадне виконання операції (DELETE/UPDATE);
встановлення порожнього (NULL-значення) або заданого значення за промовчанням.

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

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

Тип перевизначення вказується розробником при генерації схеми бази даних (рис. 6 відповідно RI Type Override, Relationship Override, Entity Override).

Зберігання інформації у моделі ERwin

Зазвичай моделі ERwin зберігаються на диск як файла. Є можливість зберігати модель цільової СУБД. Для цього за допомогою самого ERwin цільової СУБД створюється метабаза ERwin. У цій базі даних зберігається інформація про модель. В окремому випадку базою даних можуть бути і dBase-файли, з якими ERwin працює через ODBC.

Приклад розробки моделі в ERwin

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

7. Розширені функції ERwin

Зворотне проектування (Reverse engineering)

Зворотне проектування, тобто відновлення інформаційної моделі по існуючій базі даних, використовується при виборі оптимальної платформи (rightsizing) для існуючої настільної (desktop) бази даних або бази даних на mainframe, а також при розширенні (або модифікації) існуючої структури, яка була побудована без необхідної супровідної документації. Після завершення процесу відновлення моделі ERwin автоматично "розкладає" таблиці на діаграмі. Тепер можна виконувати модифікації вже з використанням логічної схеми – додавати сутності, атрибути, коментарі, зв'язки тощо. Після завершення змін одна команда – синхронізувати модель із базою даних – актуалізує всі проведені зміни.
Побудова моделі може бути виконана як на підставі даних каталогу бази даних, так і на основі пакета операторів SQL, за допомогою якого було створено базу даних.

Синхронізація з базою даних

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

Рис. 7. Вибір таблиць, що синхронізуються

ERwin "знає" про такі особливості зберігання даних в окремих СУБД, як сегменти (Sybase) і табличний простір (Oracle). Інформація про фізичне розміщення може бути включена в модель та використана при прямому та зворотному проектуванні.

Інтерфейси до СУБД

ERwin підтримує прямий інтерфейс з основними СУБД: DB2 версії 2 та 3, Informix версій 5.1, 6.0, 7.1, Ingres, NetWare SQL, ORACLE версій 6 та 7, Progress, Rdb версій 4 та 6, SQL/403 версій 2 версій 5 та 6, SQL Server версій 4 та 6, Sybase версії 4.2, Sybase System 10 та 11, Watcom SQL. Зазначимо, що підтримуються як найсучасніші, і попередні версії основних СУБД (рис.8).

Рис. 8. Вибір СУБД для створення моделі

ERwin підтримує також настільні (desktop) СУБД: Microsoft Access, FoxPro, Clipper, dBASE III, dBASE IV та Paradox.
Проектування фізично виконується в термінах тієї бази даних, яку передбачається використовувати в системі. Важливо, що ERwin "відомі" відповідності між можливостями СУБД різних виробників, унаслідок чого можливе перетворення фізичної схеми, спроектованої однієї СУБД, в іншу.
Для створення фізичної структури БД може бути запитана генерація DDL-скрипту (data definition language). При цьому використовується діалект SQL для вибраного типу та версії сервера. Хоча згенерований код не потребує модифікації, є можливість зберегти його у файл або роздрукувати.

Підтримка коштів 4GL

ERwin випускається у кількох різних редакціях, орієнтованих найбільш поширені кошти розробки 4GL. Серед засобів, що підтримуються - PowerBuidler фірми Powersoft, SQL Windows фірми Gupta, Visual Basic фірми Microsoft, Oracle*CASE фірми Oracle.
Засоби двонаправленої взаємодії ERwin з базою даних забезпечують керування інформацією, орієнтованою як на серверну, так і клієнтську частину. Наприклад, для PowerBuilder можна переглядати/редагувати розширені атрибути у редакторах ERwin.
Орієнтація ERwin на кошти 4GL дозволяє задати для майбутніх програм більшість параметрів, безпосередньо пов'язаних з базою даних, вже на стадії проектування інформаційної моделі.
Покажемо принципи організації такої взаємодії з прикладу PowerBuilder.
PowerBuilder створює у базі даних кілька внутрішніх таблиць для зберігання свого репозитарію (розширених атрибутів для datawindow). Використання розширених атрибутів гарантує збереження стилю відображення одних і тих самих колонок бази даних для всіх програм, створюваних робочою групою. У розширених атрибутах задаються такі параметри, як формат відображення, стиль редагування, перевірка на коректність, початкове значення, вирівнювання, ширина і висота елемента відображення, мітка для форми редагування, заголовок для табличного відображення.
Для розширених атрибутів допустимі самі операції синхронізації, як і для всієї моделі, тобто описи можуть бути завантажені в базу даних і, навпаки, створені з середовища PowerBuilder описи розширених атрибутів можуть бути завантажені з бази даних в ERwin для модифікації.
Приклад визначення розширених атрибутів показано на рис.9.

Рис. 9. Завдання розширених атрибутів PowerBuilder

Функція ERwin за генерацією DataWindow дозволяє згенерувати прототипи вікон даних майбутнього додатка вже на стадії створення інформаційної моделі. Для створення Data Windows пропонується Wizard, за допомогою якого вказується стиль вікна та вибрані стовпчики таблиць.

Рис. 2. Діаграма рівня сутності

Рис. 3. Діаграма рівня атрибутів у нотації IDEF1X

Вигляд тієї ж діаграми в нотації IE (Information Engineering) показано на рис.4.

Рис. 4. Діаграма рівня атрибутів у нотації IE

Рис. 5. Визначення фізичної моделі

Рис. 6. Вибір параметрів створення бази даних

Розширені функції ERwin

Лабораторна робота №5

Мета роботи:

Завдання:

Послідовність виконання роботи

Знайомство з інтерфейсом користувача

· Завантажте програму Erwin.

· У діалоговому вікні, що з'явилося, встановіть перемикач Create а New Model.На екрані з'явиться діалог Create Model – Select Template,де необхідно вибрати рівень моделювання.

Erwin має два рівні моделювання: логічний та фізичний. на логічномуДані рівні видаються так, як вони виглядають в реальному світі. Об'єктами логічного рівня є сутності та атрибути.

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

· Встановіть перемикач Logical/Physicalдля створення моделі з логічним та фізичним рівнями.

· У полях DataBaseі Versionвказується тип та версія сервера, для якого створюється модель. Виберіть у списку Access, 2000. Натисніть кнопку ОК.

· На екрані з'явиться головне вікно програми.

У верхній частині вікна знаходиться титульний рядок, в якому вказано назву програми, найменування моделі, найменування підмножини (Subject Area) та відображення, що зберігається (Stored Display). Основну частину простору програми займає робоча область, де створюється ER-діаграма.

Для перемикання між логічним та фізичним рівнями на панелі інструментів є список (рис. 1.1).

Крім цього списку на панелі інструментів є кнопки (див. табл. 1.1).

Таблиця 1.1.

Кнопки на панелі інструментів програми Erwin

Кнопка	Призначення
	Створення, відкриття, збереження та друк моделі
	Виклик діалогу Report Browser для створення звітів
	Зміна рівня перегляду моделі: рівень сутності, рівень атрибутів, рівень визначень
	Зміна масштабу перегляду моделі
	Генерація схеми БД, вирівнювання схеми з моделлю та вибір сервера (доступні лише на рівні фізичної моделі)
	Перемикання між областями моделі Subject Area

Для безпосередньої роботи з елементами моделі в програмі є палітра інструментів (Erwin Toolbox), що є плаваючим віконцем (рис. 1.2). При необхідності панель інструментів можна прибирати з екрана та викликати натисканням комбінації клавіш «CTRL-T».

Рис. 1.2. Палітра інструментів на логічному рівні

Внесення до моделі сутностей

На даному етапі необхідно внести до моделі такі сутності, виявлені в результаті аналізу предметної галузі (постачання товару відповідно до договорів): покупець, договір, накладна, товар, склад.

· Виберіть на панелі інструментів (ERwin Toolbox) кнопку Сутність,Клацнувши по ній покажчиком миші. Потім клацніть мишкою по тому місцю на діаграмі, де необхідно розмістити нову сутність. На полі діаграми з'явиться прямокутник, що зображує нову сутність, з автоматично згенерованим ім'ям "Е/1".

· Введіть з клавіатури ім'я сутності « Покупець" і натисніть Enter.

· Так само вставте в діаграму ще чотири сутності: договір, накладна, товар, склад.

· Клацнувши правою кнопкою миші по суті та вибравши з контекстного меню пункт Entity Properties, можна викликати редактор сутностей Entities(Рис. 1.6), який дозволяє змінювати властивості обраної сутності. Редактор сутностей можна також викликати через головне меню: Model | Entities.

Рис. 1.6. Редактор сутності

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

Нижче у вікні редактора міститься ряд закладок:

Definition(Визначення) – на цій сторінці вводиться визначення сутності.

Note, Note2, Note3(Примітка) – використовуються для введення довільного тексту, пов'язаного з сутністю, наприклад, зразки даних та запити.

UDP- Визначаються користувачем властивості.

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

· Для кожної сутності введіть визначення Definition.

Ключові групи

· Викличте редактор ключових груп Key Groups,клацнувши правою кнопкою миші по суті Покупецьта вибравши з контекстного меню пункт Key Groups. Редактор ключових груп можна також викликати через головне меню: Model | Key Groups.

Редактор ключових груп містить елементи керування:

Entity– поле зі списком, в якому слід вибрати сутність для редагування.

Вікно із переліком ключових груп.Кожна група представлена окремим рядком, що включає ім'я (Key Group), тип (Type) і визначення (Definition).

Крім того, діалогове вікно редактора ключових груп містить такі закладки:

ü Members (члени).Задаються члени ключових груп та їх порядок прямування у групі.

ü General (загальні установки).Перемикачі, які дають змогу задавати тип ключової групи. Для первинного та зовнішнього ключа ці групи недоступні.

ü Definition (Визначення).Довільна текстова інформація, що стосується обраної ключової групи.

ü Note (Примітка).Примітка до вибраної групи.

ü UDP (користувацькі властивості).

· Натисніть кнопку New.

· У вікні New Key Groupв полі Key Groupвведіть ім'я ключової групи – ІПН. В полі Indexвиводиться ім'я індексу, що генерується програмою Erwin. Залишіть його без змін.

· Перемикач Key Group Typeзадає тип створюваного ключа. Це може бути альтернативний ключ (Alternate Key) або інверсний вхід (Inversion Entry). Виберіть Alternate Keyі натисніть ОК. Новий альтернативний ключ з'явиться в списку ключів.

Перейдіть на закладку Members. Новий ключ поки не містить жодних атрибутів, тому правий список Key Group Members(Члени ключової групи) порожній. Виберіть у лівому списку атрибут ІПНта перемістіть його у правий список за допомогою кнопки зі стрілкою (див. мал. 1.8).

Рис. 1.8. Редактор ключових груп

· Так само створіть ключові групи для інверсних входів, наведених у табл. 1.3.

Лабораторна робота №6

Завдання правил декларативної цілісності посилань

· Перебуваючи на логічномуНа рівні моделі даних, виділіть зв'язок «укладає» між сутностями Покупець і Договір, клацнувши по ній покажчиком миші. Потім натисніть праву кнопку миші та в контекстному меню виберіть пункт Relationship Properties(Редактор зв'язків).

· У вікні редактора зв'язків Relationshipперейдіть на вкладку RI Actions. Ознайомтеся з правилами цілісності зв'язку «Покупець – Договір», присвоєними за умовчанням. Дані установки забороняють вставку та зміну екземпляра дочірньої сутності, а також видалення та зміну батьківської сутності. Це означає, що не допускається видалення або зміна покупця, якщо у базі даних є укладені з ним договори, а також введення договору без вказівки покупця або з посиланням на неіснуючого покупця. Тим самим ми виконали умову, за якою договір може існувати лише для конкретного покупця.

· Проаналізуйте встановлені правила цілісності посилання для всіх інших зв'язків.

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

Нормалізація даних

З моделі видно, що По суті Покупець присутній множинний атрибут ТЕЛ. Покупець може мати кілька телефонних номерів, що є порушенням першої нормальної форми, за якою всі значення атрибутів мають бути атомарними. Тому необхідно виділити атрибут ТІЛ в окрему сутність.

· Створіть сутність Телефон, що містить такі атрибути: КОД_ТЕЛ (первинний ключ, тип – number) та ТЕЛ (тип – string).

· Зв'яжіть сутності Покупець та Телефон ідентифікуючим зв'язком. Встановіть потужність зв'язку One or More (P)та введіть ім'я зв'язку – має.

Вибір сервера

· Виконайте команду Database | Choose Database.

· У діалоговому вікні Erwin/ERX – Target Serverнеобхідно задати тип сервера - Accessта його версію – 2000 . Крім того, тут вказується тип даних, що використовується за умовчанням, і умова NULL для новостворених колонок. Деякі параметри діалогового вікна залежать від вибраного типу сервера.

· Після вибору сервера натисніть кнопку ОК.

Денормалізація даних

На моделі є два зв'язки типу «багато-багатьом»: Товар – Договір та Товар – Накладна, які мають бути дозволені фізично. Результат дозволу даних зв'язків наведено в табл. 2.1.

Таблиця 2.1.

Результат дозволу зв'язків «багатьом-багатьом»

Дозвіл зв'язків «багатьом-до-багатьом» здійснюється автоматично при переході на фізичний рівень, або за допомогою спеціального майстра Багато Relationship Transform Wizard.

· Для виклику даного майстра виділіть зв'язок «Товар – Договір», клацнувши по ньому покажчиком миші. Потім натисніть праву кнопку миші та в контекстному меню виберіть пункт Create Association Table(Створити асоціативну таблицю). На екрані з'явиться перший діалог майстра, який містить текст призначення.

· Введіть у поле Table Name(ім'я таблиці) - Постачання_План. В полі Table Comment(Коментарі до таблиці) введіть текст: Відомості про постачання товару за договором.

· На моделі з'явилася нова таблиця Поставка_План, пов'язана ідентифікуючим зв'язком з таблицями Товар та Договір.

· Нову таблицю необхідно доповнити трьома колонками (див. табл. 2.1). Для цього виділіть таблицю Постачання_План, клацнувши по ньому покажчиком миші. Потім натисніть праву кнопку миші та в контекстному меню виберіть пункт Columns (редактор колонок) . Робота з даним редактором аналогічна до роботи з редактором атрибутів.

· Самостійно введіть три нові колонки відповідно до табл. 2.1.

· Розглянутим вище способом (з використанням майстра) перетворіть зв'язок «Товар – Накладна» та доповніть отриману асоціативну таблицю Відвантаження двома колонками згідно з табл. 2.1.

Завдання правил валідації

Завдання списку допустимих значень

Відповідно до розглянутої предметної області для поля СТАВКА_ПДВ таблиці Товар задамо список допустимих значень: 0, 10 і 18 %.

Columns.

· У вікні редактора в полі Column- СТАВКА ПДВ.

· Перейдіть на закладку обраної СУБД - Access.

· Valid.

· У діалозі Validation Rulesклацніть по кнопці New.

· У діалозі New Validation Ruleв полі Logicalвведіть ім'я правила Перевірка ставки ПДВ. Натисніть кнопку ОК.

· Перейдіть на закладку General. У групі Typeвстановіть опцію Valid Value List.

· В полі Valid Valueу першому рядку введіть 0. У другому та третьому рядку введіть значення: 10 та 18.

· Перевірте, щоб у верхній частині вікна редактора Validation Rulesз'явився рядок: Перевірка ставки ПДВ(Validation Name) IN (0, 10, 18)(Validation Rule).

· Натисніть ОК.У вікні редактора Columnsна закладці Accessв полі Validз'явилося найменування створеного правила - "Перевірка ставки ПДВ".

Завдання значень, що надаються за умовчанням

Створимо правило, згідно з яким у полі ДАТА_ДОГ таблиці Договір за замовчуванням підставлятиме значення поточної дати.

· Викличте контекстне меню таблиці Договір та виберіть пункт Columns.

· У вікні редактора в полі Columnвиберіть колонку, для якої буде задаватися правило – ДАТА_ДОГ.

· На закладці Accessклацніть по кнопці, розташованій праворуч від списку, що розкривається Default.

· У діалоговому вікні Default/Initial Valuesклацніть по кнопці New.

· У діалозі New Default Valueв полі Logicalвведіть ім'я правила Поточна дата. Натисніть кнопку ОК.

· На закладці Accessв полі Server Value – Access Defaultвведіть Date()(функцію, яка отримує значення поточної дати).

· Натисніть ОК.У вікні редактора Columnsна закладці Accessв полі Defaultз'явилося найменування створеного правила - "Поточна дата".

· Встановіть це правило для поля ДАТА_ОТГР таблиці Накладна. Для цього у вікні редактора колонок Columnвиділіть поле ДАТА_ВІДГР і на закладці Access у полі Defaultзі списку, що розкривається, виберіть правило Поточна дата.

Завдання правил перевірки значень, що вводяться

Створимо правило перевірки значень, що вводяться для поля ЦІНА таблиці Товар, згідно з яким дане поле не може мати значення, менші 0.

· Викличте контекстне меню таблиці Товар та виберіть пункт Columns.

· У вікні редактора в полі Columnвиберіть колонку, для якої буде задаватися правило - ЦІНА.

· На закладці Accessклацніть по кнопці, розташованій праворуч від списку, що розкривається Valid.

· У діалозі Validation Rulesклацніть по кнопці New.

· У діалозі New Validation Ruleв полі Logicalвведіть ім'я правила Перевірка ціни. Натисніть кнопку ОК.

· Перейдіть на закладку General. У групі Typeвстановіть опцію Min/Max.

· В полі Minвведіть 1. Крім нижньої межі діапазону значень, тут також можна задати і верхню межу ( Max).

· У верхній частині вікна редактора Validation Rulesу списку правил валідації додалося новостворене: Перевірка ціни >=1.

· Натисніть кнопку ОК.

Лабораторна робота №7

Розрахунок розміру бази даних

Мета роботи:

Освоїти методику розрахунку розміру бази даних, реалізовану в Erwin.

Лабораторна робота №8

Створення звітів у Erwin

Мета роботи:

· Вивчення видів звітів;

· Освоєння процедури створення звітів

Лабораторна робота №5

Основи роботи у Erwin. Побудова логічної моделі даних

Мета роботи:

· Оволодіння навичками роботи в Erwin;

· Побудова логічної моделі заданої предметної області.

Завдання:

Побудувати логічну інформаційну модель постачання товарів відповідно до договорів засобами Erwin.

Опис інтерфейсу 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.