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

1.3. Еволюція моделі „сутність-зв’язок”

    Модель  „сутність-зв’язок” постійно розширюється і модифікується її прихильниками. У зв’язку з наочністю представлення концептуальних схем модель увійшла до складу багатьох CASE-засобів, які також внесли свій внесок до її еволюції [1].

    Детальний огляд історії виникнення та розвитку моделі можна знайти, наприклад, у  роботах Чена та Тхелхеіма [7,8]. За даними досліджень працівників німецького Університету Отто-фон-Гуріке (Otto-von-Guericke University of Magdeburg) на початок 2005 року налічувалось близько 100 модифікацій моделі „сутність-зв’язок”.

    Модель  „сутність-зв’язок” у своїй еволюції пройшла декілька етапів, серед них  виділяють наступні:

• модель „сутність-зв’язок” (entity-relationship model);
• розширена модель „сутність-зв’язок” (extended entity-relationship model або ЕER model);
• модель „сутність-зв’язок” в квадраті (entity-relationship model squared або Е2R model);
• часова модель „сутність-зв’язок” (temporal entity-relationship model або timeER model);
• модель „сутність-зв’язок” високого порядку (higher-order entity-relationship model або HERM).

    В різних джерелах можна зустріти різні  види моделі „сутність-зв’язок”, які  виникали у зв’язку з потребами  моделювання. Чен запропонував класифікацію моделей „сутність-зв’язок”, базуючись  на обмеженнях, що накладаються на зв’язки  та атрибути [6].

    Обмеження, які накладаються на типи зв’язків, породжують два види моделей –  узагальнену модель „сутність-зв’язок” (generalized entity-relationship model) та бінарну модель „сутність-зв’язок” (binary entity-relationship model). Узагальнена модель підтримує багатосторонні типи зв’язків, а бінарна модель – лише бінарні типи зв’язків.

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

    Суттєвий  результат даної роботи у тому, що Чен продемонстрував еквівалентність  між моделями різних видів: модель одного виду може бути представлена моделлю  іншого виду; практично показав трансляції різних видів моделей „сутність-зв’язок”.

    Розширена модель „сутність-зв’язок” з’явилася у 1980-х роках у результаті введення в модель категорії абстракції, що було спричинено швидким розповсюдженням нових типів додатків БД (мультимедійні додатки, інструменти автоматизованої підготовки виробництва, інструменти автоматизованого проектування), і для того, щоб створювати моделі даних для таких БД, потрібно було уточнювати модель „сутність-зв’язок”. Розширена модель „сутність-зв’язок” має засоби для безпосередньої підтримки об’єктно-орієнтованих концепцій. Дана модель включає всі поняття моделі „сутність-зв’язок” та власні поняття.

    Модель  „сутність-зв’язок” та розширена  модель „сутність-зв’язок” мають  деякі обмеження та проблеми при  застосуванні, а саме:

• типи сутностей та атрибути повинні бути чітко розрізнені у моделі, хоча, як відомо при проектуванні, вибір представлення інформації у вигляді типу сутності чи атрибуту залежить від проектанта (тобто носить суб’єктивний характер);
• у випадку подальшої трансформації моделі у реляційну модель виникає потреба нормалізації отриманої реляційної моделі.

    Для того, щоб не виникали ці проблеми, Емблі (Embley), Лінг (Ling) та Ванг (Wang) запропонували  покращену розширену модель „сутність-зв’язок” – модель „сутність-зв’язок” у  квадраті. Дана модель окрім понять моделі „сутність-зв’язок” включає лексичні типи сутностей (lexical entity type), в ній не потрібно розрізняти при моделюванні атрибути та типи сутностей, нарешті, модель безпосередньо підтримує нормалізацію (на своєму рівні).

    Широкий діапазон відомих моделей керують  інформацією, яка змінюється у часі. Тому багато моделей фокусуються  не тільки на структурному аспекті  інформації, а й на поведінковому  аспекті. Це спричинило появу часової моделі „сутність-зв’язок”, яка є надбудовою розширеної моделі „сутність-зв’язок” за визначенням Елмасрі та Наватхе. Часова модель „сутність-зв’язок” забезпечує вбудовану підтримку для збору часових аспектів сутностей, зв’язків, атрибутів, сутностей суперклас, сутностей підклас.

    У 1992 р. Тхелхеім запропонував модель „сутність-зв’язок” високого порядку. Схему даної моделі можна автоматично транслювати  в схеми класичних моделей  даних (реляційну, ієрархічну та мережеву). Модель „сутність-зв’язок” високого порядку містить всі концепції  попередніх моделей та власні, а  саме типи зв’язків високого порядку (higher-order relationship types), оператори (наприклад, insert, delete, update, conditional operations) та обмеження цілісності узагальненої складності (integrity constraints the generalized complexity). В даній моделі використовуються абстрактні типи даних і вона базується на об’єктно-орієнтовному моделюванні.

    У зв’язку з активними дослідженнями  в області концептуального моделювання  у 1979 р. було організовано першу міжнародну конференцію „Підхід сутність-зв’язок” (International Conference on the Entity Relationship Approach), яка  відбулась в США у Лос Анжелесі. З 1996 року вона проходе під назвою „Концептуальне моделювання” (International Conference on Conceptual Modeling).

