Проектування РБД

бути встановлене необмежене число зв'язків.

Розглянемо приклади зв'язків. Наприклад, відомо, що кожен студент може навчатися в кількох вузах, на кількох спеціальностях. Сутності Студент і Залікова_книжка (далі Книжка) зв'язані. Трактуванням зв'язку Студент – Книжка наступне:

–кожна Книжка призначена для одного і тільки одного Студента;

–кожен Студент може мати одну чи більш Книжок.

У загальному випадку між двома сутностям, наприклад, А і Б, можливі кілька видів (типів) зв'язку:

1)один-до-одного; цей зв'язок означає, що кожному представнику (екземпляру) сутності А може відповідати один представник сутності Б або не відповідає ні одного (0 представників), а кожному представнику сутності Б відповідає тільки один представник сутності А; такий зв’язок позначається як

1:1;

2)один-до-багатьох (1:М); при такому зв'язку кожному представнику сутності А може відповідати 0, 1 або кілька (більше одного) представників сутності Б, а кожному представнику сутності Б відповідає тільки один представник сутності А;

3)багато-до-одного (М:1); при такому зв'язку кожному представнику сутності Б відповідає кілька представників сутності А, а кожному представнику сутності А відповідає тільки один представник сутності Б;

4)багато-до-багатьох (М:N); при такому зв'язку кожному представнику сутності Б може відповідати кілька (М) представників сутності А, а кожному представнику сутності А у свою чергу може відповідати кілька (N) представників сутності А.

Видно, що зв’язки виду 2 та 3 однакові. Тобто якщо вид 2 визначає зв’язок 1:М зі сторони сутності А до сутності Б, то у виді 3 розглядається цей же зв’язок зі сторони сутності Б до сутності А, а цей зв’язок має вид М:1. Таким чином, тип зв’язку М:1 можна вважати зворотнім (протилежним) до зв’язку типу 1:М;

Для зв’язку виду M:N можливий окремий випадок, коли М=N.

Звертаю увагу на формулювання відповідності: може відповідати, а не відповідає.

Розглянемо зв’язки між сутностями Батьки та Діти. У кожного батька (чоловіка) може бути 0, 1 або більше дітей. У кожної дитини може бути тільки один фізіологічний батько. Таким чином між сутностями Батьки і Діти існує зв’язок 1:М. У цьому прикладі сутність Батьки розглядається як батьківська, а сутність Діти – як дочірня.

Відмітимо, що якщо екземплярами сутності Батьки будуть і чоловіки, і жінки, то в такому випадку між сутностями Батьки і Діти існує зв’язок М:N, а точніше 2:N.

По аналогії у зв’язку між двома сутностями можна визначити батьківську

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

15

Тип зв’язку залежить від ПО, яка розглядається. Розглянемо ще кілька прикладів.

Одна людина може одержати ідентифікаційний номер або в силу різних причин не одержати його. Один номер може відповідати тільки одній людини. Таким чином, між сутностями Люди та Ід_номери існує зв’язок типу 1:1.

Розглянемо сутності Люди і Паспорти громадянина. Людина може мати один громадянський паспорт або не мати його, якщо їй не виповнилося 16 років. Звичайно, якщо розглядається законослухняний громадянин. Один паспорт може відповідати (належати) тільки одній людини. Таким чином, у повсякденному житті між сутностями Люди та Паспорти (громадянські) існує зв’язок типу 1:1.

Якщо ми розглядаємо роботу обліку паспортів у відповідних відділах внутрішніх справ, то там зберігається інформація про всі видані паспорти, навіть якщо вони були втрачені, зіпсовані або вкрадені. Таким чином, в паспортних відділах одній людини можуть в загальному випадку видаватися кілька паспортів різних номерів та серій. В любому випадку один паспорт відповідає тільки одній законослухняній людині. Таким чином, при паспортному обліку між сутностями Люди та Паспорти (громадянські) існує зв’язок типу 1:М.

Розглянемо ще більш загальну задачу обліку паспортів. Відомо, що людина крім громадянського паспорту може мати ще закордонні, дипломатичні, службові паспорти або не мати їх. При цьому один паспорт може відповідати тільки одній людини. Таким чином, між сутностями Люди та Паспорти загалом існує зв’язок типу 1:М.

Розглянемо облік студентів.

Студентський потік може складатися з однієї або кількох груп, а група може відноситися тільки до одного потоку. Таким чином між сутностями Потоки і Групи існує зв’язок типу 1:М.

Як відомо, студент може навчатися за кількома напрямами підготовки, а відповідно у кількох групах. В одній групі може навчатися кілька студентів, а один студент може навчатися в кількох групах. При цьому таке навчання не обов’язково має бути одночасним. Тоді між сутностями Студенти і Групи повинен існувати зв’язок типу M:N.

