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

ВІДДІЛЕННЯ (Номер_Відділення, Телефон, Факс, Поштовий_Код, E-mail).

Первинний ключ - Номер_Відділення.

ПРАЦІВНИК (Номер_Працівника, Ім’я, Прізвище, По-батькові, Серія_Паспорту, Номер_Паспорту, Дата_Народження, Місце_Проживання, Телефон, Стать, ЗарПлата, Посада).

Первинний ключ – Номер_Працівника.

Зовнішній ключ – Номер_Відділення.

КЛІЄНТ (Номер_Клієнта, Ім’я, Прізвище, По-батькові, Серія_Паспорту, Номер_Паспорту, Дата_Народження, Місце_Проживання, Стать, Мета_Перельоту).

Первинний ключ – Номер_Клієнта.

ЛІТАК (Номер_Літака, Назва).

Первинний ключ – Номер_Літака.

АВІАКВИТОК (Номер_Авіаквитку, Номер_Клієнта).

Первинний ключ – Номер_Авіаквитку.

Зовнішній ключ – Номер_ Клієнта.

КЛАС (Номер_Класу, Назва).

Первинний ключ – Номер_Класу.

РЕЙС (Номер_Рейсу, Номер_Напряму).

Первинний ключ – Номер_Рейсу.

Зовнішній ключ – Номер_Напряму.

НАПРЯМ (Номер_Напряму, Пункт_Відправлення, Пункт_Прибуття).

Первинний ключ – Номер_Напряму.

ТАБЛИЦЯ ПРОДАЖУ АВІАКВИТКІВ (Номер_Запису, Номер_Працівника, Номер_Авіаквитку, Номер_Класу, Номер_Розкладу_Авіаперельотів).

Первинний ключ – Номер_Запису.

Зовнішній ключ - Номер_Працівника.

Зовнішній ключ - Номер_Авіаквитку.

Зовнішній ключ - Номер_Класу.

Зовнішній ключ - Номер_Розкладу_Авіаперельотів.

РОЗКЛАД АВІА ПЕРЕЛЬОТІВ (Номер_Запису, Номер_Літака, Номер_Рейсу)

Первинний ключ – Номер_Запису.

Зовнішній ключ - Номер_Літака..

Зовнішній ключ - Номер_Рейсу.

Рисунок 15

Етап 2.3. Перевірка моделі за допомогою правил нормалізації

На цьому етапі необхідно перевірити створений для представлення користувача Директор набір відношень на відповідність усім вимогам процедури нормалізації. Повний процес нормалізації відношень уключає наступні дії:

· приведення до першої нормальної форми (1НФ), що дозволяє видалити з відношень повторювані групи атрибутів;

· приведення до другої нормальної форми (2НФ), що дозволяє усунути часткову залежність атрибутів від первинного ключа;

· приведення до третьої нормальної форми (ЗНФ), що дозволяє усунути транзитивну залежність атрибутів від первинного ключа;

· приведення до нормальної форми Бойса-Кодда (НФБК), що дозволяє видалити з функціональних залежностей аномалії, що залишилися.

Щоб переконатися в тому, що кожне з відношень, описаних у додатку далі, знаходиться, як мінімум, у нормальній формі Бойса-Кодда (НФБК), ми проаналізуємо функціональні залежності між цими відношеннями. Якщо буде виявлене відношення, що не представлене в НФБК, це може означати, що або створена логічна модель структурно неправильна, або при визначенні на її основі повного набору відношень була допущена помилка. У будь-якому випадку буде потрібно повернутися до попереднього етапу і внести необхідні зміни.

ВІДДІЛЕННЯ (Номер_Відділення, Телефон, Факс, Поштовий_Код, E-mail).

Первинний ключ - Номер_Відділення.

Альтернативний ключ -Телефон

Номер_Відділення - Телефон, Факс, Поштовий_Код, E-mail.

Телефон - Номер_Відділення, Факс, Поштовий_Код, E-mail.

Факс - Номер_Відділення, Телефон, Поштовий_Код, E-mail.

Поштовий_Код - Номер_Відділення, Телефон, Факс, E-mail.

E-mail - Номер_Відділення, Телефон, Поштовий_Код, Факс.

ПРАЦІВНИК (Номер_Працівника, Номер_Відділення, Ім’я, Прізвище, По-батькові, Серія_Паспорту, Номер_Паспорту, Дата_Народження, Місце_Проживання, Телефон, Стать, ЗарПлата, Посада).

Первинний ключ – Номер_Працівника.

