Учебная работа. Дипломная работа: Облік перельотів пасажирів авіакомпанії

(Пока оценок нет)

Загрузка...

Учебная работа. Дипломная работа: Облік перельотів пасажирів авіакомпанії

Факультет економіки та менеджменту

Кафедра економічної кібернетики

Курсова бота

з дисципліни «Проектування баз даних»

на тему: «Облік перельотів пасажирів авіакомпанії»

2009

ЗМІСТ

Завдання

Вступ

1. Специфікація вимог для дерматологического з двох користувачів

2. Концептуальне проектування бази даних (кроки 1.1 – 1.7

3. Логічне проектування бази даних (кроки 2.1 – 2.6, 3.1 – 3.4)

Висновок

Перечень літературних джерел

Додатки

Вступ

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

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

Запропонована у даних вказівках методологія роботи з реляційними Системами Управління Базами Даних
(далі — СУБД
), які домінують у наш час, успішно пройшла перевірку часом як у удобному, так і в науковому середовищі. Проектування баз даних складається з трьох фаз: концептуальної, логічної
та фізичної
. Перша фаза
передбачає створення концептуальної моделі даних, яка не залежить від будь-яких фізичних черт засобів реалізації. У другій фазі
концептуальна модель піддається доробці за допомогою видалення елементів, які не можуть бути реалізовані в реляційних системах. У третій фазі
логічна модель даних перетворюється у фізичний проект, який призначено для реалізації у конкретній цільовій СУБД.

Кожну з фаз наведеної методології представлено у вигляді послідовності етапів. Недосвідчений проектувальник буде виконувати ці етапи у наведеній послідовності, дотримуючись вказаного порядку. Більш досвідчений розробник не буде жорстко додержуватись даної методології – він скоріше буде використовувати її як деяку базу або контрольний перелік необхідних дій.

Тема даної курсової роботи — проектування бази даних авіакомпанії. Кожна авіакомпанія в будь-якій країні має на меті прискорювати процеси своєї діяльності, що прямо залежить з його швидкістю і якістю обслуговування, а отже і з прибутковістю. Виходячи з цього виникає потреба задоволення цієї вимоги, але це веде до того, що потрібно контролювати здійснення перельотів та продаж квитків, і тому найкращим виходом з цієї ситуації є використання баз даних. Мета цієї курсової роботи створити базу даних авіакомпанії, якою б користувалися директор та касир з продажу авіаквитків.

1.
Специфікація вимог до даних для користувача «Касир з продажу авіаквитків
»

Збір та аналіз вимог користувача «Касир з продажу авіаквитків» здійснювався в офісі відділення авіакомпанії. Було проведено опитування співробітників, які працюють на посадах касирів у авіакомпанії. Також була проаналізована вся документація, яка використовувалася даною групою співробітників. На основі цього аналізу була підготовлена специфікація вимог до інформації, що буде вміщена в створювану базу даних, а також були визначені всі трансакції, необхідні касирам для успішного виконання їхніх службових обов’язків.

Вимоги до даних для користувача «
Касир з продажу авіаквитків
»:

1. У дерматологическому відділенні авіакомпанії є персонал, що відповідає за реалізацію та реєстрацію авіаквитків – касири, нагляд та контроль за касирами здійснює директор авіакомпанії.

2. Інформація, що описує кожне відділення компанії включає унікальний номер відділення, його адресу (місто, район, вулицю, поштовий код), номер телефону, номер факсу та адресу електронної пошти.

3. Дані про авіарейси (майбутні, та вже здійснені) можна отримати у будь-якому відділенні авіакомпанії. Дані про авіарейс мають бути наступні: унікальний номер авіарейсу, напрям перельоту, авіа переліт у якому числиться даний авіарейс.

4. Розклад авіа перельотів містить у собі дані про авіарейси, літаки та таблицю продажу авіаквитків на кожен авіа переліт, що підпорядкована їй.

5. У дерматологическому літаку має бути персонал, що відповідає за пасажирів, їх безпечне та комфортне транспортування, тобто це є екіпаж літака.

6. Що стосується авіаквитків, то всі вони розподілені по класам і мають свою вартість.

7. Пасажири, тобто клієнти авіакомпанії фіксуються у базі даних та мають бути про их такі дані: унікальний номер клієнта, повне ім’я, стать, усі паспортні дані; крім того має бути зазначена мета здійснення перельоту клієнта за кордон.

8. Має бути створена таблиця продажу авіаквитків, рядки якої інформують про: унікальний номер продажу, працівника, який видав авіаквиток, пасажира, що його отримав, авіарейс, до якого належить авіаквиток.

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

— «Бронювати місця» у замовлених рейсах та видавати квитки клієнтам у разі доступності вільних місць у рейсі.

— Заносити дані про клієнтів та їх квитки у базу даних, після чого видавати їх майбутнім пасажирам.

Вимоги до транзакцій для користувача «Касир з продажу авіаквитків»:

1) Складання списку клієнтів, що отримали квитки на певний авіарейс у певному класі;

