Автоматизоване робоче місце менеджера - Навчальний посібник (Худякова І.М.)

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

 

Номер свідоцтва

 

Код — Ч

Прізвище дружини

 

Ім’я дружини

Дата реєстрації

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.), їх щоденне споживання, продукти, з яких го- туються ці страви, і постачальників цих продуктів. Інформація буде використовуватись кухарем і керівником невеликого підприємства громадського харчування, а також його відвідувачами.

 

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

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

210. Калорій 725.

Рис. 5.5.

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

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

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

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

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

дата.

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

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

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

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

•           позначення Постачальники;

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

ER-діаграма моделі наведена на  рис.  5.10.  а  модель на  мові

МІМ має наступний вигляд:

Подпись: Рис. 5.10.
Інфологічна модель бази даних «Харчування»

 

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

Продукти (ПР, Продукт, Калорійність) Постачальники (ПОС, Місто, Постачальник) [Місто] Склад [Страви M, Продукти N] (Ст, ПР, Вага (г))

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

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

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

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

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

5.1.4. Реляційна структура даних

В кінці 60-х років з’явилися наукові праці, в яких обговорю- валися можливості застосування різних табличних даталогічних моделей даних, тобто можливості використання звичних і подання способів подання даних. Найбільш значною була стаття співробітни- ка фірми IBM д-ра Е. Кодда (Codd E. F., А Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), де, ймовірно, вперше був застосований термін «реляційна модель даних».

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

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

 

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

Фундаментальною характеристикою баз даних є можливість опису властивостей відносин. Реляційне відношення має такі влас- тивості:

1.         Відносини нормалізовані, якщо кожна клітина кортежу є прос- тим значенням, що не складається з груп. (Альтернатива: у таб- лиці СЛУЖБОВЕЦЬ може існувати стовпець ДІТИ, що є групою реквізитів (ім’я, рік народження, місяць, дата народження). Це викликає необхідність заміни поля ДІТИ іншою таблицею, що порушує вимоги реляційної моделі даних і призводить до мере- жевого або ієрархічного відношення.

2.         Нормалізовані відносини подаються у вигляді таблиці, що має

ім’я (ім’я відношення), порядок (кількість стовпців), а також імена стовпців, які відповідають іменам атрибутів. Рядки табли- ці відповідають кортежам.

3.         Впорядкування кортежів необов’язкове, хоча це може відобра-

жатися на ефективності пошуку кортежів.

4.         Всі кортежі повинні відрізнятися хоча б в одному символі.

5.         Кілька одиничних атрибутів (полів) однозначно ідентифікують кортеж. Наприклад, у відношенні СЛУЖБОВЕЦЬ — це прізви- ще, ім’я і по батькові; у відношенні ТОВАР — код товару і найменування товару; у відношенні ПОСТАВКА — код поста- чальника. Це рольові атрибути, один з яких приймається за пер- винний ключ.

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

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

 

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

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

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

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

Так, домен пунктів відправлення (призначення) — безліч назв населених пунктів, а домен номерів рейсу — безліч цілих позитив- них чисел. Значення доменів полягає в наступному. Якщо значення двох атрибутів беруться з одного і того ж домена, то, ймовірно, ма- ють сенс порівняння, що використовують ці два атрибути (напри- клад, для організації транзитного рейсу можна дати запит «Видати рейси, в яких час вильоту з Києва до Сочі більше часу прибуття з Архангельська до Одеси»). Якщо ж значення двох атрибутів беруть- ся з різних доменів, то їх порівняння, ймовірно, позбавлене значен- ня: чи варто порівнювати номер рейса з вартістю квитка?

Відношення на доменах D1, D2,..., Dn (не обов’язково, щоб всі вони були різні) складається із «заголовка» і «тіла». На рис. 5.11. на- ведений приклад відношення для розкладу руху літаків.

Заголовок складається з  такої фіксованої безлічі атрибутів A1, A2,..., An, що існує взаємно однозначна відповідність між цими атрибутами Ai і визначальними їх доменами Di (i=1,2,..., n).

 

Рис. 5.11.

Відношення з математичної точки зору (Ai — атрибути, Vi —

значення атрибутів)

«Тіло» складається зі змінної в часі безлічі кортежів, де кожен кортеж складається в свою чергу з безлічі пар атрибут-значення (Ai: Vi), (i=1,2,..., n), по одній такій парі для кожного атрибуту Ai в за- головку. Для будь-якої заданої пари атрибут-значення (Ai: Vi) Vi є значенням з єдиного домена Di, який пов’язаний з атрибутом Ai.

Ступінь відношення — це число його атрибутів. Відношення ступеня один називають унарним, ступеня два — бінарним, ступеня три — тринарним,..., а ступеня n — n-арным. Ступінь відношення «Рейс» — 8.

 

Кардинальне число або потужність відношення — це число його кортежів.

Потужність відношення «Рейс» рівна 10. Кардинальне число відношення змінюється в часі на відміну від його ступеня.

Оскільки відношення — це множина, а множини за визначенням не містять елементів, що співпадають, то ніякі два кортежі відношен- ня не можуть бути дублікатами один одного в будь-який довільно- заданий  момент  часу.  Нехай  R  —  відношення  з  атрибутами  A1, A2,..., An. Говорять, що безліч атрибутів K=(Ai, Aj,..., Ak) відношення R є можливим ключем R тоді і тільки тоді, коли задовольняються два незалежних від часу умови:

1.         Унікальність: у довільний заданий момент часу ніякі два різні кортежі R не мають одного і того ж значення для Ai, Aj,..., Ak.

2.         Мінімальність: жоден з атрибутів Ai, Aj,..., Ak не може бути ви-

ключений з Ко без порушення унікальності.

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

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

Відношення — Таблиця (іноді Файл), Кортеж — Рядок (іноді Запис), Атрибут — Стовпець, Поле.

При цьому приймається, що «запис» означає «зразок запису», а

«поле» означає «ім’я і тип поля».

 

5.1.5. Реляційна база даних

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

1.         Кожна таблиця складається з однотипних рядків і має унікальне ім’я.

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

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

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

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

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

вати всі операції реляційної алгебри і практично будь-які їх поєд-

нання.   Серед   них   найбільш   поширені   SQL   (Structured   Query Language — структурована мова запитів) і QBE (Quere-By-Example — запити за зразком). Обидві належать до мов дуже високого рівня,

 

за допомогою яких користувач зазначає, які дані необхідно одержа-

ти, не уточнюючи процедуру їх отримання.

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