Розглянемо процес реєстрації громадян за місцями проживання. Визначимо сутності Квартири і Люди . При реєстрації в квартирі може бути зареєстровано 0, 1 або кілька мешканців. При цьому одна людина може бути постійно зареєстрованою лише за однією адресою, тобто в одній квартирі. Таким чином, з першого погляду можна вважати, що при реєстрації між сутностями Квартири і Люди існує зв’язок типу 1:М. Але аналіз ПО показує, що такий підхід дуже спрощений. Адреси реєстрації можуть змінюватися в часі. І тому в загальному випадку між сутностями Квартири і Люди існує зв’язок типу N:М.

При оформленні прав власності одна квартира може належати одному або кільком власникам, або не належати нікому (0 власників). При цьому одна людина може володіти кількома квартирами. Таким чином в цьому випадку між

16

сутностями Квартири і Люди існує зв’язок типу М:N.

Характерним прикладом різних видів зв’язків є зв'язок між сутностями Чоловік і Жінка, який оформлюється як Шлюб. Теоретично існують чотири можливих види такого зв'язку:

–традиційний шлюб (1:1);

–багатоженство (1:M);

–багатомужжя (M:1);

–груповий шлюб (M:N).

Ці види розглядаються на якийсь визначений момент часу. Але якщо розглядати навіть традиційний шлюб з точки зору реєстрації актів громадянського стану, то в загальному випадку шлюб – це зв’язок типу N:M: протягом життя у кожного Чоловіка може бути зареєстровано кілька шлюбів з Жінками, а у кожної Жінки кілька шлюбів з Чоловіками.

Таким чином, якщо враховувати зміни в часі, то більшість зв’язків мають тип N:M. Наприклад, Працівники – Місця роботи, Підпрємства – Керівники, тощо.

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

Розглянемо дві сутності Лікарі та Пацієнти. При лікуванні кожен лікар може мати кілька пацієнтів, а пацієнт має одного основного дільничого лікаря (зв’язок 1:M). А при консультаціях пацієнт може мати кількох лікарівконсультантів, кожен з яких може одночасно консультувати інших пацієнтів

(зв’язок N:M).

Розглянемо три сутності Лікарі, Пацієнти та Аналізи. Лікар може призначити декількох пацієнтів на декілька аналізів, аналіз може бути призначений декількома лікарями декільком пацієнтам і пацієнт може бути призначений на декілька аналізів декількома лікарями. Маємо приклад тренарного зв’язку.

Розглянемо сутність Люди. Нехай її екземплярами є як батьки, так і діти. Існують такі зв’язки:

–кожна людина (екземпляр сутності) є дитиною одного і тільки одного чоловіка (людини);

–кожна людина є дитиною однієї і тільки однієї жінки (людини);

–кожна людина (чоловік) може бути батьком для однієї дитини або більше дітей (людей);

–кожна людина (жінка) може бути матір’ю для однієї дитини або більше дітей (людей).

Таким, чином для сутності Люди маємо досить складний рекурсивний зв'язок, який зв'язує сутність з нею самою.

При зростанні порядку зв'язків їхня семантика ускладнюється. Між тими самими сутностями може існувати безліч складних зв'язків. Їх наявність визначає складність ІМД. Наприклад, інформація про прийомних дітей значно ускладнює вищенаведену МД.Тому з метою спрощення моделі всі види зв’язків звичайно переформуються до зв’язків двох типів: 1:1 або 1:М.

Атрибути, що беруть участь у зв’язку з боку дочірньої сутності,

17

називають зовнішнім ключем. Його значення однозначно характеризують сутності, представлені атрибутами батьківської сутності і задаються значеннями її первинного ключа.

У залежності від характеру існуючих зв'язків розрізняють стрижневі, асоціативні і характеристичні сутності, а також підклас асоціативних сутностей, що називаються позначеннями.

Стрижень – це незалежна сутність. У розглянутих раніше прикладах стрижнями є сутності Студенти, Квартири, Люди.

Асоціативна сутність або асоціація – це зв'язок виду "-до-багатьох" між двома чи більш сутностями чи екземплярами сутності. Для однієї сутності може також існувати рекурсивна асоціація.

Асоціації розглядаються як повноправні сутності. Вони можуть:

−брати участь в інших асоціаціях так, як і стрижні;

−мати властивості, тобто мати будь-яке число атрибутів, що характеризують зв'язок.

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

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

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

Як правило, позначення та характеристики не розглядаються як повноправні сутності. Вони не цілком незалежні сутності, оскільки припускають наявність іншої сутності, що буде "позначатися" чи "характеризуватися". Однак вони все-таки являють собою окремі випадки сутності і можуть мати властивості. Вони можуть брати участь в асоціаціях і позначеннях, а також мати свої власні характеристики більш низького рівня.

