Integrating Active Concepts into an Object ... - Semantic Scholar

Accepted for DBPL-3 workshop, Nafplion, Greece, August 27-30, 1991

Integrating Active Concepts into an Object-Oriented Database System Stella Gatziu, Andreas Geppert, Klaus R. Dittrich Forschungsbereich Datenbanktechnologie Institut für Informatik, Universität Zürich, CH-8057 Zürich, Switzerland Email: {gatziu, geppert, dittrich}@ifi.unizh.ch

Abstract This paper describes the active, object-oriented database system SAMOS being developed as a research prototype. Its main approach is the integration of rules in the sense of active database systems into a general object-oriented data model. Our effort is also focussed on integrating the rule system with transaction processing in a meaningful way.

1 Introduction Object-oriented database systems (ooDBS) aim at representing more real-world semantics in the database than conventional ones; to this end, they provide mechanisms to model complex structures and to express userdefined (procedural) behavior. Active database systems are able to recognize specific situations (in the database and beyond) and to react to them without direct explicit user or application requests. The association between situations and (re)actions is specified by means of production rules. Thus, active databases allow to represent (a different kind of) real-world semantics, too, that are otherwise hidden in applications. In consequence, the integration of both, object-oriented1 and active features into one system promises a higher degree of expressive power than today’s database products can offer. The inclusion of powerful active mechanisms into ooDBS provides services for e.g. reactions to situations in an application (external notification), reactions at specific points in time, management of (consistency) constraints, access control, or automatic propagation of updates (derived data). Most of these features are not supported by object-oriented systems now. Furthermore, using ooDBS characteristics increases the flexibility of an active mechanism in that e.g. user-defined types, methods, or inheritance can be exploited. Additionally, rules are treated as “first class objects” [Dayal 88b]: every rule can be represented as an instance of a system-defined class “rule” providing all necessary functionality. For such a class, all object-oriented characteristics are obviously available like for any other class. While active mechanisms have been investigated - to a limited extent - for a few (commercial) relational database systems ([Stonebraker 89], [SYBASE 88]), the extension of object-oriented database systems with active characteristics is still in an exploratory phase. For example, the HiPAC project [Dayal 88a], though based on an object-oriented system, does not make extensive use of specific features like classes or inheritance; [Medeiros 91] makes a first attempt to extend the object-oriented database system O2 [Deux 90] with production rules and exploits e.g. inheritance. Nevertheless, a number of further questions concerning the integration of active mechanisms and ooDBS still remains open.

1. Our conception of an object-oriented database system is like in [Atkinson 89]. Thus the notion of “active objects” is not used if just the usual paradigm of reacting to messages is followed.

1

The combination of active and object-oriented characteristics within one, coherent system is the overall goal of SAMOS2, an active, object-oriented database system currently being in the first stage of development. Two of the principal problems addressed by SAMOS are dealt with in this paper: rule specification and rule processing. Rule specification is concerned with the nature of situations, actions and their relationship to the data model. The processing of rules has to be carried out in the context of the general transaction model supported by the database system. Thus, the execution of (possibly multiple) rules needs synchronization with other concurrent transactions. The main contributions of the research described in this paper are as follows: •

Rules are classified according to their relationship to classes: they may be class-internal or class-external. In contrast to class-external rules, the former ones may access the state of objects directly; they are encapsulated within objects and thus not visible to users of those objects.

•

Rules are subject to inheritance.

•

A powerful mechanism for the specification of situations is provided.

•

Rule execution is integrated into a transaction model based on nested transactions.

•

Rules are synchronized with each other and with concurrently executing methods using semantic concurrency control.

SAMOS is not intended to propose yet another object-oriented data model (ooDM), rather it aims at exploiting how active mechanisms can be integrated with object-oriented database systems in a reasonable way. Although current object-oriented database systems differ in their data models and further functionalities (and the implementation of SAMOS will use one specific system as its basis), the concepts of SAMOS apply to a variety of ooDMs. Therefore, as far as the data model is concerned, SAMOS assumes only characteristic properties provided by nearly all ooDMs like inheritance, user-definable types and operations, encapsulation, a.s.o. The remainder of this paper is organized as follows: In section 2, we first introduce more precisely the assumptions we make about the data model. Then, we describe the underlying transaction model. In section 3, we present the knowledge model of SAMOS, i.e. the extension of the data model with specification facilities for active rules. Section 4 deals with the execution model, i.e. the execution of rules within the framework of the transaction management concept. While section 5 contains some implementations issues, section 6 gives a comparison to related work. Finally a comprehensive example and a syntax description are given in the appendix.

2 Object-Oriented Data Model and Transaction Model This section describes the salient features of both, the assumptions on the object-oriented data model as well as the supported transaction model, to the extent that they are needed for further discussion in this paper. As far as the data model is concerned, we assume a subset of the properties required by [Atkinson 89].

2.1 Object-Oriented Model Objects have a unique identifier, a value (or state), and a set of methods. We assume that users refer to objects by using either their identifier or a user-defined name. Values of objects can only be accessed or manipulated by the use of methods, i.e. objects are encapsulated. Methods of an object are executed in response to messages sent to that object. Inside methods (i.e. by means of the program code implementing it), the value of an object can be accessed or manipulated directly3. Values with the same structure are collected into types. The concrete collection of type constructors is not our concern here; presumably, it will at least include set and tuple

2. Swiss Active Mechanism-Based Object-Oriented Database System 3. In the sequel, those operations are termed value operations.

2