2) Продаж та бронювання квитків;

3) Надання інформації про напрями дерматологического авіаперельоту.

Вимоги до даних для користувача «
Директор авіакомпанії»:

1. Директор авіакомпанії здійснює контроль над всіма відділеннями авіакомпанії, кожне з яких налічує певну кількість касирів.

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

4. Дані про авіа перельоти, та всі інші дані, які є дочірніми.

Вимоги до транзакцій для користувача «Директор авіакомпанії»:

1) Контроль всіх співробітників компанії та перегляд даних про их;

2) Перегляд всіх членів екіпажу в розрізі дерматологического авіарейсу;

3) Перегляд списку проданих авіаквитків в розрізі дерматологического авіа перельоту.

2.
Концептуальне проектування бази даних (кроки 1.1 – 1.7)

Етап 1.1. Визначити типи сутностей.

Основними типами сутностей, що згадуються у специфікаціях користувачів є наступні: відділення, працівник, директор, касир, член екіпажу, літак, рейс, напрям, авіаквиток, клас, клієнти.

Документування виділених типів сутностей

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

Етап 1.2. Визначити типи зв
’
язків

Таблиця 1

Тип сутності

Тип зв’
язку

Тип сутності

Відділення

Має

Знаходиться під керівництвом

Працівник

Директор

Працівник

Належить до

Відділення

Директор

Керує

Відділення

Касир

Фіксується у

Таблиця продажу авіаквитків

Екіпаж

Перебуває у

Літак

Клієнт

Одержує

Авіаквиток

Фіксується у

Належить

Таблиця продажу авіаквитків

Клієнт

Клас

Належить до

Таблиця продажу авіаквитків

Напрям

Визначає

Рейс

Здійснюється у

Напрям

Рейс

Фіксується у

Розклад авіа перельотів

Таблиця продажу авіаквитків

Підпорядкована

Містить дані про

Розклад авіа перельотів

Касир

Авіаквиток

Клас

Літак

Фіксується у

Містить у собі

Розклад авіа перельотів

Екіпаж

Розклад авіа перельотів

Містить дані з

Містить дані про

Таблиця продажу авіаквитків

Літак

Рейс

Проаналізувавши таблицю 1.1, можна знайти, що деякі зв’язки, по суті, є тими самими. Наприклад, два типи зв’язків — „Відділення має Працівник”
та „Працівник належить до Відділення”
— фактично представляють той самий зв’язок. Цей зв’язок двічі зазначений у таблиці 1.1 по тій простій причині, що в специфікаціях даний зв’язок визначений як на боці „Працівника”
, так і на боці „Відділення”
. Аналогічно і інші зв’язки що зазначені обидва рази є, по суті, одним зв’язком.

Рис.1. Зв’язок Відділення має працівника

Рис.2. Зв’язок Директор керує відділеннями

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

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

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

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

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

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

Таблиця 1.2

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

Тип сутності

Атрибут

Відділення

Номер (Номер відділення)

Адреса (Місто, вулиця, район, поштовий індекс)

телефон (Номер телефону)

Факс (Факс відділення)

Поштовий код (Поштовий код відділення)

Електронна адреса (email)

Працівник

Номер (Табельний номер)

Номер відділення

Повне ім’я (Прізвище, ім’я, по-батькові)

Стать

Паспортні дані (Серія, номер, ким виданий, де виданий …)

Посада

телефон (Номер телефону)

Посада (Займана посада)

Заработная плата (Заробітна плата)

Клієнт

Номер (Табельний номер)

