Моделювання даних 2.4.1. Case-метод Баркера

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

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

Нотація ERD була вперше введена П. Ченом (Chen) і отримала подальший розвиток у роботах Баркера [8]. Метод Баркера буде викладатися на прикладі моделювання діяльності компанії з торгівлі автомобілями. Нижче наведені витяги з інтерв'ю, проведеного з персоналом компанії.

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

Продавець: йому потрібно знати, яку ціну запитувати і яка нижня ціна, за яку можна здійснити операцію. Крім того, йому потрібна основна інформація про машинах: рік випуску, марка, модель і т.п.

Адміністратор: його завдання зводиться до складання контрактів, для чого потрібна інформація про покупця, автомашині і продавця, оскільки саме контракти приносять продавцям винагороди за продажі.

Перший крок моделювання - вилучення інформації з інтерв'ю і виділення сутностей.

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

Рис. 2.18. Графічне зображення сутності

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

Звертаючись до наведених вище витягів з інтерв'ю, видно, що сутності, які можуть бути ідентифіковані з головним менеджером - це автомашини і продавці. Продавцю важливі автомашини та пов'язані з їх продажем дані. Для адміністратора важливі покупці, автомашини, продавці і контракти. Виходячи з цього, виділяються 4 сутності (автомашина, продавець, покупець, контракт), які зображаються на діаграмі наступним чином (малюнок 2.19).

Рис. 2.19.

Наступним кроком моделювання є ідентифікація зв'язків.

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

Зв'язки може даватися ім'я, що виражається граматичним обігом дієслова і поміщається біля лінії зв'язку. Назва кожного зв'язку між двома даними сутностями повинно бути унікальним, але імена зв'язків у моделі не зобов'язані бути унікальними. Ім'я зв'язку завжди формується з точки зору батьків, так що пропозиція може бути утворене з'єднанням імені суті-батька, імені зв'язку, вирази ступеня та імені сутності-нащадка.

Наприклад, зв'язок продавця до контракту може бути виражена таким чином:  продавець може отримати винагороду за 1 або більше контрактів;  контракт має бути ініційований рівно одним продавцем.

Ступінь зв'язку та обов'язковість графічно зображуються наступним чином (малюнок 2.20).

Рис. 2.20.

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

Рис. 2.21.

Описавши також зв'язку інших сутностей, отримаємо наступну схему (рисунок 2.22).

Рис. 2.22.

Останнім кроком моделювання є ідентифікація атрибутів.

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

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

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

Рис. 2.23.

Рис. 2.24.

Кожен атрибут ідентифікується унікальним ім'ям, висловлюваним граматичним обігом іменника, що описує що представляється атрибутом характеристику. Атрибути зображуються у вигляді списку імен усередині блоку асоційованої суті, причому кожен атрибут займає окремий рядок. Атрибути, що визначають первинний ключ, розміщуються згори списку, і виділяються знаком "#".

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

З урахуванням наявної інформації доповнимо побудовану раніше діаграму (малюнок 2.25).

Крім перерахованих основних конструкцій модель даних може містити ряд додаткових.

Підтипи і супертіпи: одна сутність є узагальнюючим поняттям для групи подібних сутностей (малюнок 2.26).

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

Рис. 2.25.

Рис. 2.26. Підтипи і супертіпи

Рис. 2.27. Взаємно виключають зв'язку

рекурсивна зв'язок: сутність може бути пов'язана сама з собою (малюнок 2.28).

Неперемещаемие (non-transferrable) зв'язку: примірник суті не може бути перенесений з одного примірника зв'язку в іншій (малюнок 2.29).

Рис. 2.28. Рекурсивна зв'язок

Рис. 2.29. Неперемещаемая зв'язок Методологія IDEF1

