Модель „сутність-зв’язок”: основні концепції, області застосування, CASE-засоби підтримки
ЗМІСТ
ВСТУП 3
РОЗДІЛ 1. ОГЛЯД МОДЕЛІ „СУТНІСТЬ-ЗВ’ЯЗОК” 4
1.1. Проблема стандартизації моделі „сутність-зв’язок” 4
1.2. Уточнення моделі „сутність-зв’язок” 7
1.3. Еволюція моделі „сутність-зв’язок” 10
1.4. Проблеми побудови моделей „сутність-зв’язок” 12
1.5. Області застосування моделей „сутність-зв’язок” 14
РОЗДІЛ 2. CASE ТЕХНОЛОГІЇ РОЗРОБКИ ТА ПІДТРИМКИ МОДЕЛЕЙ „СУТНІСТЬ-ЗВ’ЯЗОК” 16
2.1. Характеристика CASE технологій 16
2.2. Програмні засоби, які підтримують модель „сутність-зв’язок” 21
ВИСНОВКИ 25
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 26
ВСТУП
Впровадження інформаційних технологій зробило можливим значно підвищити ефективність роботи підприємств, організацій, проведення наукових досліджень, підвищити якість роботи в різних галузях освіти, науки, культури. Широке практичне використання технологій баз даних обумовлене значними досягненнями у цій галузі провідними комп’ютерними компаніями світу, потребами суспільства в ефективних засобах зберігання і обробки інформації.
Сучасні технології БД є одним з визначальних факторів успіху у будь-якій сфері бізнесу, забезпечуючи збереження корпоративної інформації: представлення даних для користувачів та клієнтів у середовищі Word Wide Web і підтримку багатьох інших процесів, зокрема планування та адміністрування виробництва.
Управління освітнім процесом також потребує автоматизації: сучасне суспільство змінює свої вимоги до підготовки фахівців значно швидше, ніж це було у минулому столітті. Оскільки невід’ємною частиною створення бази даних є її концептуальне проектування, то досить актуальною постає задача (проблема) створення моделі „сутність-зв’язок”.
Отже, метою курсової роботи визначено дослідження: основних концепцій моделі „сутність-зв’язок”, областей застосування, case-засобів підтримки.
Для досягнення мети сформульовано такі завдання:
- Ознайомитися із структурою моделі „сутність-зв’язок”;
- Визначити основні об’єкти моделі „сутність-зв’язок”;
- Дослідити case-засоби підтримки.
Об’єктом даного дослідження є структура даних та обмеження цілісності моделі „сутність-зв’язок” і case-засоби, що підтримують цю модель.
Предметом даного дослідження є безпосередньо модель „сутність-зв’язок”.
РОЗДІЛ 1. ОГЛЯД МОДЕЛІ „СУТНІСТЬ-ЗВ’ЯЗОК”
1.1. Проблема стандартизації моделі „сутність-зв’язок”
Модель „сутність-зв’язок” – це модель даних, яка використовується при проектуванні різноманітних моделей (інформаційних систем, баз даних (БД), архітектур комп’ютерних додатків та інших систем) і є високорівневою концептуальною моделлю. Дана модель ґрунтується на деякій важливій семантичній інформації про реальний світ. Вона представляє графічну нотацію, за допомогою якої можна описувати об’єкти логічних моделей даних та відношення між об’єктами [1].
Модель
„сутність-зв’язок” використовують
при концептуальному
Модель „сутність-зв’язок” була запропонована Пітером Ченом (Chen) у 1976 р. з метою впорядкування задачі проектування моделей. Дана модель задовольняє двом важливим умовам:
- потужність її засобів дозволяє досить адекватно описувати структуру різноманітних предметних областей;
- розрив між можливостями моделі і CASE-засобів (Computer Aided Software Engineering1), що її підтримують, не є надто великим.
На сьогоднішній день не існує єдиного загальноприйнятого стандарту для моделі „сутність-зв’язок”, але є набір загальних конструкцій, які лежать в основі більшості варіантів моделі. Дана ситуація виникла через те, що різні автори пропонують свої елементи моделі та відповідну термінологію (семантику цих елементів). Через це розробники БД застосовують той чи інший підхід до побудови моделі.
Ще одна проблема пов’язана з неоднозначним трактуванням термінів під час перекладу. Так ситуація на російсько- та україномовному інформаційному просторі додатково ускладнюється неякісним перекладом навчальної та наукової літератури. У різних джерелах [4,5] для одного і того самого поняття використовують різні терміни, які часто не відповідають його змісту.
У табл. 1 наведено варіанти назв ключових понять, що зустрічаються в доступній російськомовній літературі [4,5]; термінологія, що використовується в поясненнях, слідує оригінальним сучасним роботам Тхелхеіма (Thalheim), Елмасрі (Elmasri) і Наватхе (Navathe).
В роботі буде використовуватися оригінальна термінологія Тхелхеіма (Thalheim), Елмасрі (Elmasri) і Наватхе (Navathe) – 5 варіант з нищенаведеної таблиці.
Незважаючи на те, що модель „сутність-зв’язок” є високорівневим представленням, вона не дає однозначного рішення для визначення проектантом своїх вимог до об’єктів моделі. Так, не завжди можна очевидно визначити, до якого елементу моделі можна віднести певний об’єкт (до типу сутності, типу зв’язку або атрибуту). Аналіз предметної області та побудова її моделі є суб’єктивним процесом, тому проектанти можуть створювати різні, але досить допустимі інтерпретації одного і того ж факту. Вибір варіанту побудови моделі в значній мірі залежить від проектанта. Слід зауважити, що атрибут реалізувати значно простіше ніж тип сутності або тип зв’язку.
Відсутня абсолютна різниця між типами сутностей, типами зв’язків та атрибутами. Наприклад, атрибут є таким (власне атрибутом) тільки тоді, коли пов’язаний з деяким типом сутності або типом зв’язку, в іншому контексті атрибут може виступати як самостійний тип сутності.
Таблиця 1.1
Ключові поняття моделі „сутність-зв’язок” та їхні назви
| Поняття (змістовне пояснення) |
1 варіант | 2 варіант | 3 варіант | 4 варіант | 5 варіант |
| Тип сутності (entity type – складається, містить, породжує свої екземпляри) | Тип сутності | Множина сутності | Тип сутності | Клас сутності | Тип сутності |
| Екземпляр сутності (entity occurrence – належить своєму типу сутності, породжується своїм типом сутності) | Екземпляр сутності | Екземпляр сутності | Сутність | Екземпляр сутності | Сутність |
| Множина сутності (entity set – конкретний набір екземплярів типу сутності в деякий момент часу) | – | – | – | – | Множина сутності |
| Атрибут (attribute) | Властивість | Атрибут | Атрибут | Атрибут | Атрибут |
| Тип зв’язку (relationship type – складається, містить, породжує свої екземпляри) | Тип зв’язку | Зв’язок | Тип зв’язку | Клас зв’язку | Тип зв’язку |
| Поняття
(змістовне пояснення) |
1 варіант | 2 варіант | 3 варіант | 4 варіант | 5 варіант |
| Екземпляр зв’язку (relationship occurrence – належить своєму типу зв’язку, породжується своїм типом зв’язку) | Екземпляр зв’язку | Екземпляр зв’язку | Зв’язок | Екземпляр зв’язку | Зв’язок |
| Множина зв’язку (relationship set – конкретний набір екземплярів типу зв’язку в деякий момент часу) | – | – | – | – | Множина зв’язку |
Дана неоднозначність, зокрема, суттєво ускладнює роботу під час злиття локальних моделей в єдину глобальну модель, в яких вказані методи злиття локальних моделей та шляхи виходу з різних неоднозначностей, що виникають під час злиття.
Аналізуючи питання побудови (проектування) моделі, Голстейн (Goldstein) і Сторей (Storey) в роботі “Some findings on the intuitiveness of entity-relationship constructs” вказують на те, що поняття моделі „сутність-зв’язок” не такі вже й легкі для розуміння і застосування початківцями (не професіоналами у сфері проектування, або тими, що тільки починають вчитися проектувати). Дану роботу корисно опрацювати для того, щоб ознайомитися з типами невідповідностей між проектом (певною предметною областю) та його концептуальною моделлю, наприклад:
- пропущені елементи проекту у моделі;
- у моделі присутні елементи, які не мають аналогів у проекті;
- використання менш „підходящих” понять моделі „сутність-зв’язок” для відображення елементів проекту (часто ця невідповідність носить суб’єктивний характер, про що зазначалося вище).
У роботі проводиться аналіз різних типів невідповідностей та вказуються шляхи їх виправлення.
З
вищевикладеного видно, що при використанні
моделі „сутність-зв’язок” існує
ряд принципових проблем, які
спричиняються відсутністю
1.2. Уточнення моделі „сутність-зв’язок”
Розглядаючи модель „сутність-зв’язок”, будемо спиратися на формальне означення „модель даних”, дане Коддом [1]. Так, модель даних визначається як сукупність (1) колекції типів (де тип – це множина значень), (2) колекції операцій над екземплярами цих типів і (3) колекції застосовуваних до типів та операцій обмежень цілісності.
Будь-яка розвинена модель (даних) включає в себе три компонента:
- опис структури даних (структурна частина);
- опис обмежень цілісності;
- опис операцій над даними (маніпуляційна частина).
Розглядати модель та її уточнення доцільно в декілька етапів:
- розгляд та уточнення структури даних (сутності, типу сутності, слабкого типу сутності, сильного типу сутності, типу сутності підклас, типу сутності суперклас і т.д.);
- розгляд та уточнення обмежень цілісності (обмеження кардинальності типів зв’язку, обмеження кардинальності атрибутів, обмежень на значення атрибутів, ключів і т.д.);
- розгляд та уточнення операцій над даними (операцій вибірки, теоретико-множинних операцій, операцій дій над даними і т.д.).
В літературі уточнення моделі „сутність-зв’язок” здійснюють на основі математичних понять (теорії множин, теорії графів). Деякі автори при уточненні моделі використовують поняття теорії реляційних баз даних.
В подальших розділах уточнення понять моделі будуть проводитися на теоретико-множинній основі.
Відомо, що не має єдиної загальноприйнятої алгебри і числення для моделі „сутність-зв’язок”, які існують, наприклад, для реляційної моделі.
При побудові алгебр моделі „сутність-зв’язок” існують різні підходи та відповідні класи алгебр, наприклад:
- багатосортні алгебри (наприклад, алгебра для бінарної направленої моделі „сутність-зв’язок”);
- алгебри в класичному розумінні (наприклад, алгебра для так званої комплексної (complex) моделі „сутність-зв’язок”);
- модифікації реляційної алгебри.
Поряд з алгебрами моделі „сутність-зв’язок” існують також числення цієї моделі, які, звісно, будуються на основі відповідних алгебр; наприклад, є числення комплексної моделі „сутність-зв’язок”, реляційне числення моделі „сутність-зв’язок”.
Модель
даних втрачає свою користь, якщо
вона не супроводжується мовою
Серед мов маніпулювання даними моделі „сутність-зв’язок” виділяють наступні види:
- природні мови маніпулювання даними (наприклад, GORDAS, ERROL і DESPATH);
- графічні мови маніпулювання даними (наприклад, HIQUEL та мови, запропоновані Елмасрі та Ларсеном (Larsen), Мендельсоном (Mendelzon) та Зхангом (Zhang)).
Розглядаючи мови маніпулювання даними моделі „сутність-зв’язок”, зазначимо, що багато таких мов не має чіткої семантичної основи, тобто відповідної алгебри (зокрема, числення).
Існують мови, які мають чітку формальну семантику. Серед таких мов виділяють високорівневу мову NETUL та SQL-подібну мову SQL/EER .
Семантичними основами для мови NETUL є формальні структури даних, подібні мережам. Ключовою ідеєю визначення семантики мови SQL/EER є відображення SQL/EER-запитів в еквівалентні запити формального числення кортежів. Дані мови підтримують агрегатні функції.
Як
зазначалось вище, на сьогоднішній
день не існує єдиного
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). В даній моделі використовуються абстрактні типи даних і вона базується на об’єктно-орієнтовному моделюванні.
У
зв’язку з активними
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. Області застосування моделей „сутність-зв’язок”
На сьогоднішній день не можливо уявити будь-яку сферу діяльності без інноваційних систем в тому числі і інформаційних систем. Всюди, де це тільки можливо (бізнес, торгівля, економіка, сфера послуг і т.д.) зайняли своє місце обчислювальні пристрої для полегшення обчислення і пошуку інформації. І майже в усіх цих сферах присутні бази даних, оскільки з ними користувачу набагато легше і швидше працювати з інформацією. Всі вони чимось схожі, але водночас вони різні. Для того, щоб створити базу даних спочатку необхідно визначитися з предметною областю. Після цього починається проектування самої БД та концептуальне проектування. З концептуального проектування починається створення концептуальної схеми БД, в основі якої лежить концептуальна модель даних. Концептуальна модель даних представляє загальний погляд на дані та їх структуру. Найбільш поширенішою семантичною моделлю є модель „сутність-зв’язок”.
Перш,
ніж приступати до створення системи
автоматизованої обробки
ER-діаграма
задає графічне представлення
концептуальної схеми БД, конкретний
вигляд якого залежить як від
предметної галузі та мети
створення БД, так і від обраної
нотації, тобто
РОЗДІЛ 2. CASE ТЕХНОЛОГІЇ РОЗРОБКИ ТА ПІДТРИМКИ МОДЕЛЕЙ „СУТНІСТЬ-ЗВ’ЯЗОК”
2.1. Характеристика CASE технологій
Проблеми
автоматизації проектування інформаційних
систем викликали необхідність в
програмно-технологічних
Методологія CASE-технологій ґрунтується на спадному підході до проектування і дає змогу стежити за всіма етапами життєвого циклу інформаційної системи або її окремих задач. Сутність спадного підходу до проектування полягає в тому, що під час реалізації системи її характеристики конкретизуються все більше і більше.
Переваги від застосування CASE-технологій при проектуванні інформаційних систем такі:
- прискорюється та полегшується процес розробки, підвищується якість розроблюваних інформаційних систем;
- з’являється можливість перенесення застосувань із середовища однієї СУБД в іншу за рахунок перетворення концептуальної моделі на фізичну і навпаки;
- з’являється можливість проведення більш досконалого моделювання системи на початкових етапах розробки.
У
таблиці 2.1 наведено порівняння якісних
змін процесу розробки інформаційної
системи при переході до використання
CASE-засобів.
Порівняння трудомісткості традиційної розробки інформаційної системи і розробки із застосуванням CASE-засобів
Таблиця 2.1
| Традиційна розробка | Розробка
з використанням
CASE-засобів |
| Основні зусилля на кодування і тестування | Основні зусилля на аналіз і проектування |
| “Паперові” специфікації | Швидке ітераційне прототипування |
| Ручне кодування | Автоматична генерація коду |
| Ручне документування | Автоматична генерація документації |
| Тестування кодів | Автоматичний контроль проекту |
| Супроводження кодів | Супроводження специфікацій проектування |

- Модель теории фирмы и ее свойства
- Модель универсального программатора
- Модель управления
- Модель управления в России: состояние и пути совершенствования
- Модель управления в таможенных органах
- Модель управления запасами с фиксированным размером запаса
- Модель управления запасами, учитывающая скидки
- Модель современной библиотеки
- Модель Солоу с производственной функцией Кобба - Дугласа
- Модель социальной организации предприятия
- Модель социальной службы помощи семье и детям
- Модель спроса и предложения
- Модель стратегического менеджмента
- Модель стратегического состояния организации (стратегический куб)