Active Object-Oriented Database Design

Project duration: June 1995 - May 1998
Funded by: FWF - Österreichischer Wissenschaftsfonds

Short description: The design of active object-oriented databases includes modeling the structure of objects, their passive behavior in the form of operations that can be performed on them, and their active behavior in the form of business rules. Business rules are statements about business policies and can be formulated according to the event-condition-action structure of rules provided by active database systems, which allow to react to predefined situations by performing an operation if a certain condition is satisfied when the event occurs.
An approach that has been followed successfully in conventional database design is to perform database design in two phases: In the first phase, the conceptual design, a high-level graphical representation of the database schema is developed. In the second phase, the logical design, the developed schema is mapped to the data model of the system used for the implementation. We adopt this approach for the design of active object-oriented databases.
We introduce Active Object/Behavior Diagrams for the conceptual design of active object-oriented databases. Active Object/Behavior Diagrams seamlessly extend Object/Behavior Diagrams, an existing high-level graphical language for modeling the structure and the passive behavior of objects, with concepts for modeling business rules. Modeling business rules at the conceptual level requires different concepts than currently provided by active object-oriented database systems and by recent approaches to active object-oriented database design. Active Object/Behavior Diagrams introduce a graphical rule and event language that meets the identified requirements.
During logical design, a schema developed with Active Object/Behavior Diagrams is mapped to a logical schema of an existing active object-oriented database system. We present such a mapping for TriGS, a prototype of an active object-oriented database system built on top of the commercial object-oriented database system GemStone (GemStone Systems, Inc.). The mapping decomposes the high-level constructs of Active Object/Behavior Diagrams into lower-level constructs of TriGS. The presented mapping covers all three dimensions of a schema specified with Active Object/Behavior Diagrams: object structure, passive object behavior, and active object behavior.

Project team: Michael Schrefl (DKE)
Peter Lang (DKE)
Werner Obermair (DKE)

Motivation and Project Goal

Object-oriented database systems and active database systems aim at representing real-world semantics, which is otherwise hidden in application programs, in the database schema. Object-oriented database systems model the passive behavior of objects next to their structure. Active database systems provide the ability to monitor the database and its environment and to react to predefined situations without explicit user action or application requests (cf. [WC96]). Situations and actions are defined in the database schema.

Active object-oriented database systems combine the capabilities of object-oriented database systems and active database systems. They represent objects of the "universe of discourse" by their structure, their passive behavior, and their active behavior: The passive behavior is specified according to the object-oriented paradigm by a set of methods associated with object classes. The active behavior is usually specified by a set of event-condition-action rules (ECA rules) associated with classes or individual objects. Objects act autonomously upon the occurrence of an event by performing the specified action if the condition is satisfied.

In addition to modeling the structure and passive behavior of objects, the design of active object-oriented databases includes modeling the active behavior of objects. Possible approaches for the design of active object-oriented databases are:

Use the schema definition language of a favorite active object-oriented database management system.
Develop a high-level graphical representation of the database schema during conceptual design. Have this schema mapped to the object model of the system used for the implementation during logical design.

The first approach faces two major inherent design difficulties because schema definition languages of active object-oriented database management systems provide only lower-level concepts particularly suitable for logical design: (a) The potential application area of rules is large, it ranges from enforcing low-level integrity constraints to expressing high-level business policies. It is generally known from AI systems that large sets of rules are hard to design, hard to understand, and hard to maintain. (b) In many cases, rules and methods are alternative ways to express the same effect. E.g., in the case of method events, the action to the event may be specified immediately in the body of the method or in the action part of a rule triggered by the method event. If clear design guidelines are missing, large systems will be hard to maintain as different designers may model similar cases differently.

The second approach has been followed successfully in conventional database design. If there are clear guidelines when to use rules and when not to use rules at the conceputal level, different designers will model similar cases similarly, and the set of rules will remain small at the conceptual level.

Facing the difficulties of the first approach and the promises of the second approach, we adopted the second one in our project. Therefore, the goal of the project has been twofold: First, to develop a high-level graphical notation and a schema editor for the conceptual design of active object-oriented databases. Second, to map the high-level graphical notation into the schema of an active object-oriented database system and to implement a corresponding class and rule generator.

