Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Інфологічне проектування бази даних
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2006
Тип роботи:
Методичні вказівки до лабораторної роботи
Предмет:
Бази даних в інформаційно-комп'ютерних технологіях
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки України
Національний університет "Львівська політехніка"
EMBED Word.Picture.6
“Інфологічне проектування бази даних”
Методичні вказівки до лабораторного заняття з дисципліни
“Бази даних в інформаційно-комп'ютерних технологіях”
для студентів базового напрямку 6.091 “Електронні апарати”
Затверджено на засіданні кафедри ЕЗІКТ
Протокол № ___ від ___ ______ 2006 р.
Львів - 2006
Інфологічне проектування бази даних. Методичні вказівки до лабораторного заняття з дисципліни "Бази даних в інформаційно-комп'ютерних технологіях” для студентів базового напрямку 6.091 “Електронні апарати”/ Укл. Л.К.Гліненко.-Львів; Вид-во Нац. ун-ту "Львівська політехика" , 2006. - 24 с.
Укладач: Л.К.Гліненко, канд. техн. наук, доц.
Відповідальний за випуск – Г.В.Юрчик , канд. техн. наук, доц.
Рецензенти: О.М.Воблий, канд. техн. наук, доц.
І.В.Атаманова, канд. техн. наук, доц.
ІНФОЛОГІЧНЕ ПРОЕКТУВАННЯ БАЗИ ДАНИХ
1. Мета роботи
Вивчення задач та основних кроків і практичне виконання етапу інфологічного проектування бази даних.
2. Теоретичні відомості
2.1. Моделі баз даних
Висока продуктивність СУБД дозволяє ефективно експлуатувати дані у тому випадку, якщо структури даних коректні з точки зору даної СУБД та вимог користувача. Тому проектування БД є основним етапом створення БД.
Процес проектування БД спрощується при застосуванні моделей. Моделі являють собою спрощені абстракції реальних подій та умов, які дають змогу досліджувати характеристики логічних об'єктів (сутностей) та відношень, що можуть між ними створюватися. Якщо моделі не будуть логічно вірними та коректними, то отриманий на їх основі проект БД не буде відповідати вимогам ефективності обробки інформації. Ефективна техніка моделювання даних є передумовою створення ефективно спроектованої БД, що, своєю чергою, є передумовою створення ефективних додатків. І навпаки.
Модель бази даних – це сукупність логічних конструкцій, що застосовується для представлення структури даних та відношень між ними всередині БД. Моделі баз даних підрозділяються на дві категорії: концептуальні моделі та моделі реалізації.
Національний інститут стандартизації США виділяє три різних моделі даних у відповідності з рівнями абстракції: концептуальну, зовнішню та внутрішню. Для відбиття проблем реалізації БД, специфічних для обраної СУБД у внутрішній моделі, до цих рівнів абстракції додається ще один – фізичний.
Концептуальна (понятійна) модель відбиває логічну природу представлених даних, представлення про дані з погляду основних користувачів. Тому у концептуальній моделі основна увага приділяється тому, що представлене у БД, а не тому, як воно представлене. Ця модель відбиває семантику даних, тобто основні логічні об'єкти (сутності) моделі даних, та зв'язки між ними, необхідні та достатні для ефективного застосування інформації з точки зору користувача. Концептуальна модель задає структуру даних на рівні “сутність-зв'язок”; відповідно до концептуальних моделей відносять моделі “сутність-зв'язок” (ER-моделі), у яких об'єкт (сутність) задається її атрибутами, та об'єктно-орієнтовані моделі, у яких об'єкт складається з атрибутів та методів. Оскільки створення концептуальної моделі є метою інфологічного етапу проектування БД, то цю модель деколи називають інфологічною. Деколи як окремий етап інфологічного проектування виділяють побудову користувацької моделі, тобто опису вимог до змісту та операцій з даними з точки зору користувачів БД.
Модель реалізації, на відміну від концептуальної, націлена на відбиття способу представлення (синтаксису) даних у БД. Вона відбиває те, яким чином мають бути реалізовані структури даних, щоб отримати уявлення про те, що ми моделюємо, тобто адекватно відбити семантику моделі. До моделей реалізації БД відносять ієрархічну, мережеву, реляційну та об'єктно-орієнтовану моделі. Створення моделі реалізації БД на рівні певного типу та конкретної СУБД, чи логічної моделі, є метою етапу логічного проектування БД, а у випадку ієрархічних та мережевих БД – і фізичного.
Моделі реалізації за рівнем абстракції підрозділяються на внутрішні, зовнішні та фізичні моделі даних. Внутрішня модель є результатом адаптації концептуальної моделі до обраної СУБД. Іншими словами, внутрішня модель є представленням БД “з поляду” СУБД. Внутрішня модель вимагає, щоб проектувальник привів властивості та обмеження концептуальної моделі у відповідність з обраною моделлю реалізації бази даних. Оскільки, на відміну від концептуальної моделі, внутрішня модель залежить від специфічного програмного забезпечення, вона є програмно залежною.
Зовнішня модель базується на внутрішній і відбиває представлення кінцевого користувача про конфігурацію даних, де під кінцевими користувачами розуміють людей, що застосовують та розробляють прикладні програми. Кінцеві користувачі оперують додатками у певних підрозділах організації. У кожному підрозділі є власна специфіка, система обмежень та вимог, і у кожному з них використовується певна підмножина інформаційного середовища підприємства. Відповідно, прикладні програмісти, що працюють у різних підрозділах, розглядають свою підмножину даних окремо від внутрішньої моделі (як зовнішнє стосовно неї), з якої вони були отримані. Тому з точки зору прикладного програміста бажано, щоб спеціалісти з моделювання всю множину вимог та обмежень розбивали на функціональні модулі, які можна досліджувати в межах структури зовнішніх моделей. У кожну зовнішню модель включаються всі необхідні сутності, зв'язки, процеси та обмеження, визначені даним підрозділом. Зовнішня модель є підмножиною внутрішньої. При цьому, хоча представлення (views) ізольовані один від одного, вони сумісно використовують спільну сутність.
Фізична модель діє на найнижчому рівні абстракції, описуючи способи зберігання інформації на носіях, наприклад, жорстких дисках. Фізична модель вимагає визначення як пристрою фізичного зберігання, так і методу фізичного доступу, необхідного для отримання даних з фізичного носія. Очевидно, що фізична модель є як програмно, так і апаратно залежною. Використовувані структури зберігання залежать від пограмного забезпечення (СУБД, операційна система) та від типу носія, що підтримується комп'ютером. Вибір певного методу доступу до даних дає змогу оптимізувати роботу з БД кожного типу, проте реляційна модель в основному орієнтована на логічний рівень представлення і переважно не вимагає такого детального фізичного моделювання, як БД ієрархічного та мережевого типів.
2.2. Інфологічні моделі
Інфологічний етап проектування БД. Мета інфологічного етапу проектування полягає в одержанні семантичних (концептуальних) моделей, що відбивають предметну область і інформаційні потреби користувачів, поняття про предмети, факти і події, якими буде оперувати дана інформаційна система. Як інструмент для побудови семантичних моделей даних та уніфікованого представлення даних, незалежного від реалізуючого його програмного забезпечення, на етапі інфологічного проектування застосовується неформальна модель "сутність-зв'язок" (entity-relationship model, ER - model). Модель "сутність-зв'язок" ґрунтується на опорній семантичній інформації про реальний світ і призначена для логічного представлення даних у контексті їхнього взаємозв'язку з іншими даними. З моделі "сутність-зв'язок" можуть бути породжені всі існуючі моделі даних (ієрархічна, мережна, реляційна, об'єктна), тому вона є найбільш загальною.
Моделювання предметної області базується на використанні графічних діаграм, що включають невелике число різнорідних компонентів. Модель "сутність-зв'язок" не визначає операцій над даними й обмежується описом тільки їхньої логічної структури.
Основні елементи інфологічних моделей. Основними поняттями ER-моделі є сутність, зв'язок і атрибут. При інфологічному проектуванні бази даних довільний фрагмент предметної області може представляють як множину сутностей, між якими існує деяка множина зв'язків.
Сутність (entity) - це об'єкт, що може бути ідентифікований деяким способом, що відрізняє його від інших об'єктів, це реальний чи уявний об'єкт предметної області, інформація про який повинна зберігатися у базі даних і бути доступною. Приклади: конкретна людина, підприємство, подія і т.д.
Розрізняють такі поняття, як тип (клас) сутності й екземпляр сутності. Набір (тип) сутностей (entity set) - множина сутностей одного типу (тобто сутностей, що мають однакові властивості). Поняття тип сутності відноситься до набору однорідних предметів, подій, осіб, що виступають як єдине ціле. Приклади: усі люди, підприємства, свята і т.д. Набори сутностей не обов'язково повинні бути такими, що не перетинаються. Наприклад, сутність, що належить до набору ЧОЛОВІК, також належить набору ЛЮДИ. Екземпляр сутності відноситься до конкретного об'єкту в наборі. Представлення сутності у діаграмах моделей БД залежить від обраної нотації. У діаграмах ER-моделі сутність представляється у вигляді прямокутника (у нотації Баркера), що містить ім'я сутності. При застосуванні нотацій Чена та нотації типу “пташина лапа” застосовується як представлення сутностей у вигляді прямокутників (на етапі інфологічного, чи концептуального проектування), так і табличне представлення сутностей (на етапі логічного проектування у разі обрання реляційного типу бази даних). Сутність фактично задається множиною атрибутів, що описують властивості всіх членів даного набору сутностей і складають кортеж, що задає екземпляр сутності.
Атрибут - це пойменована характеристика сутності, що визначає її властивості і приймає значення з деякої множини значень (домену). П.Чен визначає атрибут як функцію, що відбиває набір сутностей у набір значень чи у декартів добуток наборів значень. Кожен атрибут забезпечується ім'ям, унікальним у межах сутності. При табличному представленні найменування атрибутів утворюють назви стовпців таблиці. Набір можливих значень атрибуту називають доменом.
Множина з одного чи декількох атрибутів, значення яких однозначно визначають кожен екземпляр сутності, називається ідентифікатором (ключем). З визначення атрибуту за П.Ченом ключем сутності є така група атрибутів, що відображення набору сутностей у відповідну групу наборів значень є взаємно однозначним відображенням. Іншими словами, ключ сутності - це один чи більш атрибутів, які унікально визначають дану сутність. Кожен екземпляр сутності повинен мати хоча б один ідентифікатор (ключ). Якщо ідентифікаторів кілька, один з них вибирається як привілейований, чи первинний, інші вважаються потенційними ключами.
Атрибути підрозділяються на прості та складені. Складений (composite) атрибут – це атрибут, який у подальшому можна розділити на кілька додаткових атрибутів. Наприклад, атрибут Адреса можна розділити на атрибути Поштовий_КОД, МІСТО, ВУЛИЦЯ, ДІМ, КВАРТИРА тощо. Простий атрибут такого розділення не допускає.
За кількістю значень, які можуть приймати атрибути, їх підрозділяють на одно- та багатозначні. Однозначні атрибути приймають лише одне значення, наприклад, кожна людина може мати лише один код ДПА. При цьому однозначні атрибути можуть бути складеними, наприклад АДРЕСА_ПРОПИСКИ. Багатозначні атрибути можуть приймати кілька значень, наприклад, людина може закінчити кілька учбових закладів або мати кілька машин різних марок. У моделі Чена багатозначеі атрибути під'єднують до сутності подвійною лінією.
Атрибути можуть класифікуватися за приналежністю до одного з трьох різних типів: описові, вказівні, допоміжні. Описові атрибути представляють факти, внутрішньо притаманні кожному екземпляру сутності. Атрибути, що вказують, (вказівні атрибути) використовуються для присвоєння імені чи позначення екземплярів сутності. Допоміжні атрибути використовуються для зв'язку екземпляра однієї сутності з екземпляром іншої. Нарешті, можуть існувати похідні (derived) атрибути, тобто атрибути, які не треба зберігати у БД, а можна отримати за допомогою певного алгоритму. Наприклад, вік співробітника СПІВРОБІТНИК_ВІК можна отримати як різницю між біжучою датою та датою народження (СПІВРОБІТНИК_ДАТАНАР). У Access цей вираз матиме вигляд INT((DATE()-СПІВРОБІТНИК_ДАТАНАР)/365).
Атрибути підкоряються строго визначеним правилам (правилам атрибутів), дотримання яких забезпечується при переході від концептуальної до логічної моделі..
Зв'язок (relationship) - це асоціація, установлена між кількома сутностями, яка являє собою абстракцію набору відносин, що систематично виникають між різними видами предметів у реальному світі. Більшість зв'язків відносяться до категорії бінарних і має місце між двома сутностями. У ER-діаграмах ця асоціація є пойменованою і зображеною графічно у вигляді лінії, що поєднує зв'язані сутності.
Серед бінарних зв'язків існують три фундаментальних види зв'язку (типи зв'язності, connectivity): один-до-одного (1:1), один-до-багатьох (1:M), багато-до-багатьох (M:M). Зв'язок один-до-одного (1:1) існує, коли один екземпляр однієї сутності зв'язаний з єдиним екземпляром іншої сутності. Зв'язок один-до-багатьох (1:M) має місце, коли один екземпляр однієї сутності зв'язаний з одним чи більше екземпляром іншої сутності, а кожен екземпляр другої сутності зв'язаний тільки з одним екземпляром першої сутності. Зв'язок багато-до-багатьох (М:N) існує, коли один екземпляр однієї сутності зв'язаний з одним чи більше екземпляром іншої сутності і кожен екземпляр другої сутності зв'язаний з одним чи більше екземпляром першої сутності. Окрім зв'язності, зв'язок характеризується кардинальністю (або степенем чи потужністю зв'язку). Ту кількість сутностей, що може бути асоційована через набір зв'язків з іншою сутністю, називають степенем, або потужністю зв'язку. Цей параметр визначає обов'язковість наявності хоча б одного екземпляру сутності, що приймає участь у зв'язку, а також чисельну кількість цих учасників.
Участь сутності у зв'язку може бути обов'язковою або ні. Участь сутності у зв'язку необов'язкова, якщо один екземпляр сутності не вимагає наявності відповідного екземпляру сутності у окремому зв'язку. Такі зв'язки називаються умовними, або необов'язковими (optional). В умовних зв'язках, на відміну від безумовних, можуть існувати екземпляри сутності, які у зв'язку не приймають участі. Якщо зв'язок умовний по обидва боки, він називається біумовним. Існування необов'язковості (optionality) вказує на те, що для необов'язкової сутності мінімальне значення потужності зв'язку дорівнює 0. Як у діаграмах Чена, так і у діаграмах «пташина лапка», необов'язковий зв'язок показується колом з боку необов'язкової сутності.
Усі зв'язки вимагають описання. Опис повинен містити:
ідентифікатор зв'язку;
формулювання імен зв'язку з погляду кожної сутності, що бере участь у зв'язку;
вид зв'язку (множинність (потужність та зв'язність) і умовність);
формулювання того, як зв'язок був формалізований.
Роль сутності в зв'язку - функція, що виконує сутність у даному зв'язку. Наприклад, у зв'язку БАТЬКО-НАЩАДОК сутності ЛЮДИНА можуть мати ролі "батько" і "нащадок". Вказування ролей у моделі "сутність-зв'язок" не є обов'язковим і служить для уточнення семантики зв'язку.
Набір зв'язків (relationship set) - це відношення між n (причому n не менше 2) сутностями, кожна з який відноситься до деякого набору сутностей.
Приклад:
сутності набори сутностей
------------ ----------------
e1 належить E1
e2 належить E2
. . .
en належить En
тоді [e1,e2,...,en] - набір зв'язків R
Хоча, строго говорячи, поняття "зв'язок" і "набір зв'язків" різні (перший є елементом другого), їх, проте, дуже часто змішують. Тому, ми також будемо часто користатися термінами "зв'язок" маючи на увазі "набір зв'язків" і "сутність" маючи на увазі "набір сутностей".
У випадку n=2, тобто коли зв'язок поєднує дві сутності, він називається бінарним. Доведено, що n-арний набір зв'язків (n>2) завжди можна замінити множиною бінарних, однак перші краще відображають семантику предметної області.
Метою формалізації сутності є визначення її через набір атрибутів та виявлення серед них ключа, що унікально визначає сутність.
Усі сутності відносяться до одного з чотирьох класів:
стрижневі;
асоціативні;
характеристичні;
такі, що позначають.
Стрижнева сутність (стрижень) являє собою незалежну сутність.
Асоціативна сутність (асоціація) - це сутність, що формалізує зв'язок виду M:N між двома чи більше сутностями чи зв'язок виду 1:1 між екземплярами сутностей.
Характеристична сутність (характеристика) являє собою сутність, що формалізує зв'язок виду 1:M чи 1:1. Єдина мета характеристики в рамках розглянутої предметної області полягає в описі чи уточненні деякої іншої сутності.
Сутність, що позначає (позначення) - це сутність, що також формалізує зв'язок виду 1:M чи 1:1 між двома сутностями, але відрізняється від характеристики тим, що не залежить від сутності, яка позначається.
Якщо сутність залежить від існування одної чи більше інших сутностей, то говорять, що вона залежна від існування (existence-dependent). Наприклад, сутність СПІВРОБІТНИК_ДІТИ у БД СПІВРОБІТНИКИ, що фіксує дітей співробітника для обрахування податків, подарунків тощо, та описується атрибутами кількість та вік, є залежною від сутності СПІВРОБІТНИК. Очевидно, що залежні сутності можуть розглядатися як характеристичні. Якщо ж сутність існує незалежно від існування іншої, то вона є незалежною. Незалежні сутності можуть бути як стрижневими, так і позначальними.
Якщо одна сутність незалежна від існування іншої, то зв'язок між ними називається слабим (weak), або неідентифікуючим (non-identifying). З погляду проектування БД слабі зв'язки мають місце тоді, коли первинний ключ зв'язаної сутності не містить первинних компонентів породжуючої сутності. Сильний (strong), або ідентифікуючий (identifying) зв'язок має місце між зв'язаними сутностями, залежними від існування. З погляду проектування БД сильні зв'язки мають місце тоді, коли первинний ключ зв'язаної сутності містить компоненти первинного ключа породжуючої сутності.
До числа більш складних елементів ER-моделі відносяться підтипи і супертипи сутностей. Сутність може бути розщеплена на два чи більш підтипи, що взаємно виключають один одного, кожний з який має спільні атрибути і/чи зв'язки. Ці спільні атрибути і/чи зв'язки явно визначаються один раз на більш високому рівні. У підтипах можуть визначатися власні атрибути і/чи зв'язки. Сутність, на основі якої визначаються підтипи, називається супертипом. Підтипи повинні утворювати повну множину, тобто будь-який екземпляр супертипу повинен відноситися до деякого підтипу. Аналогічно мовам об'єктно-орієнтованого програмування вводиться можливість успадковування типу сутності, виходячи з одного чи декількох супертипів.
У випадку дуже великої кількості сутностей і зв'язків між ними застосовується менш наочна, ніж мова ER-діаграм, але більш змістовна мова інфологічного моделювання, у якій сутності і зв'язки представляються реченнями вигляду:
СУТНІСТЬ (атрибут 1, атрибут 2 , ..., атрибут n)
ЗВ'ЯЗОК [СУТНІСТЬ S1, СУТНІСТЬ S2, ...] (атрибут 1,..., атрибут n).
2.3. Представлення інфологічних моделей у вигляді ER-діаграм
2.3.1. Представлення даних за допомогою моделі "сутність-зв'язок"
Перш, ніж приступати до створення системи автоматизованої обробки інформації, розроблювач повинен сформувати поняття про предмети, факти і події, якими буде оперувати дана система. Для того, щоб привести ці поняття до тої чи іншої моделі даних, необхідно замінити їх інформаційними представленнями. Одним з найбільш зручних інструментів уніфікованого представлення даних, незалежного від реалізуючого його програмного забезпечення, є модель "сутність-зв'язок" (entity - relationship model, ER - model).
Модель "сутність-зв'язок" ґрунтується на деякій важливій семантичній інформації про реальний світ і призначена для логічного представлення даних. Вона визначає значення даних у контексті їхнього взаємозв'язку з іншими даними. Важливим для нас є той факт, що з моделі "сутність-зв'язок" можуть бути породжені всі існуючі моделі даних (ієрархічна, мережева, реляційна, об'єктна), тому вона є найбільш загальною. Модель "сутність-зв'язок" не є моделлю даних у строгому розумінні, оскільки не визначає операцій над даними й обмежується описом тільки їхньої логічної структури.
Модель "сутність-зв'язок" була запропонована в 1976 р. Питером Пин-Шэн Ченом.
Довільний фрагмент предметної області може бути представлений як множина сутностей, між якими існує деяка множина зв'язків. Графічне відбиття цього представлення й утворює ER-діаграму. У процесі цього графічного представлення сутності різного типу відбиваються прямокутниками різної форми та обрамлення; атрибути - зв'язаними відрізками ліній з прямокутниками сутностей овалами або впровадженими всередину прямокутників записами; зв'язки – відрізками ліній, всередині яких може бути введений графічний елемент з текстом, що описує тип зв'язку, а на кінцях – графічне або текстове позначення кардинальності зв'язку. ER-діаграма задає графічне представлення концептуальної схеми БД, конкретний вигляд якого залежить як від предметної галузі та мети створення БД, так і від обраної нотації, тобто стандартизованого способу графічного представлення елементів ER-діаграми. Найчастіше застосовують нотації Чена, Мартіна (пташина лапка), IDEFIX.
Приклад. Розглянемо множину працівників певного підприємства. Кожного з них можна описати за допомогою характеристик табельний номер(number), ім'я (name), вік (age). Відповідно, сутність СПІВРОБІТНИК має атрибути ТАБЕЛЬНИЙ_НОМЕР, ІМ'Я, ВІК. Використовуючи нотацію мови Pascal, цей факт можна представити як:
type employe = record
number : string[6];
name : string[50];
age : integer;
end;
Сутність фактично становить із себе множину атрибутів, що описують властивості всіх членів даного набору сутностей. Надалі для визначення сутності і її атрибутів будемо використовувати інфологічне представлення, яке для сутності СПІВРОБІТНИК набуває вигляду: СПІВРОБІТНИК (ТАБЕЛЬНИЙ_НОМЕР, ІМ'Я, ВІК). Тоді відділи, на які підрозділяється підприємство, і в який працюють співробітники, можна описати як ВІДДІЛ (НОМЕР_ВІДДІЛУ, НАЙМЕНУВАННЯ).
Множину значень (область визначення) атрибуту називають доменом. Наприклад, для атрибута ВІК домен (назвемо його КІЛЬКІСТЬ_РОКІВ ) задається інтервалом цілих чисел більше нуля, оскільки людей з від'ємним віком не буває.
П.Чен визначає атрибут як функцію, що відбиває набір сутностей у набір значень чи у декартів добуток наборів значень. Так, атрибут ВІК здійснює відображення в набір значень (домен) КІЛЬКІСТЬ_РОКІВ. Атрибут ІМ'Я здійснює відображення в декартів добуток наборів значень ІМ'Я, ПРІЗВИЩЕ і ПО_БАТЬКОВІ. Звідси випливає визначення ключа сутності як такої групи атрибутів, що відображення набору сутностей у відповідну групу наборів значень є взаємно однозначним відображенням. Іншими словами, ключ сутності - це один чи більш атрибутів, які унікально визначають дану сутність. У нашому прикладі ключем сутності СПІВРОБІТНИК є атрибут ТАБЕЛЬНИЙ_НОМЕР (звичайно, тільки в тому випадку, якщо всі табельні номери на підприємстві унікальні).
Виходячи з визначення зв'язку (relationship) як асоціації, установлена між кількома сутностями, для розглянутого прикладу можна виділити, наприклад, такі зв'язки:
оскільки кожен співробітник працює в якому-небудь відділі, між сутностями СПІВРОБІТНИК і ВІДДІЛ існує зв'язок "працює у" чи ВІДДІЛ-ПРАЦІВНИК;
тому що один із працівників відділу є його керівником, то між сутностями СПІВРОБІТНИК і ВІДДІЛ є зв'язок "керує" чи ВІДДІЛ-КЕРІВНИК;
можуть існувати і зв'язки між сутностями одного типу, наприклад зв'язок БАТЬКО - НАЩАДОК між двома сутностями ЛЮДИНА;
(Слід зазначити, що в методиці проектування даних є неписане правило, відповідно до якого сутності позначаються за допомогою іменників, а зв'язки - дієслівними формами. Дане правило, однак, не є обов'язковим) .
Не існує загальних правил визначення, що вважати сутністю, а що зв'язком. У розглянутому вище прикладі ми поклали, що "керує" - це зв'язок. Однак можна розглядати сутність "керівник", що має зв'язки "керує" із сутністю "відділ" і "є" із сутністю "співробітник". Зв'язок також може мати атрибути. Наприклад, для зв'язку ВІДДІЛ-ПРАЦІВНИК можна задати атрибут СТАЖ_РОБОТИ_У_ВІДДІЛІ.
Кожний зв'язок характеризується як зв'язністю (чи типом) зв'язку, так і степенем (потужністю, кардинальністю) зв'язку, і ці два поняття не слід плутати. Можуть існувати наступні зв'язності бінарних зв'язків: 1:1, 1:М, М:М. Графічно зв'язність та кардинальність зв'язків відбиваються по-різному у різних нотаціях; найрозповсюдженіші варіанти розглянуто нижче.
Зв'язок один до одного (позначається 1:1 ) означає, що в такому зв'язку сутності з однією роллю завжди відповідає не більш однієї сутності з іншою роллю. У розглянутому нами прикладі це зв'язок "керує", оскільки в кожнім відділі може бути тільки один начальник, а співробітник може керувати тільки одним відділі. Даний факт представлений на наступному малюнку, де прямокутники позначають сутності, а ромб - зв'язок (як це прийнято у нотації Чена). Тому що степінь зв'язку для кожної сутності дорівнює 1, то вони з'єднуються одною лінією (рис. 1).
Рис. 1. Позначення зв'язку типу 1:1 при кардинальностях 0,1:1,1
Іншою важливою характеристикою зв'язку крім її степеня є клас приналежності сутностей, що в неї входять, чи обов'язковість зв'язку. Тому що в кожнім відділі обов'язково повинен бути керівник, те кожній сутності "ВІДДІЛ" неодмінно повинна відповідати сутність "СПІВРОБІТНИК". Однак, не кожен співробітник є керівником відділу, отже в даному зв'язку не кожна сутність "СПІВРОБІТНИК" має асоційовану з нею сутність "ВІДДІЛ". Таким чином, сутність "СПІВРОБІТНИК" має обов'язковий клас приналежності (цей факт позначається також вказівкою інтервалу числа можливих входжень сутності в зв'язок, у даному випадку це 1,1), а сутність "ВІДДІЛ" має необов'язковий клас приналежності (0,1). Тепер даний зв'язок ми можемо описати як 0,1:1,1, і саме цей опис задаватиме кардинальності зв'язку, тобто кількість екземплярів зв'язаної сутності, з якою зв'язаний кожний екземпляр даної сутності. Кожний зв'язок має 2 кардинальності. Кардинальність, проставлена з боку певної сутності, задає діапазон потужностей множини екземплярів сутності, з якими зв'язаний кожний екземпляр даної сутності. Надалі кардинальність бінарних зв'язків ступеня 1 будемо позначати так, як це прийнято в нотації “пташина лапка”, а саме в такий спосіб:
Зв'язок один до багатьох (1 : n ). У даному випадку сутності з однією роллю може відповідати будь-яка кількість сутностей з іншою роллю. Таким є зв'язок ВІДДІЛ-СПІВРОБІТНИК. У кожнім відділі може працювати довільне число співробітників, але співробітник може працювати тільки в одному відділі. Графічно степінь зв'язку n відображається "деревоподібною" лінією, так це зроблено на наступному малюнку. Як видно з рис. 2, між двома сутностями може бути визначено кілька наборів зв'язків.
Рис. 2. Позначення зв'язку типу 1:n (СПІВРОБІТНИК - працює у - ВІДДІЛ), 1,1:0,n (кожний співробітник працює лише у одному відділі, 1:1, кожний відділ може нараховувати скільки завгодно співробітників, у тому числі жодного, 0:n)
необхідно також враховувати клас приналежності сутностей. Кожен співробітник повинен працювати в якому-небудь відділі, але не кожен відділ (наприклад, ново сформований) повинен включати хоча б одного співробітника. Тому сутність "ВІДДІЛ" має обов'язковий, а сутність "СПІВРОБІТНИК" необов'язковий класи приналежності. Кардинальність бінарних зв'язків степеня n будемо позначати так:
Зв'язок багато до багатьох (n : n, або М:М, або N:М). У цьому випадку кожна з асоційованих сутностей може бути представлена будь-якою кількістю екземплярів. Нехай на розглянутому нами підприємстві для виконання кожного контракту (сутність КОНТРАКТ) створюється робоча група, у яку входять співробітники різних відділів. Оскільки кожен співробітник може входити в кілька (у тому числі й у жодну) робочих груп, а кожна група повинна включати не менш одного співробітника, то зв'язок між сутностями СПІВРОБІТНИК і РОБОЧА_ГРУПА має степінь n : n.
Рис. 3. Позначення зв'язку типу n:n
Якщо існування сутності x залежить від існування сутності y, то x називається залежною сутністю (іноді сутність x називають "слабкою", а "сутність" y – “сильною”). Як приклад розглянемо зв'язок між раніше описаними сутностями РОБОЧА_ГРУПА і КОНТРАКТ. Робоча група створюється тільки після того, як буде підписаний контракт із замовником, і припиняє своє існування по виконанні контракту. Таким чином, сутність РОБОЧА_ГРУПА є залежною від сутності КОНТРАКТ. Залежну сутність будемо позначати подвійним прямокутником, а її зв'язок із сильною сутністю - лінією зі стрілкою:
Рис. 4. Позначення залежних і незалежних сутностей
Кардинальність зв'язку з боку сильної сутності завжди буде (1,1). Клас приналежності і степінь зв'язку для залежної сутності можуть бути будь-якими. Припустимо, наприклад, що розглянуте нами підприємство користається кількома банківськими кредитами, що представляються набором сутностей КРЕДИТ (НОМЕР_ДОГОВОРУ, СУМА, ТЕРМІН_ПОГАШЕННЯ, БАНК). По кожному кредитові повинні здійснюватися виплати відсотків і платежі в рахунок його погашення. Цей факт представляється набором сутностей ПЛАТІЖ (ДАТА, СУМА) і набором зв'язків "здійснюється по". У тому випадку, коли одержання запланованого кредиту скасовується, інформація про нього повинна бути вилучена з бази даних. Відповідно, повинні бути вилучені і всі відомості про планові платежі по цьому кредиту. Таким чином, сутність ПЛАТІЖ залежить від сутності КРЕДИТ.
Рис. 5. Сутність ПЛАТІЖ залежна і існує дише у разі існування сутності КРЕДИТ
2.3.2. Порядок побудови інфологічних моделей у вигляді ER-діаграм
Дуже важливою властивістю моделі "сутність-зв'язок" є те, що вона може бути представлена у вигляді графічної схеми. Це значно полегшує аналіз предметної області. Існує кілька стандартизованих варіантів позначення (нотацій) елементів діаграми "сутність-зв'язок", кожний з який має свої позитивні риси. Атрибути із сутностями і сутності зі зв'язками з'єднуються лініями, переважно прямими . Позначення елементів залежать від обраної нотації.
У процесі побудови діаграми можна виділити кілька очевидних етапів:
ідентифікація сутностей, що становлять інтерес, і зв'язків;
присвоєння назв сутностям;
ідентифікація семантичної інформації в наборах зв'язків (наприклад, чи є деякий набір зв'язків відображенням 1:n);
визначення типів сутностей й атрибутів; Визначення зв'язностей, кардинальностей і обов'язковості (умовності) зв'язків;
визначення атрибутів і наборів їхніх значень (доменов);
організація даних у вигляді відносин "сутність-зв'язок";
формулювання зв'язків з погляду кожної сутності, що бере в них участь;
виділення багатозначних атрибутів та вибір способу заміни їх однозначними; Введення додаткових сутностей, якщо це потрібно;
виділення типів та супертипів сутностей, їх дискримінація;
формалізація зв'язків вигляду 1:1, 1:M, M:N;
виділення стрижневих, асоціативних, характеристичних сутностей та сутностей, що позначають;
вибір нотації для представлення моделі;
нанесення на діаграму сутностей, під'єднання до них атрибутів з урахуванням типів;
позначення зв'язків та їх параметрів;
остаточна побудова ER-діаграми.
2.3.3. Нотації, що застосовуються при побудові моделей сутність зв'язок (ER-діаграм)
2.3.3.1. Нотація Чена
Це історично перша і найпростіша нотація, яка широко застосовується при інфологічному проектуванні (табл. 1). Основний її недолік – «перевантаженість» поля діаграми атрибутами для складних БД, перевага – ідентифікація типів атрибутів, простота сприйняття.
Таблиця 1
Позначення елементів при побудові ER-діаграм у нотації Чена
Зв’язок з'єднується з поєднуваними сутностями лініями. Біля кожної сутності на лінії, що з'єднує її зі зв'язком, цифрами вказується кардинальність, як це показано нижче.
Рис. 6. Позначення елементів ER-діаграми у нотації Чена
Представлення фрагменту БД СПІБРОБІТНИКИ для ситуації, коли один співробітник працює лише у одному підрозділі, наведене нижче. Зверху показана зв'язність, нижче – кардинальніфсть зв'язку.
EMBED Visio.Drawing.6
Рис. 7. Фрагмент ER-діаграми у нотації Чена
2.3.3.2. Нотація Мартіна (“пташина лапка”, “crow’s feet”)
Методологія IE (Information Engineering), розроблена Мартіном (Martin), Финкельштейном (Finkelstein) і іншими авторами, використовується переважно в промисловості (табл. 2). Перевага – графічне позначення кардинальності, недолік – необхідність його пам'ятати при читанні діаграми, а також необхідність перебудови діаграми при внесенні коректив у кардинальність.
Таблиця 2
Позначення елементів при побудові ER-діаграм у нотації Мартіна (“пташина лапка”)
Перелік атрибутів приводиться усередині прямокутника, що позначає сутність. Ключові атрибути підкреслюються. Зв'язки зображуються лініями, що з'єднують сутності, вигляд лінії в місці з'єднання із сутністю визначає кардинальність зв'язку (табл. 3).
Таблиця 3
Позначення кардинальності зв'язку при побудові ER-діаграм у нотації Мартіна (“пташина лапка”)
INCLUDEPICTURE \d \z "Модель сущность-связь1_files/Image54.gif"INCLUDEPICTURE \d \z "Модель сущность-связь1_files/Image55.gif"INCLUDEPICTURE \d \z "Модель сущность-связь1_files/Image56.gif"
Ім'я зв'язку вказується на лінії, що його позначає (рис. 8).
Рис. 8. Відбиття зв'язків у нотації Мартіна
2.3.3.3. Нотація IDEFIX
Методологія IDEFІX (табл. 4) була розроблена для армії США і широко використовується в державних установах США, фінансових і промислових корпораціях.
Таблиця 4
Позначення елементів при побудові ER-діаграм у нотації IDEFІX
Список атрибутів наводиться усередині прямокутника, що позначає сутність. Атрибути, що складають ключ сутності, групуються у верхній частині прямокутника і відокремлюються горизонтальною рисою (табл. 5, 6, рис. 9).
Таблиця 5
Позначення зв'язків при побудові ER-діаграм у нотації IDEFІX
Таблиця 6
Позначення кардинальності зв'язку при побудові ER-діаграм у нотації IDEF1X
Рис. 9. Відбиття зв'язків у нотації IDEFІX
Крім того, у IDEFІX уводиться поняття “відношення категоризації”, за змістом еквівалентне розглянутому нами ієрархічному зв'язку. Позначення відношення повної категоризації (сутності-категорії складають повну множину нащадків батьківської сутності) наведене на рис. 10.
Рис. 10. Відношення повної категоризації у нотації IDEFІX
Також може існувати відношення неповної категоризації (сутності-категорії складають неповну множину нащадків спільної сутності), рис. 11.
Рис. 11. Відношення неповної категоризації у нотації IDEFІX
2.3.3.4. Нотація Баркера
Сутності позначаються прямокутниками, усередині яких наводиться список атрибутів. Ключові атрибути відзначаються символом # (решітка). Зв'язки позначаються лініями з іменами, місце з'єднання зв'язку і сутності визначає кардинальність зв'язку (табл. 7, рис. 12).
Таблиця 7
Позначення елементів при побудові ER-діаграм у нотації Баркера
Рис. 12. Відбиття зв'язків у нотації Баркера
Для позначення відношення категоризації уводиться елемент "дуга" (рис. 13).
EMBED Word.Picture.8
Рис. 12. Відбиття відношення категоризації у нотації Баркера
3. Практична реалізація інфологічних моделей баз даних у вигляді діаграм”сутність-зв'язок” за допомогою Microsoft Visio Professional
3.1. Інструменти Microsoft Visio, що використовуються при роботі з БД
Основним інструментом Microsoft Visio Professional, який підтримує розробку, генерацію та аналіз БД, є шаблон Database Model Diagram.
Він дає змогу розробляти, описувати та аналізувати на логічному рівні графи моделей БД у вигляді, зокрема, ER-діаграм (діаграм “сутність-зв'язок”) для реляційних та об'єктно-реляційних БД.
У Microsoft Visio Professional існують 3 основні можливості створення ER-діаграм:
створення діаграм інфологічної моделі комбінуванням форм Microsoft Visio з або без створення окремого користувацького шаблону;
створення діаграм логічної моделі з нуля як документу Microsoft Visio за допомогою шаблонів Database Model Diagram;
виділення і перетягування у Visio схеми даних існуючої БД з наступним її коригуванням або просто дослідженням;
імпортування діаграм логічної моделі БД, створеної в іншій програмі.
Microsoft Visio надає можливість створити інфологічну та логічну моделі БД у вигляді:
ER-діаграми (діаграми “сутність-зв'язок”, шаблон “Entity-Relationship”) ;
об'єктно-реляційної діаграми (діаграми “об'єкт-відношення”, шаблон “Entity-Relationship”);
Express_G схему даних для багаторівневих структур даних в нотації Express (стандарт ISO 10303-11);
ORM-діаграми (Object Role Modeling), тобто моделі БД у вигляді взаємодіючих об'єктів з визначенням ролі кожного з об'єктів (стандарт моделювання даних Object Role Modeling).
3.2. Створення ER-діаграми
Створення ER-діаграми (діаграми “сутність-зв'язок”) полягає у визначенні основних сутностей користувацької моделі даних, визначенні їх атрибутів та зв'язків між ним.
Основним інструментом Microsoft Visio Professional, який підтримує розробку та аналіз БД, є шаблон Database Model Diagram.
Він дає змогу розробляти, описувати та аналізувати на логічному рівні графи моделей БД у вигляді, зокрема, ER-діаграм (діаграм “сутність-зв'язок”) для реляційних та об'єктно-реляційних БД. Шаблони ER- та ER-діаграм підтримують табличне представлення сутностей (об'єктів) та їх атрибутів, характерне для розгорнутих варіантів нотацій Мартіна, IDEFIX та Чена, тобто дозволяють створити логічну модель БД.
Для створення ER-діаграм у різних нотаціях на рівні інфологічної моделі слід скористатися розробленим нами користувацьким шаблоном «Erdiagrams» (“Модель сутність-зв'язок”).
3.3. Створення інфологічних моделей у вигляді ER-діаграм в нотаціях Чена, Мартіна та IDEFIX за допомогою шаблону «Erdiagrams»
Для створення ER-діаграм у різних нотаціях необхідно:
створити новий документ (поле документу) для побудови ER-діаграми.. Для цього в меню File обрати команду New (Новий) і виконати команду Новий малюнок (New drawing). Скорочено послідовність дій має вигляд: File New New drawing, рис. 14;
Рис. 14. Створення інфологічної моделі у вигляді діаграми “сутність-зв'язок” за допомогою користувацького шаблону Erdiagrams Microsoft Visio, крок 1.
відкрити шаблон «Erdiagrams» (File Sttencils Open Stencil активація шаблону шляхом браузингу та клацання по його імені за відповідною адресою, наприклад C\\:Database\Visio\Erdiagrams.vss чи G\:Erdiagrams.vss або прямим набором адреси з клавіатури (рис. 15);
Рис. 15. Виклик користувацького шаблону Erdiagrams
Для того, щоб шаблон і поле документу було видно одночасно, встановіть опцію Tile в меню Window (рис. 15);
Рис. 16. Приведення екрану з проектом діаграми “сутність - зв'язок” до стандартного вигляду при застосуванні шаблону Erdiagrams
обрати нотацію, в якій будете будувати діаграму. Створений нами користувацький шаблон Erdiagrams дозволяє будувати діаграми “сутність -зв'язок” у всіх основних нотаціях, оскільки містить шаблони елементів у різних нотаціях (рис. 17). При виконанні завдання обрання нотації означає вибір шаблонів представлення основних елементів діаграми.
Рис. 17. Елементи користувацького шаблону Erdiagrams
визначити перелік та назви сутностей ER-моделі;
визначити тип кожної з сутностей (залежна (слаба) чи незалежна (сильна));
перетягти шаблони (іконки) відповідних сутностей у відповідній до обраної нотації формі представлення з панелі «Ermodel» на робоче поле документу за методом “drag and drop”;
присвоїти назву кожній з сутностей у відповідності до класу об'єктів, який вона репрезентує. Для цього активувати відповідний прямокутник чи овал сутності і набрати назву з клавіатури. Ім'я сутності можна ввести також через вікно “Встановити ім'я сутності”, що відкривається при клацанні по сутності правої кнопки миші (рис. 18) та активуванні команди Set Entity Name (рис. 19), після чого відкриється діалогове вікно Custom Properties (рис. 19).
Рис. 18. Контекстне меню редагування сутності
Рис. 19. Встановле...
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора