Облік перельотів пасажирів авіакомпанії (стр. 2 из 7)

Рис.3. Касир фіксується у таблиці продажу авіаквитків

Рис.4. Зв’язок Клієнт одержує авіаквиток

Зведення про типи зв’язків наведені у додатку Б.

Етап 1.3. Визначення атрибутів і зв'язування їх з типами сутностей і зв'язків.

Тепер нам необхідно виділити атрибути сутностей, що у специфікаціях також можуть бути представлені іменниками (або відповідними сполученнями). Атрибут описує деякий аспект визначеної сутності або зв'язку. При виконанні цього етапу варто звернути особливу увагу на ті випадки, коли визначений атрибут справляє враження, ніби він описує більше одного типу сутності або зв'язку.

Зведення про виділені атрибути і їх приналежність відповідним сутностям та зв'язкам наведені в табл.1.2.

Таблиця 1.2

Атрибути, які належать сутностям

Тип сутності	Атрибут
Відділення	Номер (Номер відділення) Адреса (Місто, вулиця, район, поштовий індекс) Телефон (Номер телефону) Факс (Факс відділення) Поштовий код (Поштовий код відділення) Електронна адреса (Email)
Працівник	Номер (Табельний номер) Номер відділення Повне ім’я (Прізвище, ім’я, по-батькові) Стать Паспортні дані (Серія, номер, ким виданий, де виданий …) Посада Телефон (Номер телефону) Посада (Займана посада) Зарплата (Заробітна плата)
Клієнт	Номер (Табельний номер) Повне ім’я (Прізвище, ім’я, по-батькові) Стать Паспортні дані (Серія, номер, ким виданий, де виданий …) Мета перельоту
Авіаквиток	Номер Номер клієнта
Літак	Номер Назва
Клас	Номер Назва
Напрям	Номер Пункт відправлення Пункт прибуття
Рейс	Номер Номер напряму Назва
Таблиця продажу авіаквитків	Номер (Номер запису у таблиці) Номер розкладу Номер працівника Номер авіаквитка Номер класу
Розклад авіа перельотів	Номер (Номер запису у таблиці) Номер літака Номер рейсу

Документування виділених атрибутів

У документацію необхідно помістити докладні зведення про атрибути, перераховані у табл.1..2. Для кожного атрибута варто вказати загальний опис, тип даних і довжину значення, наявні обмеження, значення за замовчуванням (якщо таке є), псевдоніми (якщо такі існують), а також є атрибут складеним або похідним і чи припустиме для нього значення NULL. Фрагмент подібного документа наведений у кінці цього розділу (Додаток В).

Етап 1.4. Визначення доменів атрибутів

На цьому етапі потрібно визначити домени атрибутів, поміщених у локальну концептуальну модель. Доменом називають безліч припустимих значень для одного або більше атрибутів. Наприклад, домен атрибута Номер сутності Відділення складається з рядків довжиною до трьох символів, що мають значення від '111' до '999'.

Прикладом домену, поділюваного декількома атрибутами, є домен значень адрес. Атрибути Адреса, що належать сутностям працівник, мають той самий загальний домен припустимих значень. Зведення про домени атрибутів наведені у додатку Г.

Етап 1.5. Визначити атрибути, що є потенційними і первинними ключами

Звернемося до табл. 1.2 і виділимо в ній усі можливі потенційні ключі для кожної із сутностей, представлених у локальній концептуальній моделі даних користувача Директор. Потім зі знайдених потенційних ключів виберемо первинні ключі, що найбільше підходять для кожного типу сутності. Результати визначення первинних і альтернативних ключів для кожної із сутностей представлені в табл.1.3.

Таблиця 1.3

Сутності і їх первинні й альтернативні ключі

Сутність	Первинний ключ	Альтернативний ключ
Відділення	Номер	Телефон
Працівник	Табельний Номер	Паспортні дані
Клієнт	Номер	Паспортні дані
Авіаквиток	Номер
Літак	Номер
Клас	Номер
Напрям	Номер
Рейс	Номер
Таблиця продажу авіаквитків	Номер
Розклад авіа перельотів	Номер

Етап 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.

7. Видалення надлишкових зв'язків.

Видалення зв’язків типу M:N

На ER-діаграмі зв’язки такого типу відсутні.

Видалення складних зв’язків

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

Видалення рекурсивних зв'язків

Рекурсивних зв’язків у концептуальній моделі не було виявлено.

Видалення зв'язків, що мають атрибути

Присутність зв'язків з атрибутами може вказувати на наявність у моделі ще не виділених сутностей, але таких зв’язків немає у концептуальній моделі.

Видалення множинних атрибутів

У локальній концептуальній моделі даних множинні атрибути відсутні, тому ми просто переходимо до наступного етапу.

Повторний огляд зв'язків типу 1:1

У деяких випадках сутності, що беруть участь у зв'язку 1:1, можуть фактично представляти різні аспекти того самого об`єкта. З цієї причини рекомендується знову проаналізувати зміст усіх зв'язків типу 1:1, що існують у моделі даних. У нашому прикладі є зв'язок цього типу Клієнт має Авіаквиток, однак зовсім очевидно, що сутності, що беруть участь у ньому, представляють різні об`єкти реального світу.

Видалення надлишкових зв'язків

У ER-діаграмі надлишкових зв’язків не виявлено.

Етап 2.2. Визначити набір відношень, вихочи зі структури локальної логічної моделі даних.

На цьому етапі мають бути створені відношення, що представляють сутності і зв'язки, наявні у показаній на рисунку 15 локальній логічній моделі даних представлення користувача Директор. Зв'язки між сутностями моделюються за допомогою механізму первинних і зовнішніх ключів. Для опису складу всіх створюваних відношень буде використовуватися мова DDL (українською мовою).

Для кожної наявної в моделі даних сутності варто створити відношення, що буде включати всі прості атрибути цієї сутності.