Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: A Comparative evaluation of active relational databases
Full Citation
Permanent Link:
 Material Information
Title: A Comparative evaluation of active relational databases
Series Title: Department of Computer and Information Science and Engineering Technical Report ; 93-002
Physical Description: Book
Language: English
Creator: Chakravarthy, Sharma
Publisher: Department of Computer and Information Sciences, University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: january, 1993
Copyright Date: 1993
 Record Information
Bibliographic ID: UF00095166
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.


This item has the following downloads:

199383 ( PDF )

Full Text

University of Florida
Computer and Information Sciences

.. -* Department of Computer and Information Sciences
,_ Computer Science Engineering Building
SUniversity of Florida
Gainesville, Florida 32611

A Comparative Evaluation of Active
Relational Databases

S. Chakravarthy

Tech. Report UF-CIS-TR-93-002
January 1993
(Submitted for publication)

A Comparative Evaluation of Active Relational Databases*

S. Chakravarthy

Database Systems Research and Development Center
Computer and Information Sciences Department
University of Florida, Gainesville, FL 32611

January 3, 1993


Over the past few years, active databases have become an important area of research. A
number of efforts have addressed event-condition-action (ECA) rule support in the context of
relational databases. This paper provides a concise comparative evaluation of active database
features of representative commercial as well as research prototypes. The comparison uses three
key characteristics: rule expressiveness, execution semantics, and efficiency aspects.

Index terms: Active functionality, Coupling modes, Database events, Temporal events, Event-
condition-action rules, External events

1 Introduction

Over the last five years research on active databases has been addressing the needs of a variety
of non-traditional applications that are not readily met by traditional database management sys-
tems (DBMSs). These applications -network management, Air Traffic Control, program trading,
Computer Integrated Manufacturing (CIM), and engineering design, to name a few -need to, as
part of their application semantics, continually monitor changes to the database state and initiate
appropriate actions, preferably, without user or application intervention. Timeliness of event de-
tection and action execution is equally important for a number of these applications. Furthermore,
some of the applications, such as network management, CIM, and program trading, need to be able
to recognize certain happenings or events of interest that are outside the purview of the DBMSs
(e.g., modem failures, machine breakdown, global currency instabilities), and initiate appropriate
transactions (e.g., diagnostics) or computations on the data stored in the database. The events
to be monitored can be categorized into: database events (typically, insert, delete, and modify
operations in a relational database), temporal events (typically, absolute and relative events), and
abstract or external events (typically, events detected outside the scope of the DBMS although the
rule itself is processed by the DBMS).

*This work was supported in part by the NSF Research Initiation Grant IRI-9011216.

2 Rule Format

Consensus seems to be emerging in the database community about the elemental components of
a rule used for supporting the active functionality: an event expression, one or more conditions,
an action, and a set of attributes. A rule with the these components is termed an ECA or event-
condition-action rule in the literature [3]. Explicit specification of these components of a rule
provides maximum flexibility and expressibility although these components have been packaged in
different ways in the literature as shown in Figure 1.

When < Event Expression > ]

If < Condition Expression >

Then < Action >

Attributes {priority, coupling mode, ...}

Figure 1: Rule Format Possibilities.

In Sybase [22] and InterBase [15] a rule is composed of an event part, and an action part (case II
in Figure 1). The action part is a transaction (a sequence of Transact-SQL statements, in Sybase).
The condition part is encoded as part of the action. ETM (Event Trigger Mechanism, [8, 16]) also
follows the same philosophy. On the other hand, POSTGRES [21], Starburst [23], and HiPAC ([3],
[7]) have separate event, condition and action parts (case III in Figure 1). Case I is typically used
by production rule systems (e.g., OPS5 ([11]). They just have a condition part (from which one or
more events are implicitly derived) and an action part.
Below, we briefly describe the approaches taken for ECA rule support by earlier work in the
relational database context. To keep the presentation focused, we shall not discuss the details of
complex events [6, 12] or the architectural details for the relational model [2, 19].

3 Comparison Criteria

Functionally, an active database management system monitors conditions til --. .1 by events rep-
resenting database events, temporal events, or external events and if the condition evaluates to
true then the action is executed. Introduction of ECA rules into a DBMS has an impact on several
functional modules of the traditional DBMS architecture.
Rule expressiveness: Commonly used data manipulation languages (SQL and its variations)
do not support ECA rule specification. As a result ad hoc extensions have been proposed even
for the specification of simple integrity constraints (e.g., domain constraints). Some of the earlier
approaches [9] specifically addressed the enforcement of integrity constraints by extending the data
model for specifying triggers.
In contrast, active DBMSs require enhancements to the data model in at least two ways: i) for
specifying events and ii) for specifying conditions and actions. In addition to specification of events
that correspond to database operations, such as insert, delete, and modify, specification of temporal
and/or periodic as well as external events need to be supported. Specification of conditions and