Метод IDEF1, розроблений Т. Ремей (T. Ramey), також заснований на підході П. Чена і дозволяє побудувати модель даних, еквівалентну реляційної моделі в третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створена її нова версія - методологія IDEF1X. IDEF1X розроблена з урахуванням таких вимог, як простота вивчення і можливість автоматизації. IDEF1X-діаграми використовуються поруч поширених CASE-засобів (зокрема, ERwin, Design/IDEF).

Сутність в методології IDEF1X є незалежною від ідентифікаторів або просто незалежною, якщо кожен екземпляр сутності може бути однозначно ідентифікований без визначення його відносин з іншими сутностями. Сутність називається залежною від ідентифікаторів або просто залежною, якщо однозначна ідентифікація примірника суті залежить від його відношення до іншої сутності (малюнок 2.30).

Рис. 2.30. Сутності

Кожній сутності присвоюється унікальне ім'я та номер, що розділяються косою рисою "/" і поміщаються над блоком.

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

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

Зв'язок зображується лінією, що проводиться між сутністю-батьком і суттю-нащадком з крапкою на кінці лінії у сутності-нащадка. Потужність зв'язку позначається як показано на рис. 2.31 (потужність за замовчуванням - N).

Рис. 2.31. Потужність зв'язку

ідентифікує зв'язок між сутністю-батьком і суттю-нащадком зображується суцільною лінією (рисунок 2.32). Сутність-нащадок в ідентифікує зв'язку є залежною від ідентифікатора сутністю. Сутність-батько в ідентифікує зв'язку може бути як незалежною, так і залежною від ідентифікатора сутністю (це визначається її зв'язками з іншими сутностями).

Рис. 2.32. Ідентифікує зв'язок

Пунктирна лінія зображує неідентіфіцірующую зв'язок (малюнок 2.33). Сутність-нащадок в неідентіфіцірующей зв'язку буде незалежною від ідентифікатора, якщо вона не є також сутністю-нащадком в будь-який ідентифікує зв'язку.

Атрибути зображуються у вигляді списку імен усередині блоку сутності. Атрибути, що визначають первинний ключ, розміщуються згори списку, і відділяються від інших атрибутів горизонтальною рискою (малюнок 2.34).

Сутності можуть мати також зовнішні ключі (Foreign Key), які можуть використовуватися як частини або цілого первинного ключа або неключових атрибута. Зовнішній ключ зображується за допомогою приміщення всередину блоку суті імен атрибутів, наслідком яких є букви FK в дужках (малюнок 2.35).

Рис. 2.35. Приклади зовнішніх ключів Підхід, який використовується в CASE-засобі Vantage Team Builder

У CASE-засобі Vantage Team Builder (Westmount I-CASE) [14] використовується один з варіантів нотації П. Чена. На ER-діаграмах сутність позначається прямокутником, що містить ім'я сутності (малюнок 2.36), а зв'язок - ромбом, пов'язаних лінією з кожної з взаємодіючих сутностей. Числа над лініями означають ступінь зв'язку.

Рис. 2.36. Позначення сутностей і зв'язків

Зв'язки є багатонаправленого і можуть мати атрибути (за винятком ключових). Виділяють два види зв'язків:  необов'язкова зв'язок (optional);  слабкий зв'язок (weak).

У необов'язковою зв'язку (малюнок 2.37) можуть брати участь не всі екземпляри сутності.

Рис. 2.37. Необов'язкова зв'язок

На відміну від необов'язковою зв'язку в повною (total) зв'язку беруть участь всі примірники хоча б однієї з сутностей. Це означає, що примірники такий зв'язки існують тільки за умови існування екземплярів іншої сутності. Повна зв'язок може мати одна з 4-х видів: обов'язкова зв'язок, слабкий зв'язок, зв'язок "супертіп-підтип" і асоціативний зв'язок.

Обов'язкова (mandatory) зв'язок описує зв'язок між "незалежної" і "залежною" сутностями. Всі екземпляри залежною ( "обов'язковим") суті можуть існувати тільки за наявності примірників незалежної ( "необов'язковою") сутності, тобто екземпляр "обов'язкової" сутності може існувати тільки за умови існування певного примірника "необов'язковою" сутності.

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