The Pivot Point: Business Rules

During the initial stage of the project, we have identified business processes and especially the business rules controlling business processes as the focus of our work. Different types of business rules are considered in the diverse literature: consistency rules defining static and dynamic integrity constraints and reactions to constraint violations, rules on business procedures defining in which order business activities may be performed, and rules on business policies defining which transactions have to be performed at specific calendar times or which transactions have to be initiated upon the occurrence of specific database states.

We have studied the role of ECA rules in conceptual database design in [KS96]. The study revealed that during conceptual design only rules on business policies should be formulated according to the ECA rule paradigm. The other types of business rules should be better represented by other high-level modeling concepts. Static integrity constraints are better captured directly by semantic data model concepts or are better expressed by a specific constraint specification language. Dynamic integrity constraints are better expressed by preconditions and postconditions of methods. Work step ordering is better represented by remembering processing states with objects and by identifying prestates and poststates of methods. In our project, we restricted the usage of the term "business rule" exclusively to "rules on business policies", i.e., on rules that are actually formulated in an ECA-like manner during conceptual design.

Case studies have shown that business rules (in our narrower sense) are formulated from the perspective of an external user. In both, the detection of situations and the execution of rules, this external user's perspective requires a different set of concepts than currently provided by active object-oriented database systems or by recent approaches to active object-oriented database design.

The requirements, which we have elaborated in [LOS97], are:

Update unit: Database changes should be observed only at the level of transactions that are not further decomposable. In the realm of ACID-transactions, all actions performed and all events raised within a transaction occur instantaneously for the external observer.
Future calendar events and intervals: Business rules should be able to refer to calendar time, including future calendar events as well as future calendar intervals.
Events and intervals as first-class objects: Events and intervals should be represented in the data model of a system as first-class objects. This means that events and intervals should be described by types and collected in sets like conventional database objects.
Abstracting from granularity of time: The time model lying behind the conceptual model should allow to abstract from the granularity of the time axis defined by an internal system clock.
Declarative event language: Similarly as QBE and SQL are better accepted by end users than Relational Algebra, end users are assumed to prefer a declarative event language over an operational one.
Reliable and controllable rule execution: Modelers and system users expect business rules to be executed reliably, i.e., transactions performing rule executions should be restarted automatically if they are aborted due to serialization failures, and controllably, i.e., specific types of exceptional situations occurring during rule execution should be reported by events, which can again be handled by business rules.
Asynchronous and immediate rule execution: Two rule categories are needed to formulate business policies: (1) rules that are considered and executed asynchronously to user transactions and (2) rules that are considered and executed immediately upon temporal events. This feature does not necessarily require the capabilities of real-time database systems, but temporally faithful rule execution is sufficient for many business applications. Informally, temporal faithfulness means that transactions requesting to commit after a temporal event triggering some business rule are serialized after the transaction performing the rule action and vice versa. The latter rule category is not supported by current active object-oriented database systems.

Conceptual Design

Based on these requirements, we have introduced Active Object/Behavior Diagrams, a high-level graphical language for the conceptual design of active object-oriented databases. Active Object/Behavior Diagrams extend Object/Behavior Diagrams with Situation/Activation Diagrams.

Object/Behavior Diagrams. Object/Behavior Diagrams [KS91] are a graphical object-oriented design notation for modeling the structure and the passive behavior of objects. During the project, we have extended the original definition of Object/Behavior Diagrams by introducing object-class diagrams and query diagrams (cf. [Lan97,Obe98]). An object-class diagram depicts local referential integrity constraints that apply to the instances of the object type with which the object-class diagram is associated. A query diagram allows to specify graphically the derivation expression of a derived property in an OQL-like manner ([CB97]). Within the project, modeling cooperative object behavior has been also studied in [SKL98].

