Мета моделювання даних полягає в забезпеченні розробника ІС концептуальною схемою бази даних у формі однієї моделі або кількох локальних моделей, які відносно легко можуть бути відображені в будь-яку систему баз даних.
Найбільш поширеним засобом моделювання даних є діаграми "сутність-зв'язок" (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 BW 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.