Повне ім’я (Прізвище, ім’я, по-батькові)

Стать

Паспортні дані (Серія, номер, ким виданий, де виданий …)

Мета перельоту

Авіаквиток

Номер

Номер клієнта

Літак

Номер

Назва

Клас

Номер

Назва

Напрям

Номер

Пункт відправлення

Пункт прибуття

Рейс

Номер

Номер напряму

Назва

Таблиця продажу авіаквитків

Номер (Номер запису у таблиці)

Номер розкладу

Номер працівника

Номер авіаквитка

Номер класу

Розклад авіа перельотів

Номер (Номер запису у таблиці)

Номер літака

Номер рейсу

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

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

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

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

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

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

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

Таблиця 1.3

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

Сутність

Первинний ключ

Альтернативний ключ

Відділення

Номер

телефон

Працівник

Табельний Номер

Паспортні дані

Клієнт

Номер

Паспортні дані

Авіаквиток

Номер

Літак

Номер

Клас

Номер

Напрям

Номер

Рейс

Номер

Таблиця продажу авіаквитків

Номер

Розклад авіа перельотів

Номер

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

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

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

Як показано в таблиці 1.2, всі атрибути сутності Працівник
, уключаючи і первинний ключ, присутні також у сутностях Директор
, Секретар
та Екіпаж
. Однак кожна з цих сутностей бере участь у різних зв’язках, наприклад у таковых, як Директор керує відділенням
і Екіпаж перебуває у літаку
. На підставі цих зведень ми приймаємо рішення провести генералізацію сутностей Директор, Касир
і Екіпаж
. Вони будуть представлені як підкласи суперкласу Працівник
. Зв’язки, що суперклас «підтримує» зі своїми підкласами, є частковими і непересічними, оскільки той самий працівник не може бути одночасно й директором, і касиром і членом екіпажу.

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

Із метою одержання наочного представлення основних сутностей і зв’язків, визначених у специфікаціях, ми побудували вихідну ER-діаграму, яка має вигляд, показаний на рисунку 13 (для представлення користувача директор) та на рисунку 14 (касир).

Рис. 12. Суперклас Працівник

Рис. 14. Локальна концептуальна модель даних для представлення користувача Касир

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 (українською мовою).

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

Набросок 15

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цілісність сутностей

Атрибут первинного ключа сутності не може мати значення NULL. Наприклад, кожен екземпляр сутності Відділення
обов’язково повинен мати конкретне значення атрибута його первинного ключа Номер_Відділення
. Атрибути, що входять у значення первинного ключа кожної сутності, були визначені при виконанні попередніх етапів Докладні зведення про ключі сутностей представлені в додатку.

Посилальна цілісність

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

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

Для дерматологического зовнішнього ключа відношення варто вказати умови, що повинні виконуватися при відновленні або видаленні відповідного значення первинного ключа. У цьому випадку можна застосувати одну з пропонованих стратегій — NO ACTION
, CASCADE
, SET NULL
, SET DEFAULT
або NO CHECK
(див. додаток Д).

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

Ці вимоги, які інакше називаються бізнес-правилами, визначаються тими способами й обмеженнями, що прийняті на даному підприємстві щодо виконання різних операцій. Наприклад, у АТП установлено, що працівник може бути закріпленим лише за одним відділом. Основні бізнес-правила авіакомпанії представлені у додатку Е.

Етап 3.
Створити і перевірити глобальну логічну модель даних.

Етап 3.1. Злити локальну логічну модель даних у єдину глобальну модель даних.

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

Аналіз імен сутностей і їхніх первинних ключів

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

Таблиця 3.1

Порівняння імен сутностей і їхніх первинних ключів у представленнях користувачів Директор і Касир

Тип сутності (представлення Директор)

Первинний ключ

Тип сутності (представлення Касир)

Первинний ключ

Відділення

Номер_Відділення

Відділення

Номер_Відділення

Працівник

Номер_Працівника

Працівник

Номер_Працівника

Табл. продажу авіаквитків

Номер_Запису

Табл. продажу авіаквитків

Номер_Запису

Авіаквиток

Номер_Авіаквитка

Авіаквиток

Номер_Авіаквитка

Клієнт

Номер_Клієнта

Клієнт

Номер_Клієнта

Клас

Номер_Класу

