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

Атрибут первинного ключа сутності не може мати значення NULL.

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

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

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

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

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

Вимоги даного Ощадбанку Ці вимоги, ще називають бізнес-правилами, які визначаються тими методами й обмеженнями, що прийняті в Ощадбанку

. Одним з них є те, що інспектор не може редагувати дані про робітників.

SQL код:

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

-- Create view viewEkonomist.

select [c1].[KliPrizvyzhe] AS [KliPrizvyzhe], [c1].[KliImya] AS [KliImya], [c1].[KliPoBatkovi] AS [KliPoBatkovi], [c2].[RahNomer] AS [RahNomer], [c3].[ObSum] AS [ObSum], [c3].[ObNomer] AS [ObNomer]

from [Klient] AS [c1], [Rahunok] AS [c2], [Oblik] AS [c3]

where [c1].[KliID] = [c3].[KliID] and

[c2].[RahNomer] = [c3].[RahNomer] ;

Представлення Завідуючий відділом

-- Create view viewZav.

select [c1].[KliPrizvyzhe] AS [KliPrizvyzhe], [c1].[KliImya] AS [KliImya], [c1].[KliPoBatkovi] AS [KliPoBatkovi], [c1].[KliAdresa] AS [KliAdresa], [c1].[KliTelefon] AS [KliTelefon], [c1].[KliPasport] AS [KliPasport], [c1].[KliIdentyfikNomer] AS [KliIdentyfikNomer], [c1].[KliDataNarodjennya] AS [KliDataNarodjennya], [c2].[ObSum] AS [ObSum], [c2].[ObNomer] AS [ObNomer]

from [Klient] AS [c1], [Oblik] AS [c2]

where [c1].[KliID] = [c2].[KliID] ;

Етап 2.7. Обговорення розроблених локальних логічних моделей даних з кінцевими користувачами

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

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

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

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

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