Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /var/www/nelvin/data/www/ebooktime.net/index.php:6) in /var/www/nelvin/data/www/ebooktime.net/index.php on line 7

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /var/www/nelvin/data/www/ebooktime.net/index.php:6) in /var/www/nelvin/data/www/ebooktime.net/index.php on line 7
5.1.3. Інфологічна модель даних «Сутність-зв’язок». Основні поняття : Автоматизоване робоче місце менеджера : Бібліотека для студентів

5.1.3. Інфологічна модель даних «Сутність-зв’язок». Основні поняття


Повернутися на початок книги
1 2 3 4 5 6 7 8 9 10 11 12 13 14 
15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 
30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 
45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 
60 61 62 63 64 65 66 67 68 69 

магниевый скраб beletage

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

Частина 5 РОЗРОБКА АВТОМАТИЗОВАНИХ РОБОЧИХ МІСЦЬ

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

Сутністю можуть бути люди, місця, літаки, рейси, смак, колір і т.ін. Необхідно розрізняти такі поняття, як тип сутності та зразок сутності. Поняття тип сутності відноситься до набору однорідних осіб, предметів, подій або ідей, які є цілим. Зразок сутності відно-ситься до конкретної речі в наборі. Наприклад, типом сутності може бути МІСТО, а зразком — Москва, Київ і т.ін.

Атрибут — пойменована характеристика сутності. Його на-йменування повинне бути унікальним для конкретного типу сутності, але може бути однаковим для різного типу сутності (наприклад, КОЛІР може бути визначений для багатьох сутнос-тей: СОБАКА, АВТОМОБІЛЬ, ДИМ і т.ін.).

Атрибути використовуються для визначення того, яка інформа-ція повинна бути зібрана про сутність. Прикладами атрибутів для сутності АВТОМОБІЛЬ є ТИП, МАРКА, НОМЕРНИЙ ЗНАК, КО-ЛІР і т. ін. Тут також існує відмінність між типом і зразком. Тип атрибуту КОЛІР має багато зразків або значень: Червоний, Синій, Банановий, Біла ніч і т.ін., проте кожному зразку сутності привлас-нюється тільки одне значення атрибуту.

Абсолютна відмінність між типами сутності і атрибутами відсутня. Атрибут є таким тільки у зв’язку з типом сутності. У іншому кон-тексті атрибут може виступати як самостійна сутність. Наприклад, для автомобільного заводу колір — це тільки атрибут продукту ви-робництва, а для лакофарбної фабрики колір — тип суті.

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

Скороходов В. А., Худякова І. М. АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ МЕНЕДЖЕРА

Для сутності Розклад ключем є атрибут Номер рейсу або набір: Пункт відправлення, Час вильоту і Пункт призначення (за умови, що з пункту в пункт вилітає в певний момент часу один літак).

Зв’язок — асоціювання двох або більше сутностей.

Якби призначенням бази даних було тільки зберігання окремих, не пов’язаних між собою даних, то ЇЇ структура могла б бути дуже простою. Проте одна з основних вимог до організації бази даних — це забезпечення можливості пошуку однієї сутності за значениям ін-ших, для чого необхідно встановити між ними певні зв’язки. А оскі-льки в реальних базах даних нерідко містяться сотні або навіть тися-чі сутностей, то теоретично між ними може бути встановлено біль-ше мільйона зв’язків. Наявність такої безлічі зв’язків і визначає складність інфологічних моделей.

Характеристика зв’язків і мова моделювання

При побудові інфологічних моделей можна використовувати мову ЕК-діаграм (від англ. Епгігу-Кеіагіопзпір, тобто сутність-зв’я-зок). У них сутність зображена позначеними прямокутниками, асо-ціації — ромбами або шестикутниками, атрибута — поміченими овалами, а зв’язки між ними — ненаправленими ребрами, над якими може проставлятися ступінь зв’язку (1 або буква, що замінює слово «багато») і необхідне пояснения.