Клас

Номер_Класу

Розклад авіа перельотів

Номер_Запису

Розклад авіа перельотів

Номер_Запису

Рейс

Номер_Рейсу

Рейс

Номер_Рейсу

Напрям

Номер_Напряму

Напрям

Номер_Напряму

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

Аналіз імен зв’язків

Тепер порівняємо імена присутніх у представленнях Директор
і Касир
зв’язків. Імена зв’язків, що існують у дерматологическому із представлень, показані в табл. Кожен зв’язок представлений у таблиці тільки один раз і асоційований з її батьківською сутністю.

Таблиця 3.2

Порівняння зв’язків, наявних у представленнях Директор і Касир

Сутності

(представлення Директор)

Тип зв’язку

Тип сутності (представлення Директор)

Сутності (представлення Касир)

Тип зв’язку

Тип сутності (представлення Касир)

Відділення

Має

Знаходиться під керівництвом

Працівник

Директор

Відділення

Має

Знаходиться під керівництвом

Працівник

Директор

Працівник

Належить до

Відділення

Працівник

Належить до

Відділення

Директор

Керує

Відділення

Директор

Керує

Відділення

Касир

Фіксується у

Таблиця продажу авіаквитків

Касир

Фіксується у

Таблиця продажу авіаквитків

Екіпаж

Перебуває у

Літак

Екіпаж

Перебуває у

Літак

Клієнт

Одержує

Авіаквиток

Клієнт

Одержує

Авіаквиток

Фіксується у

Належить

Таблиця продажу авіаквитків

Клієнт

Авіаквиток

Фіксується у

Належить

Таблиця продажу авіаквитків

Клієнт

Клас

Належить до

Таблиця продажу авіаквитків

Клас

Належить до

Таблиця продажу авіаквитків

Напрям

Визначає

Рейс

Напрям

Визначає

Рейс

Здійснюється у

Напрям

Рейс

Здійснюється у

Напрям

Рейс

Фіксується у

Розклад авіа перельотів

Рейс

Фіксується у

Розклад авіа перельотів

Таблиця продажу авіаквитків

Підпорядкована

Містить дані про

Розклад авіа перельотів

Касир

Авіаквиток

Клас

Таблиця продажу авіаквитків

Підпорядкована

Містить дані про

Розклад авіа перельотів

Касир

Авіаквиток

Клас

Літак

Фіксується у

Містить у собі

Розклад авіа перельотів

Екіпаж

Літак

Фіксується у

Містить у собі

Розклад авіа перельотів

Екіпаж

Розклад авіа перельотів

Містить дані з

Містить дані про

Таблиця продажу авіаквитків

Літак

Рейс

Розклад авіа перельотів

Містить дані з

Містить дані про

Таблиця продажу авіаквитків

Літак

Рейс

Це попереднє порівняння імен зв’язків у дерматологическому із представлень користувачів також допомагає уточнити ділянки, спільні для обох представлень. Однак із цього зовсім не випливає що можна покладатися на те, що сутності або зв’язок з тими ж іменами відіграють однакову роль у дерматологическому із представлень. І все-ж таки, порівняння імен сутностей і зв’язків можна вважати дуже зручною вихідною точкою пошуку ідентичних ділянок у представленнях, що зливаються, якщо, звичайно, не забувати, про можливі помилки.

Злиття загальних сутностей з окремих локальних моделей

На даному етапі виконується перевірка імен і вмісту кожної сутності в обох представленнях. Зокрема, для ідентифікації еквівалентних сутностей з різними іменами варто проаналізувати їхні первинні ключі. Виконання даного етапу включає наступні дії:

· злиття сутностей з однаковими іменами й однаковими первинними ключами;

· злиття сутностей з однаковими іменами, що мають різні первинні ключі;

· злиття сутностей з різними іменами, що мають однакові або різні первинні ключі.

Злиття сутностей з однаковими іменами й однаковими первинними ключами.

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

Злиття сутностей з однаковими іменами, що мають різні первинні ключі.

Такі сутності відсутні.

Злиття сутностей з різними іменами, що мають однакові або різні первинні ключі .

Такі сутності відсутні.

Включення (без злиття) сутностей, унікальних для дерматологического локального представлення.

Глобальне представлення

Злиття загальних зв’язків з окремих локальних моделей

