природного з'єднання.

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

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

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

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

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

Створення і коректування записів, що містять докладні зведення про роботу Ощадбанку, яке обслуговує клієнтів різного типу:

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

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

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

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

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

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

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

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

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

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

• вимоги головпоштамту.

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

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

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

Докладні зведення про атрибути, що входять у локальну модель даних були приведені при виконанні етапу 2.3.

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

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

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