Як наслідок, можна перевизначити стрижні як сутності, що не є ні асоціаціями, ні позначеннями, ні характеристиками. Такі сутності мають

18

незалежне існування. Їх значення майже не залежать від ПО. До стрижнів, наприклад, можна віднести перелік міст України, державний класифікатор професій, перелік напрямів та спеціальностей, за якими здійснюється підготовка бакалаврів, фахівців і магістрів у ВНЗ.

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

Недостатньо продумана модель може призвести до невдало спроектованого проекту ІС. У більшості випадків такий вмираючий проект неможливо реанімувати за допомогою змін в ПД. Доведеться знову починати з уточнення ІМД.

Рекомендації з побудови ІМД формувалися десятиліттями кращими фахівцями в області обробки даних. Пік робіт з концептуального моделювання припав на кінець 70-х років минулого століття. коли були розроблені кілька різних методологій.

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

3.3 Мова інфологічного моделювання

Для опису ІМД може бути використана мова інфологічного моделювання

(МІМ).

У МІМ для опису сутностей використовують окремі речення. Синтаксис речень залежить від виду сутностей і має наступний вигляд:

СУТНІСТЬ (атрибут 1, атрибут 2 , ..., атрибут n) АСОЦІАЦІЯ [СУТНІСТЬ S1, СУТНІСТЬ S2,...]

(атрибут 1, атрибут 2, ..., атрибут n) ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, ...)

{СПИСОК СУТНОСТЕЙ, ЩО ХАРАКТЕРИЗУЮТЬСЯ}. ПОЗНАЧЕННЯ (атрибут 1, атрибут 2, ...)

[СПИСОК СУТНОСТЕЙ, ЩО ПОЗНАЧАЮТЬСЯ].

У цих реченнях атрибути, що входять у ключ, відзначаються підкресленням. Але ключі краще відзначати не підкресленням, а знаком (*). Інакше, наприклад, в атрибуті Код_студента можемо загубити підкреслення в назві атрибуту.

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

19

Опис позначення зовні відрізняється від опису характеристики тільки тим, що сутності, які позначаються, замикаються не у фігурні дужки, а в квадратні.

Для ІМД реєстрації людей опис може мати наступний вид: Квартири (*Код_квартири, Адреса, Поверх, Площа,…) Мешканці (*Ід_номер, Прізвище, Ім’я, По_батькові, Стать,…)

Реєстрація [Квартири M, Мешканці] (Дата_реєстрація, Дата_вибуття,…) Інші приклади будуть розглянуті в розділі 8.

Опис ІМД на МІМ може бути дуже змістовним, особливо при побудови великих моделей.

3.4 Діаграми "Сутності-Зв'язки"

Частина методологій рекомендують при побудові ІМД використовувати графічне представлення у вигляді моделі типу "Сутності-Зв'язки". Основним видом таких моделей вважають ER-моделі або ER-діаграми (від англ. EntityRelationship).

Загальний набір елементів ЕR-діаграм наведено на рис. 3.1.

Рисунок 3.1 – Елементи ER-діаграм

Кожна сутність має унікальне для МД ім’я. Ці імена записуються в елементи діаграми. Зазвичай для імен сутностей використовують іменники в однині. Але для кращого розуміння краще використовувати імена у множині.

Зв'язок між сутностями графічно зображується як асоціація. У будь-якому зв'язку виділяються два кінці.

На кожному кінці зв’язку може бути вказано:

–ім'я кінця зв'язку;

–ступінь кінця зв'язку (скільки екземплярів даної сутності зв'язується);

–обов'язковість зв'язку (тобто чи будь-який екземпляр даної сутності повинен брати участь у даному зв'язку).

Атрибути сутностей і ключі можуть бути наведені як безпосередньо у

20

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

На рис. 3.2 наведені приклади ER-діаграм для зв’язків двох основних

типів.

	1		1
ЛЮД И		П Р И ЗН АЧЕН Н Я		ІД _НОМЕР И

а)зв’язок типу 1:1

б)зв'язок типу 1:М Рисунок 3.2 – Приклади ERдіаграм

Інші приклади будуть розглянуті в розділі 7.

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

ER-діаграми застосовують як при ручному, так і при автоматизованому проектуванні ІС.

У першому випадку зазвичай використовують графічні можливості пакетів Microsoft Word (фігури та рисунки SmartArt), Microsoft Visio (режим Basic flowshart shapes), тощо.

В другому випадку використовують спеціальні програмні продукти автоматизованої розробки ІС, які отримали загальну назву CASE-засобів

