Database Management Sys4

8/14/2019 Database Management Sys4

1/10

The Architecture Of An Active Data Base Management System*Dennis R. McCarthyXerox Advanced nformation Technology4 CambridgeCenterCambridge, MA 02142ARPANET [email protected]

UmeshwarDayalDigital Equipment Corporation CambridgeResearch aboratoryOne Kendall SquareCambridge, MA 02139ARPANET [email protected]

AbstractThe HiPAC project is investigating active, time-constraineddatabase managment. An active DBMS is one whichautomatically executes specified actions when speciifedconditions arise. HiPAC has proposed Event-Condition-Action (ECA) rules as a formalism for active databasecapabilities. We have also developed an execution modelthat speicifes how these ules are processedn the context ofdatabase ransactions. The additional functionality providedby ECA rules makes new demands on the design of anactive DBMS. In this paper we propose an architecture foran active DBMS that supports ECA rules. Thisarchitecture provides new forms of interaction, in support ofECA rules, between application programs andthDBMS.This leads to a new paradigm for constructingdatabase pplications.

Permission to copy without fee all or part of this material is granted provided thatthe copies are not made or distributed for direct commercial advantage, the ACMcopyright notice and the title of the publication and its date appear, and notice isgiven that copying is by permission of the Association for Computing Machinery.To copy othewise, or to republish, requires a fee and/or specific pemksion.0 1989 ACMO-89791-317-5/89/0005/0215 $1.50

1. INTRODUCTIONConventional databasemanagementsystemsare passive, nthe sense that they only manipulate data in response toexplicit requests rom applications. The HiPAC project isinvestigating active, time-constraineddatabasemanagement[DAY88a]. An active DBMS is a DBMS that allows usersto specify actions to be taken automatically, without userintervention, when certain conditions arise. Active DBMScapabilities can be traced back to the ON conditions ofCODASYL [COD73]. Triggers and assertions wereproposed for System R as a mechanism for enforcingintegrity constraints [ESW75,ESW76]. Declarative rulesfor expressing relationships between data items[MOR83,ST086] are another form of active DBMScapability. Simple triggers are now appearing incommercial DBMS products [SYB87], and automaticenforcementof referential integrity constraints s included inthe ANSI SQL2 standard.*This work was supported by the Defense Advanced ResearchProjects Agency and by the Rome Air Development Centerunder Contract No. F30602-87-C-0029. The views andconclusions contained in this report are those of the authorsand do not necessarily represent the official policies of theDefense Advanced Research projects Agency, the Rome AirDevelopment Center, or the U.S. Government.

215


2/10

The HiPAC project has proposed Event-Condition-Action(ECA) rules as a general formalism that subsumesmost ofthese active DBMS functions, which previously wereimplemented by special purpose mechanisms. We havedeveloped a knowledge model lDAY88b] that describes hesemanticsof ECA rules, and an execution model [HSU88]that specifies how these rules are processed n databasetransactions. We have also begun work on timeconstrainedscheduling of databaseransactions SUCSS].ECA rules provide active database apabilities beyond whatis found in a conventional, passive DBMS. The design ofan active DBMS must provide support for implementingthis additional functionality. This paper proposes anarchitecture for an active, object-oriented DBMS thatimplementsour knowledge model and execution model.The next two sections contain overviews of the HiPACknowledge model and execution model, respectively.Section 4 then describes how applications interact withHiPAC in using ECA rules. Section 5 describes theinternal structure of HiPAC to support rule processing, andSection 6 shows how the components of the HiPACarchitecture interact to process a rule. Finally, Secticq 7describes the implementation status of HiPAC, and ourplans for future work.2. KNOWLEDGE MODEL: RULES AS OBJECTSCentral to the HiPAC knowledge model is the concept ofEvent-Condition-Action (ECA) rules. The semantics ofECA rules are straightforward when the event occurs (issignalled), evaluate the condition; and, if the condition issatisfied, execute the action. Integrity constraints, accessconstraints, derived data, alerters, and other active DBMSfeaturescan all be expressedas ECA rules. HiPAC usesanobject-oriented data model (the details of which areunimportant for this paper), and rules are first-class databaseobjects, subject to the same operations as user-definedobjects (plus some special operations).In this section, we describe the attributes of rule objects,the operations defined on rule objects, and the architecturalimplications of supporting ECA rules.2.1 Rule AttributesThe attributes of rules are:Event The event that triggers the rule (i.e.,causes HiPAC to evaluate the rulescondition). Typed formal argumentsmaybe defined for the event; these are boundto actual arguments when the event isdetected. Event occurrences and theargument bindings are reported in anevent signal.Condition A collection o f queries that are evaluatedwhen the rule is triggered by its event.

