Застосування методології концептуального проектування баз даних

Етап 1. Побудова локальної концептуальної моделі даних для представлення користувача „Інспектор”.

Приступаючи до розроблення локальної концептуальної моделі даних для представлення користувача „Інспектор” у програмі „Нерухомість”, насамперед, варто виявити різні компоненти цієї моделі, використовуючи наявні специфікації вимог користувача (далі - просто "специфікації"). У кожну створювану модель даних входять наступні компоненти:

· типи сутностей;

· типи зв'язків;

· атрибути;

· домени атрибутів;

· потенційні ключі;

· первинні ключі.

Етап 1.1. Визначення типів сутностей

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

· відділення;

· оголошення;

· працівник;

· газета;

· інспектор;

· співбесіда;

· секретар;

· клієнт;

· об'єкт, що здається в оренду;

· договір про оренду;

· власник - фізична особа;

· інспекція;

· власник - юридична особа.

Документування виділених типів сутностей

Документування зведень про кожнуз виділених сутностей полягає в підготовці докладного визначення кожної сутності, включаючи існуючі для неї псевдоніми й опис особливостей використання - наприклад, таких: "Кожен об'єктмає єдиного власника". Всі зведення, поміщені в документацію на цьому етапі, наведені в додатку, розташованому наприкінці цієї глави.

Етап 1.2. Визначення типів зв'язків

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

Таблиця 1.1 Основні типи зв'язків, виділені в специфікаціях для користувача „Інспектор”

Тип сутності	Тип зв'язку	Тип сутності
Відділення	Має à	Працівник
Працівник	Відповідає за à Виконує розпорядження à Користується послугами à Проводить à Оформляє à Виконує à	Об'єкт Інспектор Секретар Співбесіда Угода Інспекція
Інспектор	Керує à	Працівник
Об'єкт	Закріплюється за à Обслуговується à Належить à	Філія Працівник Власник
Власник – фізична особа	Володіє à	Об'єкт
Власник - юридична особа	Володіє à	Об'єкт
Оголошення	Описує à Міститься в à	Об'єкт Газета
Співбесіда	Виконується з à	Клієнт
Клієнт	Оглядає à Орендує à Укладає à	Об'єкт Об'єкт Угода
Угода оренди	Зв'язана з à	Об'єкт
Інспекція	Проводиться для à	Об'єкт

Проаналізувавши таблицю 1.1, можна знайти, що деякі зв'язки, по суті, є однаковими. Наприклад, два типи зв'язків - „Працівник Виконує розпорядження Інспектора” та „Інспектор керує працівником” - фактично представляють той самий зв'язок. Цей зв'язок двічі зазначений у таблиці 1.1 по тій простій причині, що в специфікаціях даний зв'язок визначений як на боці „працівника”, так і на боці „інспектора”.

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