Дипломная работа: Облік перельотів пасажирів авіакомпанії
Номер
Літак
Номер
Клас
Номер
Напрям
Номер
Рейс
Номер
Таблиця продажу авіаквитків
Номер
Розклад авіа перельотів
Номер
Етап 1.6. Спеціалізація/генералізація типів сутностей
На цьому етапі приймаються (необов'язкові) заходи для поліпшення вихідного варіанта ER-діаграми за допомогою застосування процедури генералізації або спеціалізації сутностей, виділених на етапі 1.1. При проведенні спеціалізації починаються спроби виділити розходження між сутностями. На противагу цьому при застосуванні методів генералізації здійснюється пошук загальних характеристик сутностей різних типів.
Наприклад, на рисунку 1 об'єкти Директор, Касир і Екіпаж представляють різні типи сутностей. Перевіримо, чи можна виконати генералізацію цих сутностей у підкласи суперкласу Працівник або краще зберегти їх як незалежні типи сутностей.
Як показано в таблиці 1.2, всі атрибути сутності Працівник , уключаючи і первинний ключ, присутні також у сутностях Директор , Секретар та Екіпаж . Однак кожна з цих сутностей бере участь у різних зв'язках, наприклад у таких, як Директор керує відділенням і Екіпаж перебуває у літаку . На підставі цих зведень ми приймаємо рішення провести генералізацію сутностей Директор, Касир і Екіпаж . Вони будуть представлені як підкласи суперкласу Працівник . Зв'язки, що суперклас "підтримує" зі своїми підкласами, є частковими і непересічними, оскільки той самий працівник не може бути одночасно й директором, і касиром і членом екіпажу.
Етап 1.6. Створення діаграми сутність-зв’язок
Із метою одержання наочного представлення основних сутностей і зв'язків, визначених у специфікаціях, ми побудували вихідну ER-діаграму, яка має вигляд, показаний на рисунку 13 (для представлення користувача директор) та на рисунку 14 (касир).
Рис. 12. Суперклас Працівник
|
3. Логічне проектування бази даних (кроки 2.1 – 2.6, 3.1 – 3.4)
Етап 2. Побудувати і перевірити локальну логічну модель даних на основі представлення про предметну область кожного з типів користувачів.
Етап 2.1. Перетворити локальну концептуальну модель даних у локальну логічну модель.
На цьому етапі слід перетворити концептуальну модель даних із метою видалення з неї всіх структур, реалізація яких у СУБД реляційного типу є складною. Бажаний результат може бути досягнутий за допомогою виконання таких дій, як:
1. Видалення зв’язків типу M:N.
2. Видалення складних зв’язків.
3. Видалення рекурсивних зв’язків.
4. Видалення зв'язків, що мають атрибути.
5. Видалення множинних атрибутів.
6. Повторний огляд зв'язків типу 1:1.