Action The action that is executedwhen the ruleis triggered and its condition is satisfied.E-C Coupling A coupling mode that specifies when thecondition is evaluated relative to thetransaction in which the triggering eventis signalled.C-A Coupling A coupling mode that specifies when the

action is executed relative to thetransaction in which the condition isevaluated.(Rules can have other attributes; the ones listed here arethose which determine he processing.)The event for a rule can be a primitive event, or acombination of primitive events. The primitive events are:1. DatabaseOperations: data definition, data manipulation,transaction control. The description of a databaseeventspecifies the operation type and its parameters. Thesignal includes the operation and its actual arguments

(e.g., the object instances being modified, and the oldand new values of the modified objectsattributes).2. Temporal Events: absolute, relative, periodic. Thedescription of a temporal event specifies an absolutetime; some other event (the baseline) and a relative timeoffset from the baseline; or a baseline and a period;optional descriptive information may also be specified.The signal includes the absolute time at which teh eventoccurred and the optional information.3. External Notification: application defined events. Thedescription of an external event specifiesarbitrary forma lparameters from the application program. The signal

includes the binding of these ormal parameters o actualarguments in the execution of the application programin which the event occurs.Primitive events can be combined using disjunction andsequenceoperators o specify composite events. The eventspecification can also be omitted from a rule definition. Inthis case, HiPAC derives the event specification from thecondition.The condition is a collection of queries expressed in anobject-oriented DML. The queries may refer to argumentsin the event signal. The condition is satisfied if all of thesequeries produce non-empty results. The results of thesequeries are passed on to the action, together with theargumentbindings obtained from the event signal.The action is a sequence of operations. These can bedatabase operations or external requests to applicationp*grams*The E-C coupling is the relationship, relative to transactionboundaries, between the triggering event and the conditionevaluation. There are three possible coupling m odes:

216


3/10

1. immediate: when the triggering event occurs, evaluatethe condition immediately (i.e., preempt the processingof the remaining steps of the transaction) in the sametransaction.2. separate:when the triggering event occurs, evaluate thecondition in a separate ransaction.

Rule conditions can be complex, and rules with complexconditions can fire frequently. HiPAC must provideefficient condition evaluation, using techniques such asmultiple query optimization, incremental evaluation, andmaterialization o f derived data (A range of techniques isdescribedn lDAY88al.)3. EXECUTION MODEL: RULE FIRINGS AND3. deferred: evaluate the condition in the same ransaction TRANSACTIONS

as the triggering event, but when that transactionterminates.The samemodes are available for the C-A coupling, whichspecifies he relationship, relative to transaction boundaries,between he evaluation of the condition and the execution ofthe action.2.2 Rule OperationsSince rules are database objects, they are subject to theoperations common to all database objects: creation,modification, deletion. In addition, there are operationsspecific to rules that affect rule processing:

When a rule fires, database operations are performed as partof condition evaluation and action execution. Thesedatabase operations are executed concurrently withapplication transactions and other rule firings. The HiPACexecution model [HSUSS] describes how rules fire indatabase ransactions, and the relationships among thesetransactions. The execution model consists of a nestedtransaction model, and an assignment of conditionevaluation and action execution to transactions based oncoupling.3.1 Nested Transactions

Fire Evaluate the rules condition and, if it issatisfied, execute the rules action (subject to thecoupling mode specifications).Disable Disable automatic rule firing for its event (orsome subset of the events that cause he rule tofire).Enable Enable rule firing for its event.HiPAC normally fires a rule automatically when its eventoccurs. A rule can also be manually fired using the fireoperation. Automatic firing can be disabled using thedisable operation, and re-enabled using the enableoperation.

