- •Лекція 5. Модель “Сутність – зв’язок”
- •5.1. Концепції er-моделі
- •5.1.1. Типи сутностей Типи сутностей - об'єкт чи концепція, що характеризуються на даному підприємстві які мають незалежне існування.
- •Сутність - екземпляр типу сутності, що може бути ідентифікований унікальним образом.
- •Слабкий тип сутності - тип сутності, існування якого, залежить від якогось іншого типу сутності. Сильний тип сутності - тип сутності, існування якого не залежить від якогось іншого типу сутності.
- •Способи представлення сутностей на діаграмі
- •5.1.2. Атрибути Атрибут - властивість типу сутності чи типу зв'язку.
- •Домен атрибута - набір значень, що можуть бути привласнені атрибуту.
- •Простий атрибут - атрибут, що складається з одного компонента з незалежним існуванням.
- •Складений атрибут - атрибут, що складається з декількох компонентів, кожний з який характеризується незалежним існуванням.
- •Однозначний атрибут - атрибут, що містить одне значення для однієї сутності.
- •Багатозначний атрибут - атрибут, що містить кілька значень для однієї сутності.
- •Похідний атрибут - атрибут, що представляє значення, похідне від значення зв'язаного з ним атрибута чи деякої безлічі атрибутів, що належать якомусь (не обов'язково даному) типу сутності.
- •Потенційний ключ - атрибут чи набір атрибутів, що унікально ідентифікує окремі екземпляри типу сутності.
- •Первинний ключ - потенційний ключ, що обраний як первинний ключ.
- •Складений ключ – потенційний ключ, що складається з двох чи більше атрибутів.
- •Представлення атрибутів на діаграмах
- •5.1.3. Типи зв'язків Тип зв'язку - осмислена асоціація між сутностями різних типів.
- •Зв'язок - асоціація між сутностями, що включає по одній сутності з кожного типу, що бере участь у зв'язку сутності.
- •Представлення зв'язків на діаграмах
- •Ступінь зв'язку - кількість сутностей, що охоплені даним зв'язком.
- •Рекурсивний зв'язок - зв'язок, у якому ті самі сутності беруть участь кілька разів і в різних ролях.
- •5.1.4. Атрибути зв'язків
- •5.2. Структурні обмеження
- •5.2.1. Показник кардинальності Показник кардинальності описує кількість можливих зв'язків для кожної із сутностей учасниць.
- •Зв'язку „один до одного"
- •З в'язок „один до багатьох"
- •Зв'язку "багато до багатьох"
- •5.2.2. Ступінь участі Ступінь участі визначає, чи залежить існування деякої сутності від участі в зв'язку деякої іншої сутності.
- •5.3. Проблеми er-моделювання
- •5.3.1. Пастки розгалуження Пастка розгалуження має місце в тому випадку, коли модель відображає зв'язок між типами сутностей, але шлях між окремими сутностями цього типу визначений неоднозначно.
- •5.3.2. Пастки розриву Пастка розриву з'являється в тому випадку, коли в моделі передбачається наявність зв'язку між типами сутностей, але не існує шляху між окремими сутностями цих типів.
- •5.4.1. Суперкласи і підкласи типів сутностей
- •Суперклас - тип сутності, що включає різні підкласи, які необхідно представити в моделі даних. Підклас - тип сутності, що виконує окрему роль, а також є членом суперкласу.
- •5.4.2. Спадкування атрибутів
- •5.4.3. Спеціалізація Спеціалізація - процес збільшення розходжень між окремими членами типу сутності за рахунок виділення їхніх відмінних характеристик.
- •5.4.4. Генералізація Генералізація - процес зведення розходжень між сутностями до мінімуму шляхом виділення їхніх загальних характеристик.
- •5 .4.5. Обмеження, що накладаються на процедури спеціалізації і генералізації
- •5.4.6. Категоризація Категоризація - моделювання одного підкласу зі зв'язком, що охоплює кілька різних суперкласів.
- •5.5. Створення eer-моделі для представлення користувача Manager з навчального проекту DreamHome
- •5.5.1. Специфікації вимог для представлення користувача Manager
- •5.5.2. Створення eer-моделі
- •Визначення типів сутностей
- •Визначення типів зв'язків
- •Визначення показника кардинальності і ступеня участі сторін для типів зв'язків
- •Визначення атрибутів і зв'язування їх з типами сутностей і зв'язків
- •Визначення атрибутів, що є потенційними і первинними ключами
- •Чи спеціалізація генералізація типів сутностей
- •Категоризація типів сутностей
- •Створення розширеної діаграми „сутність-зв’язок"
- •Питання
- •Вправи Навчальний проект University Accommodation Office
Визначення атрибутів, що є потенційними і первинними ключами
Для пошуку потенційних ключів кожної сутності варто уважно вивчити табл. 5.3. Для сутностей з декількома потенційними ключами необхідно вибрати той, котрий буде використовуватися як первинний ключ. Наприклад сутність Staff володіє наступними потенційними ключами:
Staff Jo;
FName, LName, DOB;
NIN.
Найпростіший потенційний ключ Staff_No обраний як первинний ключ сутності Staff, а інші потенційні ключі є її альтернативними ключами. У табл. 5.4 перераховані первинні (і альтернативні, якщо такі маються) ключі всіх сутностей з табл. 5.3.
Таблиця 5.4. Типи сутностей і їх первинні й альтернативні ключі
Тип сутності Первинний ключ Альтернативний ключ
Branch Branch No Tel No
FaxNo
Staff Staff_No FName, LName, DOB
NIN
Manager Staff_No FName, LMame, DOB
NIN
Next_of_Kin
Supervisor Staff No FName, LName, DOB
NIN
Allocated_Staff
Property for Rent Property No
Private Owner Owner No
Business Owner Owner No Tel No
Fax_No
Renter Renter No-
Viewing
Rental Agreement Rental_No
Advert
Newspaper Newspaper Name Tel No
Fax_No
Зверніть увагу, що сутності Next_of__Kin, Allocated__Staff, Viewing і Advert не мають первинного ключа, а тому є слабкими сутностями. Первинні ключі цих сутностей будуть частково чи цілком виведені на основі їхніх батьківських сутностей. Процес створення і визначення первинних ключів для слабких сутностей розглядається як частина методології логічного проектування бази даних.
Чи спеціалізація генералізація типів сутностей
У цьому розділі ми розглянемо можливість спеціалізації чи генералізації сутностей, описаних у специфікаціях вимог користувача Manager. До визначеного ступеня цей процес виконується з урахуванням суб'єктивної думки конкретного розроблювача. Однак при виборі способу представлення сутностей у кожній створюваній моделі даних важливо в максимальній ступені дотримуватись повної відповідності вимогам специфікації. У приведених у розділі 5.1.1 специфікаціях вимог користувача Manager мається кілька пунктів, для яких може виявитися корисним виконати спеціалізацію чи генералізацію. Наприклад, сутності Manager і Supervisor зв'язані із сутністю Staff, а тому прийдеться прийняти рішення про те, як треба представити їх - як підкласи, зв'язані із суперкласом Staff, чи у виді окремих незалежних сутностей.
Рішення про спеціалізацію чи генералізацію сутностей може бути прийняте на основі спільності атрибутів і зв'язків кожної із сутностей. Як показано в табл. 5.3, всі атрибути сутності Staff також представлені в сутностях Manager і Supervisor, причому усі вони мають той самий первинний ключ. Більш того, сутність Supervisor не має ніяких додаткових атрибутів, що відповідають цієї службової ролі. З іншого боку, сутність Manager має три додаткових атрибути:
Date_Mgr_Start, Car_Allowance і Bonus Payment. Крім того, сутності Manager і Supervisor підтримують різні зв'язки: сутність Manager зв'язана зв'язком Manages із сутністю Branch, а сутність Supervisor - зв'язком Supervises із сутністю Staff. На підставі всіх цих зведень можна зробити висновок про те, що сутності Manager і Supervisor являють собою підкласи суперкласу Staff (див. мал. 5.1).
Даний зв'язок "суперклас/підклас" є частковим і непересічний, оскільки не всі співробітники є менеджерами чи інспекторами, а той самий співробітник не може бути одночасно менеджером і інспектором. Це представлення особливо корисне для відображення спільного використання атрибутів, зв'язаних зі згаданими підкласами і суперкласом Staff.
Аналогічний аналіз варто виконати у відношенні спільності, що існує між різними типами власників об'єктів нерухомості. У специфікаціях вимог користувача Manager описані два типи власників; приватні особи (Private_0wner) і юридичні особи (фірми) (Business Owner). Виходячи зі зведень, представлених у табл. 5.2 і 5.3, можна укласти, що в цих сутностей є деякі загальні атрибути (Owner No, Address і Tel No), а також той самий тип зв'язку (зв'язок Owns із сутністю Property_for_Rent). Однак у них є й інші, незбіжні атрибути. У даному випадку доцільно створити суперклас Owner з підкласами Private Owner і Business Owner, як показано на мал. 5.1. Знову створений зв'язок "суперклас/підклас" є повним і непересічним, оскільки кожен власник повинний бути приватною особою чи фірмою, але він не може бути одночасно і тим, і іншим.
Приведені в цьому розділі приклади спеціалізації/генералізації відносно прості. Але, як уже згадувалося вище, процес генералізації може бути продовжений далі. Наприклад, сутності Staff, Manager, Supervisor, Private_0wner і Renter представляють людей із загальними характеристиками (Name, Address, Tel_No), а тому на їхній основі можна було б створити суперклас Person. Але в даному випадку цього робити не слід, і ми залишимо ці сутності так, як вони є.