3. Методика перетворення концептуальних структур даних у реляційні структури.

У спрощеній концептуальній моделі можуть бути присутні наступні структури даних:

– об'єкти та атрибути;

– бінарні зв'язки типу 1:1 і типу 1:М;

– зв'язки типу суперклас-підклас.

Далі наведені правила перетворення кожної зі структур у реляційні структури.

3.1 Перетворення об'єктів і атрибутів.

Розглянемо базу даних, що включає об'єкти ВИКЛАДАЧ і КУРС.

Об'єкт ВИКЛАДАЧ має в цьому випадку два атрибути, один із яких (Таб_номер) може бути використаний для ідентифікації екземпляра викладача, тобто бути первинним ключем.

Таким чином, ліва діаграма може бути перетворена у відношення:

ВИКЛАДАЧ (Таб_номер, ПІБ).

Об'єкт КУРС має тільки один атрибут, який не можна використати як ключ, тому що дисципліни з однаковою назвою можуть мати різні робочі програми для різних спеціальностей. Для ідентифікації об'єкта додамо ще один атрибут, який можна використати як первинний ключ: Ном_курсу.

У результаті маємо відношення:

КУРС (Ном_курсу, Найм_курсу).

Загальний підхід до перетворення об'єктів концептуальної моделі у відношення реляційної БД полягає в наступному:

– побудувати набір попередніх відношень і вказати первинні ключі для кожного відношення;

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

3.2 Перетворення бінарних зв’язків.

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

Розглянемо бінарний зв'язок ЧИТАЄ між об'єктами ВИКЛАДАЧ і КУРС:

Об'єкт ВИКЛАДАЧ однозначно ідентифікується за допомогою атрибута Таб_ном (табельний номер), а об'єкт КУРС – за допомогою атрибута Ном_кур (номер курсу). Якщо всі елементи даного об'єкта повинні брати участь у зв'язку, то така участь називається обов'язковою. Клас належності об'єктів, а також потужність зв'язку між об'єктами є факторами, що визначають структуру проектованої БД.

Бінарний зв'язок типу 1:1.

Нехай у проектованій БД повинна зберігатися наступна інформація:

– Таб_ном – табельний номер викладача;

– ПІБ – прізвище, ім'я по батькові викладача;

– Тел_викл – телефон викладача;

– Ном_курс – номер курсу;

– Назв_курс – назва курсу.

Клас належності обох об'єктів (ВИКЛАДАЧ і КУРС) – обов'язковий, внаслідок чого одержуємо відношення:

ВИКЛАДАЧ (Таб_ном, ПІБ, Тел_викл, Ном_курс, Назв_курс),

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

Якщо з яких-небудь міркувань для кожного об'єкта бажано мати окреме відношення, то кращим рішенням у цьому випадку є визначення трьох відношень – по одному для кожного об'єкта та одного для зв'язку:

ВИКЛАДАЧ (Таб_ном, ПІБ, Тел_викл),

КУРС (Ном_курс, Назв_курс),

ЧИТАЄ (Таб_ном, Ном_курс)

Відношення ВИКЛАДАЧ містить відомості про всіх викладачів; відношення КУРС містить відомості про всі курси. Відношення для зв'язку повинне мати серед своїх атрибутів по одному ключеві від кожного об'єкта.

У відношенні ЧИТАЄ будь-які значення Таб_ном і Ном_курс можуть з'являтися тільки один раз, тому що показник кардинальності 1:1.

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

Бінарний зв'язок типу 1:М.

Для зв'язку типу 1:М існує тільки два варіанти. Варіант визначається класом належності М-зв'язного об'єкта, а клас належності 1-зв'язного об'єкта на кінцевий результат в обох випадках не впливає.

Варіант 1. ВИКЛАДАЧ – клас належності необов'язковий, КУРС – клас належності обов'язковий. Рішення цього завдання можливе, якщо використати два відношення, по одному на кожний об'єкт, за умови, що ключ кожного об'єкта служить первинним ключем для відповідного відношення. У якості батьківського призначається відношення, що відповідає "одиничній" стороні зв'язку, а в якості дочірнього призначається відношення, що представляє "множинну" сторону зв'язку. Для представлення цього зв'язку необхідно скопіювати первинний ключ батьківського відношення в дочірнє, де він буде описаний як зовнішній.

В результаті отримаємо два відношення:

ВИКЛАДАЧ (Таб_ном (PK), ПІБ, Тел_викл),

КУРС (Ном_курс (PK), Назв_курс, Таб_ном (FK))

Варіант 2. Клас належності обох об'єктів – необов'язковий. В одиночному відношенні, що моделює цю систему, виникають аномалії та надмірність:

– виникають пробіли в атрибутах курсу, що не читає викладач;

– виникають пробіли в атрибутах викладача, де курс не читається жодним викладачем,

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

Якщо використати попередній варіант, то зникнуть 1-ша та 3-тя проблеми, але залишиться 2-га.

Рішення даного завдання – у формуванні трьох відношень: по одному на кожний об'єкт, з відповідними первинними ключами, і одного для зв'язку:

ВИКЛАДАЧ (Таб_ном, ПІБ, Тел_викл),

КУРС (Ном_курс, Назв_курс),

ЧИТАЄ (Таб_ном, Ном_курс)

За аналогічною 2-му варіанту схемою перетвориться і зв'язок типу M:N, причому незалежно від класу належності обох об'єктів.

Перетворення зв'язку типу "суперклас/підклас".

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

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