In a nested ransaction model lMOS851 there are two typesof transactions: top level transactions and nestedtransactions (also called subtransactions). A nestedtransaction is wholly contained within another transaction,called its parent. The parent of a nested ransactioncan be atop level transaction or another nested transaction. Atransaction can have more than one subtransaction, andsibling subtransactions can execute concurrently. Ourmodel assumes hat a parent transaction s suspendedwhileits subtransactions xecute.

As database objects, rules are subject to transactionsemantics. A transaction must obtain the appropriate lockon a rule before performing an operation on that rule.Firing requires a read ock. All operations hat update ules(create,modify, delete, enable, disable) require write locks.(Note that we think of enable and disable as modifyinga rule, insofar as they modify the ability of an event signalto fire the rule.)

Top level transactions, ike the usual database ransactions,are atomic,serializable, and permanent. Nested ransactionsare atomic. Concurrently executing sibling subtransactionsare serializable. The effects of a subtransaction do notbecome permanent until it, and all of its ancestors hrougha top transaction, commit. When a transaction aborts, itseffectsand the effectsof all of its descendants re discarded.3.2 Coupling Modes and Transactions

2.3 Architectural ImplicationsTo support ECA rules, HiPAC must first have the abilityto determine when events have occurred. HiPAC mustdetect primitivedatabase events, receive signals for externaland temporal events from application or system processes,infer complex events from the primitive events, and matchthe event signals against rule event specifications todeterminewhich rules are triggered.

When a rule fires, a transaction is created and the rulescondition is evaluated n that transaction. If the rules E-Ccoupling mode s immediate or deferred, hen the transactionis a subtransaction of the transaction containing thetriggering event. The parent transaction is suspendedwhilethis subtransaction executes. For immediate coupling, thecondition evaluation subtransaction s created and executedat the point where the triggering event occurs. For deferredcoupling, the condition evaluation subtransaction s createdand executed ust prior to its parent transaction committing.If the rules E-C coupling mode is separate, hen conditionevaluation takes place in a top level transaction thatexecutesconcurrently with the triggering transaction.

After determining that a rule has been triggered by an event,HiPAC must schedule condition evalution and actionexecution according to the rules coupling modes.

If the rules condition is satisfied, then another transactionis created and the rules action is executed in thattransaction. The particulars of this transaction are

217


4/10

determined by the rules C-A coupling mode, in a manneranalogous o that describedabove or condition evaluation.If an event triggers more than one rule, then a conditionevaluation transaction is created for each rule. For ruleswith the sameevent and E-C coupling mode, the conditionevaluation transaction will execute concurrently. Similarly,for rules with the sameevent and C-A coupling, the actionexecution transactions will execute concurrently. Thusthere is no conflict resolution policy that chooses a singlerule to fire, or a serial order in which to fire all of the rules.Instead, all of the rules fire concurrently as siblingtransactions. The correcmesscriteria is serializability, andthis is enforced by the HiEAC transaction manager.When a rule fires, its action can include an operation thattriggers another rule. If both rules have immediatecoupling for their conditions, then the original triggeringtransaction will have a subtransaction for the first rulescondition evaluation, and this subtransaction will in turnhave a subtransaction for evaluating the second rulescondition. Thus, cascading rule firings produce a tree ofnested ransactions.

3.3 Architectural implicationsAn active DBMS supporting ECA rules must haveconcurrencycontrol and recovery mechanisms or the nestedtransaction model. (Algorithms are given in [HSUSS].) Itmust create transactions or rule firings and schedule thosetransactions,as describedabove.4. A PARADIGM FOR ACTIVE DBMS

APPLICATIONSEven in those DBMSs that provide some form of activedatabase acilities, both the events that trigger actions andthe actions that they trigger are limited to databaseoperations. Consider triggers in System R and Sybase.The event for a trigger is an insert, update, or deleteoperation on a table; the action is expressed n SQL. Incontrast, HiPAC allows rule events to be defined by theapplication, and allows rule actions to contain requests oapplications. The result is a whole new paradigm forbuilding database pplications.

databaseoperation

Application

Aevent application transactionsignal operation operation

* t IHiPAC

Figure 4.1 Interface Betweenan Application Programand HiPAC

