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

ER-модель бази даних

Модель сутність-зв'язок (англ. entity-relationship model, ERM, ER-модель) дозволяє описувати концептуальні схеми предметної області.

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

Як відомо, базовим поняттямРеляційною БД є таблиця (ставлення). Таблиця використовується для структуризації та зберігання інформації. У реляційних БД кожен осередок таблиці містить одне значення. Крім того, всередині однієї БД існують взаємозв'язки між таблицями, кожна з яких задає спільне користуванняданими таблиці.

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

Взаємозв'язок показує, що дані однієї сутності посилаються або пов'язані з іншими даними.

Ступінь кінця зв'язку вказується графічно, множина зв'язку зображується у вигляді "вилки" на кінці зв'язку. Модальність зв'язку також зображується графічно - необов'язковість зв'язку позначається кружком кінці зв'язку. Найменування зв'язку виражається одним дієсловом (рис.13).

Рис.13.

Атрибутисутності записуються всередині прямокутника, що зображує сутність, і виражаються іменником в однині.

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

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

· Жодний з атрибутів первинного ключа не повинен мати нульового значення.

· Значення атрибутів первинного ключа не повинні змінюватись. Якщо значення змінилося, це вже інший екземпляр сутності.

При виборі первинного ключа, зазвичай, в сутність вводиться додатковий атрибут, який ставати ключем.

Так, визначення первинного ключа часто використовують унікальні номери, які можуть автоматично генеруватися системою при додаванні екземпляра сутності в БД. Застосування унікальних номерівполегшує процес індексації та пошуку в БД.

Першим кроком під час створення логічної моделіБД є побудова ER-діаграми, що складається з трьох частин: сутностей, атрибутів та взаємозв'язків.

Розроблено безліч інструментів візуального створення ER - діаграм для різних платформ. У цьому проекті використовувалась розробка MySQL Workbench.

Цей інструмент спрощує проектування баз даних та обслуговування, автоматизує, забирають багато часу і схильні до помилок завдання та покращує зв'язок серед команд розробників та архітекторами БД. Він дозволяє архітекторам даних візуалізувати вимоги, спілкуватися з зацікавленими особамиз питань проектування, перш ніж будуть зроблені інвестиції в проект. Це забезпечує кероване моделлю проектування баз даних, яке є найефективнішою методологією для того, щоб створити реальні та добре продумані бази даних. ER - діаграма бази даних системи дистанційного тестування ( control_tests) зображено малюнку (рис.14). Дві вертикальні рисочки з одного боку і "тризуб" з іншого позначають відповідно "зв'язок один до багатьох".

Мал. 14. ER – діаграма бази даних control_test системи дистанційного тестування


Нормалізація бази даних

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

Проте, деякі канони, правила таки існують. До таких правил ставляться правила нормалізації, тобто. приведення стосунків до нормальної форми.

Типовою формою документування логічної моделі предметної галузіпри ER-моделюванні є діаграми "сутність-зв'язок", або ER-діаграми (Entity Relationship Diagram). ER-діаграма дозволяє графічно представити всі елементи логічної моделі згідно з простими, інтуїтивно зрозумілими, але суворо визначеними правилами. нотаціям.

Для створення ER діаграм зазвичай використовують одну з двох найпоширеніших нотацій.

  • Integration DEFinition for Information Modeling (IDEF1X). Ця нотація була розроблена для армії США та стала федеральним стандартом США. Крім того, вона є стандартом у низці міжнародних організацій (НАТО, Міжнародний валютний фонд та ін.).
  • Інформація Engineering (IE). Нотація, розроблена Мартіном (Martin), Фінкельштейном (Finkelstein) та іншими авторами, використовується переважно у промисловості.

Побудова ER-діаграм зазвичай ведеться з використанням CASE-засобів. У цій лекції у всіх прикладах, якщо це не зазначено особливо, використовуватиметься нотація MS Office Visio 2007.

Сутність на ER-діаграмі представляється прямокутником з ім'ям у верхній частині (рис. 6.3).


Мал. 6.3.Подання сутності "Співробітник" на ER-діаграмі

У прямокутнику перераховуються атрибути сутності, при цьому атрибути, що становлять унікальний ідентифікатор сутності, Наголошуються (рис. 6.4).