Номер_Працівника - Ім’я, Прізвище, По-батькові, Серія_Паспорту, Номер_Паспорту, Дата_Народження, Місце_Проживання, Телефон, Стать, ЗарПлата, Посада

КЛІЄНТ (Номер_Клієнта, Ім’я, Прізвище, По-батькові, Серія_Паспорту, Номер_Паспорту, Дата_Народження, Місце_Проживання, Стать, Мета_Перельоту).

Первинний ключ – Номер_Клієнта.

Номер_Клієнта - Ім’я, Прізвище, По-батькові, Серія_Паспорту, Номер_Паспорту, Дата_Народження, Місце_Проживання, Стать, Мета_Перельоту.

ЛІТАК (Номер_Літака, Назва).

Первинний ключ – Номер_Літака.

Номер_Літака - Назва.

АВІАКВИТОК (Номер_Авіаквитку, Номер_Клієнта).

Первинний ключ – Номер_Авіаквитку.

Зовнішній ключ – Номер_ Клієнта.

Номер_Авіаквитку - Номер_ Клієнта.

КЛАС (Номер_Класу, Назва).

Первинний ключ – Номер_Авіаквитку.

Номер_Класу - Назва.

РЕЙС (Номер_Рейсу, Номер_Напряму, Назва).

Первинний ключ – Номер_Рейсу.

Зовнішній ключ – Номер_Напряму.

Номер_Рейсу - Номер_Напряму, Назва.

НАПРЯМ (Номер_Напряму, Пункт_Відправлення, Пункт_Прибуття).

Первинний ключ – Номер_Напряму.

Номер_Напряму - Пункт_Відправлення, Пункт_Прибуття.

Первинний ключ – Номер_Запису.

Зовнішній ключ - Номер_Працівника.

Зовнішній ключ - Номер_Авіаквитку.

Зовнішній ключ - Номер_Класу.

Зовнішній ключ - Номер_Розкладу_Авіаперельотів.

Номер_Запису - Номер_Працівника, Номер_Авіаквитку, Номер_Класу, Номер_Розкладу_Авіаперельотів.

РОЗКЛАД АВІА ПЕРЕЛЬОТІВ (Номер_Запису, Номер_Літака, Номер_Рейсу)

Первинний ключ – Номер_Запису.

Зовнішній ключ - Номер_Літака.

Зовнішній ключ - Номер_Рейсу.

Номер_Запису - Номер_Літака, Номер_Рейсу.

Після виконання процедури перевірки моделі за допомогою правил нормалізації для всіх відношень ми переконалися у тому, що всі відношення відповідають вимогам НФБК.

Етап 2.4. Перевірити модель у відношенні транзакцій користувачів.

Призначення цього етапу складається в перевірці локальної логічної моделі даних представлення Директор у відношенні можливості виконання всіх транзакцій, передбачених специфікаціями. Для цієї мети ми використовуємо ER-діаграму, а також додану до неї документацію. Виходячи з цих даних, ми зробимо спробу виконати кожну з транзакцій вручну. Якщо це виявиться можливим для всіх транзакцій, необхідних відповідно до

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

Етап 2.5. Створити діаграму сутність-зв’язок.

Остаточний варіант ER-діаграм логічної моделі даних для користувачів Директор та Касир залишився той самий після виконання усіх перевірок та показаний на малюнках 16 та 17 відповідно.

Етап 2.6. Визначити вимоги підтримки цілісності даних.

На цьому етапі ми визначимо ті вимоги підтримки цілісності даних, які необхідно реалізувати в локальній логічній моделі даних користувача Директор. Їхнє призначення полягає в підтримці постійної внутрішньої погодженості інформації, організованої у вигляді бази даних. На цьому етапі наше завдання полягає в тому, щоб установити, які саме вимоги підтримки цілісності даних необхідні, а питання методів їх реалізації будуть вирішуватися пізніше. Ми розглянемо п'ять типів вимог підтримки цілісності:

· обов'язкові дані;

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

· цілісність сутностей;

· посилальна цілісність;

· вимоги даного підприємства.

Обов'язкові дані

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

Докладні зведення про атрибути, що входять у локальну модель даних користувача Директор, були наведені при виконанні етапу 1.3 і представлені в додатку В до концептуального проектування БД.

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

Домен атрибута встановлює набір припустимих значень, що можуть привласнюватися цьому атрибутові. Наприклад, набір припустимих значень для атрибута Номер сутності Працівник являє собою всі можливі рядки довжиною до 4 символів, що мають значення від 1 до 9999. Приклади доменів атрибутів логічної моделі даних користувача Директор були наведені при виконанні етапу 1.4 і представлені в додатку Г.