На цьому етапі виконується аналіз імен і призначення всіх зв’язків, що є наявними в обох локальних представленнях. Перш ніж приступати до злиття зв’язків, дуже важливо усунути будь-які конфлікти, що стосуються їх кардинальності і ступеня участі сторін. Імена зв’язків, що наявні в обох локальних представленнях, утримуються в таблиці. Обов’язковою задачею, розв’язуваної на даному етапі, є злиття зв’язків, що мають однакові імена і подібне призначення, а також злиття зв’язків, що мають різні імена, але ідентичне призначення. Але в локальних логічних моделях обох представлень такі зв’язки не були виявлені.

Включення (без злиття) зв’язків, унікальних для дерматологического локального представлення

У таблиці можна виділити зв’язки, що є унікальними для дерматологического з
представлень. Для представлення користувача Директор
виявлені унікальні зв’язки: Директор керує Відділенням, Екіпаж перебуває у Літаку, Літак міститься у Розкладі авіа перельотів. Ці зв’язки повинні бути перенесені в глобальну модель даних без яких-небудь змін.

Етап 3.2. Перевірити глобальну логічну модель.

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

Перевірка на наявність пропущених сутностей і зв’язків

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

Перевірка коректності зовнішніх ключів

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

Перевірка дотримання обмежень цілісності

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

Етап 3.3. Перевірити можливості розширення моделі в майбутньому.

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

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

Остаточна версія логічного глобального представлення показана на рис. 18.

ВИСНОВОК

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

Розробка даної курсової роботи отдала мені можливість більш детально уявити боту авіакомпанії, набути та поглибити знання з даного предмету.

СПИСОК ЛІТЕРАТУРНИХ ДЖЕРЕЛ

1
. Дейт К.Дж. Введение в системы баз данных. 6-е издание. Диалектика. Киев – Москва. 1998 г. 784 с.

2
. Хансен Г., Хансен Дж. Базы данных: разработка и управление. Двучлен. Москва. 1999 г. Пер. с англ. 700 с.

3
. Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика. 2-е издание. Вильямс. Москва-Санкт-Петербург-Киев. 2000 г. 1111 с.

4
. Кириллов В.В. Базы проектирования реляционных баз данных. Учебное пособие. Санкт-Петербургский Муниципальный институт четкой механики и оптики (технический институт). Кафедра вычислительной техники. — HTTP://www.cs.ifmo.ru

5
. С.Д. Кузнецов Базы современных баз данных. Информационно-аналитические материалы. — HTTP://www.citmgu.ru/

Додаток
А

Відомості про типи сутностей

Ім’я сутності

Опис

Особливості використання

Відділення

Місце роботи

Одне і більше відділень авіакомпанії

Працівник

Загальний термін. Описує весь персонал, який працює у авіакомпанії.

Кожен із працівників належить до певного відділення.

Директор

Керуючий відділеннями

Здійснює контроль над всіма відділеннями авіакомпанії

Касир

Персонал, що продає авіаквитки

Здійснює, продаж, реєстрацію квитків та внесення даних у базу даних

Екіпаж

Персонал, що знаходиться у літаку під час перельоту

Відповідає за безпечне та комфортне транспортування пасажирів

Літак

Пристрій для транспортування пасажирів

Використовується для надання послуг авіакомпанією

Рейс

Певний переліт

Використовується для ідентифікації авіа перельоту

Напрям

Певний маршрут літака

Використовується для відображення пунктів відправлення та прибуття літака

Авіаквиток

документ для здійснення авіа перельоту пасажиром

Підтверджує легальність перельоту пасажиром

Таблиця продажу авіаквитків

Таблиця

Кожен запис таблиці відображає факт продажу авіаквитка.

Розклад авіа перельотів

Таблиця

Кожен запис цієї таблиці відображає факт здійснення певного авіа перельоту

Додаток
Б

Зведення про типи зв’язків

Тип сутності

Тип зв’язку

Тип сутності

Кардинальність

Відділення

Має

Знаходиться під керівництвом

Працівник

Директор

1:М

М:1

Працівник

Належить до

Відділення

М:1

Директор

Керує

Відділення

1:M

Касир

Фіксується у

Таблиця продажу авіаквитків

1:М

Екіпаж

Перебуває у