Мал. 6.4.Подання сутності "Співробітник" з атрибутами та унікальним ідентифікатором сутності

Кожен екземпляр сутностімає бути унікальним та відрізнятися від інших атрибутів. Одним з основних комп'ютерних способіврозпізнавання сутностей в ІВ є присвоєння сутності ідентифікаторів (entity identifier). Оскільки сутність визначається набором своїх атрибутів, кожної сутності доцільно виділити таке підмножина атрибутів, яке однозначно ідентифікує цю сутність. Часто ідентифікатор сутностіназивають первинним ключем ( primary key).

Первинний ключ (primary key) – це атрибут або група атрибутів, що однозначно ідентифікує екземпляр сутності. Атрибути первинного ключа на діаграмі не вимагають спеціального позначення– це атрибути, які знаходяться у списку атрибутів вище горизонтальній лінії(рис. 6.3).

Вибір первинного ключа може виявитися непростим завданням, Рішення якої в змозі вплинути на ефективність майбутньої ІС. В одній сутності може бути кілька атрибутів або наборів атрибутів, які претендують на роль первинного ключа. Такі претенденти називаються потенційними ключами(Candidate key).

Ключі можуть бути складними, тобто. містять кілька атрибутів. Складні первинні ключі не вимагають спеціального позначення – це список атрибутів вище за горизонтальну лінію.

Розглянемо кандидатів на первинний ключ сутності "співробітник" (рис. 6.5).


Мал. 6.5.Визначення первинного ключа для сутності "працівник"

Тут можна виділити такі потенційні ключі.

  1. Табельний номер.
  2. Номер паспорта.
  3. Прізвище + Ім'я + По-батькові.

Для того, щоб стати первинним, потенційний ключповинен задовольняти низку вимог.

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

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

При виборі первинного ключа перевага має надаватися більше простим ключам, тобто ключам, що містять меншу кількість атрибутів. У прикладі ключі № 1 і № 2 переважно ключа № 3.

Атрибути ключа не повинні містити нульових значень. Якщо допускається, що співробітник може мати паспорта чи замість паспорта мати якесь інше посвідчення особи, то ключ № 2 не підійде на роль первинного ключа. Якщо для забезпечення унікальності необхідно доповнити потенційний ключдодатковими атрибутами, вони не повинні містити нульових значень. При доповненні ключа №3 атрибутом дата народженняНеобхідно переконатися, що дати народження відомі всім співробітників.

Значення атрибутів ключа не повинно змінюватись протягом усього часу існування екземпляра сутності. Співробітниця організації може вийти заміж та змінити як прізвище, так і паспорт. Тому ключі № 2 та 3 не підходять на роль первинного ключа.

Кожна сутність повинна мати, Крайній мірі, один потенційний ключ. Багато сутності мають лише один потенційний ключ. Такий ключ стає первинним. Деякі сутності можуть мати більше одного можливого ключа. Тоді один із них стає первинним, а решта – альтернативними ключами. Альтернативний ключ (Alternate Key) – це потенційний ключ, який не став первинним.

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

Домени призначаються аналітиками та фіксуються в спеціальному документі - словники даних(Data Dictionary). При створенні логічної моделі домени можуть бути специфіковані по суті на ER-діаграмі.

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

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

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

  • для реалізації реляційного ХД потрібно використовувати реляційну або об'єктно-реляційну СУБД, наприклад, MS SQL Server 2008;
  • у більшості реляційних СУБД як мова маніпулювання та опису даних використовується SQL, що підтримує певні стандарти, наприклад, ANSI SQL-92.

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


Мал. 6.6.

У MS Office Visio ім'я зв'язку, ступінь зв'язку (потужність) та клас власності сутностідо зв'язку визначається вкладці "Властивості бази даних", як показано на рис. 6.7. Стрілка на лінії зв'язку вказує на батьківську таблицю.

