Active Database Systems - Université libre de...

Active Database SystemsNORMAN W. PATON

University of Manchester

AND

OSCAR DIAZ

University of the Basque Country

Active database systems support mechanisms that enable them to respondautomatically to events that are taking place either inside or outside the databasesystem itself. Considerable effort has been directed towards improvingunderstanding of such systems in recent years, and many different proposals havebeen made and applications suggested. This high level of activity has not yielded asingle agreed-upon standard approach to the integration of active functionalitywith conventional database systems, but has led to improved understanding ofactive behavior description languages, execution models, and architectures. Thissurvey presents the fundamental characteristics of active database systems,describes a collection of representative systems within a common framework,considers the consequences for implementations of certain design decisions, anddiscusses tools for developing active applications.

Categories and Subject Descriptors: H.2.3 [Database Management]: Languages

General Terms: Languages

Additional Key Words and Phrases: Active databases, events, object-orienteddatabases, relational databases

1. INTRODUCTION

Traditionally, database systems havebeen viewed as repositories that storethe information required by an applica-tion, and that are accessed either byuser programs or through interactiveinterfaces. In such a context, a range ofdifferent tools and systems are used to-gether to support the requirements of

the application. However, database sys-tems are beginning to be applied to arange of domains associated with highlycomplex information processing, evermore substantial quantities of data, orhighly stringent performance require-ments, in which the conventional multi-component environment has proved tobe unsatisfactory. This has resulted in a

We are pleased to acknowledge the support of the European Union Human Capital and MobilityNetwork ACT-NET, the UK Engineering and Physical Sciences Research Council (Grant GR/H43847)and the Basque Government for funding active database research involving the authors.Authors’ addresses: N. W. Paton, Department of Computer Science, University of Manchester, OxfordRoad, Manchester M13 9PL, UK; e-mail: ^[email protected]&; O. Dıaz, Departamento de Lenguajes ySistemas Informaticos, University of the Basque Country, San Sebastian, Spain; e-mail:^[email protected]&.Permission to make digital / hard copy of part or all of this work for personal or classroom use is grantedwithout fee provided that the copies are not made or distributed for profit or commercial advantage, thecopyright notice, the title of the publication, and its date appear, and notice is given that copying is bypermission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute tolists, requires prior specific permission and / or a fee.© 1999 ACM 0360-0300/99/0300–0063 $5.00

ACM Computing Surveys, Vol. 31, No. 1, March 1999

trend in database research towardsmore of the functionality required by anapplication being supported within thedatabase system itself, giving rise todatabase systems with more compre-hensive facilities for modeling both thestructural and the behavioral aspects ofan application. Among the fields thathave received attention in recent yearswith a view to enhancing the behavioralfacilities of database systems are data-base programming, temporal databases,spatial databases, multimedia data-bases, deductive databases, and activedatabases. This survey focuses upon thelast mentioned.

Traditional database managementsystems (DBMSs) are passive in thesense that commands are executed bythe database (e.g., query, update, de-lete) as and when requested by the useror application program. However, somesituations cannot be effectively modeledby this pattern. As an example, considera railway database where data arestored about trains, timetables, seats,fares, and so on, which is accessed bydifferent terminals. In some circum-stances (e.g., public holidays, culturalevents) it may be beneficial to add addi-tional coaches to specific trains if thenumber of spare seats a month in ad-vance is below a threshold value. Twooptions are available to the administra-tor of a passive database system who isseeking to support this requirement.One is to add the additional monitoringfunctionality to all booking programs sothat the preceding situation is checkedeach time a seat is sold. However, thisapproach leads to the semantics of themonitoring task being distributed, repli-cated, and hidden among different ap-plication programs. The second ap-proach relies on a polling mechanismthat periodically checks the number ofseats available. Unlike the first ap-proach, here the semantics of the appli-cation is represented in a single place,but the difficulty stems from ascertain-ing the most appropriate polling fre-quency. If too high, there is a cost pen-alty. If too low, the reaction may be too

late (e.g., the coach is added, but onlyafter several customers have beenturned away).

Active databases support the preced-ing application by moving the reactivebehavior from the application (or pollingmechanism) into the DBMS. Active da-tabases are thus able to monitor andreact to specific circumstances of rele-vance to an application. The reactivesemantics is both centralized and han-dled in a timely manner. An active da-tabase system must provide a knowl-edge model (i.e., a descriptionmechanism) and an execution model(i.e., a runtime strategy) for supportingthis reactive behavior.

A common approach for the knowl-edge model uses rules that have up tothree components: an event, a condition,and an action. The event part of a ruledescribes a happening to which the rulemay be able to respond. The conditionpart of the rule examines the context inwhich the event has taken place. Theaction describes the task to be carriedout by the rule if the relevant event hastaken place and the condition has eval-uated to true.

Most active database systems supportrules with all three of the componentsdescribed; such a rule is known as anevent-condition-action or ECA-rule. Insome proposals the event or the condi-tion may be either missing or implicit. Ifno event is given, then the resultingrule is a condition-action rule, or pro-duction rule. If no condition is given,then the resulting rule is an event-ac-tion rule.

At first glance, the introduction ofactive rules to a database system mayseem like a straightforward task, but inpractice proposals have been made thatsupport widely different functionalities.Among the issues that distinguish pro-posals are the expressiveness of theevent language, the scope of access todatabase states from the condition andaction, and the timing of condition andaction evaluation relative to the event.The functionality of a specific systemwill be influenced by a number of fac-

64 • N. W. Paton and O. Dıaz


tors, including the nature of the passivedata model that is being extended, andthe categories of application to be sup-ported.

1.1 Active Database Applications

As mentioned previously, database re-search often aims to extend the range offacilities within the database system forrepresenting application concepts.Hence, additional capabilities arelargely dependent on the designated ap-plications. In the case of active rules,the following categories of applicationcan be distinguished.

Database System Extensions. Activerules can be used as a primitive mecha-nism for supporting the implementationof other parts of a database system. Forexample, ECA rules have been used tosupport integrity constraints [Ceri et al.1990; Diaz 1992], materialized views[Stonebraker et al. 1990; Widom et al.1991], derived data [Etzion 1993], coor-dination of distributed computation[Dayal et al. 1990; Ceri and Widom1993], transaction models [Geppert andDittrich 1994], advanced data modelingconstructs [Paton et al. 1993], and auto-matic screen updating in the context ofdatabase change [Diaz et al. 1994; Pa-ton et al. 1996].

Such extensions to core databasefunctionality are usually supported bydefining a high-level syntax for the ex-tended functionality, plus a mappingonto sets of active rules. For example,Ceri et al. [1990] present a constraintlanguage for implementation using ac-tive rules, illustrated using an applica-tion that models a power distributionsystem. In this constraint language, therestriction that no wire has a voltagethat is greater than that of its type isexpressed thus:

wire:voltage . any(select max-voltage

from wire-typewhere type 5 wire.type)

This constraint can be violated by arange of different update operations

(e.g., a new wire is created of an exist-ing wire-type , the max-voltage of awire-type is updated, etc.) that canthen be monitored by a set of system-generated active rules. For example, tocheck for violation of the constraint oninsertion of a new wire , the followingactive rule could be used.

on insert into wireif insert.voltage . any(select max-voltage

from wire-typewhere type 5 insert.type)

do ^action &

Here, the on clause defines the event(the insert of a tuple into the wirerelation), the if clause expresses thecondition, and the do clause specifiesthe action. Information about the eventis referred to in the condition by access-ing the voltage and type of the newlyinserted tuple using the reserved wordinsert . In this example, the actioncould be defined in different ways—theupdate operation could be blocked byaborting the transaction, the constraintcould be repaired by changing the volt-age of the inserted wire, and so on.

Closed Database Applications. Thiscategory of application involves the useof active functionality to describe someof the behavior to be manifested by asoftware system without reference toexternal devices or systems. For exam-ple, rules might be used to describerepair actions in a modeling database,to monitor sales in a stock control data-base, to propagate load calculations inan architectural design database, or toanticipate market activity in a portfoliomanagement database. In these appli-cations there may not be any mappingfrom a higher-level description onto theactive rule language—ECA rules areused directly to support the semanticsof the application. For example, in aportfolio management database a rulecould be written that deletes any stock-holders whose portfolios have value 0,while at the same time recording theseholders in a distinct relation:

Active Database Systems • 65


on update to value of Holderif new.value 5 0do begin

delete from Holder wherereg# 5 update.reg#;

insert into VoidHoldervalues (update.reg#, update.

name, update.address, to-day)

end

In this example, the event monitorsupdates to the value attribute of theHolder relation. The condition thenchecks the new element that has beenassigned to the value attribute to see ifit is 0. If so, then the action is executed,which deletes the updated tuple fromthe Holder relation, and then insertsinformation from the deleted tuple intothe VoidHolder relation. It is worthnoting that both the condition and theaction of this rule require access to in-formation on the update that triggeredthe rule.

Open Database Applications. In thiscategory of application, a database isused in conjunction with monitoring de-vices to record and respond to situationsoutside the database. For example,rules could be used in command andcontrol applications to respond to evolv-ing battlefield scenarios [Dayal et al.1988], in medical applications to warnphysicians of changes in a patient’s con-dition [Blue et al. 1988], in transportapplications to anticipate traffic hold-ups, and in air-traffic control to detectpotentially dangerous aircraft move-ments [Naqvi and Ibraham 1994]. Forexample, in an aircraft monitoring data-base, the following rule adapted fromNaqvi and Ibraham [1994] could informa controller when two aircraft are ap-proaching each other.

on update to pos of aircraftif exists

(select pfrom aircraft Otherwhere distance (Other.pos,new.pos) , 5000 anddistance (Other.pos,old.pos) . 5000)

do ^send message to control-ler &

In this example, the event being mon-itored is the position of an aircraft com-municated to the database from an ex-ternal device, and the action taken is achange to a display that the air trafficcontroller is monitoring. Both the newvalue and the old value for the posaffected by the event are accessed fromwithin the condition.

1.2 Outline of Survey

This survey provides an overview of re-cent research into active database sys-tems. Section 2 introduces an exampleapplication that is used throughout thearticle. Section 3 presents the struc-tural characteristics of active rules, andSection 4 shows how different executionmodels can be used to characterize theruntime interpretation of a set of rules.Section 5 indicates what facilities maybe available for managing rule bases,and Section 6 describes and compares arange of representative active databasesystems within the framework pre-sented in Sections 3 to 5. Section 7indicates what architectural featuresare important for the implementation ofan active database system and Section 8considers the facilities that are usefulfor supporting the development of appli-cations using active functionality. Sec-tion 9 presents some conclusions.

2. EXAMPLE APPLICATION

This section introduces a portfolio man-agement database that is used through-out the article to exemplify the function-ality of active database systems[Chandra and Segev 1994]. In fact, arange of different financial applicationsstand to benefit from the presence ofactive functionality for monitoring fi-nancial transactions, identifying un-usual patterns of activity, enforcing in-tegrity constraints, maintaining deriveddata, generating timely reports, andperforming periodic processing. The rel-



evant entities and relationships are de-picted graphically in Figure 1.

In this example, a Holder is an indi-vidual or organization that owns stocks.Every Holder has a unique registrationnumber, a name, a country , and a totalvalue of stock held. An organizationthat has been floated on the stock mar-ket is represented by the entity typeStock , and has attributes that recordits name, share price , the total numberof shares available, and the uniqueidentification number by which it can bereferenced. The Owns relationship indi-cates that a Holder possesses qtyitems of a particular kind of Stock . Arelational schema for implementing thisdatabase using SQL is presented in Fig-ure 2.

Specific examples of active behaviorthat can be used in this application areintroduced when they are used to illus-trate concepts, rather than presented asa group here. Where rules are presentedin this survey, the syntax used is notthat of any specific active rule system,but rather a notation based upon SQLthat should require minimal explana-tion.

3. KNOWLEDGE MODEL

The knowledge model of an active data-base system indicates what can be saidabout active rules in that system. This

is in contrast to the execution model,which determines how a set of rulesbehaves at runtime, as presented inSection 4. As the knowledge model es-sentially supports the description of ac-tive functionality, the features dealtwith in this section often have a directrepresentation within the syntax of therule language. Rather than using anyparticular rule language to illustratefeatures of the knowledge model, thissection is based around a number ofdimensions of active behavior, which ex-

Figure 2. Relational tables for storing portfolioinformation.

Figure 1. Entity/Relationship diagram for portfolio database.



tend those presented in Paton et al.[1994]. These dimensions essentiallymake explicit the decision space withinwhich the designers of active rule sys-tems work, without endeavoring to pro-vide any formal description of the se-mantics of specific rule systems, a topicthat is dealt with in Section 8.2.

