Етап 2.5. Створення діаграм „сутність -зв'язок"
Графічне представлення способу виконання транзакцій безпосередньо на ER-діаграмі (див. рис.11) дозволяє виявити області моделі, що є критичними з погляду виконання транзакцій, а також ті області діаграми, які не використовуються при їх виконанні. Наприклад, на рис.11 не представлені шляхи виконання транзакцій g і h, описаних у попередньому розділі, оскільки вони вимагають наявності прямого зв'язку між сутностями Клієнт і Відділення, необхідного для ідентифікації клієнтів, зв'язаних з кожним з відділень. Це дозволяє зробити висновок, що критичний для виконання транзакцій зв'язок між сутностями Клієнт і Відділення був пропущений при побудові моделі й обов'язково повинний бути внесений в остаточний варіант моделі даних. Додаткові обговорення з користувачами показали, що кожен клієнт реєструється тільки в одному з відділень. У результаті в модель був уведений новий зв'язок — Відділення Реєструє Клієнта, показаний на рис.12, а у відношення Клієнт був поміщений новий зовнішній ключ - Номер_відділення.
Зверніть увагу, що на
ER-діаграмі, показаній на рис.11, немає
транзакцій, що використовує відношення
Працівник Проводить Інтерв’ю і
Інтерв’ю З Клієнтом. 
Наслідком
цього факту стала поява сумнівів у
необхідності збереження відповідної
інформації в базі даних. Після консультацій
з користувачами було прийняте рішення
про доцільність видалення даної частини
локальної логічної моделі даних
користувача Інспектор. Хоча практику
проведення співбесід з потенційними
клієнтами (якщо це можливо) у кампанії
ніхто не скасовував, до зведень про
проведення подібних співбесід Дата
Інтерв’ю і Коментарі згодом
звертаються рідко (якщо взагалі
звертаються). Після обговорення
користувачі підтвердили доцільність
видалення сутності Інтерв’ю і усіх
установлених з нею зв'язків з логічної
моделі даних. Не існує також транзакцій,
що використовують присутню в моделі
даних зв'язок Працівник Організує
Угоду оренди. Проведення консультацій
з користувачами показало, що, хоча угода
про оренду користувачем об'єкта готується
визначеним працівником, ця інформація
згодом не представляє інтересу для
компанії. Тому зв'язок Працівник
Організує Угоду оренди є надлишковим
і повинний бути вилучений з моделі
даних користувача Інспектор.
Остаточний варіант ER-діаграми логічної моделі даних для користувача Інспектор, виконаний з обліком усіх внесених змін, показаний на рис.12.
Етап 2.6. Визначення вимог підтримки цілісності даних
На цьому етапі ми займемося визначенням тих вимог підтримки цілісності даних, які необхідно реалізувати в локальній логічній моделі даних користувача Інспектор. Їхнє призначення складається в підтримці постійної внутрішньої погодженості інформації, організованої у виді бази даних. На даному етапі наше завдання полягає в тім, щоб установити, які саме вимоги підтримки цілісності даних необхідні, а питання методів їх реалізації будуть вирішуватися пізніше. Ми розглянемо п'ять типів вимог підтримки цілісності:
обов'язкові дані;
обмеження для доменів атрибутів;
цілісність сутностей;
посилальна цілісність;
вимоги даного підприємства.