actions also require extensions to the language supported by the data model. Conditions and
actions may be complex, may include aggregation operators, and may refer to the old and new
states corresponding to the state before the execution of an operation and the state created after
the execution of the operation, respectively.
Rule optimization: The set of all event-condition-action rules is likely to form a potentially large
set of predefined queries that need to be efficiently managed and evaluated when specified events
occur. Rule evaluation imposes an overhead on (possibly) every event. Also, when the number
of rules is large, grouping related rules (rules that have common subexpressions in events and
conditions, for example) to reduce computation is beneficial.
Conventional query processing techniques do not seem to be adequate for optimizing rules,
necessitating extensions to existing ones as well as the development of new ones. First, rules are
temporally persistent. That is, they have a longer life-span and as a result are likely to be evaluated
many times. This suggests that several rules can be optimized simultaneously in a group, possibly
using some of the techniques developed for multiple query optimization [10, 5, 20, 1]. The effect
of multiple query optimization can be further enhanced by materializing intermediate results (e.g.,
common subexpressions) judiciously. Second, rules used for real-time applications are likely to
have priorities or timing requirements associated with their execution. Optimization of such rules
requires different techniques, such as exhaustive optimization, novel buffering strategies, use of
main memory, and appropriate processing techniques (e.g., use of parallelism).
Rule execution semantics: The execution model requirements is likely to be application-dependent.
For some applications, in order to provide timely response to critical events, it may be important
to evaluate the condition immediately after an event has occurred, and to execute the action part
immediately after the condition evaluation. In this immediate mode of execution, the processing
of the remaining steps of the transaction which caused the event to occur (termed the triggering
transaction) is suspended until the fired rule has been completely processed. Long delays can result
in completing the processing of the triggering transaction, especially if the action part of the rule
causes firing of other rules. Response times and concurrency can be improved if the condition
evaluation and/or action execution are detached from the triggering transaction and executed in a
separate transaction. Also, enforcement of integrity constraints in a transaction oriented environ-
ment requires that an integrity rule be executed at the end of a transaction before its commit, i.e.,
in a deferred coupling mode.
Finally, it is possible that an event occurrence can make several rules eligible for execution
(multiple rule execution either concurrently or using some conflict resolution strategy); also, as
additional rules can be ti B--. .1 from within the action component of a rule, support for nested or
cascaded execution of rules is important.

4 Comparison

Figure 21 provides a comparison of the major relational active database efforts using expressiveness,
. frI, '" n, and execution semantics as the criteria. A detailed discussion of active relational DBMSs
and their comparison can be found in [4]. The comparison shown in the table is based on the
literature cited in this paper.

1This is not an exhaustive comparison of all systems. Some commercial (e.g., VAX/Rdb, INGRES) and some
research prototypes (e.g., Ariel [13]) have not been included to keep the presentation manageable.

Features Rule Expressiveness Execution Semantics Efficiency

Cascaded Multiple Optimization
Database Temporal External Event Coupling rule rule of rulestectural

System Events Events Eents Constructors modes execution execution Approach
Delta relations,
HiPAC Insert, Absolute, Disjunction, Immediate, Using Integrated
Delete Relative Yes Sequence, Deferred, Yes Extended Chain rule,
nested multiple query
Modify Closure Detached transactions optimization

ETM Insert, No using user
Delete, No Yes Immediate Yes defined No On top of
Modify priority DAMASCUS
retrieve, Query rewrite, Extended
replace, time() Only Using user tuple level Relational
ostgres delete, Date() No Disjunction Immediate Yes defined processing,
append functions priority rule locks
new, old
using a Extended
Inserted, Only conflict UsingExtended
Starburst Deleted, No No Disjunction Deferred Yes resolution I, D, and U Relational
Updated strategy relations

