Перетворення концептуальної моделі в реляційну

Концептуальна модель даних складається із зв'язаної між собою сутності. Основними характеристиками сутності є атрибут і ПК сутності. Зв'язок характеризується мірою і класом приналежності.

Існує алгоритм, по якому концептуальна модель може бути переведена в реляційну, причому гарантована принаймні ЗНФ.

Перетворення сутностей

1. Кожній сутності ставиться у відповідність відношення.

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

3. Первинний ключ сутності стає ПК відношення (PRIMARY KEY). Атрибути, що входять в ПК, набувають властивості обов’язковості (NOT NULL) і унікальності (UNIQUE).

Перетворення зв’язків

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

КЛАС ПРИНАЛЕЖНОСТІ (КП) ОБОХ СУТНОСТЕЙ ОБОВ'ЯЗКОВИЙ.

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

КП однієї СУТНОСТІ ОБОВ'ЯЗКОВИЙ, ІНШИЙ - НЕОБОВ'ЯЗКОВИЙ.

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

КП ОБОХ СУТІ НЕОБОВ'ЯЗКОВИЙ.

Потрібно три відношення, поодинці на кожну сутність, і відношення зв'язку. Ключ кожної суті стає ПК відповідних стосунків. Відношення зв'язку містить як ключові атрибути (FOREING KEYS) ключі обох суті. У відношення зв'язку включаються також атрибути, належні зв'язки (якщо вони є).

1: *, КП багатозв'язкової СУТІ Є ОБОВ'ЯЗКОВИМ.

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

1:*, КП багатозв'язкової СУТІ Є НЕОБОВ'ЯЗКОВИМ.

Потрібно три відношення, поодинці на кожну суть, і відношення зв'язку. Ключ кожної суті стає ПК відповідних стосунків. Відношення зв'язку містить як ключові атрибути (FOREING KEYS) ключі обох суті. У відношення зв'язку включаються також атрибути, належні зв'язки (якщо вони є).

*:*, КП ОБОХ СУТІ НЕ МАЄ ЗНАЧЕННЯ.

Потрібно три відношення, поодинці на кожну суть, і відношення зв'язку. Ключ кожної суті стає ПК відповідних стосунків. Відношення зв'язку містить як ключові атрибути (FOREING KEYS) ключі обох суті. У відношення зв'язку включаються також атрибути, належні зв'язки (якщо вони є).

ПЕРЕТВОРЕННЯ РЕКУРСИВНИХ ЗВ'ЯЗКІВ.

Відношення, що має рекурсивний зв'язок, як ПК має ключ суті, а також включає цей же ключ суті як неключовий атрибут (FOREING KEY).

 

Перетворення відношень супертип - підтип

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

1. Для всієї суті Супертип-Підтипи заводиться одне відношення, що містить всі атрибути супертипа і всі атрибути всіх підтипів. ПК відношення стає ключ супертипа. Значення атрибутів, що характеризують підтипи, допускають значення NULL.

2. Для супертипа і кожного підтипу заводяться різні стосунки. Відношення супертипа включає одне поле для зв'язку зі всіма стосунками підтипів, яке має бути ПК в кожному із стосунків для підтипів.

3. Для супертипа і кожного підтипу заводяться різні стосунки. Відношення супертипа включає по одному полю зв'язки з кожним із стосунків для підтипів, які мають бути ПК в цих стосунках. Поля зв'язку допускають невизначені значення.

 

ПРИКЛАД ПРОЕКТУВАННЯ РБД НА ОСНОВІ

КОНЦЕПТУАЛЬНОЇ МОДЕЛІ

Вище ми отримували РБД ВИКЛАДАЧ_ПРЕДМЕТ на основі концепції функціональної залежності. Інший підхід до проектування розглянемо на цій же моделі.

В наочній області можна виділити наступну суть і відповідні ним атрибути (ключі суті підкреслені).

При цьому спостерігаються наступні зв'язки між суттю.

1. ВИКЛАДАЧ - ПРЕДМЕТ: тип зв'язку *:*, клас приналежності обох суті - обов'язковий. Кожен Викладач повинен вести хоч би один Предмет. Кожен Предмет повинен вестися хоч би одним Викладачем. Крім того, даний зв'язок має атрибут зв'язку, що характеризує кількість годинника, яка веде викладач по предмету. Цей атрибут відмінний від загальної кількості годинника, що відводиться на вивчення конкретного предмету.

2. ВИКЛАДАЧ - КАФЕДРА: тип зв'язку 1:* (уважно розглянете діаграму!), клас приналежності обох суті - обов'язковий. На кожній Кафедрі повинен працювати хоч би один Викладач. Кожен Викладач повинен працювати лише на одній Кафедрі.

3. ВИКЛАДАЧ – ТАРИФНА_СІТКА: тип зв'язку 1:*, клас приналежності суті ВИКЛАДАЧ - обов'язковий, суть ТАРИФНА_СІТКА - необов'язковий. Кожен Викладач повинен мати лише одну Посаду. На кожному Посаді можуть працювати декілька ВИКЛАДАЧІВ.

Відповідна концептуальна модель даних змальована на малюнку 13.

Перетворимо отриману модель в РБД. Згідно з правилом перетворення суті, кожній суті заведемо по відношенню. Ключі суті стануть первинними ключами своїх стосунків. Маємо:

ВИКЛАДАЧ = < Особистий №, Прізвище>;

КАФЕДРА = < Назва, Телефон>;

ПРЕДМЕТ = < Назва, К-сть годин>;

ТАРИФНА_СІТКА = < Посада, Оклад>.

 

Рис. 13

Ці таблиці прийнято називати довідниками. Відмітимо, що оскільки ми не вводили суть ТЕЛЕФОН, то проблеми з взаємно-однозначною залежністю не існує. Телефон є атрибутом суті КАФЕДРА. Таке трактування наочної області допускає наявність паралельних підключень телефонів.

Згідно з правилом перетворення зв'язків один-до-одного з обов'язковим класом приналежності з боку багатозв'язкової суті, ключі суті КАФЕДРА і ТАРІФНАЯ_СЕТКА мають бути додані у відношення ВИКЛАДАЧ як зовнішні ключі:

ВИКЛАДАЧ = < Особистий №, Прізвище, Назва_кафедри (FK)>.

Згідно з правилом перетворення зв'язків многие-ко-багатьом в реляційну модель слід додати відношення зв'язки, що складаються з ключів суті ВИКЛАДАЧ і ПРЕДМЕТ, а так само атрибуту зв'язку К-сть_годин:

НАВАНТАЖЕННЯ = < Особистий №, Назва (FK), Навантаження (FK)>.

Повна схема РБД наведена на рисунку 14.

Звернете увагу на спосіб розкриття не бажаного в реляційній моделі зв'язку типа «багато до багатьох» шляхом створення додаткової таблиці зв'язку. Це є завуальованим методом переходу від зв'язків типа «багато до багатьох» до зв'язків «один до багатьох».

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

Рис. 14

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

 

 

ЛАБОРАТОРНИЙ ПРАКТИКУМ

ПО ПРОЕКТУВАННЮ РБД

Лабораторна робота №1