Situation/Activation Diagrams. Situation/Activation Diagrams are integrated seamlessly into Object/Behavior Diagrams for modeling the active behavior of objects. They consist of situation diagrams, which we have introduced in [LOS96], and of activation diagrams, which we have introduced in [LOS97]. A situation diagram specifies declaratively when a situation occurs. Like the structure of a query diagram, also the structure of a situation diagram is OQL-like. Situation diagrams visualize the temporal order of situations such that temporal conditions, which are typically used in the definition of situations, are easy to specify and easy to recognize. Situation diagrams incorporate a calendar system that allows to refer also to future calendar situations. Situations are viewed from the external user's perspective. The underlying time model abstracts from the granularity of the time axis defined by the internal system clock. Similar to objects, which are instances of an object type and are collected in object classes, situation occurrences are instances of a situation type and are collected in situation classes. An activation diagram specifies graphically which activity has to be performed upon some triggering event provided that an associated condition is satisfied. Rules specified by means of activation diagrams are executed reliably and controllably. Two rule categories are provided: (1) start-rules, which are executed asynchronously to the triggering event, and (2) do-rules, which are executed temporally faithfully at the point in time when they are triggered by temporal events.

Specialization. To cope with the complexity of business applications, concepts for specializing the structure and the passive behavior of objects have been presented in the literature. Specializing business rules has received only little attention so far. In preparation of the project and accompanying the project work, we have discussed the consistent specialization of object behavior in [SS95,SS97] and have presented a case study in [KS95]. Based on this work, we have introduced concepts for specializing business rules in [Lan97]. We borrowed concepts from deontic logic and extended Active Object/Behavior Diagrams by two kinds of preconditions for activities, necessary conditions and sufficient conditions. In application terms, the negated necessary precondition of an activity models a prohibition, and the sufficient precondition of an activity models a permission. The basic rule for specializing inherited conditions at subtypes is that sufficient conditions may become only weaker at subtypes, whereas necessary conditions may become only stronger at subtypes. By not requiring that prohibitions and permissions are complementary at supertypes, we can follow contra-variance as well as covariance in specialization (Contra-variance and covariance have been seen as conflicting requirements so far). Conflicts do not appear in our setting when permissions and prohibitions are added at subtypes that refer to conditions neither permitted nor prohibited at supertypes. The overall goal in specializing business rules is to guarantee decision consistency. Business rules are assumed to be sufficient conditions as they say when something is to be done. Therefore, they may become only weaker at subtypes, which means that what is obligatory for an object viewed as instance of a supertype has to be obligatory for the object viewed as instance of a subtype.

Design Guidelines. Even if all consistency rules are obeyed, different designers may produce different consistent database schemata. In addition to consistency rules, guidelines should help the designer to achieve a high-quality database schema. We present guidelines for using Active Object/Behavior Diagrams in [Lan97]. Guidelines help to avoid a large set of rules by promoting the specification of rules locally to object types. Further guidelines help to decide whether to use "small rules" or "big rules." Finally, guidelines assist the designer in specializing the active behavior, for example, by advising to factor out the active behavior common to several object types as high as possible in the inheritance hierarchy.

Logical Design

Since Situation/Activation Diagrams support different concepts than currently provided by existing active object-oriented database systems, the second project topic---the mapping of Situation/Activation Diagrams to rules of an active object-oriented database system---had to be reconsidered. A straight mapping as forseen in the project plan could not be presented.

Currently, there is no accepted standard in the field of active object-oriented database systems. So, we used an existing system to study the mapping of Active Object/Behavior Diagrams. The selected system is TriGS [KRSR98], an active extension to the commercial object-oriented database system GemStone (GemStone Systems, Inc.). We have selected TriGS since GemStone as an interpreting system provides a flexible framework for a prototypical implementation. Since the knowledge model and the execution model of TriGS are comparable with those of other active object-oriented database systems, we expect that the lessons learned from mapping to TriGS can be transferred to other systems.

The concepts for mapping a conceptual database schema modeled with Active Object/Behavior Diagrams to a logical schema of TriGS are presented in [Obe98]. Business rules as they are modeled with Situation/Activation Diagrams and TriGS rules differ in both, the way events are detected and the way rules are executed:

Event detection: Logical events triggering business rules and complex TriGS events are evaluated on different database states. While complex TriGS events are detected incrementally, the view character of situation diagrams describing logical events requires that situation diagrams always reflect the current database state. In [Obe98], we show how situation diagrams can be mapped to OQL queries. To avoid that all events on which business rules are based have to be evaluated at every point in time, potential occurrences of logical events are detected incrementally and registered for further processing. Detection and registration is done by means of TriGS rules.
Rule execution: The semantics of business rules requires that a business rule cannot be executed isolated from other business rules and conventional user transactions. Therefore, a TriGS database for which business rules are defined contains a central coordinator which controls the execution of business rules by employing the services of so-called rule handlers. A rule handler is a software agent designed as an active TriGS object.