INSERT, Conventional Relational
Sybase UPDATE, No No Immediate Yes No query

DELETE Optimization
Store, Using user Conventional
Modify, Relational
Interbase Erase No No No Immediate Yes defined query
pre, post priority Optimization

Figure 2: Comparison of Active Relational Database Features

All the systems shown in the table support database events; only HiPAC and ETM support
external events. The need of temporal events was recognized in HiPAC and absolute and relative
events were proposed. POSTGRES, on the other hand, supports a few specific temporal events
(e.g. time and date). POSTGRES and Starburst support only disjunction of events whereas HiPAC
provides three event constructors viz., disjunction, sequence and closure using which a regular event
expression can be expressed.

Starburst supports only deferred mode, while ETM, POSTGRES, Sybase and interBase support
immediate coupling mode only. HiPAC supports a general execution model [14] which includes
immediate, deferred and detached modes. The detached mode includes causally-dependent and
causally-independent modes. In causally-dependent mode there is a commit dependency between
the triggering transaction and the rules ti -B-:. i.1 by that transaction. All the allow cascaded
execution of rules. Again, all the systems, except Sybase, support multiple rules to be associated
with a relation. Sybase allows only three rules per relation, one each for INSERT, DELETE,
and MODIFY events. All of the systems, except HiPAC, prioritize potentially executable rules
activated by an event. ETM, POSTGRES and InterBase order rules in the order specified by the
user when rules are defined. HiPAC interleaves multiple rule execution (i.e., provided concurrent
rule execution) using an extended nested transaction model. Starburst assumes a conflict resolution

scheme similar to the ones used in expert systems. Starburst uses an incrementally computed
context for execution of rules which were t iB--- I' .1 by an event.
Only HiPAC and POSTGRES propose techniques for efficient rule evaluation. Starburst, Sybase
and InterBase do not explicitly state anything about optimization of rule evaluation. ETM pro-
vides fast access paths to events, constraints, actions and triggers. But it does not provide efficient
strategies for evaluation of rules in general. HiPAC supports several such strategies [18, 17, 1]. In
addition to the multiple query optimization techniques, an extended algebra for the Changes oper-
ators using delta relations and incremental operators has been developed. A chain rule transforms
an expression containing the changes operator into an expression containing incremental operators.
HiPAC also allows transformations specific to situations. Optimization of events is done with the
help of signal graphs. Events are given a tree structure, called signal graph, and strategies have
been proposed for evaluating these graphs. They include bottom-up approach, top-down approach
and signal driven approach. Signal driven approach is a combination of data and command driven
POSTGRES uses several techniques for rule optimization. They include indexing, cashing,
lazy-evaluation and eager-evaluation. Besides these, it supports: tuple level processing (called
when individual tuples are deleted, inserted, modified or accessed) and query rewrite processing
(converts user command to an alternative form prior to optimization.) The latter one is used to
process a subset of rules efficiently.

5 Conclusion

In summary, considerable research has been carried out on active relational database systems. It is
also clear that the approaches vary depending upon the applications that were used for driving this
research. It is important to emphasize that commercial database vendors have already subscribed
to the usefulness of active database features.


[1] S. Chakravarthy. Divide and Conquer: A Basis for Augmenting a Conventional Query Optimizer with
Multiple Query Processing Capabilities. In Proc. of the 7th 1,t / Conf. on Data Engineering, Kobe,
Japan, pages 482-490, Apr. 1991.
[2] S. Chakravarthy. Architectures and monitoring techniques for active databases: An evaluation. Techni-
cal Report UF-CIS TR-92-041, Database Systems R&D Center, CIS Department, University of Florida,
E470-CSE, Gainesville, FL 32611, November 1992.
[3] S. Chakravarthy et al. HiPAC: A Research Project in Active, Time-Constrained Database Management,
Final Report. Technical Report XAIT-89-02, Xerox Advanced Information Technology, Cambridge, MA,
Aug. 1989.
[4] S. Chakravarthy, S. B. Navathe, S. Garg, D. Mishra, and A. Sharma. An evaluation of active dbms
developments. Technical Report UF-CIS TR-90-23, Database Systems R&D Center, CIS Department,
University of Florida, E470-CSE, Gainesville, FL 32611, Sep. 1990.
[5] U. S. Chakravarthy and J. Minker. Multiple Query Processing in Deductive Databases Using Query
Graphs. In Proceedings of International Conference of Very Large Data Bases, pages 384-391, 1986.

