Sunday, August 2, 2009

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec H -- By Mathias Weske

Modelling Process Data

Business processes operate on data. Explicitly representing data, data types, and data dependencies between activities of a business process puts a business
process management system in a position to control the transfer of relevant
data as generated and processed during processes enactment.

Modelling Data

Data modelling is at the core of database design. The Entity Relationship
approach is used to classify and organize data in a given application domain.
The Entity Relationship modelling approach belongs to the metamodel level. it provides the required concepts to express
data models. Data modelling will be illustrated by a sample application
domain, namely by order management.
In a modelling effort, the most important entities are identified and classified.
Entities are identifiable things or concepts in the real world that are
important to the modelling goal. In the sample scenario, orders, customers,
and products are among the entities of the real world that need to be represented
in the data model.
Entities are classified as entity types if they have the same or similar
properties. Therefore, orders are classified by an entity type called Orders.
Since each order has an order number, a date, a quantity, and an amount, all
order entities can be represented by this entity type. Properties of entities are
represented by attributes of the respective entity types.
The entities classified in an entity type need to have similar, but not identical
structure, because attributes can be optional. If the application domain
allows, for instance, for an order to have or not to have a discount, then the
amount attribute is optional. This means that two orders are classified in
entity type order even if one has a discount attribute while another does not.
Entity types in the Entity Relationship metamodel need to be represented
in a notation by a particular symbol. While there are variants of Entity Relationship
notations, entity types are often represented by rectangles, marked
with the name of the entity type. Other entity types in the sample application domain
are customers and products. The attributes are represented as ellipsoids
attached to entity types.
Entities are associated with each other by relationships. For instance, a
customer “Miller” requests an order with the order number 42. These types of
links between entities are called relationships. Just as there are many customer entities and many order entities, there are many customer-order relationships.
To represent these relationships, a relationship type requests classifies them
all. In Entity Relationship diagrams, relationship types are typically represented
by diamond symbols, connected to the respective entity types by edges.
The complex nature of data in a given application domain can be well
represented by Entity Relationship Diagrams. These diagrams can be used to
create relational database tables, using transformation rules. Once the respective
database tables have been created in a relational database, application
data can be stored persistently. The data can be retrieved efficiently using
declarative query languages, for instance Structured Query Language.
While this discussion focuses on data modelling in the context of database
applications, the same data modelling method can be used to represent data
structures in business process management. Based on these data structures,
data dependencies between activities in business processes can be captured
precisely.
Data modelling is also the basis for the integration of heterogeneous data.
In the enterprise application integration scenarios discussed above, one of the
main issues was the integration of data from heterogeneous data sources. Once
data models are available for these data sources, the data integration problem
can be addressed. There are advanced data integration techniques that also
take into account data at the instance level, but explicit data models in general
are essential to addressing data integration.
Data integration can then be realized by a mapping between the data
types. For instance, there might be applications on top of database systems A
and B, such that these systems have tables CustomerA and CustomerB, respectively,
that differ. For instance, while CName is the attribute of the CustomerA
table, referring to the name of the customer, CustN might be the respective
attribute in the CustomerB table. In order to integrate both tables, the attributes
need to be mapped. In this case, CustomerA.CName is mapped to
CustomerB.CustN.
In data integration projects, complex integration problems are likely to
emerge. There might be attributes that cannot be mapped, but there might
also be attributes that need to be mapped to different tables, often by our
using transformation rules. The hardest set of problems, however, stem from
semantic heterogeneity. There are assumptions on the data that are not explicit
in the data model or in the actual data stored in the database. These
semantic differences can only be taken into account when investigating the
meaning of the attributes in detail, often during interviews with the persons
involved in the data modelling and database design of the systems to integrate.
Semantic specification of data can be used to solve these data integration
problems. However, complete semantic specification of data requires considerable
resources, and the completeness of the semantic specification cannot be
proven automatically. Therefore, further research is required to evaluate the
possibilities of semantics-based data integration.
In graph-based approaches to business process modelling, data dependencies
are represented by data flow between activities. Each process activity is
assigned a set of input and a set of output parameters. Upon its start, an
activity reads its input parameters, and upon its termination it writes data it
generated to its output parameters. These parameters can be used by followup
activities in the business process.
The transfer of data between activities is known as data flow. By providing
graphical constructs to represent data flow between activities, the data
perspective can be visualized and used to validate and optimize business processes.


No comments:

Post a Comment