Предметна область

(частина реального світу, яка відображується у базі даних)

_{Користувачі}

_{бази даних} ^{Адміністратор}

^{базі даних}

_{Інфологічна модель даних}

Узагальнений, не прив’язаний до конкретної СУБД або ПК опис предметної області (набір даних, їх типів, свіязей, довжин та ін.)

_{

Моделі та описи, які використову є СУБД

Даталогічна модель даних

Опис на мові конкретної СУБД

Фізична модель даних

Опис даних, які зберігаються

База даних

Рис. 5.3.

Рівні моделей даних

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

«прозорими» для них), так само як не будуть помічені і нові корис- тувачі. Отже, незалежність даних забезпечує можливість розвитку системи баз даних без руйнування існуючих додатків.

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

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

Спочатку стали використовувати ієрархічні даталогічні моделі.

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

Мережеві моделі також створювалися для мало ресурсних ЕОМ. Це достатньо складні структури, що складаються з «наборів» — так званих дворівневих дерев. «Набори» з’єднуються за допомогою

«записів-зв’язок», утворюючи ланцюжки і т.ін. Один із розробників операційної системи UNIX сказав «Мережева база — це найвірні- ший спосіб втратити дані».

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

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

5.1.3. Інфологічна модель даних

«Сутність·зв’язок». Основні поняття

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

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

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

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

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

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

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

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

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

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

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

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

«багато») і необхідне пояснення.

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

Перший тип — зв’язок ОДИН-ДО-ОДНОГО (1:1): у кожен мо-

мент часу кожному представнику (зразку) сутності А відповідає

1 або 0 представників сутності В (рис.5.4.).

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

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

¹ 1

А ^АВ В

₁

^Сту-

дент

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

1

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

Рис. 5.4.

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

¹ М

А _АВ В

₁

Квар-

тира

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

М

Меш- канець

Рис. 5.5.

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

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

Оскільки між двома сутностями можливі зв’язки в обох напря-

мах, то існує ще два типи зв’язку БАГАТО-ДО-ОДНОГО (Б:1) і БА-

ГАТО ДО-БАГАТЬОХ (М: N).

Приклад 1. Якщо зв’язок між сутностями ЧОЛОВІКИ і ЖІНКИ

називається ШЛЮБ, то існує чотири можливих подання такого зв’яз-

ку (рис. 5.6.).

Характер зв’язків між сутностями не обмежується перелічени-

ми. Існують і складніші зв’язки (рис.5.7.):

1. Пацієнт, маючи одного лікаря, який його лікує, також може ма-

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

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

ком пацієнтам і пацієнт може бути призначений на кілька аналі-

зів кількома лікарями);

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

1

Чоловіки

1

Чоловіки

М Чоловіки

М Чоловіки

₁

Шлюб

М Шлюб

₁

Шлюб

N Шлюб

Жінки Жінки Жінки

Жінки

Традиційний шлюб

Багатоженство

Поліандрія

Груповий шлюб

Рис. 5.6.

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

₁ ^{Лікуючий лікар М}

_Лікар ^{Пацієнт}

^М _{Консультант} ^N

Рис.5.7.

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

М Лікар

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

_N

^Аналіз

Р

Пацієнт

Рис. 5.8.

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

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

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

АСОЦІАЦІЯ [СУТЬ S1, СУТЬ S2,...]

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

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

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

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

може бути описаний на МІМ таким чином:

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

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

Ім’я, По батькові, Адреса, Дата народження, Стать)

Лікар, що лікує [Лікар 1, Пацієнт M]

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

Консультант [Лікар M, Пацієнт N]

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

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

_а)

Код

чоловіка

Прізвище

Код чоловіка

Чоловіки

… …

_{М N}

Шлюб

Код жінки

Жінки

Код жінки

Прізвище

Ім’я

…

№ по- свідчення

№ по- свідчення

Ім’я

…

^б) Код чоловіка

Прізвище

Ім’я

Шлюб

_… ^…

Код жінки

№ по- свідчення

Прізвище

^в) Код чоловіка

Прізвище

Ім’я

_…

1

Чоловіки

М

Шлюб

…

Код жінки

№ по- свідчення

Прізвище

^г) Табель- ний номер

Прізвище

Ім’я

_{Рис. 5.9.}

1

^{Співробітник} Шлюб

1

… ^…

Табель- ний номер

Табель- ний номер

Приклади ER-діаграм

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

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

ER-діаграма якої наведена на рис. 5.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
...	...	...	...	...	...

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

«Чоловіки».

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

родження)

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

ням на відповідний опис за суттю «Чоловіки».

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

ER-діаграма зв’язку цієї сутності показана на рис. 5.4. в, а при-

клад їх екземплярів в табл. 5.2 і 5.3.

_{Таблиця 5.2}

Код Ч	Прізвище	Ім’я	По батькові	Рік/нар.	Місце народж.
111	Пєтухов	Альфред	Остапович	1971	м. Цапелька
112	Селезнєв	Вавила	Абрамович	1973	м. Гусєв
113	Парасюк	Горацій	Федулович	1972	м. Свиньїн

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

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

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

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

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

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

_{Таблиця 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..

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

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

На завершення розглянемо приклад побудови інфологічної мо-

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