Атрибут первинного ключа сутності не може мати значення NULL. Наприклад, кожен екземпляр сутності Відділення обов'язково повинен мати конкретне значення атрибута його первинного ключа Номер_Відділення. Атрибути, що входять у значення первинного ключа кожної сутності, були визначені при виконанні попередніх етапів Докладні зведення про ключі сутностей представлені в додатку.
Зв'язки між сутностями моделюються за допомогою приміщення в дочірнє відношення копії первинного ключа батьківського відношення. Поняття посилальної цілісності означає, що якщо зовнішній ключ дочірнього відношення містить деяке значення, то це значення повинне посилатися на існуюче і коректне значення ключа в батьківському відношенні. Атрибути, що входять до складу первинних і зовнішніх ключів різних сутностей, представлені в додатку В.
Підтримка посилальної цілісності організується за допомогою завдання необхідних обмежень для значень первинних і зовнішніх ключів. Ці обмеження визначають умови, яких слід дотримуватися при відновленні або видаленні значень первинного ключа, а також при вставці або відновленні значень зовнішнього ключа. Відзначимо, що вставка нового значення первинного ключа або видалення значення зовнішнього ключа не викликає яких-небудь проблем з посилальною цілісністю.
Для кожного зовнішнього ключа відношення варто вказати умови, що повинні виконуватися при відновленні або видаленні відповідного значення первинного ключа. У цьому випадку можна застосувати одну з пропонованих стратегій - NO ACTION, CASCADE, SET NULL, SET DEFAULT або NO CHECK (див. додаток Д).
Ці вимоги, які інакше називаються бізнес-правилами, визначаються тими методами й обмеженнями, що прийняті на даному підприємстві щодо виконання різних операцій. Наприклад, у АТП установлено, що працівник може бути закріпленим лише за одним відділом. Основні бізнес-правила авіакомпанії представлені у додатку Е.
Етап 3. Створити і перевірити глобальну логічну модель даних.
На цьому етапі ми зіллємо дві локальні логічні моделі даних з метою створення глобальної логічної моделі даних, тобто глобального представлення для всієї авіакомпанії. Процес злиття моделей даних ми почнемо з виявлення в них подібних елементів, після чого виконаємо пошук і видалення конфліктних областей. Завершить процедуру включення в глобальну модель унікальних областей кожної з вихідних локальних моделей. Деякі типові задачі, що доводиться вирішувати під час виконання злиття, нижче будуть проілюстровані на конкретних прикладах.
Порівняємо імена сутностей і визначені для них первинні ключі кожної з локальних моделей, що зливаються.
Таблиця 3.1
Порівняння імен сутностей і їхніх первинних ключів у представленнях користувачів Директор і Касир
| Тип сутності (представлення Директор) | Первинний ключ | Тип сутності (представлення Касир) | Первинний ключ |
| Відділення | Номер_Відділення | Відділення | Номер_Відділення |
| Працівник | Номер_Працівника | Працівник | Номер_Працівника |
| Табл. продажу авіаквитків | Номер_Запису | Табл. продажу авіаквитків | Номер_Запису |
| Авіаквиток | Номер_Авіаквитка | Авіаквиток | Номер_Авіаквитка |
| Клієнт | Номер_Клієнта | Клієнт | Номер_Клієнта |
| Клас | Номер_Класу | Клас | Номер_Класу |
| Розклад авіа перельотів | Номер_Запису | Розклад авіа перельотів | Номер_Запису |
| Рейс | Номер_Рейсу | Рейс | Номер_Рейсу |
| Напрям | Номер_Напряму | Напрям | Номер_Напряму |
Попереднє порівняння імен сутностей і їх первинних ключів у кожному із представлень дозволяє виявити їх загальні ділянки, тобто ті області, у яких вони перекриваються.
Тепер порівняємо імена присутніх у представленнях Директор і Касир зв'язків. Імена зв'язків, що існують у кожному із представлень, показані в табл. Кожен зв'язок представлений у таблиці тільки один раз і асоційований з її батьківською сутністю.
Таблиця 3.2
Порівняння зв'язків, наявних у представленнях Директор і Касир
| Сутності (представлення Директор) | Тип зв'язку | Тип сутності (представлення Директор) | Сутності (представлення Касир) | Тип зв'язку | Тип сутності (представлення Касир) |
| Відділення | Має Знаходиться під керівництвом | Працівник Директор | Відділення | Має Знаходиться під керівництвом | Працівник Директор |
| Працівник | Належить до | Відділення | Працівник | Належить до | Відділення |
| Директор | Керує | Відділення | Директор | Керує | Відділення |
| Касир | Фіксується у | Таблиця продажу авіаквитків | Касир | Фіксується у | Таблиця продажу авіаквитків |
| Екіпаж | Перебуває у | Літак | Екіпаж | Перебуває у | Літак |
| Клієнт | Одержує | Авіаквиток | Клієнт | Одержує | Авіаквиток |
| Авіаквиток | Фіксується у Належить | Таблиця продажу авіаквитків Клієнт | Авіаквиток | Фіксується у Належить | Таблиця продажу авіаквитків Клієнт |
| Клас | Належить до | Таблиця продажу авіаквитків | Клас | Належить до | Таблиця продажу авіаквитків |
| Напрям | Визначає | Рейс | Напрям | Визначає | Рейс |
| Рейс | Здійснюється у | Напрям | Рейс | Здійснюється у | Напрям |
| Рейс | Фіксується у | Розклад авіа перельотів | Рейс | Фіксується у | Розклад авіа перельотів |
| Таблиця продажу авіаквитків | Підпорядкована Містить дані про Містить дані про Містить дані про | Розклад авіа перельотів Касир Авіаквиток Клас | Таблиця продажу авіаквитків | Підпорядкована Містить дані про Містить дані про Містить дані про | Розклад авіа перельотів Касир Авіаквиток Клас |
| Літак | Фіксується у Містить у собі | Розклад авіа перельотів Екіпаж | Літак | Фіксується у Містить у собі | Розклад авіа перельотів Екіпаж |
| Розклад авіа перельотів | Містить дані з Містить дані про | Таблиця продажу авіаквитків Літак Рейс | Розклад авіа перельотів | Містить дані з Містить дані про Містить дані про | Таблиця продажу авіаквитків Літак Рейс |
Це попереднє порівняння імен зв'язків у кожному із представлень користувачів також допомагає уточнити ділянки, спільні для обох представлень. Однак із цього зовсім не випливає що можна покладатися на те, що сутності або зв'язок з тими ж іменами відіграють однакову роль у кожному із представлень. І все-ж таки, порівняння імен сутностей і зв'язків можна вважати дуже зручною вихідною точкою пошуку ідентичних ділянок у представленнях, що зливаються, якщо, звичайно, не забувати, про можливі помилки.
Злиття загальних сутностей з окремих локальних моделей
На даному етапі виконується перевірка імен і вмісту кожної сутності в обох представленнях. Зокрема, для ідентифікації еквівалентних сутностей з різними іменами варто проаналізувати їхні первинні ключі. Виконання даного етапу включає наступні дії:
· злиття сутностей з однаковими іменами й однаковими первинними ключами;
· злиття сутностей з однаковими іменами, що мають різні первинні ключі;
· злиття сутностей з різними іменами, що мають однакові або різні первинні ключі.
Злиття сутностей з однаковими іменами й однаковими первинними ключами.
Сутності, що мають в обох представленнях той самий первинний ключ, як правило, представляють ту саму концепцію реального світу. Ідентифікація й об'єднання подібних пар являє собою відносно нескладну задачу.
Такі сутності відсутні.
Такі сутності відсутні.
Глобальне представлення
ВІДДІЛЕННЯ (Номер_Відділення, Телефон, Факс, Поштовий_Код, E-mail).
Первинний ключ - Номер_Відділення.
ЛІТАК (Номер_Літака, Назва).
Первинний ключ – Номер_Літака.
На цьому етапі виконується аналіз імен і призначення всіх зв'язків, що є наявними в обох локальних представленнях. Перш ніж приступати до злиття зв'язків, дуже важливо усунути будь-які конфлікти, що стосуються їх кардинальності і ступеня участі сторін. Імена зв'язків, що наявні в обох локальних представленнях, утримуються в таблиці. Обов'язковою задачею, розв'язуваної на даному етапі, є злиття зв'язків, що мають однакові імена і подібне призначення, а також злиття зв'язків, що мають різні імена, але ідентичне призначення. Але в локальних логічних моделях обох представлень такі зв’язки не були виявлені.