4.1 The interface Between Applications andHIPACFigure 4.1 depicts the interface between an applicationprogram and HiPAC. This interface is divided into fourmodules. Two of these provide the ususal DBMSfunctionality, and the other two are unique to HiPAC. Theformer are the modules that support operations on data andtransactions. The latter are the modules that containoperations on events, and application-specific operations.

(types) and operations on instances of those classes.Applications manipulate data by invoking those operationsthrough this interface. Note that the execution of such anoperation on a databaseobject is an event that can be usedin defining a rule.The operations on transactions are create, commit, andabort Recall that HiPAC uses a nested ransaction model.Applications can create and terminate subtransactions aswell as top level transactions.

The operations on data encompass ata definition as well asdata manipulation. Since HiPAC uses an object-oriented The event operations module provides two operations ondata model, data definition consists of defining classes events: define and signal. This interface allows applicationsto define and signal their own events. After an application-

218


5/10

specific event has been defined, it can be used in creatingone or more rules. Then, when the application signals theevent, HiPAC will fire the rule. The definition of an eventspecifies the data to be included in the event signal. Thisdata can be accessed y the rules condition and action.The last module, application operations, allows a reversalof roles in which HiPAC becomes the client and theapplication becomes he server. HiPAC allows requests oapplication programs o be included in the action for a rule.When the rule fires and the action is executed, HiPAC willcall the application program the execute the operation.This provides a new medium for interaction amongapplication programs. One program can can send a requestto another program either directly (e.g., IPC m essage),orindirectly through a rule firing.

A mechanismmust be provided for communicating requestsfrom the Rule Manager to applications. In most systems,the DBMS and application run in different addressspaces(processes), sometimes on different machines. Thecommunication mechanism is already present for sendingrequests from the applications to the DBMS, and repliesback to the applications. In most cases, the sameunderlying operating system acility can be used to reversethe direction in which requestsand replies are transmitted.4.2 An Example ApplicationThe first application implemented over HiPAC was aSecurities Analysts Assistant (SAA). The purpose of thisapplication is to deliver information to an analysts display,and to automatically execute radesaccording to the analytsinstructions. This application is shown in Figure 4.2. Itconsistsof programs and rules.

database eventoperation signal

SAA Application

application11111111perationHiPAC

&..Itransactionoperation

Figure 4.2 An Example of an Active DatabaseApplication

The SAA consistsof three application programs:Ticker Updates the current prices of securities in thedatabasebasedon price quotes read from a wireservice.

Display Displays prices, trades, portfolios and otherinformation on an analysts workstation.Trader Executes trades by transmitting requests to atrading service and updating the clients portfoliowhen the reply is received.

219


6/10

There would be severalcopies of eachprogram running: oneticker for each source of price quotes (e.g., NYSE), onedisplay for eachanalyst using the application, and one traderfor each rading service.The rules for the SAA application are divided into twogroups, display and trading, according to the applicationoperations invoked in their actions. Display rules containrequests o a display program in their action. For example,each analyts display includes a window that scrolls pricequotes from right to left, like the stock ticker seen at abrokerage. This ticker window is driven by the followingrule:

Event: update stock priceCondition: trueAction: send display price quote request todisplay programCoupling: condition and action together in aseparate transaction

There is a rule of this form for each display programrunning. The actions for trading rules contain request totrading programs. For example, an analyst might instructthe application to buy 500 shares of Xerox for a clientwhen the price reaches50. This is expressedas a rule:

Event: update Xerox priceCondition: where new price = 50Action: send request to buy 500 shares forclient ACoupling: condition and action together in aseparate transactionThe execution of a trade is an event defined by SAA andsignalled by a trading program. There is a display rule thatcauses he trade to be displayed and the portfolio updatedonthe analystsscreenand trading rules.After implementing the SAA using HiRAC rules, we notedthe following:

There are no direct interactions between the applicationprograms. All interactions take place through rulesfiring.The application programs tended to be quite simpleservers. The control logic was encoded n the rules.Most of our rules contained requests to applicationprograms n their actions, rather than database perations.To modify the behavior of the application, we wouldchange he rules rather than the software.

In traditional database applications, data flows from oneapplication program to another through the DBMS. WithECA rules, application defined events, and calls toapplication programs in rule actions, HiFAC provides amedium for flow of control as well as data. The high levellogic for the application can be encoded n rules rather than