Літак

М:1

Клієнт

Одержує

Авіаквиток

1:1

Авіаквиток

Фіксується у

Належить

Таблиця продажу авіаквитків

Клієнт

1:1

Клас

Належить до

Таблиця продажу авіаквитків

1:М

Напрям

Визначає

Рейс

1:М

Рейс

Здійснюється у

Напрям

М:1

Рейс

Фіксується у

Розклад авіа перельотів

1:1

Таблиця продажу авіаквитків

Підпорядкована

Містить дані про

Розклад авіа перельотів

Касир

Авіаквиток

Клас

М:1

1:1

М:1

Літак

Фіксується у

Містить у собі

Розклад авіа перельотів

Екіпаж

1:М

Розклад авіа перельотів

Містить дані з

Містить дані про

Таблиця продажу авіаквитків

Літак

Рейс

1:М

М:1

1:1

Додаток
В
Зведення про атрибути

Тип сутності

Атрибут

Опис

Тип даних, довжина

Обмеження

Значення за замовчуванням

Псевдонім

Допустимість Null

Похідний

Відділення

Номер

Унікальний ідентифікатор відділення

Символьний, до 3 символів

Первинний ключ

Ні

телефон

Номер телефону відділення

Символьний, фіксований, 13 символів

Альтернативний ключ

Ні

Факс

Номер факсу відділення

Символьний, фіксований, 13 символів

Альтернативний ключ

Ні

Поштовий код

Поштовий код відділення

Символьний, фіксований, 13 символів

Альтернативний ключ

Ні

E-mail

Електронна адреса відділення

Символьний, фіксований, 25 символів

Альтернативний ключ

Так

Ні

Працівник

Номер

Унікальний ідентифікатор співробітника

Символьний, до 5 символів

Первинний ключ

Ні

Номер відділення

Унікальний ідентифікатор відділення

Символьний, до 3 символів

Так

Ні

Повне ім’я

Ім’я працівника (складений атрибут, включає атрибути Прізвище, Ім’я і По-Батькові)

Ім’я

Ім’я працівника

Символьний, до 15 символів

Ні

Прізвище

Прізвище працівника

Символьний, до 15 символів

Ні

По-батькові

По-батькові працівника

Символьний, до 20 символів

Ні

Паспортні дані

Складений атрибут, включає атрибути Серія, Номер паспорту, Дата народження, Місце проживання

Символьний, до 15 символів

Альтернативний ключ

Ні

Серія паспорту

Символьний, до 2 символів

Ні

Номер паспорту

Символьний, до 6 символів

Ні

Дата народження

Дата

Ні

Місце проживання

Місце проживання працівника

Символьний, до 50 символів

Ні

телефон

Номер телефону працівника

Символьний, фіксований, 13 символів

Так

Ні

Стать

Стать працівника

Символьний, фіксований, 1 знак

Ні

Зар. Плата

Заробітна плата працівника у національній валюті

Грошовий

Ні

Посада

Посада, займана працівником

Символьний до 20 символів

Ні

Клієнт

Номер

Унікальний ідентифікатор клієнта

Символьний, до 5 символів

Первинний ключ

Ні

Повне ім’я

Повне ім’я клієнта (складений атрибут, включає атрибути Прізвище, Ім’я і По-Батькові)

Ім’я

Ім’я клієнта

Символьний, до 15 символів

Ні

Прізвище

Прізвище клієнта

Символьний, до 15 символів

Ні

По-батькові

По-батькові клієнта

Символьний, до 20 символів

Ні

Паспортні дані

Складений атрибут, включає атрибути Серія, Номер паспорту, Дата народження, Місце проживання

Символьний, до 15 символів

Альтернативний ключ

Ні

Серія паспорту

Символьний, до 2 символів

Ні

Номер паспорту

Символьний, до 6 символів

Ні

Стать

Стать клієнта

Символьний, фіксований, 1 знак

Ні

Мета перельоту

Мета перельоту за кордон

Символьний, 50 символів

Ні

Директор

Ті, що для сутності Працівник

Визначає працівника, який займає посаду директора

Ті, що для сутності Працівник

Касир

Ті, що для сутності Працівник

Визначає працівника, який займає посаду директора

Ті, що для сутності Працівник

Екіпаж

Ті, що для сутності Працівник

