3 Создание локальных концептуальных моделей

Известны две точки зрения на информационную модель и, соответственно, два уровня представления модели:

• Логический уровень (точка зрения пользователя). Это абстрактный взгляд на данные. На нем используются данные в таком виде, в каком они известны в реальном мире. Объектам модели (сущностям и атрибутам) даются имена, понятные широкому кругу специалистов. Логическая модель данных является универсальной и никак не связана с особенностями реализации конкретной системы управления базой данных (СУБД).

• Физический уровень – определяет представление информации в базе данных (БД). На физическом уровне объекты модели должны обозначаться так, как того требуют ограничения выбранной СУБД. Если в логической модели не имеет принципиального значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о таблицах, колонках, индексах, процедурах и т.п. Такую модель создают специалисты по СУБД.

Основными компонентами диаграммы в ERwin являются сущности, атрибуты и связи. Каждая сущность является множеством подобных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта.

Разработка информационной модели начинается с создания логической модели. После этого проектировщик выбирает необходимую СУБД и с помощью специальных средств создает соответствующую физическую модель. На основе физической модели генерируется специальный каталог СУБД или соответствующий SQL-скрипт.

Концептуальное проектирование – процедура конструирования информационной модели предприятия, не зависящей от каких-либо условий реализации. Фаза концептуального проектирования начинается с создания концептуальной модели данных, полностью независимой от типа СУБД, приложения, языка программирования, типа компьютера и т.п.

3.1 Выявление и определение сущностей на основе анализа dfd-диаграммы

Сущность – представляет собой множество реальных или абстрактных предметов, обладающих общими атрибутами или характеристиками.

На DFD-диаграмме информация, которую необходимо хранить в БД, изображается с помощью «хранилищ». Таким образом, выявляя на диаграммах потоков данных хранилища информации, мы определяем перечень сущностей, которые в дальнейшем потребуется создать при построении локальных концептуальных и логических моделей данных.

Рассмотрим DFD-диаграммы блоков. Из хранилищ данных выделим сущности и дадим им имена. Проана­лизируем DFD – диаграмму блока «Принять заказ на строительство», показанную на рисунке 3. Данная DFD – диаграмма содержит следующие хранилища: «Список клиентов», «Список мест строительства», «Список сотрудников строительной фирмы», «Список стоимостей строительства», «Список дат оформления договоров», «Список сроков сдачи строительства», «Список проектов зданий» и «Список заказов». В локальной концептуальной модели на логическом уровне должны быть представлены сущности, соответствующие этим хранилищам. Назовем их соответственно «КЛИЕНТ», «СОТРУДНИК», «ЗАКАЗ_НА_СТРОИТЕЛЬСТВО», «АДРЕС». Создавать сущности для хранилищ «Список стоимостей строительства», «Список сроков сдачи строительства», «Список дат оформления договоров» нет смысла. Лучше сделать эти хранилища атрибутами сущности «ЗАКАЗ_НА_СТРОИТЕЛЬСТВО». Аналогично, анализируем остальные три DFD – диаграммы.

На диаграмме «Провести подготовительные работы», представленную на рисунке 4, имеются хранилища данных: «Список работ», «Список сотрудников строительной фирмы», «Список документов, необходимых для получения разрешения на строительство», «Список требований от экологов», «Список заказов, готовых к строительству», «Список купленных мест, готовых к строительству». Выделяем четыре сущности: «СОТРУДНИК», «АДРЕС», «ЗАКАЗ_НА_ СТРОИТЕЛЬСТВО», «РАБОТА». Хранилище «Список заказов, готовых к строительству» будет атрибутом сущности «ЗАКАЗ_НА_СТРОИТЕЛЬСТВО». Хранилища данных «Список документов, необходимых для получения разрешения на строительство» и «Список требований от экологов» в электронной базе данных храниться не будут, так как их хранение в базе нецелесообразно.

На диаграмме «Выполнить строительные работы», представленную на рисунке 5, имеются хранилища данных: «Список работ», «Список сотрудников строительной фирмы», «Список строительных материалов», «Список количества материалов, расходуемых на работу», «Список коттеджей, готовых к проверке». Исходя их этих хранилищ, выделяем сущности: «СОТРУДНИК», «МАТЕРИАЛ», «ЗАКАЗ_НА_ СТРОИТЕЛЬСТВО», «РАБОТА». Хранилище «Список количества материалов, расходуемых на работу» будет атрибутом сущности «РАБОТА».

На диаграмме «Пройти обследование на соответствие стандарту качества», представленную на рисунке 6, имеются следующие хранилища данных: «Список работ», «Список сотрудников строительной фирмы», «Список сотрудников жилищной комиссии» и «Список построенных коттеджей». Выделяем четыре сущности: «СОТРУДНИК», «ЗАКАЗ_НА_СТРОИТЕЛЬСТВО» и «РАБОТА». Для хранилища данных «Список сотрудников жилищной комиссии» сущность создаваться не будет, так как его хранение в электронной базе строительной фирмы нецелесообразно.