МОДЕЛЬ “сутність-зв’язок”

Як уже згадувалося в розділі 141, одним з найбільш відомих і одержали широке поширення методів семантичного моделювання є метод побудови моделі Сутність-звязок (Або ER-моделі) Цей підхід заснований на використанні моделі сутність-звязок, запропонованої Ченом в 1976 році [146] і з тих пір неодноразово дополнявшейся як самим Ченом, так і багатьма іншими дослідниками (про це можна прочитати, наприклад, в [1418], [1445] – [1447]) Подальше обговорення в цій главі в основному присвячено саме даному підходу (Слід підкреслити, що модель сутність-звязок є далеко не єдиною розширеної моделлю, крім неї, було запропоновано дуже багато інших моделей Зокрема, в [146], [1418], [1430], [1437] і особливо в [1424] наведені загальні ввідні відомості по деяких з них, а в [1427] і [1436] дані ввідні огляди по розглянутій темі)

ER-модель включає аналоги всіх семантичних обєктів, представлених в табл 141,

кожен з яких докладно розглядається далі в цьому розділі Насамперед відзначимо, що в [146] була запропонована не тільки сама ER-модель як така, а й відповідна їй технологія побудови діаграм, одержали назву ER-діаграми Більш докладно ER-діаграми описуються в наступному розділі, а на рис 141 показаний простий приклад подібної діаграми, взятий з [146] Це приклад представлення структури даних деякої вигаданої виробничої компанії (KnowWare, Inc) Він буде корисний при вивченні наступного матеріалу даної глави і детально описується нижче (Це – розширена версія ER-діаграми, наведеної на рис 16 в розділі 1)

Примітка Більшість понять, що розглядаються в наступних підрозділах, добре відомі тим, хто знайомий з реляційною моделлю Але, як буде показано, між використовуваними в цих двох моделях термінами існують певні відмінності

Рис 141 Діаграма моделі сутність-звязок (Скорочена версія для розглянутого прикладу)

Сутності

Робота [146] починається з визначення сутності (Entity) як поняття, яке може бути чітко ідентифікована. При цьому сутності поділяються на звичайні і слабкі Слабкою називається така сутність, існування якої залежить від іншої сутності, тобто вона не може існувати, якщо цієї іншої сутності не існує Наприклад, на рис 141 сутність DEPENDENT (Утриманець працівника) є слабкою, оскільки вона не може існувати (у контексті розглянутої бази даних), якщо не існує відповідної сутності EMPLOYEE (Працівник) Зокрема, якщо відомості про деяке працівника (сутність EMPLOYEE) будуть видалені, то і відомості про всі його утриманців (сутності DEPENDENT) також повинні бути видалені Звичайною називається сутність, яка не є слабкою У даному прикладі сутність EMPLOYEE – звичайна

ПриміткаДеякі автори замість терміназвичайна сутністьзастосовують термін сильна сутність

Властивості

Сутності (і звязку) володіють деякими властивостями (Property) Всі сутності чи звязку одного і того ж типу володіють певними загальними властивостями Наприклад, всі працівники мають табельний номер, імя, зарплату і тд (Примітка У даному прикладі серед властивостей працівника свідомо не згадується номер відділу причина цього розяснюється в наступному підрозділі) Значення властивостей кожного типу витягуються з відповідного безлічі значень, яке в реляційної термінології називається доменом (або типом) Нижче перераховані деякі характеристики властивостей і вказані їх особливості

■&nbsp&nbsp&nbsp Просте або складене властивість Наприклад, властивість імя працівника може бути складеним, якщо його значення складається зі значень простих властивостей імя, по батькові і прізвище.

■&nbsp&nbsp&nbsp Ключове властивість (тобто властивість, яка може виявитися унікальним тільки в певному контексті) Наприклад, імя утриманця певного співробітника зазвичай буває унікальним тільки в контексті даних про це співробітника

■&nbsp&nbsp&nbsp Однозначне або багатозначне свойство3 (тобто в цій моделі допускаються повто ряющіеся групи) Всі властивості, представлені на рис 141, є одне значними Але якщо деякий постачальник (SUPPLIER) матиме кілька раз них офісів, то властивість CITY (Місто) для нього буде багатозначним

■ Відсутнє властивість (тобто властивість невідоме або незастосовні) Ця кон цепция не відображена на рис 141, а її більш докладний опис дано в главі 19

■&nbsp&nbsp&nbsp Базове або похідне властивість Наприклад, загальна кількість деталей визна ленного виду може бути обчислено за допомогою підсумовування обєму окремих поставок даної деталі Ця концепція також не представлена ​​на рис 141 Примітка У контексті ER-моделі деякі автори замість терміна властивість використовують термін атрибут