Між двома сутностями, наприклад, А і В можливі чотири види зв’язків.

Перший тип — зв’язок ОДИН-ДО-ОДНОГО (1:1): у кожей момент часу кожному представнику (зразку) сутності А відповідає 1 або 0 представників сутності В (рис.5.4.).

Студент може не «заробити» стипендію, одержати звичайну або одну з підвищених стипендій.

Другий тип — зв’язок ОДИН-ДО-БАГАТЬОХ (1: Б): одному представнику сутності А відповідають 0, 1 або кілька представників сутності В (.5.).

Частина 5 РОЗРОБКА АВТОМАТИЗОВАНИХ РОБОЧИХ МІСЦЬ

Студент

.4.

Зв’язок ОДИН-ДО-ОДНОГО

Призна-чення

Від стипендії

А

М

АВ

Квартира

Призна-чення

М

Меш-канець

.5.

Зв’язок ОДИН-ДО-БАГАТЬОХ

Квартира може бути порожньою, в ній може мешкати одна або кілька осіб.

Оскільки між двома сутностями можливі зв’язки в обох напря-мах, то існує ще два типи зв’язку БАГАТО-ДО-ОДНОГО (Б:1) і БА-ГАТО ДО-БАГАТЬОХ (М: N).

Приклад 1. Якщо зв’язок між сутностями ЧОЛОВІКИ і ЖІНКИ називається ШЛЮБ, то існує чотири можливих подання такого зв’яз-ку (.6.).

Характер зв’язків між сутностями не обмежується перелічени-ми. Існують і складніші зв’язки (рис.5.7.):

1. Пацієнт, маючи одного лікаря, який його лікує, також може ма-ти кількох лікарів-консультантів; лікар може лікувати одних пацієнтів, а також давати консультації кільком іншим (рис.5.8.).

2. Лікар може дати направлення кільком пацієнтам здавати кілька аналізів, аналіз може бути призначений кількома лікарями кіль-ком пацієнтам і пацієнт може бути призначений на кілька аналі-зів кількома лікарями);

3. Зв’язки вищих порядків, семантика (значення) яких іноді дуже складна.

В

Скороходов В. А., Худякова І. М. АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ МЕНЕДЖЕРА

№&

-----------\-------------------

Шлюб у>------ Жінки  Традиційний шлюб

< -----------\ ^------------------- Шлюб ^>------\ Жінки  Багатоженство

 у-------ч х-----------

—<^ Шлюб у>------ї Жінки  Поліандрія

Чоловіки

Чоловіки

Чоловіки

 ^ У------------Ч

------<^ Шлюб ^>

N

Жінки Груповий шлюб

.6.

Можливі типи зв’язку

Лікуючий лікар ^>-

М

<СГ Консультант ~^>-

Пацієнт

N

Рис.5.7.

Безліч зв’язків між однією і тією ж сутністю

Лікар

М

Призначений аналіз

N

Аналіз

Пацієнт

.8.

Тринарні зв’язки

Р

Частина 5 РОЗРОБКА АВТОМАТИЗОВАНИХ РОБОЧИХ МІСЦЬ

У наведених прикладах для підвищення ілюстративності да-них зв’язків не подані атрибути сутності та асоціацій у всіх ЕК-діаграмах. Так, введення лише кількох основних атрибутів в опис шлюбних зв’язків значно у складнить ЕК-діаграму. У зв’язку з цим мова ЕК-діаграм використовується для побудови невеликих моделей та ілюстрації окремих фрагментів великих. Частіше ж за-стосовується менш наочна, але змістовніша мова інфологічного моделювання (МІМ), в якій суть і асоціації подаються у вигляді пропозицій:

СУТЬ   (атрибут 1, атрибут 2,..., атрибут и)

АСОЦІАЦІЯ  [СУТЬ 51, СУТЬ 82,...]

(атрибут 1, атрибут 2,..., атрибут и)

де 5 — ступінь зв’язку, а атрибути, що належать до ключа,