software, making the application more modular and easierto modify.5. FUNCTIONAL COMPONENTSTo implement the HiPAC knowledge model and executionmodel, a DBMS must provide object-oriented datamanagment and nested transactions. It must support thesemanticsof the rule object class. This includes detectingevents, determining which rules to fire when events arereported, scheduling condition evaluation and actionexecution according to rule coupling modes,and performingtheseactivities in nested ransactions.Figure 5.1 deuicts the functional componentsof the HiEACar&itectme. Theseare:Object Manager Provides object-oriented datamanagement.Transaction ManagerEvent Detectors

Rule ManagerCondition Evaluator

Pmvides nested ransactions.Detect primitive events andsignal them to the RuleManager.Maps events to rule firings, andrule firings to transactions.Evaluates ule conditions.

The Object Manager and Transaction Manager togetherprovide the functionality of an object-oriented DBMS, plusnested transactions. ECA rules are implemented by theEvent Detectors,Rule Manager, and Condition Evaluator.The overall flow of control and data is as follows. First, anevent relevant to some rule (e.g., a databaseoperation) isdetected by an Event Detector and reported to the RuleManager. The Rule Manager determineswhich rule to fire,and schedulescondition evalution for these rules based ontheir condition coupling modes. The Rule Manager callson the Transaction Manager to create a transaction forcondition evalution, and calls on the Condtion Evaluator toevaluate the rules condition. If the condition is satisfied,the Rule Manager calls on the Transaction Manager tocreatea transaction or executing the action.5.1 Object ManagerThe Object Manager provides object-oriented datamanagement. It supports the definition of object types andoperations on instances of those types, and is responsiblefor executing those operations. In the course of executingdatabase operations, the Object Manager calls on theTransaction Manager to obtain locks, and acts as an eventdetector, eporting database perations o the Rule Manager.The interface to the Object Manager consists of a singleoperation:

220


7/10

Execute Operation Execute a database operation(DDL or DML) on one or more databaseobjects.The parameters are the database objects and thetransaction n which to perform the operation.This interface is used by applications, the Rule Manager,and the Condition Evaluator.

Application

eventsignalt Iapplication transactionoperation operationdatabaseoperation

HiPAC

ondition3aluator1valuate lockcondition objectiFigure 5.1 the HiPAC Functional Components

5.2 Transaction ManagerThe Transaction Manager implements the HiPAC nestedtransaction model. It is responsible for creating andterminating transactions, and for concurrency control. Inaddition, it acts as an event detector, reporting transactiontermination to the Rule Manager.The interface to the Transaction Manager consists of threeoperations:Create Transaction Create a (top level or nested)transaction.Commit Transaction Commit a (top level or nested)transaction.Abort Transaction Abort a (top level or nested)transaction.

This interface is used by applications and the RuleManager.5.3 Event DetectorsEvent Detectorsare responsible or reporting the occurrenceof primitiveevents to the Rule Manager. There are eventdetectors for databaseevents (in the Object Manager andTransaction Manager), for temporal events, and forapplication-defined events. Particular event detectorsdifferin the type of events that they detect, how these events aredescribed when programming the event detector, and thecontents of the event signal that is passed to the RuleManagerwhen an event s reported.When a rule is created, he appropriate event detector(s) s(are) programmed o detect and report the primitive eventsthat can trigger the rule. The event detector(s) is (are)instructed to cease detecting the event when the rule isdeleted (if there is no other rule with the same event).When a rule is disabled, event detection for the rule is

221


8/10

disabled. When the rule is enabled again, event detection senabled.The interface to an Event Detector consists of the followingoperations:Define Event Program the event detector to report theoccurrence of a primitive event. Theparameter s a description of the event.Delete EventEnable EventDisable Event

Ceasedetecting and signalling an event.Suspend the detection and signalling ofan event, specifiedas a parameter.Resume the detection and signalling ofan event, specifiedas a parameter.