(Computer-aided software engineering), а точніше їх інструменти проектування МД, БД і сховищ даних.

21

4 ДАТАЛОГІЧНЕ МОДЕЛЮВАННЯ

4.1 Ранні моделі даних

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

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

Як зазначено вище, БД – це сукупність взаємопов’язаних даних, організованих згідно зі схемою даних.

Схема даних – це формальний опис БД згідно з конкретною моделлю БД. А модель БД – це логічне подання організації даних у БД згідно з заданою структурою. Структура даних залежить від технології організації БД. А організація БД – це представлення і управління даними відповідно до визначених угод.

Таким чином технології організації БД, а з ними структури даних, моделі БД, а також відповідні СУБД поділяють на три основні типи:

1)ранні (дореляційні);

2)реляційні;

3)постреляційні.

Поняття МД фактично сформувалося у фахівців в області БД тільки разом з реляційним підходом. Фактично спочатку з’явилися ранні системи, а пізніше на основі аналізу і виявлення загальних ознак цих систем були сформовані їх абстрактні уявлення у вигляді МД.

До ранніх систем можна віднести:

1)ієрархічні системи;

2)мережні системи;

3)системи, засновані на інвертованих списках.

При розгляді цих систем можна побудувати ланцюжок визначень за алгоритмом: Структура даних → Модель даних → БД → Система управління.

Ієрархічна структура – це структура даних, що складає множину, частково впорядковану так, що існує тільки один елемент цієї множини, який не має попереднього, а всі інші елементи мають тільки один попередній.

Ієрархічна МД – це МД для подання даних за ієрархічною структурою. Ієрархічна БД – це БД, реалізована згідно з ієрархічною моделлю даних.

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

Якщо об'єкти моделі представити у вигляді двох типів – предків і

22

нащадків, тоді очевидно, що в ієрархії тільки один об'єкт моделі не має предка, а всі інші мають тільки одного предка. Загалом ієрархічна БД складається з упорядкованого набору дерев (рис. 4.1.б).

а)	б)
Рисунок 4.1	– Графічне подання БД з ієрархічною моделлю

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

Найбільш відомим і розповсюдженим представником ієрархічних систем є

Information Management System (IMS) фірми IBM (1968 р.).

Мережні МД також створювалися у час і для малоресурсних ЕОМ. Мережна структура – це структура даних, що складає множину, частково

впорядковану так, що хоча б для деяких елементів існує більш одного попереднього. Іншими словами, один об'єкт моделі може мати декілька предків. У цій моделі дані представляються в вигляді довільного графа. Вид цієї структури наведено на рис. 4.2.

а) б) Рисунок 4.2 – Графічне подання БД із мережною організацією

23

Архітектура мережних систем заснована на пропозиціях групи по БД Data Base Task Group (DBTG) Комітету з мов програмування організації Conference on Data Systems Languages (CODASYL), відповідальної за визначення мови програмування Кобол. Звіт групи DBTG був опублікований у 1971 р.

У 70-х роках минулого століття з'явилося кілька мережних систем.

Типовим представником була система Integrated Database Management System (IDMS) компанії Cullinet Software, призначена для використання на машинах основного класу фірми IBM під управлінням різних операційних систем. Пізніше ця система одержала розвиток у мережній системі CA-IDMS/DB фірми

Computer Associates International (CAI). Використання мережних МД дозволило збільшити продуктивність відповідних СУБД, але водночас істотно ускладнило ці системи.

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

Теоретично будь-яка мережна структура при необхідності може бути приведена до ієрархічної. Досить вказати в дереві об'єкти, що мають декількох нащадків, кілька разів. Це, звичайно, призведе до надмірності даних, але може значно спростити структуру. При перетвореннях слід пам’ятати, що для БД визначається певний порядок обходу по рівнях та об’єктах: зверху – униз, зліва

– праворуч.

Наведені вище МД попарно еквівалентні між собою: 4.1а 4.2а, 4.1б 4.2б.

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

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

Adabas компанії Software AG і систему Datacom/DB компанії Applied Data Research (ADR), орієнтовану на використання на машинах основного класу фірми IBM.

Ранні СУБД дозволили зробити крок уперед в обробці даних. Можна вважати, що рівень засобів ранніх СУБД співвідноситься з рівнем файлових систем приблизно так само, як рівень мови Кобол співвідноситься з рівнем мови Асемблера.

Недоліками ранніх СУБД були:

–висока складність у використанні;

–необхідність наявності знань фізичної організації;

–залежність прикладних систем від фізичної організації;

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

користувачів накопичені величезні БД. Тому вони продовжують широко використовуватися разом із сучасними системами. Методи ранніх СУБД лягли в основу внутрішньої організації СУБД більш високого рівня.

24