ОБДЗ / Лекции Access / Проектування РБД / 8_автоматизацiя
.pdf8 АВТОМАТИЗАЦІЯ ПРОЦЕСУ ПРОЕКТУВАННЯ МОДЕЛЕЙ ДАНИХ
8.1 Інструментальні засоби розробки моделей даних
Для автоматизації проектування ІС широко застосовують комп’ютерні засоби розробки, які мають назву CASE-засобів (Computer-aided software engineering). Застосування цих візуальних інструментальних програмних пакетів істотно підвищує продуктивність розробників ІС. Більшість з них надають розробникам можливість розробки МД.
Автоматизація процесу проектування МД висуває додаткові вимоги до мови опису МД. Ця мова повинна:
–бути такою, що обчислюється, тобто сприйматися й оброблятися за допомогою засобів обчислювальної техніки;
–використовувати графічні інтерфейси, дружелюбні до користувача;
–бути незалежною від устаткування та інших ресурсів.
Візуальне подання МД, створених за допомогою CASE-засобів, може використовуватися для детального аналізу і уточнення задачі, а також для оформлення документації, необхідної в циклі розробки.
CASE-засоби дозволяють:
–проектувати схеми ЛМД;
–формувати ФМД;
–легко вносити зміни в МД їх розробці та корегуванні;
–автоматично генерувати опис БД на мові багатьох цільових СУБД;
–генерувати БД у середовищі СУБД;
–проводити зворотнє проектування МД по існуючим;
–сінхронізувати МД і БД.
Треба визнати, що концептуальне проектування прямо не реалізовано в жодному пакеті автоматизованого проектування ІС, а МД у виді ER-моделей типу “Таблиці – зв’язки” одержали широке використання.
CASE-засоби будуються на різних методологіях розробки МД, які визначають термінологію і знаки графічного зображення типових елементів на діаграмах.
Найбільш поширена методологія IDEF1X (ICAM Definition Method 1 Extended) дозволяє побудувати МД, близьку до оптимальної. Ця методологія, зокрема, поділяє сутності на дві категорії: незалежні та залежні.
Сутність є незалежною від ідентифікаторів або просто незалежною, якщо кожний екземпляр сутності може бути однозначно ідентифікований без визначення його відносин з іншими сутностями. Сутність вважається залежною від ідентифікаторів або просто залежною, якщо однозначна ідентифікація екземпляра сутності залежить від його відношення до іншої сутності.
ER-діаграми типу IDEF1X (або IDEF1X-діаграми) використовують кілька розповсюджених CASE-засобів, наприклад, пакети AllFusion Erwin Data Modeler (ERwin) фірми Computer Associates International Inc. і Microsoft Visio.
Розглянемо приклади розробки ER-діаграм за допомогою пакету ERwin.
73
8.2 Розробка баз даних за допомогою ERwin 8.2.1 Етапи розробки моделей
В ERwin існують два рівні подання та моделювання – логічний і фізичний. Пакет надає розробникам БД великі можливості створення та управління цими рівнями подання однієї моделі.
Діаграма ERwin будується із трьох основних блоків – сутностей, атрибутів і зв'язків. Пакет має багато варіантів відображення моделі залежно від обраного режиму подання діаграми. Режим може змінюватися через пункт основного меню Model або через контекстне меню, яке викликається правою кнопкою миші.
Всі об'єкти моделі ERwin можна редагувати засобами, прийнятими в Windows: угрупування, копіювання, видалення, переміщення, використання системного буфера. Установку кольорів і шрифтів здійснюють в зручних діалогах.
Процес створення МД за допомогою Erwin складається з наступних кроків:
1)створення планшету МД;
2)визначення сутностей;
3)визначення залежностей між сутностями;
4)завдання первинних й альтернативних ключів;
5)визначення атрибутів сутностей;
6)приведення моделі до необхідного рівня НФ;
7)перехід до ФМД;
8)генерація БД.
Останні два пункти відносяться до ФМД.
На практиці зазвичай дещо змінюють наведену послідовність кроків створення моделей.
8.2.2 Створення планшету моделі
Розробка МД починається зі створення її планшету (бланку діаграми). Спочатку розглянемо процес створення ЛМД. Тому при створенні
планшету виберемо тип Logical (рис. 8.1).
Далі через меню Model→Model Properties уточнимо методологію (нотацію) МД (рис. 8.2).
Для того, щоб задавати імена атрибутів і сутностей російською або українською мовою, треба використовувати відповідні шрифти (Cyr – кирилиця). Вони встановлюються через меню Format → Default Fonts & Colors (рис. 8.3).
Моделі ERwin зберігаються на диску у вигляді файлу з розширенням
*.er1.
74
Рисунок 8.1 – Вибір типу МД
Рисунок 8.2 – Вибір нотації МД
75
Рисунок 8.3 – Настройка середовища ERwin
8.2.3.Визначення сутностей
Сутності створюються за допомогою меню та лінійки інструментів (рис.8.4) у режимі відображення сутностей “Entity”.
Рисунок 8.4 – Вид меню і панелі інструментів ERwin
Сутності автоматично позначаються як Еi/I, де Ei – це ім’я сутності, I – її номер у моделі. Позначення розміщується над прямокутником.
Режим “Entity” служить не тільки для розміщення сутностей, а і для зручності огляду великої діаграми.
Незалежні сутності на діаграмі вони зображуються прямокутниками, а залежні – прямокутниками із заокругленими кутами.
Для кожної сутності в редакторі “Entity Definition” можна задати її визначення та докладний опис. Ці нотатки з'являться у звітах і можуть бути відображені на діаграмі. Такий режим представлення сутностей служить для презентації моделі.
76
8.2.4 Визначення атрибутів сутностей
При переході від ПО до ІЛМ потрібно вводити інформацію про те, що становить сутність. Цю інформацію вводять шляхом завдання атрибутів.
Завдання атрибутів проводиться у режимі Attributes, що викликається через пункт основного меню Model або через контекстне меню → Attributes. Цей режим є основним при проектуванні як на логічному, так і на фізичному рівнях.
Відповідне вікно редагування атрибутів “Attributes” дозволяє додавати атрибути до вибраної сутності, проводити їх перейменування та вилучення, визначати тип домену (Datetime, Number, String), назначати ключові атрибути.
На рис. 8.5 наведено вікно завдання властивостей умовним атрибутам Pij, де i – номер сутності, j – номер атрибуту сутності.
Рисунок 8.5 – Вікно визначення властивостей атрибутів
На рис. 8.6 наведено основний планшет МД після створення двух сутностей.
Рисунок 8.6 – Основний планшет діаграми рівня сутностей
Імена атрибутів відображають у прямокутниках сутностей. При цьому прямокутник сутність поділяють горизонтальною лінією на дві частини – у верхній частині відображають атрибути, що становлять ключ, а в нижній – інші атрибути.
77
Атрибути, що можуть бути альтернативним ключем, помічають покажчиком AKi у дужках після імені. В ERwin можна також встановлювати групи атрибутів, які не ідентифікують унікально екземпляри сутності, але часто використовуються для доступу до даних.
Порядок завдання первинних ключів та визначення атрибутів не має значення. Ті самі атрибути сутності можуть входити до кількох різних груп ключів.
Зауважимо, що для дочірньої сутності атрибут зв’язку на цьому етапі не вказують. ERwin забезпечить його міграцію з батьківської сутності під час встановлення зв’язку
Таким чином, в ERwin сутність візуально представляє три основних види інформації:
–ім’я та тип сутності (незалежна/залежна);
–атрибути, що становлять первинний ключ;
–неключові атрибути.
Залежно від режиму подання діаграми сутність може містити також її опис і інші відомості.
8.2.5 Визначення залежностей між сутностями
Опис зв'язків між сутностями вводиться в редакторі “Relationships”.
В ERwin зв'язки представлені п'ятьма основними елементами інформації:
1)тип зв'язку;
2)батьківська сутність;
3)дочірня (залежна) сутність;
4)потужність зв'язку (cardinality);
5)допустимість порожніх Null-значень.
Зв'язки можуть бути ідентифікуючими, неідентифікуючими, повної або неповної категорії, а також неспецифічними.
Зв'язок називається ідентифікуючим, якщо екземпляр дочірньої сутності ідентифікується через її зв'язки з батьківською сутністю. Дочірня сутність при ідентифікуючому зв'язку завжди є залежною. При цьому атрибути, що становлять первинний ключ батьківської сутності, будуть входити у первинний ключ дочірньої сутності. Батьківська сутність в ідентифікуючому зв'язку, в залежності від її зв'язків з іншими сутностями, може бути як незалежною, так і залежною. Сутність-нащадок в ідентифікуючому зв'язку є залежною сутністю.
Зв'язок називається неідентифікуючим, якщо екземпляр дочірньої сутності ідентифікується інакше, ніж через зв'язок з батьківською сутністю. При цьому атрибути, що становлять первинний ключ батьківської сутності, будуть входити до складу неключових атрибутів дочірньої сутності. Сутністьнащадок у неідентифікуючому зв'язку буде незалежною, якщо вона не є також сутністю-нащадком у якому-небудь ідентифікуючому зв'язку.
Для визначення зв'язків ERwin обирають тип зв'язку, потім мишею спочатку вказують батьківську сутність, а потім – дочірню сутність. Ідентифікуючий зв'язок зображується суцільною лінією; неідентифікуючий –
78
пунктирною лінією. Лінії закінчуються точкою з боку дочірньої сутності. Зразки зв’язків наведені на рис.8.7.
а) ідентифікуючий зв'язок б) неідентифікуючий зв'язок Рисунок 8.7 – Типи зв’язків між сутностями
Як було зазначено вище, при встановленні зв’язків відбувається міграція атрибутів первинного ключа батьківської сутності у відповідну область атрибутів дочірньої сутності. Тому такі атрибути не вводяться вручну. Вони за замовчуванням мігрують зі своїми іменами. ERwin дозволяє ввести для них ролі, тобто нові імена, під якими мігруючі атрибути будуть представлені в дочірній сутності.
На фізичному рівні імена ролі – це ім'я поля зовнішнього ключа в дочірній таблиці. У випадку кількаразової міграції атрибута таке перейменування є необхідним. Також треба пам’ятати, що кількаразове застосування ідентифікуючих зв'язків веде до розростання кількості атрибутів у ключах сутностей. А це в свою чергу може знизити рівень НФ відповідної дочірньої сутності.
Зв'язок може додатково мати зазначення його потужності. Цей показник являє собою відношення кількості екземплярів батьківської сутності до відповідної кількості екземплярів дочірньої сутності. Для будь-якого зв'язку, крім неспецифічного, ця зв'язок записується як 1:N.
Відповідно до методології IDEF1X пакет ERwin надає 4 варіанти для числа N, які зображуються додатковим символом у дочірній сутності:
–нуль, один або більше (за замовчуванням);
–один або більше (зображується буквою "P");
–нуль або один (зображується буквою "Z");
–рівно N, де N – конкретне число (зображується числом N). Властивості звязку встановлюються у вікні Relationship Properties. Приклад опису основних властивостей зв’язку наведено на рис. 8.8а.
При визначенні властивостей звязку бажано встановити правила
підтримки цілісності за посиланнями Referential Integrity. Це дозволить забезпечити вимоги, щоб значення зовнішнього ключа екземпляра дочірньої сутності завжди відповідали значенням первинного ключа екземпляра в батьківській сутності. Правила встановлюються у режимі Referential Integrity (RI) Action (рис. 8.8б) і визначають ті дії (операції), які мають бути виконані для значень атрибутів звязку в екземплярах однієї сутності, якщо в іншій звязаній сутності виконані операції зміни.
79
а) вибір виду зв’язку
б) вибір виду дій Рисунок 8.8 – Вікно визначення властивостей зв’язку
80
Зазвичай такі дії оформлюються як процедури обробки подій при виконанні операції в вибраній сутності. Посилальна цілісність може контролюватися при всіх діях (операціях), які змінюють дані в звязаних сутностях, а саме додавання (Insert), вилучення (Delete) та модифікація (Update). Для кожного зв'язку можуть бути задані вимоги щодо обробки цих операцій як для батьківської, так і для дочірньої сутності. Фактично, для виконання правил цілісності в МД створюються відповідні RIтригери і процедура обробки подій оформлюються як їх реакція.
ERwin надає кілька варіантів обробки подій, які вибираються из списку:
–Restrict (обмеження) перешкоджає дії, якщо в іншій сутності є зв'язані екземпляри (заборона операції);
–Cascade (каскад) виконання аналогічної операції;
–Set null (встановити Null) значення встановлюються як Null (порожнє,
–Set default (встановити значення за умовчанням) встановлюються вказані значення за умовчанням;
–No Action (немає дії) не виконується ніяка дія, яле виконується перевірка допустимості;
–None (нічого) ніяка дія не потрібна (відсутність перевірки). Допустимість порожніх Null-значень у неідентифікуючих зв'язках ERwin
зображує порожнім ромбиком на дузі зв'язку з боку батьківської сутності.
Ім'я зв'язку на логічному рівні являє собою "дієслово", що зв'язує сутності. Фізичне ім'я зв'язку, яке може відрізнятися від логічного, для ERwin означає ім'я обмеження (constraint) або індексу.
Залежна сутність може успадковувати той самий зовнішній ключ від більш ніж однієї батьківської сутності, або від однієї й тієї ж батьківської сутності через кілька зв'язків. Якщо не введені різні ролі для такого множинного наслідування, треба забезпечити, щоб в залежній сутності атрибути зовнішнього ключа з'являлися лише один раз. Для цього проводиться уніфікація атрибутів.
Уніфікація – це об'єднання двох або більше груп атрибутів зовнішніх ключів в один зовнішній ключ у припущенні, що значення однойменних атрибутів у дочірній сутності завжди однакові.
Але уніфікація атрибутів може дати невірний з погляду ПО результат. Для скасування уніфікації для атрибутів рекомендується вводити імена ролей.
Після встановлення властивостей зв’язків можна вважати, що ЛМД побудована.
Кілька прикладів ER-діаграм логічного рівня були наведені на рис. 6.9, 7.6, 7.7.
Після формування ЛМД можна переходити до побудови ФМД і генерації
БД.
Разом з тим, ЛМД і ФМД можуть розроблятися паралельно.
81