constructors. Classes are collections of objects with the same set of methods and with values of the same type. Thus, the definition of a class consists of a name, the related type, and a set of methods. Classes may inherit from other classes. Note that a variety of inheritance semantics has been proposed. For our purpose, we assume that subclasses inherit the type and methods of their superclasses. A subclass may define additional or overwrite inherited methods. Furthermore, a class may extend an inherited type (if the type of the superclass is a tuple type) by adding further attributes. Various object-oriented data models differ in their treatment of persistent extensions: some of them (automatically) assign an extension to each class, while in others it is up to the user to define (multiple) extensions of classes. For SAMOS, we assume that the user will define set-valued objects if he/she is interested in the persistent collection of existing instances of a specific class. Note that the manipulation of those extensions (e.g. adding new members) requires the invocation of specific methods. For example, if a new instance of a class is created, it needs to be explicitly inserted into the appropriate extension object. Further features of the object-oriented paradigm [Atkinson 89] like complex objects are not dealt with in this paper, nor is the relaxation of the complete encapsulation property for objects; these are topics for further extensions of SAMOS. The various aspects of class definitions are captured by the following syntax (throughout the paper, we use the following conventions: “|” denotes alternatives, an expression enclosed in square brackets is optional, an expression labelled with an asterisk can be repeated zero or more times, and expressions labelled with a “+” have to be repeated one or more times. Terminal symbols are enclosed in quotation marks: class_def ::= “DEFINE CLASS” class_name “TYPE” type_definition (*set, list, a.s.o.*) [“INHERITS” class_name+ ] “METHODS” (method_name “(“ argument+ “)” return_type )+ “END” class_name For each method, we obviously assume that an implementation has been made available in the system.

2.2 Transaction Model From the point of view of the DBMS transaction management, a (user-defined) transaction is a sequence of messages, i.e. method calls4. Instead of locking objects in read/write mode until the user transaction commits, it is desirable to release these locks as soon as possible. Thus, the system handles user-defined methods in the framework of (generalized) multi-level transactions [Beeri 88] with (atomic) method executions as subtransactions. Consequently, as a first requirement, a compensating method has to be specified for each method. Since transactions (or methods) may access an object modified by another transaction before the latter commits, state-based recovery is not sufficient and compensating methods have to be specified in order to avoid cascading aborts. Furthermore, we assume (conflict) serializability [Bernstein 87] as correctness criterion for the interleaved execution of transactions. However, instead of determining conflicts in terms of read and write operations, we want to take the semantics of classes and their methods into account [Schwarz 84]. Thus, conflicts are specified based on the set of methods of each class; two methods conflict if they do not commute. Two methods commute (when performed on the same object) if the new state of the object is independent of the execution order of the methods, and if the return value of each method is not influenced by the execution of the other [Hadzilacos 88]. Conflicts are defined in terms of conflict relations (which in turn are subsets of all pairs of methods for a specific

4. For the sake of simplicity, we assume that users cannot define nested transactions explicitly; however, nested transactions result from messages sent to objects.

3

class). The definition of conflict relations is the duty of the class implementor; which it causes more work for him/her, it also results in a higher degree of parallelism. In the following, we first describe how serializability is ensured and implemented by a locking protocol. Later in this paper, we will show how rules can be integrated into this approach.

Serializability The approach described in this section is a slight modification of [Hadzilacos 88]. A method execution or transaction5 is a set of steps (value operations or messages) together with an ordering of at least the conflicting steps. A histule6 h is a quadruple (E, ‹, B, S), where E is a set of method executions, ‹ is a partial order on the method executions in E, B maps messages of steps of h to method executions in E, and S is a set of initial states. Serializability is defined in terms of serialization graphs: the serialization graph of a histule h is a directed graph with its nodes corresponding to method executions or value operations. An edge between nodes e and e’ exists iff •

e and e’ represent method executions and some step of a descendant f of e precedes and conflicts with some step of a descendant f’ of e’, or

•

e and e’ have a least common ancestor f, and within f, executes some ancestors t and t’ of e and e’, respectively, such that t is to be executed before t’.

Note that in the first disjunct value operations may not occur; dependencies between value operations are detected on the level of methods executing those value operations, two methods performing incompatible value operations on the same object have to be specified as conflicting. Finally, a theorem states that a histule h is serializable iff its serialization graph is acyclic. Serializability, as usual, is defined as equivalence of a histule to a serial histule, where a serial histule executes a set of (top-level) methods consecutively.

Locking Protocol For each method there exists a specific lock mode. Additionally, the usual read and write locks exist for value operations. Thus, before a value operation can be performed, an appropriate lock has to be granted. Read and write locks are released immediately after the value operation. The compatibility function of lock modes is derived from the conflict relation of each class. If a method or transaction wishes to execute some operation (a value operation or some other method), it has to obtain the respective lock. Especially, if a method executes a value operation, a read or write lock has to be received before. Read and write locks are released as soon as the value operation is performed, while method locks are released at the end of a method execution and inherited to the parent (if there is one); principle of closed nested transactions. In summary, we assume semantic concurrency control on the level of methods, thus the system has to be told about conflict relations over the set of methods of a class and about undo methods (compensation). Especially, conflict relations are a further part of class definitions having the following syntax: “CONFLICTS” ( “(“ method_name “,” method_name “)” )+

3 Active Rules in an Object-Oriented Environment A (production) rule in the sense of active database systems is a (situation, action)-pair. A situation is generally specified by means of an event and a condition, where an event indicates an occurrence in the database system or its environment and a condition relates to the current database state and can be formulated as a predicate over it. A condition has to be evaluated when the corresponding event is signalled; if it holds, the associated action has to be executed. The overall structure of rule definitions is as follows: 5. The difference between transactions and method executions can be neglected when transactions are viewed as special method executions on a “environment” object. 6. History + Schedule

4

rule_def ::= “DEFINE RULE” rule_name “ON” event “IF” condition “DO” action Note that the syntax of rule definitions has been chosen for the sake of readability and convenience; internally, this syntax transforms to a define method for the class rule. In the next subsections, various kinds of events are described, followed by a closer look at entire rules. Examples for both, events as well as rules may be found in the appendix.

3.1 Events Events can be roughly subdivided into two categories: primitive events which correspond to elementary occurrences, and composite events which are composed out of other composite or primitive events. Furthermore, event types and event instances are distinguished: an event type is what we specify within a rule definition, while an event instance relates to the actual occurrence of an event (of a specific type). In the sequel, we will simply talk about events whenever the distinction is clear from the context. 3.1.1 Primitive Events In most active systems, an event is conceived as the point in time when a data manipulation operation like an update starts or terminates. In an object-oriented environment, however, users manipulate objects by sending messages to them. Thus, each message gives rise for two events: the point in time when the message is “arriving” at the object and the point in time when the object has finished the execution of the appropriate method (message events). Some rules with message event types may require information beyond the simple occurrence of the event. For instance, a condition evaluation may (semantically) depend on some parameters supplied to the method (see the appendix for a concrete example). Therefore, rules with message event types may refer to the method parameters inside the condition or action which are therefore made formal parameters of the appropriate event type. When the event instance occurs, the actual parameters supplied to the method act as actual parameters of the event (according to its type) and may thus be passed to the condition (and the action, if necessary). Furthermore, an event may be (semantically) related to e.g. the modification of (parts of) the value of an object, which can take place in various methods. Thus, using message events only, it would be necessary to define one rule for each method where this modification occurs. Additionally, every time a new update method is implemented, a new rule with a corresponding message event would have to be defined as well. Instead, we permit the definition of value operations as events (value events). Obviously, due to encapsulation, appropriate rules have to be regarded as part of the class implementation and are definable/visible for the class implementor only. Our approach also supports time events. These can be absolute points in time (e. g., 22:00:00, February 28, 1991), periodically reappearing events (e.g. every hour) or relative to occurring events (e.g. 2 min after “login”, 1 min after event E1). Note that in the case of absolute time events, there is only one instance per event type. Transaction events are defined by the start or the termination of (user-defined) transactions. We assume that transaction programs, respectively, can be named. Similar to the case of events, we distinguish transaction types and transaction instances. A named transaction program is actually the specification of a transaction type, while all the executions of such a transaction program are referred to as instances of that transaction type. Of course, in the case of named transaction events, we want to define events for transaction types and not for single executions only. If for a transaction event no transaction name is given, an event is raised as soon as any arbitrary transaction execution starts (or ends, depending on the transaction event type). Up to now, we have introduced several kinds of events which are conveying specific semantics known by SAMOS such that their occurrence can be detected by the system itself. However, users and applications may

5

need other events according to their specific semantics as well (abstract events). They are defined and named by users and can be used in rules like any other event. Abstract events are not detected by SAMOS, but users/ applications have to notify the system about their occurrence by issuing an explicit raise event operation. 3.1.2 Composite Events The kinds of primitive events described above correspond to elementary occurrences and thus are not adequate for handling events that occur when some combination of other events happened. Thus, we support composite events built from others by means of event constructors. The disjunction of events (denoted “E1 | E2”) occurs when either E1 or E2 occurs; it is essentially an abbreviation for two rules with identical conditions and actions, respectively. The second constructor is the conjunction of events (denoted “E1 , E2”); the resulting event is signalled when E1 and E2 occur, regardless of order. E1 and E2 may be required to occur either in the same transaction (be it named or not) or regardless of transactions during a specified time interval (e.g. 1 min). In the latter case the interval starts as soon as the first event (E1 or E2) occurs; then the second event has to occur within the interval (1 min) in order to raise the composite event. Time intervals can be specified in terms of months, days, hours, and minutes. As an example suppose the following abstract events E1= “Error diagnosis of machine x1”, E2 = “Error diagnosis of machine x2”, when both events occur during 1 min a further machine must be added. Thus the conjunctive event is: E = (E1 , E2 : 1 min). The third constructor refers to the sequence of events (denoted “E1 ; E2”); the resulting composite event occurs when E1 and afterwards E2 occurs. Like in a conjunction, E1 and E2 must occur either in the same transaction or within a predefined time interval. In addition for the later case, if the sequence consists of more than two components, a time between the occurrence of Ei and Ei+1 can be defined. This may be e.g. in the form of [min, max], where min and max indicate the minimum and maximum time required between the occurrence of two successive events, respectively. As an example, suppose an abstract event E1 = “Maximal amount of daily withdrawals reached” and a message event E2 = “Withdraw money”, where one day after reaching the limit, no withdrawal money is allowed. Thus, the sequence event is E3 = (E1 ; E2: 1 day). Finally, we support negative events (denoted “¬ E”) which occur if E did not occur in a specified (named) transaction or in a predefined time interval (e.g. every workday from 16:00 until 18:00). Negative events can be component events of any composite event. However, in a sequence the first event must be positive, since otherwise a new semantics of sequence would result. A sequence of events corresponds to a sequence of points in time at which the specific events occurred - a negative event, however, corresponds to a time interval. Thus, with a negative event at the beginning of a sequence, one would not be able to specify a point in time where the rest of the sequence is expected to occur. In the middle of a sequence, however, there is no problem with a negative event: in this case, the event must not occur between the occurrence of its predecessor and its successor. Note that a conjunction may also consist of negative events only, e.g (¬ E1, ¬ E2) which is equivalent to ¬ (E1 | E2). Here are two simple example of the use negative events in a sequence: When during three days after the delivery of an article it is not giving back, a bill has to be send. Thus, E1 = “Delivery of an article”, E2 = Obtained an article back” and the sequence is E3 = (E1; NOT E2: 3 days). Another rule is: At the latest one week of an article has be ordered, it has to be delivered. Thus E1 = “Order of an article” E2 “Delivery of an article” and E3 = (E1 ; NOT E2: 7 days). Raising E3 might e.g. trigger express delivery. Often, events will be used in multiple rules. As a matter of reusability and convenience, one does not want to describe the same event (especially a composite one) in each rule. Therefore, events may be named and defined separately. Corresponding rules can then refer to the event via its name. Thus, event and rule definitions have the following overall syntax (only the major parts are specified): event_def ::= “DEFINE EVENT” event_name event_clause

6

rule_def ::= “DEFINE RULE” rule_name “ON” event_name | event_clause “IF” condition “DO” action event_clause ::= event | comp_event comp_event ::= comp_event (“|” comp_event)+ | comp_event (“,” comp_event)+ “:” time_interval | comp_event (“;” [time] comp_event)+ “:” time_interval | “¬” comp_event “:” time_interval | event event ::= message_event | value_event | time_event | transaction_event | abstract_ event time_interval ::= timespace | transaction (* exact specification of a point in time *) time ::= [“min”] timespace [“max” timespace] timespace ::= month day hour minute A condition is a formula composed of predicates over the database state. Predicates are typically comparisons, the arguments of such predicates can include messages (more precisely, their return parameters) as well as query language expressions (if the ooDBS provides for a query language at all). An action can be any executable program; it may send messages or even abort the execution of the (user-defined) transaction in which the corresponding event occurred. However, sometimes it may be desired not to abort the entire transaction, but rather the method in which the event occurred (e.g. a value or method event). Therefore, in addition to the abort_transaction operation, an abort_method operation is supported (note that methods are regarded as subtransactions anyway).

3.2 Rules and Classes Rules may be classified according to their relationship to the classes (or objects) they are defined for. Concretely, certain rules may be permitted (class-internal rules) or prevented (class-external rules) to operate on or access object values. 3.2.1 Class-Internal Rules Their definition is part of the class definition, which then consists of a name, the related type, a set of methods and a set of rules. Class-internal rules are encapsulated within instances and are visible to the class designer only. Therefore, value events are permitted beyond message events for the entire class, time events and abstract events (and combinations thereof). Conditions and actions of class-internal rules are also allowed (but not restricted) to operate directly on values. This property leads to a high level of object autonomy, specific tasks (e.g. some integrity constraint maintenance) which are relevant only to a certain object can be kept completely local to that object. Actions of class-internal rules or methods may want to notify the “outside world” about the occurrence of a specific state of an object (i.e. about a specific situation), although (or even because!) the state of the object is encapsulated and thus cannot be examined conventionally from outside the object. These situations may be turned into an abstract event by the class implementor. This event is made part of the class interface beside the methods and thus “exported” to the outside. Thus, the definition of class-external rules referring to such objectspecific situations is facilitated. Class definitions are captured by the following syntax: class_def ::= “DEFINE CLASS” class_name

7

“TYPE_ type_definition (*set, list, a.s.o.*) [“INHERITS” class_name+ ] “METHODS” (method_name “(“ argument+ “)” return_type )+ “CONFLICTS” ( “(“ method_name “,” method_name “)” )+ [“RULES” rule_def+ ] [“EXPORTS” event_name+ ] “END” class_name 3.2.2 Class-External Rules While class-internal rules can be defined by the class implementor only, class-external rules may be defined by any user or application. In consequence, permissible events are message, transaction, time and abstract events as well as compositions thereof. Obviously, value operations cannot be used for class-external rules; i.e. neither for events, conditions, nor actions. Class-external rules are global in sense that they may refer to arbitrary class (one or more). If necessary, message events used in such rules have to be specified by giving the respective class or object name as prefix, e.g in the form. (class_name | object_identificator) “.” message event In summary, the schema definition for an active, object-oriented database system consists of a set of classes (including type definitions, method definitions, conflicts relations, and class-internal rule definitions) and a set of class-external rules. The permissible uses of the various types of events for class-internal and class-external rules is summarized in Table 1. rule type event type message events value events transactions events time events abstracts events

class-internal

class-external

Table 1: Permissible Combinations of Rule Types and Event Types 3.2.3 Inheritance of Rules Furthermore, rules (class-internal or class-external) specified for one or more classes are subject to inheritance. Thus, they can be propagated across class hierarchies (like in [Medeiros 91]). Condition and action can be inherited by the subclasses and need not be defined for each of them. A subclass may define additional or overwrite inherited rules. Composite events have to be considered more precisely in the context of inheritance, since those events may comprise message events for various classes. Figure 1 shows an example of a class hierarchy; we use the pair

Ma Mb

C1 C11

C2 C12

Figure 1. An Example Class - Hierarchy

8

Mc

(C, M) to denote a message event where C is a class name and M a method name. First, for the disjunction constructor, we must break down the composite event into its parts and then built again the disjunction from the elements and from the appropriate events for all subclasses. Thus, an event (C1, Ma) | (C1, Mb) for the class C1 is transformed to (C1, Ma) | (C1, Mb) | (C11, Ma) | (C11, Mb) | (C12, Ma) | (C12, Mb) and an event (C1, Ma) | (C2, Mc) for the two classes C1 and C2 is transformed to (C1, Ma) | (C11, Ma) | (C12, Ma) | (C2, Mc). For the conjunction or sequence constructor, new composite events for each subclass must be generated. As an example, the propagation of the sequence event (C1, Ma) ; (C1, Mb) across the class hierarchy of C1 additionally generates the following two events: (C11, Ma) ; (C11, Mb) and (C12, Ma) ; (C12, Mb). Otherwise, the event (C1, Ma) ; (C2, Mc) generates the events: (C11, Ma); (C2, Mc) and (C12, Ma) ; (C2, Mc). Note that the sequence between methods and the sequence between classes still remains the same before and after the propagation of a sequence event.

3.3 Manipulation of Rules To stay in the same “world” and exploit its advantages, rules are represented as objects themselves and are instances of a class rule. The instances of that class can be manipulated and accessed by means of methods like define, delete, activate, deactivate, and raise. In contrast to the class-internal rules which are accessible only to the class implementator, these operations for class-external rules can be applied inside an application program. By means of the operations activate and deactivate, rules - more precisely the association between a situation and an action - may be (temporally) switched on and off, respectively. They also can have a time interval as an optional parameter during which the rule is to be active or inactive. These time intervals can be absolute or periodically. As an example, a rule must be activated every end of the month, i.e. activate rule1 (every (28. 31.)) or it must be deactivated every weekend, i.e deactivate rule2 (every (Saturday - Sunday)), or it must be deactivated between August 15, 1991 and August 31, 1991, i.e. deactivate rule3 (15.8.91-31.8.91). When no time interval is given for a (de)activate operation, the rule must be (in)active from immediately (i.e after the execution of the operation) to the next de(activate) operation. At some point in time, users/applications may desire to execute a rule (i.e. check the condition, and if necessary, execute the action) although the related event did not occur. By means of the operation raise rule, rules are fired explicitly by users or applications. Whether the corresponding event actually occurred or not, the rule execution starts in either case.

4 Rule Execution An active database system executes rules in addition to conventional user transactions. Execution of a rule with an event E starts whenever E (the triggering event) occurs and consists of the evaluation of the condition and (if it is satisfied) the execution of the action which are called triggered operations. In detail, we have to consider the following aspects: •

the rule definer may specify when a condition has to be evaluated and/or an action to be executed relative to the triggering event by means of coupling modes,

•

the system has to handle the execution of multiple rules which are triggered by the same event,

•

triggered operations have to be integrated with the DBMS transaction model, which in our case is based on nested transactions and semantic concurrency control.

Usually, the execution of the triggered operations begins immediately after the triggering event and thus within the transaction in which this occurred (triggering transaction). In other cases, e.g. when rules are used for consistency constraints, their execution may be delayed until the end of the triggering transaction (but still takes place within). We call this strategy coupled execution. We also support a decoupled execution model in which triggered operations are executed in a separate transaction which is independent from the triggering one. Thus, on the one hand the triggering transaction can finish more quickly, and on the other hand, the execution of the

9

triggered operations e.g. action execution can commit even if triggering transaction aborts. One example of rules of this type are statistical rules, e.g. rules auditing the number of some updates without respect to commit. In some cases, it can be useful to separate the action execution from the condition evaluation, e.g. if the condition has to be evaluated immediately after the event occurred, while the action (maybe, a time-consuming program) is desired to run in a transaction of its own. Thus, like [Hsu 88], we distinguish coupling modes for conditions and actions, respectively. Both are defined in relation to the triggering event; another alternative would be to relate the action execution to the condition evaluation. In summary, we support three kinds of coupling modes for condition evaluation and action execution, respectively: •

immediately: immediately after the triggering event

•

deferred: after the last operation in the triggering transaction, but before it commits

•

decoupled: in a separate transaction which means independently of the triggering transaction.

With the assumption that an action always has to be executed after the corresponding condition evaluation, the six meaningful combinations of coupling modes for conditions and actions presented in Table 2. While the rows represent the coupling modes for the condition, the columns contain those for the action.

condition immediately deferred decoupled

action

immediately

deferred

decoupled

I

II IV

III V VI

Table 1: Combinations of Coupling Modes for Conditions and Actions

In the case of rules with message, value events, transactions events or abstract events, all cases are allowed. For time events, only case VI is allowed because no triggering transaction exist. The coupling modes of rules with composite events always refer to the last triggering event within a composition. Coupling modes are specified within rule definitions according to the following syntax: coupling_mode ::= “COUPLING_MODE” “( ” coupling “,” coupling “) ” coupling ::= “IMMEDIATE” | “DEFERRED” | “DECOUPLED”

4.1 Transaction Structures One aspect of the execution model deals with the relationships between triggering and triggered transactions. In this paragraph, we sketch how transaction trees and transaction forests [Beeri 89] are built from both kinds of transactions. While transaction trees represent (nested) transactions, transaction forests represent sets of concurrent nested transactions. Principally, condition evaluation and action execution in SAMOS are implemented by own (sub-) transactions (triggered transactions). In cases I, II and III, a subtransaction performing the condition evaluation is started as soon as the respective event occurs. In cases IV and V, this subtransaction is run after the last (user-specified) operation, but before committing the triggering transaction. In case VI, an own top-level transaction is started. Assume now that the condition evaluates to true. Then, the same principles as for condition evaluation hold for action executions. Note that if both, condition and action have the same coupling mode (cases I, IV, VI), they can be combined into one (sub)transaction. In the deferred mode, for each triggering transaction the triggered subtransactions are processed in a first-come-first-served manner [Hsu 88]. The process sketched above may continue recursively: assume, for example, that an action sends a message which results in an event used in another rule. Thus, triggered transactions can act as triggering transactions themselves (nested rule execution).

10

4.2 Concurrency Control So far, we have described the structure of transaction trees and forests for single rules. However, rules also have to be synchronized with each other and with the execution of concurrent methods (i.e. other operations of userspecified transactions). Thus, the question arises how rule execution can be integrated into the general concurrency control scheme. As sketched in section 2, knowledge about commuting methods is applied to define serializability. Executions of class-external rules are regarded as subtransactions as described above; they call methods which in turn are synchronized with other methods and rules. Class-internal rules, on the other hand, can manipulate values of objects directly, and thus behave comparable to methods. Consequently, a class implementor has to provide conflict relations with condition or action parts of (class-internal) rules.

4.3 Execution of Multiple Rules Multiple rules may share the same event. In this case, the question arises whether their execution order is systemdefine, or whether an execution order can be specified by users. The SAMOS approach is as follows: when an event is detected, the concerned rules are grouped according to their coupling modes (cases I to VI in Figure 2). Each rule of group VI is represented by an independent top-level transaction, respectively. In each of the cases I and IV, however, the effect of the rules depends on the execution order: the action of one rule may invalidate the condition of others. Thus, the execution order needs to be specified by the rule definer (within the class containing the respective rules or within the rule definition section of the schema) by means of priorities using the following syntax: “PRIORITY” [(rule_name “‹” rule_name)+] In the three other cases of Figure 2, coupling modes of conditions and actions are different, thus invalidations as described above cannot occur; consequently, priorities are not necessary for the corresponding rules in these cases. The impact of priorities on concurrency control is as follows: usually, serializability (of a schedule) is defined as equivalence to any serial histule. With priorities, however, equivalence to a serial schedule obeying the order specified by the priorities is required.

4.4 Recovery Rules also have to be integrated into the recovery scheme of the supported transaction model. Conditions are restricted to read access only, thus no recovery is necessary for them. Actions, on the other hand, may perform updates and thus recovery has to be supported for them. Actions of class-internal rules are comparable to methods; consequently, the same principles as for methods are applied, i.e. undo actions have to be specified for the actions of class-internal rules. Furthermore, actions of class-external rules are restricted to method calls, for which compensating methods have already been required anyway, thus no further requirements exist for those actions.

5 Implementation Issues In addition to the usual functionalities of (passive) ooDBMS, an active DBS has to perform the following tasks: •

definition and management of rules,

•

efficient event detection,

•

rule execution.

First of all, rules have to be “understood”, thus an existing DDL-compiler has to be extended in order to compile rule definitions. Then, rules are represented as objects of a class rule. Thus, additionally to the database a rulebase has to be managed by a rule manager7. The rule manager is also responsible for management of the rule

11

execution. Providing a powerful mechanism for the specification of events requires components for the administration of event schemas and a variety of events detectors to detect the difference types of events. The transaction manager of the DBMS has to implement the execution model, including support of nested transactions, various couplings modes and support of multiple rules. In summary, the architecture of SAMOS augment the architecture of a (passive) object-oriented DBMS by new components like a rule manager, an event detector and integrates both with the transaction manager. A detailed description of these components is beyond the scope of this paper, but we briefly present how rule firing has to be handled. Obviously, the implementation of an efficient event detector is a crucial task for the efficiency of an active database system. As soon as an event is detected, it is inserted in the so-called event register. Based on the (updated) information in the event register, the rule manager then has to get activated and has to determine the rules to be executed. Thus, in addition to event detection, the search for rules to be fired is another critical task with respect to efficiency. Class-internal rules, for instance, are easy to detect since they are local to the instances of the class (and need not be worried about when instances of other classes are accessed). Furthermore, since value events can occur in class-internal rules only, the search for rules to be fired can be restricted to a small number of rules. Time events, on the other hand, may be detected with the help of operating system functions. A prototype implementation of SAMOS’ general concepts uses the extensible database system EXODUS [Carey 86]. EXODUS provides an architecture framework for building database systems; thus the active object-oriented data model proposed by SAMOS can be implemented with reasonable effort.

6 Related Work Several proposals have been made for augmenting a database system with productions rules in the sense of active databases, primarily for defining integrity constraints (e.g. [Eswaran 76], [Kotz 88]). [Kotz 88] proposes a generalized event/trigger (ETM) concept in which a trigger serves to associate an event with an action. [Stonebraker 89], [Widom 90], [Hanson 89], [Cohen 89] consider production rules in the context of relational database systems; thus, events are operations on relations like append, replace, delete etc. [Widom 90] proposes set-oriented production rules which are triggered by sets of changes and in turn trigger sets of changes. A model to handle the rule execution for single and multiple rules is also proposed, but without support for various coupling modes. The execution order of multiple rules is specified like in SAMOS by means of priorities. Interestingly, after the execution of the first rule and before choosing the next one it has to be checked which rules are still triggered in the new database state (i.e. their condition has to be evaluated on the new database state again). In [Ceri 90], a framework is described for translating constraints into constraint-maintaining production rules. [Hanson 89] describes ARIEL, a DBMS with an integrated production rule system built by use of the EXODUS database tool kit. ARIEL extends in contrast to SAMOS POSTQUEL with rules that also support time-based events. Rule processing of ARIEL is based on a variation of the Rete network (used widely in rule based systems for artificial intelligence programming). [Cohen 89] describes how triggers can be compiled into a “matcher” that efficiently detects when the triggers are matched and by what data. HiPAC [Dayal 88], [Chakravarthy 90] extends the object-oriented data model PROBE with “event-conditionaction” rules. An event can be a function (method) on objects, a clock time or an external notification. Rules are treated as objects, but the integration with further properties of the object-oriented paradigm like classes or inheritance have not been discussed in this work. The execution model of HiPAC [Hsu 88] is based on an extended nested transaction model. Concurrency control algorithms of HiPAC are based on extensions to

7. As rules are themselves represented by objects, the rulebase is apart of the general database.

12

standard two-phase locking and before and after image logging, in contrast to SAMOS’ semantic concurrency control. [Medeiros 91] describes a production rule management system which has been integrated into the O2 objectoriented database system. Rules in O2 are associated with message events, time events (only periodically e.g. every 10 minutes) and composite events (using the disjunction constructor only); additionally they are subject of inheritance across class hierarchies. Contrary to SAMOS, further object-oriented concepts like encapsulation is not exploited and no work on the execution model has been done.

7 Conclusion In this paper, we sketched some properties of the active-object-oriented database system SAMOS, including its knowledge and its execution model. The knowledge model is an object-oriented data model extended by classinternal and class-external rules. Class-internal rules are defined as part of the class definition; they are encapsulated and they (i.e. their event, condition and action part) can operate directly on the value of an object. Class-external rules can be defined by the class implementor, but also by any user or application; they can be manipulated in applications. In addition we want to provide a powerful mechanism for the specification of events, thus an event language is proposed supporting primitive and composite events. We are currently working on historical events i.e. events that occurs with a certain frequency during a specified time interval. Studies has be already done on specification of the time interval. The execution model of SAMOS is based on (generalized) multi-level transactions. Semantic concurrency control is used to synchronize concurrent method and rule execution. Further research is also required to complete the event language e.g. with implicit events, i.e. events that automatically result when a given condition becomes true. As far as the execution model is concerned, further research will deal with open nested transactions as a framework for rule execution. Simultaneously, a prototype implementation of SAMOS is under way.

Acknowledgment The work of S. Gatziu is supported by the Union Bank of Switzerland (UBS). A. Geppert is supported by KWF (Switzerland) in the context of the ESPRIT-II Project ITHACA. Furthermore, we would like to acknowledgment the contributions of the (anonymous) referees.

References Atkinson 89

M. Atkinson, F. Bancilhon, D. DeWitt, K. Dittrich, D. Maier and S. Zdonik. The ObjectOriented Database Manifesto. Proc. DOOD, Kyoto 1989.

Beeri 88

C. Beeri, H.-J. Schek, G. Weikum. Multi-Level Transaction Management: Theoretical Art or Practical Need? Proc. EDBT 1988, Lecture Notes in Computer Science 303, Springer 1988.

Beeri 89

C. Beeri, P.A. Bernstein, N. Goodman. A Model for Concurrency in Nested Transaction Systems. JACM 36:2, 1989.

Bernstein 87

P.A. Bernstein, V. Hadzilacos, N. Goodman. Concurrency Control and Recovery in Database Systems. Addison-Wesley, Reading, MA, 1987.

Atkinson 89

M. Carey, D. DeWitt.The Architecture of the EXODUS Extensible DBMS. Proc. 1st Intl. IEEE Workshop on Object-Oriented Database Systems; IEEE, Pacific Grove, Asilomar, CA, USA, 1986.

13

Ceri 90

S. Ceri, J. Widom. Deriving Production Rules for Constraint Maintenance. Proc. of the 16th VLDB Conf. Brisbane, Australia 1990.

Dayal 88a.

U. Dayal. Active Database Management Systems. Proc. 3. International Conference on Data and Knowledge Bases, Jerusalem, June 1988.

Deux 90

U. Dayal. Rules Are Objects Too: A Knowledge Model For An Active, Object-Oriented Database System. Lecture Notes in Computer Science 334, Springer 1988.

Deux 90

O. Deux. The Story of O2. IEEE Transactions on Knowledge Bases and Data Engineering 2:1, 1990.

Cohen 89

D. Cohen. Compiling complex database transition triggers. Proc. ACM-Sigmod Intl. Conf. on Management of Data, Portland, June 1989.

Chakravarthy 90

S. Chakravarthy, S. Nesson. Making an Object-Oriented DBMS Active: Design, Implementation, and Evaluation of a Prototype. Proc. EDBT 1990, Lecture Notes in Computer Science 416, Springer 1990.

Eswaran 76

K.P. Eswaran, J.N. Gray, R.A. Lorie, I.L. Traiger. The Notions of Consistency and Predicate Locks in a Database System. CACM 9:11, 1976.

Hadzilacos 88

T. Hadzilacos, V. Hadzilacos: Transaction Synchronization in Object Bases. PRoc. ACM PODS 1988.

Hanson 89

E. Hanson. An Initial Report on the Design of Ariel: A DBMS With an Integrated Production Rule System.. SIGMOD Record 18(3), September 1989.

Haskin 82

R.L. Haskin, R.A. Lorie. On Extending the Functions of a Relational Database System. ACM SIGMOD 1982.

Hsu 88

M. Hsu, R. Ladin, D. McCarthy. An Execution Model for Active DBMS. Proc. 3. International Conference on Data and Knowledge Bases, Jerusalem, June 1988.

Kotz 88

A. Kotz, K. Dittrich, J. Mülle. Supporting Semantic Rules by a Generalized Event/Trigger Mechanism. Proc. EDBT 1988, Lecture Notes in Computer Science 303, Springer 1988.

Medeiros 91

C. Medeiros, P. Pfeffer. A Mechanism for Managing Rules in an Object-Oriented Database. Rapport Technique, Altair, 1991.

Moss 81

J.E.B. Moss. Nested Transactions: An Approach to Reliable Distributed Computing. PhD Dissertation, MIT, 1981.

Schwarz 84

P.M. Schwarz, A.Z. Spector. Synchronizing Shared Abstract Data Types. ACM Transactions on Computer Systems 2:3, 1984.

Stonebraker 89

M. Stonebraker, M. Hearst, S. Potamianos. A Commentary on the POSTGRES Rule System. Sigmod Record 18:3, September 1989.

SYBASE 88

SYBASE Inc. SYBASE Data Server. Product information, Berkley, 1988

Widom 90

J. Widom, Sh Finkelstein. Set -Oriented Production Rules in Relational Database Systems. Proc.Intl. ACM-Sigmod Intl. Conf. on Management of Data, Atlantic City, May 1990

Appendix I: A Comprehensive Example The (toy) example Software Crisis is used to demonstrate the main features of the SAMOS approach. Assume the schema as depicted below is used to organize and administrate large software projects. Boxes represent classes, arrows references and bold, dashed arrows represent is_a relationships. Those attributes of classes which are relevant for the example are connected to the classes by edges. Where necessary, the domain of attributes (e.g. a set of references) is shown as well. Projects comprise certain tasks and some general documents. Tasks are managed by some person and performed by groups of people. During the work on a task, a number of documents is produced. Furthermore, tasks are classified, say in to programming, testing, a.s.o. Finally, tasks have a deadline when they have to be finished.

14

In general, documents may be programs (which in turn may be specialized into specifications, implementations, tests) or documentations (reports, manuals). The active mechanism of SAMOS may be used for (a combination) of various tasks: •

consistency maintenance,

•

notification,

•

authorization,

• planning and supervision. In the sequel, a number of rules are defined for the example to illustrate the various concepts. If not mentioned otherwise, all rules are class-external ones.

deadline tasks: { }

project

project_docs: { }

manager user_group members: {}

task

name profile absence

user

group { } manager documents { } type deadline

author

program

document

status

documentation

Figure 2. Sample Schema Example 1: As an overall constraint our company requires that at least 40% of the users have to be females. We assume an object staff of type user_ group whose value represents the extension of all the users. Thus, whenever someone tries to add a user by means of the method add_member applied to staff, the constraint has to be checked. Furthermore, we make use of the argument new_user supplied to the method. DEFINE RULE rule1 ON BEFORE staff.add_member IF [new_user get_gender] = “male” AND count (SELECT s FROM s IN self WHERE [s get_gender] = “female”)

15

< 0.4 * ( count ( self ) ) DO abort_transaction COUPLING_MODE (DEFERRED, DEFERRED) Example 2: The next example uses a time event; additionally, inheritance of rules is illustrated. For documents, assume a method evaluate (for instance, supervising programming guidelines for programs, naming standards and spell checkers for documentations) which computes a mismatch rate. Then, if two weeks before deadline of a task the mismatch is greater than 0.1, raise an event emergency_case. DEFINE RULE rule2 ON 2 WEEKS BEFORE document.[self get_deadline] IF [self evaluate] < 0.1 DO raise event ( emergency_case) COUPLING_MODE (DECOUPLED, DECOUPLED) Note that this class-internal rule is defined for class document. It will be inherited to the subclasses (program and documentation) and will use the appropriate evaluate method in case it has been overwritten by one of the subclasses. Example 3: In the third example, an abstract event is used. Furthermore, the deactivate operation is applied to deactivate a rule. The semantics of the rule is to (possibly) disregard the “female quota” when the emergency_case was signalled before. DEFINE RULE rule3 ON emergency_case IF true DO deactivate( rule1) COUPLING_MODE (IMMEDIATE, IMMEDIATE) Of course, this rule will not be the only one to be executed whenever the emergency_case is raised.

Example 4: In this example, the use of value events, abstract events, and composite events is shown. Assume an integrated staff management using various methods of the class user for holidays, business trips, and absence due to illness (which all update the absence attribute). Then, whenever the emergency_case has been raised and an update of the absence attribute of a user is to be performed, we want to check whether some sort of reorganization in our project is necessary. DEFINE RULE rule4 ON emergency_case; update (absence) : 2 weeks IF true DO [self check_reorganization] COUPLING_MODE (IMMEDIATE, DECOUPLED) In this rule it is assumed that check_reorganization computes the critical tasks where the absent user participate. However, it would be more comfortable to check in the rule condition whether the user actually participate such critical tasks and to pass the concerned tasks to the action part. The action part, in turn, could then perform notifications of the respective managers. However, for this we require a mechanism to pass parameters from the condition to the action part. This mechanism is subject to our future work.

Example 5: Assume a checkout/checkin mechanism [Haskin 82] for (among other purposes) transferring documents to the workspace of users and for copying it back when the user work is completed. Then, another rule is applied to evaluate the document at checkin time and to reject the checkin if the evaluation fails.

16

DEFINE RULE rule5 ON BEFORE document.checkin IF [self evaluate] > 0 DO [ [self get_author] notify_user]; abort_transaction COUPLING_MODE (DEFERRED, DEFERRED) Furthermore, a user may check his/her design even before commit. To do this, he/she can apply the operation raise rule to the rule defined above: raise rule (rule5).

Appendix II schema ::= schema_def+ schema_def ::= class_def | event_def | rule_def | priority_def class_def ::= “DEFINE CLASS” class_name “TYPE_ type_definition (*set, list, a.s.o.*) [“INHERITS” class_name+ ] “METHODS” (method_name “(“ argument+ “)” return_type )+ “CONFLICTS” ( “(“ method_name | rule_part “,” method_name | rule_part“)” )+ [“RULES” rule_def+ ] priority_def [“EXPORTS” event_name+ ] “END” class_name rule_part ::= rule_name “.” (“CONDITION” | “ACTION” ) event_def ::= “DEFINE EVENT” event_name event_clause rule_def::= “DEFINE RULE” rule_name “ON” event_name | event_clause “IF” condition “DO” action “COUPLING_MODE” “(“ coupling “,” coupling “)” event_clause ::= event | comp_event comp_event ::= comp_event (“|” comp_event)+ | comp_event (“,” comp_event)+ “:” time_interval | comp_event (“;” [time] comp_event)+ “:” time_interval | “¬” comp_event “:” time_interval | event event ::= message_event | value_event | time_event | transaction_event | abstract_ event time_interval ::= timespace | transaction time ::= [“min”] timespace [“max” timespace] timespace ::= month day hour minute priority_def ::= “PRIORITIES” [(rule_name “‹” rule_name)+]

17

18

19

20