Моделирование бизнес-процессов (стр. 13 )

А.2.3.2. Конфигурирование данных

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

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

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

Рис. 65. Группы данных в системах workflow

Первая группа преимущественно содержит нетрадиционные данные, такие как мультимедийные документы, доставляемые клиенту системой workflow. Во второй группе выполняются лишь обращения к данным, хранящимся в информационных объектах. Управление доставкой данных осуществляется логически путем передачи привилегий доступа в рамках процесса.

Рассматривавшиеся до сих пор объекты метамодели могут служить для описания потребностей системы workflow в данных с точки зрения бизнеса (Caller. Vom Geschaftsprozeftmodell zum Workflow—Modell. 1997, c. 67). Иногда при моделировании целесообразно использовать отдельные экземпляры данных (конкретные документы), если они присутствуют в каждом экземпляре типа бизнес-процесса. В этом случае модель данных необходимо дополнить функциональными возможностями для администрирования экземпляров.

С точки зрения бизнеса, структуры данных в бизнес-приложениях все чаще описываются при помощи моделей данных. На рис. 66а и 66б приведены фрагменты моделей данных SAP R/3 и приложения ARIS. Хотя оба типа представления основаны на моделях ERM, их методология различна. Представление SAP-ERM объединяет модели ERM Чена (Chen. Entity-Relational model. 1976), структурированные модели ERM Зинца (Sinz. Datenmodellierung im SERM. 1993) и систему обозначений Бахмана (Bachman. The Programmer as Navigator. 1973).

Рис. 66а. Модель данных SAP

Рис. 66б. Модель данных приложения ARIS

Диаграмму ERM и выбранные здесь обозначения SAP-ERM можно объединить (Scheer. Business Process Engineering. 1994; Niittgens. Koordiniert-dezentrales Informationsmanagement. 1995, c. 104). С моделями данных для стандартного приложения обычно можно выполнять следующие манипуляции:

• удаление информационных объектов;

• удаление атрибутов;

• обновление числа разрядов в атрибутах;

• добавление атрибутов;

• добавление объектов данных.

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

Рис. 67. Конфигурирование пользовательского интерфейса на базе модели данных

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

А.2.3.3. Спецификация проекта в рамках модели данных

В процессе спецификации проекта языки интерфейсов для баз данных генерируются на основе семантической модели данных. Хотя эти интерфейсы соответствуют определенным моделям данных, мы должны отличать их от понятия «семантическая модель данных». Широко известны такие модели данных, как иерархические, сетевые, реляционные, объектно-ориентированные. Иерархические модели данных представляют интерес лишь с исторической точки зрения, а сетевые постепенно утрачивают свое значение, поэтому мы сосредоточим внимание на реляционных моделях данных и лишь вскользь затронем объектно-ориентированные.

На первом этапе информационные объекты уровня определения требований трансформируются в отношения. Здесь необходимо соблюдать определенные правила.

На втором этапе отношения оптимизируются посредством нормализации. При этом удаляются любые аномалии, возникающие при использовании функций «вставка», «изменение» и «удаление». Теперь предварительные отношения, перенесенные с уровня определения требований, разбиваются на более мелкие элементы. Если чрезмерная детализация приведет к снижению производительности, можно применить прямо противоположный метод, который называется денормализацией.

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

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

Реляционная схема переносится на используемый базой данных язык описания данных (ЯОД) и адаптируется к техническим требованиям ЯОД. Саму реализацию это никак не затрагивает. В то же время ЯОД представляет собой язык описания, наиболее «близкий» к реализации, где с моделью данных взаимодействуют другие модели ARIS. Приложения должны взаимодействовать только через схему базы данных, описанную посредством ЯОД.

А.2.3.3.1. Создание отношений

Отношения (Ri) описываются путем перечисления имен атрибутов Aij (см. (1) на рис. 68). Удобно представлять отношения в виде таблиц. С математической точки зрения, отношение есть подмножество декартова произведения доменов, связанных с атрибутами.

(1) Ri (Ai1, Ai2, … ,Aiz) aij = Attribute j in relation

Деталь (Номер детали, Имя, Запас)

Деталь	Номер детали	Имя	Запас
	4717	Отверстие	526
	4728	Болт	768

(2) Ri (Di1 x Di2 x … x Diz)

whereby D is the domain of A

Рис. 68. Описание отношений

Соблюдая сравнительно простые правила, отношения можно вывести на основе модели ERM, описывающей требования на уровне данных. При этом каждый тип сущности и каждый тип отношения n:n преобразуется в отношение. Тип отношения n:n означает, что максимальное значение мощностей связей по крайней мере двух смежных типов сущностей равно n.

С другой стороны, связи типа 1:n не имеют собственного отношения. В этом случае отношения адаптируются путем введения ключевого атрибута в тип сущности, в результате чего максимальное значение мощности оказывается равно 1 (см. примеры на рис. 69). Такой перенесенный ключевой атрибут называется внешним ключом.

Рис. 69. Выведение отношений на основе ЕПМ

Метамодель, представленная на рис. 70, вводит класс ОТНОШЕНИЕ. Его отношение с классом ИНФОРМАЦИОННЫЙ ОБЪЕКТ, созданным на стадии определения требований, устанавливается при помощи связи СОЗДАНИЕ ОТНОШЕНИЯ. В соответствии с формированием отношений информационный объект может иметь либо 0, либо (максимум) 1 отношение, тогда как одно отношение может быть связано с одним или множеством информационных объектов. Атрибутом класса ОТНОШЕНИЕ является его собственное имя, которое также может совпадать с именем исходного информационного объекта ERM. Имена атрибутов, принадлежащих тому или иному отношению, также можно взять из определения требований, хотя их можно и изменить. Если изменения не вносятся, атрибуты создаются путем связывания классов ОТНОШЕНИЕ и ИНФОРМАЦИОННЫЙ ОБЪЕКТ. Однако для того чтобы подчеркнуть автономность спецификации проекта на уровне разработки, присваиваемые отношению атрибуты связываются с общим описанием атрибутов на уровне определения требований при помощи АССОЦИАЦИИ ОТНОШЕНИЕ-АТРИБУТ. Если при переносе с уровня определения требований имена не меняются, отношения можно формировать в соответствии с описанными требованиями. Многие коммерческие инструменты типа CASE обеспечивают такой автоматический переход от модели ERM.

Рис. 70. Метамодель выведения отношений

Доступ доменов к имеющимся описаниям доменов, полученным на этапе определения требований, осуществляется через присвоение атрибутов. Для иллюстрации мы рассмотрим класс ДОМЕН, когда будем обсуждать реляционную модель и условия целостности, относящиеся к доменам.

В то время как перенос типов сущностей и отношений в реляционную модель не составляет проблемы, перенести в нее сложные объекты гораздо труднее. Это обусловлено тем, что возникает необходимость в таких дополнительных операциях, как импортирование в реляционную модель процедур неструктурированных групп данных или даже расширение модели данных до уровня объектно-ориентированной.