Tool Support

We have developed a graphical editor for Active Object/Behavior Diagrams [KT97], which has been presented at the 14th IEEE International Conference on Data Engineering [LOKT98]. The editor performs syntactic consistency checks already during the interactive design process. Moreover, by building the logical model in parallel to the diagrams, the editor guarantees that local semantic consistency checks can be performed incrementally, too. The editor clearly separates between schema data and pure visualization data describing the location of diagram elements. Both, schema data and visualization data can be stored in GemStone.

Selected References

[KS95]: P. Küng and M. Schrefl,
Spezialisierung von Geschäftsprozessen am Beispiel der Bearbeitung von Kreditanträgen,
in HMD: Theorie und Praxis der Wirtschaftsinformatik, 32(185):78-94,
September 1995.
[KS96]: G. Kappel and M. Schrefl,
Modeling Object Behavior: To use rules or methods or both,
in Proc. of the 7th Intl. Conf. on Database and Expert Systems Applications (DEXA'96), LNCS 1134,
Springer, 1996.
[KT97]: W. Kraus and T. Thalhammer,
Design and Implementation of a Graphical Editor for Active Object/Behavior Diagrams,
Master's thesis, Universität Linz,
September 1997.
[Lan97]: P. Lang,
Conceptual Active Object-Oriented Database Design,
Dissertation, Universität Linz,
September 1997.
[LOKT98]: P. Lang, W. Obermair, W. Kraus, and T. Thalhammer,
A Graphical Editor for the Conceptual Design of Business Rules,
in Proc. of the 14th Intl. Conf. on Data Engineering, Orlando, Florida,
Computer Society Press, 1998.
[LOS96]: P. Lang, W. Obermair, and M. Schrefl,
Situation Diagrams,
in Proc. of the 7th Intl. Conf. on Database and Expert Systems Applications, LNCS 1134, pages 400-421,
Springer, September 1996.
[LOS97]: P. Lang, W. Obermair, and M. Schrefl,
Modeling Business Rules with Situation/Activation Diagrams,
in Proc. of the 13th Intl. Conf. on Data Engineering (ICDE), pages 455--464,
IEEE Computer Society Press, April 1997.
[Obe98]: W. Obermair,
Active Object-Oriented Databases---From Conceptual Design to Logical Design,
Dissertation, Universität Linz,
February 1998.
[SKL98]: M. Schrefl, G. Kappel, and P. Lang,
Modeling Cooperative Behavior Using Cooperation Contracts,
in Data & Knowledge Engineering, Vol. 26, No. 2, pages 191-224, Elsevier North-Holland,
June 1998.
[SS95]: M. Schrefl and M. Stumptner,
Behavior Consistent Extension of Object Life Cycles,
in Proc. of the 14th Intl. Conf. on the Entity-Relationship Approach,
Springer LNCS, 1995.
[SS97]: M. Schrefl and M. Stumptner,
Behavior Consistent Refinement of Object Life Cycles,
in Proc. of the 16th Intl. Conf. on Conceptual Modeling (ER),
1997.

Selected References

[CB97]: R.G.G. Cattell and D. Barry, editors,
The Object Database Standard: ODMG 2.0,
Morgan Kaufmann, 1997.
[KRSR98]: G. Kappel, S. Rausch-Schott, and W. Retschitzegger,
A Tour on the TriGS Active Database System---Architecture and Implementation,
in Proc. of the ACM Symposium on Applied Computing, Atlanta, Georgia,
1998.
[KS91]: G. Kappel and M. Schrefl,
Object-Behavior Diagrams,
in Proc. of the 7th Intl. Conf. on Data Engineering, Kobe, Japan, pages 530--539,
1991.
[WC96]: J. Widom and S. Ceri, editors,
Active Database Systems---Triggers and Rules For Advanced Database Processing,
Morgan Kaufmann Publishers, 1996.