Dimensions Of Active BehaviourNorman W. Patony, Oscar D��azz, M. Howard Williamsy,Jack Campiny, Andrew Dinnyand Arturo JaimezDepartment of Computing and Electrical Engineering,yHeriot-Watt University, RiccartonEdinburgh, Scotland.e-mail: < norm,howard,jack,andrew>@cee.hw.ac.ukDepartamento de Lenguajes y Sistemas Informaticos,University of the Basque Country,zSan Sebasti�an, Spain.e-mail: < diaz,arturo >@si.ehu.esAbstractThis paper introduces a number of dimensions of active rule system be-haviour which can be used both to highlight di�erences between proposalsfor active rule systems, and to identify the requirements of di�erent appli-cations. These dimensions relate to the structure, execution model andmanagement of active rules, and enable the concise expression of whatfacilities a system supports and what features an application requires11 IntroductionThe extension of conventional passive databases with features which supportautomatic responses to particular circumstances has been recognised as a worth-while endeavour by database researchers. The resulting active database sys-tems not only ease the implementation of time-constrained applications, butcan be readily extended with enhanced data modelling facilities. The perceiveddesirability of active mechanisms has led to a number of detailed proposalsfor the introduction of active behaviour to new or existing database systems[5, 22, 25, 10, 16]. However, such proposals di�er in a number of aspects whichsigni�cantly a�ect the behaviour of a set of rules at run-time. In order to aidunderstanding of active databases, this paper seeks to identify a number of suchaspects, referred to here as dimensions, which can be used to characterise thebehaviour of individual active rule systems.1In: Proc. 1st Int. Wshp. on Rules In Database Systems, N.W. Paton and M.H. Williams(eds), 40-57, Springer-Verlag, 1994. 1