При виділенні зв'язків акцент робиться на виявлення їх показників. Зв'язок є взаємовідносинами між двома або більше сутностями. Кожен зв'язок реалізується через значення атрибутів сутностейнаприклад, екземпляр сутності"Співробітник" (рис. 6.6) пов'язаний з екземпляром сутності"Освіта" з однаковим значенняматрибутів Табельний номер. Іншими словами, при створенні зв'язку в одній із сутностей, яка називається дочірньою сутністю, створюється новий атрибутзваний зовнішнім ключем (Foreign Key, FK) (на рис. 6.6 це атрибут Табельний номер). Іноді атрибути зовнішнього ключа позначаються символом (FK) після імені.

Зв'язок є логічним співвідношенням між сутностями. Кожен зв'язок має іменуватися дієсловом або дієслівною фразою Ім'я зв'язку (Verb Phrase) – фраза, що характеризує відношення між батьківською та дочірньою сутностями. Ім'я зв'язку висловлює певне обмеження чи бізнес-правило та полегшує читання діаграми. На рис. 6.8 показано надання зв'язку імені.

Існують різні типизв'язків: ідентифікуючий зв'язок (identifying relationship) "один до багатьох", зв'язок "багато до багатьох" та неідентифікуючий зв'язок (non-identifying relationship) "один до багатьох". З типами зв'язків пов'язують різні типи сутностей.

Розрізняють два типи сутностей: залежні(Dependent entity) та незалежні(Independent entity). Тип сутності визначається її зв'язком із іншими сутностями. Ідентифікуючий зв'язок встановлюється між незалежною (батьківський кінець зв'язку) та залежною (дочірній кінець зв'язку) сутностями.

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

Якщо модель створюється за допомогою CASE-засобів, то при генерації БД схеми атрибути первинного ключа отримають ознаку NOT NULL, що означає неможливість внесення запису в таблицю "Співробітники" без інформації про табельному номеріспівробітника.

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

Примірник сутності"Співробітник" може існувати безвідносно до будь-якого екземпляру сутності" Відділ " , т. е. співробітник може у організації і не значитися у якомусь відділі.

Ідентифікуючий зв'язок показується на діаграмі суцільною лінією з жирною точкою на дочірньому кінці зв'язку (див. рис. 6.8), що не ідентифікує пунктирною (див. рис. 6.9).

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

Зв'язок "багато хто до багатьох" має іменуватися двома фразами – в обидві сторони (у прикладі "приймає/лікується"). Це полегшує читання діаграми. Зв'язок на

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

Найбільш часто формалізація уявлень про предметну область здійснюється в рамках моделі «сутності-зв'язку» («об'єкти-зв'язку»). на даному етапіпроектування використовується метод "сутність - зв'язок", який називають також методом "ER-діаграм" ("Essence" - сутність, "Relation" - зв'язок). Цей метод заснований на використанні діаграм, званих відповідно діаграмами ER-екземплярів та діаграмами ER-типу.

ER – діаграма «сутність-зв'язок» є набір безлічі об'єктів та його параметрів, і навіть взаємозв'язків з-поміж них, необхідні виявлення даних, які у подальшому застосовуються функціями проектованої системи.

Основними поняттями методу сутність – зв'язок є такі:

Сутність;

атрибут сутності;

Ключ сутності;

Зв'язок між сутностями;

Ступінь зв'язку;

Клас власності екземплярів сутності;

Діаграми ER-примірників;

Діаграми ER-типу.

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

Атрибут ((від латів. attribuo – приписую) – властивість чи річ, невіддільні від предмета) є логічно неподільний елемент структури інформації, що характеризується безліччю атомарних значень. Це поняття аналогічне поняттю «атрибут» щодо. Примірник об'єкта характеризується сукупністю конкретних значень атрибутів даного типуоб'єкт. Один або деяка група атрибутів об'єкта даного типу можуть виконувати роль ключового атрибута (ключ сутності). В даному курсовому проекті вищезазначені сутності характеризуються атрибутами, такими, як: код_факультету, назва_факультету, код_кафедри, ПІБ_співробітника і т.д.



Ключ сутності – це атрибут або набір атрибутів, що ідентифікують екземпляр сутності (наприклад, код_посади).

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

Ієрархічні;

Однорівневі.

Для підвищення наочності та зручності проектування використовуються графічні засобиуявлення сутності, екземплярів сутності та зв'язків між ними. ER-діаграма представлена ​​у додатку А.


Класифікація зв'язків

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

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

