которых показывают альтернативы и места принятия решений в бизнеспроцессе, а также объекты – стрелки, которые показывают временную последовательность работ в бизнес-процессе (рис. 2.6).

Рис. 2.6. Схема бизнес-процесса в стандарте IDEF3

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

Таблица 2.1. Типы связей между работами в стандарте IDEF3

Помимо наличия нескольких типов связей между работами в стандарте IDEF3 логические операторы, которые в данном случае называются перекрестками, также делятся на несколько типов. «Исключающий ИЛИ», «И» и «ИЛИ».

60

Перекресток «Исключающий ИЛИ» обозначает, что после завершения работы «A», начинает выполняться только одна из трех расположенных параллельно работ B, С или D в зависимости от условий 1, 2 и 3 (рис. 2.7). Перекресток «И» обозначает, что после завершения работы «A», начинают выполняться одновременно три параллельно расположенные работы B, С и D. Перекресток «ИЛИ» обозначает, что после завершения работы «A», может запуститься любая комбинация трех параллельно расположенных работ B, С и D. Например, может запуститься только одна из них, три работы, а также двойные комбинации В и С, либо C и D, либо B и D. Перекресток «Исключающий ИЛИ» является самым неопределенным, так как предполагает несколько возможных сценариев реализации бизнес-процесса и применяется для описания слабо формализованных ситуаций.

Перекрестки «И» и «ИЛИ» подразделяются еще на два подтипа – синхронные и асинхронные. Перекрестки синхронного типа обозначают, что работы В, С и D запускаются одновременно после завершения работы

61

Характеристики всех типов перекрестков, как в схемах схождения, так и в схемах расхождения приведены в табл. 2.2.

62

Таблица 2.2. Обозначения, названия и смысл типов перекрестков в схемах схождения и расхождения

Последним отличием стандарта IDEF3 от классической методологии WFD является использование на схеме бизнес-процесса такого элемента, как «объект ссылки», с помощью которого показывается прочая важная информация, которую целесообразно зафиксировать при описании бизнеспроцесса.

2.6. Построение информационной модели системы. Проектирование баз данных

Диаграммы «сущность–связь» (entity – relationship ERD)

ERD предназначены для разработки информационных моделей системы, т. е. моделей данных; обеспечивает стандартный способ определения данных и отношений между ними. С помощью ERD осуществляется детализация хранилищ данных функциональной модели системы.

Такой подход был предложен Ченом и получил дальнейшее развитие в работах Баркера.

Нотация Баркера. Модель «сущность – связь» в нотации Баркера. Методология IDEF1X

В нотации Баркера используется только один тип диаграмм – диаграмма «сущность – связь» ERD. Она основывается на важной семантической информации о реальном мире. Может использоваться в

63

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

1.Сущность (entity) – это «предмет», который может быть идентифицирован некоторым способом, отличающим его от других «предметов» (определение Питера Чена). Каждая сущность обладает набором атрибутов (рис. 2.9). Атрибут – отдельная характеристика сущности. Сущность состоит из экземпляров, каждый из которых должен отличаться от другого. Пример: сущность – сотрудник, экземпляр сущности – сотрудник Петров Виктор Сергеевич.

2.Связь (relationship) – это логическая ассоциация, устанавливаемая между сущностями; представляет собой бизнес-правило или ограничение. Сущность отображается прямоугольником, сверху которого представлено название сущности. Прямоугольник делится горизонтальной линией: атрибуты, представленные выше линии, являются атрибутами первичного ключа; ниже линии представлены неключевые атрибуты.

Рис. 2.9. Отображение сущности

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

Связи отображаются как линии между сущностями (рис. 2.10). В зависимости от роли в связи сущность может быть родительской или дочерней. В методике IDEF1X у дочерней сущности на связи присутствует точка. Каждая связь имеет глагольную фразу, которая ее характеризует. Глагольная фраза читается по следующей формуле: название родительской сущности + глагольная фраза + название дочерней сущности. Иногда для большей ясности разработчики используют вторую глагольную фразу, которая читается по формуле: название дочерней сущности + глагольная фраза + название родительской сущности.

Существует два типа сущностей:

зависимая сущность. Для определения экземпляра такой сущности необходимо сослаться на экземпляр независимой сущности, с которой

64

связана зависимая сущность. Пример: сущности – заказ и позиция заказа. Для идентификации позиции заказа нужно сослаться на заказ, в который входит данная позиция;

независимая сущность. Для определения экземпляра сущности нет необходимости ссылаться на другие сущности. Пример: сущности – заказ и позиция заказа. Для определения заказа (сущности) нет необходимости ссылаться на позиции этого заказа (другие сущности).

Существует несколько видов связей.

Идентифицирующая связь указывает на то, что дочерняя сущность в связи является зависимой от родительской, т. е. экземпляр зависимой сущности может быть однозначно определен только в том случае, если в этом экземпляре есть ссылка на экземпляр независимой сущности. Идентифицирующая связь отображается сплошной линией, причем дочерняя сущность является зависимой и поэтому отображается прямоугольником со скругленными углами (рис. 2.10).

Рис. 2.10. Идентифицирующая связь

Неидентифицирующая связь показывает на зависимость между родительской и дочерней сущностями, при этом экземпляр дочерней сущности может быть однозначно идентифицирован без ссылки на экземпляр родительской сущности. Неидентифицирующая связь отображается штриховой линией (рис. 2.11).

Рис. 2.11. Неидентифицирующая связь

Связь «многие ко многим» (рис. 2.12). Неспецифичный тип связи, во многом свидетельствующий о незавершенности анализа. На конечных этапах моделирования данных все связи «многие-ко-многим» преобразуются в другие (идентифицирующие и неидентифицирующие) типы связей. В связи «многие-ко-многим» не выделяются родительская и дочерняя сущность и, как правило, используются две глагольных фразы.

65

идентификацию связей и указание типов отношений. Связи может присваиваться имя, выражаемое глаголом или грамматическим оборотом; идентификацию атрибутов. Атрибуты бывают обязательные и необязательные. Обязательные атрибуты не могут принимать неопределенных значений. Обязательными являются все атрибуты

первичного ключа, а также некоторые из неключевых атрибутов.

Методика построения информационной модели данных или модели «сущность – связь»

Разработка диаграммы «сущность–связь» включает следующие основные этапы:

идентификацию сущностей, их атрибутов, первичных и альтернативных ключей;

идентификацию отношений между сущностями и указание типов отношений;

разрешение неспецифических отношений.

Для реляционной модели данных неспецифическими являются отношения типа «многие-ко-многим».

Первый этап является определяющим при построении модели данных. Исходная информация для данного этапа – содержимое хранилищ данных функциональной модели системы. На первом этапе осуществляется упрощение схемы отношений за счет ее нормализации путем избавления от повторяющихся строк таблицы. Нормализация всегда выполняется путем расщепления сущности на две или более простых сущностей.

Методы нормализации схемы базы данных были предложены Коддом в работах, посвященных реляционной модели данных. Кодд определил для схемы отношений существование трех нормальных форм: первой, второй и третьей.

Примеры диаграмм для предметной области «Сервисный центр по гарантийному обслуживанию компьютерной техники» представлены на рис. 2.15–2.20.

68

69

70

Отдел

ID_Отдела Определяет

Название отдела Назначение отдел

Получил

Виднеисправности

Диагностирует ID_Неисправности

ID_Техники (FK)

Описание неисправнос ID_Сотрудника (FK)

Рис. 2.20. Модель данных в стандарте IDEF1X, выполненная при помощи инструмента Erwin (аналог – в характеристике на Power Designer

и приложении на Enterprise Architect)

71