
- •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. Список літератури
9. Багатозначні атрибути
Для кожного багатозначного атрибуту в сутності створюється нове відношення, відповідне багатозначному атрибуту, і в це нове відношення передається первинний ключ сутності для використання як зовнішній ключ. Якщо сам багатозначний атрибут не є альтернативним ключем сутності, то первинним ключем нового відношення є поєднання багатозначного атрибуту і первинного ключа сутності.
Наприклад, в представленні Branch відповідно до тієї ситуації, що кожне відділення може мати до трьох номерів телефонів, атрибут telno сутності Branch був визначений як багатозначний (див. рис. 15.5, а). Для перетворення цього атрибуту створюється відношення для сутності Branch і відношення Telephone, що містить інформацію про багатозначний атрибут telno. У результаті формується структура, показана на рис. 15.10.
Branch (branchNo, street, city, postcode Первиний ключ branchNo |
Telephone (telNo, branchNo) Первинвий ключ telNo Зовнішній ключ branchNo посилається на Branch {branchNo)
|
Рис. 15.10. Структура зв'язку стосунків Branch і Telephone
Знову рекомендуємо порівняти результати такого перетворення з моделлю даних, показаною на рис. 15.5, б. У таблиці. 15.2 приведені підсумкові відомості про способи перетворення сутності і зв'язків в відношення.
Таблиця 15.2. Підсумкові відомості про способи перетворення суті і зв'язків в стосунки
Суть/зв'язок Спосіб перетворення
|
Спосіб перетворення |
Сильна сутність |
Створення стосунків, які включають всі прості атрибути |
Слаба сутність |
Створення стосунків, які включають всі прості атрибути (після перетворення зв'язку з кожною суттю-власником необхідно також визначити первинний ключ) |
Двохсторонній зв'язок типу 1:* |
Передача первинного ключа суті на сторону "один" для використаня первинний ключ у відношенні, відповідному суті на стороні "багато". На сторону "багато хто" передається також всі атрибути зв'язку
|
Двохсторонній зв’язок типу 1:1: |
|
Обов’язкова участь обох сторін |
Об'єднання суті в одне відношення |
Обов’язкова участь одної сторони |
для використання як зовнішній ключ у відношенні що представляє суть на "обов'язковій" стороні Передача первинного ключа суті на "необов'язкову" сторону |
Необов’язкова участь обох сторін |
Якщо відсутня додаткова інформація, то вибір стає довільним |
Зв'язок суперклас/підклас |
|
Двосторонній зв’язок типу *:*, тяжкий атрибутів зв'язку |
Створення відношення, що представляє зв'язок, і включення всіх атрибутів зв'язку. Передача в нове відношення копії первинного зв’язок ключа з кожної суті-власника для використання в якості зовнішніх ключів |
Багатозначний атрибут |
Створення відношення, що представляє багатозначний атрибут і передача копії первинного ключа суті-власника в нові відношення для використання як зовнішній ключ |
Документування відношень і атрибутів зовнішнього ключа
Після закінчення етапу 2.2 необхідно формально описати на мові DBDL зміст відношень, отриманих на основі логічної моделі даних. Відношення, відповідні представленню staff учбового проекту Dreamhome, показані в таблиці. 15.3.
Таблиця 15.3. Відношення, відповідні представленню Staff учбового проекту Dreamhome
Відношеня |
Staff (staffNo, fName, INarae, position, sex, DOB, supervisorStaffNo} |
Первинвий ключ staffNo |
Зовнішній ключ supervisorStaf fNo посилається на Staff {staffNo) |
BusinessOwner (ownerNo, bName, ЬТуре, contactName, address, telNo) |
Первиний ключ ownerNo |
Альтернативний ключ bName |
Альтернативний ключ telNo |
PropertyForRent (propertyNo, street, city, postcode, type, rooms, rent, |
ownerNo, staffNo) |
Первиний ключ propertyNo |
Зовнішній ключ ownerNo посилається на PrivateOwner (ownerNo) і |
BusinessQwner(ownerNo) |
Зовнішній ключ staff NO посилається на staff (staffNo) |
Lease (leaseNo, paymentMethod, depositPaid, rentStart, rentFinish, |
clientNo, propertyNo) |
Первиний ключ leaseNo |
Альтернативние ключі propertyNo, rentstart |
Альтернативние ключі clientNo, rentStart |
Зовнішній ключ clientHo посилається на client (clientNo) |
Зовнішіній ключ propertyNo посилається на PropertyForRent (propertyNo} |
Похідний атрибут deposit (PropertyForRent .rent*2} |
Похідний атрибут duration (rentFinish - rentstart) |
PrivateOwner (OwnerNo, fname, lname, address, telNo) |
Первинний ключ ownerNo |
Client (clientNo, fname, lname, telNo, prefType, maxRent, staffNo) |
Первинний ключ clientNo |
Зовнішній ключ staffNo посилається на staff (staffNo) |
Vieving (clientNo, propertyNo, dateView, comment) |
Первинний ключ clientNo, propertyNo |
Зовнішній ключ clientNo посилається на client(clientNo) |
Зовнішній ключ propertyNo посилається на PropertyForRent (propertyNo) |
Тепер для кожного відношення визначено повний набір атрибутів, тому розробник отримує можливість визначити всі нові первинні та / або альтернатівні ключі. Цю операцію особливо важливо виконати для слабких сутностей, власний первинний ключ яких формується шляхом передачі первинного ключа з батьківського сутності (або сутностей). Наприклад, слабка сутність Viewing тепер має складовою первинний ключ, що складається з копії первинного ключа сутності PropertyForRent (атрибут propertyNo) і копії первинного ключа сутності Client (атрибут clientNo).
Для відображення обмежень цілісності, які поширюються на зовнішні ключі, може використовуватися розширений синтаксис DBDL (етап 2.5). Крім того, повинен бути поновлений словник даних з урахуванням усіх нових первинних і альтернативних ключів, що були виявлені на даному етапі. Наприклад, слідом за передачею первинних ключів відношення Lease отримує нові альтернативні ключі, сформовані з атрибутів (propertyNo, rents tart) і (clientNo, rentStart).