повинні бути виділені підкресленням.

Так, розглянутий вище приклад з безліччю зв’язків між суттю, може бути описаний на МІМ таким чином:

Лікар   (Номер_лікаря, Прізвище, Ім’я, По батькові, Спеціальність)

Пацієнт   (Реєстраційний_номер, Номер ліжка, Прізвище,

Ім’я, По батькові, Адреса, Дата народження, Стать) Лікар, що лікує  [ Лікар 1, Пацієнт Щ

(Номер_лікаря, Реєстраційний_номер) Консультант  [Лікар М, Пацієнт Щ

(Номер_лікаря, Реєстраційний номер).

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

Скороходов В. А., Худякова І. М. АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ МЕНЕДЖЕРА

а)

б)

в)

г)

.9.

Приклади ЕН-діаграм

43&

Частина 5 РОЗРОБКА АВТОМАТИЗОВАНИХ РОБОЧИХ МІСЦЬ

Приклад 2. Відділ записів актів громадянського стану (ЗАГС) займається реєстрацією шлюбу, народження або смерті. Тому в краї-нах, де допускаються лише традиційні шлюби, відділи ЗАГС можуть містити відомості про реєстрацію шлюбу в єдиній сутності:

ШЛЮБ (Номер свідоцтва, Прізвище чоловіка, Ім’я чоловіка, По батькові чоловіка, Дата народження чоловіка, Прізвище дружини, Дата реєстрації, Місце реєстрації,...),

ЕК-діаграма якої наведена на .9 (б)

Приклад 3. Тепер розглянемо ситуацію, коли відділ ЗАГС знахо-диться в країні, яка дозволяє багатоженство. Якщо для реєстрації шлю-бів використовувати суть «Шлюб» прикладу 2., то дублюватимуться відомості про чоловіків, що мають кількох дружин (див. табл. 5.1).

Таблиця 5.1

Номер свідоцтва       Прізвище чоловіка    ...         Прізвище дружини   ...         Дата реєстрації

1-ЮБ 154745 Пєтухов          ...         Курочкіна       ...         06/03/1991

1-ЮБ 163489 Пєтухов          ...         Пеструшкіна   ...         11/08/1991

1-ЮБ 169887 Пєтухов          ...         Рябова            ...         12/12/1992

1-ЮБ 169878 Селезнєв        ...         Уточкіна         ...         12/12/1992

1-ЮБ 154746 Парасюк         ...         Свинюшкіна  ...         06/03/1991

1-ЮБ 169879 Парасюк         ...         Хавронія        ...         12/12/1992

...         ...         ...         ...         ...         ...

Скороходов В. А., Худякова І. М. АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ МЕНЕДЖЕРА

Дублювання можна виключити створенням додаткової сутності «Чоловіки».

Чоловіки  (Код_М, Прізвище, Ім’я, По батькові, Дата народження, Місце на-

родження)

і заміною сутності «Шлюб» характеристикою (див. п.З) з посилан-ням на відповідний опис за суттю «Чоловіки».

ШЛЮБ (Номер свідоцтва, Код_Ч Прізвище дружини.....Дата реєстрації...){Чоловіки}.

ЕК-діаграма зв’язку цієї сутності показана на .4. в, а приклад їх екземплярів в табл. 5.2 і 5.3.

Таблиця 5.2

Код Ч  Прізвище        Ім’я     По батькові    Рік/нар.           Місце народж.

111      Пєтухов Альфред      Остапович     1971 м. Цапелька

112      Селезнєв Вавила      Абрамович    1973  м. Гусєв

113      Парасюк Горацій      Федулович     1972  м. Свиньїн

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

Співробітники (Табельний_номер, Прізвище, Ім’я,...).

Використання, розглянутої в прикладі 2, сутності Шлюб» недо-цільне: у сутності» Співробітники» вже є прізвища, імена, по бать-кові подружжя. Тому створимо асоціацію

ШЛЮБ [Співробітник 1, Співробітник 1]