Рис. 2.38. Обов'язкова зв'язок

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

Слабка зв'язок завжди є бінарної і має на увазі обов'язкову зв'язок для "слабкою" сутності. Сутність може бути "слабкою" в одній зв'язку та "сильною" в інший, але не може бути "слабкою" більше, ніж в одній зв'язку. Слабка зв'язок може не мати атрибутів.

Приклад на малюнку 2.39: ключ (номер) рядка в документі може не бути унікальним і має бути доповнений ключем документа.

Рис. 2.39. Слабка зв'язок

Зв'язок "супертіп-підтип" зображена на малюнку 2.40. Загальні характеристики (атрибути) типу визначаються по суті-супертіпе, сутність-підтип успадковує всі характеристики супертіпа. Примірник підтипу існує тільки за умови існування певного примірника супертіпа. Підтип не може мати ключа (він імпортує ключ з супертіпа). Сутність, що є супертіпом в одній зв'язку, може бути підтипом в іншому зв'язку. Зв'язок супертіпа не може мати атрибутів.

Рис. 2.40. Зв'язок "супертіп-підтип"

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

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

Рис. 2.41. Асоціативна зв'язок

Первинний ключ кожного типу сутності позначається зірочкою (*).

ER-діаграма має підпорядковуватися наступних правил:  кожна сутність, кожен атрибут і кожна зв'язок повинні мати ім'я      (зв'язок супертіпа або асоціативний зв'язок може не мати імені);  ім'я суті повинна бути унікальною в рамках моделі даних;  ім'я атрибута повинна бути унікальною в рамках сутності;  ім'я зв'язку повинна бути унікальною, якщо для неї генерується таблиця      БД;  кожен атрибут повинен мати визначення типу даних;  сутність в необов'язковою зв'язку повинна мати ключовий атрибут. Те      ж саме відноситься до сильної сутності в слабкою зв'язку, супертіпу у зв'язку      "супертіп-підтип" і необов'язковою суті в обов'язковій      (повної) зв'язку;  підтип у зв'язку "супертіп-підтип" не може мати ключовий      атрибут;  в асоціативної або слабкою зв'язку може бути тільки одна      асоціативна (слабка) сутність;  зв'язок не може бути одночасно обов'язковою,      "супертіп-підтип" або асоціативної. Література  Вендров А.М. Один з підходів до вибору засобів проектування баз      даних і додатків. "СУБД", 1995, № 3.  Зіндера Е.З. Бізнес-реінжиніринг і технології системного      проектування. Навчальний посібник. М., Центр Інформаційних Технологій, 1996        Калянов Г.М. CASE. Структурний системний аналіз (автоматизація та      застосування). М., "Лорі", 1996.  Марка Д.А., МакГоуен К. Методологія структурного аналізу і      проектування. М., "МетаТехнологія", 1993.  Міжнародні стандарти, що підтримують життєвий цикл програмних      коштів. М., МП "Економіка", 1996  Створення інформаційної системи підприємства. "Computer      Direct ", 1996, N2  Шлеер С., Меллор С. Об'єктно-орієнтований аналіз: моделювання      світу в станах. Київ, "Діалектика", 1993.  Barker R. CASE * Method. Entity-Relationship Modelling. Copyright      Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.  Barker R. CASE * Method. Function and Process Modelling. Copyright      Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.  Boehm B.W. A Spiral Model of Software Development and Enhancement.      ACM SIGSOFT Software Engineering Notes, Aug. 1986  Chris Gane, Trish Sarson. Structured System Analysis.      Prentice-Hall, 1979.  Edward Yourdon. Modern Structured Analysis. Prentice-Hall, 1989.  Tom DeMarco. Structured Analysis and System Specification. Yourdon      Press, New York, 1978.