Етап 1.6. Спеціалізація/генералізація типів сутностей

На цьому етапі приймаються (необов'язкові) заходи для поліпшення вихідного варіанта ER-діаграми за допомогою застосування процедури генералізації або спеціалізації сутностей, виділених на етапі 1.1. При проведенні спеціалізації починаються спроби виділити розходження між сутностями. На противагу цьому при застосуванні методів генералізації здійснюється пошук загальних характеристик сутностей різних типів.

Наприклад, на рисунку 5 об'єкти Інспектор і Секретар представляють різні типи сутностей. Перевіримо, чи можна виконати генералізаціюцих сутностей у підкласи суперкласу Працівник або краще зберегтиїх як незалежні типи сутностей.

Як показано в таблиці 1.2, всі атрибути сутності Працівник, уключаючи і первинний ключ, присутні також у сутностях Інспектор та Секретар. Більше того, сутність Інспектор не має ніяких додаткових атрибутів, а сутність Секретар має єдиний додатковий атрибут зім'ям Швидкість. Однакяк сутність Інспектор, так і сутність Секретар беруть участь у різних зв'язках, наприклад у таких, як Інспектор керує працівником і Секретар обслуговує Працівника. На підставі цих зведень ми приймаємо рішення провести генералізацію сутностей Інспектор і Секретар. Вони будуть представлені як підкласи суперкласу Працівник. Зв'язки, що суперклас "підтримує" зі своїми підкласами, є частковими і непересічними, оскільки той самий працівник не може бути одночасно й інспектором, і секретарем; крім того, тільки деякі з працівників відділення є інспекторами або секретарями. Подібний варіант представлення дуже зручний при відображенні атрибутів сутностями Інспектор, Секретар і Працівник - як показано на рисунку 5.

У якості ще одного прикладу розглянемо взаємини між сутностями, що представляють власників власності, що здається в оренду. У специфікаціях визначено два типи подібних сутностей - Власник–фізична особа і Власник–юридична особа. Як видно з таблиць 1.1 і 1.2, ці сутності розділяють кілька загальних атрибутів (Номер, Адреса, Телефон), а також підтримують той самий зв'язок (Володіють Об’єктом в оренду), як показано на рисунку 6. Однак є й атрибути, специфічні для сутностей Власник – фізична особа (Ім ’ я і Прізвище) і Власник – юридична особа (Назва, Тип і Ім ’ я для контактів). З усього цього випливає, що дані сутності представляють різні типи власників власності, що здається в оренду.

 

Ми приймаємо рішення виконати генералізацію сутностей Власник – фізична особа і Власник – юридична особа, обґрунтовуючи її спільністю атрибутів та наявністю спільно використовуваного зв'язку Володіє. Таким чином, сутності Власник – фізична особа і Власник – юридична особа будуть представлені як окремі підкласи суперкласу з ім'ям Власник. Зв'язки, які суперклас Власник має зі своїми підкласами, будуть тотальними і непересічними, оскільки будь-який власник власності є або фізичною, або юридичною особою, але не може бути одночасно і тим, і іншим. Отримане представлення є досить зручним для відображення сутностями Власник – фізична особа і Власник – юридична особа атрибутів і загального зв'язку Володіє (рисунок 6).

 

Хоча наведені в цьому розділі приклади є відносно простими і цілком очевидними, необхідно відзначити, що процес генералізації можна продовжити. Наприклад, сутності Працівник, Інспектор, Секретар, Фізична особа і Клієнт представляють окремих персон, що мають кілька загальних атрибутів (Адреса і Телефон). Хочачітких рекомендацій із проведення процедури генералізації або спеціалізації не існує, дуже важливо представити в моделі даних усі найважливіші сутності і зв'язки максимально можливо спрощеними. Отже, відображуваний на діаграмі ступінь спеціалізації/генералізації повинен визначатися вимогами максимально можливої читабельності цієї діаграми і ясності моделювання найважливіших сутностей та зв'язків, що мають місце в реальномусвіті. Виходячи з цих розумінь, ми відмовилися від представлення на ER-діаграмі суперкласу Особа.

Етап 1.7. Створення діаграми „сутність-зв'язок”

 

 

 

Із метою одержання наочного представлення основних сутностей і зв'язків, визначених у специфікаціях для користувача Інспектор,ми побудували вихідну ER-діаграму, яка має вигляд, показаний на рисунку 7. Ця ER-діаграма і підготовлена на етапі 1 документація (у сукупності) являють собою локальну концептуальну модель даних для користувача Інспектор програми „Нерухомість”.