Між таблицями можуть встановлюватися:

Бінарні зв'язки;

тернарні зв'язки;

N-арні зв'язки.

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

1:1 (один до одного);

1: М (один до багатьох);

М:1 (багато до одного);

М: М (багато хто до багатьох).

Зв'язок виду 1:1 утворюється, якщо всі поля зв'язку батьківської та дочірньої таблиці є ключовими. Оскільки значення ключових полях двох таблиць не повторюються, забезпечується взаємно-однозначне відповідність записів з цих таблиць. Самі таблиці, насправді, тут стають рівноправними.

Зв'язок виду 1:М має місце у разі, коли одному запису батьківської таблиці відповідає кілька записів дочірньої таблиці.

Зв'язок М:1 має місце у випадку, коли однієї мул кільком записам основної таблиці ставиться у відповідність один запис додаткової таблиці.

Зв'язок М:М виникає у випадках, коли кільком записам основної таблиці відповідає кілька записів додаткової таблиці.

Аналогічно зв'язку 1:1, зв'язок М:М не встановлює підпорядкованість таблиць. Насправді у зв'язок зазвичай залучено кілька таблиць. При цьому одна таблиця може мати різні видизв'язки з кількома таблицями, утворюючи ієрархію чи «дерево зв'язків» .

У цьому курсовому проекті таблиці пов'язані зв'язками типу 1:М (один до багатьох). Наприклад, таблиця "факультети" є батьківською таблицею по відношенню до дочірньої таблиці "кафедри". Ці таблиці пов'язані ставленням 1:М за допомогою ключа «код_факультету»

  • 2. Економічні інформаційні системи, їх класифікація та інформаційне забезпечення
  • 3. Позамашина організація економічної інформації
  • 6. Трирівнева модель організації бд
  • 7. Ієрархічна модель
  • 8. Мережева модель
  • 9. Основні поняття реляційної моделі даних (відносини, домен, схема відношення, ступінь відношення, декор твору, атрибут, кортеж)
  • 11. Умови реляційної цілісності
  • 13. Етапи проектування баз даних
  • 10. Основні поняття реляційної моделі даних (фундаментальні св-ва відносин, первинний ключ, зв'язування таблиць, зовнішній ключ, схема даних)
  • 12. Пристрої для зберігання баз даних
  • 14. Модель "сутність-зв'язок" (er-модель)
  • 15. Перетворення er-моделі на реляційну модель даних для зв'язків типу 1:1 з обов'язковою участю з обох сторін.
  • 16. Перетворення er-моделі в реляційну модель даних для зв'язків типу 1:1 з обов'язковою участю з одного боку та необов'язковою з іншої сторони.
  • 17. Перетворення er-моделі на реляційну модель даних для зв'язків типу 1:1 з необов'язковою участю з обох сторін.
  • 18. Перетворення er-моделі на реляційну модель даних для зв'язків типу 1:м з обов'язковою участю з боку «багато»
  • 19. Перетворення er-моделі на реляційну модель даних для зв'язків типу 1:м з необов'язковою участю з боку «багато»
  • 34. Адміністрація бази даних. Відновлення бази даних
  • 20. Перетворення er-моделі в реляційну модель даних зв'язків типу m:n.
  • 21. Нормалізація таблиць. Ефективність реляційної бази даних. Перша нормальна форма (1нф).
  • 22. Нормалізація таблиць. Функціональна залежність. Повна та часткова функціональна залежність. Друга нормальна форма (2нф).
  • 23. Нормалізація таблиць. Транзитивна залежність. Третя нормальна форма (3нф).
  • 24. Поняття та можливості системи управління базами даних (субд)
  • 25. Класифікація систем управління базами даних (субд)
  • 26. Системи управління базами знань
  • 27. Віддалена обробка даних
  • 28. Обробка запитів в архітектурі файл/сервер
  • 30. Архітектура системи обробки розподіленої бази данихРаБд
  • 29. Обробка запитів в архітектурі клієнт/сервер
  • 31. Сховища даних
  • 32. Адміністрація бази даних. Користувачі та адміністратор бд
  • 33. Адміністрація бази даних. Захист баз даних
  • 14. Модель "сутність-зв'язок" (er-модель)

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

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

    Важливою характеристикою зв'язку є типзв'язку(кратність). Розглянемо типи вищезгаданих зв'язків. Оскільки один менеджер управляє лише однією філією, то 1-я зв'язок має тип «один-к-одному» (1:1).

    Так як одна філія обробляє кілька рахунків, а кожен рахунок обробляється тільки однією філією, то 2-я зв'язок має тип «один-багатьом» (1: М).

    Так як один рахунок може спільно використовуватися декількома клієнтами і один клієнт може мати кілька рахунків, то третій зв'язок має тип «багато-багатьом» (M: N).

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

    Якщо не кожен екземпляр сутності А пов'язаний з будь-яким екземпляром сутності, то ступінь участі сутності А є необов'язковою. Це зображується на ER-діаграмі чорним кружком, розміщеним на лінії зв'язку біля сутності А.

    Якщо кожен екземпляр сутності А пов'язаний з будь-яким екземпляром сутності, то ступінь участі сутності А є обов'язковою. При цьому на ER-діаграмі чорний кружок на лінії зв'язку міститься у прямокутнику поряд із сутністю А. Напр., зв'язок Співробітник Реєструє Клієнтівмає тип (1:М). При цьому не кожен співробітник реєструє клієнтів (необов'язкова участь), але кожен клієнт реєструється співробітником (обов'язкова участь):

    Кожна із чотирьох сутностей моделі може бути описана своїм набором атрибутів.

    МЕНЕДЖЕР

    Номер менеджера (НМ)

    Номер філії (НФ)

    Стажроботи (СТАЖ)

    Адреса філії (АДР_Ф)

    Спеціальність (СПЕЦ)

    Номер клієнта (ПК)

    Номер рахунку (НС)

    П.І.Б. клієнта (ПІБ_К)

    Тип рахунку (ТИП)

    Адреса клієнта (АДР_К)

    Залишок на рахунку (ОСТ)

    Соціальне становище (СОЦ_П)

    ER-модель разом із наборами атрибутів сутностей може бути прикладом семантичної (концептуальної) моделі предметної області чи концептуальної схеми бази даних.

    1.5 ER-моделювання

    Моделювання даних – це перший крок на шляху проектування БД, це перехід від об'єктів реального світу до комп'ютерної моделіБД.

    ER-модель служить поєднання різних уявлень даних на концептуальному рівні. На основі ER-моделі будуються ER-діаграми, на яких відображаються три основні компоненти ER-моделі: сутності, атрибути, зв'язки.

    1.5.1 Сутності

    Оскільки сутність є об'єктом реального світу, то слова «сутність» і «об'єкт» часто позначають те саме.

    На рівні ER-моделювання під сутністю насправді мається на увазі набір сутностей (entity set), а чи не єдина сутність. Інакше кажучи, сутність в ER-моделюванні відповідає таблиці, а не рядку в реляційному середовищі, окремий рядок в ER-моделі називається екземпляром сутності (entity instance, entity occurrence). Сутність зображується прямокутником, у якому записано ім'я сутності.

    1.5.2 Атрибути

    Атрибути описують властивості сутності. Наприклад, сутність STUDENT включає атрибути NSTBIL (№ студентського квитка), FIO (ім'я студента), KURS (курс) і т.д.

    Мал. 1.24. Атрибути сутності STUDENT у ER-моделі.

    Атрибути мають домени. Домен – це набір можливих значень атрибуту. Наприклад, домен для числового значення середньої оцінкистудента може бути записаний у вигляді інтервалу.

    Первинні ключі у ER-моделі підкреслюються. Якщо є кілька первинних ключів, то наголошуються всі.

    Атрибути можуть бути прості та складові. Складовий атрибут – це атрибут, який може бути розділений на кілька атрибутів. Наприклад, атрибут ADRESS (адреса) може бути поділений на STREET (вулиця), CITY (місто) і т.д.

    Атрибути можуть бути однозначними та багатозначними. Однозначний атрибут – це такий атрибут, який може набувати єдиних значень. Наприклад, ІПН може мати єдине значення у кожної людини. p align="justify"> Однозначні атрибути не обов'язково є простими. Наприклад, серійний номер 78-03-06-137846 є однозначним атрибутом, але водночас це складовий атрибут, т.к. його можна розділити на регіон, в якому виріб було випущено (78), код міста (03), зміну (06), номер виробу (137846).

    Багатозначний атрибут – це атрибут, який може набувати кількох значень. Наприклад, людина може закінчити кілька ВНЗ, мати кілька телефонних номерів.

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

    Похідний атрибут - це атрибут, який не потрібно зберігати в БД, його одержують за допомогою деякого алгоритму. Наприклад, вік службовця можна отримати як ціле значення різниці між поточною датоюта датою народження.

    1.5.3. Зв'язки

    Зв'язки (relationship) – це асоціювання. Сутності, що у зв'язку, називаються учасниками (participants). Як назва зв'язків може використовуватися дієслово або документ. Наприклад, відділом керує службовець, товари надходять виходячи з укладеного договору тощо.

    Зв'язки між сутностями в кількісному співвідношенні можуть бути "один-до-одного", "один-до-багатьом". Для позначення типів зв'язків використовується термін "зв'язок" (connectivity).

    Потужність зв'язку (cardinality) виражає певну кількість екземплярів сутностей, пов'язаних з одним екземпляром пов'язаної сутності. На ER-діаграмі потужність зв'язку не позначається, але в прикладне програмуваннявідомості про max і min кількості примірників сутності можуть стати в нагоді. Наприклад, група не може розпочати заняття, якщо в ній менше 10 студентів.

    Зв'язки встановлюються між сутностями. Якщо сутність залежить від існування однієї чи більше інших сутностей, вона залежить від існування (existence – dependent). Наприклад, якщо співробітники мають утриманців, то для обчислення податків можна встановити зв'язок «співробітник має утриманців». І тут сутність «утриманець» залежить від сутності «співробітник».

    Якщо сутність може існувати поза іншими сутностями, вона незалежна від існування (existence –independent). Наприклад, сутність «деталь» може бути незалежно від сутності «постачальник».

    Якщо одна сутність є незалежною від існування іншої сутності, зв'язок між ними називається слабким зв'язком (weak relationship) або неідентифікованим зв'язком (non – identifying relationship). Слабкі зв'язки мають місце, якщо первинний ключ зв'язаної сутності не містить первинні компоненти сутності, що породжує. Наприклад, є дві сутності COURSE (курс) та CLASS (група), описані як

    COURSE ( CRS-CODE, DEPT_CODE,…)

    CLASS ( CLASS-CODE, CRS_CODE,…)

    Між цими сутностями існує слабкий зв'язок, т.к. атрибут CLASS_CODE є первинним ключем сутності CLASS, тоді як атрибут CRS_CODE сутності CLASS є зовнішнім ключем. Первинний ключ сутності CLASS не успадковує компонент первинного ключа із сутності COURSE. Слабкий зв'язок зображується на ER-діаграмі штриховою лінією.

    Сильний зв'язок (strong relationship), також називається ідентифікованим зв'язком (identifying relationship) має місце, якщо пов'язані сутності залежні від існування. Сильний зв'язок між двома сутностями має місце, коли первинний ключ зв'язаної сутності містить компонент первинного ключа сутності, що породжує. Наприклад, сутності

    COURSE ( CRS-CODE, DEPT_CODE,…)

    CLASS ( CRS_CODE, CLASS-SECTION,…)

    Мають сильний зв'язок, т.к. складовий ключ сутності CLASS включає первинний сутності COURSE. На ER-діаграмі сильні зв'язки є суцільною лінією.

    Необхідно пам'ятати, що порядок, у якому таблиці створюються і завантажуються, має значення. Для даних, наприклад, неможлива ситуація, коли зовнішній ключ таблиці CLASS посилається на таблицю COURSE, що ще не існує. Проблема після послідовності створення таблиць у деяких СУБД немає, доки завантажуються дані. Щоб уникнути порушення цілісності на рівні посилання, у зв'язку 1:М необхідно завантажувати сторону «1» незалежно від того, є вона сильною чи слабкою.

    Участь сутності у зв'язку може бути обов'язковою або необов'язковою. Участь сутності є необов'язковою (optional participation), якщо один екземпляр сутності не вимагає наявності відповідного екземпляра сутності в окремому зв'язку. Наприклад, у зв'язку з курсом (COURSE), створюються групи (CLASS) принаймні, на деяких курсах можуть і створюватися групи. Тобто. екземпляр сутності (рядок) у таблиці COURSE не вимагає обов'язкової наявності відповідного екземпляра сутності у таблиці CLASS. Тому сутність CLASS сприймається як необов'язкова стосовно сутності COURSE. Необов'язковий зв'язок на ER-діаграмі є невеликим гуртком з боку необов'язкової сутності. Існування необов'язковості вказує на те, що для необов'язкової сутності min значенняпотужності зв'язку дорівнює 0.

    Участь сутності у зв'язку є обов'язковою (mandatory participation), якщо один екземпляр сутності обов'язково вимагає відповідного екземпляра сутності в окремому зв'язку. Якщо у сутності не зображено жодного додаткового символу, це означає, що дана сутністьбере участь в обов'язковому зв'язку із пов'язаною сутністю. Min потужність для обов'язкової сутності дорівнює 1.

    а) Сутність CLASS необов'язкова для сутності COURSE

    б) Сутності COURE та CLASS у обов'язковому зв'язку.

    Рис.1.25. Зображення обов'язкового та необов'язкового зв'язків у ER-моделі.

    У термінах проектування БД існування сильного зв'язку між сутністю, що породжує, і пов'язаною з нею сутністю або сутностями асоціюється зі слабкими сутностями.

    Слабкою сутністю (weak entity) називається сутність, яка задовольняє двом умовам:

    умову залежність від існування, тобто. вона не може існувати без сутності, з якою вона пов'язана;

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

    У моделі ER слабкі сутності зображуються невеликими сегментами в кожному з чотирьох кутів прямокутника сутності.

    Мал. 1.26. Слабка сутність у ER-діаграмах.

    Слабка сутність успадковує всі частини первинного ключа свого сильного партнера зв'язку. Саме проектувальник БД вирішує, потрібно чи ні оголошувати суть слабкої.

    Ступінь зв'язку (relationship degree) вказує на кількість асоційованих сутностей. Унарна зв'язок (unary relationship) існує тоді, коли асоціація підтримується всередині єдиної сутності. Бінарний зв'язок (binary relationship) існує тоді, коли асоціюються дві сутності. Тернарна зв'язок (ternary relationship) має місце тоді, коли зв'язуються три сутності. Хоча існують і більше високі ступенізв'язку, вони досить рідкісні і мають особливих назв.

    Якщо сутність має зв'язки із собою, то такий зв'язок називається рекурсивним.

    Мал. 1.27. ER-представлення рекурсивного зв'язку

    Ієрархія узагальнених уявлень (generalization hierarchy), що відображає зв'язки «предок-нащадок». У контексті реляційних БД ієрархія узагальнених уявлень відображає зв'язки між супертипами сутності верхнього рівнята підтипами сутності нижнього рівня. Тобто. супертип містить атрибути, що спільно використовуються, в той час як підтип містить унікальні атрибути.

    Мал. 1.28. Ієрархія узагальнених уявлень.

    Зв'язки успадковуються, тобто. підтип сутності успадковує атрибути та зв'язки від супертипу сутності. Наприклад, всі пілоти, механіки та бухгалтери мають табельні номери, ПІБ, домашню адресу і т.д., але вони можуть мати атрибути, унікальні для їхньої спеціалізації. Іншими словами, супертип набору сутностей зазвичай пов'язаний з декількома унікальними підтипами набору сутностей, що не перетинаються. Такі зв'язки, що не перетинаються, позначаються буквою 'G'.

    Супертип та підтип(и) підтримують зв'язок 1:1. Наприклад, структуру таблиці EMPLOYEE можна замінити двома таблицями, одну з яких представляє супертип EMPLOYEE, іншу – підтип PILOT.

    Деякі супертипи містять підтипи, що перетинаються (overlapping). Наприклад, якийсь співробітник може бути викладачем, але водночас і адміністратором.

    Зв'язки, що перетинаються, відображаються символами 'Gs'.

    Мал. 1.29. Ієрархія узагальнених уявлень з підтипами, що перетинаються.