Дипломная работа: Облік перельотів пасажирів авіакомпанії
Номер_Запису - Номер_Літака, Номер_Рейсу.
Після виконання процедури перевірки моделі за допомогою правил нормалізації для всіх відношень ми переконалися у тому, що всі відношення відповідають вимогам НФБК.
Етап 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
Порівняння імен сутностей і їхніх первинних ключів у представленнях користувачів Директор і Касир
| Тип сутності (представлення Директор) | Первинний ключ | Тип сутності (представлення Касир) | Первинний ключ |
|
Відділення | Номер_Відділення | Відділення | Номер_Відділення |
|
Працівник | Номер_Працівника | Працівник | Номер_Працівника |
|
Табл. продажу авіаквитків | Номер_Запису | Табл. продажу авіаквитків | Номер_Запису |
|
Авіаквиток | Номер_Авіаквитка | Авіаквиток | Номер_Авіаквитка |
|
К-во Просмотров: 394
Бесплатно скачать Дипломная работа: Облік перельотів пасажирів авіакомпанії
|