
- •Корпоративные информационные системы
- •Введение
- •1. Анализ предметной области
- •1.1. Описание объекта автоматизации
- •1.2. Учет готовой продукции
- •2. Проектирование модели бизнес процессов
- •2.1. Диаграмма потоков данных dfd
- •2.2. Функциональная модель idef0
- •3. Проектирование модели базы данных
- •3.1. Логическая модель
- •3.2. Физическая модель
- •3.3. Физическая модель в режиме отображения представлений
- •Заключение
2. Проектирование модели бизнес процессов
2.1. Диаграмма потоков данных dfd
DFD - диаграмма потоков данных используется для описания потоков информации между узлами обработки и внешними ссылками.
Моделирование потоков данных (DFD), часто используемое при разработке программного обеспечения, сосредоточено вокруг потоков данных, передающихся между различными операциями, включая их хранение, для достижения максимальной доступности и минимального времени ответа. Такое моделирование позволяет рассмотреть конкретный процесс, проанализировать операции, из которых он состоит, а также точки принятия решений.
Диаграмма потоков данных представлена на рисунке 3.
Рисунок 3 – Диаграмма потоков данных.
2.2. Функциональная модель idef0
IDEF0 - язык функционального моделирования, широко применяемый при структурном моделировании системы. При использовании данного метода сначала дается общий обзор сложной системы, после чего осуществляется детализация элементов с одновременной разработкой их структуры.
Первая диаграмма в иерархии диаграмм IDEF0 изображает функционирование в целом. Такие диаграммы называются контекстными. В контекстные диаграммы входит описание цели моделирования, области (описания того, что будет рассматриваться в качестве компонента системы, а что в качестве внешнего воздействия) и точки зрения (позиции, с которой будет строиться модель).
Контекстная диаграмма представлена на рисунке 4.
Рисунок 4 – Контекстная диаграмма КИС
После того как контекст описан, проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на диаграмме вышестоящего уровня.
Контекстную диаграмму разбиваем на 5 блоков в соответствии с функциями объекта автоматизации, представлена на рисунке 5.
Рисунок 5 – Декомпозиция основного процесса
3. Проектирование модели базы данных
3.1. Логическая модель
Логическая модель данных описывает факты и объекты, подлежащие регистрации в будущей базе данных. Основными компонентами такой модели являются сущности, их атрибуты и связи между ними. Физическим аналогом сущности в будущей базе данных является таблица, атрибута — поле этой таблицы.
С логической точки зрения сущность представляет собой совокупность однотипных объектов или фактов, называемых экземплярами этой сущности. Физическим аналогом экземпляра является запись в таблице базы данных. Как и записи в таблице реляционной СУБД, экземпляры сущности должны быть уникальными, то есть полный набор значений их атрибутов не должен дублироваться. И так же, как и поля в таблице, атрибуты могут быть ключевыми и не ключевыми.
На этапе логического проектирования для каждого атрибута обычно определяется примерный тип данных (строковый, числовой, BLOB и др.). Конкретизация происходит на этапе физического проектирования, так как различные СУБД поддерживают разные типы данных и ограничения на их длину или точность.
Связь с логической точки зрения представляет собой соотношение между сущностями, которое нередко может быть выражено обычными фразами, например: «поступление стройматериала на склад».
ER-диаграмма логического уровня представлена на рисунке 6.