Звязки

В [146] звязок (Relationship) визначається як асоціація, що обєднує кілька сутностей. Наприклад, між відділами та працівниками існує звязок з імям DEPT_EMP Вона представляє той факт, що в кожному відділі працює певна кількість працівників Так само, як і щодо сутностей (див главу 1), необхідно розуміти принципову різницю між типами та примірниками звязків, проте в неформальному описі такими тонкощами можна знехтувати, що ми і будемо неодноразово робити в майбутньому

Сутності, включені в звязок, називаються її учасниками, а кількість учасників звязку називається її ступенем (Слід зазначити, що в даному випадку визначення терміна ступінь відрізняється від його визначення в реляційної моделі)

Нехай R є типом звязку, що включає тип сутності Е в якості учасника

Якщо кожен екземпляр сутності Е бере участь принаймні в одному примірнику звязку R,

то участь сутності Е у звязку R називається повним, в іншому випадку – частковим

3 Определениеэтоготерминаприведеновподразделе&quotАтрибутысозначениямиввидеотношения&quotраздела 64

Наприклад, якщо кожен працівник обовязково повинен ставитися до певного відділу, то участь сутності EMPLOYEE У ЗВЯЗКУ між працівниками та відділами (DEPT_EMP) є повним З іншого боку, якщо допустима ситуація, коли в деякому відділі (наприклад, новоствореному) не буде жодного працівника, участь сутності

DEPARTMENT У ЗВЯЗКУ DEPT_EMP буде частково

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

Підтипи і супертіпи сутностей

Примітка Представлені в цьому розділі поняття не були включені в оригінальну версію ER-моделі [146] вони були додані пізніше Детальніше про це можна прочитати, наприклад, в [1446]

Кожна сутність має принаймні один тип, але у деякої сутності може бути одночасно кілька типів Наприклад, якщо певні працівники є програмістами (і всі програмісти є працівниками), то можна сказати, що

тип сутності PROGRAMMER (програміст) являє собою підтип типу сутності

EMPLOYEE (працівник) (Або, що еквівалентно, тип сутності EMPLOYEE є супертіптипу сутності PROGRAMMER) Програмісти автоматично мають всі властивості працівників, проте зворотне твердження невірно (наприклад, для програмістів може бути задана властивість володіння мовою програмування , яке в загальному випадку не застосовно до всіх працівників) Аналогічним чином, сутність PROGRAMMER автоматично бере участь у всіх звязках, в яких бере участь сутність EMPLOYEE, проте зворотне твердження також невірно (наприклад, програмісти можуть входити в суспільство компютерних фахівців, в яке інші працівники в загальному випадку не входять) Тому вважається, що підтип успадковує властивості і звязку супертіпа

Зверніть увагу на те, що одні програмісти (сутність PROGRAMMER) можуть бути прикладними програмістами (сутність APPLICATION_PROGRAMMER), а інші – системними програмістами (SYSTEM_PROGRAMMER) Виходячи з цього, можна сказати,

ЩО ТИПИ APPLICATION_PROGRAMMER І SYSTEM_PROGRAMMER

єпідтипами

супертіпа PROGRAMMER і тд Інакше кажучи, сутність-підтип раніше є типом сутності, тому може мати власні підтипи Деякий тип сутності, його безпосередні підтипи, підтипи цих підтипів і тд всі разом утворюють ієрархію типів сутності, приклад якої представлений на рис 142

Тут варто докладно розглянути наведені нижче особливості

1 Оскільки детальне обговорення ієрархії і спадкування типів буде відкладено до глави 20, слід попередити читача, що в даній чолі термін тип має таке ж значення, як і в розділі 5 (тобто він НЕ означає тип сутності)

2 Для читачів, знайомих з СУБД IMS (або який-небудь інший СУБД, в якій використовується ієрархічна структура даних), необхідно відзначити, що иерар хии типів НЕ слід плутати з ієрархіями даних Наприклад, на рис 142 зовсім не мається на увазі, що в розрахунку на одного працівника (EMPLOYEE) є неяк до відповідних програмістів (PROGRAMMER) Навпаки, для одного екзем Пляра типу сутності EMPLOYEE існує не більш одного відповідного примірника типу сутності PROGRAMMER, що представляє того ж працівника в ролі програміста (як було б, якби цей малюнок представляв ієрархію в стилі IMS)

Рис 142 Приклад ієрархії типів сутностей

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

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*