Моделювання предметної області за допомогою ER-діаграм. CASE-системи
Мета роботи: отримати навички проектування ER-діаграм із застосуванням інструментального засобу CA ERwin Data Modeler.
Завдання:
1. Ознайомитися з практичним завданням.
2. Ознайомитися з теоретичними аспектами ER-діаграм.
3. Ознайомитися з інструментальним CASE - засобом CA ERwin Data Modeler з метою подальшого формування ER-діаграм.
4. Виконати практичне завдання.
Теоретичні відомості
Процес проектування бази даних становить складний і багатоетапний процес, в рамках якого можна виділити кілька основних етапів – концептуальний, логічний та фізичний.
1. Концептуальне (інфологічне) проектування бази даних – побудова семантичної (формалізованої) моделі предметної області, тобто інформаційної моделі найбільш високого рівня абстракції. Така модель створюється без орієнтації на якусь конкретну СКБД і модель даних. Терміни «семантична модель», «концептуальна модель» і «інфологічна модель» є синонімами. Крім того, в цьому контексті рівноправно можуть використовуватися слова «модель бази даних» та «модель предметної області» (наприклад, «концептуальна модель бази даних» і «концептуальна модель предметної області»), оскільки така модель є як образом реальності, так і образом проектованої бази даних для цієї реальності.
Конкретний вигляд і зміст концептуальної моделі бази даних визначається обраним для цього формальним апаратом. Зазвичай використовуються графічні нотації, наприклад ER-діаграми.
Найчастіше концептуальна модель бази даних включає в себе:
- опис інформаційних об'єктів або понять предметної області і зв'язків між ними.
- опис обмежень цілісності, тобто вимог до допустимих значень даних і до зв'язків між ними.
Етап концептуального (інфологічного) проектування бази даних зазвичай реалізується у вигляді ER-діаграми (-моделі) з використанням одної з наявних нотацій (нотації Пітера Чена, Crow's Foot (нотації запропонованої Гордоном Еверестом), Bachman notation, EXPRESS, IDEF1x, Martin notation, (min, max)-Notation, UML.
Логічне (даталогічне) проектування ‒ створення схеми бази даних на основі конкретної моделі даних: реляційної, мережевої, ієрархічної або об'єктно-орієнтованої. Для реляційної моделі даних даталогічная модель ‒ набір схем відношень, зазвичай із зазначенням первинних ключів, а також «зв'язків» між відношеннями, що представляють собою зовнішні ключі.
Перетворення концептуальної моделі в логічну модель, як правило, здійснюється за формальними правилами. Цей етап може бути в значній мірі автоматизований.
На етапі логічного проектування враховується специфіка конкретної моделі даних, але може не враховуватися специфіка конкретної СКБД.
Етап логічного (даталогічного) проектування бази даних зазвичай реалізується у вигляді схеми бази даних, що перевірена на відповідність третій нормальній формі, та розробленій логічній моделі.
Фізичне проектування ‒ створення схеми бази даних для конкретної СКБД. Специфіка конкретної СКБД може включати в себе обмеження на іменування об'єктів бази даних, обмеження на підтримувані типи даних і т.п. Крім того, специфіка конкретної СКБД при фізичному проектуванні включає вибір рішень, пов'язаних з фізичним середовищем зберігання даних (вибір методів управління дисковою пам'яттю, поділ БД по файлах і пристроях, методів доступу до даних), створення індексів і т.д.
Етап фізичного проектування бази даних зазвичай реалізується у вигляді фізичної моделі.
Схема 1. Етапи проектування бази даних
Таким чином етап концептуального проектування бази даних починається зі створення концептуальної моделі даних підприємства, повністю незалежної від будь-яких деталей реалізації. До останніх належать: вибраний тип СКБД, перелік програмних застосувань, мова програмування, конкретна обчислювальна платформа та будь-які інші фізичні особливості реалізації. Важливість даного етапу важко переоцінити, оскільки від якості її реалізації багато в чому залежить хід подальшого проектування бази даних.
У рамках етапу концептуального проектування бази даних створюється модель даних, виходячи з уявлень про предметну область кожного з типів користувачів, а для цього розробник системи повинен мати повне уявлення про поняття, предмети, факти та події, якими буде оперувати система, що розробляється. Для того, щоб привести ці поняття до тієї чи іншої моделі даних, необхідно замінити їх інформаційними уявленнями.
Одним з найбільш зручних інструментів уніфікованого подання даних, незалежного від програмного забезпечення що його реалізує, є модель «сутність-зв'язок» (entity-relationship model, ER-model). Автором даного підходу є американський вчений Пітер Чен.
Модель «сутність-зв'язок» ґрунтується на важливій семантичній інформації про реальний світ і призначена для логічного подання даних. Вона визначає значення даних у контексті їхнього взаємозв'язку з іншими даними. З цієї моделі можуть бути породжені всі існуючі моделі даних (ієрархічна, мережна, реляційна, об'єктна), тому, в цьому сенсі, вона є найбільш загальною.
Процес створення моделі предметної області є досить нетривіальним завданням і становить багато в чому творчий процес, внаслідок чого його комплексна автоматизація практично неможлива. Однак застосування сучасних програмних засобів, що базуються на CASE-технологіях, на етапі створення моделі предметної області, дозволяє здійснити цей процес більш якісно та з меншими витратами трудових ресурсів.
CASE-технологія є методологією автоматизації проектування інформаційних систем (ІС) і її складових елементів, зокрема бази даних (БД), а також набір інструментальних засобів, які дозволяють в наочній формі моделювати предметну область, аналізувати цю модель на усіх етапах розробки і супроводу ІС, а також розробляти застосування, відповідно до інформаційних потреб користувача.
Одним з найбільш популярних засобів інформаційного моделювання і автоматизації є CASE – засіб Erwin Data Modeler фірми Computer Associates. Реалізація моделювання в ERwin базується на теорії реляційних баз даних і на методології IDEF1X (Integration DEFinition for Information Modeling).
Методологію IDEF1X було розроблено для ВПС США і тепер воня використовується, зокрема, в урядових, аерокосмічних і фінансових установах, а також у великій кількості приватних компаній. Методологія IDEF1X визначає стандарти термінології, використовуваної при інформаційному моделюванні, і графічного зображення типових елементів на діаграмах. У 1981 році цей стандарт був формалізований і опублікований організацією ICAM (Integrated Computed Aided Manufacturing), і відтоді є найбільш поширеним стандартом для створення моделей баз даних по усьому світу.
Опис програмного забезпечення для проектування ER-діаграм
CA ERwin Data Modeler (раніше ERwin) ‒ CASE-засіб для проектування та документування баз даних, який дозволяє створювати, документувати і супроводжувати бази даних, сховища і вітрини даних. Моделі даних допомагають візуалізувати структуру даних, забезпечуючи ефективний процес організації, управління і адміністрування таких аспектів діяльності підприємства, як рівень складності даних, технологій баз даних та середовища розгортання.
CA ERwin Data Modeler (ERwin) призначений для всіх компаній, що розробляють і використовують бази даних, для адміністраторів баз даних, системних аналітиків, проектувальників баз даних, розробників, керівників проектів. CA ERwin Data Modeler дозволяє управляти даними в процесі корпоративних змін, а також в умовах стрімко змінюються технологій.
CA ERwin Data Modeler (ERwin) дозволяє наочно відображати складні структури даних. Зручне у використанні графічне середовище CA ERwin Data Modeler спрощує розробку бази даних і автоматизує безліч трудомістких завдань, зменшуючи терміни створення високоякісних і високопродуктивних транзакційних баз даних і сховищ даних. Дане рішення покращує комунікацію організації, забезпечуючи спільну роботу адміністраторів і розробників баз даних, багаторазове використання моделі, а також наочне уявлення комплексних активів даних в зручному для розуміння та обслуговування форматі.
Поняття про логічні та фізичні рівні побудови моделі даних в Erwin
Erwin використовується для побудови моделі даних. ERwin має два рівні уявлення моделі – логічний і фізичний. На логічному рівні дані не пов'язані з конкретною СКБД. Фізичний рівень даних – це по суті відображення системного каталогу, який залежить від конкретної реалізації СКБД. ERwin дозволяє проводити процеси прямого і зворотного проектування БД. Це означає, що за моделлю даних можна згенерувати схему БД або автоматично створити модель даних на основі інформації системного каталогу. Для створення моделей даних в Erwin використовуються дві методології: IDEF1X і IE.
На фізичному рівні об'єкти БД можуть називатися так, як того вимагають обмеження СКБД. На логічному рівні можна цим об'єктам дати синоніми – імена більш зрозумілі неспеціалістам, в тому числі на кирилиці і з використанням спеціальних символів.
Створення моделі даних, як правило, починається зі створення логічної моделі. Після опису логічної моделі, проектувальник може вибрати необхідну СКБД, і ERwin автоматично створить відповідну фізичну модель. На основі фізичної моделі ERwin може згенерувати системний каталог СКБД або відповідний SQL-скрипт. Цей процес називається прямим проектуванням (ForwardEngineering). Тим самим досягається масштабованість – створивши одну логічну модель даних, можна згенерувати фізичні моделі під будь-яку підтримувану ERwin СКБД. З іншого боку, ERwin здатний по вмісту системного каталогу або SQL-скрипту відтворити фізичну і логічну модель даних (ReverseEngineering). На основі отриманої логічної моделі даних можна згенерувати фізичну модель для іншої СКБД і потім згенерувати її системний каталог. Отже, ERwin дозволяє вирішити задачу по перенесенню структури даних з одного сервера на інший.
Створення концептуальної моделі даних передбачає створення моделі даних логічного рівня, що складається з сутностей і зв'язків між ними. Атрибути сутностей на рівні концептуальної моделі не розглядаються. Сутності та лінії зв'язку повинні мати, як правило, назви, зрозумілі фахівцям предметної області, до якої належить модель, яка розробляється.
Основні поняття моделі «сутність-зв'язок». ER-моделі
Модель «Сутність-Зв'язок» (ER-модель) (англ. entity-relationship model (ERM) або англ. entity-relationship diagram (ERD)) ‒ модель даних, що дозволяє описувати концептуальні схеми. Надає собою графічну нотацію, засновану на блоках і з'єднуючих їх лініях, за допомогою яких можна описувати об'єкти і відносини між ними якої-небудь іншої моделі даних. У цьому сенсі ER-модель є мета-моделлю даних, тобто засобом опису моделей даних.
За допомогою ERD здійснюється деталізація накопичувачів даних DFD ‒ діаграми, а також документуються інформаційні аспекти бізнес-системи, включаючи ідентифікацію об'єктів, важливих для предметної області (сутностей), властивостей цих об'єктів (атрибутів) та їх зв'язків з іншими об'єктами (відносин).
Модель «сутність-зв'язок» була запропонована в 1976 році Пітером Пін-Шен Ченом (англ. Peter Pin-Shen Chen), американським професором комп'ютерних наук в університеті штату Луїзіана.
У зв'язку з наочністю подання концептуальних схем баз даних ER-моделі одержали широке поширення в CASE системах, що підтримують автоматизоване проектування реляційних баз даних. Серед безлічі нотацій ER-моделей одна з найбільш розвинених ‒ Unified Modeling Language (уніфікована мова моделювання), скор. UML ‒ застосовується в системі CASE фірми ORACLE. Нотація UML так само використовується і / або підтримується: Borland Software Corporation, Університетом Бремена, Університетом Кента, Університетом Йорка і Дрезденським Університетом Технології.
Базові поняття ER-моделі
Сутність (Entity) – множина екземплярів реальних або абстрактних об'єктів (людей, подій, станів, ідей, предметів та ін.), що мають загальні атрибути або характеристики. Будь-який об'єкт системи може бути представлений тільки однією сутністю, яка має бути унікально ідентифікована. При цьому ім'я сутності повинне відбивати тип або клас об'єкту, а не його конкретний екземпляр (наприклад, АЕРОПОРТ, а не БОРИСПІЛЬ або ХІТРОУ).
Кожна сутність повинна мати унікальний ідентифікатор. Кожен екземпляр сутності повинен однозначно ідентифікуватися і відрізнятися від усіх інших екземплярів цього типу сутності. Кожна сутність повинна мати деякі властивості, а саме:
1) унікальне ім'я; до одного і того ж імені повинна завжди застосовуватися одна і та ж інтерпретація; одна і та ж інтерпретація не може застосовуватися до різних імен, якщо тільки вони не є псевдонімами;
2) один або декілька атрибутів, які або належать сутності, або наслідуються через зв'язок;
3) один або декілька атрибутів, які однозначно ідентифікують кожен екземпляр сутності.
Кожна сутність може мати будь-яку кількість зв'язків з іншими сутностями моделі.
Зв'язок (Relationship) – пойменована асоціація між двома сутностями, що має значення для даної предметної області. Зв'язок – це асоціація між сутностями, при якій кожен екземпляр однієї сутності асоційований з довільною (у тому числі нульовою) кількістю екземплярів іншої сутності, і навпаки.
Атрибут (Attribute) – будь-яка характеристика сутності, значима для даної предметної області і призначена для кваліфікації, ідентифікації, класифікації, кількісної характеристики або вираження стану сутності. Атрибут представляє тип характеристики або властивості, що асоціюються з множиною реальних або абстрактних об'єктів (людей, місць, подій, станів, ідей, предметів і так далі). Екземпляр атрибуту – це певна характеристика окремого елементу множини. Екземпляр атрибуту визначається типом характеристики і її значенням, що називається значенням атрибуту.
Ключ (Key) – атрибут або множина атрибутів, що однозначно ідентифікує конкретний екземпляр сутності (ключові атрибути).
Приклади. Є сутність Співробітник, у якої може бути такий набір атрибутів: Табельний номер, Прізвище, Ім'я, По батькові, Дата народження, Кількість дітей, Наявність родичів за кордоном. Для сутності Співробітник ключовим буде атрибут Табельний номер, оскільки для усіх співробітників цього підприємства табельні номери різні.
Екземпляром сутності Співробітник буде опис конкретного співробітника підприємства. Одне із загальноприйнятих графічних позначень сутності – прямокутник, у верхній частині якого записано ім'я сутності, а нижче перераховуються атрибути, причому ключові атрибути позначаються, наприклад, підкресленням або спеціальним шрифтом, як показано на рис. 1.1.
Рис. 1.1. Приклад позначення сутності
Між сутностями можуть бути встановлені зв'язки – бінарні асоціації, що показують, яким чином сутності співвідносяться або взаємодіють між собою. Зв'язок може існувати між двома різними сутностями або між сутністю та самою ж нею (рекурсивний зв'язок). Вона показує, як пов'язані екземпляри сутностей між собою. Якщо зв'язок встановлюється між двома сутностями, то він визначає взаємозв'язок між екземплярами однієї та іншої сутності. Наприклад, якщо є зв'язок між сутністю "Студент" і сутністю "Викладач" і цей зв'язок – керівництво дипломними проектами, то кожен студент має тільки одного керівника, але один і той же викладач може керувати декількома студентами-дипломниками. Тому це буде зв'язок "один-до-багатьох" (1:М), один з боку "Викладач" і багато з боку "Студент" (рис. 1.2).
Рис. 1.2. Зв'язок сутностей Викладач та Студент
У різних нотаціях потужність зв'язку відображається по-різному, але сенс має один. Графічна інтерпретація зв'язку дозволяє відразу прочитати сенс взаємозв'язку між сутностями, вона наочна і легко інтерпретується. Зв'язки діляться на три типи за потужністю: один-до-одного (1:1), один-до-багатьох (1:М), багато-до-багатьох (М:М).
Зв'язок один-до-одного означає, що екземпляр однієї сутності пов'язаний тільки з одним екземпляром іншої сутності. Зв'язок 1:М означає, що один екземпляр сутності, розташований ліворуч лінії зв'язка, може бути пов'язаний з декількома екземплярами сутності, розташованими праворуч. Зв'язок "багато-до-багатьох" (М:М) означає, що один екземпляр першої сутності може бути пов'язаний з декількома екземплярами другої сутності, і навпаки, один екземпляр другої сутності може бути пов'язаний з декількома екземплярами першої сутності.
Наприклад, зв'язок типу "Вивчає" між сутностями "Студент" і "Дисципліна" є зв'язок типу "багато-до-багатьох" (М:М), оскільки кожен студент може вивчати декілька дисциплін, а кожна дисципліна вивчається множиною студентів.
Між двома сутностями може бути задано скільки завгодно зв'язків з різними смисловими навантаженнями. Наприклад, між двома сутностями "Студент" і "Викладач" можна встановити два зв'язка, один – розглянутий вже раніше "Дипломне проектування", а другий може бути умовно названий "Лекції", і він визначає – лекції яких викладачів слухає цей студент і яким студентам цей викладач читає лекції. Зрозуміло, що це зв'язок типу багато-до-багатьох (рис.1.3).
Рис. 1.3. Множинні зв'язки між сутностями
Зв'язок будь-якого з цих типів може бути обов'язковим, якщо в цьому зв'язку повинен брати участь кожен екземпляр сутності, і необов'язковою – якщо не кожен екземпляр сутності повинен брати участь в цьому зв'язку. При цьому зв'язок може бути обов'язковим з одного боку і необов'язковим з іншого боку. Обов'язковість зв'язку теж по-різному позначається в різних нотаціях.
Представлення ER-діаграм у нотації IDEF1X
Існує декілька способів відображення ER-діаграм. Найбільш поширеними є метод Баркера і метод IDEFI.
Метод Баркера заснований на нотації, запропонованій автором, і використовується в CASE-засобі Oracle Designer.
Метод IDEFI заснований на підході Чена і дозволяє побудувати модель даних, еквівалентну реляційній моделі в третій нормальній формі. На основі вдосконалення методу IDEFI створена його нова версія – метод IDEF1X, розроблений з урахуванням таких вимог, як простота для вивчення і можливість автоматизації. IDEF1X-діаграми використовуються у ряді поширених CASE-засобів (зокрема, ERwin, Design/IDEF).
У методі IDEF1X сутність є незалежною від ідентифікаторів або просто незалежною, якщо кожен екземпляр сутності може бути однозначно ідентифікований без визначення його зв'язку з іншими сутностями. Наприклад: сутності Клієнт і Замовлення. Для ідентифікації замовлення немає необхідності в посиланні на клієнта, який зробив це замовлення.
Сутність називається залежною від ідентифікаторів або просто залежною, якщо однозначна ідентифікація екземпляра сутності залежить від його відношення до іншої сутності. Приклад: сутності – Замовлення і Позиція замовлення. Для ідентифікації позиції замовлення треба послатися на замовлення, в яке входить ця позиція.
Зв'язок може додатково визначатися за допомогою вказівки ступені або потужності (кількості екземплярів сутності-нащадка, яке може породжувати кожен екземпляр сутності-батька). У IDEF1X можуть бути створені такі потужності зв'язків:
– кожен екземпляр сутності-батька може мати нуль, один або більше за один пов'язаних з ним екземплярів сутності-нащадка;
– кожен екземпляр сутності-батька повинен мати не менше одного пов'язаного з ним екземпляра сутності-нащадка;
– кожен екземпляр сутності-батька повинен мати не більше одного пов'язаного з ним екземпляра сутності-нащадка;
– кожен екземпляр сутності-батька пов'язаний з деяким фіксованим числом екземплярів сутності-нащадка.
Якщо екземпляр сутності-нащадка однозначно визначається своїм зв'язком з сутністю-батьком, то зв'язок називається ідентифікуючим, інакше - неідентифікуючим.
Зв'язок зображується лінією, що проводиться між сутністю-батьком і сутністю-нащадком, з точкою на кінці лінії у сутності-нащадка (рис. 1.4). Потужність зв'язків може набувати таких значень: N – нуль, один або більше; Z – нуль або один, Р – один або більше. За замовчуванням потужність зв'язків приймається рівною N.
Рис.1.4. Графічне зображення потужності зв'язку
Ідентифікуючий зв'язок між сутністю-батьком і сутністю-нащадком зображується суцільною лінією. Сутність-нащадок в ідентифікуючому зв'язку є залежною від ідентифікатора сутності. Сутність-батько в ідентифікуючому зв'язку може бути як незалежним, так і залежним від ідентифікатора сутності (це визначається її зв'язками з іншими сутностями).
Пунктирна лінія зображує неідентифікуючий зв'язок (рис. 1.5). Сутність-нащадок у неідентифікуючому зв'язку буде незалежною від ідентифікатора, якщо вона не є також сутністю-нащадком, в якому- небудь ідентифікуючому зв'язку.
Атрибути зображуються у вигляді списку імен усередині блоку сутності. Атрибути, що визначають первинний ключ, розміщуються спочатку і відділяються від інших атрибутів горизонтальною рисою.
Сутності можуть мати також зовнішні ключі (Foreign Key), які використовуються як частина або цілий первинний ключ або неключовий атрибут. Для позначення зовнішнього ключа всередині блоку сутності поміщають імена атрибутів, після яких записують букви FK в дужках (рис. 1.5).
Рис. 1.5. Неідентифікуючий зв'язок
|
Інтерфейс Erwin Data Modeler
При запуску програми Erwin Data Modeler з'являється її вікно, в якому затінені усі палітри інструментів, окрім меню і кнопок створення нової моделі і відкриття моделі (рис. 1.6).
Рис. 1.6. Початковий вид вікна Erwin Data Modeler
При створенні нової моделі вимагається вказати її тип: логічний, фізичний або логічний/фізичний (рис.1.7).
Після вибору режиму створення моделі або відкриття вже існуючої моделі, палітра інструментів стає доступною (рис. 1.8).
Рис. 1.7 Вибір типу нової моделі
Рис. 1.8. Вид вікна Erwin Data Modeler для нового проекту
Основне призначення кнопок на панелі інструментів таке (табл.1.1).
Таблиця 1.1. Основна панель інструментів ERWin
Палітра інструментів виглядає по-різному на різних рівнях відображення моделі.
На логічному рівні панель інструментів виглядає таким чином (рис. 1.9).
Рис. 1.9. Палітра інструментів на логічному рівні
Кнопка покажчика (режим миші) – в цьому режимі можна встановити фокус на якому-небудь об'єкті моделі.
Кнопка внесення сутності – для внесення сутності треба клацнути лівою кнопкою миші по кнопці внесення сутності і один раз по вільному простору на моделі. Повторне клацання приведе до внесення в модель ще однієї нової сутності. Для редагування сутностей або інших об'єктів моделі необхідно перейти в режим покажчика.
Кнопка категорії'. Категорія, або категоріальний зв'язок – це спеціальний тип зв'язка між сутностями. Для встановлення категоріального зв'язка треба клацнути лівою кнопкою миші по кнопці категорії, потім один раз клацнути по сутності - родовому предку і, потім по сутності – нащадку.
Кнопка створення зв'язків, ідентифікуючих, "багато-до-багатьох" та неідентифікуючих.
На фізичному рівні палітра інструментів має такий вигляд (рис. 1.10). З'являється можливість створити таблиці та подання.
Рис. 1.10. Палітра інструментів на фізичному рівні
Для перемикання між логічною і фізичною моделлю даних служить список вибору в центральній частині панелі інструментів ERwin (рис. 1.11). Якщо при перемиканні фізичної моделі ще не існує, вона буде створена автоматично.
Рис. 1.11. Перемикання між логічною та фізичною моделлю
Приклад виконання лабораторної роботи
Створення моделі предметної області «Продаж хлібобулочних виробів»
Для ілюстрації роботи з Erwin Data Modeler спочатку спроектуємо просту ІС, яка базується на, системі обліку продажу хлібобулочних виробів.
Розробку бази даних розпочинаємо зі створення нової моделі в ERwin, для цього треба виконати такі дії:
- запустити ERwin;
- вибрати Create a new model (Створити нову модель);
- вибрати тип моделі. Вибравши тип Physical або Logical/Physical, можна відразу визначити базу даних, в якій буде реалізована модель.
Виберемо тип моделі Logical/Physical. Це дозволить надалі легко перемикатися між логічним і фізичним рівнями. У списку пропонованих баз даних виберемо Access. Пізніше, у разі потреби, середовище реалізації можна буде змінити.
Поняття про логічні та фізичні рівні
Як вже було зазначено раніше, існує два різні способи моделювання в ERwin - логічний рівень і фізичний рівень. Поняття логічний рівень передбачає, що ми мислимо в поняттях реального світу і безпосередньо з нього беремо об'єкти для моделювання. На логічному рівні не має значення, наприклад, якою СКБД ми користуватимемося, чи є деяке число цілим або дійсним, як краще індексувати таблицю тощо.
Після того, як модель побудована на логічному рівні, вона виражається в термінах фізичної бази даних, включаючи вибір СКБД, типів даних за замовчуванням і ефективних схем індексування. Це прийнято називати фізичним рівнем моделі ERwin. ERwin підтримує побудову і організацію роботи на цих двох рівнях для однієї діаграми.
Модель в ERwin, що має тільки логічний рівень може бути синхронізована з декількома моделями, що мають тільки фізичний рівень. Таким чином, на основі однієї логічної моделі можна створювати декілька фізичних, таких, що відповідають різним СКБД.
Робота з діаграмою ERwin
Робоча область ERwin складається з двох частин. Ліворуч розташований навігатор моделі, що надає додаткові можливості пошуку і редагування об'єктів моделі. Основну зону вікна займає безпосередньо сама діаграма. У верхній частині вікна розташовані панелі інструментів. Інтерфейс виконаний в стилі Windows-додатків, досить простий і інтуїтивно зрозумілий.
Сутності та атрибути. Сутність служить для представлення набору реальних або абстрактних предметів (людей, місць, подій і тому подібне), які мають загальні атрибути або характеристики. Кожна сутність являє собою множину подібних індивідуальних об'єктів, що називаються екземплярами. Атрибут виражає певну властивість об'єкту. На фізичному рівні сутність представляється таблицею, атрибут - колонкою таблиці, екземпляр – рядком таблиці.
Для наведеного прикладу виділимо такі основні логічні об'єкти: Товари і Виробники.
1.
Клацніть значок
на
панелі інструментів. Курсор набере вигляду
.
2. Клацніть на будь-якому місці діаграми. На екрані з'явиться нова сутність.
3. За замовчуванням, сутності привласнюється ім'я E/x, де x - унікальний номер сутності. Змінити ім'я можна, клацнувши по сутності лівою кнопкою миші, або вибравши пункт Entity Properties в контекстному меню сутності (рис. 1.12).
4. У властивостях сутності також можна дати опис сутності, ввести замітки і вказати іншу інформацію.
На логічному рівні бажано називати сутності українськими словами для полегшення читання схеми усіма учасниками процесу розробки. Пізніше на фізичному рівні можна змінити назви сутностей і атрибутів на латинські, оскільки більшість СКБД підтримують тільки латинські букви.
Обов'язково складайте описи створюваних сутностей. Це допоможе надалі зрозуміти, що це за об'єкт і зробить схему читабельною для інших учасників процесу розробки. Крім того, побудувавши після створення діаграми звіт, можна отримати готову документацію за схемою.
Для внесення опису і зауважень виберіть в контекстному меню сутності пункт меню Entity Properties. У полі Definition вкажіть визначення сутності (рис. 1.12).
Рис. 1.12 Вікно створення нової сутності
На фізичному рівні визначення сутності можна експортувати як частину схеми і використати в реальній БД.
У вкладці Note можна ввести корисне зауваження, що описує будь- яке бізнес-правило або угоду по організації діаграми.
У вкладці Note 2 зазвичай документуються деякі можливі запити, які, як очікується, використовуватимуться по відношенню до сутності у БД. Ця інформація буде корисною при проектуванні БД на фізичному рівні.
Вкладка Note 3 дозволяє вводити приклади даних для сутності в довільній формі.
1. Виділіть сутність.
2. Клацніть правою кнопкою і виберіть Attributes в контекстному меню сутності. З'являється діалог Attributes (рис. 1.13)
Рис. 1.13. Вікно створення атрибутів сутності
Щоб додати новий атрибут клацніть кнопку New, введіть ім'я атрибуту, ім'я колонки до БД і його домена. Домен атрибуту використовуватиметься при визначенні типу колонки на фізичному рівні. Для атрибутів первинного ключа у вкладці General необхідно зробити позначку у вікні вибору Primary Key.
Аналогічно сутностям, необхідно задавати опис атрибутам (вкладка Definition).
Далі створимо сутність Виробники і створимо атрибути для неї (рис. 1.14).
Рис. 1.14. Створення сутності «Виробники»
Загальний вид екрану в цьому випадку виглядає так (рис 1.15) якщо встановити рівень перегляду атрибутів (Attribute level)
Рис. 1.15. Вид екрану для двох створених сутностей
Поняття зв'язку
Створення сутностей і інформації про них - це тільки частина картини. Необхідно показати, як взаємодіють між собою об'єкти моделі. Логічні з'єднання або асоціації між двома сутностями називаються зв'язками. Дані, що відносяться до зв'язків, дуже важливі. Зв'язок –- це співвідношення або між двома сутностями, або між сутністю і цією же сутністю. Кожний зв'язок повинен іменуватися дієсловом або дієслівною фразою, яка полегшує читання діаграми. Якщо взаємозв'язки між сутністю були правильно встановлені, то, для перевірки адекватності логічної моделі, можна скласти речення, що їх описують, наприклад, «Покупець робить Замовлення», «Багато замовлень робляться одним покупцем», тощо (рис. 1.16).
Рис. 1.16. Відображення зв'язку між сутностями
Складання таких речень дозволяє перевірити відповідність отриманої моделі вимогам і обмеженням створюваної системи.
На логічному рівні можна встановити три
типи зв'язків: ідентифікуючий зв'язок «один до багатьох» – ,
неідентифікуючий зв'язок «один до багатьох» –
і
невизначений зв'язок «багато-до-багатьох» –
Щоб створити зв'язок необхідно:
1. Клацнути по одній з вище приведених кнопок на панелі інструментів.
2. Клацнути по батьківській сутності.
3. Клацнути по дочірній сутності.
Ідентифікуючий зв'язок – зв'язок, при якому екземпляр дочірньої сутності визначається через свій зв'язок з батьківською сутністю. Атрибути первинного ключа батьківської сутності стають атрибутами первинного ключа дочірньої. Операція доповнення атрибутів дочірньої сутності при створенні зв'язка називається міграцією атрибутів. У дочірній сутності нові атрибути позначаються як зовнішній ключ (FK).
При встановленні ідентифікуючого зв'язка між сутностями дочірня сутність стає залежною. Залежна сутність - це сутність, екземпляри якої не можуть бути унікальним чином ідентифіковані без визначення її зв'язка з іншою сутністю або сутностями. Залежні сутності в Erwin зображується у вигляді прямокутника із закругленими кутами.
У даному прикладі ми не вводимо ідентифікуючих зв'язків. Кожен екземпляр всіх сутностей однозначно визначається своїм номером.
Неідентифікуючий зв'язок – це такий зв'язок, при якому екземпляр дочірньої сутності не ідентифікується через свій зв'язок з батьківською сутністю. Атрибути первинного ключа батьківської сутності стають неключовими атрибутами дочірньої. При встановленні неідентифікуючого зв'язка дочірня сутність залишається незалежною.
Незалежна сутність – це сутність, екземпляри якої можуть бути унікальним чином ідентифіковані без визначення її зв'язка з іншою сутністю.
У ілюстрованому прикладі зв'язок «Виробники виробляють Товари» матиме зв'язок «багато-до-багатьох», який може бути створений тільки на рівні логічної моделі (рис. 1.17, рис. 1.18).
Рис. 1.17. Вікно створення зв'язку
Рис. 1.18. Відображення зв'язку на діаграмі
Відображення на екрані дієслівних фраз
За замовчуванням дієслівна фраза не відображається на екрані. Для того, щоб показати на екрані дієслівну фразу, що відноситься до зв'язка, клацніть правою кнопкою миші по будь-якому місці у вікні діаграми і виберіть пункт Relationship Display -> Verb Phrase.
Типи сутностей та ієрархія наслідування
Як було вказано вище, зв'язки визначають, чи є сутність незалежною або залежною. Розрізняють декілька типів залежних сутностей.
Характеристична – залежна дочірня сутність, яка пов'язана тільки з однією батьківською і у цьому сенсі зберігає інформацію про характеристики батьківською сутності.
Прикладом характеристичної сутності може служити сутність Замовлення.
Асоціативна – сутність, пов'язана з декількома батьківськими сутностями. Така сутність містить інформацію про зв'язки сутностей.
Іменуюча – окремий випадок асоціативної сутності, що не має власних атрибутів (тільки атрибути батьківських сутностей, що мігрували як зовнішній ключ).
Категоріальна – дочірня сутність в ієрархії наслідування.
Ієрархія наслідування (або ієрархія категорій) є особливим типом об'єднання сутностей, які розділяють загальні характеристики.
Створення фізичної моделі даних
Для створення фізичної моделі слід позбавитися від зв'язків «багато-до-багатьох». Для цього виділимо зв'язок і запустимо майстер перетворення зв'язка «багато-до-багатьох» (рис. 1.19).
Рис. 1.19. Перетворення зв'язка «багато-до-багатьох»
Після запуску майстра в його початковому вікні натискаємо кнопку «Далі» і переходимо у вікно «Transform information», де вказуємо ім'я перетворення та його опис (рис. 1.20).
|
Рис. 1.20. Вікно для внесення інформації про перетворення зв'язку
Натискаємо кнопку «Далі» і переходимо до наступного вікна, в якому даємо ім'я новостворюваній асоціативній сутності і вводимо її опис (рис. 1.21).
Рис. 1.21. Опис новостворюваної асоціативної сутності
Натискаємо кнопку «Далее», а потім «Готово». У результаті отримуємо таку діаграму (рис. 1.22)
Рис. 1.22. Вид створеної діаграми після перетворення зв'язку
З'являється нова сутність «Продажі», така, що забезпечує асоціативний зв'язок між Виробниками і Товарами. Поява такої сутності позбавляє нас від зв'язка «багато до багатьох». Первинні ключі початкових сутностей стають складеним первинним ключем нової асоціативною сутності.
Після цього додамо до сутності Продажі нові атрибути (рис. 1.23).
Рис. 1.23. Додавання нових атрибутів до асоціативної сутності
Процес генерації фізичної схеми БД з логічної моделі даних називається прямим проектуванням (Forward Engineering). При генерації фізичної схеми ERwin включає тригери посилальної цілісності, збережені процедури, індекси, обмеження та інші можливості, доступні при визначенні таблиць у вибраній СКБД.
Для генерації системного каталогу БД
перейдіть з логічної моделі на фізичну, виберіть пункт меню Tools
->Forward Engineer/Schema
Generation або клацніть кнопку на панелі інструментів Database
(рис.
1.24).
Рис. 1.24. Вибір генерації фізичної схеми бази даних
Ви увійдете до діалогу Schema Generation (рис. 1.25).
Рис. 1.25. Вікно діалогу при прямому проектуванні бази даних
Діалог Schema Generation має три закладки:
1. Закладка Options служить для завдання опцій генерації об'єктів БД- тригерів, таблиць, подання, колонок, індексів тощо. Для завдання опцій генерації якого-небудь об'єкту слід вибрати об'єкт у лівому списку закладки, після чого увімкнути відповідну опцію в правому списку.
2. В закладці Summary відображаються усі опції, задані в закладці Options. Список опцій в Summary можна редагувати так само, як і в Options.
3. Закладка Comment дозволяє внести коментар для кожного набору опцій.
Для генерації схеми БД треба клацнути кнопку Generate та увійти до діалогу Connection для встановлення сеансу зв'язку з сервером і запуску SQL-скрипта (рис. 1.26).
Рис. 1.26. Вікно вибору бази даних при прямому проектуванні
Для того, щоб згенерувати базу даних в Access треба:
1. Створити порожню базу даних в MS Access.
2. Вибрати створену базу даних на локальному диску комп'ютера в полі Database.
3. Клацнути кнопку Connect.
4. Відбувається запуск процесу генерації таблиць у вибраній БД (рис. 1.27).
Рис. 1.27. Ілюстрація процесу генерації схеми бази даних
Відкривши створену базу даних в ACCESS, побачимо таку схему (рис. 1.28).
Рис. 1.28. Схема створеної бази даних у ACCESS
На етапі проектування ER-моделі можна було атрибути складеного первинного ключа перенести вниз (не робити первинним), а додати штучний ключ «Код продажу» (рис 1.29).
Рис. 1.29. Фрагмент ER-діаграми зі штучним ключем
Контрольні запитання
1. Охарактеризуйте фізичну модель бази даних.
2. Охарактеризуйте логічну модель бази даних.
3. Охарактеризуйте концептуальну модель бази даних.
4. Поняття зв'язку. Типи зв'язків між таблицями.
5. Поняття ЕR-діаграм.
6. Поняття та призначення первинних та вторинних ключів.
7. Поняття нормалізації.