An Active Object-Oriented Database: A Multi

An Active Object-Oriented Database: A Multi-Paradigm Approach to Constraint Management Hiroshi Ishikawa and Kazumi Kubota Fujitsu Laboratories Ltd., Software Laboratory 1015 Kamikodanaka, Nakahara-Ku, Kawasaki 211, Japan Abstract

must represent both types of constraints, we discuss consfraint managemew as a new databasetechnology to attain this goal.

Mb describe the design and implementation of a constraint management facility for our active object-oriented database system called Jasmine/A. The facility includes integrity constraints, events/triggers, and constraint rules. The facility enables the user to handle both interobject and intraobject constraints, to define both primitive and composite events, and to populate databases with values satisfying specified constraints. We have taken a multi-paradigm approach to construint management. All the paradigms are integrated into object-oriented databases. We describe the semantics of the constraint management facility by extending the conventional terms of trrnsactions and consistency. Evaluation is done officiontly using puge buffers for constraints associated with sot-oriented accessand object buffers for those associatedwith individual object access. Users are also able to control the constraint evaluation.

1. Introduction Ht: developed a prototype object-oriented database system called Jasmine [ISHI91][ISHI93] for advanced applications such us engineering design support and structured document mmagement. Such advanced applications require more active functions than arc needed by conventional applications. For example, we must not only model complex structures and relationships of design objects, but we must also handle design constraints as design specification and geometric constraints bctwccn components. Some constraints can be reduced to a collection of constraints on single object attributes. Other constraints inherently span several object attributes. Since we Permission to copy without fee all or part of this material is granted provided that rk copies are not made or distributed for direct cummcrcial advantage, tk VLDB copyright notice and the title of tk publication and its date appear, and notice is given that copying is by permission of tk Very La&e Data Base Endowment. To copy otkrwise, or to republish, requires a fee and/or special permission from tk Endowment. Proceedlngs of the 19th VLDB Dublin, Irelund, 1993.

Conference,

467

Constraint management includes integrity constraint enforcement, an event/trigger mechanism to propagate updates. and constraint rules to generate values satisfying specified constraints. We call databases with such constraint management facilities acfive databases by extending the original term [MORG83]. There have been attempts to generalize the event/trigger mechanism such as HiPAC [MCCA89] and SAMOS [GATZgl]. Systems such as Postgres [STON90] and Starburst [LOHM91] aim to extend relational databases by introducing production rules. Works on derived attributes and integrity constraints in object-oriented databases include Cactis [HUDS89] and ODE [AGRA89]. We developed a research system called HyperCAD [ISHI91], which supports engineering tasks by using Jasmine to implement the constraint management facilities. W? propose a general framework for constraint management based on the experiences of engineering applications. From this viewpoint, there are some problems with the previous approaches.First, conventional production rules are weak both in generating values which satisfy specified constraints such as design constraints and in describing complex events such as design processes. Such facilities are essential to improve reliability and productivity in design. Second, a singleparadigm approach is not always better than a multi-paradigm approach for representing a variety of purposes such as integrity constraints, triggers, and constraint rules. Third, the semantics of active databases is not so clear in terms of transactions and consistency. Lastly, functions, in particular, triggers and constraint rules must be implemented efficiently. High performance is vital for engineering applications. We have implemented an active object-oriented database system called Jasmine/A (Jasmine Active database system) by extending Jasmine, a kernel object-oriented databasesystem. In this paper, we describe the constraint managementfacility of Jasmine/A and its implementation. The facility includes integrity constraints, events/triggers, and constraint rules. We take a multi-paradigm approach to constraint management. We describe the semantics in terms of transactions and consistency. Evaluation is done efficiently using page buffers

for constraints associated with set-oriented object access and object buffers for those associated with individual object access.Users are also able to control the constraint evaluation. The paper is organized as follows. Section 2 describes active database issues and compares Jasmine/A with related work. Section 3 briefly describes Jasmine, Section 4 discusses our constraint management facility and its semantics, and Section 5 describes its implementation.

user can define time events and composite events. The E-C and C-A couplings can take immediate. dcferrcd. and scparatc ns evaluation modes. HiPAC rules mainly provide support for a trigger mechanism, but unlike Jasmine/A, provides no direct support for constraint rules to uulomatically l~opulalc databases. Like HiPAC, SAMOS allows time and composite events basedon the E-C-A paradigm. It provides E-C and C-A couplings which use the three evaluation modes. SAMOS focuses on triggers, but not on constraint rules.

2. Requirements and Related Work

