Облік перельотів пасажирів авіакомпанії (стр. 5 из 7)
Включення (без злиття) зв'язків, унікальних для кожного локального представлення
У таблиці можна виділити зв'язки, що є унікальними для кожного з представлень. Для представлення користувача Директор виявлені унікальні зв’язки: Директор керує Відділенням, Екіпаж перебуває у Літаку, Літак міститься у Розкладі авіа перельотів. Ці зв'язки повинні бути перенесені в глобальну модель даних без яких-небудь змін.
Етап 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:М М:1 1:1 |
Додаток В
Зведення про атрибути
| Тип сутності | Атрибут | Опис | Тип даних, довжина | Обмеження | Значення за замовчуванням | Псевдонім | Допустимість Null | Похідний | |||||
| Відділення | Номер | Унікальний ідентифікатор відділення | Символьний, до 3 символів | Первинний ключ | Ні | Ні | |||||||
| Телефон | Номер телефону відділення | Символьний, фіксований, 13 символів | Альтернативний ключ | Ні | Ні | ||||||||
| Факс | Номер факсу відділення | Символьний, фіксований, 13 символів | Альтернативний ключ | Ні | Ні | ||||||||
| Поштовий код | Поштовий код відділення | Символьний, фіксований, 13 символів | Альтернативний ключ | Ні | Ні | ||||||||
| Електронна адреса відділення | Символьний, фіксований, 25 символів | Альтернативний ключ | Так | Ні | |||||||||
| Працівник | Номер | Унікальний ідентифікатор співробітника | Символьний, до 5 символів | Первинний ключ | Ні | Ні | |||||||
| Номер відділення | Унікальний ідентифікатор відділення | ||||||||||||
| Так |