5 Разработка информационной модели

Построение информационной модели производится с помощью CASE-средства PLATINUM ERwin 4.0, которое удовлетворяет всем требованиям к системам разработки информационных моделей БД и является эффективным и удобным инструментом для построения моделей данных.

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

ERwin имеет два уровня представления модели – логический и физический.

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

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

5.1 Определение сущностей

Цель данного этапа – выявление и определение сущностей. Необходимо выявить среди исходных имен существительные, которые могут быть в дальнейшем представлены сущностями.

Сущность представляет собой множество реальных или абстрактных предметов, обладающих общими атрибутами или характеристиками. В ходе процесса определения сущностей возможны следующие ситуации: существительное может являться сущностью или атрибутом; могут появиться «невидимые» ранее сущности. Для отделения сущности от атрибута нужно ответить на вопросы:

• Может ли существительное быть описано как сущность?

• Обладает ли характерными особенностями?

• Существует ли более одного экземпляра?

• Может ли быть один экземпляр отделен (идентифицирован) от другого?

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

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

Таблица 5.1 - Выявление сущностей

DFD-диаграмма	Хранилища	Сущности	Внешние данные
Сформировать структуру документа	Классификатор "Документы"	Документы	Да
	Справочник "Календарь"	Календарь	Да
	Список категорий важности	Категории важности	Нет
Сформировать карточку исполнителю	Классификатор "Документы"	Документы	Да
	Справочник "Календарь"	Календарь	Да
	Автоматизированная система "Кадры"	Функциональные службы Картотека руководителей Подразделения ГРПЗ	Да
	Список категорий важности	Категории важности	Нет
Внести необходимую информацию о контролируемых работах	Автоматизированная система "Кадры"	Функциональные службы Картотека руководителей Подразделения ГРПЗ
	Список категорий важности	Категории важности	Нет
	Список признаков исполнения	Признаки исполнения	Нет
	Контролируемые работы	Контролируемые работы	Нет
Перенести сроки выполнения	Классификатор "Документы"	Документы	Да
	Справочник "Календарь"	Календарь	Да
	Автоматизированная система "Кадры"	Функциональные службы Картотека руководителей Подразделения ГРПЗ	Да
	Список причин переноса	Причины переноса	Нет
	Перенесённые работы	Перенесённые работы	Нет

В качестве внешних данных используются:

- автоматизированная система «Кадры»;

- общесистемный справочник «Календарь»;

- общесистемный классификатор «Документы».