[6] S. Chakravathy and D. Mishra. An event specification language (snoop) for active databases and
its detection. Technical Report UF-CIS TR-91-23, Database Systems R&D Center, CIS Department,
University of Florida, E470-CSE, Gainesville, FL 32611, Sep. 1991.
[7] U. Dayal, A. Buchmann, and D. McCarthy. Rules are Objects Too: A Knowledge Model for an Active,
Object-Oriented Database Management System. In Proceedings ,.1'. International Workshop on Object-
Oriented Database Systems, Bad Muenster am Stein, Ebernburg, West Germany, Sept. 1988.
[8] K. R. Dittrich, A. M. Kotz, and J. A. Mulle. An Event/Trigger Mechanism to Enforce Complex
Consistency Constraints in Design Databases. SIC, iOD Record, 15(3):22-36, Sep. 1986.
[9] K. P. Eswaran. Specifications, Implementations, and Interactions of a Trigger Subsystem in an Inte-
grated Data Base System. IBM Research Report RJ1820, Aug. 1976.
[10] S. Finkelstein. Common Expression Analysis in Database applications. In Proc. of AC I!- ifOD,
Orlando, Jun. 1982.
[11] C. L. Forgy. RETE: A Fast Algorithm for the Many Pattern/\ I.; Object Pattern Matching Problem.
Artificial Intelligence 19, pages 17-37, 1982.
[12] N. H. Gehani, H. V. Jagadish, and O. Shmueli. Event Specification in an Object-Oriented Database.
In Proceedings International Conference on Management of Data, pages 81-90, San Diego, CA, June
[13] Eric N. Hanson. An Initial Report on the Design of Ariel: a DBMS with an integrated production rule
system. AC if SIC ifOD RECORD, 18(3):12-19, Sep. 1989.
[14] M. Hsu, R. Ladin, and D. McCarthy. An Execution Model for Active Data Base Management Systems.
In Proceedings 3rd International Conference on Data and Knowledge Bases, Jun. 1988.
[15] InterBase Software Corporation, Bedford, MA. InterBase DDL Reference Manual, InterBase Version
3.0, 1990.
[16] A. Kotz, K. Dittrich, and J. Mulle. Supporting Semantic Rules by a Generalized Event/Trigger Mecha-
nism. In Proceedings International Conference on Extending Database Technology, Venice, March 1988.
[17] A. Rosenthal and U. Chakravarthy. Anatomy of a Modular Multiple Query Optimizer. In Proceedings
14th International Conference on Very Large Data Bases, pages 230-239, Los Angeles, CA, Sept. 1988.
[18] A. Rosenthal, U. S. Chakravarthy, B. Blaustein, and J. Blakeley. Situation Monitoring in Active
Databases. In Proc. of the 15th I,,t Conf. on Very Large Databases, pages 455-464, Amsterdam, Aug.
[19] U. Schreier et al. Alert: An architecture for transforming a passive dbms into an active dbms. In Pro-
ceedings 17th International Conference on Very Large Data Bases, pages I.'i I; Barcelona (Catalonia,
Spain), Sept. 1991.
[20] T. Sellis. Global Query Optimization. In Proceedings of SIC7 \OD, pages 191-205, 1986.
[21] M. Stonebraker, M. Hanson, and S. Potamianos. The POSTGRES rule manager. IEEE Transactions
on Software Engineering, 14(7):897-907, Jul. 1988.
[22] Sybase, Inc., Sybase, Inc. Berkeley, CA '1 10. Transact-SQL User's Guide, Release 4.2, May 1990.
[23] J. Widom and S. Finkelstein. Set-Oriented Production Rules in Relational Database Systems. In Proc.
of AC !- fC i[OD, pages 1'",*1 270, May 1990.

University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs