BOTTOM-UP DESIGN OF ACTIVE OBJECT-ORIENTED DATABASES.(Technology Information)

Top-down design approaches give database designers little guidance with transforming a conceptual model into an active object-oriented database schema. A bottom-up design approach may provide a better perspective.

ACTIVE OBJECT-ORIENTED DATABASES (AOODB) are a commonly accepted solution for smoothly capturing the frequently changing business policies of large enterprises [2]. By factoring out business policies from single applications and incorporating them into an AOODB, they are maintained in an application-independent manner, and may be imposed on all applications. One of the most prominent basic mechanisms of an AOODB system is an Event/Condition/Action rule (ECA rule), which allows for a localized specification of a business policy as opposed to spreading it over several applications. Monitoring events and conditions, ECA rules execute the corresponding action when the event occurs and the condition is true [8]. Extensions of the basic ECA paradigm allow a more flexible definition of rule execution points. For instance, in our research AOODB system TriGS the model is ECEA, which means another event may be awaited before the action is triggered [4, 9]. (TriGS stands for Triggersystem for GemStone, which is an active layer on top of the object-oriented database system GemStone.)

Unfortunately, AOODB designers are overtaxed with the expressive power and flexibility of existing active object-oriented models, especially with the options for mapping business policies onto ECA rules. Rather than provide guidelines on which business policies to put into the AOODB, existing techniques follow a top-down design approach focusing on the graphical representation of rules at the conceptual level by integrating them into existing conceptual design models [12]. Logical AOODB design, including the transformation of a conceptual model into an AOODB schema, has been dealt with infrequently [1]. Learning from similar design problems in OO system development, we propose a bottom-up design approach. We introduce rule patterns in analogy to design patterns [3], describing sample rule patterns for specifying interaction policies in workflow applications. More extensive annotated examples written in TriGS code can be found at www.ifs.uni-linz.ac.at/ifs/research/publications/papers01.html.

USING OUR APPROACH TO AOODB DESIGN necessitates two subtasks: specifying application classes, and identifying business policies, which are generally spread over different classes. Since the first subtask resembles traditional OO design, we use three model elements of the standard OO modeling language UML [11]: the class model for capturing the classes and their relationships, the statechart model for capturing the behavior of each class, and the interaction model for capturing the interactions between objects of different classes. The second subtask is more subtle, as several approaches exist for identifying business policies [7]. Instead of arbitrarily picking one approach, we extract business policies from the three models designed in the first subtask. For example, integrity constraints stated in the class model and interaction constraints stated in the interaction model are typical representatives of business policies, and thus candidates for being specified in terms of ECA rules.

When looking at rules specifying business policies, one may find components applicable to several applications, as well as specific to one application. In order to avoid the application designer having …