Приклад проектування рбд на основі концептуальної моделі
Вище ми отримували РБД ВИКЛАДАЧ_ПРЕДМЕТ на основі концепції функціональної залежності. Інший підхід до проектування розглянемо на цій же моделі.
В наочній області можна виділити наступну суть і відповідні ним атрибути (ключі суті підкреслені).
При цьому спостерігаються наступні зв'язки між суттю.
1. ВИКЛАДАЧ - ПРЕДМЕТ: тип зв'язку *:*, клас приналежності обох суті - обов'язковий. Кожен Викладач повинен вести хоч би один Предмет. Кожен Предмет повинен вестися хоч би одним Викладачем. Крім того, даний зв'язок має атрибут зв'язку, що характеризує кількість годинника, яка веде викладач по предмету. Цей атрибут відмінний від загальної кількості годинника, що відводиться на вивчення конкретного предмету.
2. ВИКЛАДАЧ - КАФЕДРА: тип зв'язку 1 :* (уважно розглянете діаграму!), клас приналежності обох суті - обов'язковий. На кожній Кафедрі повинен працювати хоч би один Викладач. Кожен Викладач повинен працювати лише на одній Кафедрі.
3. ВИКЛАДАЧ – ТАРИФНА_СІТКА: тип зв'язку 1:*, клас приналежності суті ВИКЛАДАЧ - обов'язковий, суть ТАРИФНА_СІТКА - необов'язковий. Кожен Викладач повинен мати лише одну Посаду. На кожному Посаді можуть працювати декілька ВИКЛАДАЧІВ.
Відповідна концептуальна модель даних змальована на малюнку 13.
Перетворимо отриману модель в РБД. Згідно з правилом перетворення суті, кожній суті заведемо по відношенню. Ключі суті стануть первинними ключами своїх стосунків. Маємо:
ВИКЛАДАЧ = <Особистий №, Прізвище>;
КАФЕДРА = <Назва, Телефон>;
ПРЕДМЕТ = <Назва, К-сть годин>;
ТАРИФНА_СІТКА = <Посада, Оклад>.
Рис. 13
Ці таблиці прийнято називати довідниками. Відмітимо, що оскільки ми не вводили суть ТЕЛЕФОН, то проблеми з взаємно-однозначною залежністю не існує. Телефон є атрибутом суті КАФЕДРА. Таке трактування наочної області допускає наявність паралельних підключень телефонів.
Згідно з правилом перетворення зв'язків один-до-одного з обов'язковим класом приналежності з боку багатозв'язкової суті, ключі суті КАФЕДРА і ТАРІФНАЯ_СЕТКА мають бути додані у відношення ВИКЛАДАЧ як зовнішні ключі:
ВИКЛАДАЧ = <Особистий №, Прізвище, Назва_кафедри (FK)>.
Згідно з правилом перетворення зв'язків многие-ко-багатьом в реляційну модель слід додати відношення зв'язки, що складаються з ключів суті ВИКЛАДАЧ і ПРЕДМЕТ, а так само атрибуту зв'язку К-сть_годин:
НАВАНТАЖЕННЯ = <Особистий №, Назва (FK), Навантаження (FK)>.
Повна схема РБД наведена на рисунку 14.
Звернете увагу на спосіб розкриття не бажаного в реляційній моделі зв'язку типа «багато до багатьох» шляхом створення додаткової таблиці зв'язку. Це є завуальованим методом переходу від зв'язків типа «багато до багатьох» до зв'язків «один до багатьох».
Введення додаткової таблиці необхідне і при моделюванні зв'язку «один-безліч» з необов'язковим класом приналежності на кінці «безліч». Проте спонукаючі мотиви тут інші. Оскільки клас приналежності необов'язковий, отже, в багатозв'язкової суті можуть існувати екземпляри, що не беруть участь в зв'язку. Тому додавання первинного ключа однозв'язній суті у відношення для багатозв'язкової суті незручно, це поле часто може залишатися невизначеним, що затрудняє підтримання цілісності за посиланнями.
Рис. 14
Проте при моделюванні реальної наочної області для запобігання надмірному збільшенню кількості таблиць стосунками зв'язку в деяких випадках нехтують, надаючи можливість атрибуту мати невизначені значення.