This interface is used by the Rule Manager.5.4 Rule ManagerThe Rule Manager is responsible for firing the appropriaterules when an event is detected. That is, it determineswhich rules to fire, and schedulescondition evaluation andaction execution for those rules according to their couplingmodes. The Rule Manager calls on the TransactionManager to create the transaction used for conditionevaluation and action execution, and it calls on theCondition Evaluator at the appropriate points to determinewhich conditions are satisfied. The Rule Manager is alsoresponsible for suspending triggering transactions until allof their subtransactions (for immediate and defrred rulefirings) have terminated.The interface to the rule manager consists of a singleoperation:Signal Event Report the occurrence of an event. Theparameters are the event, its signal, andthe transaction in which the eventoc4med.This interface is used by the Event Detectors and theTransactionManager.5.5 Condition EvaluatorAfter an event has been detected, he Condition Evaluator isresponsible for efficiently determining which ruleconditions are satisfied (among the rules triggered by theparticular event). The Condition Evaluator uses echniquessuch as multiple query optimization and viewmaterialization to do this. The data structure used for thispurpose is called a condirion graph. The ConditionEvaluator can be thought o f as having two functionsrelative to these condition graphs. One is to maintain thecondition graphs as rules are created, deleted, enabled, anddisabled. The other is to use the condition graphs todetermine which rule conditions are satisfied when an eventOCCUTS.

The interface to the Condition Evaluator consists of thefollowing operations:Add Rule Add a rule to the condition graph. Themessagencludes the event, the condition, and thecoupling mode for condition evaluation. Theoutput includes the events that must be signaled.Delete Rule Remove a rule from the condition graph.Evaluate Conditions Determine which rules have beensatisfied . The input is the event signal, couplingmode, and previous database state (deferred andseparate ondition evaluation only).This interface s used only by the Rule Manager.6. RULE PROCESSINGIn this section we describe how the HiPAC componentsdescribedabove nteract in carrying out operations on rules.The operations described here are creating a rule, signallingan event, and committing a transaction.6.1 Rule CreationRule creation is initiated when an application issues arequest for the rule creation operation. The request ishandled by the Object Manager. The Object Managercreates the rule object, obtains a write lock on it, andsignals the create rule event to the Rule Manager. TheObject Manager then waits for a reply from the RuleManager.First, the Rule Manager issues an add rule request to theCondition Manager. Then it issues define event requeststo the appropriate Event Detectors. Finally, it adds he ruleand events to its mapping from events to rules. At thispoint, the Rule Manager replies to the event signal, and theObject Manager resumesprocessing he original request.6.2 Event Signal ProcessingWhen the event for a rule occurs, an Event Detector issuesan event signal to the Rule Manager (because the RuleManager programmed he Event Detector to do so when therule was created). The operation that triggered the eventsignal is suspended. The Rule Manager then determineswhich rules to fire by consulting the mapping that itmaintains between events and rules. The Rule Managerdivides these rules into three groups according to theircoupling mode for condition evaluation.For each rule firing with separatecondition evaluation, theRule Manager obtains a new top level transaction (from theTransaction Manager) and calls on the Condition Evaluatorto evaluate the rules condition in that transaction. All ofthese transactions execute concurrently, each in its ownthread of execution. If a rules condition is satisfied , thethread of execution will process the rules action.Meanwhile, the Rule Manager continues with theprocessingof the original event signal.

222


9/10