Розглянемо наведену на малюнку діаграму зв'язку типу "суперклас/клас" де підкласи АСИСТЕНТ, СТАРШИЙ ВИКЛАДАЧ, ДОЦЕНТ, ПРОФЕСОР є членами суперкласу ВИКЛАДАЧ.

Подібна діаграма перетвориться в наступну реляційну схему відношень:

ВИКЛАДАЧ (Таб_ном, ПІБ, Адреса, Тел_викл, Пед_стаж);

ПРОФЕСОР (Таб_ном, Ном_дипл_проф);

ДОЦЕНТ (Таб_ном, Ном_дипл_доц);

СТАРШИЙ ВИКЛАДАЧ (Таб_ном);

АСИСТЕНТ (Таб_ном).

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

Перетворення рекурсивного зв'язку.

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

Зобразимо діаграму зв'язку двох об'єктів: МАЙСТЕР і ЗБИРАЧ.

Ключем кожного об'єкта є табельний номер. Оскільки показник кардинальності зв'язку 1:М і клас належності обох об'єктів є обов'язковим, то можна побудувати два попередніх відношення:

МАЙСТЕР (Ном_майстра, ...............);

ЗБИРАЧ (Ном_збирача, ........ Ном_майстра)

Іншими атрибутами, до яких мають інтерес, є:

– ПІБ_служб – прізвище, ім.’я та по батькові службовця;

– Роб_телм – робочий телефон майстра (збирач робочого телефону не має);

– Дом_телсл – домашній телефон службовця;

– Адреса_Сл – домашня адреса службовця;

– Т_ставказб – тарифна ставка збирача;

– Окл_М – оклад майстра.

При розміщенні атрибутів Роб_телм, Т_ставказб, Окл_М у двох відношеннях проблем не виникає, а при розміщення атрибутів ПІБ_служб, Дом_телсл, Адреса_Сл можуть виникнути проблеми, які можна вирішити або перевизначивши атрибути (окремо для збирача й майстра), що дасть невдале рішення, або ввести суперклас СЛУЖБОВЕЦЬ, а ЗБИРАЧ і МАЙСТЕР розглядати як підкласи, пов'язані зв'язком КЕРУЄ.

Одержуваний у результаті набір відношень буде мати вигляд:

СЛУЖБОВЕЦЬ (Ном_служ, ...ПІБ_служб, Дом_телсл, Адреса_Сл);

МАЙСТЕР (Ном_майстра, Окл_М , Роб_телм ...............);

ЗБИРАЧ (Ном_збирача, Т_ставказб ........ Ном_майстра)

Перетворення складених об'єктів.

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

Внутрішній об'єкт ВИКОНУЄ має показник кардинальності зв'язку "багато до багатьох". Тоді, згідно з викладеною вище методикою, перетворення цієї моделі в реляційну вимагає генерації трьох відношень:

ФАХІВЕЦЬ (Таб_номер, Посада, ПІБ);

ВИД_РОБОТИ (Код_виду, Характеристика);

ВИКОНУЄ (Таб_номер, Код_виду)

Якби відношення ФАХІВЕЦЬ і ВИД_РОБОТИ мали тільки ключові атрибути, то їх можна було б виключити, тому що ключові атрибути вже містяться у відношенні ВИКОНУЄ.

Внутрішній складений об'єкт ВИКОНУЄ разом з об'єктом НДР утворить новий складений об'єкт із показником кардинальності зв'язку "багато до багатьох". Перетворення цієї моделі в реляційну вимагає генерації двох додаткових відношень:

НДР (Індекс_НДР, Назва, Керівник);

З (Таб_номер, Код_виду, Індекс_НДР, Год_оплата, Кільк_годин).

Атрибути, що ввійшли у відношення З – Год_оплата та Кільк_годин відносяться до всього складеного об'єкта.

У результаті перетворень вихідної концептуальної моделі отримаємо реляційну модель, що включає п'ять відношень:

ФАХІВЕЦЬ (Таб_номер, Посада, ПІБ);

ВИД_РОБОТИ (Код_виду, Характеристика);

ВИКОНУЄ (Таб_номер, Код_виду);

НДР (Індекс_НДР, Назва, Керівник);

З (Таб_номер, Код_виду, Індекс_НДР, Год_оплата, Кільк_годин).

Однак, отримана модель містить надмірність інформації – вся інформація, що міститься у відношенні ВИКОНУЄ також присутня і у відношенні З. Оскільки відношення ВИКОНУЄ не містить неключових атрибутів, те його можна видалити, прибравши у такий спосіб і надмірність. Кінцевий результат буде мати вигляд:

ФАХІВЕЦЬ (Таб_номер, Посада, ПІБ);

ВИД_РОБОТИ (Код_виду, Характеристика);

НДР (Індекс_НДР, Назва, Керівник);

З (Таб_номер, Код_виду, Індекс_НДР, Год_оплата, Кільк_годин).

Неважко помітити, що дана модель являє собою тернарний зв'язок із власними атрибутами.

Перетворення тернарних зв'язків.

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

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

Наприклад, моделювання зв'язку між трьома об'єктами ВИКЛАДАЧ, КУРС, СТУДЕНТ вимагає генерації чотирьох відношень:

ВИКЛАДАЧ (Таб_номер, ПІБ_Викл, Посада, Тел_Викл,....);

КУРС (Ном_курсу, Назва,...);

СТУДЕНТ (Ном_зал_кн, ПІБ_Ст,...);

Викл_ДО_Ст (Таб_номер, Ном_курсу, Ном_зал_кн,...)

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

Аналогічно, коли зв'язок n-арний, потрібно n+1 попереднє відношення.