
- •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. Список літератури
2. Слабкі типи сутностей.
Для кожної слабкої сутності, присутньої в моделі даних, створюється відношення, що включає всі прості атрибути цієї сутності. Первинний ключ слабкої сутності частково або повністю залежить від ключа сутності-власника і тому виявлення первинного ключа слабкої сутності неможливо виконати до тих пір, поки не завершено перетворення в відношення всіх зв'язків сутностей-власників. Наприклад, слабка сутність Preference (рис. 15.1) спочатку перетвориться в наступне відношеня:
Preference (preftype, maxrent) Первинний ключ відсутній (на даний момент)
В даній ситуації первинний ключ відношення Preference неможливо визначити до тих пір, поки не буде належним чином виконано перетворення зв'язку States в відношення.
3. Двосторонні зв'язки типа "один до багатьох" (1 :*)
Для кожного двостороннього зв'язку 1:* сутність, що знаходиться на стороні зв'язку "один", визначається як батьківська, а сутність на стороні зв'язку "багато" - як дочірня. Для позначення цього зв'язку копія атрибуту (атрибутів) первинного ключа батьківської сутності передається у відношення, відповідне дочірній сутності, для використання як зовнішній ключ.
Наприклад, зв'язком Staff Registers client (Співробітник компанії регіструє клієнта) (див. рис. 1-5.1) є зв'язок типу 1:*, оскільки один співробітник компанії може зареєструвати багато клієнтів. В даному прикладі сутність staff знаходиться на стороні зв'язку "один" і є батьківською, а сутність Client знаходиться на стороні "багато" і є дочірньою. Зв'язок між цією сутністю встановлюється шляхом передачі копії первинного ключа (батьківської) сутності Staff (staffno) в (дочірнє) відношення Client. Схема взаємодії відношень Staff і Client показана на рис. 15.6.
Передати атрибут staffno у відношення Client, щоб промоделювати зв'язок Registers типа 1 :*
Staff (staffNo, fName, IName, position, sex, DOB} Первинний ключ staffNo
|
Client (clientNo, fName, IName, telNo, staffNo) Первинний ключ clientNo Альтернативний ключ telNo Зовнішній ключ staffNo посилаєтьсяна Staff (staffNo)
|
Рис. 15.6. Схема взаємоді відношень Staff і Client
В тому випадку, якщо зв'язок 1:* охоплює один або декілька атрибутів, такі атрибути повинні слідувати за вставкою первинного ключа в дочірні відношення. Наприклад, якщо зв'язок Staff .Registers Client має атрибут dateregister (Дата реєстрації), що містить інформацію про те, коли була проведена реєстрація клієнта співробітником компанії, цей атрибут також має бути вставлений у відношення Client поряд з копією первинного ключа відношення Staff, а саме staffno.
4. Двосторонні зв'язки типу "один до одного" (1:1)
Завдання створення відношень, відповідних зв'язку типу 1:1, небагато тяжче, оскільки для визначення того, які сутності в зв'язку є батьківськіми і дочірніми, не може застосовуватися така ознака, як кардинальність зв'язків. Замість цього, щоб визначити, чи слід перетворити цей зв'язок в відношення шляхом об'єднання всіх сутностей, що беруть участь в ньому, в одне відношеня або створити два відношення і передати копію первинного ключа з одного відношення в інше, застосовуються обмеження міри участі (див. розділ 11.6.5). Нижче розглядаються способи створення відношення, які відповідають наступним обмеженням міри участі.
1. Обов'язкова участь обох сторін в зв'язку типу 1:1.
2. Обов'язкова участь однієї сторони в зв'язку типу 1:1.
3. Необов'язкова участь обох сторін в зв'язку типу 1:1.
А. Обовязкова участь обох сторін в зв'язку типу 1:1
В цьому випадку необхідно об'єднати в одне відношення суті, учасників в зв'язку, і вибрати один з первинних ключів первинних сутностей для використання як первинний ключ нового відношення, а другий первинний ключ (якщо він існує) — для використання як альтернативного ключа. Зв'язок Client States Preference (Клієнт виражає свої побажання) представляє собою приклад зв'язку 1:1 з обов'язковою участю обох сторін. Допустимо, що в цьому випадку вирішено об'єднати ці два відношення для отриманя наступного відношення Client: Client (clientNo, fName, IName, telNo, prefType, raaxRent, staffNo)
Первиний ключ clientNo
Зовнішній ключ staffNo посилається на Staff(staffNo)
В тому випадку, якщо зв'язок 1:1 з обов'язковою участю обох сторін має один або декілька атрибутів, ці атрибути мають бути також включені в створюване відношення. Наприклад, якщо зв'язок States має атрибут datestated, в якому зберігається дата оформлення побажань клієнта, цей атрибут також має бути присутнім в об'єднаному відношенні Client.
Слід зазначити, що дві сутності можуть бути об'єднані в одне відношеня лише в тому випадку, якщо між ними немає інших прямих зв'язків,виключаючих можливості виконання такої операції об'єднання (наприклад,звязку 1:*). Якби така ситуація мала місце в даному випадку, то потрібно було б представити зв'язок states за допомогою механізму первинного ключа/зовнішнього ключа. Способи визначення в такій ситуації батьківської і дочірньої сутності описані нижче.