Автоматизоване робоче місце менеджера - Навчальний посібник (Скороходов В.А.)

5.1. ресурси баз даних

 

Розуміння суті бази даних (БД) необхідне для ефективного звернення із запитами до різних видалених БД, для усвідомлення дисципліни колективного використання БД, а також для орієнтації в особливостях проектування схем БД.

Один кінцевий користувач може мати справу з інформаційними

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

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

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

На середньому ж і вищому рівнях менеджменту програмується

лише частина завдань, оскільки тут їх практично немає масових і ви- значених наперед. Тут менеджерам понад усе необхідні засоби ситу- ативних запитів до різних баз даних, а також системи підтримки ухвалення рішень (СПУР) і електронні таблиці для оперативного формування проблемної аналітичної інформації.

 

 

5.1.1. Основні поняття БД

 

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

 

Основна особливість СУБД — це наявність процедур для вве- дення і зберігання не тільки самих даних, але й описів їх струк- тури. Файли, забезпечені описом даних, що зберігаються в них, і СУБД, що знаходяться під управлінням, стали називати банки даних, а потім «Бази даних» (БД).

 

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

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

 

Ключовими поняттями БД і СУБД є фізичне і логічне подан-

ня даних, незалежність даних, моделі даних.

 

 

Фізичні дані, або фізичне подання даних, це дані, які зберіга- ються в пам’яті комп’ютера на фізичних носіях (магнітних дис- ках, оптичних дисках і т. ін.).

 

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

 

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

 

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

 

У традиційних файлових системах немає незалежності даних, що призводить до жорсткості системи і викликає труднощі при вне- сенні змін у прикладні програми при додаванні нових даних або змі- ні структури файлу.

 

 

Логічно подати дані можна по-різному, у зв’язку з цим велике значення має поняття моделі даних.

 

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

 

У британському тлумачному словнику з обчислювальних сис- тем модель даних (data model) визначається так: «Термін, викорис- таний в різних випадках у зв’язку із зберіганням даних на фізичному або логічному рівні, частіш на першому. Зазвичай йдеться про фор- мально певну структуру, яка використовується для подання даних».

Наведені вище визначення доповнюють один одного. Важливо розуміти, що модель даних — це не самі дані, а дані про дані (мета- дані), які характеризують принцип організації одиниць інформації і допустимі операції над ними.

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

 

СЛУЖБОВЕЦЬ, НАЧАЛЬНИК, ТЕЛЕФОН.

 

В основі реляційного подання даних є проста таблиця, тому да-

лі ми можемо говорити про таблиці і реляційну модель.

Модель даних має три компоненти:

•           структуру даних користувача,

•           допустимі операції з метою визначення нових БД;

•           обмеження для контролю цілісності даних з метою охорони БД

і її захисту від некоректного оновлення і обігу.

 

 

Службовець

Начальник     Телефон

 

 

Реляційна модель задає зв’язки між елементами

(полями, атрибутами)

 

Начальник

 

Службовець

Службовець

Службовець

Телефон

 

Ієрархічна модель задає один  зв’язок між двома одиницями інформації

 

Начальник

 

Службовець

Службовець

Телефон

 

 

Мережева модель задає два типа  зв’язків: між елементами і між складними одиницями

 

Рис. 5.1.

Суть трьох моделей даних

 

Наприклад, реляційна модель даних не допускає в таблиці існу- вання двох однакових записів (кортежів). Т. б. обмеження вимагає, щоб кожен кортеж (ланцюг взаємопов’язаних полів) був унікальним примірником. Якщо  ж  користувач уведе в  таблицю два  однакові

 

 

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

До основних термінів БД входить також поняття схеми бази да-

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

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

 

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

 

Це відображено на рис. 5.2.

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

 

 

у файлі. Концептуальна і зовнішні схеми БД є найважливішими інструментами для адміністратора БД, який адмініструє права кож- ного користувача БД в інформаційній системі (ІС).

 

d¡ d¡ d¡

 

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

 

 

C, m

 

A, C, D           C, k

Зовнішні схеми

 

 

 

 

A, B, C, D, E, F, …, k, …,n

Концепт- туальна схема

 

 

 

Реальне фізичне уявлення даних

 

 

База даних

Внутрішня схема

 

 

Подпись: Фізичний
рівень
Рис. 5.2.

Ієрархія схем і рівнів баз даних в інформаційних системах

 

Коло даних окремого користувача, тобто таблиць, з якими він має право працювати, утворює зовнішню схему БД. В ІС існує єдина концептуальна схема і декілька зовнішніх схем БД. Характерним є те,  що  концептуальна схема не  є  простим поєднанням зовнішніх

 

 

схем. Розраховані на велику кількість користувачів дані (ситуація з таблицею «С» на рис. 6.2.2) в концептуальній моделі відображаються одноразово з додатковими обмеженнями на допуск до даних (повно- важеннями). Крім того, в концептуальній схемі відображаються логічні взаємозв’язки (відносини) між елементами даних на рівні по- лів (елементів даних).

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

 

5.1.2. Архітектура СУБД

 

СУБД повинна надавати доступ до даних будь-яким користува- чам, включаючи і тих, які практично не мають і (або) не хочуть мати уявлення про:

•     фізичне розміщення в пам’яті даних та описів;

•     механізми пошуку даних, що в процесі запиту;

•           проблеми, що виникають при одночасному запиті одних і тих же даних багатьма користувачами (прикладними програмами);

•     способи забезпечення захисту даних від некоректних оновлень і

(або) несанкціонованого доступу;

•     підтримку баз даних в актуальному стані;

•     та безліч інших функцій СУБД.

 

 

При виконанні основних з цих функцій СУБД повинна викори-

стовувати різні описи даних. А як створювати ці описи?

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

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

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

Така людино-орієнтована модель повністю незалежна від фізи-

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

Решта моделей, зображених на рис. 5.3, є комп’ютерно-орієнто-

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

Оскільки зазначений доступ здійснюється за допомогою конк-

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

 

 

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

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

 

Користувачі

бази  даних    Адміністратор

базі даних

 

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

 

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

 

 

 

{

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

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

 

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

 

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

 

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

 

БАЗА  ДАНИХ

 

Рис. 5.3.

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

 

 

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

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

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

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

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

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

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

 

 

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

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

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

 

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

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

 

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

 

 

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

 

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

 

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

 

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

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

 

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

 

 

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

 

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

 

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

 

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

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

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

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

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

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

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

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

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

 

 

1          1

А         АВ      В

1

Сту-

дент

 

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

1

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

 

 

Рис. 5.4.

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

 

1          М

А         АВ      В

1

Квар-

тира

 

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

М

Меш- канець

 

 

Рис. 5.5.

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

 

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

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

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

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

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

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

ку (рис. 5.6.).

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

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

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

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

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

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

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

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

 

 

1

Чоловіки

 

1

Чоловіки

 

М Чоловіки

 

М Чоловіки

1

Шлюб

 

М Шлюб

 

1

Шлюб

 

N Шлюб

 

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

Жінки

 

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

 

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

 

Поліандрія

 

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

 

 

Рис. 5.6.

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

 

1          Лікуючий лікар         М

Лікар                 Пацієнт

М         Консультант 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

 

<\/a>") //-->