Systems such as Postgres [STONYO] and Starhurst ]LOllM91] aim to add production rules to cxtcnd relational databases. Unlike Jasmine/A. Postgrcs rules provide n unified npproach IO integrity constraint checks, updato propagation, and view facilities. Postgresdoes not, however. provide any facility for automatic database population based on constraint rules. In general, there are two methods for rule evaluation: forward and backward chaining. Postgres uses optimization to choose bctwccn them. Production rules arc implemented at tuplc arid query lcvcls. which corrcspond to Jasmine/A’s evaluation of constraints on object buffers and on page buffers. Postgrcs does not provide composite events. Examining Starburst, it also provides for production rules. Events arc insertion. replacement. and deletion of values. Conditions and actions can take queries specified in extended SQL and databasecommands. Alert, a Starburst subsystem. allows the user to define views as a kind of production rules. Starburst provides no facility for composite events or constraint rules.

2.1 Requirements Our work aims to satisfy the following requirements. First, constraints must be maintained for object attributes. Such constraints include those on single attributes and those which span multiple attributes of one or more objects, where the latter cannot be reduced to a collection of the former. Second, the system must not only provide direct support for generic integrity constraints, such as mandatory and multiple constraints, but the system must also allow the user to specify application-specific constraints. Third, the constraint managementfacilities must include check and enforcement of constraints on attributes associated with value updates as well as attribute value generation satisfying user-specified constraints, that is, automatic database population based on constraint rules. In particular, such automatic database population is important for engineering applications. Next, we must provide the user with multiple paradigms which are appropriate for all of these purposes. The appropriate paradigm must be available for each facility. These paradigms must be naturally integrated into the object-oriented databases which we take as a basic framework. The semantics of constraint management must be described in terms of transactions and consistency, requiring more generalized concepts of transactions and consistency. Lastly, we must efficiently implement the constraint management facilities. In particular, we must carefully trade off the expressive power of constraint management against the performance. Since the system cannot know all the information available for optimization, the user must also be able to explicitly control the methods of constraint evaluation, making up for any limitations in the system. From these points of view, WC describe Jasmine/A in this paper.

2.2 Related

Work

Systems such as HiPAC [MCCA89] and SAMOS [CATZ91] attempt to integrate active database concepts into objectoriented databases. HiPAC introduces the event (E)-condition (C)-action (A) paradigm. In addition to primitive events, the

ODE [AGKA89] (GEHAYILJprovides integrity constrsints and triggers as separate functions of object-oriented databurrs. Cactis ]HUDS89] aims at active object-oricutcd databuscs. Cactis proposes rule cvuluation schcmcs based on the dcpcndcncy relationships of method (rule) definitions. ODE provides composite events, but Cactis doesn’t. ODE and Cactis provide no direct support for constrsint rules.

3. Overview of Jasmine 3.1

Functionality

‘lb describe Jasmine’s object model. objects arc a collection of attributes, which arc catcgorizcd into properlies (enumeralcd attributes) and method7 (procedural al1ribute.v). Properties are object structures and methods are operutions on those objects. Objects are categorized into instances and clusses. Instances denote individual data and classesdenote types (i.e., structures) and operations applicable to instances of the class. lnstanccs consist of a collection of attribute names and values. Classes consist of attribute names, definitions, and associated information such as demons. Objects are identified by values of the system-defined attribute object identifier (011)). Therefore. objects with the same object idcntificr in a consistent database

468

have the same values. On the other hand, while values such as nunrhcrs and character strings have no OlDs, they do have system-dcfincd classes. Objects with OlDs arc called reference o/Jjwi.s untl vulucs with no OlDs are culled immcdiote 0bjcct.r. Objccta cau include other objects (i.e. 011)s) as attrihutc v;tlu~s. This cnablcs the user to directly dcfinc complex o6jtx.t~ ((~m/~.ri/c* objecrs) ] KIMoO]. Classes arc organized into a hierarchy (more strictly, a lattice)

