6. Рекурсивні зв'язки "один до одного" (1:1)

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

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

7. Зв'язки типу суперклас/підклас

Для кожного зв'язку типу суперклас/підклас в концептуальній моделі даних сутність, відповідна суперкласу, визначається як батьківська, а сутність, відповідна підкласу, — як дочірня. Є також можливість перетворити подібний зв'язок в одне або декілька відношень. Вибір найбільш відповідного способу перетворення залежить від багатьох чинників, таких як обмеження не перехрещення і міри участі, які розповсюджуються на зв'язок типу суперклас/підклас (див. розділ 12.1.6), від того, чи приймають участь підкласи в різних зв'язках, а також від кількості сутностей, приймаючих участь в зв'язку суперклас/підклас. У таблиці. 15.1 приведені рекомендації по користуванню конкретного чину представлення зв'язку суперклас/підклас з обліком лише обмежень міри участі і неперехрещення.

Наприклад, розглянемо зв'язок суперклас/підклас Owner, показаний на рис. 15.1. Згідно таблиці. 15.1 цей зв'язок може бути перетворений в одне або декілька відношень (лістинг 15.1) різними способами, починаючи від розміщеня всіх атрибутів в одному відношенні з двома визначниками (pownerflag і bownerflag), вказуючими, до якого конкретного підкласу відноситься той або інший рядок (варіант 1), і закінчуючи розподілом всіх атрибутів на три відношення (варіант 4). У схожих випадках найбільш відповідний спосіб перетворення зв'язку суперклас/підклас можна визначити з врахуванням обмеження, які поширюються на цей зв'язок. Згідно рис. 15.1, зв'язок між суперкласом Owner і його підкласами є обов'язковим і таким що неперетинається, оскільки кожен член суперкласу Owner має бути членом одного з підкласів (Privateowner або Buainessowner), але не може одночасно відноситися до обох підкласів. Тому як найкращий спосіб представлення цього зв'язку вибраний варіант 3, створено окреме відношення, що відповідає кожному підкласу, а копія атрибуту (атрибутів) первинного ключа суперкласу включена в кожне відношення.

Таблиця 15.1. Рекомендації по вибору способу перетворення зв'язку суперклас/підклас з обліком лише обмежень міри участі і непересічення

Обмеження міри участі	Обмеження неперетинності	Обов'язкові відношення
Необхідні {Mandatory}	Перехрещення допускається {and}	Одне відношення (с одним або кількома визначниками, що дозволяють вказати тип кожного запису)
Необов’язкові (optional)	Перехрещення допускається {and}	Два відношення: одне – для суперкласу, а друге – для всіх підкласів (с одним або кількома визначниками, що дозволяють вказати тип кожного запису)
Необхідні {Mandatory}	Перехрещення не допускається {or}	Декілька відношень: по одному відношенню для кожного співвідношення суперклас\підклас
Необов’язкові (optional)	Перехрещення не допускається {or}	Декілька відношень: одне для суперкласу, інші – по одному для кожного підкласу

Лістінг 15.1. Різні варіанти перетворення зв'язку суперклас/підклас Owner, засновані на використанні обмежень міри участі і непересічення, приведених в таблиці. 15.1

Варіант 1 - обов'язкова участь, пересічення допускається

AllOwner (ownerNo, address, telNo, fName, INarae, bName, toType,

contactName, pOwnerFlag, bownerFlag)

Первиний ключ ownerNo

Варіант 2 - необов'язкова участь, пересічення допускається

Owner (ownerNo, address, telNo)

Первиний ключ ownerNo

OwnerDeCails (ownerNo, fName IName, bName, bType, contactName,

pOwnerFlag, bOwnerFlag)

Первиний ключ ownerNo

Зовнішній ключ ownerNo посилається на Owner(ownerNo)

Варіант 3 - обов'язкова участь, пересічення не допускається

PrivateOwner (ownerNo, fName, IName, address, telNo)

Первиний ключ ownerNo

BusinessOwner (ownerNo, bName, bType, contactName, address, telNo}

Первиний ключ ownerNo

Варіант 4 - необов'язкова участь,пересеченіє не допускається

Owner (ownerNo, address, telNo)

Первиний ключ ownerNo

PrivateOwner (ownerNo, fName, IName}

Первиний ключ ownerNo

Зовнішній ключ ownerNo посилається на Owner(ownerNo)

BusinessOwner (ownerNo, bName, bType, contactName)

Первиний ключ ownerNo

Зовнішній ключ ownerNo посилається на Owner(ownerNo)

Необхідно підкреслити, що дані, приведені в таблиці. 15.1, придзначені для використання лише і якості загальних рекомендацій, і на кінцевий вибір можуть вплинути інші чинники. Наприклад, варіант 1 (обов'язковий, пересічний) передбачає вживання двох визначників, що дозволяють позначити приналежність рядка до певного підкласу.Не менш обгрунтований спосіб позначення цих обмежень може передбачати використання одного визначника, що дозволяє вказати, відносився рядок до підкласу Privateowner, Businessowner або до того і іншого. Ще один спосіб передбачає повну відмову від визначників і перевірку того, чи має один з атрибутів, унікальних для конкретного підкласу, значеня, відмінне від NULL, для визначення приналежності рядка до цього підкласу. Але у такому разі необхідно передбачити, щоб атрибут, що перевіряється, був обов'язковим (отже, відмінним від NULL).

На рис. 15.1 показаний ще один зв'язок типу суперклас/підклас між сутностями Staf і Supervisor з необов'язковою участю. Але оскільки суперклас Staff має лише один підклас (Supervisor), то на цей зв'язок не розповсюджується обмеження непересічення. Очевидно, що в цьому випадку кількість "контрольованого персоналу" набагато перевищує кількість інспекторів, тому такий зв'язок можна представити у вигляді одного відношення:

Staff (staffNo, fName, IName, position, sex, DOB, supervisorStaffNo)

Первиний ключ staffNo

Зовнішній ключ supervisorStaffNo посилається на Staff (staffNo)

Якщо ж цей зв'язок типу суперклас/підклас буде як і раніше роздивлятись у вигляді рекурсивного зв'язку 1:* (як було спочатку показано на рис. 14.2) з необов'язковою участю обох сторін, то це приведе до полученя такої ж структури, як вказано вище. До цього моменту процес перетворення має бути завершений, при умові, що виконаний етап 2.1. Але якщо цей етап був пропущений, може вимагатись провести наступні три додаткові перетворення.