The variability of proposed systems along the dimensions considered in thispaper has a signi�cant bearing upon the applications in which a rule system canbe employed. Indeed, it is shown that potential applications can be classi�edusing the same dimensions as the di�erent rule systems, thereby highlightingwhich proposals for rule systems are most appropriate for di�erent applications.The classi�cation of applications according to the di�erent dimensions ofrule behaviour suggests that a single, in exible model for rule behaviour isunlikely to be appropriate for a wide range of tasks. This suggests that eitherrule systems must be sophisticated enough to anticipate the needs of di�erentapplications, or must be tailorable to suit di�erent requirements.The paper is structured as follows. Section 2 introduces the dimensionsof active behaviour considered later in the paper. Section 3 indicates how anumber of existing systems support the di�erent dimensions, and section 4relates the dimensions to a number of typical applications. Conclusions arepresented in section 5.2 Dimensions Of Active BehaviourThis section introduces a number of dimensions of active behaviour. Thisprocess makes explicit the decision space within which the designers of activerule systems work, without endeavouring to provide any formal description ofthe semantics of speci�c rule systems { the actual behaviour of a rule system isalso in uenced by the environment of which the rule system is part, speci�callythe data model, query language, update language, etc. However, the fact thatthe dimensions discussed in this section abstract over certain details of rulesystem functionality which a�ect more than `look and feel' does not signi�cantlydetract from the overall aim of providing a framework which highlights keydi�erences between existing systems and applications.The concepts considered in this section as dimensions are clearly not new {they are supported within a range of proposals for rule systems, and thus theterminology used below should be familiar to the readers of [5, 25, 22]. However,we are not aware of any other attempt to identify generic concepts which canthen be used in the comparison of rule systems or applications. The dimensionsof rule functionality considered in this paper are presented in Table 1, and arediscussed further in the following subsections. In the table the symbol � isused to indicate that the particular dimension can take on more than one ofthe values given, whereas 2 indicates a list of alternatives.An active rule is considered to have (up to) three principal components, anevent, a condition and an action. When the event takes place, the conditionis evaluated to examine the context in which the event took place, and if truethen the action is executed to enact some suitable response to the event.2.1 EventThe Type of an event can be:

Table 1 { Dimensions of Active BehaviourEvent Type � fPrimitive, Composite gSource � fStructure Operation, Behaviour Invocation,Transaction, Clock, Error, ExternalgLevel � fInstance, CollectiongRole 2 fMandatory, Optional, NonegCondition Mode � fImmediate, Deferred, DetachedgRole 2 fMandatory, OptionalgAction Mode � fImmediate, Deferred, Detached Dependent,Detached IndependentgOptions � fUpdate-Db, Update-Rules, Inform,Abort, Do Instead gExecution Transition Granularity 2 fInstance, SetgModel Binding Model � fInstance, Set, PriorgConstraints � fTiming, AlternativesgScheduling 2 fAll Fired, Some FiredgPriorities 2 fNumerical, Relative, NonegManagement Operations � fActivate, DeactivategDescription � fProgramming Language,Extended Query Language, ObjectsgAdaptability 2 fCompile Time, Run TimegData Model 2 fRelational, Extended Relational,Deductive, Object-OrientedgPrimitive, in which case the event is raised by a single, low-level occurrence,which belongs to one of the categories described in Source below.Composite, in which case the event is raised by some combination of prim-itive events [5, 14]. A composite event is constructed from a number ofother primitive or composite events using a range of operators which varyfrom system to system, but which may include conjunction, disjunction,sequence and negation. The semantics of composite events are compli-cated by the need to maintain a history of events which have taken placeover some timespan (e.g. during a transaction) [15].The Source of an event can be:Structure Operation, in which case the event is raised by an operation onsome piece of structure (e.g. insert a tuple, update an attribute, access atuple).Behaviour Invocation, in which case the event is raised by the executionof some user-de�ned operation [10] (e.g. the message display is sent toan object of type widget). In the case of behaviour invocation, there isalso the issue of when the event is raised relative to the invocation of theoperation { for example, it is possible for the event to be raised before orafter the execution of the operation.

Transaction, in which case the event is raised at some speci�c point in atransaction (e.g. before abort, start of transaction).Clock, in which case the event is raised at some particular point in time [5, 14](e.g. it is 23:00 hours, it is 4 hours since some other event). Furthermore,clock events can be used to specify the time limit within which compositeevents should take place [14].Error, in which case some error has occurred within the database.External, in which case the event is raised by a happening outside the database[5] (e.g. the temperature reading goes above 30 degrees).The Level of an event indicates whether an event is de�ned for every objectin a collection (e.g. every instance of a class), or for speci�c instance objects(e.g. to prevent unauthorised access to speci�c instances, or to enable theupdate of the speci�c widget objects which are presently on screen.The Role of an event indicates whether events must always be given foractive rules, or whether the explicit naming of an event is not necessary. If theRole is Optional, then when no event is speci�ed condition-action rules aresupported, which have signi�cantly di�erent functionality and implementationsfrom event-condition-action (ECA) rules [21, 16]. If the Role is None thenevents cannot be speci�ed, and all rules are condition-action rules. If the Roleis Mandatory then only ECA-rules are supported.2.2 ConditionThe Mode of a condition indicates when the condition is to be evaluatedrelative to the event which triggers the rule [5]. The Mode of a condition canbe:Immediate, in which case the condition is evaluated immediately after theevent which triggers the rule.Deferred, in which case the condition is evaluated within the same transac-tion as the event which triggers the rule, but not necessarily at the earliestopportunity after the event. For example, the condition may not be eval-uated until the end of the transaction [25], or may be forced to evaluate ata speci�c point in time by a �re rules command in an application program[25].Detached, in which case the condition is evaluated within a di�erent trans-action from the one in which the event took place.The Role of a condition indicates whether or not it must be given. InECA-rules, the condition is invariably Optional. When no condition is givenfor an ECA-rule, an event-action rule results, which is similar to the notion of atrigger supported by some commercial relational database systems. In systemsin which both the event and the condition are optional, it is always the casethat at least one is given.

2.3 ActionThe Mode of an action indicates when the action is evaluated relative to thecondition of the rule [5]. The Mode of an action can be:Immediate, in which case the action is executed immediately after the con-dition of the rule.Deferred, in which case the action is executed within the same transaction asthe condition of the rule, but not necessarily at the earliest opportunity.Detached Dependent, in which case the action is executed within a di�erenttransaction from the one in which the condition was evaluated. Theexecution of the action is Dependent upon the transaction in which theevent took place committing.Detached Independent, in which case the action is executed within a dif-ferent transaction from the one in which the condition was evaluated.The execution of the action is Independent of the committing of thetransaction in which the event took place.The range of tasks which can be performed by an action is speci�ed as itsOptions. Actions may Update the database or rule set, Inform the user orsystem administrator, Abort a transaction or take some alternative course ofaction using Do Instead[22]. As an example of Do Instead, if an event wasan inappropriate update, then a more appropriate alternative update could beused instead of rather than as well as the operation which raised the event.2.4 Execution ModelThe execution model speci�es how a collection of rules is treated at run-time.The Transition Granularity indicates how regularly events are raised, andthus the amount of intermediate information associated with each event. TheTransition Granularity can be:Instance, in which case an event can be raised every time an operation isperformed on a single data item. For example, if an event is de�ned ondeletions to the student relation, then an event is raised every time anindividual student is deleted. Thus an event is associated with a singlecurrent tuple.Set, in which case an event can be raised at a point subsequent to operationswhich could have modi�ed multiple data items. For example, if an eventis de�ned on deletions to the student relation, then an event could beraised every time an operation completes which deletes students. Suchan operation may delete many students (e.g. delete from student whereage > 30), and thus an event is associated with a set of current tuples. Afurther possibility is that events are raised at the end of a transaction. Forexample, if an event is de�ned on deletions to the student relation, then an

event is raised at the end of the transaction if any statement has deletedtuples from the student relation. There may have been a number of suchoperations during the transaction. Indeed, di�erent operations duringthe transaction may have inserted and then deleted a student tuple. Inthis case, the net e�ect [25] of a sequence of operations is normally usedto associate a set of current tuples with an event, and thus rules havethe e�ect of accumulating changes which have taken place during thetransaction for processing at commit time.The Binding Model indicates what information on the context of the ruleis available to the condition or action of the rule. Clearly it is possible for arule condition to query the database, but it is often necessary for the conditionor action to be able to retrieve details on the nature/e�ect of the event whichhas triggered the rule. It is normal for the same binding operations to besupported by the condition and the action, although if an action does not takeplace immediately after the condition is evaluated then the condition and actionmay access di�erent data. There are sometimes also mechanisms available toallow information which is retrieved by the condition to be passed on directlyto the action. The Binding Model can be:Instance, in which case particular instances associated with an event can bereferred to by the condition/action, e.g. a window close event couldestablish a binding for the variable Window.Set, in which case the accumulation of instances associated with events of agiven type could be stored in a collection referred to by the rule con-dition/action. For example, tuple updates for a given relation could beaccumulated to establish a binding for the variable Updated-People. Notethat Set binding can only occur where the Transition Granularity isSet.Prior, in which case the value of an instance or collection before an updateoperation can be explicitly accessed in a condition.The Constraints associated with the execution model relate in particularto time constrained applications [5]. These indicate if it is possible to suggestto the system the Time within which a rule must be processed to completion,and also some Alternative to the standard rule action which is to be carriedout if it proves to be impossible to satisfy the time constraint.The Scheduling dimension indicates what is to happen if multiple rulesare triggered at the same time { either every rule must be �red (All Fired) oronly some of the activated rules are processed to completion (Some Fired).The actual semantics may be complex. For example, in the case of Starburst[25] a rule may be triggered by some update event which is then subsequentlyundone by another update, and thus the action of the rule will not be executed,even though Starburst operates an All Fired strategy. Where only some ofthe triggered rules are �red, it is possible that only the �rst is �red (chosen atrandom, or using a priority scheme), or that rules are �red until one fails [10].

A rule is selected from a collection of simultaneously �red rules for executionusing a Prioritymechanism. Rules can be placed in order using aNumericalscheme in which each rule is given an absolute value which is its priority [22],or by indicating the Relative priorities of rules, by stating explicitly that agiven rule must be �red before another when triggered at the same time [1].2.5 ManagementThe above dimensions of rule functionality relate principally to the run-timebehaviour of rules. This section considers the facilities provided by the systemfor managing rules { speci�cally what operations can be applied to rules, andhow rules are themselves represented.Besides creation and deletion, which are taken to be mandatory, the follow-ing Operations can be supported on rules:Activate, which enables a deactivated rule to respond to events.Deactivate, which prevents a rule from being triggered { a rule will not re-spond to events while deactivated.Rules themselves are normally expressed using a database ProgrammingLanguage [15], an Extended Query Language [25, 22], or sets of Objects[5, 10] in an object-oriented database. These categories are not exclusive. Forexample, it is possible for an extended query language facility in an object-oriented database to arrange for rules to be stored as objects.Another key issue relating to the de�nition and management of rules isthe level of Adaptability supported. In some systems it is only possible tochange the rules associated with an application by recompiling the applicationcode, and thus the rules can only be modi�ed at Compile Time. Otherssupport more dynamic Run Time rule modi�cation, including the ability ofrule actions to modify the rule base. Clearly there is a sliding scale of degrees ofAdaptability { in the context of dimensions, any system which allows rules tobe created after the database has been populated can be considered to supportRun Time adaptability.There is an extent to which the Data Model with which an active rulesystem is associated is independent of the other dimensions of rule systemfunctionality. However the data model does have a signi�cant in uence on thenature of the resulting system, and is thus included as a dimension.3 Systems and DimensionsThe previous section has introduced the dimensions of active rule behaviour.This section shows how these dimensions can be used to highlight both thesimilarities and di�erences between existing active rule systems. Where it isnot clear from the papers what a dimension should be, this is indicated byinserting ?? in the table.

3.1 StarburstThe Starburst active rule system is a set-oriented rule system developed for anextensible relational database system [25]. The system has been used to add anumber of features to the underlying database, including integrity constraints[2] and materialised views [3]. The way in which the dimensions are supportedin Starburst is depicted in Table 2.Table 2 { Dimensions in StarburstEvent Type � fPrimitive, Composite gSource � fStructure OperationgLevel � fCollectiongRole 2 fMandatorygCondition Mode � fDeferredgRole 2 fOptionalgAction Mode � fImmediategOptions � fUpdate-Db, Update-Rules, AbortgExecution Transition Granularity 2 fSetgModel Binding Model � fSet, PriorgConstraints � fgScheduling 2 fAll FiredgPriorities 2 fRelativegManagement Operations � fActivate, DeactivategDescription 2 fExtended Query LanguagegAdaptability 2 fRun-TimegData Model 2 fRelationalgThe Starburst rule system derives certain of its characteristics from the re-lational data model with which it is associated { events are raised by structureoperations because user-de�ned operations are not stored in the database di-rectly; the rule system operates on transitions which consist of sets of valuesbecause the relational operations act on sets of tuples; the de�nition and man-agement of rules is related to the de�nition and management of queries, re ect-ing the central role of the query language. The Binding Model in Starburstis slightly unusual, in that the action operates over the bindings established bythe condition, rather than using the set bindings directly. Furthermore, when arule is �red multiple times within a single transaction, the changes it has accessto are those which have taken place since the last �ring of the rule. Withinthese changes, the system considers the net e�ect, e.g. the insertion of a tupleis not considered if this tuple is subsequently deleted within the transaction.The Starburst rule system can be considered to be conservative in its design{ a modest and �xed set of facilities are supported. However, the semantics ofrule execution in Starburst are still quite complex [25], and it could be arguedthat supporting many more facilities would lead to rule sets which are di�cultto understand and maintain.

Table 3 { Dimensions in POSTGRESEvent Type � fPrimitivegSource � fStructure OperationgLevel � fCollectiongRole 2 fMandatorygCondition Mode � fImmediategRole 2 fOptionalgAction Mode � fImmediategOptions � fUpdate-Db, Do Instead, Abort gExecution Transition Granularity 2 fTuplegModel Binding Model � fInstance, PriorgConstraints � fgScheduling 2 fAll FiredgPriorities 2 fgManagement Operations � fgDescription 2 fExtended Query LanguagegAdaptability 2 fRun TimegData Model 2 fExtended Relationalg3.2 POSTGRESThe POSTGRES rule system [22], like Starburst, acts on a data model which isbased upon the relational model, although this has been extended with certainobject-oriented features in the case of POSTGRES [23]. The rule system hasbeen utilised for supporting derived data, integrity checking and authorisation[22]. The way in which the dimensions are supported in POSTGRES is depictedin Table 3.The POSTGRES rule system, like that of Starburst, can be consideredto be quite conservative, although a key distinction is that the POSTGRESrule system is tuple-oriented. Thus, unlike in Starburst, the consequences of anevent being triggered take e�ect immediately, and are not deferred until the endof the transaction. The utility of set and tuple oriented evaluation strategies isconsidered in section 4.3.3 ArielAriel [16], like Starburst and POSTGRES, is an active database system utilisingthe relational data model. However, Ariel is principally a database productionsystem, in that while ECA rules are supported, the event is optional. ThusAriel is based upon a recognise-act cycle which is similar to that supportedby main-memory forward-chaining expert systems, such as OPS5 [12]. Thisapproach has been considered by some authors to impose too high an overheadto be practical for use with large database systems, although recent researchhas sought to overcome the performance problems [21, 16]. The way in whichthe dimensions are supported in Ariel is depicted in Table 4.

Table 4 { Dimensions in ArielEvent Type � fPrimitivegSource � fStructure OperationgLevel � fCollectiongRole 2 fOptionalgCondition Mode � fImmediate, DeferredgRole 2 fOptionalgAction Mode � fImmediategOptions � fUpdate-DbgExecution Transition Granularity 2 fSetgModel Binding Model � fInstance, PriorgConstraints � fgScheduling 2 fSome FiredgPriorities 2 fNumericalgManagement Operations � f??gDescription 2 fExtended Query LanguagegAdaptability 2 fCompile TimegData Model 2 fRelationalgThe crucial features of the dimensions in Ariel are the optionality of theevent, and the nature of the Mode and Scheduling dimensions. The Modeof a rule condition is normally Immediate, but can be Deferred by enclosinga sequence of operations in a block { the entire contents of a block are evaluatedbefore the next cycle of the recognise-act loop. As in main-memory productionsystems, a single rule is considered for �ring each time round the recognise-actloop, which leads to some rules being triggered but never �red.3.4 SAMOSSAMOS is an acive rule system based upon an object-oriented data model[14, 13], which supports the dimensions as described in Table 5. At time ofwriting, not all of SAMOS has been implemented.Noteworthy features of SAMOS include an event language in which com-posite events can be constructed using the operations disjunction, conjunction,sequence and negation (which occur when a given event does not happen duringa given time interval). Further, the event *E is raised once when the event Eoccurs one or more times in a given time interval, and the event TIMES(n,E)is raised when the event E has occurred n times during a given time interval.As well as supporting Clock events, composite events can be speci�ed tohave taken place within a given time interval. Clock events can be describedin terms of absolute, periodic and relative points in time. Events can also beparameterised [13].A rule can be de�ned either as a property of a class or as an independententity. The former, known as class-internal rules, can be associated with theencapsulated structure of a class. Rules de�ned independently of classes are

Table 5 { Dimensions in SAMOSEvent Type � fPrimitive, CompositegSource � fStructure Operation, Behaviour Invocation,External, Clock, TransactiongLevel � fInstance, CollectiongRole 2 fMandatorygCondition Mode � fImmediate, Deferred, DetachedgRole 2 fOptionalgAction Mode � fImmediate, Deferred, Detached IndependentgOptions � fUpdate-Db, Inform, Abort TransactiongExecution Transition Granularity 2 fTuplegModel Binding Model � fInstancegConstraints � fgScheduling 2 fAll FiredgPriorities 2 fRelativegManagement Operations � fActivate, DeactivategDescription 2 fExtended Query LanguagegAdaptability 2 fCompile-TimegData Model 2 fObject-Orientedgknown as class-external, and cannot be associated with operations on encapsu-lated structure.3.5 HiPACHiPAC [5] is a prototype rule system for the PROBE object-oriented datamodel, in which rules are supported as �rst-class objects. Table 6 shows thedimensions supported by HiPAC:In HiPAC, Clock events can be de�ned which are absolute, relative or pe-riodic. Operations supported for constructing Composite events include dis-junction, sequence and closure (the event closure of an event E is signaled afterthe event E has been signaled one or more times in a transaction).The HiPAC execution model is supported using nested transactions, inwhich multiple rules may be executed in parallel with di�erent levels of nesting[6].3.6 EXACTEXACT [9, 7], an EXtensible ACTive rule manager, enhances the object-oriented database system ADAM [19] with active capabilities. The main ra-tionale behind this system is to provide support for rules as normal databaseobjects, and to enable smooth evolution of the functionality of the rule system.Such evolution implies the introduction of new features to the rule manager,as well as rede�nition or tuning of characteristics already provided by the sys-tem. However, no drastic changes should be involved { the basic model should

Table 6 { Dimensions in HiPACEvent Type � fPrimitive, CompositegSource � fStructure Operation, External,Clock, TransactiongLevel � fInstance, CollectiongRole 2 fMandatorygCondition Mode � fImmediate, Deferred,Detached Dependent, Detached IndependentgRole 2 fOptionalgAction Mode � fImmediate, Deferred,Detached Dependent, Detached IndependentgOptions � fUpdate-Db, Update-Rules, Inform,Abort gExecution Model Transition Granularity 2 fTuple, SetgBinding Model 2 fInstance, Set, PriorgConstraints � fTiming, AlternativesgScheduling 2 fAll FiredgPriorities 2 fRelativegManagement Operations � fActivate, DeactivategDescription 2 fObjectsgAdaptability 2 fRun TimegData Model 2 fObject-Orientedgbe retained, but extensions made to the core to cater for new requirements.Therefore, the dimensions given in Table 7 below are those provided by thecurrent system, and can be enlarged or customised by the user to ful�l specialneeds.4 Applications and DimensionsThis section outlines how the dimensions introduced in the previous sectioncan also be used to classify applications, thereby answering the question Whichdimensions are necessary for which applications?. The use of dimensions whenanswering the question also helps to highlight the key requirements of rulesystems for speci�c applications.In the case of dimensions which can take on multiple values, there is thequestion whether any of the values in the set can be used or all are required.This is represented in the following tables by using � or 2 to indicate that anyof the stated values will do, and = to indicate that all must be supported. In thecase where � is used, it may be that system support for several of the optionslisted would improve the exibility or performance of the resulting system.

Table 7 { Dimensions in EXACTEvent Type � fPrimitive, CompositegSource � fStructure Operation, Behaviour Invocation,Transaction, ClockgLevel � fInstance,CollectiongRole 2 fMandatorygCondition Mode � fImmediategRole 2 fMandatory gAction Mode � fImmediate gOptions � fUpdate-Db, Update-Rules,Inform, Abort TransactiongExecution Transition Granularity 2 fTuplegModel Binding Model � fInstance, PriorgConstraints � f gScheduling 2 fSome FiredgPriorities 2 fRelativegManagement Operations � fActivate, DeactivategDescription 2 fObjectsgAdaptability 2 fRun TimegData Model 2 fObject-Orientedg4.1 Composite ObjectsRule systems have been used widely to implement modelling constructs whichare not directly supported by a given data model. This section considers sup-port for composite objects using active rules, in which the run-time conse-quences of the existence of a part-of hierarchy are supported using ECA-rules[20].The model for composite objects to be supported is that of [17], in which acomposite part can reference its component parts using references which maybe:1. Exclusive and dependent,2. Exclusive and independent,3. Shared and dependent, or4. Shared and independent.To give a avour of these semantics, consider the case where the engine ofa car is referenced using an exclusive and dependent reference. The engine isreferenced by only that car, and when the car is deleted from the database,then so is the engine. If the reference was shared and independent, then theengine could be referenced by any number of cars, the deletion of which wouldnot result in deletion of the engine.

The presence of such additional reference semantics imposes some con-straints on legal networks of database objects. Certain update operations mustbe forbidden from taking place, and others must be extended with additionalfunctionalities. For example, in the exclusive-dependent case above, the sys-tem must forbid an engine from being attached to multiple car objects, andthe deletion process must be extended to delete the engine whenever a car isdeleted.Composite objects seem to be most naturally supported by the immediateexecution of rules on the detection of events which a�ect the part-of hierarchy.To defer the execution of such rules would be to partition the implementationof primitive operations on composite objects, so that part of an update occursimmediately, and the consequences of the update are addressed at a later date.This would be likely to be counter-intuitive to users of such a composite objectscheme, and could easily lead to incorrect assumptions being made about thestate of a database in the period after an update has been executed, but beforeits consequences have been worked out. Thus the following dimensions can beconsidered appropriate for supporting composite objects using active rules:Table 8 { Dimensions for Composite ObjectsEvent Type � fPrimitivegSource � fStructure OperationgLevel � fCollectiongRole 2 fMandatorygCondition Mode � fImmediategRole 2 fOptionalgAction Mode � fImmediategOptions � fUpdate-Db, AbortgExecution Model Transition Granularity 2 fTuplegBinding Model � fInstancegConstraints � fgScheduling 2 fAll FiredgPriorities 2 fgManagement Operations � fgDescription 2 fgAdaptability 2 fRun TimegData Model � fObject-OrientedgWhere a dimension is left empty, there is no particular requirement imposedby the application { for example, the composite objects application does notseem to require a particular priority mechanism. The fact that the ConditionisOptional should not be taken to mean that the rule system need not supportconditions, but rather that a rule system should optionally support conditionsif it is to be appropriate for supporting composite objects.

4.2 Integrity ConstraintsThere is no model-independent notion of integrity constraint; most proposalsfor or implementations of them are built on the relational model, although[8] considers constraints in an object-oriented model based upon an approachdeveloped by Morgenstern [18] called constraint equations. Hence constraintsin the relational model are considered as the paradigm example. Constraints inthe sort of object-oriented models intended for design databases may be more exible and expressive, but do not as yet �t into a descriptive framework ascomprehensive as the relational one.There are a variety of integrity constraints de�ned over the relational model,as described in (for example) [24], [4]:key constraints: These specify that a group of attributes forms a key for arelation, that is, they may not have multiple or null occurrences. Theycan be violated by insertions or modi�cations but not by deletions.domain constraints: These require that the value of a speci�ed �eld be ofa speci�ed type or lie within a speci�ed range. They subsume non-nullconstraints, which prevent an attribute taking on a null value, which isparticularly important for keys.inclusion dependencies: These require one or more columns of a relation tobe included in another relation. The most important category of these isreferential integrity constraints which require part of a key in one relationto be the key of another relation. Enforcing these may require cascadedrule execution.aggregate dependencies: These restrict the allowable values of aggregatefunctions on a relation. They may require that the condition computeover the entire relation rather than only the modi�ed tuples.functional dependencies: These require that a \result" attribute of a rela-tion should be uniquely determined by \argument" attributes, and thusonly need to be checked on insertions or modi�cations; deletions cannotviolate them.more general dependencies: These include multivalued dependencies andjoin dependencies. They subsume some of the other constraints but addno new requirements to an active rule support mechanism except forincreasing the complexity of condition checking.In the framework of this model, almost all proposals for database integrityenforcement require rule mechanisms lying close to the same point in the clas-si�cation space, as detailed in the following table.Constraint rules are triggered by structure operations: insertions, deletionsor modi�cations of tuples. The Role of the events is invariably Mandatory;rules can only be triggered in response to such operations. The Level of events

Table 9 { Dimensions for Integrity ConstraintsEvent Type � fPrimitivegSource � fStructure OperationgLevel � fCollectiongRole 2 fMandatorygCondition Mode � fImmediate, DeferredgRole 2 fMandatorygAction Mode � fImmediategOptions = fUpdate-Db, Abort, Do Instead gExecution Transition Granularity � fTuple, SetgModel Binding Model � fInstance, Set, PriorgConstraints � fgScheduling 2 fSomeFiredgPriorities 2 fNumerical, RelativegManagement Operations � fActivate, DeactivategDescription 2 fExtended Query LanguagegAdaptability 2 fRun TimegData Model � fExtended Relationalgis Collection; all tuples in a relation are treated alike by the event mechanism.Composite events will rarely be required.TheMode of the condition that checks one of the above constraints will gen-erally have to be Deferred to the end of the transaction (as in Ullman's QBEexample), although very simple constraints (like domain constraints) could bechecked immediately. The Role of the condition is Mandatory; no violationcan be detected without at least an expression evaluation taking place.The Mode of actions will usually be Immediate. Since constraint vio-lations should be resolved within the transaction that creates them, the De-tached modes are semantically ruled out.The Transition Granularity of an integrity support mechanism could beeither Tuple or Set depending on the data manipulation language and thespeci�c type of constraint. Similarly either Instance or Set binding modelscould be appropriate. Prior binding may also be needed e.g for a constraintthat the value of an attribute (like a sequentially allocated accession number fora library) may not decrease. Timeout Constraints are irrelevant to integrity.Support for con ict resolution implies the ability to `untrigger' a rule. If asingle proposed modi�cation violates several constraints and accordingly trig-gers several rules, it is unlikely that all their actions will need to be executed (anupdate only need be prevented once). This suggests a Some Fired schedulingpolicy with some sort of Priority mechanism.The Management of rules for integrity constraints can be quite simplycompared with other applications of active rules; creation of rules at arbitrarypoints during execution will not generally be needed. Creation of rules may berequired independently of the de�nition of the database schemas although suchan option has complications associated with it { how does the system guarantee

that the current state of the database satis�es the constraints being inserted?4.3 Derived dataThe term derived data can be de�ned as data which is obtained from otherdata (i.e. the derivers) through calculations, but which looks as if it is stored.Derived data has been used to support multiple views, capture data semanticsor hide database evolution. Recently some authors have proposed active rulesas a mechanism for supporting derived data [11, 3]. Active rules provide ameans to express how derived data is obtained from its derivers. In [11] itis claimed that a data-driven rather than an event-driven approach is moreappropriate for expressing the derivation relationship. However, this sectionfocuses on the requirements posed for rule management regardless of whethera data-driven or event-driven approach is used.A �rst issue is whether the derived data is obtained on demand or is materi-alised (i.e. stored) and updated when any of its derivers is modi�ed. The lattercan be motivated by e�ciency considerations due to having many retrieval op-erations and few updates. If derived data is stored, the question is when itshould be updated relative to a update to its deriver. The answer can in uencethe action mode associated with the corresponding rules. The options are:� the derived data is updated immediately after the modi�cation of thederiver and within the same transaction. This can be supported by animmediate mode. This option always ensures a database state consistentwith the derivation relationship.� the update of the derived data is postponed. Two di�erent action modescan be used here, these being:{ deferred mode: the derived data is calculated once at the end of thetransaction regardless of the number of updates in its derivers.{ detached dependent mode: the update is performed in a di�erenttransaction.Another requirement is the need for a priority mechanismto avoid non-deterministicresults in case more than one derivation rule is available [11].Finally, composite events can be utilised here, as re-calculation of the ma-terialised derived data can be triggered by updates on any of the derivers.5 ConclusionsResearch into active databases has proceeded along similar lines to researchinto object-oriented databases { there has been considerable experimentation,but little work on standardisation or theory. In the early stages of researchinto an area this situation need not be seen as a major drawback, in that suchresearch does lead to exploration of alternative approaches driven by the needsof di�erent applications. However, there is also a need to be able to compare

Table 10 { Dimensions for Derived DataEvent Type � fPrimitive, CompositegSource � fStructure OperationgLevel � fCollectiongRole 2 fMandatory, OptionalgCondition Mode � fImmediategRole 2 fOptionalgAction Mode � fImmediate, Deferred, Detached DependentgOptions � fUpdate-DbgExecution Transition Granularity 2 fTuplegModel Binding Model � fInstance, Set, PriorgConstraints � fNonegScheduling 2 fOnly One FiredgPriorities 2 fNumerical, RelativegManagement Operations � fgDescription 2 fgAdaptability 2 fRun-TimegData Model 2 fObject-Oriented, Deductivegand contrast both active rule systems and the applications which it is suggestedthey should be able to support. This paper has presented a framework withinwhich di�erent systems and applications can be compared by identifying anumber of dimensions which highlight principal areas of overlap or di�erence.This process indicates that major proposals di�er in their support for suchdimensions, and that di�erent applications have di�erent requirements in termsof such dimensions. The framework should thus prove useful both for designersand users of active rule systems in deciding which facilities they should supportor are likely to need.AcknowledgementsWe are pleased to acknowledge the support of the UKScience and Engineering Research Council (grant GR/H43847) and the Euro-pean Community Human Capital and Mobility (ACT-NET) programme in thefunding of this research. We are also grateful to Alex Buchmann, Opher Etzion,Stella Gatziu and Jennifer Widom for their comments on how the dimensionsrelate to their speci�c systems/interests.References[1] R. Agrawal, R. Cochrane, and B. Lindsay. On maintaining priorities in a produc-tion rule system. In R. Camps G.M. Lohman, A. Sernadis, editor, Proceedingsof 17th VLDB, pages 479{488. Morgan-Kaufmann, 1991. ISBN 3-540-50345-5,ISBN 0-387-50345-5.[2] S. Ceri and J. Widom. Deriving production rules for constraint maintenence. InProceedings of 16th VLDB, pages 566{577. Morgan-Kaufmann, 1990.[3] S. Ceri and J. Widom. Deriving production rules for incremental view main-tenance. In R. Camps G.M. Lohman, A. Sernadis, editor, Proceedings of 17th

VLDB, pages 577{589. Morgan-Kaufmann, 1991. ISBN 3-540-50345-5, ISBN0-387-50345-5.[4] C.J. Date. Introduction to Database Systems, 5th edition. Addison-Wesley, 1990.[5] U. Dayal, A.P. Buchmann, and D.R. McCarthy. Rules are Objects Too. InK.R. Dittrich, editor, Proceedings of the 2nd International Workshop on Object-Oriented Databases, LNCS 334, pages 129{143. Springer-Verlag, 1988. ISBN3-540-50345-5, ISBN 0-387-50345-5.[6] U. Dayal, M. Hsu, and R. Landin. Organising long-running activities with trig-gers and transactions. In SIGMOD Conference, pages 204{214. ACM, 1990.[7] O. Diaz and A. Jaime. EXACT: an EXtensible approach to ACTive object-oriented databases. Submitted for publication, 1993.[8] Oscar Diaz. Deriving Active Rules for Constraint Maintenance in an Object-Oriented Database. In A M Tjoa and I Ramos, editors, Proc. Database andExpert Systems Applications (DEXA), pages 332{337. Springer-Verlag, 1992.[9] Oscar Diaz and Norman W. Paton. Sharing Behaviour in an Object-OrientedDatabase Using a Rule-Based Mechanism. In M.S. Jackson and A.E. Robinson,editors, Aspects of Databases: The Proceedings of the Ninth British NationalConference on Databases, pages 17{37, Wolverhampton, July 1991. Butterworth-Heinemann Ltd.[10] Oscar Diaz, Norman W. Paton, and Peter M.D. Gray. Rule Management inObject-Oriented Databases: A Uniform Approach. In R. Camps G.M. Lohman,A. Sernadis, editor, Proceedings of 17th VLDB, pages 317{326. Morgan-Kaufmann, 1991.[11] Opher Etzion. PARDES -a data-driven oriented active database model. SIG-MOD RECORD, 22(1):7{14, 1993.[12] C.L. Forgy. Rete: A fast algorithm for the many pattern/many object patternmatch problem. Arti�cial Intelligence, 19:17{37, 1982.[13] S. Gatziu and K.R. Dittrich. Samos: an active object-oriented database system.IEEE Quartely Bulletin on Data Engineering, January 1993.[14] S. Gatziu, A. Geppert, and K.R. Dittrich. Integrating active concepts into anobject-oriented database system. In Proc. of the 3rd Int. Workshop on DatabaseProgramming Languages, pages 399{415, August 1991.[15] N.H. Gehani, H.V. Jagadish, and O. Shmueli. Event speci�cation in an object-oriented database. In Proceedings of SIGMOD, pages 81{90. ACM Press, 1992.[16] E.N. Hanson. Rule Execution Testing and Action Execution in Ariel. In Pro-ceedings of SIGMOD, pages 49{58. ACM, 1992.[17] Won Kim, Elisa Bertino, and Jorge F. Garza. Composite Objects Revisited. InJames Cli�ord, Bruce Lindsay, and David Maier, editors, Proceedings of the 1989ACM SIGMOD International Conference on the Management of Data, pages337{347, Portland,OR, June 1989. ACM Press.[18] M. Morgenstern. Constraint equations: declarative expression of constraints withautomatic enforcement. In Proc. VLDB. Morgan-Kaufmann, 1984.[19] Norman W. Paton. ADAM: An Object-Oriented Database System Implementedin Prolog. In M. H. Williams, editor, Proceedings of the Seventh British NationalConference on Databases (BNCOD 7), pages 147{161, Edinburgh, July 1989.Cambridge University Press.

[20] N.W. Paton, O. Diaz, and M.L. Barja. Combining active rules and metaclassesfor enhanced extensibility in object-oriented databases. Data and KnowledgeEngineering, 10:45{63, 1993.[21] T. Sellis, C-C Lin, and L. Raschild. Data intensive production systems: Thedips approach. SIGMOD RECORD, 18(3):52{53, September 1989.[22] M. Stonebraker, A.J. Jhingran, J. Goh, and S. Potamianos. On Rules, Proce-dures, Caching and Views in Data Base Systems. In Proceedings of SIGMOD,pages 281{290. ACM Press, 1990.[23] Michael Stonebraker and Greg Kemnitz. The POSTGRES Next-generationDatabase Management System. Communications of the ACM, 34(10):78{92,October 1991.[24] J.D. Ullman. Principles of Database Systems, 2nd edition. Pitman, 1982.[25] J. Widom and S.J. Finkelstein. Set Oriented Production Rules in RelationalDatabase Systems. In Proceedings of SIGMOD, pages 259{270. ACM Press,1990.