(Табельний номер чоловіка, Табельний номер дружини,...),

з’єднуючи між собою певні зразки сутності «Співробітники» (.9., г).

Частина 5 РОЗРОБКА АВТОМАТИЗОВАНИХ РОБОЧИХ МІСЦЬ

Таблиця 5.3

Номер свідоцтва       Код — Ч        Прізвище дружини   Ім’я дружини Дата реєстрації

1-ЮБ 154745 111      Курочкіна       Августина      06/03/1991

1-ЮБ 163489 111      Пеструшкіна   Маріана          11/08/1991

1-ЮБ 169887 112      Рябова            Мілана            12/12/1992

1-ЮБ 169878 112      Уточкіна         Вероніка         12/12/1992..

1-ЮБ 154746 113      Свинюшкіна  Ельвіра           06/03/1991..

1-ЮБ 169879 113      Хавронія        Руфіна 12/12/1992..

Зазначимо, що ЕК-діаграма .9., а описуе структуру розміщення даних про шлюби у відділах ЗАГС країн, що допускають групові шлюби, а ЕК-діаграми прикладу 5.9., описи будь-яких видів шлюбів у організаціях, де є сутність «чоловіка» і «жінки», включаючи неодружених.

Що ж таке «зв’язок»? У ЕК-діаграмах це лінія, що з’єднує гео-метричні фігури, що відображають сутність, атрибута, асоціації та інші інформаційні об’єкти. У тексті ж цей термін використовується для вказівки на взаємозалежність сутності. Якщо ця взаємозалеж-ність мае атрибута, то вона називається асоціацією.

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

Скороходов В. А., Худякова І. М. АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ МЕНЕДЖЕРА

1. Лобіо по-грузинськи

Ламану очищену квасолю, нашаткований лук посолити, посипати перцем і припустите в маслі з невеликою кількістю бульйону; додати кинзу, зелень петрушки, рейган (базилік) і довести до готовность Потім запекти в духовці. Квасоля стручкова (свіжа або консервова-на) 200, Цибуля зелена 40, Масло вершкове 30, Зелень 10. Вихід 210. Калорій 725.

.5.

Приклад кулінарного рецепту

За допомогою зазначених користувачів виділені такі об’єкти і характеристики бази, що проектується:

1. Страви, для опису яких потрібні дані, що входять до складу ку-лінарних рецептів: номер страви (наприклад, з книги кулінар-них рецептів), назва та вид (закуска, суп, смаженина т.ін.), рецепт (технологія приготування блюда), вихід (вага порції), назва, калорійність і вага кожного продукту, що є інгредієнтом страви.

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

3. Щоденне споживання страв (витрати): страва, кількість порцій, дата.

Аналіз об’єктів дозволяє виділити:

• Основи: Страви, Продукти і Міста;

• асоціації: Склад (пов’язує Страви з Продуктами) і Поставки (пов’язує Постачальників з Продуктами); позначення Постачальники;

характеристики Рецепти і Витрати.

ЕК-діаграма моделі наведена на .10. а модель на мові МІМ має наступний вигляд:

(^ Вага(кг) ^)

аг/

.10.

Інфологічна модель база данах«Харчування»

 

Скороходов В. А., Худякова І. М. АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ МЕНЕДЖЕРА

Страви (СТ, Страва, Вид)

Продукта (ПР, Продукт, Калорійність)

Постачальники (ПОС, Місто, Постачальник) [Місто]

Склад [Страви М, Продукта Ы] (Ст, ПР, Вага (г))

Поставки [Постачальники М, Продукта Ы] (ПОС, ПР, Дата П, Ціна, Вага (кг)

Міста (Місто, Країна)

Рецепта (Ст, Рецепт) {Страви}

Витрати (СТ, Дата Р, Порцій) {Страви}

У цих моделях Страва, Продукт і Постачальник — найменуван-ня, а СТ., ПР І ПОС — цифрові коди блюд, продуктів і організацій, що постачають ці продукты.