by generalizolion relationships. This hierarchy is called a c4~s.rhierarchy. A superclass in a class hierarchy is dcnotcd by the system-defined attribute, Super. Classes (i.e., subclasses) can inherit atlributc definitions from their superclasses. Unlike the features provided for in Smalltalk-g0 (GOLD83J. the user can make instances (i.e.. instunriote) from any class in a class hicrnrchy. Such instances arc called intrink instances of the CISSS. III addition IO defining object types and methods. classes arc also intcrprctcd as sets of instances. That is. the instances of a class arc LIIC union of all the intrinsic instances of the class and alI its SII~~~;ISSCS. This diffcrcntiutus Jasmine from other ( X )Dlts such as GcmStonc ] MAIE86] whcrc the user must dcfme separate classes both as a type and as II set. Objects can have a set of objects or just a single object as an attribute value. The, former arc called multiple-valued oftributes and the latter singleton-valued attributes. Specialized functions, called dcmon~. can be attached to attributes to enable the user to flexibly implcmcnt active databases. III Jasmine. the user manipulates objects by sending messages IO objects just as in object-oricntcd programming languages. This is called singleton access. The user can assign values to attributes and rcfcrcncc attribute values. Jasmine allows seforierited ac~~.r~ in addition to singleton access. Set-oriented IWCSS is done by object qucrics. The basic unit of an object cpwry is an object expression. a class name followed by a series of uttribute names delimited with periods. Object expressions climinatc most of tile need for equijoin predicates in relational databnses. The user can also specify methods in object cxprcssions. An object query consists of a target and a condition. The target part is a list of object expressions. The condition part is a logical combination of simple conditions comparing object expressions by comparison operators. For exemplc. the following query finds the name of coworkers of an employee who works in the shoe department and is over 30 ycnrs of age:

messages to the object variables. The introduction of object variables reduces impedance mismufch between a programming language and a database language [MAIE86]. As users can specify object queries as well as simple manipulation of attributes in methods. virtual objects can be defined using methods. Since a query on a class rctums all the instances of the class and its subclasses. a single Jasmine query can rctricvc what would take multiple relational database queries to retrieve. By specifying methods in a query, users can retrieve and manipulate objects in a set-oriented manner. If a superclass is spccificd with a method in a query, methods dedicated to instances of the class and its subclasses can be invoked simultaneously. This facilitates polymorphism [STEF86] in a set-oriented manner. A query can also make new instances from more hn one class like joins in a relational database. Application programs written with Jasmine are precompiled into C programs. During this process, references to attributes arc statically resolved to reduce the burden of a dynamic search, allowing the C programs to execute efficiently. A set-oriented query can also be interpreted interactively. Although objects are basically persistent. since they exist over program execution, though users can make temporary objects as in conventional programming languages. which exist only during program execution. A Jasmine database usually consists of several classes and users can access several databases concurrently or switch among them. Jasmine provides basic database facilities such as transaction management.

3.2

Implementation

The Jasmine system has a layered architecture consisting of object management and data management (See Figure 1). The object management layer allows modeling and manipulation of objects. In particular, this layer has object buffers that cfficicntly manage objects in main memory. The data management layer allows transaction management and page buffer management as database functions.

EMP.Coworkers.Name where EMP.Dept = “shoe” and EMP.Age > 30

Object

management I

Data management I Databases

‘lo make application programs, users can combine singlctonaccess and set-oricntcd access. An elcmcnt of a set of objects is assigned to an object variable and is manipulated by sending

469

Figure 1. System architecture.