1.4. Проблеми побудови моделей „сутність-зв’язок”

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

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

    Приклад. Розглянемо такі зв'язки: на факультеті навчається багато студентів, до складу факультету входить багато груп (рис. 1.1). Ці зв'язки вірно відображають зміст предметної області, але при спробі з'ясувати, в яких групах навчаються конкретні студенти, виникають проблеми. Із сутності Факультет виходять два зв'язки 1:М.

    Усунути цю проблему можна шляхом перебудови моделі для представлення правильної взаємодії цих сутностей (рис. 1.2).

Рис. 1.1. Приклад дефекту розгалуження в ЕR-моделі 

    Рис. 1.2. Усунення дефекту розгалуження в прикладі ЕR-моделі

    Отже, тепер відповідь на попереднє  питання не є проблемою.

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

    Приклад. Розглянемо такі зв'язки: до складу факультету входить багато кафедр, кожна кафедра може відповідати за декілька комп'ютерних класів (від 0 до М) (рис. 1.3). Тобто, деякі кафедри можуть не бути відповідальними за комп'ютерний клас. У свою чергу комп'ютерний клас може підпорядковуватися певній кафедрі, а може підпорядковуватися безпосередньо факультету (факультетський комп’ютерний клас). Ці зв'язки вірно відображають зміст предметної області, але при спробі з'ясувати, які комп'ютерні класи підпорядковані певному факультету, виникають проблеми. Зв'язок між сутностями Кафедра і Комп'ютерний клас передбачає необов'язкову участь сутностей, і він є частиною шляху між сутностями Факультет і Кафедра.

    Усунути цю проблему можна шляхом введення додаткового зв'язку між сутностями Факультет і Комп'ютерний клас (рис. 1.3).

Рис. 1.3. Приклад дефекту розриву в  ЕR-моделі 

 

    Рис. 1.4. Усунення дефекту розриву в  прикладі ЕR-моделі 

1.5. Області застосування моделей „сутність-зв’язок”

    На  сьогоднішній день не можливо уявити будь-яку сферу діяльності без інноваційних систем в тому числі і інформаційних систем. Всюди, де це тільки можливо (бізнес, торгівля, економіка, сфера послуг і т.д.) зайняли своє місце обчислювальні пристрої для полегшення обчислення і пошуку інформації. І майже в усіх цих сферах присутні бази даних, оскільки з ними користувачу набагато легше і швидше працювати з інформацією. Всі вони чимось схожі, але водночас вони різні. Для того, щоб створити базу даних спочатку необхідно визначитися з предметною областю. Після цього починається проектування самої БД та концептуальне проектування. З концептуального проектування починається створення концептуальної схеми БД, в основі якої лежить концептуальна модель даних. Концептуальна модель даних представляє загальний погляд на дані та їх структуру. Найбільш поширенішою семантичною моделлю є модель „сутність-зв’язок”.

      Перш, ніж приступати до створення системи  автоматизованої обробки інформації, розробник повинен сформувати поняття про предмети, факти і події, якими буде оперувати дана система. Для того, щоб привести ці поняття до тої чи іншої моделі даних, необхідно замінити їх інформаційними представленнями. Одним з найбільш зручних інструментів уніфікованого представлення даних є модель "сутність-зв'язок" (entity - relationship model, ER - model). Модель "сутність-зв'язок" ґрунтується на деякій важливій семантичній інформації про реальний світ і призначена для логічного представлення даних. Вона визначає значення даних у контексті їхнього взаємозв'язку з іншими даними. Важливим є той факт, що з моделі "сутність-зв'язок можуть бути породжені всі існуючі моделі даних (ієрархічна, мережева, реляційна, об'єктна), тому вона є найбільш загальною. Модель "сутність-зв'язок" не є моделлю даних у строгому розумінні, оскільки не визначає операцій над даними й обмежується описом тільки їхньої логічної структури.

      ER-діаграма  задає графічне представлення  концептуальної схеми БД, конкретний  вигляд якого залежить як від  предметної галузі та мети  створення БД, так і від обраної  нотації, тобто стандартизованого  способу графічного представлення  елементів ER-діаграми. Найчастіше  застосовують нотації Чена, Мартіна  (пташина лапка), IDEFIX.

 

РОЗДІЛ 2. CASE ТЕХНОЛОГІЇ РОЗРОБКИ ТА ПІДТРИМКИ МОДЕЛЕЙ  „СУТНІСТЬ-ЗВ’ЯЗОК”

2.1. Характеристика CASE технологій

    Проблеми  автоматизації проектування інформаційних  систем викликали необхідність в  програмно-технологічних засобах  спеціального класу – CASE-засобах (Computer Aided Software Enginnering). CASE-технологія являє  собою сукупність методів проектування програмного забезпечення, а також  набір інструментальних засобів, які  дозволяють у наочній формі моделювати предметну область, аналізувати  цю модель на всіх стадіях розробки і супроводження програмного  забезпечення і розробляти застосування згідно з інформаційними потребами  користувачів [6].

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

    Переваги  від застосування CASE-технологій при  проектуванні інформаційних систем такі:

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

    У таблиці 2.1 наведено порівняння якісних  змін процесу розробки інформаційної  системи при переході до використання CASE-засобів. 

    Порівняння  трудомісткості традиційної  розробки інформаційної  системи і розробки із застосуванням CASE-засобів

    Таблиця 2.1