The concepts considered in this sec-tion as dimensions are clearly notnew—the aim is to provide a frameworkfor characterizing active database func-tionality, rather than to introduce newnotions, so the terminology used shouldbe familiar to the readers of papers suchas Dayal et al. [1988], Widom andFinkelstein [1990], and Stonebraker etal. [1990]. The dimensions of rule func-tionality considered in this article arepresented in a tabular form. In the ta-bles, the symbol , is used to indicatethat the particular dimension can takeon more than one of the values given,whereas [ indicates a list of alterna-tives.

The knowledge model of an active ruleis considered to have (up to) three prin-cipal components, an event, a condition,and an action. The dimensions associ-ated with these structural componentsof an active rule are presented in TableI and discussed in the following sec-tions.

3.1 Event

An event is something that happens ata point in time. Specifying an event

therefore involves providing a descrip-tion of the happening that is to be mon-itored. The nature of the descriptionand the way in which the event can bedetected largely depend on the Sourceor generator of the event. Possible alter-natives are:

—structure operation, in which casethe event is raised by an operation onsome piece of structure (e.g., insert atuple, update an attribute, access atuple);

—behavior invocation, in which casethe event is raised by the execution ofsome user-defined operation (e.g., themessage display is sent to an object oftype widget). It is common for eventlanguages to allow events to be raisedbefore or after an operation has beenexecuted;

—transaction, in which case the eventis raised by transaction commands(e.g., abort, commit, begin-transac-tion);

—abstract or user-defined, in whichcase a programming mechanism isused that allows an application pro-gram to signal the occurrence of anevent explicitly (e.g., in response tosome information entered by a user);

—exception, in which case the event israised as a result of some exceptionbeing produced (e.g., an attempt ismade to access some data without ap-propriate authorization);

Table I. Dimensions for the Knowledge Model



—clock, in which case the event israised at some point in time [Dayal etal. 1988; Gatziu and Dittrich 1994].Absolute (e.g., the 13th of November1998 at 15:00), relative (e.g., 10 daysafter the shares are sold), and peri-odic (e.g., the first day of everymonth) time events are reported inthe literature;

—external, in which case the event israised by a happening outside the da-tabase (e.g., the temperature readinggoes above 30 degrees [Dayal et al.1988]).

The Event Granularity of an eventindicates whether an event is definedfor every object in a set (e.g., everyinstance of a class), for given subsets(e.g., all staff members except profes-sors) or for specific members of the set(e.g., to prevent unauthorized access tospecific instances, or to enable the up-date of the specific widget objects thatare presently on screen [Diaz et al.1994]).

The Type of an event can be:

—primitive, in which case the event israised by a single low-level occurrencethat belongs to one of the categoriesdescribed in Source. For example,the event on insert to Owns mon-itors the insertion of new tuples intothe Owns relation.

—composite, in which case the event israised by some combination of primi-tive or composite events using a rangeof operators that constitute the eventalgebra.

The range of event operators variesfrom system to system. The most com-mon are: disjunction—E1orE2 occurswhen either E1 or E2 has occurred; con-junction—E1andE2 happens when bothE1 and E2 have occurred in any order;sequence—seq(E1, E2) occurs when E1occurs before E2; closure—closure E inInt is raised only once the first time E issignaled, regardless of later occurrencesof E in the time interval Int; history—times(n, E) in Int is signaled whenevent E occurs n times during the time

interval Int; not—not E1 in Int detectsthe nonoccurrence of the event E1 in theinterval Int.

As an example of a rule with a com-posite event, the following rule enforcesthe constraint that the qty attribute ofstock is the same as the amount re-corded in the Owns relation.

on update to qty of Holder orupdate to qty of Stock orinsert to Stock ordelete to Stock orinsert to Holder ordelete to Holder

if exists(select p

from Stockwhere qty Þ

(select sum(qty)from Ownswhere Owns.reg# 5 Stock-.reg#)

)do abort

As a further example, to detect whethera stock price has changed during aworking day the event can be used: onupdate to price of Stock in[09:00, 17:00].

Rich event algebras have been pro-posed for a range of systems, includingHiPAC [Dayal et al. 1988], SAMOS[Gatziu and Dittrich 1994], ODE [Ge-hani et al. 1992], and Sentinel [Chakra-varthy et al. 1994]. However, compositeevent handling presents challenges interms of semantics and efficiency thathave yet to be fully addressed.

When detecting composite events,there may be several event occurrences(of the same event type) that could beused to form a composite event. As anexample, consider a composite event CEwhich is the sequence of events EV1and EV2. If two occurrences of eventEV1, first ev1 and later ev19, have al-ready been signaled, and an occurrenceof event EV2 (e.g., ev2) is now pro-duced, there is a question as to whatinstances of CE should be raised. Possi-bilities include sequence(ev1, ev2) or se-quence(ev19, ev2) or sequence(ev1, ev2) øsequence(ev19,ev2). The alternatives are



distinguished using consumption pol-icies. In Chakravarthy et al. [1994]four possible consumption policies areintroduced: a recent context, whichconsiders the most recent set of eventsthat can be used to construct the compo-sition (in the previous example, sequen-ce(ev19, ev2) is detected when ev2 arises,after which ev19 and ev2 are no longerconsidered for the detection of CE); achronicle context, which consumes theevents in chronological order (sequen-ce(ev1, ev2) is signaled when ev2 arises,after which ev1 and ev2 are no longerconsidered for the detection of CE); acontinuous context, which defines asliding window and starts a new compo-sition with each primitive event thattakes place (two sequence events wouldbegin to be constructed when ev1 andev19 arise, and both sequence eventswould be signaled as ev2 is detected);and a cumulative context, which accu-mulates all the primitive events untilthe composite event is finally raised (asequence event is signaled only oncewhen ev2 arises, where the first param-eter of the sequence includes the pa-rameters of all the occurrences of EV1,i.e., ev1 and ev19).1 The rationale foreach context can be found in Chakra-varthy et al. [1994].

The Role of an event indicateswhether events must always be givenfor active rules, or whether the explicitnaming of an event is unnecessary. Ifthe role is optional, then when noevent is specified condition-action rulesare supported, which have significantlydifferent functionality and implementa-tions from event-condition-action (ECA)rules, as described in Section 7.5. If therole is none then events cannot be spec-ified, and all rules are condition-actionrules. If the role is mandatory thenonly ECA-rules are supported.

3.2 Condition

The Role of a condition indicateswhether it must be given. In ECA-rules,the condition is generally optional.When no condition is given for an ECA-rule, or where the role is none, anevent-action rule results. In systems inwhich both the event and the conditionare optional, it is always the case thatat least one is given.

The Context indicates the setting inwhich the condition is evaluated. Thedifferent components of a rule are notevaluated in isolation from the databaseor from each other, and furthermorethey may not be evaluated in quick suc-cession, as described in Section 4. As aresult, the processing of a single rulecan potentially be associated with atleast four different database states:DBT—the database at the start of thecurrent transaction; DBE—the databasewhen the event took place; DBC—thedatabase when the condition is evalu-ated; and DBA—the database when theaction is executed. Active rule systemsmay support facilities within the condi-tion of a rule that allow it to access zeroor more of the states DBT, DBE, andDBC, and may also provide access tobindings associated with the event(BindE). The availability of informationto the different components of a rule isillustrated in Figure 3. In general, theposition is even more complex than thatportrayed in Figure 3, as the state be-fore and after an event has taken placemay be different, and as multiple rules

1 Unlike the continuous context, an event occur-rence does not participate in more than one com-posite computation in the cumulative context.

Figure 3. The context within which a rule isprocessed.



may be triggered and may execute tocompletion during the execution of asingle action. As an example of the util-ity of such information, the followingrule is used to respond to the situationin which the value of the stock held bya Holder drops to 0.

on update to value of Holderif new.value 5 0do âction &

In this rule, information from the event(DBE) is used to identify when thevalue field has been set to 0, so that anappropriate response can be made (e.g.,the Holder is deleted, information onthe Holder is sent to the fund manager,etc.). In other examples in this survey,conditions or actions access event pa-rameters using old to refer to the valuethat a data item held before an eventupdated it, insert to refer to a newlyinserted value, delete to refer to arecently deleted value, and update torefer to attributes of a data item thatwere unaffected by an update event.

3.3 Action

The range of tasks that can be per-formed by an action is specified as itsOptions. Actions may update thestructure of the database or rule set,perform some behavior invocationwithin the database or an externalcall, inform the user or system admin-istrator of some situation, abort atransaction, or take some alternativecourse of action using do-instead[Stonebraker et al. 1990]. As an exam-ple of do-instead, if an attempt wasmade to delete a tuple from the Holderrelation that has a value . 0, thenrather than allow the operation to pro-ceed, the system manager could be in-formed of the attempted operation:

on delete to Holderif delete.value . 0do instead înform system man-

ager &

This is in contrast with the morestandard semantics, in which the tuple

is deleted and the system manager isinformed:

on delete to Holderif delete.value . 0do înform system manager &

The Context of the action is similarto that of the condition, and indicatesthe information that is available to theaction, as illustrated in Figure 3. It issometimes possible for information to bepassed from the condition of a rule to itsaction as DBE or BindC. As an exampleof the utility of context information, thefollowing rule is used to revise the datastored in the value attribute of allHolder tuples that are affected by achange in the price of some Stock .

on update to price of Stockif truedo update Holder

set value 5 value p (new.price/old.price)

where reg# in (select reg#from Owns where stock# 5update.stock#)

In this rule, both the old and the newvalues of the price have to be accessed(DBE), as does the state of the databaseat the time of the update (DBA).

4. EXECUTION MODEL

The execution model specifies how a setof rules is treated at runtime, and ischaracterized by the dimensions pre-sented in Table II. Although the execu-tion model of a rule system is closelyrelated to aspects of the underlyingDBMS (e.g., data model, transactionmanager), there are a number of phasesin rule evaluation, illustrated in Figure4, that transcend considerations thatrelate to specific software environ-ments.

(1) The signaling phase refers to theappearance of an event occurrencecaused by an event source.

(2) The triggering phase takes theevents produced thus far, and trig-gers the corresponding rules. Theassociation of a rule with its event



occurrence forms a rule instantia-tion.

(3) The evaluation phase evaluates thecondition of the triggered rules. Therule conflict set is formed from allrule instantiations whose conditionsare satisfied.

(4) The scheduling phase indicates howthe rule conflict set is processed.

(5) The execution phase carries out theactions of the chosen rule instantia-tions. During action execution otherevents can in turn be signaled thatmay produce cascaded rule firing.

These phases are not necessarily exe-cuted contiguously, but depend on theEvent-condition and Condition-ac-tion coupling modes. The former deter-mines when the condition is evaluatedrelative to the event that triggers therule. The Condition-action couplingmode indicates when the action is to beexecuted relative to the evaluation ofthe condition. The options for couplingmodes most frequently supported are:

—immediate, in which case the condi-tion (action) is evaluated (executed)immediately after the event (condi-tion);

—deferred, in which case the condition(action) is evaluated (executed) withinthe same transaction as the event

(condition) of the rule, but not neces-sarily at the earliest opportunity.Normally, further processing is leftuntil the end of the transaction. How-ever, some authors [Diaz and Jaime1997] have also proposed to have auser-invoked coupling mode wherebythe condition (action) is evaluated (ex-ecuted) at a user-specified time afterthe event (condition) has been sig-naled (evaluated). A similar effect isalso supported by Starburst [Widomand Finkelstein 1990] where userscan invoke rule processing within atransaction by issuing special com-mands: the process rules, processruleset S, and process rule R com-mands invoke rule processing for thewhole triggering rule set, a given sub-set S, or a unique rule R, respec-tively; and

—detached, in which case the condi-tion (action) is evaluated (executed)within a different transaction fromthe event (condition). The execution ofthe action can be dependent upon orindependent of the committing of thetransaction in which the event tookplace or the condition was evaluated.

The nature of the relationship be-tween events and the rules they triggeris partially captured by the transitiongranularity. This indicates whether

Table II. Dimensions for the Execution Model

Figure 4. Principal steps that take place during rule execution.



the relationship between event occur-rences and rule instantiations is 1:1 ormany:1. When the transition granu-larity is tuple, a single event occur-rence triggers a single rule. When thetransition granularity is set, a collec-tion of event occurrences are used to-gether to trigger a rule. For example, ifa rule R with a condition-action cou-pling mode of deferred is monitoringan event E, and occurrences e1, e2, ande3 of E have taken place during a trans-action, then the transition granularityindicates how many instantiations of Rare created by the triggering phase. Ifthe transition granularity is tuple,then a separate instantiations of R iscreated for each of e1, e2, and e3; if thetransition granularity is set, then asingle instantiation of R is created torespond to the set of events {e1, e2, e3}.

Another feature that influences therelationship between events and therules they trigger is the Net effect pol-icy, which indicates whether the neteffect of the event occurrences ratherthan each individual event occurrenceshould be considered. The difference be-tween the two strategies stems fromcases in which several updates on thesame data item can be considered as asingle update: if an instance is updatedand then deleted, the net effect is dele-tion of the original instance; if an in-stance is inserted and then updated, thenet effect is the insertion of the updatedinstance; if an instance is inserted andthen deleted, the net effect is no modifi-cation at all [Hanson 1992].

The question of what happens whenevents are signaled by the evaluation ofthe condition or action of a rule is ad-dressed by the Cycle policy of the exe-cution model. In general, there are twooptions. If the Cycle policy is iterative,then events signaled during conditionand action evaluation are combinedwith those from the original eventsource illustrated in Figure 4, and aresubsequently consumed by rules fromthis single global repository of signaledevents. This means that condition oraction evaluation is never suspended to

allow responses to be made to eventssignaled by those conditions or actions.By contrast, if the Cycle policy is recur-sive, events signaled during conditionand action evaluation cause the condi-tion or action to be suspended, so thatany immediate rules monitoring theevents can be processed at the earliestopportunity. In practice, a recursive cy-cle policy is only likely to be consideredin systems that support immediate ruleprocessing, and some systems support arecursive cycle policy for immediaterules and an iterative cycle policy fordeferred rules.

The Scheduling phase of rule evalu-ation determines what happens whenmultiple rules are triggered at the sametime. The two principal issues are asfollows.

—The selection of the next rule to befired. This topic has received muchattention in the expert system com-munity as it is seen as fundamental tounderstanding and controlling the be-havior of a set of rules [Winston1984]. Indeed, rule order can stronglyinfluence the result and reflects thekind of reasoning followed by the sys-tem. Examples of well-known Dy-namic approaches (referred to as con-flict resolution policies) are those thatprioritize rules based on either therecency of update (i.e., the time ofevent occurrence) or the complexity ofthe condition. The former makes thesystem focus on a line of reasoning,since the most recently modified dataare those associated with the mostrecently fired rule (i.e., the searchspace is traversed depth-first). Thelatter reflects the assumption thatcondition complexity indicates thespecificity of the rule (i.e., the extentto which the rule fits the current sit-uation). However, mechanisms avail-able in active database systems thathave to cope with large quantities ofdata efficiently in a context wheredeterministic behavior is held to behighly desirable tend to support prior-



ity schemes in which rules are associ-ated with a priority statically.

Static priorities are often determinedeither by the system (e.g., based on rulecreation time) or by the user as anattribute of the rule. In the latter case,a rule is selected from a collection ofsimultaneously fired rules for executionusing a Priority mechanism. Rules canbe placed in order using a numericalscheme, in which each rule is given anabsolute value that is its priority[Stonebraker et al. 1990], or by indicat-ing the relative priorities of rules bystating explicitly that a given rule mustbe fired before another when both aretriggered at the same time [Agrawal etal. 1991].

—The number of rules to be fired. Possi-ble options include (1) to fire all ruleinstantiations sequentially; (2) tofire all rule instantiations in paral-lel; (3) to fire all instantiations of aspecific rule before any other rulesare considered, which is known asfiring a rule to saturation; and (4) tofire only one or some rule instantia-tion(s). Which approach is most ap-propriate depends upon the task thatis being supported by the rule. Thefirst alternative is suitable for rulessupporting integrity maintenance: anupdate is successful once all con-straints have been validated. The sec-ond option is described in HiPAC in abid to encourage more efficient ruleprocessing. The third option is mostpopular among expert-system practi-tioners, as it yields more focused in-ference than the other approaches.The fourth option can be of use tosupport derived data—different deri-vation criteria may be available (each

of them supported by a rule), but onlyone is used.

A further aspect to be considered ishow Error handling is supported dur-ing rule firing. Most systems simplyabort the transaction, as this is stan-dard behavior in databases. However,other alternatives may be more conve-nient [Hanson and Widom 1993]: to ig-nore the rule that raised the error andto continue processing other rules; tobacktrack to the state when rule pro-cessing started and either restart ruleprocessing or continue with the transac-tion; to adopt some contingency planthat endeavors to recover from the errorstate, possibly using the exceptionmechanism of the underlying databasesystem.

5. MANAGEMENT

Sections 3 and 4 have, respectively, de-scribed the structural characteristics ofindividual active rules and the runtimeevaluation of sets of such rules. Thissection considers the facilities providedby the system for managing rules, spe-cifically what operations can be appliedto rules, how rules are themselves rep-resented, and programming support forrules. Possible dimensions are shown inTable III.

The Description of rules refers tohow rules themselves are normally ex-pressed using a database program-ming language [Gehani et al. 1992;Buchmann et al. 1995], a query lan-guage [Widom and Finkelstein 1990;Stonebraker et al. 1990], or as objectsin an object-oriented database [Dayal etal. 1988; Diaz et al. 1991]. These catego-ries are not exclusive. For example, it is

Table III. Dimensions for Rule Management



possible for an extended query languagefacility in an object-oriented database toarrange for rules to be stored as objects.

Besides creation and deletion, whichare taken to be mandatory, other Oper-ations commonly found are activate,deactivate, and signal. Activation (de-activation) of rules makes the systemstart (stop) monitoring the rule’s eventor condition. Since rules can persist forlong periods, this mechanism helps thedatabase administrator to temporarilyswitch on (off) some rules without delet-ing them. Among other things, such de-activation mechanisms may be conve-nient for improving efficiency, fordebugging, or for loop prevention (e.g.,by deactivating rules once they havebeen fired). This mechanism may beavailable for individual rules as well asfor rule sets. The latter can help instructuring the rule base, as well asspeeding up rule processing.

The operation Signal is required tosupport abstract events, and is invokedexplicitly by the application to notifythe rule system of external occurrences.

Although all active DBMSs supportcreation and deletion of rules, they candiffer in the level of Adaptability sup-ported. In some systems it is only possi-ble to change the rules associated withan application by recompiling the appli-cation code, and thus the rules can bemodified only at compile time. Otherssupport more dynamic run time rulemodification, including the ability ofrule actions to modify the rule base.Clearly there is a sliding scale of de-grees of Adaptability: in the context ofthe dimensions, any system that allowsrules to be created without recompilingapplication code can be considered tosupport run time adaptability.

There is an extent to which the DataModel with which an active rule systemis associated is independent of the otherdimensions of rule system functionality.However, the data model is likely tosignificantly influence the designers ofan active rule system, and is thus in-cluded as a dimension.

Programmer Support is of para-

mount importance if active rules are tobe adopted as a mainstream implemen-tation technology in business environ-ments. Important facilities for support-ing the developers of rule bases includethe ability to query the rule base and totrace or in some other way monitor rulesystem behavior. Support for applica-tion development is discussed morefully in Section 8.

6. ACTIVE RULE SYSTEMS

The previous three sections have intro-duced many of the principal features ofactive database systems, and togetherconstitute a framework within whichactive functionality can be described. Inthis section the framework is applied tothe presentation of a range of promi-nent proposals for active database sys-tems, thereby highlighting importantsimilarities and differences.

6.1 Relational Systems

The inclusion of active behavior model-ing facilities in relational databases isnot particularly new, and most commer-cial systems include triggering mecha-nisms. In addition, a number of re-search prototypes have been developedthat seek to provide more comprehen-sive support for active rules. Proposalsfor including active behavior in rela-tional systems often have a range ofcommon characteristics, which stemfrom the nature of the underlying pas-sive database system. For example,rules are generally triggered by system-defined operations on the structure ofthe database (e.g., insert a tuple, modifya tuple), because until recently, rela-tional systems have rarely supporteduser-defined operations. It can be antic-ipated that future active rule systemsfor relational databases will be ex-tended so that primitive events includethe execution of stored procedures, butsuch functionality is not supported bythe systems reviewed here. Further-more, because relational languages suchas SQL provide facilities for expressing



conditions and for performing updates,the rule description language is often anextension of the query language. In gen-eral, active mechanisms proposed forrelational databases support only one ora limited range of coupling modes, andhave limited support for compositeevent detection. This, however, is notbecause of any fundamental restrictionsimposed by the relational model, andextended proposals may emerge in duecourse.

Table IV indicates how four proposals

for the inclusion of active behavior intorelational systems, namely Starburst,POSTGRES, Ariel, and SQL-3, fit intothe framework introduced in the previ-ous three sections. The following sub-sections describe distinctive features ofthese proposals. Other examples of ac-tive extensions to systems with largelyrelational data models are presented inKotz et al. [1988], Kiernan et al. [1990],Zaniolo [1994], Harrison and Dietrich[1994], Bayer and Jonker [1994], andReddi et al. [1995].

Table IV. Dimensions Applied to Active Relational Database Systems



6.1.1 Starburst. The Starburst ac-tive rule system adds active functional-ity to an extensible relational databasesystem [Widom and Finkelstein 1990],and has been used as a testbed for anumber of database internal applica-tions, including integrity constraints[Ceri et al. 1990] and materializedviews [Ceri and Widom 1991].

Perhaps the most noteworthy featureof the Starburst rule system is its set-based execution model, in which rulesare triggered by the net effect of a set ofchanges to the data stored in the data-base. When an operation takes placethat is being monitored by a rule, thenature of the change is logged in atransition table. Entries in such tablescan then be revised to take account ofsubsequent update operations; for ex-ample, if a tuple is inserted and thenupdated, the net-effect is logged as aninsert of the updated tuple; if a tuple isinserted and then deleted, the net-effectis that no operation has taken place.The information that is stored in transi-tion tables is used to trigger rules atrule assertion points, that may takeplace either during or at the end of atransaction. In this context, events donot trigger rules directly. Rather, thefact that an event has occurred is re-corded in a transition table for subse-quent consideration, and the timing ororder of specific events is not taken intoaccount by the scheduler.

Each rule that is monitoring a partic-ular event has access to the net-effect ofall updates of relevance to that event,and that have not already been consid-ered by the rule; when a rule is firedmultiple times within a single transac-tion, the changes it has access to arethose that have taken place since thelast firing of the rule.

The Starburst rule system can be con-sidered to be conservative in its design,in that a modest and fixed set of facili-ties is supported. However, the seman-tics of rule execution in Starburst is stillquite complex, and it can be argued thatsupporting many more facilities is likely

to lead to rule sets that are difficult tounderstand and maintain.

6.1.2 POSTGRES. The active rulesystem is only one of a number of exten-sions to the relational model supportedwithin POSTGRES [Stonebraker andKemnitz 1991], with others facilitatingthe representation of objects and user-defined operations. The POSTGRESrule system is considered within thesection on relational databases becausethe object-oriented features of POST-GRES seem to have had little bearingon the design of the rule system. ThePOSTGRES rule system, like that ofStarburst, can be considered to be quiteconservative, although a key distinctionis that the POSTGRES rule system istuple-oriented. Furthermore, the conse-quences of an event being raised takeeffect immediately, rather than beingdeferred until a later rule assertionpoint.

6.1.3 Ariel. An important character-istic of Ariel that distinguishes it fromStarburst or POSTGRES is the option-ality of the event—Ariel principally sup-ports condition-action rules. The conse-quences of this distinction for theimplementation of rule systems is con-sidered in Section 7.5.

The suitability of condition-actionrules compared with ECA-rules dependsupon the context. There are circum-stances in which it is necessary to makethe event part of a rule explicit to cap-ture the semantics of an application. Inthe example application from Section 2,there might be a general policy that nomore than 10% of the total value of thestock owned by Cautious Investmentsshould be of the one kind. This could becaptured by a condition-action rulethus.

if h.name 5 “Cautious Invest-ments”and h.reg# 5 o.reg#ando.stock# 5 s.stock# ando.qty p s.price . 0.1 ph.value

from h in Holder, o in Owns,



s in Stockdo ^reduce quantity of s owned

by h &

However, this rule would have theeffect of selling a particular kind ofstock without regard for the reason thatits value had increased relative to thetotal value held by Cautious Invest-ments. It may be preferable to distin-guish between the different events thatcaused the condition to go true usingECA-rules. For example, if the conditionbecame true as a result of the purchaseof more of the stock, then the updatemay be blocked. By contrast, if the con-dition became true as a result of anincrease in the price of the stock, thenthe portfolio manager could be warned,but no action taken. These approachescan be supported by the following rules.

on update to qty of Ownsif h.name 5 “Cautious In-

vestments” andh.reg# 5 new.reg# andnew.stock# 5 s.stock# andnew.qty p s.price . 0.1 p

h.valuefrom h in Holder, s in Stockdo abort

on update to price of Stockif h.name 5 “Cautious In-

vestments” andh.reg# 5 o.reg# ando.stock# 5 new.stock# ando.qty p new.price . 0.1 p

h.valuefrom h in Holder, o in Owns

do ^inform portfolio manager &

Thus ECA-rules can be considered todescribe the context of a rule in a moreprecise way than condition-action rules.This may not, however, always be to theadvantage of programmers using a rulesystem. For example, to describe thesituation captured by the preceding con-dition-action rule using ECA-rules,events would have to be defined thatmonitor the insertion of tuples into theOwns table, changes to the reg# at-tribute of Owns and Holder , updates tothe value attribute of Holder , and soon. Thus, by providing both ECA-rules

and condition-action rules, Ariel can besaid to offer the best of both worlds incontexts such as the preceding.

6.1.4 SQL-3. Most commercial rela-tional databases support trigger mecha-nisms. However, the knowledge and ex-ecution models of these mechanismshave traditionally differed from systemto system. With a view to providingmore consistent support for activemechanisms in relational systems, trig-gers are included in the emergingSQL-3 standard [Kulkarni et al. 1999].This survey features the standardrather than any of the current commer-cial systems, as it is expected that thecommercial systems will drift towardsthe standard in due course.

The SQL-3 standard, like many com-mercial systems, supports both row-level triggers (with a transition granu-larity of tuple) and statement-leveltriggers (with a transition granularityof set). Statement-level triggers are exe-cuted once in response to an updateoperation on a table, no matter howmany tuples are affected by the update.However, perhaps the most importantfeature of the SQL-3 standard is that itmakes explicit how triggers are to inter-act with other features found in rela-tional databases, and in particular, de-clarative integrity-checking mechanisms.

6.2 Object-Oriented Systems

Object-oriented databases (OODBs), un-like their relational predecessors, havealways supported a close association ofuser-defined behavior with databasedata. Such behavior is generally ex-pressed as methods attached to theclasses that structure the data stored inthe database. This, plus the hiding ofcertain aspects of the structure of anobject using encapsulation, means thatcertain of the tasks that may be per-formed by active behavior in relationaldatabases are supportable usingmethod code in object-oriented systems.Despite this, proposals for active exten-sions to OODBs abound, with early pro-posals being made only a few years after



the first work on passive OODBs. Thisrapid and extensive research activityhas probably been encouraged by thetendency for OODBs to be used in ad-vanced applications, where the need forcomprehensive behavior managementfacilities is greater than in more tradi-tional domains. Furthermore, the na-ture of certain applications has encour-aged investigation of active databaseconstructs that are significantly morepowerful than those described for rela-tional systems in Table IV, as shown forselected systems in Tables V and VI. Aswell as being more powerful than mostextensions to relational databases, acommon difference is that primitiveevents in active OODBs are often asso-ciated with method invocations ratherthan access to or update of structure.This partly derives from the desire toavoid reducing data independence bylinking active behavior to structure di-rectly, and partly from the fact thatsome systems use layered architecturesin which it is not straightforward toraise events on the basis of structureoperations.

The following subsections outline theprincipal features of eight projects de-veloping active object-oriented data-bases, four of which are not based uponpersistent C11 systems (HiPAC, EX-ACT, NAOS, and Chimera, as featuredin Table V), and four of which are basedon database extensions of C11 (Ode,SAMOS, Sentinel, and REACH, as fea-tured in Table VI). Other examples ofactive extensions to OODBs are pre-sented in Dittrich [1993], Etzion et al.[1994], Naqvi and Ibraham [1994],Thomas and Jones [1995], and Dinn etal. [1996].

6.2.1 HiPAC. The HiPAC project[Dayal et al. 1988; Chakravarthy 1989;Dayal 1989] pioneered many of the mostimportant ideas in active databases,such as coupling modes and compositeevents, although the resulting designwas not fully implemented. HiPAC wasassociated with the passive OODBPROBE, and objects in this model were

used to store the ECA-rules of the activeextension. Further distinctive featuresof HiPAC are the parallel execution oftriggered rules as subtransactions, theextension of the query algebra with achanges operator that allows access todelta relations that monitor the net ef-fect of a set of changes, and identifica-tion of real-time applications that canbenefit from active database facilities.

6.2.2 EXACT. EXACT, an extensi-ble active rule manager [Diaz et al.1991; Diaz and Jaime 1997], adds activefacilities to the OODB ADAM, in whichinstances, classes, rules, and events arerepresented uniformly as database ob-jects. Two contentions support thiswork, specifically: that control informa-tion rarely refers to single rules but tosets of rules, and that rules supportingdifferent applications often require dif-ferent execution models. To supportthese contentions, EXACT provides anextensible rule model in which collec-tions of rules can be developed thatshare similar features, the functional-ities of which are described by specializ-ing the general rule management facili-ties provided with the system. EXACThas been used for experimentation inthe development of advanced databasefacilities [Diaz 1992; Paton et al. 1993;Diaz et al. 1994].

6.2.3 NAOS. NAOS [Collet et al.1994] is an active rule system for the O2commercial OODB [Deux et al. 1990].As NAOS has been implemented as partof the kernel of O2, rather than as alayer on top that has not been sanc-tioned by the vendor, it may developinto the first commercially available ac-tive OODB.

As O2 provides comprehensive sup-port for two languages, O2C and OQL,NAOS has been able to exploit this toprovide declarative expression of condi-tions using OQL and powerful actionexpression using O2C. The executionmodel of NAOS is slightly unusual, insupporting depth-first, recursive pro-cessing of immediate rules, but breadth-first, iterative processing of deferred



rules. The NAOS rule system has beenformally specified using denotationalsemantics [Coupaye and Collet 1995],

and is also being used for experimentalwork on optimization [Collet and Man-chado 1995].

Table V. Dimensions Applied to Active Object-Oriented Systems



6.2.4 Chimera. The Chimera [Ceriet al. 1996] active rule system is uniqueamong those surveyed here in buildingupon a deductive object-oriented data-base (another such system is describedin Dinn et al. [1996]). The use of the

deductive language for condition expres-sion encourages a set-oriented view ofrule processing, and information ispassed from the event to the conditionby querying an event history. Anotherunusual feature of Chimera is that rule

Table VI. Dimensions Applied to Active Object-Oriented Systems Based on C11



conditions and actions can access pastdatabase states, either at the start ofthe current transaction, or when therule was last fired. Chimera is imple-mented by compiling user statementsinto an internal form that is interpretedby a runtime system that stores bothdatabase and rule system data usingthe ALGRES extended relational stor-age manager.

6.2.5 Ode. The Ode database systemis defined and manipulated using theO11 database programming language,which extends C11 with database facil-ities (e.g., persistence, versions). It pro-vides two categories of rules that aresemantically divided into constraintsand triggers, each with a different syn-tax and execution model [Gehani andJagadish 1991]. Although triggers can,in general, be used to support con-straints, the authors argue that the dis-tinction clarifies the role that is beingplayed, and facilitates more efficient im-plementation. Both constraints andtriggers are defined at the class level,and are subject to inheritance like otherproperties of a class.

A constraint consists of a predicate onthe state of an object and a single actionto be executed if the condition becomesfalse. Once the action has been exe-cuted, the system checks the conditionagain. If it is still false, the transactionis aborted. As for the event-conditioncoupling modes, different options aresupported depending on whether con-straints should be checked immediately(declared as hard constraints), or de-ferred until the end of transaction (de-clared as soft constraints). Multiple up-dates affecting the same hardconstraint in the course of a transactioncause the constraint to be evaluatedonce after each update, whereas for asoft constraint the check is only carriedout once at the end of the transaction.Constraints affect all instances of aclass, and are permanently activated.

Unlike constraints, triggers have tobe explicitly activated on particular ob-jects. If a trigger is active, then when its

condition becomes true, its action is ex-ecuted. Once signaled, triggers declaredas once-only are automatically deacti-vated whereas those declared as perpet-ual are reactivated automatically. Theuser can explicitly deactivate a triggerusing the command deactivate. Unlikeconstraints, triggers with a conditionthat has evaluated to true are executedin a separate transaction after the cur-rent transaction has committed (i.e., theevent-condition coupling mode is imme-diate, whereas the condition-action cou-pling mode is detached dependent).Note that the processing supported bytriggers in Ode is quite distinctive, andopen to interpretation in different ways.Here, triggers have been considered ascondition-action rules, but an equallyvalid interpretation is that they areevent-action rules in which the event isdefined using a rich event algebra andBoolean expressions, known as masks.

6.2.6 SAMOS. SAMOS [Gatziu etal. 1991; Gatziu and Dittrich 1994] pro-vides active facilities on top of the Ob-jectStore commercial OODB. As the de-velopers of SAMOS did not have accessto the source of ObjectStore, the activesystem is implemented as a layer on topof ObjectStore, rather than as part ofthe kernel.

Perhaps the most significant featureof SAMOS is its event detector, the se-mantics of which is based upon Petrinets, and which, in turn, is imple-mented using a graph structure thatreflects the structure of the Petri net.The event language itself presents userswith a series of operators that areshared by other systems with compre-hensive event languages, such asHiPAC [Dayal et al. 1988], Sentinel[Chakravarthy et al. 1994], or REACH[Buchmann et al. 1995].

6.2.7 Sentinel. Sentinel [Chakra-varthy et al. 1994] is an active exten-sion to the C11 based OpenOODB sys-tem from Texas Instruments [Wells etal. 1992]. The focus in this project hasbeen upon the provision of comprehen-



sive event specification mechanisms,representation of rules as database ob-jects, and integration of the rule systemwith a sophisticated transaction man-ager. In particular, the consumptionmodes that are now widely accepted asproviding appropriate descriptions ofhow to construct parameters to compos-ite events in rule systems with tuple-level transition granularities were firstimplemented in Sentinel.

6.2.8 REACH. REACH [Buchmannet al. 1995] has much in common withSentinel in that it too is an active exten-sion to OpenOODB. The emphasis inthe REACH project has been on devel-oping a comprehensive understandingof how the rule manager interacts withcomplex transaction models, with aview to supporting open applications[Branding et al. 1994]. Examples of cou-pling modes supported in REACH withopen applications in mind are sequen-tial causally dependent, in which a rule

executes in a separate transaction fromits triggering event only after the trig-gering transaction commits, and exclu-sive causally dependent, in which a ruleexecutes in a separate transaction fromits triggering event only after the trig-gering transaction aborts.

7. ARCHITECTURAL ISSUES

This section considers how some of thecharacteristics of active database sys-tems presented in the foregoing sectionscan be implemented. In addressing cer-tain issues, reference is made to theabstract architecture of an active data-base system presented in Figure 5. Thisfigure makes explicit the principal pro-cesses (rectangles) and data stores (el-lipses) used to implement the function-ality illustrated in Figure 4.

The principal processes are as follows.

(1) The Event Detector ascertainswhat events of interest to the rule

Figure 5. Abstract active rule system architecture.



system have taken place, if any.Primitive events are notified fromthe database or from external sourc-es; composite events are constructedfrom incoming primitive events plusinformation about past events thatcan be obtained from the history.

(2) The Condition Monitor evaluatesthe conditions of rules associatedwith events that have been detectedby (1). In systems that support con-dition-action rules, there is no ex-plicit statement of the events to bemonitored, although actual imple-mentations do have to monitor prim-itive events. The distinctive imple-mentation strategies that are oftenused in such systems are consideredin Section 7.5.

(3) The Scheduler compares recentlytriggered rules with those that havepreviously been triggered, updatesthe conflict set, and fires any rulesthat are scheduled for immediateprocessing.

(4) The Query Evaluator executes da-tabase queries or actions. Accessmay be required both to the currentstate of the database and to paststates in order to support monitor-ing of how the database is evolving.

The functionality of each of the preced-ing components depends very much onthe knowledge and execution models ofthe active database system to be sup-ported, which in turn are influenced bythe environment within which the ac-tive database is being developed. Archi-tecturally, two principal categories ofactive database can be identified.

Layered. The active component isdeveloped as a layer of software on topof an unchanged passive database sys-tem. This approach has the advantagethat no access is required to the sourcecode of the passive database system,and that the resulting active systemmay be easily portable for use with dif-ferent passive systems. However, thelack of access to the kernel of the under-lying database may have an impact

upon performance and limit what func-tionality can be supported in terms ofprimitive event detection, couplingmodes, and optimization.

Integrated. The active component isdeveloped by changing the source of anexisting passive database system. Thisapproach frees the designer of the activedatabase system from the limitations ofthe layered approach, and is probablythe preferred model for developing in-dustrial-strength systems. It is worthnoting, however, that the number of re-quired changes to the kernel of a systemto allow it to support active capabilitieseffectively is often not large, and thatpractical systems can be developed us-ing largely layered software, with asmall number of hooks into the kernel.

The first systematic performanceevaluation of different active databasesystems and architectures is providedby Geppert et al. [1998]. The followingsubsections address a range of imple-mentation issues in more detail.

7.1 Event Detection

There are two principal aspects to theimplementation of event detection—themonitoring of primitive events and theaccumulation of information that is ofrelevance to composite events.

The detection of primitive events nor-mally involves some form of checkwithin the kernel of the database sys-tem, a characteristic that means it isoften not possible for active functional-ity to be implemented as a layer on topof an existing database system. For ex-ample, to detect that an update hasbeen made to a tuple in a relation, it isnecessary for the update operation ofthe database system to be able to iden-tify which primitive events are associ-ated with the specific update being per-formed. As a further example, in object-oriented databases events are oftenraised in response to the invocation ofuser-defined methods, in which case theevent detector must be notified of mes-sage-sending events by the method dis-



patcher. Specific techniques for detect-ing primitive events in object-orientedsystems are discussed in Dittrich[1993], Gatziu and Dittrich [1994],Chakravarthy et al. [1994], and Kim etal. [1992]. Broadly speaking, this can beachieved using a sender-based, receiver-based, or dispatcher-based mechanism[Fernandez and Diaz 1995]. The firstdoes not really lead to active systems,as event detection is undertaken by theapplication rather than the DBMS it-self. The application is changed wher-ever the relevant message is sent. Aswell as being intrusive, the main draw-back of this approach is that detection isreplicated, distributed, and embeddedin application programs, thus jeopardiz-ing encapsulation and maintenance.

The receiver-based approach ismainly based on wrappers: a monitoredmessage must activate an operationthat extends the original code providedby the user with the associated signal tothe event detector. This extra code iscalled a wrapper since it is typicallyexecuted before and/or after the originalmethod. The receiver-based approach isgenerally found in layered architec-tures, as primitive event detection canbe implemented by preprocessing appli-cation programs, and thus changes tothe kernel of the database are not re-quired.

By contrast, dispatcher-based mecha-nisms offer a general solution by placingthe signaling code inside the databasesystem itself. Such mechanisms can beused to monitor a range of aspects ofsystem behavior, including transactionoperations, structural primitives, andbehavior invocations. As this approachrequires changes to the kernel of thedatabase, it is found only in systemswith integrated architectures.

As for composite event detection, itinvolves recording information on allpartially detected composite events thatmay become fully detected in the future.For example, in the composite event E1and E2, if E1 has taken place but E2 hasnot, then this fact must be recordeduntil E2 either does take place or the

timespan within which the event is tobe detected expires. For compositeevents whose components are primitiveevents that have originated within theboundaries of a single transaction, theend of the transaction marks the end ofthe monitoring period, and all partiallycomposed events can be removed. If thesource transaction is not relevant, sothat a composite event can be formed byevents that originate in different trans-actions, a validity interval is required.This may be given either for the wholecomposite event, or it may be deter-mined by the smallest validity intervalof the composing events [Buchmann etal. 1995].

A range of different structures hasbeen proposed for implementing com-posite events along with event algebras.For example, Gatziu and Dittrich [1994]describe the use of colored Petri nets forspecifying and implementing an eventdetector, whereas Gehani et al. [1992]use finite state automata, and Chakra-varthy et al. [1994] use an event graphthat is linked directly to the querygraph used to express the condition ofthe corresponding rule. As an exampleof how information on partially detectedevents is accumulated, Figure 6 showsthe event graph that would be used todescribe the event E1 and E2 or E3. Asevents take place, the event graph isdecorated with instances of primitive

Figure 6. Example of Sentinel event graph.



events that are then consumed as com-posite events are detected. For the ex-ample, in Figure 6, in all event con-sumption modes except Recentmentioned in Section 4, if N occurrencesof E1 are raised before any occurrencesof E2, then all N occurrences of E1 mustbe stored in anticipation of the subse-quent raising of some matching occur-rences of E2. Such a process can be veryexpensive, and in practice care must betaken in the design and use of compos-ite event detectors to ensure that thehistory datastore in Figure 5 does notbecome extremely large.

7.2 Condition Monitoring

The event combined with the conditiondescribes the situation that an ECA-rule is monitoring. As such, there isoften a close association between theevent detector and the condition moni-tor—the event detector initiates pro-cessing within the condition monitor,and information about the events thathave occurred must be passed from theevent detector to the condition monitor.The more sophisticated the event detec-tor, the more complex will be the infor-mation to be passed to the conditionmonitor. For example, in the case of aprimitive event such as on insert toStock , the only information that needsbe passed to the condition monitorabout the event is the inserted tuple. Bycontrast, where the event is composite,the relevant information about theevent is also more complex. For exam-ple, in a conjunctive event, informationshould be available to the condition ofthe rule on all of the events that causedthe conjunctive event to be signaled.

Once rules that are associated withdetected events have been retrievedfrom the rule base and bound to theparameters of these events, they mustbe passed to the query evaluator to es-tablish which rules have satisfied condi-tions. The query processor is likely to bean extension of that used with a passivedatabase, as rule conditions are param-eterized with bindings from events, and

may also have access to past states ofthe database. For example, in Starburst[Widom et al. 1991] a transition logrecords how tables have changed duringa transaction, which supports accessfrom the condition of the rule to theaccumulated changes associated withthe event that has triggered the rule. Acomparable mechanism is required byany system that supports rule process-ing based upon the net effect of a set ofaccumulated changes. The contents ofthe history in a specific rule systemthus depend upon the nature of theevent specification language supported,plus the scope of access to past databasestates from the condition/action of therule.

Some condition languages are basedon the declarative query language of theunderlying database, which raises thepossibility of applying optimizationtechniques to rule conditions. In gen-eral, the existing optimizer can be ap-plied directly to the optimization of suchconditions, and significant gains in per-formance are likely to be experiencedwhere event parameters are used to re-strict the information accessed by thecondition. A similar theme is exploredby Baralis and Widom [1995], where itis shown how exploitation of intermedi-ate information held by the rule man-ager can be used to speed up conditionevaluation, although this approach onlyprovides significant gains where thereis repeated triggering of individualrules. Furthermore, in systems withrich event algebras that are able tomatch specific values in events, an opti-mizer may be able to move some of theselections from the condition into theevent detector. It is also shown in Colletand Manchado [1995] how detailedanalysis of rule conditions and actionscan be used to identify rules that areamenable to parallel execution.

The design and implementation of ef-fective situation monitors for active da-tabase systems is of considerable impor-tance, and various balances have to bestruck between the provision of expres-sive facilities and efficiency of process-



ing. For example, expressive event alge-bras enable more of the situation that isbeing monitored to be described withinthe event part of the rule, which in turnleads to less frequent invocation of sim-plified rule conditions. However, the re-duced cost of condition evaluation mustbe balanced against the considerableoverheads associated with compositeevent detection. A definitive position onthe tradeoffs involved in situation mon-itoring awaits further theoretical andempirical analyses of alternative ap-proaches.

7.3 Action Execution

Rules with conditions that are satisfiedare prepared for execution by the sched-uler, which also maintains the conflictset of triggered rules that have yet to befired. The complexity of the scheduleralso varies considerably from system tosystem: for example, in POSTGRES[Stonebraker et al. 1990] the scheduleris quite straightforward, as all rules arefired as soon as they are triggered, andbecause there is no priority scheme thatrequires rules to be fired in a specificorder. By contrast, in Starburst [Widomet al. 1991] the scheduler is more com-plex: rules must be fired in an orderthat is consistent with a priority graph,and it is possible for a rule to be re-moved from the conflict set without be-ing fired because the processing of rulesis based upon the net effect of thechanges to the underlying database.

When a rule is scheduled for execu-tion, its action is passed to the queryevaluator, which in turn is likely toupdate the database and the history.The action of a rule is also likely to haveaccess to information on the event thatcaused the rule to be triggered (i.e.,BindE), and may also be passed datathat have been retrieved by the condi-tion of the rule (i.e., BindC), for exam-ple, the set of objects for which an integ-rity constraint has been violated.

Binding can be supported in differentways. In HiPAC and EXACT, explicitlyspecified parameters are available to

provide access to the current event. Forexample, the predicate current_occur-rence(O) can be used in rule conditionsor actions in EXACT to obtain the pa-rameters of the event occurrence thathas triggered the rule. Starburst storesbinding information in transition tablesthat record the net effect of tuple modi-fications caused during query process-ing. Transition tables can be queried bythe condition or the action of a rule.Unlike Starburst, POSTGRES hastuple-based processing, which consider-ably simplifies the bindings, since onlythe current tuple needs to be consid-ered. Correlation names new and oldare provided to allow accessing thevalue of the current tuple before andafter modification.

7.4 Transaction Management

It is often the case that sophisticatedfacilities in the associated passive data-base system can be used to increase thefunctionality of the active mechanisms.For example, in active object-orientedsystems much has been made of theability to associate rules with user-de-fined operations, and to share activebehavior within inheritance hierarchies.Most implemented active database sys-tems are associated with conventionalflat transaction models, and thus rulesare processed to completion within thesame transaction as the events that ledto their triggering. However, wheremore sophisticated transaction manage-ment facilities are available, these canbe exploited to increase the flexibility ofconventional rule systems, and to allowaddition of features that can be used tosupport more advanced applications.

Rich transaction models can be usedto underpin a range of different behav-ioral extensions to execution models[Beeri and Milo 1991]. A nested transac-tion is a transaction that containswithin it a number of component trans-actions, or subtransactions [Moss 1985].The nested transaction creates the sub-transitions and waits until they termi-nate. This model can be extended so



that the nested transaction can run con-currently with the subtransactions[Harder and Rothermel 1993]. As wellas speeding up the whole process as aresult of increased concurrency, thismodel can be useful for active databasesystems. For example, if the action of arule is unable to carry out the taskassigned to it, then there is a significantchance that the whole transaction willbe aborted, potentially undoing a signif-icant amount of work. By contrast, ifthe action of the rule is executed in aseparate subtransaction (the triggeredtransaction) which aborts, then the par-ent transaction (the triggering transac-tion) is free to decide how to respond tothe failure: it could repeat the action aset number of times, fire an alternativeaction, and so on. Such underlying func-tionality can be made available to therule programmer as extensions to therule definition that describe how to re-spond to failures.

In addition, a number of issues can beidentified that relate to the relationshipbetween concurrency control and cou-pling modes. If the triggering and trig-gered transaction are executed concur-rently, it could happen, depending onthe concurrency control method used,that the triggered transaction commitswhile the triggering transaction is stillexecuting (and thus, potentially abort-ing). This possible behavior jeopardizesthe concept of causality: an effect shouldnot precede its cause [Hsu et al. 1988].To fall into line with this concept, aschedule must obey the following tworules: the triggered transaction must beserialized after the triggering transac-tion, and the triggered transaction cancommit only if the triggering transac-tion commits. The user may eitherchoose to obey the causality principle orto allow the triggered transaction to beexecuted freely. Using the terminologyintroduced in Section 4, these optionscorrespond to the detached depen-dent and detached independent cou-pling modes, respectively.

7.5 Production Rule Algorithms

The architecture presented in Figure 5makes explicit the role of event detec-tion for situation monitoring, whereassome systems, such as Ariel [Hanson1992] and Amos [Skold and Risch 1995]support production (or condition-action)rules without explicit event specifica-tions. In practice, however, primitiveupdate events must also be detected bydatabase production systems, as thetruth of a condition can be changed as aconsequence of changes to the underly-ing database. Figure 5 can thus be seenas a potential architecture for imple-menting a production rule system, al-though algorithms commonly used forimproving the efficiency of conditionevaluation are quite different fromthose generally applied in the context ofECA-rules.

Condition-action rules are processedin the context of the following recognize-act cycle.

matchwhile (conflict set not

empty) doconflict resolutionactmatch

end-while

In such a cycle, the match phase iden-tifies rules with conditions that are truewith respect to the state of the data-base, and adds them to the conflictset , which is essentially a queue oftriggered rules waiting to be fired. Theconflict resolution step selects asingle rule from the conflict set for fur-ther processing in the act phase, whichexecutes the statements in the action ofthe selected rule.

A naive evaluation of the matchphase would evaluate the condition ofevery rule to find which rules should beconsidered for processing. Such an ap-proach would be prohibitively expen-sive, and is unnecessary, as only a smallpart of the database over which eachcondition acts is likely to change duringeach cycle. What many methods seek todo is avoid recomputing the entire con-



dition of a rule by storing informationon the partially computed condition of arule between cycles.

In what follows, the example relationsfrom Figure 2 are used to illustrate twoof the principal approaches. A typicalproduction rule in Ariel notation [Han-son 1992] relating to these data couldmonitor every UK based owner of IBMstock:

if s.name 5 “IBM” ands.stock# 5 o.stock# and

o.reg# 5 h.reg# andh.country 5 “UK”

from s in Stock, o in Owns,h in Holder

do ^action &

The query used to express the condi-tion involves a join of the Owns relationwith both Stock and Holder .

The principal notion behind the Rete[Forgy 1982] matching algorithm, whichwas originally proposed for implement-ing main-memory OPS-5 productionrule systems, is that by storing the par-tially computed condition of a rule be-tween cycles of rule execution, the effectof changes to the database on the con-flict set can be computed with minimaladditional effort. The partially com-puted condition of a rule is often storedin a graph structure known as a dis-crimination network. The preceding ex-ample query can be represented by theRete discrimination network in Figure7.

The Rete network has a number ofdifferent node types: a root node servesas the entry point to the network; belowthe root node are a number of nodesthat represent the base tables; and be-low any node that represents a storedtable, there can be zero or more filternodes, each of which applies a singlecondition to the relation. After a filterhas been applied, the tuples that havesatisfied the condition in the filter arestored in a memory tables. A node withtwo parents performs a join on its par-ent relations, the result of which isstored in a b memory node. At the bot-

tom of the tree is the result node thatholds the conflict set.

The Rete match phase operates bypassing information down through thenetwork from the root. For example, if anew Holder tuple is entered into thedatabase, it is tested to see if it has acountry equal to UK—if so, it is storedin the a memory node alpha1. The tupleis then joined with the a memory nodealpha2, and if tuples result from thejoin, they are stored in the b memorynode beta1. Any such new tuples arethen joined to the a memory node al-pha3 to yield additional data for theconflict set.

Although Rete has been used in com-mercial production-rule systems, thereare a number of problems, especiallywhen large databases are used: thespace overhead is high, with both a andb memories storing the intermediate re-sults of computation, and maintenanceof such results, particularly on deletionof data, imposes a significant overhead.Work on the identification of alterna-tives to Rete has explored two principalissues relating to intermediate informa-tion.

What to Store. A spectrum can beseen to exist, with no storage of inter-mediate results at one end, and storageof all intermediate results at the other.Rete is at the storage-intensive end ofthis spectrum, with both a and b mem-ories being used. A variation of Retewith a but no b memories is TREAT[Miranker 1987], which outperformsRete in many cases [Wang and Hanson1992]. More recent research has shownhow rules can be analyzed to identifywhat level of intermediate storage ismost suitable for them [Fabret et al.1993].

How to Store It. Algorithms such asTREAT can be built directly on top ofrelational storage structures, but re-searchers have identified structuresthat improve certain aspects of condi-tion monitoring. For example, Hanson[1992] exploits interval skip lists to re-



duce the cost of searching and updatinga memories, and Brant and Miranker[1993] use a specialized index structureto improve join performance.

7.6 Active Rules in a DistributedEnvironment

Until now, this article has assumed thatactive behavior is being supported in asingle centralized database. However,many modern applications have a dis-tributed nature, and a number of pro-posals have been made for exploitingactive behavior in distributed systems.Here, the active mechanism is seen as a

set of cooperating objects distributedthroughout a network of loosely coupledautonomous nodes. Event detection,event management, or rule manage-ment are seen as services that cooperateto offer the functionality previouslybundled in a monolithic active mecha-nism. Standards such as CORBA [Orfaliet al. 1996] provide the communicationmiddleware required for cooperation inthis distributed setting. Figure 8 givesan overview of how the architecture pre-sented in Figure 11 has been adapted tothe new setting. The pioneer work of C2

offeine [Koschel et al. 1997] illustrates

Figure 7. Rete network for example rule.



this approach. This system enables ECArule-based detection, processing, and re-porting of events and complex situa-tions to be done in CORBA-based sys-tems with heterogeneous anddistributed information sources. Despitethe limited experience to date, some in-sights can be given about the implica-tions of distribution of active rule sup-port.

As far as architecture is concerned,rule management is no longer central-ized but distributed. Although Figure 8suggests that each component is cen-trally located at a different site, thisdoes not need to be so. For instance,event detection can be distributedamong sites [Bacon et al. 1995; Schwid-erski 1996]. Each site contains a localevent detector and a global event detec-tor. The former basically corresponds tothe detectors found in centralized sys-tems, while the latter are responsiblefor monitoring intersite compositeevents. A global event detector responsi-ble for event e registers its interest ine’s components in the corresponding de-tectors. The detection of a global eventis then distributed among differentsites. As soon as an event is detected, asignal is sent to each of the detectorsthat have registered an interest in it.Likewise, rule management support of-

fers distinct alternatives: (1) a centralrule manager maintaining a global rulebase, (2) a set of rule managers in dis-tinct sites each one with its local rulebase, and (3) a set of rule managers butwith a global rule set [von Bueltzings-loewen et al. 1998].

Being in a distributed context, archi-tectural alternatives must considercommunication overheads. For instance,CORBA includes an event service thatsupports asynchronous communicationbetween objects. Communication isachieved through event channels. Anevent channel is a queue onto whichevents are placed by suppliers and re-moved by consumers. Two models areprovided for event communication,based on who initiates the communica-tion. The push model allows a supplierof events to initiate the transfer of theevent data to consumers. The pullmodel permits a consumer of events torequest the event data from a supplier.2

These options should be considered

2 A key point, however, is that both the supplierand the consumer are aware of event processing;that is, they have to initiate event processingexplicitly, thus violating the nonintrusive princi-ple that characterizes the event-based paradigm.Moreover, CORBA does not explicitly supportcomposite events.

Figure 8. Active rule system architecture: moving to a distributed setting.



when addressing communication amongthe distinct components supporting theactive functionality. For instance,should the signaling phase involvingcommunication between event sourcesand the event detector follow a pushmodel (also known as reactive) or a pullmodel (also known as proactive)? Reac-tive models are useful for central eventdetectors where every event is relevantfor the system. Otherwise, an importantcommunication overhead is caused sinceevery event must be communicated tothe event detector. On the other hand,proactive models incur a bigger process-ing overhead [von Bueltzingsloewen etal. 1999]. Likewise, communication be-tween the event detector and the rulemanager (the triggering phase) can alsofollow a reactive or a proactive ap-proach. The former implies explicit sub-scription of the rule manager to the setof events in which it is interested,whereas the proactive approach leavesthe rule manager to poll the event col-lection periodically [von Bueltzingsloe-wen et al. 1999].

In addition to architectural consider-ations, both the knowledge and execu-tion models should also be revised whenmoved to a distributed (and potentiallyheterogeneous) setting. As for theknowledge model, heterogeneity of theevent sources can lead to additionalclassifications besides those found incentralized systems (e.g., workflowevents). Also, the diversity of the datasources and the lack of a single staterequires further precision in setting thecontext in which conditions and actionsare performed. A complex problem isthat of timestamps. In a centralized sys-tem there is a single clock that allows atotal ordering of event instances basedon their occurrence time. That is, twodistinct primitive events e1 and e2 canalways be ordered as they cannot occursimultaneously: either e1 happens be-fore e2 or vice versa. The time of acomposite event occurrence is then de-rived from the occurrence times of itscomponents. By contrast, distributedsystems do not have global time: each

site has its own local clock, and eventsmay occur simultaneously at differentsites. As events contributing to a com-posite event originate from differentsites, an event’s timestamp should beglobally meaningful. Therefore, localclocks must be synchronized throughspecial time servers that transmit timeinformation to each site, and the delayin the synchronization among the sitesshould be below a parameter P obtainedas the maximum time difference be-tween two “simultaneous” ticks of anytwo local clocks. Summing up, two time-stamps are required, namely, localtimestamps, needed for constructing in-trasite composite events, and globaltimestamps as a canonical form used inthe detection of intersite compositeevents [Schwiderski 1996].

Finally, the execution model alsoneeds to be revised. As a case in point,the error handling dimension shouldnow be extended with communicationdelays and disruptions to be faced inany messaging among the componentsof the active mechanism. The solutionwill vary depending on the componentsand the impact of the error. For in-stance, communication delays duringsignaling between the event detectorand an event source can cause globalevent detectors to receive events in adifferent order from their actual occur-rence. Contingency actions can opt forasynchronous evaluation or synchronousevaluation [Schwiderski 1996]. Theformer ignores the fact that there maybe delayed events, and begins evalua-tion as soon as suitable event occur-rences arrive at a composite event de-tector. Hence, events are not composedin a way that takes account of the orderof their occurrence, but, on the otherhand, event detection is not blocked bydelayed events and is therefore faster.As an example, consider the event e1 ore2. If e2’s site fails, the disjunction canstill be detected whenever e1 is de-tected. By contrast, synchronous evalu-ation waits for delayed events, and eval-uation proceeds only if all relevantevents have arrived at the site of the



global event detector. Although syn-chronous evaluation respects the occur-rence order of events, the evaluationmay be blocked long-term if there istransmission disruption or site failure.In the previous disjunctive example, thesites of both e1 and e2 are checked forrelevant events before a disjunctiveevent occurrence is detected. In mostcases, checking reveals that no relevantevents should have been detected. Occa-sionally, a disruption can occur that de-lays the arrival of a relevant event. Theglobal detector does this checking sothat the consumption policy can beproperly supported. As Schwiderskipoints out, which strategy is most ap-propriate depends on the application.Likewise, failure of data source access(e.g., due to a node breakdown) duringcondition evaluation or action executionshould be addressed. The options pro-posed range from an instead action tothe execution of no action [Koschel et al.1997].

Although few details are yet avail-able, distributed active rule manage-ment is likely to be one of the futureservices offered by CORBA-compliantsuppliers. Its need can be corroboratedby the proposals for event mechanismswhich, independently of the activeDBMS community, have already beenproposed for supporting debugging[Bates 1995], communication, and inte-gration in distributed applications[Amouroux 1995; Barghouti and Krish-namurthy 1995].

8. DEVELOPING ACTIVE APPLICATIONS

Comprehensive support for active mech-anisms within a database system is noguarantee that they will be used. In-deed, experience in the application ofactive databases often indicates that al-though such facilities are suitable forperforming a range of different tasks,they are not straightforward to use. Dif-ficulties include the following.

—It is not obvious (1) which parts of anapplication should be supported using

active mechanisms, and which usingother techniques, and (2) what perfor-mance penalty is likely to result fromthe use of rules. This is exacerbatedby the lack of appropriate designmethodologies.

—The functionality of a large rule basemay be difficult to understand, withrules interacting in complex ways andno single description of how controlflows through an application.

—The tools associated with an activerule system may be minimal, withlittle support for browsing, monitor-ing, or debugging of active rules.

These points reflect a need for designmethodologies, rule analysis tech-niques, and tools for debugging and ex-planation. In what follows, recent ad-vances in each of these areas areoutlined.

8.1 Rule Design

There are well-established techniquesfor database design that emphasize thedescription of the structural aspects ofinformation in a domain (e.g., E/R mod-eling, normalization), and which in turnare used alongside mechanisms for de-scribing processes (e.g., dataflow dia-grams) to capture the semantics of com-plete applications. Although activebehavior is often closely linked to thestructures stored in a database, andrule actions carry out tasks that can beviewed as processes, it is not yet clearwhat techniques are most suitable for,or most easily adapted to address, thefunctionalities supported by activerules. In particular, given the require-ments of an application, design tech-niques should provide guidance on theaspects that should be supported usingactive mechanisms, and those that arebetter addressed using other facilities.

Where proposals have been made formethods with explicit support for activebehavior, this has often been as an ex-tension to an existing structural datamodel. For example, (ER)2 [Navathe etal. 1995] is an extension of the E/R



model to support the description ofevents and rules that can be mapped toactive rule facilities similar to thosefound in commercial relational data-bases. IFO2 adapts the modeling con-structs of the IFO semantic data model[Abiteboul and Hull 1987] for use indescribing composite events, and alsoincludes a mapping to an active rulelanguage, although in this case the des-ignated language must be more power-ful than in the case of (ER)2. Morecomprehensive facilities still, includingtemporal events, are provided byBichler and Schrefl [1994] in an ex-tended object-oriented modeling lan-guage. These approaches, however, allassume that active rules should surfaceexplicitly in the design method, whichtends to prejudge the question of whichparts of an application should be sup-ported using active techniques andwhich using other alternatives.

This has been the focus of the IDEAmethodology [Ceri and Fraternali 1997]which gives some initial insights on thistopic, and provides high-level descrip-tion languages which in the later stagesof development are mapped into low-level triggers (such as those found in acommercial DBMS).

8.2 Rule Analysis

The semantics of most active databasesystems in the literature are describedinformally; for representative examplessee Section 6, and papers such as Stone-braker et al. [1990] and Widom andFinkelstein [1990]. There are a numberof disadvantages to this approach: spe-cific descriptions may be incomplete orambiguous, it is often difficult to com-pare the functionality of different sys-tems, and there is no basis upon whichto build tools that support the formalanalysis of rule bases. Recently, formalspecifications have been developed foractive database systems using denota-tional semantics [Widom 1992; Coupayeand Collet 1995], Object-Z [Campin etal. 1997], and combined logic/opera-tional techniques [Fraternali and Tanca

1995; Fernandes et al. 1997], but al-though such proposals help to clarifythe informal definitions of specific sys-tems, they have not yet been used as abasis for reasoning about rule bases.

There are a number of different char-acteristics of rule behavior for which arule analyzer can search [Aiken et al.1992].

—Termination. Is rule processingguaranteed to terminate? Rule pro-cessing may fail to terminate when-ever a cycle exists in a graph in whichnodes represent rules and edges rep-resent Can-Trigger relationships—thetriggering graph. For example, in Fig-ure 9, any firing of rules R2 and R4 isguaranteed to terminate, but any fir-ing of rules R1 or R3 may initiate aseries of rule firings that fails to ter-minate.Static analysis of a rule base can indi-cate whether a set of rules may fail toterminate. For example, a straightfor-ward approach to the analysis of theCan-Trigger relationship would insertan edge from rule Ri to rule Rj if theaction of Ri performs an update to arelation that is being monitored bythe event of Rj. This approach is

Figure 9. Graph depicting possible rule trigger-ing dependencies.



conservative, in the sense that poten-tial nontermination will be detectedeven when in practice the rules willalways terminate. For example, con-sider the following rule definition thatrelates to the unary relation Rel withthe integer attribute num.

create rule R1 ason insert to Relif num . 10do insert into Rel values(5)

Using the approach described previ-ously, R1 in itself would be consideredto be a potential source of nontermi-nation, although in practice R1 isnever directly recursive because thetuple inserted by its action alwaysleads to the condition of the rule be-ing false. Less conservative ap-proaches to rule termination analysisthat examine the conditions and theactions of rules in more detail, butwhich are as a result more systemspecific, are presented in Baralis andWidom [1994] and Weik and Heurer[1995].

—Confluence. Is the result of ruleprocessing independent of the orderin which simultaneously triggeredrules are selected for processing? Ifthe policy Holder relation from Sec-tion 2 had an attribute NumStocks ,the role of this attribute could be in-terpreted differently by differentrules. For example, the following rulewould help to maintain NumStocks asthe number of items of stock held.

on insert to Owns orupdate to reg# of Owns orupdate to reg# of Holder

if ^change affects amount ofstock held by Holder h &

do ^update NumStocks at-tribute of h &

However, an alternative interpreta-tion would treat NumStocks as themaximum number of stocks that aHolder can own at any one time, giv-ing rise to the following rule.

on insert to Owns or updateto reg# of Owns or

update to reg# of Holderif ^amount of stock held by

Holder h is more than Num-Stocks &

do ^reduce range of stockheld by Holder h &

These rules clearly implement incon-sistent policies regarding stock hold-ing; if both rules have the same prior-ity and are present in the rule base atthe same time, then updates to thedatabase will nondeterministically af-fect what stock is held.Confluence can be understood by con-sidering that the firing of a rule inone database state may lead to thecreation of a new database state. Ifmore than one rule is triggered at thesame time, then more than one poten-tial successor state exists, as illus-trated in Figure 10 where the statesS2 and S3 are the successors of S1that result from the firing of rules Riand Rj, respectively. A rule base isconfluent if for any two rules Ri andRj triggered in any initial state S1, asingle final state S4 is guaranteed tobe reached regardless of the order in

Figure 10. Graph depicting confluent rule behav-ior.



which any subsequent simultaneouslytriggered rules are selected for firing(denoted as * in Figure 10). Note that,for example, the actions of rules Riand Rj may have triggered additionalrules as a side-effect of the transitionfrom S1 to states S2 and S3, and thatthe behaviors of these subsequentlytriggered rules have to be taken intoaccount when considering confluenceof the entire rule base. Work on con-fluence analysis has developed algo-rithms for analyzing complete rulebases [Aiken et al. 1992], for consider-ing the effect of an update on thetruth of a condition [Baralis and Wi-dom 1994; Levy and Sagiv 1993], andfor characterizing the contexts inwhich nonconfluent behavior may beexhibited [van der Voort and Siebes1994].

—Observable determinism. Is theeffect of rule processing as observedby a user of the system independentof the order in which triggered rulesare selected for processing? This no-tion seeks to extend deterministicrule system behavior beyond theboundaries of the database itself. Forexample, the following two rules im-plement a response which is confluentbut observably nondeterministic.

on êvent E1 &if ^condition C1 &do ^send message to user &

on êvent E1 &if ^condition C1 &do âbort &

In this example, if the first rule isscheduled for firing before the second,then the user receives a message andthe transaction over the database isaborted. By contrast, if the secondrule is scheduled before the first, thenthe transaction is aborted, but nomessage is sent to the user.

Initial research into the static analy-sis of active rule bases has not, to date,significantly eased the development ofactive applications. This is because suchrule analyzers are not generally sup-

plied with active systems, and becauseit is not always obvious what actionshould be taken when a potential sourceof nontermination or nonconfluence isdetected. There is a range of possiblechanges that can be made: rule priori-ties can be used to tailor the order inwhich rules fire, rule conditions or ac-tions can be modified to change theireffect, or rules may be seen to be imple-menting conflicting policies anddropped. The development of effectiverule analysis systems awaits furtherwork on communicating the results ofanalysis to users, as well as experiencebased upon the use of implemented ruleanalyzers.

8.3 Rule Debugging

Users may be reluctant to apply activefacilities because of anticipated prob-lems with maintenance, unforeseeablebehavior, and lack of control [Simon andKotz-Dittrich 1995], which motivatesthe development of debugging environ-ments that help in defining safe rulesets, that is, rules that comply with thetermination, confluence, and observabledeterminism properties previously de-scribed.

Unfortunately, these properties arenot always easy to ascertain for a fullyfledged rule language at compile time,and hence research on rule analysis hasfocused on formal declarative lan-guages. However, not all authors agreethat active rule systems should neces-sarily be associated with such lan-guages, and many implemented rulesystems are integrated with imperativedatabase programming languages[Buchmann 1994]. Furthermore, thefact that a rule base exhibits terminat-ing and confluent behavior does not initself imply that it is correct. Thus, asrule languages become more compli-cated, thereby increasing the range ofapplications for which they are suitable,the need for rule debugging environ-ments becomes increasingly pressing.

Unfortunately, traditional debuggermodels are not adequate for debugging



rules. Conventional debuggers provideexhaustive information on the state ofthe execution process (e.g., programvariables, subroutines, and the like),thereby allowing the user to monitor theevolution of this state information. Bycontrast, what makes rule debugging achallenging task are the insidious waysin which rules can interact. Interaction,rather than state, becomes the mainsource of incorrect or unexpected behav-ior, and this context-dependent controlexhibited by active rules imposes newdemands on the debugger.

Unlike traditional programming lan-guages, where sequential control isspecified both explicitly and staticallyby the programmer, active rules arefired dynamically by the system basedon the previous flow of events. There isthus no way to know in advance whichrules will be fired. Rules eligible for

firing, as represented by the conflict set,depend on the events raised (internal orexternal to the DBMS). Hence, it ismore appropriate to reveal the contextin which rules have been triggered (e.g.,the conflict set and the event base) thanto present a sequential trace of trig-gered rules. DEAR, a debugger for EX-ACT [Diaz et al. 1994], attempts to ad-dress this issue by showing theintertwined cycle of rules and events.Hence, the user can ascertain not onlywhich rules have been triggered, butalso whether the event triggering therule was raised from a top-level transac-tion instruction or a rule execution.Furthermore, when an event is raised,such a cycle permits identification of thecontext in which the event took place interms of recently triggered rules.

Figure 11 shows such an event-rulecycle for an immediate coupling mode.

Figure 11. An intertwined event-rule cycle.



The representation is a tree where theroot is artificially created (the corre-sponding node is labeled with root) andits direct descendants are the firstevents to be raised. Nodes can representeither events or rules, where eventnodes alternate with rule nodes. An arcfrom an event node to a rule nodemeans that the event has triggered therule. An arc from a rule node to anevent node means that the event wasproduced as a result of executing theaction of the rule. As execution pro-ceeds, the event/rule tree is constructeddepth-first. In Figure 11, event (put_projects,before,2#manager) happened be-fore (modify_method,before,2#manager),and the leftmost occurrence of rule 12#in-tegrity_rule before the leftmost occur-rence of rule 14#integrity_rule. More-over, Figure 11 also makes explicit theconflict set of simultaneously triggeredrules, once the conflicts among thoserules have been resolved by the rulemanager. An indication of the rules par-ticipating in this conflict set is usefulfor focusing on a restricted number ofrules where complex interactions canoccur.

Rather than building trees followingthe execution, an alternative investi-gated in the visual tool for rule analysisVITAL [Benazet et al. 1995] is to showthe trace in the triggering graph createdduring analysis (see Figure 9). A colorcode is used for each event state (i.e.,raised or not raised) and each rule state(i.e., inactive, triggered, or executed).As execution proceeds the displayed col-ors change, and a textual trace of theexecution is displayed in a separatedwindow. VITAL also proposes the use ofa statistics manager that calculates andrecords statistics on the behavior of therule processor (e.g., the number oftuples inserted, deleted, or modifiedduring a rule execution cycle, the num-ber of times a rule is triggered, etc).These data can be used, for instance, toidentify potentially infinite cycles, or tohelp find erroneous rule declarations.The former can be ascertained by moni-toring the size of relevant tables: if the

size tends to increase in a uniform way,it suggests that the cycle will not termi-nate. Erroneous rule condition declara-tions may be suspected if the number oftimes a rule is executed is very lowcompared to the number of times therule is triggered. Thus, features of sta-tistical data can point to potentially ab-normal behavior.

The preceding approaches have fo-cused mainly on displaying the inter-leaving of events and rules, but arerestricted to primitive events. The mon-itoring of composite event occurrences isa more complicated task due to thelarge number of occurrences that mayneed to be shown and the intricate waysin which events are combined to obtaincomposite event occurrences. A first ap-proach to this issue has been presentedas part of the Sentinel system [Chakra-varthy et al. 1995]. Sentinel provides apost-execution debugging tool where in-formation from the execution is storedin log files that are consulted by thedebugging tool to simulate runtime ac-tivities. An event tree is created whereprimitive events are leaf nodes andcomposite events are seen as parents oftheir component events. A color code isused to represent event status (detectedor not detected). This tree grows fromprimitive events to the root. In addition,a transaction tree describes the trigger-ing rule context: the root node repre-sents the top-level transaction, andchild nodes represent rules fired in thecontext of their parent node (either theuser transaction or a rule, as rules areexecuted as subtransactions). A colorcode is used to represent the differentstates of subtransactions: running, sus-pended, or committed. Whenever a ruleis fired, a line is drawn connecting thetransaction node of the current rule andthe triggering event. An example isgiven in Figure 12. The detection ofevents e1 and e2 leads to the happeningof the conjunction event e5, which inturn causes the triggering of rule R1(i.e., trans 111). This rule is fired in thecontext of the running transaction trans11, which is a child of transaction trans



1. In the first version of this system, allrules and events produced are shown,which could lead to cluttered visualiza-tions [Chakravarthy et al. 1995].

Despite the advances in rule debug-ging, more remains to be done (e.g.,customizable visualization of rule exe-cution, automatic generation of testdata), and different active rule systemfunctionalities are likely to be most ef-fectively presented to users using differ-ent visualizations.

9. CONCLUSIONS

Research into active databases has pro-ceeded along similar lines to early re-search into object-oriented databases, inthat there has been considerable exper-imentation, but relatively little work onstandardization or theory. This has re-sulted in a wide range of constructs,execution strategies, and software ar-chitectures being proposed that haveutility in different problem domains[Dittrich et al. 1995]. This survey hasreviewed research and developmentwork in active databases by: describingtasks that can benefit from active be-havior, presenting a framework thatcharacterizes important aspects of ac-tive functionality, describing a range ofrepresentative systems within the

framework, indicating how imple-mented systems support the principalfeatures described in the framework,and by outlining ongoing activity ontools that support the design and imple-mentation of applications that exploitactive technologies. In so doing, the aimhas been to identify the principal contri-butions made by researchers to date, toindicate how important ideas havemade their way into implemented sys-tems, to allow detailed comparison ofspecific proposals, and to suggest areasthat stand to benefit from future re-search results.

Future research is required on appli-cation and efficient implementation ofevent algebras, optimization of activerules, implementation and use of ruleanalyzers, tools that support design andmaintenance of rule bases, architec-tures for realtime active applications,distributed active functionality, and in-tegration of active behavior with deduc-tive and temporal facilities.

ACKNOWLEDGMENTS

We are grateful to our colleagues for useful dis-cussions on active database systems, includingAlex Buchmann, Andrew Dinn, Alvaro Fernandes,Ray Fernandez, Peter Gray, Jon Iturrioz, ArturoJaime, and Howard Williams.

REFERENCES

ABITEBOUL, S. AND HULL, R. 1987. IFO: A for-mal semantic database model. ACM Trans.Database Syst. 12, 4 (Dec.), 525–565.

AGRAWAL, R., COCHRANE, R., AND LINDSAY, B.1991. On maintaining priorities in a produc-tion rule language. In Proceedings of the Sev-enteenth VLDB, G. Lohman, A. Sernadas, andR. Camps, Eds., Morgan-Kaufmann, San Ma-teo, CA, 479–487.

AIKEN, A., WIDOM, J., AND HELLERSTEIN, J. 1992.Behaviour of database production rules: Ter-mination, confluence, and observable deter-minism. In SIGMOD Rec. 21, 59–68.

AMOUROUX, R. 1995. Reactive services for sup-porting tool integration in a development en-vironment. In Proceedings on Technology ofObject-Oriented Languages and Systems(TOOLS), 61–70.

BACON, J., BATES, J., HAYTON, R., AND MOODY,K. 1995. Using events to build distributedapplications. In Proceedings of the Interna-

Figure 12. Tracing composite events in Sentinel.



tional Workshop on Services in Distributedand Networked Environments (SDNE) (Whis-tler, BC), 148–155.

BARALIS, E. AND WIDOM, J. 1994. An algebraicapproach to rule analysis in expert databasesystems. In Proceedings of the TwentiethVLDB, J. Bocca, M. Jarke, and C. Zaniolo,Eds., Morgan-Kaufmann, San Mateo, CA,475–486.

BARALIS, E. AND WIDOM, J. 1995. Using deltarelations to optimize condition evaluation inactive databases. In Proceedings of the SecondInternational Workshop on Rules In DatabaseSystems (RIDS), T. Sellis, Ed., Springer-Ver-lag, 292–308.

BARGHOUTI, N. AND KRISHNAMURTHY, B. 1995.Using event contexts and matching con-straints to monitor software processes. In Pro-ceedings of the ICSE, 83–92.

BATES, P. 1995. Debugging heterogeneous dis-tributed systems using event-based models ofbehaviour. ACM Trans. Comput. Syst. 13, 1,1–31.

BAYER, P. AND JONKER, W. 1994. A frameworkfor supporting triggers in deductive data-bases. In Proceedings of the First Interna-tional Workshop on Rules in Database Sys-tems, N. Paton and M. Williams, Eds.,Springer-Verlag, 316–330.

BEERI, C. AND MILO, T. 1991. A model for activeobject oriented database. In Proceedings of theSeventeenth International Conference on VeryLarge Data Bases (Barcelona), R. C. G. M.Lohman and A. Sernadas, Eds., Morgan-Kauf-mann, San Mateo, CA, 337–350.

BENAZET, E., GUEHL, H., AND BOUZEGHOUB, M.1995. VISUAL: A visual tool for analysis ofrule behaviour in active databases. In Pro-ceedings of the Second International Work-shop on Rules in Database Systems, T. Sellis,Ed., Springer-Verlag, 182–196.

BICHLER, P. AND SCHREFL, M. 1994. Active ob-ject-oriented database using active object/be-haviour diagrams. In Proceedings of theFourth International Workshop on ResearchIssues in Data Engineering (RIDE-ADS’94),163–171.

BLUE, A., BROWN, B., AND GRAY, W. 1988. Animplementation of alerters for health districtmanagement. In Proceedings of the Sixth Brit-ish National Conference on Databases (BN-COD), W. Gray, Ed., 125–140.

BRANDING, H., BUCHMANN, A., KUDRASS, T., ANDZIMMERMANN, J. 1994. Rules in an opensystem: The REACH rule system. In Rules inDatabase Systems, N. Paton and M. Williams,Eds., Springer-Verlag, 111–126.

BRANT, D. AND MIRANKER, D. 1993. Index sup-port for rule activation. SIGMOD Rec. 42–48.

BUCHMANN, A. 1994. Current trends in activedatabases: Are we solving the right problems.In Information Systems Design and Multime-

dia, Proceedings of the Basque InternationalWorkshop on IT, C. Chrisment, Ed., CepaduesEditions, 121–133.

BUCHMANN, A., ZIMMERMANN, J., BLAKELY, J., ANDWELLS, D. 1995. Building an integrated ac-tive OODBMS: Requirements, architecture,and design decisions. In Proceedings of IEEEData Engineering, 117–128.

CAMPIN, J., PATON, N., AND WILLIAMS, M. 1997.Specifying active database systems in an ob-ject-oriented framework. Softw. Eng. Knowl.Eng. 7(1), 101–123.

CERI, S. AND FRATERNALI, P. 1997. DesigningApplications with Objects and Rules: TheIDEA Methodology. International Series onDatabase Systems and Applications, Addison-Wesley Longman, Reading, MA.

CERI, S. AND WIDOM, J. 1993. Managing seman-tic heterogeneity with production rules andpersistent queries. In Proceedings of the Nine-teenth International Conference on Very LargeData Bases, R. Agrawal, S. Baker, and D.Bell, Eds., Morgan-Kaufmann, San Mateo,CA, 108–119.

CERI, S. AND WIDOM, J. 1991. Deriving produc-tion rules for incremental view maintenance.In Proceedings of the Seventeenth Interna-tional Conference on Very Large Data Bases,R. C. G. M. Lohman and A. Sernadas, Eds.,Morgan-Kaufmann, San Mateo, CA, 577–589.

CERI, S., FRATERNALI, P., PARABOSCHI, S., ANDTANCA, L. 1996. Active rule managementin Chimera. In Active Database Systems: Trig-gers and Rules for Active Database Processing,J. Widom and S. Ceri, Eds., Morgan-Kauf-mann, San Mateo, CA, 151–175.

CERI, S., GOTTLOB, G., AND TANCA, L. 1990.Logic Programming and Databases, Springer-Verlag, Berlin.

CHAKRAVARTHY, S. 1989. Rule management andevaluation: An active DBMS perspective. SIG-MOD Rec. 18, 3, 20–28.

CHAKRAVARTHY, S., ANWAR, E., MAUGIS, L., ANDMISHRA, D. 1994a. Design of Sentinel: Anobject-oriented DBMS with event-based rules.Inf. Softw. Technol. 36, 9, 555–568.

CHAKRAVARTHY, S., KRISHNAPRASAD, V., ANWAR, E.,AND KIM, S.-K. 1994b. Composite events foractive databases: Semantics, contexts and de-tection. In Proceedings of the Twentieth Inter-national Conference on Very Large DataBases, J. Bocca, M. Jarke, and C. Zaniolo,Eds., Morgan-Kaufmann, San Mateo, CA,606–617.

CHAKRAVARTHY, S., TAMIZUDDIN, Z., AND ZHOU,J. 1995c. A visualization and explanationtool for debugging ECA rules in active data-bases. In Proceedings of the Second Interna-tional Workshop on Rules in Database Sys-tems, T. Sellis, Ed., Springer-Verlag, 196–209.

CHANDRA, R. AND SEGEV, A. 1994. Active data-



bases for financial applications. In Proceed-ings of the Fourth International Workshop onResearch in Data Engineering (RIDE-ADS), J.Widom and S. Chakravarthy, Eds., IEEE, 46–52.

COLLET, C. AND MANCHADO, J. 1995. Optimiza-tion of active rules with parallelism. In Pro-ceedings of Active and Real Time DatabaseSystems (ARTDB), M. Berndtsson and J.Hansson, Eds., Springer-Verlag, 82–103.

COLLET, C., COUPAYE, T., AND SVENSEN, T. 1994.NAOS: Efficient and modular reactive capa-bilities in an object-oriented database system.In Proceedings of the Twentieth VLDB Confer-ence, J. Bocca, M. Jarke, and C. Zaniolo, Eds.,Morgan-Kaufmann, San Mateo, CA, 132–143.

COUPAYE, T. AND COLLET, C. 1995. Denotationalsemantics for an active rule execution model.In Proceedings of the Second InternationalWorkshop on Rules in Database Systems, T.Sellis, Ed., Springer-Verlag, 36–50.

DAYAL, U. 1989. Active database managementsystems. SIGMOD Rec. 18, 3, 150–169.

DAYAL, U., BUCHMANN, A., AND MCCARTHY, D.1988. Rules are objects too: A knowledgemodel for an active object oriented databasesystem. In Proceedings of the Second Interna-tional Workshop on OODBS, LNCS 334, K.Dittrich, Ed., Springer-Verlag, 129–143.

DAYAL, U., HSU, M., AND LANDIN, R. 1990. Or-ganising long-running activities with triggersand transactions. In Proceedings of the SIG-MOD Conference, ACM, New York, 204–214.

DEUX, O. ET AL. 1990. The story of O2. IEEETrans. Knowl. Data Eng. 2, 1 (March), 91–108.

DIAZ, O. 1992. Deriving rules for constraintmaintenance in an object-oriented database.In Proceedings of the International Conferenceon Databases and Expert Systems DEXA,I. R. A. M. Tjoa, Ed., Springer-Verlag, 332–337.

DIAZ, O. AND JAIME, A. 1997. EXACT: an EX-tensible approach to ACTive object-orienteddatabases. VLDB J. 6, 4, 282–295.

DIAZ, O., JAIME, A., AND PATON, N. 1994a.DEAR: A DEbugger for Active Rules in anobject-oriented context. In Proceedings of theFirst International Workshop on Rules in Da-tabase Systems, N. Paton and M. Williams,Eds., Springer-Verlag, 180–193.

DIAZ, O., JAIME, A., PATON, N., AND AL QAIMARI, G.1994b. Supporting dynamic displays usingactive rules. SIGMOD Rec. 23, 1, 21–26.

DIAZ, O., PATON, N., AND GRAY, P. 1991. Rulemanagement in object-oriented databases: Auniform approach. In Proceedings of the Sev-enteenth International Conference on VeryLarge Data Bases (Barcelona), G. Lohman, A.Sernadas, and R. Camps, Eds., Morgan-Kauf-mann, San Mateo, CA, 317–326.

DINN, A., PATON, N., WILLIAMS, M., AND FER-NANDES, A. 1996. An active rule languagefor ROCK & ROLL. In Proceedings of theFourteenth British National Conference onDatabases, Springer-Verlag, 36–55.

DITTRICH, A. K. 1993. Adding active functional-ity to an object-oriented database—a layeredapproach. In Proceedings of Datenbank-systeme in Buro (Braunschweig, Germany).

DITTRICH, K., GATZIU, S., AND GEPPERT, A.1995. The active database management sys-tem manifesto: A rulebase of ADBMS fea-tures. In Rules In Database Systems: Proceed-ings of the Second International Workshop, T.Sellis, Ed., Springer-Verlag, 3–17.

ETZION, O. 1993. PARDES—a data-driven ori-ented active database model. SIGMOD Rec.22, 1, 7–14.

ETZION, O., GAL, A., AND SEGEV, A. 1994. Datadriven and temporal rules in PARDES. InProceedings of the First International Work-shop on Rules in Database Systems, N. Patonand M. Williams, Eds., Springer-Verlag, 92–108.

FABRET, F., REGNIER, M., AND SIMON, E. 1993.An adaptive algorithm for incremental evalu-ation of production rules in databases. InProceedings of the Nineteenth InternationalConference on Very Large Data Bases, R.Agrawal, S. Baker, and D. Bell, Eds., Morgan-Kaufmann, San Mateo, CA, 455–466.

FERNANDES, A., WILLIAMS, M., AND PATON, N.1997. A logic-based integration of active anddeductive databases. New Gen. Comput. 15, 2,205–244.

FERNANDEZ, R. AND DIAZ, O. 1995. Reactive be-haviour support: Themes and variations. InProceedings of the Second International Work-shop on Rules in Database Systems, T. Sellis,Ed., Springer-Verlag, 69–85.

FORGY, C. 1982. Rete: A fast algorithm for themany pattern/many object pattern matchproblem. Artif. Intell. 19, 17–37.

FRATERNALI, P. AND TANCA, L. 1995. A struc-tured approach to the definition of the seman-tics of active databases. ACM Trans. Data-base Syst. 20, 4, 414–471.

GATZIU, S. AND DITTRICH, K. 1994. Events in anactive object-oriented database. In Proceed-ings of the First International Workshop onRules in Database Systems, N. Paton and M.Williams, Eds., Springer-Verlag, 23–39.

GATZIU, S., GEPPERT, A., AND DITTRICH, K. 1991.Integrating active concepts into an object-ori-ented database system. In Proceedings of theThird Workshop on Database ProgrammingLanguages, P. Kanellakis and J. Schmidt,Eds., Morgan-Kaufmann, San Mateo, CA.

GEHANI, N. AND JAGADISH, H. 1991. ODE as anActive Database: Constraints and Triggers. InProceedings of the Seventeenth InternationalConference on Very Large Data Bases (Barce-



lona), R. C. G. M. Lohman and A. Sernadas,Eds., Morgan-Kaufmann, San Mateo, CA,327–336.

GEHANI, N., JAGADISH, H., AND SHMUELI, O. 1992.Event specification in an active object-ori-ented database. SIGMOD Rec., 81–90.

GEPPERT, A. AND DITTRICH, K. 1994. Rule-basedimplementation of transaction model specifi-cations. In Proceedings of the First Interna-tional Workshop on Rules in Database Sys-tems, N. Paton and M. Williams, Eds.,Springer-Verlag, 127–142.

GEPPERT, A., BERNDTSSON, M., LIEUWEN, D., ANDRONCANCIO, C. 1998. Performance evalua-tion of object-oriented active database man-agement systems using the beast benchmark.Tapos 4, 4.

HANSON, E. 1992. Rule condition testing andaction execution in Ariel. In Proceedings ofSIGMOD, ACM, New York, 49–58.

HANSON, E. N. AND WIDOM, J. 1993. An over-view of production rules in database systems.Knowl. Eng. Rev. 8, 2, 121–143.

HARDER, T. AND ROTHERMEL, K. 1993. Concur-rency control issues in nested transactions.VLDB J. 2, 1, 39–74.

HARRISON, J. AND DIETRICH, S. 1994. Integrat-ing active and deductive rules. In Proceedingsof the First International Workshop on RulesIn Database Systems, N. Paton and M. Wil-liams, Eds., Springer-Verlag, 288–305.

HSU, M., LADIN, R., AND MCCARTHY, D. 1988.An execution model for active data base man-agement systems. In Proceedings of the Inter-national Conference on Data and KnowledgeBases, 171–179.

KIERNAN, G., DE MAINDREVILLE, C., AND SIMON, E.1990. Making deductive databases a practi-cal technology: A step forward. In Proceedingsof the ACM SIGMOD Conference, H. Garcia-Molina and H. Jagadish, Eds., 237–246.

KIM, W., LEE, Y., AND SEO, J. 1992. A frame-work for supporting triggers in object-ori-ented database systems. Int. J. Intel. Coop.Inf. Syst. 1, 1, 127–143.

KOSCHEL, A., KRAMER, R., VON BULTZINGSLOEWEN,G., BLEIBEL, T., KRUMLINDE, P., SCHMUCK, S.,AND WEINAND, C. 1997. Configurable activefunctionality for Corba. In Proceedings of theEleventh ECOOP Workshop 7 on CORBA.

KOTZ, A., DITTRICH, K., AND MULLE, J. 1988.Supporting semantic rules by a generalizedevent/trigger mechanism. In Proceedings ofAdvance in Database Technology, EDBT(Venice), 76–91.

KULKARNI, K., MATTOS, N., AND COCHRANE, R.1999. Active database features in SQL-3. InActive Rules in Database Systems. N. Paton,Ed., Springer-Verlag.

LEVY, A. AND SAGIV, Y. 1993. Queries indepen-dent of updates. In Proceedings of the Nine-

teenth VLDB, R. Agrawal, S. Baker, and D.Bell, Eds., Morgan-Kaufmann, San Mateo,CA, 171–181.

MIRANKER, D. 1987. TREAT: A better match al-gorithm for AI production systems. In Pro-ceedings of AAAI, 42–47.

MOSS, E. ED. 1985. Nested Transactions: AnApproach to Reliable Distributed Computing.MIT Press, Cambridge, MA.

NAQVI, W. AND IBRAHAM, M. 1994. Rule andknowledge management in an active databasesystem. In Proceedings of the First Interna-tional Workshop on Rules in Database Sys-tems, N. Paton and M. Williams, Eds., Spring-er-Verlag, 58–69.

NAVATHE, S., TANAKA, A., MADHAVAN, R., AND GAN,Y. H. 1995. A methodology for applicationdesign using active database technology.Tech. Report RL-TR-95-41, Rome Laboratory.

ORFALI, R., HARKEY, D., AND EDWARDS, J. 1996.The Essential Distributed Objects SurvivalGuide. Wiley, New York.

PATON, N., ED. 1999. Active Rules in DatabaseSystems. Springer-Verlag.

PATON, N., DIAZ, O., AND BARJA, M. 1993.Combining active rules and metaclasses forenhanced extensibility in object-oriented sys-tems. Data Knowl. Eng. 10, 45–63.

PATON, N., DIAZ, O., WILLIAMS, M., CAMPIN, J.,DINN, A., AND JAIME, A. 1994. Dimensionsof active behaviour. In Proceedings of the FirstInternational Workshop on Rules in DatabaseSystems, N. Paton and M. Williams, Eds.,Springer-Verlag, 40–57.

PATON, N., DOAN, D., DIAZ, O., AND JAIME,A. 1996. Exploitation of object-orientedand active constructs in database interfacedevelopment. In Proceedings of the Third In-ternational Workshop on Interfaces to Data-base Systems, J. Kennedy and P. Barclay,Eds., Springer-Verlag.

REDDI, S., POULOVASSILIS, A., AND SMALL, C. 1995.Extending a functional DBPL with ECA-rules. In Proceedings of the Second Interna-tional Workshop on Rules in Database Sys-tems, T. Sellis, Ed., Springer-Verlag, 101–115.

SCHWIDERSKI, S. 1996. Monitoring the behav-iour of distributed systems. Ph.D. Thesis,University of Cambridge, United Kingdom.

SIMON, E. AND KOTZ-DITTRICH, A. 1995. Prom-ises and realities of active database systems.In Proceedings of the 21st International Con-ference on Very Large Data Bases, U. Dayal,P. Gray, and S. Nishio, Eds., Morgan-Kauf-mann, San Mateo, CA, 642–653.

SKOLD, M. AND RISCH, T. 1995. Using partialdifferencing for efficient monitoring of de-ferred complex rule conditions. In Proceedingsof IEEE Data Engineering.

STONEBRAKER, M. AND KEMNITZ, G. 1991. ThePOSTGRES next-generation database man-



agement system. Commun. ACM 34, 10 (Oct.),78–92.

STONEBRAKER, M., JHINGRAN, A., GOH, J., ANDPOTAMIANOS, S. 1990. On rules, procedures,caching and views in database systems. InProceedings of ACM SIGMOD, 281–290.

THOMAS, I. AND JONES, A. 1995. Design and im-plementation of an active object-oriented da-tabase supporting construction of databasetools. In Proceedings of the Second Interna-tional Workshop on Rules in Database Sys-tems, T. Sellis, Ed., Springer-Verlag, 147–164.

VAN DER VOORT, L. AND SIEBES, A. 1994.Enforcing confluence of rule execution. In Pro-ceedings of the First International Workshopon Rules in Database Systems, N. Paton andM. Williams, Eds., Springer-Verlag, 194–207.

VON BUELTZINGSLOEWEN, G., KOSCHEL, A., LOCK-EMANN, P., AND WALTER, H. 1999. ECAfunctionality in a distributed environment. InActive Rules in Database Systems. Springer-Verlag.

WANG, Y.-W. AND HANSON, E. 1992. A perfor-mance comparison of the Rete and TREATalgorithms for testing database rule condi-tions. In Proc. of Data Engineering, 88–97.

WEIK, T. AND HEURER, A. 1995. An algorithmfor the analysis of termination of large triggersets in an OODBMS. In Proceedings of Active

Real Time Database Systems (ARTDB), M.Berndtsson and J. Hansson, Eds., Springer-Verlag, 158–169.

WELLS, D., BLAKELEY, J., AND THOMPSON, C. 1992.Architecture of an open object-oriented data-base management system. IEEE Comput. 25,10 (Oct.).

WIDOM, J. 1992. A denotational semantics forthe Starburst production rule language. SIG-MOD Rec. 21, 3, 4–9.

WIDOM, J. AND FINKELSTEIN, S. 1990. Set-ori-ented production rules in relational databasesystems. In Proceedings of the ACM SIGMODInternational Conference on Management ofData, 259–270.

WIDOM, J., COCHRANE, R., AND LINDSAY, B. 1991.Implementing set-oriented production rulesas an extension to Starburst. In Proceedingsof the Seventeenth International Conference onVery Large Data Bases (Barcelona),R. C. G. M. Lohman and A. Sernadas, Eds.,Morgan-Kaufmann, San Mateo, CA, 275–286.

WINSTON, P. 1984. Artificial Intelligence (Sec-ond ed.). Addison-Wesley, Reading, MA.

ZANIOLO, C. 1994. A unified semantics for ac-tive and deductive databases. In Rules inDatabase Systems, N. Paton and M. Williams,Eds., Springer-Verlag.

Received November 1994; revised February 1998; accepted June 1998



Active Database Systems - Université libre de...

Documents

Transcript of Active Database Systems - Université libre de...