ERCIM News No.35 - October 1998

An Object-Oriented Database Model for Business Entities and Processes

by Michele Missikoff and Roberto Pizzicannella

An enterprise is a heterogeneous domain where complex entities take part in business processes of different nature and complexity. Traditionally, entities are stored in a database and processes are implemented in the application software. In the ProForm project (see ERCIM News No. 32) we store and manage both entities and processes as structured objects, with an internal state. In particular, processes are seen as static entities when we specify and manage them; conversely, they are seen as dynamic entities when their execution is activated. To treat a ‘passive’ object as an executable component of the application system we envisioned a specific operational semantics (instantiation semantics) which was used when building the ProForm engine.

A number of complex object types have been conceived at IASI-CNR to represent a Business Environment in both its static (actors and entities) and dynamic (Business Processes: BP) components, and store them in an Object-Oriented database.

For the static component we use the standard Object-Oriented (OO) approach, essentially based on the TQL++ model.

The standard OO constructs used in ProForm concern:

To better represent business environments, to these standard construct we have added two modeling constructs:

Constraints allows the modeling of notions such as: business rules and best practises. Business States allows the designer to specify, for a given Business Entity, those states that determine specific behavioural patterns of that entity within the enterprise. Therefore, Business States represents a sort of conceptual bridge between static and dynamic modeling. We will not give further details on the static constructs as they are defined according to the Object-Oriented paradigm, which is assumed to be known.

For the dynamic component, we started by considering typical workflows in business domains, carefully analysing the structuring and modeling techniques found in the literature. Here we present a description of the proposed Business Process database model, which is represented as a set of predefined templates (essentially, a BP metamodel). These templates, adopted to model the BPs of an enterprise, are used to build the schema of an Object-Oriented database, referred to as Business Process Base (BPB). In our approach, the specification of a BP is obtained by recursively decomposing it into its components. The BP is organised as a partially ordered set of Use Cases. A Use Case (UC), a modeling notion originally proposed by Jacobson, is a business operation activated by the user. We interpret it as a user transaction. A UC is then decomposed into actions that are recursively decomposed into subactions. The final level of this hierarchical decomposition is represented by the elementary steps: basic operations that can be directly executed. In our approach, the steps are specified using SQL, with a few additions in order to adjust the richer BP metamodel to the underlying database model.

As stated, a BP is represented as a static entity, following the OO approach (by applying a mechanism often referred to as reification). The BP metamodel is thus composed by the following object types: Business Process Object (BPO), Use Case Object (UCO), and Action Object (ACO). Each type is structured in two sections: a preamble, which reports descriptive information, and a body, which contains the functional decomposition into sub-objects. In particular, a BPO is composed of UCOs, and a UCO is composed of ACOs. An Action Object is recursively decomposed into sub-actions or into executable steps. The latter are not objects, they appear as attributes of an ACO. The figure shows the relationships between these object types.

Object Types

Business Process Object - This is the most general description of a BP; its structure is organised as follows:

Use Case Object - This structure represents a meaningful unit of interaction between user and system. From a database perspective, it can be seen as a transaction:

Action Object - This is the performing element that can be specified at different levels of refinement. The first level allows a task decomposition approach to be adopted, the final level (leaves) is represented by directly executable steps.

The BPs defined according to the object types presented above form the schema of the Business Process database (BPB). A BP schema can be executed, since it is associated with an operational semantics (referred to as instantiation semantics). The result of such an execution is the creation of a BPO instance in the BPB, besides the obvious side effects that take place in the entity database. The ProForm system has an engine that interprets a BPO type according to the instantiation semantics.

Please contact:

Michele Missikoff
or Roberto Pizzicannella - IASI-CNR
Tel: +39 06 77161
E-mail: {missikoff, pizzican}

return to the contents page