
- •1. Мета роботи
- •2. Короткі теоретичнi вiдомостi
- •Створення і перевірка локальної логічної моделі даних для окремих призначених для користувача представлень
- •1.1 Виключення особливостей, несумісних з реляційною моделлю (необов'язковий етап)
- •Видалення двосторонніх зв'язків "багато до багатьох" (*:*)
- •Видалення рекурсивних зв'язків "багато до багатьох" (*:*)
- •Видалення складних зв'язків
- •4. Видалення багатозначних атрибутів
- •1.2. Визначення набору відношень виходячи із структури локальної логічної моделі даних
- •1. Сильні типи сутності.
- •2. Слабкі типи сутностей.
- •3. Двосторонні зв'язки типа "один до багатьох" (1 :*)
- •4. Двосторонні зв'язки типу "один до одного" (1:1)
- •5. Обов'язкова участь однієї сторони в зв'язку типу 1:1
- •6. Рекурсивні зв'язки "один до одного" (1:1)
- •7. Зв'язки типу суперклас/підклас
- •8. Двосторонні зв'язки "багато до багатьох" (*:*)
- •9. Багатозначні атрибути
- •1.3. Перевірка відношень за допомогою правил нормалізації
- •1.4 Перевірка відповідності стосунків вимогам призначених для користувача транзакцій
- •Контрольні запитання
- •4. Практичне завдання
- •6. Список літератури
5. Обов'язкова участь однієї сторони в зв'язку типу 1:1
В цьому випадку завдання визначення батьківської і дочірньої сутності для зв'язку 1:1 з використанням обмеження міри участі вирішується просто. Сутність, яка характеризується необов'язковою участю в зв'язку, позначається як батьківська, а сутність, яка повинна обов'язково брати участь в зв'язку, визначається як дочірня. Як вказано вище, копія первинного ключа батьківської сутності поміщається у відношення, що представляє дочірну сутність. Якщо цей зв'язок має один або декілька атрибутів,то вони повині йти за вставкой первиного ключа в дочірнє відношеня. Наприклад, якщо зв'язок Client States Preference типу 1:1 характеризується частковою участю з боку сутності Client (іншими словами, не кожен клієнт висловлює свої побажання відносно нерухомості, що орендується), то сутність Client має бути визначена як батьківська, а сутність Preference — як дочірня. Тому в (дочірнє) відношення Preference влазить копія первинного ключа (батьківського) відношення Client (атрибут clientno), внаслідок чого створюється структура, показана на рис.15.7.
Слід зазначити, що атрибут зовнішнього ключа відношення Preference утворює також первинний ключ цього відношення. У такій ситуації первинний ключ відношення Preference неможливо визначити до тих пір, поки не буде виконана вставка зовнішнього ключа з відношення Client у відношення Preference. Тому до кінця даного етапу мають бути виявлені всі нові первинні або потенційні ключі, сформовані в цьому процесі, а також відповідним чином оновлений словник даних.
В. Необов’язкова участь обох сторін в зв'язку типу 1:1
У такому разі одну з суті можна позначити як батьківську, а іншу — як дочірню довільним чином, якщо відсутня яка-небудь додаткова інформація про даний зв'язок, який міг би допомогти прийняти рішення на користь однієї із сторін.
Наприклад, розглянемо завдання про те, як представити зв'язок Staff Uses Car (Співробітник компанії використовує автомобіль) типу 1:1 з необов'язковою участю з обох боків зв'язку. (Слід зазначити, що приведені нижче роздуми відносяться також до зв'язків 1:1 з обов'язковою участю обох сутностей, якщо відсутня можливість об'єднати ці сутності в одне відношення.) Якщо немає якої-небудь додаткової інформації, що дозволяє обгрунтовано вибрати батьківську і дочірню сутність, то вибір стає довільним. Іншими словами, може бути прийняте рішення передати копію первинного ключа сутності Staff в сутність Саr або ж прямо протилежне рішення.
Проте можна передбачити, що більшість автомобілів, належить компанії (але не всі), використовуються її співробітниками, але лише не велика частина співробітників може користуватися автомобілями компанії.
Для формування зв'язку типа 1:1 з обов'язковою участю з боку відношення Client передати атрибут clientno у відношення Preference, щоб промоделіровать зв'язок States
Client (clientNo, fName, IName, telNo, staffNo) Первинний ключ clientno Зовнішній ключ staffno посилається на Staff (staffno) |
Preference (clientNo, prefType, maxRent) Первинний ключ clientno Зовнішній ключ clientno посилається на Client(clientno) |
Рис, 15.7. Приклад структури зв'язку типу 1:1
Тому сутність Car, не дивлячись на її необов'язкову участь, характеризується повнішою участю в зв'язку в порівнянні з сутністю Staff. Тому ліпше визначити сутність Staff як батьківську, а сутність Саr— як дочірню і помістити копію первинного ключа сутності staff (атрибут staf fno) у відношення Саr.