Визначає працівника, який займає посаду директора

Ті, що для сутності Працівник

Літак

Номер

Унікальний ідентифікатор літака

Символьний, до 3 символів

Первинний ключ

Ні

Назва

Назва літака

Символьний, до 15 символів

Ні

Авіаквиток

Номер

Унікальний ідентифікатор авіаквитка

Символьний, до 3 символів

Первинний ключ

Ні

Номер клієнта

Унікальний ідентифікатор клієнта

Символьний, до 5 символів

Ні

Клас

Номер

Унікальний ідентифікатор класу

Символьний, до 3 символів

Первинний ключ

Ні

Назва

Назва класу

Символьний, до 15 символів

Ні

Рейс

Номер

Унікальний ідентифікатор рейсу

Символьний, до 3 символів

Первинний ключ

Ні

Номер напряму

Унікальний ідентифікатор напряму

Символьний, до 3 символів

Ні

Назва

Назва рейсу

Символьний, до 15 символів

Ні

Напрям

Номер

Унікальний ідентифікатор напряму

Символьний, до 3 символів

Первинний ключ

Ні

Пункт відправлення

Символьний, до 15 символів

Ні

Пункт прибуття

Символьний, до 15 символів

Ні

Таблиця продажу авіаквитків

Номер

Номер запису у таблиці продажу авіаквитків (унікальний)

Символьний, до 3 символів

Первинний ключ

Ні

Номер розкладу

Унікальний ідентифікатор розкладу

Символьний, до 3 символів

Ні

Номер працівника

Унікальний ідентифікатор працівника

Символьний, до 5 символів

Ні

Номер авіаквитка

Унікальний ідентифікатор авіаквитка

Символьний, до 3 символів

Ні

Номер класу

Унікальний ідентифікатор класу

Символьний, до 3 символів

Ні

Розклад авіа перельотів

Номер

Номер запису у таблиці продажу авіаквитків (унікальний)

Символьний, до 3 символів

Первинний ключ

Ні

Додаток Г
Зведення про домени атрибутів поміщених у документацію

Ім’я домена

свойства домена

Зразки припустимих значень

Табельний Номер

Рядок перемінної довжини, до 5 символів

А0001, А0002, В0003, В0004

Вулиця

Рядок перемінної довжини, до 25 символів

вул. Шевченка, 10 кв. 44

телефон

Рядок перемінної довжини, до 13 символів

8-050-30-44-702

Стать

Рядок довжиною в 1 знак (значення „Ч” або „Ж”)

Ч, Ж

Додаток Д

Опис у вигляді мови DDL для дерматологического відношення для представлення користувача

Директор

– Номер_ Клієнта посилання
Клієнт (Номер_Клієнта) при видаленні
NO ACTION при зміні
CASCADE.

при видаленні
CASCADE при зміні
CASCADE.

– Працівник (Номер_Працівника) посилання
Працівник (Номер_Працівника) при видаленні
NO ACTION при зміні
CASCADE.

– Авіаквиток (Номер_Авіаквитку) посилання
Авіаквиток (Номер_Авіаквитку) при видаленні
NO ACTION при зміні
CASCADE.

— Номер_Класу посилання
Клас (Номер_Класу) при видаленні
NO ACTION при зміні
CASCADE.

— Номер_Розкладу_Авіаперельотів посилання
РОЗКЛАД АВІА ПЕРЕЛЬОТІВ(Номер_Розкладу_Авіаперельотів) при видаленні
NO ACTION при зміні
CASCADE.

— Номер_Літака посилання
Літак (Номер_Літака) при видаленні
NO ACTION при зміні
CASCADE.

— Номер_Рейсу посилання
Рейс (Номер_Рейсу) при видаленні
NO ACTION при зміні
CASCADE.

Додаток Е
Бізнес-правила для представлення користувача
Директор:

1. Кожен літак має налічувати не більше ніж 6 членів екіпажу.

2. Заробітна плата дерматологического працівника виновата бути не менше встановленого державою мінімуму.

3. Кожен авіа переліт повинен налічувати не більше 90 клієнтів (пасажирів).

4. У дерматологическому напрямі має бути передбачено мінімум 5 рейсів.

Додаток Є

Умовні позначення на ER-діаграмах

— сильний тип сутності;