For each rule firing with deferred condition evaluation, theRule Manager savesadds the rule and event signal to a setof deferred ule firings that is associatedwith the transactionin which the triggering event occurred. This set of rulefirings is processed ater, when the transaction commits (asdescribed n the next section).For each rule firing with immediate condition evaluation,the Rule Manager obtains a subtransaction (of thetriggering transaction (from the Transaction Manager) andcalls on the Condtion Evaluator to evaluate the rulescondition in that subtransaction. When all conditions havebeen evaluated, actions are executed for those rules whoseconditions were satisfied.When all immediate condition evaluation and actionexecution is completed, the Rule Manager replies to theEvent Detector. At this point the operation that originallycaused he event signal resumes.6.3 Transaction Commit ProcessingTransaction commit is initiated by a commit transactionrequest to the Transaction Manager. As part of commitprocessing, he Transaction Manager issuesan event signalto the Rule Manager. This event signal identifies thetransaction that is terminating.The Rule Manager maintains a set of deferred rule firingsfor each transaction. When the Rule Manager receives thecommit event signal, it first gets the corresponding set ofdeferred rule firings. This set is divided into two subsetsaccording to whether it was the condition or action that wasdeferred. For each of the former, the Rule Manager calls onthe Condition Evaluator to evaluate the rules condition.For the latter, the Rule Manager simply executes theaction.When all deferred rule firings have completed, the RuleManager replies to the commit event signal, and theTransaction Manager resumescommit processing.7. IMPLEMENTATION STATUS AND FUTUREWORKWe have presented an architecture for HiPAC, an activeDBMS with ECA rules. This architecture supports theknowledge model, execution model, and conditionmonitoring algorithms described in the HiPAC researchpapers. In doing so, it specifies two new forms ofinteraction between an application and the DBMS.Application programs signal events, and HiPAC makesrequests o application programs in executing rule actions.This leads to a new paradigm for building applications overan active DBMS. Control logic is encoded n rules ratherthan software. HiPAC becomesa medium for the flow ofcontrol, as well as data, between application programs.We are currently implementing a HiPAC prototype andapplications using Smalltalk-80. Initially, we areconcentrating on the knowledge model and the executionmodel. The Rule Manager and Transaction Manager are

implemented. The Object Manager and ConditionEvaluator are being designed. The Object Manager willsupport the Probe data model and algebra [MANN86]. Inthe interim, rule conditions and actions are expressed asSmalltalk- blocks. Concurrent execution of transactionsis implemented using Smalltalk- processes, which arelight weight.In our paradigm for active database applications, manycontrol functions are implemented n ECA rules rather thansoftware. While this tends to simplify the software, t alsoproduces large sets of rules. As the rule base for anapplication grows, problems due to unexpected nteractionsamong rules become more likely. Tools and techniqueshave evolved for dealing with large, complex programs(e.g., modularity, data abstraction, debuggers). Futureresearch will produce the tools and techniques needed todevelop arge, complex rule bases.6. REFERENCES[BUCSS] A. Buchmann et al. A Framework ForIntegrating Time-Critical Scheduling and

DatabaseTransaction Scheduling. To appearin Proc. 5th International Conferenceon DataEngineering, February 1989.[COD733 CODASYL Data Description LnaguageCommittee. CODASYL Data DescriptionLanguage Journal of Development June 1973.NBS Handbook 113 (1973).[DAYSSal U. Dayal et al. HiPAC: a Research Projectin Active, Time-Constrained DatabaseManagement, Interim Report. TechnicalReport XAIT-88-02, Xerox Advanced

Information Technology, June 1988.[DAYSSb] U. Dayal, A. Buchmann, and D. McCarthy.Rules Are Objects Too: A KnowledgeModel For An Active, Object-OrientedDatabase System. Advances in Object-Oriented Database Systems,September1988,pp. 129-143.[ESW75] K. P. Eswaran and D. D. Chamgerlain.Functional Specifications of a Subsystem orData Base Integrity. Proc. 1st Int? Conf. onVery Large Data Bases September1975).[ESW76] K. P. Eswaran. Specifications,Implementations, and Interactions of a TriggerSubsystem in an Integrated Data BaseSystem. IBM Research Report RJ1820(August 1976).[HSUSS] M. Hsu, R. Ladin, D. McCarthy. AnExecution Model For Active DatabaseManagement Systems. Proc. 3rdInternational Conference on Data andKnowledge Bases,June 1988, pp. 171-179.

223


10/10

[MAN861 F. Manola and U. Dayal. PDM: An Object-Oriented Data Model. P roc. Intl Workshopon Object-OrientedDatabaseSystems, 1986).[MOR83] M. Morgenstem. Active Databases as aParadigm for Enhanced ComputingEnvironments. Proc 9th Zntl Co& on VeryLarge Data Bases, Florence, pp. 34-42(October 1983).[MOSS51 E. Moss. Nested Transactions: An Approachto Reliable Distributed Computing, MITPress 1985).[ST0861 M. Stonebraker et al. A Rule Manager ForRelational Database Systems. ThePOSTGRES Papers, Univ. of California,Berkley, Ca. Electronics Research Lab,Memo No. UCB/ERL M86/85 (1986).[SYB871 Sybase, Inc. Transact-SQL Users Guide(1987).

224

Documents

Database Management Sys4