The data management layer is a general-purpose database management system that extends relational databases (YAMA891. This enables the user to define and access nested relations [ROTH881 as well as flat reladons. This layer provides nest and unnest operations for relations, in addition to reference and update. The system provides sequential, B-treebased, and hash-based access to both flat and nested relations. A clustered index can be implemented by storing whole tuples into B-tree relations. A nonclustered index can be implemented by storing only keys and tuple identifiers into B-tree relations. Objects are mapped into relations as follows. All intrinsic instances of a class are stored in a relation by having attributes correspond to fields. Intrinsic instances include inherited and non-inherited attributes. Multiple values are stored in multiplevalued fields, the simplest form of nested relations. Classes arc stored in nested relations because they have nested suuctures. The user can specify logical page sizes for each relation. Each class has its own page size. A class normally inherits the page size of its superclass. If necessary, however, the page size can be enlarged. There is no limitation to the number and length of tuples and fields although whole tuples must be contained in one page. This enables the user to optimally store and access large-scale data such as images. Operations and tests on fields of relations are treated as user-defined functions in the data and predicate management layer, called manipulation on data in page funclions. and compiled into operations buffers. Object queries are translated into relational operations such as selection and join. During this process, they are optimized. Object expressions generate several joins whose execution order is determined dynamically. Joins are usually proccsscd based on hashing. If an index is attached to fields, it is used for selection and join. Page buffers are appropriate for access to homogeneous data. but inappropriate for access to related heterogeneous data such as complex objects. Therefore, the object management layer provides object buffers. Objects, when accessed for the first time, are fetched from databases in secondary memory to pa8c buffers in the data management layer. Only the rcquircd data comes to the object buffers from the page buffers. Object identifiers are represented as a triplet of database, class, and instance numbers. The identifiers of objects fetched into object buffers are translated into addresses in main memory. This eliminates the need for joins of relations and enables direct access of complex objects. The objects in object buffers also have tuple identifiers. If there are any updated objects in the object buffers, they arc written back to [he page buffers using the tuple identifiers at the end of the transaction. Before a set-oriented query is evaluated, any updated objects

470

associated with the query, that are in the object buffers arc moved to the page buffers. The query is then evaluated agninst the page buffers. Unlike Jasmine, Orion [KIM90] evaluates the same query for both object buffers and page buffers and integrates the results. Because our approach needs only one evaluation scheme. the system is more compact. A query on nonlcaf classes in a class hierarchy is trnnslatcd into multiple queries on relations. Simple methods specified in a query, such as manipulation of attributes, are transformed into operations on fields of relations. These can be excculcd more efficiently on page buffers because unnecessary daut transfer between page and object buffers is reduced. On the other hand, more complex methods, such as manipuladon of heterogeneous objects of complex objects, are rrlorc cfficicntly cvaluald in object buffers. Methods appearing in the condition purl arc similarly processed. Unlike other OODBs. Jasmine efficiently cxecutcs methods by combining object and page buffers.

4. Constraint 4.1 Integrity

Management Constraint

W? now describe integrity constraints supported by Jasmine/A. Basically, constraint management is modclcd on the E-C-A paradigm. We realize intcgrhy conslruints by Jasmine demons, which are essentially the conditions and uctions dcscribcd in Section 4.2. First. WC provide the system-dcfincd dauons for and mulliple. They take the properties such as mundakwy following syntax: ClassName

PropertyName

mandatory muhiple

If a value is inserted into a mandatory property at instantiation, that is, if inserl and instantiute events occur at the same time, then Lhc instantiate event is successful. Otherwise. the instaniiation is aborted. If a value is dclctcd from a mandatory property, that is. a delete cvcnt occurs, then an error is induced. Of course, the rcpluccmcnl of a mandutory properly value. or a replace event, is possible. If a new value is added to a multiple-valued property. then the insertion is successful. The insertion to a single-valued propercy is prohibilcd when the property already has n value. Of course, the rcplaccmcnt of a singleton-valued property is possible. All the cvcnls. conditions. and actions associated with mandatory and multiple demons are system-dcfincd. Next we dcscribc following syntax:

constraint

dcmens. The demon has IIIC

ClussName

constraint

PropertyNume

(condition

demon definitions. The variable Self is bound to the instance where the event occurs. The variable Value is bound to refcrenccd. inserted. deleted, or replaced values depending on the events. An existing value before replacement is bound to the variable OldValue.

)

lf the user-defined condition is true when an insert or a replace event OCCII~S. the transaction for the cvcnt is committed. ()lhcrwisc, the transaction is aborted. The cvcnt and action in his case arc system-dcfincd while only the condition is userdrfincd. The condition is specified by a subset of the query language. hat is. the condition part of a query. For example,

Methods can also take the following

demons:

before -demon melhod

Wll’

after-demon

mandatory multiple constraint ( Value >= IS )

Dcp1

C’oworkcrs Age

Invocation of user-defined methods correspond to user-defined events. Method demons, that is. before and after demons also modularize user-defined conditions and actions like property demons. Before demons are invoked before the main methods; after demons are invoked after. Usually, before demons are used to cheek or establish the preconditions of the method invocation. After demons are used to propagate the effects of the method invocation.

whcrc the variable V&e rcplaccd. The constraint dcfincd constraints on wnslrainls. Constraints

is bound to the value being inserted or demon is mainly for expressing usersingle attributes. that is. infroobjecf spanning multiple attributes, that is, inlerobject conslruinls, arc supported by triggers and constraint rules as described later.

4.2 ‘Itiggers

and

Primitive

The integrity constraints and user-defined demons described above arc specified in the class and are activated on its instances where associated events occur. Of course, they are invoked when instances are set-theoretically retrieved, replaced, or accessed with methods inserted. deleted, invocation. If there are multiple rules, that is. pairs of conditions and actions associated with the same event for one attribute. they are usually prioritized by using if-then-else constructs within demons. Note that we presently do not provide support for simultaneous firing of multiple rules.

Events

We dcscribc our basic cvcnt and triggering mechanisms called demons. Jasmine/A allows 111~user to define demons for propcrlics as follows: ( .‘lu.ssNumr I’roperryNum*

if-rcfcrcnccd if-inscrlcd if-dclctcd if-rcplaccd

( iJ: re~!reflccd-_d~,t~)tl

)

{ IT-inserted--demon ( ij:deleled-demon (i/-replaced-demon

) ) )

Property demons such us if-referenced. if-inscrtcd. if-delctcd, and if replaced demons modularize user-dcfincd conditions und arlions ns follows: if condirion lhen action clsc if condition then uction

The condition syntax corrcsponds to that of ~hc condition part of H query. The conditions, howcvcr. can access database lronsirions as well as database states. The actions include both SCI oriented and individual object access. If system-dcfincd cvcnts such as rcfcrcnce. insert, dclctc. or replace occur, the corresponding user-defined demons are invoked. In general, production rules consist of conditions and uctions, so demons can reprcscnt u WI of production rules. Constraint rules for automatic value gcnerution nrc described in Section 4.4 The systcmdcfined

variables Self and Value can bc: us4 in the

Objects arc acccsscd through system-defined and user-defined methods. System-dcfincd methods include start, commit, and abort of transactions in addition to instance operations such as refcrencc, insert, delete. replace. In general, method invocation corresponds to event occurrence, so the system can directly recognize the event occurrence. Method invocation corresponds to basic events. The user can combine primitive cvcnts to define composite events as described in Section 4.3. W illustrate the demon functionality by taking some examples used in other work such as Postgres [STON90]. The following demon defined for the Attribute Salary of the class EMP(loyee) specifies the rule that if Joe’s salary is updated, the new value is propagated to Sam’s salary. EMP Salary if-replaced (if Sclf.Name = “Joe” then EMP.replace (“Salary”, Value) where EMP.Name=“Sam”) The next demon specifies the rule that every time Joe’s salary is rcfcrcnced, Rill’s salary is made equal to Joe’s:

471

EMP Salary if-referenced (if Self.Name = “Joe” then EMP.replace(“Salary”. Value) where EMP.Name=“R ill”) The following demon specifies the rule that Joe is unable to see Salaries of employees in the shoe department:

demons, and even views are integrated into object-oriented databases. Demons are inherited through a class hierarchy. Polymorphism is also avuilablc. If the snme event occurs IO instances of different classes in a query inchiding muhiplr classes, each of the demons associated with the same cvcn~ is invoked. Users can also activate and deactivate demons. Next WC take some examples of Date’s Hypothetical Language [ DATEYO].

EMP Salary if-referenced (If Self.Dept = “shoe” and user0 = “Joe” then Value = Null]

S Status if-replaced { if Value c= OldValue then Self.replace(“Status”, OldVulue)) if-in.serted ( if S.Status.avg() 0.06+ CylindcrDiametcr advice Sclf.incrcasc() (2) Vuluc < 0.065* CylinderDiametcr advice Sclf.decrcase() (3) Power (PistonDiameter, 2) + ExplosionPowcr / power (Value, 2)< 80.0 advice Self.increase() I PistonDiameter.decrcasc () incrcasc generate-incr decrease generate,deer Name Parameter

fashion. In Jasmine/A, the user can modify the initial solution by invoking the constraint rules again with some constraints changed. The user can specify constraints such as fix, increase, decrcasc. loose fix, and don’t care for the current values.

4.5

Semantics

Wb describe the semantics of integrity constraints, triggers including primitive and composite events, and constraint rules in terms of transactions and consistency. In general, a transaction causes transition from one consistent database state to another consistent database state. Transactions under consideration consist of events, conditions, and actions as follows: C ( event condition action ) C’ where C and C’ denote consistent database states. First, we consider integrity constraints. such as mandatory, multiple, and constraint. When the event such as insert or instantiate, occurs, the transition from C to C’ is committed only if the condition, system-defined or user-defined, is true. Otherwise, the transaction including the triggering event is aborted. As a result, the state C stilj holds. In case of primitive events such as reference, insert, delete, and replace, the action is invoked within the associated demons to result in the state C’ if the condition holds. Otherwise, in case of insert, delete, and replace events. the action compensating for the effect of the cvcnt is invoked within the demons. At that time, the resultant slale C’ is semantically equal to the state C. Thcsc semantics are also true for constraint rules. If the conditions of one rule are satisfied, the transaction establishing the property value as the action of the rule is committed to reflect the event effect to the database. Otherwise, the action compensating for the event effect is committed and another rule is invoked. Note that even then, all the rules are not aborted.

This rule dctcrmincs the value of PistonHcadThickness dependent on other parameters. such as ExplosionPower and CylindcrDiameter. by using the gcncration method. Three condition-action pairs are specified. The last condition’s action for advice in the cvcnt of failure specifics disjunctions of actions. Like triggers, our constraint rules are basically set-oriented. In general, there is more than one combination of parameters satisfying the same set of constraints. However, we don’t take the approach where all solutions are automatically generated, because all of them are not always interesting. It is more dcsirnble lhat the user can modify the initiul solution to get an alternative if it is unsatisfactory. In a word, the user must be able to control the exploration of alternatives in a stepwise

Until now, we have used the term transaction to mean a conventional short transaction. The consistency associated with a short transaction is application-independent, or a local consistency. In general, an application is a sequence of such constitutes a long short transactions. Such an application transaction as a whole. The associated consistency is application-dependent, or a global consistency. The purpose of applications is to establish global consistency. Integrity constraints focus more on local consistency while composite events and constraint rules focus more on global consistency. In particular, there are cases where events, conditions, and actions are separate transactions. That is. there are applicationindependent consistent states between C and C’. The coupling modes of the E-C-A paradigm are used to specify such cases.

475

5. Implementation 5.1 Integrity

Constraints

and Primitive

Events

This section describes the implementation of system-dcfincd integrity and user-defined demons (primitive events). For multiple integrity for a property, the following code is embeddedinto predicate functions of the insert operation of the data management subsystem only if multiple is not specified for the property by the user, that is, only if the property is singleton-valued: if the property is empty, then return True else return False

inscrtcd, if-dclctcd. and if-replaced demons should be cpccifiad for B. l’hc former cast corresponds to brckward chaining and the latter cast corresponds to forward chaining. Like this, JasminclA ullows the user to control evaluation because WC: assume that the user knows access pattcms better than the system dots.

5.2 Composite

Events

W realize composite events by using methods and demons of objects in a bootstrap manner. To check events for immcdintc or scparatc evaluation, the PRIMITIVE-EVENT clnss has the following demon spccilicd for the property Time: PRIMITIVE-EVENT Property TIME Time multiple if-inserted ( Sclf.Compositc.check_immcdiatc~or_scpllte () whcrc Sclf.Compositc.E-C-mode= immediate or Sclf.ComJxrsite.E-C-mode= separate)

The insert operation is performed only if the predicate.is true.

The insertion to a mandatory property is needed at instantiation of the instance with the property. Deletion is prohibited while replacement is allowed. So the instantiate method checks the insertion to the mandatory properties. The delete method checks the deletion of the mandatory propertics. These cheeks can be done at the object managementlayer without accessing actual values. The user-defined constraint is embedded into predicate functions of the insert and replace operations of the For defcrrcd cvaluution. the system cxccutes the following data management. The insert and replace operations arc query bcforc the end of the transaction: performed only if the predicate is true. COMPOSlTE,EVENT.sort(‘Time”. Ascending).chcck-dcfcrrcdo Next we describe the implementation of user-defined demons. where COMPOSJTE&‘ENT.E-C-mode = dcfcrred or COMPOSITE-EVENTC-A-mode = deferred The conditions and actions of demons if-referenced. if-inserted. if-deleted, and if-replaced are compiled respectively into the predicate and manipulation functions of the select, insert, The expression sorr( ‘Time”, Ascendinlp) means that composite delete, and replace operations in data management. The events are evaluated in a first-come-first-served manner. It is predicate and manipulation functions are directly evaluated on implcmcntcd by cmbcdding the above query in the before page buffers. This reduces unnecessary data transfer between demon of the transaction commit method. application programs and page buffers. This scheme is used for set-oriented accessof objects. For individual accessof objects, The six combinations of the two coupling modes are intcrprctcd and the conditions and actions are evaluated on the object buffers. by the methods check-immediate-or-scparatc 1llC whcrc W. provide separateevaluation schemesappropriate for each of check-dcfcrrcd of COMPOSITE-EVENT. the two types of access. The demons for the user-defined spawn-transaction operation crcatcs a new transaction whose methods (events) are also compiled into predicate and execution may bc postponed until the triggering transaction manipulation functions. In this way, the conditions and actions commit or abort methods arc activated (See Figure 2). associated with the events can be efficiently proccsscd. The detection of events themselves can be also efficiently done. Rules That is. the system can directly detect the occurrences of 5.3 Constraint events, system-defined or user-defined, because they are Constraint rule processing is divided into rule analysis, invoked only through method invocation. execution planning, and rule execution. Constraint rules are In general, there are two evaluation schemes for triggers or used to determine property values of objects satisfying the production rules: forward chaining and backward chaining specified constraints. Basically, the execution order of rules is [STON90]. Assume that A and B are attributes of objects and determined by the dependency between rules. that is. between that A is dependenton B. If A is rarely referenced and B is often propertics. The depcndcncy bctwecn rules is called n updated, the if-referenced demon should be specified for A. dependency network. The uppermost nodes in the dcpendcncy Conversely, if A is often referenced and B is rarely updated. if- network arc propertics which arc not dcpcndcnt on other nodes.

476

satisfaction is based on the gcncrate and test scheme. rl~cck..immetliutc_or~-sep~ratc() l if Sclf.E-C-mode = immcdiatc then (if SclfC-A-mode = immediate then 1if Sclfevcnt-cval() & Sclf.condition-cval() then Self.action-evaI else if Sclf.C-A-mode = defcrrcd then ( if Sclf.cvent-eval() & Sclf.condition-cval() then SelfCondition-value = True else SclfCondition-value = False) else if Sc1f.CA-mode = separate then ( if Sclf.evcnt-evul() & SelLcondition-cval() then spawn-transaction (Self.action-cval()) else if Se1f.E-Cmode = separate & SclfC-A-mode = separate then l if Sclf.cvcnt-eval() then spuwn-lransaclion { if Sclfcondition-eval() then Sclf.action-&I()) clsc error0 )

(1) Rule analysis The system detcrmincs the level of rules according to the dependency between rules. Rules at level 1 depend on no other rules. Rules at level 2 only depend on level 1 rules. In general, rules at level n depend on at least one rule at level n-l. We can detect loop dependencies by using developed and undeveloped rule lists. Initially, the undeveloped rule list contains all rules at level 1 and the developed rule list contains no rules. The rules at level 1 are developed into the rules dependent on the rules at level 1. The developed rules are put in the developed rule list. The dependent rules are put in the undeveloped rule list. Similarly, the rules taken from the undeveloped rule list are developed into the rules dependent on the taken rules. If, during rule analysis, the same rule appears both in the undeveloped and developed rule lists at the same time, a loop occurs. This is brought to the user’s attention for further processing.

))

)

(2) Execution planning check-dcfcrrcd() ( if Self.E-C-mode = immcdiatc &’ Sclf.C-A-mode = dcfcrred then 1 if Self.Condition-value = True then Self.action-eval() ) else if Sclf.E-C-mode = deferred & Self.C-A-mode = deferred then { if Self.event-eval() & Self.condition-cval () then Self.action-evaI clsc if SelLE-C-mode = dcferrcd & Sclf.C-A-mode = separate then [ if Self.evcnt~.eval() & Self.condition-cval() then spawn-transaction ( Sclf.action-cval() )) clsc

cnor()

)

Figure 2. Methods of COMPOSITE-EVENT.

Rasically, rule execution or constraint satisfaction is dorm from top to bottom in the dependency network. If one rule is cxccuted successfully, another rule is fired. One rule corrcsponds IO a short transaction and establishes local consistency. Global consistency is only established as a whole if all the rules corresponding to a long transaction urc successful. Of course, candidate values do not ncccssarily satisfy the constraint condition initially. That is. the backtracking is usually needed for constraint sutisfaction. When backtracking occurs, the effects of unsuccessful rules arc compensated and ultcrnative rules are invoked. The backtracking method is specified in the advice part of the constraint rules by the user. Loop dctcction is done statically during dcpcndency netwnrk clcvclopment. As is described later, dynamic loop detection is donr during rule cxccution. For generality, constraint

After the levels of rules are determined. the rules are grouped into disjoint sets of related or connected rules. Within one rule group, the rules are ordered according to increasing level. If there is more than one rule with the same level, order is determined based on the number of rules upon which the rules depend. That is, the smaller the number, the higher the execution priority. In the final step, the disjoint sets of rule groups are merged into a linear list. (3) Rule cxccution A plan is a list of rules pushed onto the stack. Individual rules ure popped from the stack. A candidate value is generated through the generate method of the constraint rule. If a pattern of partially determined values including the candidate value is already in the history hash table, a rule execution loop occurs. That is, the system can detect the loop dynamically In other words, the system can guarantee the termination of rule execution. If the pattern is not in the history table, then the constraint condition is evaluated. If the condition is satisfied, then all the advice actions associated with this rule are popped off the stack. Otherwise, the advice action of the condition is pushed on the stack. If all the conditions are satisfied, the dependent rules are pushed on and the control is given to the beginning of this process. When the user has specified alternative solutions or alternative sets of values, the system modifies the constraints according to these specifications. For example. if the user specifies “Increase the current value”, the condition “Value > CurrentValue” is inserted to the constraint rules. The execution of rules is done in the same order as the initial plan.

477

6. Conclusion Ws have described the design and implementation of the constraint management facility for our active object-oriented database system called Jasmine/A. The facility includes integrity constraints, events/triggers, and constraint rules. The facility enables the user to handle both interobject and intraobject constraints, to define both primitive and composite events, and to populate databases with values satisfying specified constraints. We have taken a multi-paradigm approach to constraint management. All the paradigms are integrated into object-oriented databases.We have described the semantics of the constraint management facility by extending the conventional terms of transactions and consistency. Evaluation is done efficiently using page buffers for constraints associated with set-oriented object access and object buffers for those associatedwith individual object access.Users are also able to control the constraint evaluation, We plan to apply Jasmine/A to various practical applications to verify the validity of our approach and give expcriencc feedback to the system. We also plan to include cnhanccments such as extension of composite event specification, extension of constraint rule description, and the addition of a graphical user interface.

Acknowledgments % thank the anonymous referees for their helpful suggestions.

References [AGRA89] Agrawal, R.. et al.: ODE: The language and the data model, Proc. the 1989 ACM-SIGMOD Conference, pp.3645( 1989). [DATE901 Date, J.C.: An Introduction to Database Systems, vol. 1. Addison-Wesley, 1990. [GATZ91] Gatziu, S., et al.: Integrating Active Concepts into an Object-Oriented Database System, Proc. the 3rd International Workshop on Database Programming Languages (1991). [GEHA92] Gehani. N.H.. et al.: Event Specification in an Active Object-Oriented Database, Proc. the 1992 ACMSIGMOD Conference, pp. 81-90 (1992). [GOLD83 ] Goldberg, A., et al.: Smalltalk-80: The Language and Its Implementation. Addison-Wesley, Reading, MA., 1983. [HUDS89] Hudson, S.. et al: Cactis: A Self-Adaptive, Concurrent Implementation of An Object-Oriented Database Management System, ACM Trans. Database Syst.. vol. 14.. no.3. pp.291-321(1989). [ISHI90] Ishikawa. H.: An Object-Oriented Knowledge Base Approach to a Next Generation of Hypermedia System, Proc. IEEE COMPCON Spring 90 Conference, pp. 520-527 (1990).

[ISH191] Ishikawa, H.. et al.: An Object-Oriented Database: System and Applications, Proc. the IEEE Pacific Rim Confercncc on Communications, Computers. and Signal Processing, pp.288-291 (1991). (ISHI Ishikawa, H.. ct al.: An Object-Oriented Dntabasc System and its View Mechanism for Schema integration, Proc. the 2nd Far-East Workshop on Future Database Systems, pp.l94-200 (1992). [ISH193] Ishikawa, H., et al.: The Model, Ltmguagc. and Implementation of an Object-Oriented Multimodia Knowlcdgc Base Management System, ACM Trans. Dutahase Syst.. vo1.18. no.1. pp.l-50 (March 1993). [KIM901 Kim, W.. et al.: Architecture of the ORION NextGeneration Database, IEEE Trans. Knowlcdgc and Data Engineering, vol. 2. no.1. pp. 109-124 (1990). [LGHM91] Lohman, G.. et al.: Extensions to Starburst: Objects. Types, Functions, and Rules. Comm. ACM, ~01.34. no.10. pp.94-109 (1991). [MAIE86] Maier, D.. CLal.: Dcvclopment of an object-oriented DBMS, Proc. the 1st OOPSLA Confcrencc, pp. 472-482 (1986). [MCCASY) McCarthy, D.. et al.: The Architecture of An Active. Object-Oriented Database System, Proc. the 1989 ACMSIGMOD Conference. pp.215-224 (1989). [MORG83] Morgcnstcm. M.: Active Databasesas II paradigm for Enhanced Computing Environments. I’roc. IIIC 9th VLDR Confcrcnce, pp. 34-42 (1983). IROTH Roth, M. A., et al.: Extended Algebra and Calculus for Nested Relational Databases. ACM Trans. DatabaseSyst.. ~01.13, no.4, pp.389-417 (Dec. 1988). (STEF86] Stefik, M., et al: Object-Oriented Programming: Themes and Variations, AI MAGA7JNE. ~01.6, no.4. pp.40.62 (winter 1986). [STON90] Stoncbraker, M., et al.: On Kules. proccdurcs. caching and views in database systems, Proc. the 1990 ACMSIGMOD Confcrcncc. pp.281-290 (1990). (YAMA Yamane, Y., ct al.: Design and Evaluation of a High-Speed Extcndcd Relational Dutabase Engine XRDB. Proc. Intcmational Symposium on Database Systems for Advanced Applications, pp.52-60 (1989).

478