3.3.1 Характеристика входной информации

При описании данного пункта необходимо сначала описать перечень всей входной информации, удобнее представить данный материал будет в табличном виде

Характеристика входной информации

Входная информация	Источник данных	Получатель	Периодичность	Вид документа	Приложение
Название Документа 1	Например, Контрагент	Например, Отдел	Ежедневно	Входной документ	Приложение …
Название Документа N	Например, Склад	Например, Контрагент	Ежемесячно	Входной документ	…
Электронный файл			Оперативно/ по мере формирования/ по запросу	Электронное сообщение	…
Справочник базы данных (наименование)					…

В случае разработки информационной системы и появления необходимости в разработке состава и содержания входных документов, определения их реквизитного состава и методов их построения в этом пункте проводится проектирования такой входной информации.

3.3.2 Характеристика выходной информации

Аналогичным образом (в подобной таблице) описывается состав и характеристика выходной информации, при необходимости разрабатываются и проектируются формы экранных и печатных выходных документов, и файлов, описывается их реквизитный состав.

3. Концептуальная информационная модель системы

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

Последовательность шагов при концептуальном проектировании:

Выделение сущностей. Первый шаг в построении концептуальной модели данных состоит в определении основных объектов (сущностей), которые могут интересовать пользователя и, следовательно, должны храниться в БД. При наличии функциональной модели IDEF0 прообразами таких объектов являются входы, управления и выходы. Еще лучше для этих целей использовать DFD. Прообразами объектов в этом случае будут накопители данных. Как было отмечено выше, накопитель данных является совокупностью таблиц (набором объектов) или непосредственно таблицей (объектом). Для более детального определения набора основных объектов необходимо также проанализировать потоки данных и весь методический материал, требуемый для решения задачи.

В ходе анализа и проектирования информационной модели наборы объектов должны быть детализированы.

Определение атрибутов. Как правило, атрибуты указываются только для сущностей. Если у связи имеются атрибуты, то это указывает на тот факт, что связь является сущностью. Самый простой способ определения атрибутов – после идентификации сущности или связи, задать себе вопрос «Какую информацию требуется хранить о …?». Существенно помочь в определении атрибутов могут различные бумажные и электронные формы и документы, используемые в организации при решении задачи. Это могут быть формы, содержащие как исходную информацию, так и результаты обработки данных.

Определение связей. Наиболее характерными типами связей между сущностями являются:

связи типа «часть–целое», определяемые обычно глаголами «состоит из», «включает» и т.п.;

классифицирующие связи (например, «тип – подтип», «множество – элемент», «общее – частное» и т. п.);

производственные связи (например, «начальник–подчиненный»);

функциональные связи, определяемые обычно глаголами «производит», «влияет», «зависит от», «вычисляется по» и т. п.

Среди них выделяются только те связи, которые необходимы для удовлетворения требований к разработке БД.

Определение суперклассов и подклассов. В тех случаях, когда две и более сущностей по набору атрибутов незначительно отличаются друг от друга, можно применять в модели конструкцию – иерархию наследования (категорий), включающую в себя суперклассы и подклассы.

Суперкласс – сущность, включающая в себя подклассы.