Title Page
 Table of Contents

Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: A Confluent rule execution model for active databases
Full Citation
Permanent Link: http://ufdc.ufl.edu/UF00095355/00001
 Material Information
Title: A Confluent rule execution model for active databases
Series Title: Department of Computer and Information Science and Engineering Technical Reports
Physical Description: Book
Language: English
Creator: Kim, S-K.
Chakravarthy, S.
Affiliation: University of Florida
University of Florida
Publisher: Department of Computer and Information Science and Engineering, University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: October, 1995
Copyright Date: 1995
 Record Information
Bibliographic ID: UF00095355
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:

1995193 ( PDF )

Table of Contents
    Title Page
        Page i
    Table of Contents
        Page ii
        Page 1
        Page 2
        Page 3
        Page 4
        Page 5
        Page 6
        Page 7
        Page 8
        Page 9
        Page 10
        Page 11
        Page 12
        Page 13
        Page 14
        Page 15
        Page 16
        Page 17
        Page 18
        Page 19
Full Text

University of Florida

Computer and Information Science and Engineering

Computer and Information Science and Engineering Department
E301 Computer Science and Engineering Building
:University of Florida, PO Box 116120
Gainesville, Florida 32611-6120

A Confluent Rule Execution Model for

Active Databases

S-K. Kim
S. Chakravarthy
EMAIL: sharma@cis.ufl.edu
WWW: http://www.cis.ufl.edu/~sharma

Tech. Report UF-CIS-TR-95-032
(Submitted for publication)

October 1995
(This work is partly supported by the Office of Naval Research and the Navy
Cornimand. Control and Ocean Surveillance Center RDT&E Division, and by the
Rome Laboratory.)

a P



1 Introduction 1

2 Limitations of the Earlier Rule Execution Models 3

3 Definitions and Extensions 5
3.1 Rule Execution Sequence (RES) and Rule Commutativity . . . . . . 5
3.2 Dependencies and Dependency Graph ................... . . .... 7
3.3 Trigger Graph ................... ................... 8

4 Confluence and Priority Specification 9

5 Strict Order-Preserving Rule Execution Model 12
5.1 Extended Execution Graph ............... . . . . . ...... 12
5.2 Strict Order-Preserving Executions .................. ....... .. 13
5.3 Im plem entation .................. ............. . . . .. 14
5.4 Parallel Rule Execution ................. . . . . . ...... 16

6 Conclusions 18

A Confluent Rule Execution Model for Active Databases*

Seung-Kyum Kim Sharma Chakravarthy

Database Systems Research and Development Center
Department of Computer and Information Science and Engineering
University of Florida, Gainesville, FL 32611
Email: {skk, sharma}@cis.ufl.edu

In this paper we propose a new rule execution model along with priority specification schemes
to achieve confluent rule execution in active databases. Our model employs prioritization to
resolve conflicts between rules, and uses a rule scheduler based on the topological sort to achieve
correct confluent rule executions. Given a rule set, a trigger graph and a dependency graph are
built from the information obtained by analyzing the rule set at compile time. The two graphs
are combined to form a priority graph, on which the user is requested to specify priorities only
if there exists dependencies in the dependency graph. From the priority graph, an execution
graph is derived for every user transaction that triggers one or more rules. The rule scheduler
uses the execution graph. Our model also correctly handles the situation where trigger paths
of rules triggered by a user transaction are overlapping, which existing models are unable to
handle. We prove that our model achieves maximum parallelism in rule executions.

1 Introduction

Incorporating ECA rules (Event-Condition-Action rules) enhances the functionality of traditional
database systems significantly [C+89, GJ91, AMC93, HW'i.;] Also, ECA rules provide flexible
alternatives for implementing many database features, such as integrity constraint enforcement,
that are traditionally hard-wired into a DBMS [CW90, SJGP90, WF90, CW91, WCL91].
An ECA-rule consists of three parts: event, condition, and action. Execution of ECA rules
goes through three phases: event detection, condition test, and execution of action. An event can
be a data manipulation or retrieval operation, a method invocation in Object-Oriented databases,
a signal from timer or the users, or a combination thereof. An active database system monitors
occurrences of events pre-specified by ECA rules. Once specified events have occurred, the condition
part of the relevant rule is tested. If the test is satisfied, the rule's action part can be executed.
In Sentinel [CKAK94], a rule is said to be triggered when the rule has passed the event detection
phase; that is, when one or more events which the rule is waiting for have occurred. When an
ECA rule has passed the condition test phase, it is said to be eligible for execution.1 In this paper,

*This work is partly supported by the Office of Naval Research and the Navy Command, Control and Ocean
Surveillance Center RDT&E Division, and by the Rome Laboratory.
'The definition of trigger is blurred as condition-action rules such as the production rule [BFKM85] have evolved
to ECA-rules. A condition-action rule is triggered and eligible for execution when the current database state satisfies
the specified condition, whereas for an ECA rule to be ready to execute, it has to pass separate event detection and
condition test phases.

we use the word I, :--. I to describe the eligible rules assuming that the condition part has been
satisfied or it is nil.
The ECA rule execution model (rule execution models in general) has to address several issues.
First, multiple rules can be t; i--. i' and eligible for execution at the same time. For example,
suppose that two rules ri and rj are defined, respectively, on two events El and (E1VE2) and
there are no conditions specified for the rules, where (E1VE2) is a disjunction of two component
events El and E2. A disjunction occurs when either component event occurs [CKAK94]. Now, if
event El occurs, it will trigger both ri and rj. As addressed in [AWH92], multiple til-.-. I' rules
pose problems when different execution orders can produce different final database states. If an
active database system randomly chooses a rule to execute (out of several ti ;.-- 1. .1 rules), the final
database state is nondeterministic. This adds to the problem of understanding applications that
trigger rules. Priorities are generally used to deal with conflict resolution of rules [SHP'" C+89,
ACL91, Han92]. When multiple conflicting rules are til-.-. .1 at the same time, a rule with the
highest priority is selected for execution.
[AWH92] focuses on testing whether or not given a rule set has the confluence property. A rule
set is said to be confluent if any permutation of the rules yields the same final database state when
the rules are executed. If a rule set turns out to be not confluent, either the rule set is rewritten to
remove the conflicts or priorities are explicitly defined over the conflicting rules. Then, the new rule
set is retested to see if it has the confluence property. A problem with this approach is that it tends
to repeat the time-consuming test process until the rule set eventually becomes confluent. Also, it
has not been shown as to how confluence can be guaranteed as priorities between conflicting rules
are added to the system.
There are other subtle problems with the ECA rule execution model. Suppose that ri and
rj mentioned previously have condition parts. As event El occurs, the two rules pass the event
detection phase. Assume that both rules have passed the condition test and ready to execute
their action part. It is possible that the execution of one rule's action, say rid's, can invalidate rj's
condition that was already tested to be true; that is, ri can iitritiqqr rj. Apart from the issue
of whether or not the condition test should be delayed up to the point (or retested at the point)
just before execution of the action part, if one rule untriggers other rules, it is very likely that
the rule set is not confluent. The opposite situation can also happen. Suppose the condition of ri
was not met. So its action part would not be executed. But execution of rj's action could change
database state so that rid's condition could be satisfied this time. Therefore, if rj executes first and
rid's condition is tested after that, ri will be able to execute too. Again, execution order of the two
rules makes a difference. Instead of proposing a more rigorous rule execution model to deal with
the anomalies, we consider such rules as conflicting with one another so that the rule programmer
can be informed of these rules. This view will allow us to cover the problem within the framework
of confluent rule executions.
In this paper we explore problems of confluent rule executions, which deal with obtaining a
unique final database state for any initial set of rules that is ti;-.-:. .1 by a user transaction. We
show that previous rule execution models are inadequate for confluent rule executions (Section 2),
and propose a new rule execution model that guarantees confluent executions (Sectione 3, 4, and
part of 5). We also show that our model is a perfect fit for parallel rule executions (Section 5).
Conclusions are in Section 6.

r,0 S r4 r, r

r20------>Q rI r2 - r

r0 (5 r6 r3 0 r6

(a) (b)

Figure 1: Rule execution graphs

2 Limitations of the Earlier Rule Execution Models

Early rule execution models such as one used in OPS5 [BFK:.1 ".] deal with problems of confluent
rule executions only in terms of conflict resolution. When multiple rules are til .-. I .1 (and eligible
for execution), the rule scheduler selects a rule to execute according to a certain set of criteria such
as recency of trigger time, complexity of conditions. Although this scheme is used in the AI do-
main, users in the database domain prefer deterministic states from the executions of transactions.
Furthermore, the conflict resolution approach is not a complete answer to the confluence problem
since it is based on dynamic components such as recency of trigger time and does not support
concurrent execution. For the above reasons, we do not consider this approach in our work.
A somewhat different approach taken in active database systems such as Starburst [AWH92,
ACL91] and Postgres [SHP-" SJGP90] is to statically assign execution priorities over rules. In
these systems if multiple rules are ti ;.-.-. i .1 a rule with the highest priority among them is executed
first. However, rule execution models in these systems cannot guarantee confluent rule executions
unless all the rules (not only conflicting ones) are totally ordered. This problem is illustrated in
the following examples.

Example 2.1 Figure l(a) shows nondeterministic behavior of rule execution even when all con-
flicting rules are ordered. In the figure solid arrows represent trigger relationships. Dashed lines
represent conflicts and an arrow on a dashed line indicates priority between two conflicting rules.
As shown, two pairs of rules are conflicting: (r2, rs) and (T3, r5). The conflicting rules are ordered
in such a way that r2 precedes r5 and r5 precedes r3 when the pairs of conflicting rules are ti ;.-- I.
at the same time. Now suppose rl and r4 are tl .-j. d.1 by the user transaction at the same time.
(Note that these rules are denoted by solid circles in the graph.) In a rule execution model such
as Starburst, one of rl and r4 will be randomly selected for execution since there is no conflict
between them. Suppose r4 is executed first, then it will trigger rs. Yet there is no order between
rl and r5 which are ready to execute. So r5 may go first, and its execution will trigger r6. Then,
r6, 1r, r2, and r3 may follow. Including this, two of legitimate execution sequences for the rule set
are following: (1) (r4 r'5 r'6 rl 2 r '2 r3) and (2) (ri r'2 r3 r4 r5 r6). Note that relative orders
of two conflicting rules, r2 and r5 (as well as r3 and rs) in the two rule execution sequences are
different, thereby unable to guarantee confluent execution. <

Example 2.2 Figure 2 illustrates another situation where the previous rule execution models fail
to achieve confluent rule executions. There is a dependency between rk and rl and rk has priority
over rl. In this example, ri and rj are ti;:--. i .1 by the user transaction. Note also that ri is an
ancestor of rj in trigger relationship and thereby trigger paths originated from both rules overlap
one another. Given that priority, the following two (and more) sequences of rule executions are

r, 0 r,O [3]
ri O ri O [1]
1 I

k k

r 0 r 0' [4]

(a) (b)

Figure 2: Overlapped trigger paths

possible: (r; rj r rj r r'j rk rr) and (r; rj rj r r l r) Now relative orders of two conflicting
rules r'k and rl in the two execution sequences are different. Therefore confluent rule executions
cannot be guaranteed in the given situation.

As the previous examples -ir:- -. a problem that the extant active rule execution models fail
to address properly is that even though two rules are not directly conflicting each other, they may
trigger other rules that are directly conflicting. Depending on the execution order of triggering rules,
directly conflicting rules may be executed in a different order from what the user specified, likely
resulting non-confluent rule executions. Unless all the direct conflicts are removed by rewriting the
rules, one possible remedy for this problem, implied in Starburst [AWH92], would be to regard the
indirectly conflicting rules as conflicting ones. Figure l(b) illustrates how conflicts of Figure l(a) are
propagated toward ancestor rules in trigger relationship if this approach is taken. An undesirable
consequence of propagating conflicts is that it severely limits parallel rule execution. In addition,
it is not always clear how to propagate conflicts in some cases as Figure 2(a) shows.
Another problem which the previous rule execution models does not handle is shown in Ex-
ample 2.2 where trigger paths of rules t ;b:-. i' by the user transaction overlap. In fact, this new
situation poses additional problems for priority specification. That is, any static priority schemes
specified before rules' execution cannot range over all possible permutations of conflicting rules
execution, since one cannot anticipate which rules will be ti.---. ..1 by the user transaction how
many times. For instance, given the rule set of Figure 2(a), there can be two distinct final database
states which result from rule execution sequences, (r rj rk -rl -rj rk rl) and (r rj, rj r -r rl -rl.
All other legitimate rule execution sequences are equivalent to one of the two sequences in terms
of final database states. However, if rj is ti;.-.-. .1 twice and ri once by the user transaction, the
number of distinct final database states increases up to five. As ri and rj are ti l.-.-. i more number
of time, the number of final database states increases exponentially. Therefore, it is not realistic to
provide every possible alternative for these cases. Rather, a much less general scheme of priority
specification, which provides only some specific alternatives, needs to be considered.
Figure 2(b) shows one way of specifying priority for the rules in Figure 2(a), which is similar to
the priority scheme adopted in Postgres [SHP'-] Numbers in brackets denote absolute priorities
associated with rules. A larger number denotes a higher priority. This priority specification guar-
antees confluent rule executions although non-conflicting rules (ri and rj) too need to be assigned
priorities. Note that the given priority specification is (unnecessarily) strong it effectively imposes
a serial execution order (r r r - r; ri r - ri), thereby ruling out any parallel rule executions.
For instance, one instance of rj could run in parallel with a series of ri and rj without affecting the
final database state.

In the rest of the paper, we develop a novel rule execution model and a priority scheme that
not only ensures confluent rule executions but also allows greater parallelism.

3 Definitions and Extensions

3.1 Rule Execution Sequence (RES) and Rule Commutativity

Informally, a rule execution sequence (RES) is a sequence of rules that the system can execute
when a user transaction triggers at least one rule in the sequence. To characterize RESs, we first
define partial RESs. Throughout this paper, R denotes system rule set, a set of rules defined in
the system by the user. D denotes a set of all possible database states determined by the database
schema. (dj,Rk), dj E D and Rk C R, denotes a pair of a database state and a til-.-. i .1 rule set.
If Rk is a set of rules directly tib-r-. i .1 by a user transaction, it is termed UTRS which stands for
User-Triggered-Rule-Set. UTRS is, in fact, a multiset since as we shall see later, multiple instances
of a rule can be in it. S denotes the set of all partial RESs (see below) defined over R and D.

Partial RES Given R and D, for a nonempty set of tilb'. I .1 rules, Rk C R and a database
state dj E D, a partial RES, a is defined to be a sequence of rules that connects pairs of a database
state and a ti-r.-. .1 rule set as follows:

a = ((dj, Rk) (dj+, Rk+1) 1 +m -1 (dj+m, k+m))
where dj+i E D (1 < I < m) is a new database state obtained by the execution of ri+_-1, each
rule ri+l (0 < I < m) is in a til_1r. .1 rule set Rk+i, and eligible for execution in dj+i, i.e., dj+i
evaluates the rule's condition test to true. Each til-.-. .1 rule set Rk+1 C R (1 < I < m) is built as
Rk+l = ((Rk+l-1 {ri+-1 Ruk+l) U Rtk+l, where Ruk+l is a set of rules untriggered by ri+_-1
and Rtk+l is a set of rules til;'. i .1 by ri+-_1.2
In this paper, if only sequences of rule executions are of interest, for simplicity we write a
partial RES without associated database states and til--. .1 rule sets. For example, the partial
RES above can be denoted as a = (ri r+i ... ri+,ml), which we already used for partial RESs in
the previous sections. Among partial RESs, we are interested in some, called complete RESs (or
simply, RESs), that satisfy certain conditions.

Complete RES Given R and D, for a nonempty set Rk C R which is a set of rules tir.-j. I .1 by
a user transaction (i.e., UTRS) and dj E D is a database state produced by operations in the user
transaction, a complete RES (or RES), a is defined to be a partial RES:

a = ((dj, Rk) (dj+i, Rk+1) +1 tl (dj+m, Rk+m 0))
where no til-.-. l.1 (and eligible) rules remain after execution of the last rule ri+,l- (i.e., Rk+m
Note that given Rk and dj, there may be multiple different RESs, even in a case where there is
only one rule in Rk, and those RESs do not necessarily have the same set of rules executed, since a
rule's triggering/untriggering other rules may be dependent on the current database state. In this
paper we use rule schedule in informal settings interchangeably with complete RES.
Subscripts, i, i + 1, - i + m 1, attached to rules, are intended to mean that they are m rules that need not
be distinct (similarly for d's and R's). They do not represent any sequential order of rules with respect to subscript
numbers. That is, they should not be interpreted as, for instances, ro, r11, r12 *- in case where r, is rio. For a
precise denotation, we could use io, il, im-1, instead. However, we have opted for the less precise notation in
favor of simplicity throughout this paper.

Rule shuffling Given a partial RES o1, two rules ri and rj in cr can exchange their positions
provided rj E Ry, yielding a different partial RES 0r2 as below:

a1 = ((d,, R,) (dk, RI) (d, R,))

2 = ((d,, Ry) ( dd,1,R B) (d,, Rt))

Next we define an important property of rules that is used to show if a system rule set is
confluent. Two rules are defined to be commutative if shuffling them always yields the same result.

Rule commutativity Given R and D, two rules ri, rj E R are defined to be commutative, if for
all Ry C R, where ri, rj E Ry, and for all database state d, E D, the following two partial RESs
can be defined:
((d, R,) T (dk, Rl) (d, R,))

((d, R,Y) (d., R,) (d., R,))
where d,, dk, d,, du E D need not be distinct and likewise Ry, RI, R,, Rv C R need not be distinct.

Note that any rule is trivially commutative to itself.

Equivalent partial RESs Two partial RESs oa and aj are defined to be equivalent (-) if:

1. oa and aj begin with the same pair of database state and til .-. .1 rule set, and end with the
same pair of database state and til.--. ,.1 rule set; and

2. in oa and oj the same set of rules is til;.. ,.1 possibly in different orders.

The two partial RESs shown in the definition of rule commutativity are equivalent. In fact, the rule
commutativity is used to prove that two or more partial RESs are equivalent, and the equivalence
of partial RESs is, in turn, used to show whether given a system rule set is confluent or not.
Incidentally, it should be noted that without condition 2), the equivalence definition can still be
valid. However, with our static analysis method it is not possible to identify all such equivalent
partial RESs. To make presentation of this paper coherent, we chose a more restrictive form of
The equivalence of partial RESs naturally lends itself to definition of equivalence classes of
partial RESs. For given R and D, the set of all partial RESs, S is partitioned into disjoint classes
by the equivalence relation (-). All partial RESs belonging to an equivalence class have the same
final result, i.e., the same database state and the til.--. .1 rule set.

Equivalence class of partial RESs For a partial RES, a E S, the equivalence class of a is the
set S, defined as follows:
S, = c7 o}.

Of partial RESs belonging to the same equivalence class, for the discussion in this paper we define
canonical partial RES, or canonical RES for short, to be a partial RES that comes first when all the
partial RESs are sorted by their rules' indices in lexicographical order. For instance, assuming that
an equivalence class includes only three partial RESs, ao = (r r2 .r4 r3), rj = (ri 74 72 r3), and

-rk = (r1-r2"r3'r4 Ork is the canonical RES representing that equivalence class (by lexicographically
sorting the sets:, (1, 2, 4, 3), (1, 2, 3, 4) and (1,4, 2, 3)). Our prime interest is the equivalence class
of complete RESs.

Confluent Rule Set Given R and D, if there exists only one equivalence class of complete RESs
for every nonempty set R' C R and every d E D, R is defined to be confluent.

3.2 Dependencies and Dependency Graph

If a different execution sequence of the same rules can produce a different final database state, it is
because of certain interactions between rules and between rules and the environment. If we assume
the execution environment to be fixed and there is no interference from the user while rules are
executing, the interactions between rules must be the sole reason for non-confluent rule executions.
Based on this, we define rules' interactions responsible for non-confluence as dependencies between
rules, much like those of the concurrency control in transaction processing. We define two kind of

Data dependency Two distinct rules ri and rj are defined to have data dependency with each
other if ri writes in its action part to a data object that rj reads or writes in its action part, or vice
versa. <

Untrigger dependency Two distinct rules ri and rj are defined to have iitriiqq, r dependency
each other if ri writes in its action part to a data object that rj reads in its condition part or vice
versa. <
If two rules have a data dependency with each other, the input to one rule can be altered
by the other rule's action. Thus it is very likely that the affected rule would behave differently.
The data dependency can also mean that one rule's output can be overridden by the other rule's
output. This also has a bearing on the final outcome. If there is no data dependency, two rules
act independently. Therefore, there should be no difference in the final outcome due to different
relative execution order of the two rules.
On the other hand, if there is untrigger dependency between two rules ri and rj, this implies that
one rule's action can change the condition which determines whether the other rule is to execute
or not. If the affected rule, say ri, has already executed first, it is unrealistic to revoke the effect of
ri. As a result, both ri and rj will execute in this case. However, if the affecting rule rj executes
first, it can prevent ri from executing. Since it is assumed that there are no read-only rules, the
two different execution sequences can result in different database states even though there is no
data dependency.3
From the above observation, it is clear that the absence of data dependency and untrigger
dependency between two rules is a sufficient condition for the two rules to be commutative. (The
reverse is not necessarily true.) If there exists either dependency between two rules, the rules are
said to conflict with each other. Obviously, conflicting rules are non-commutative.

3It should be noted that whether or not the untrigger dependency can indeed affect confluent execution depends
on rule execution model employed by an active database system. If the rule execution model does not re-check the
condition part of a rule just before it executes the action part of that rule, then no rule is untriggered. In such a
case, it can appear that the untrigger dependency is no longer a problem and only data dependency matters.

Lemma 1 Given a partial RES a, a new partial RES a' obtained by freely .shffling rules in a is
equivalent to a, as long as relative orders of conflicting rules in both RESs are equal if there are
any conflicting rules.

Proof of lemma 1 Suppose a and a' are not equivalent despite the same relative orders of
conflicting rules in them. Then, there must be one or more pairs of non-conflicting rules in a that
can be shuffled but result in a different (non-equivalent) partial RES. These non-conflicting rules
are, then, conflicting and should have the same relative orders in a and a', which is a contradiction.

Below, we define dependency graph that represents dependencies between rules in the system
rule set.

Dependency graph Given a system rule set R, a dependency graph, DG = (R, ED) is an
undirected graph where R is a node set in which a node has one-to-one mapping to a rule and ED
is a dependency edge set. For any two nodes u and v in R, a dependency edge, (u, v) is in ED if
and only if there is data dependency or untrigger dependency (or both) between u and v.
A dependency graph is non-transitive; that is, (u, v) and (v, w) in ED do not imply (u, w) in
ED. Edges in a dependency graph represent only direct dependencies. An indirect (transitive)
dependency is represented by a path consisting of a set of connected dependency edges.

3.3 Trigger Graph

A trigger graph (TG) is an acyclic directed graph representing trigger relationships between rules
within given a system rule set R. For a system rule set R, TG = (R, ET) has a node set R and a
trigger edge set ET. The node set is equivalent to the rule set. For any two rules (i.e., nodes) ri
and rj in R, trigger edge set ET contains a directed edge, called trigger edge, (ri rj), if and only
if ri can trigger rj. It is defined that ri can trigger rj if execution of rid's action can give rise to an
event that is referenced in the event specification of rj.4
Note that for rules ri and rj above, it is possible that rj is not ti-.- i..1 by ri at run time if
rid's action part contains a conditional statement. Nevertheless we conservatively maintain a trigger
edge if there is any possibility of rid's triggering rj. In addition, we are assuming that a trigger
graph is acyclic to guarantee termination of rule executions [AWH92]. If a trigger graph contains a
cycle, it is possible that once a rule in the cycle is ti l--. i .1 all the rules in the cycle keep triggering
the next rule indefinitely. We also assume that there exists a separate mechanism for detecting
cycles in a trigger graph so that the rule programmer can rewrite the rules in such a case.
A trigger path in a trigger graph is a path starting from any node and ending at a reachable
leaf node. Incidentally, it should be noted that a trigger relationship between two rules does not
necessarily imply a dependency between the rules. For instance, given a trigger edge (ri rj), if
ri for sure triggers rj and no other rules are til.-.-. .1 from ri and rj, there are only two possible
partial RESs for the two rules, (ri rj -rj) and (rj -ri -rj). If there is no data or untrigger dependency
between ri and rj (i.e, the two rules are commutative), the two RESs are equivalent despite the
trigger edge.
4We admit that this definition of "can t ;... I" is rather crude. In Sentinel, for example, if a rule is waiting for an
occurrence of (El; E2), which is a composite event sequence and occurs when E2 occurs provided El occurred before,
the occurrence of El alone never triggers that rule. In our current work, however, we do not pursue this issue any
further. (For event specifications in Sentinel, see [CKAK94].)

r,0 S r4

r20 -------D r5

r3 0 0 r6

Figure 3: A conflicting rule set

r, 0 r, rr4 r r4 r, 0 r4

r2 ------ r r2 ------ r r20---- r

rO 0 r6 r3 0 r r6 r3O r6

(a) (b) (c)

Figure 4: Priority graphs for Figure 3

4 Confluence and Priority Specification

In this section we present basic ideas that give us a handle for dealing with conflicting rules in
order to obtain confluent rules executions. We consider simple cases first. When there are n
distinct rules to execute and m pairs of conflicting rules among them, intuitively, the maximum
number of different final database states that can result from all differing RESs is conservatively
bounded by 2", since each pair of conflicting rules can possibly produce two different final database
states by changing their relative order.

Example 4.1 Figure 3 is a redrawing of Figure l(a) with removal of directions on dependency
edges (r2, r5) and (r3, r5). Note that rl and r4, denoted by solid nodes in the graph, are in UTRS,
a set of rules initially ti -:-. I .. by a user transaction. Assuming that all the six rules are executed,
all complete RESs that can be generated should be equal to a set of possible merged sequences
of two partial RESs (rli r2 3) and (r4 7,5 Tr6). Then, all the possible merged (now complete)
RESs can be partitioned into up to four groups by relative orders between r2 and rs and between
r3 and r5 as follows: (1) (r2 75) (r3 75), (2) (r2 5 r5) (r3 75), (3) (r2 75) (r3 75),
and (4) (r2 rT) (r3 Tr). However, since there exists an inherent order between r2 and T3, i.e.,
(r2 r3), dictated by a trigger relationship, no merged RESs can contain combination (4) due to
a cycle being formed. Combination (4) is dropped from consideration. Since cumulative effect of
all the other rules are the same regardless of their execution order, the three combinations are the
only factors that can make a difference in the final database state. Therefore, in this example, up
to three distinct final database states can be produced by all possible complete RESs. <

Using the three possible orderings of conflicting rules in Example 4.1, we can assign directions
to dependency edges in the graph of Figure 3. Resulting graphs, which we call priority graphs, are
shown in Figure 4. These priority graphs present how priorities can be specified over conflicting rules
in order to make rule executions confluent. Also, importantly, they represent partial orders that
the rule scheduler needs to follow as it schedules rule executions. As we shall see in the following
section, the rule scheduler basically uses a topological sort algorithm working on a subgraph of
priority graph, and this demands the priority graph to be acyclic.

rloO r, rlO rl 0,,

riOu r,2\ r1,,----------O- r2

rs r, rs r3 0 6 r4 .0 rs

r6 r7 ,rs r60.0- r70" r,

r r9 0 r9

(a) (b)

Figure 5: A pair of trigger graph and dependency graph

Example 4.2 All possible topological sorts on priority graph of Figure 4(a) correspond to an
equivalence class represented by a canonical RES, ar = (ri r2 4 r'5 r3 r' 6) -for clarity we use
to denote conflicting rules as r2. Note that a RES, (r'l r4 r2 r r3 r6) is equivalently converted
to ac by shuffling r2 and r4, which are commutative. Similarly, a72 = (rl r'2 r'3 r4 r5 r6) and
03 = (ri 7r4 r5 r2 r3 r6) represent equivalence classes obtained when the topological sort is
carried out on priority graphs of Figure 4(b) and Figure 4((c), respectively.

The formal definition of the priority graph is given below.

Priority graph Given trigger graph TG = (R, ET) and dependency graph DG = (R, ED),
priority graph, PG = (R, Ep) is a directed acyclic multigraph formed by merging TG and DG,
where R is a node set defined as before and Ep is a priority edge set. For any two distinct nodes
u, v E R, (u v) E Ep if and only if (u T v) E ET, and either (u D v) E Ep or (v D u) E Ep if
and only if (u, v) E ED. (u D v) (or (v D u)) is called directed dependency edge to distinguish it
from undirected ones in ED, and the direction of the edge is given by the user.
For a PG, a trigger edge is depicted by a solid arrow line while a directed dependency edge is
depicted by a dashed arrow line. A PG is defined to be a multigraph because it can have more
than one edge (actually two edges, i.e., a trigger edge and a directed dependency edge) between
two nodes. It should be noted that if a node u is an ancestor of a node v in TG and there is a
dependency edge (u, v) in DG, the corresponding directed dependency edge in PG is automatically
set to (u D v), not to form a cycle in PG.

Example 4.3 Figures 5(a) and (b) show a trigger graph and its dependency graph counterpart
respectively. Figure 6 shows a priority graph built out of the two graphs. Note that directions of
dependency edges are determined by the user as a way of specifying priorities between conflicting
rules. However, direction of dependency edge between ri and rs (between r2 and r4 as well) is set
by the system as shown in the graph because rl is an ancestor of rs in a trigger path. <

Note that given a system rule set R, only one PG is built at compile time. The PG contains
nodes for all rules in R. When an active database system is running, subsets of R will be til;--. .1
and executed dynamically. In order to schedule those rules, the rule scheduler builds a subgraph
of PG, called execution graph, when a user transaction triggers rules.

rloO rl

rllO<----------- r2
r3 1 r '
rX 4 r Or,

r6 7 r8

Figure 6: A priority graph


r6 8
'r, r

Figure 7: An execution graph

Execution graph Given a system rule set R, a priority graph PG = (R, Ep), and a UTRS
R' C R, an execution graph EG = (RE, EE) is a subgraph of PG where RE is a node set and EE is an
edge set. RE is recursively defined as RE = {r r E R' V (r' 3(r' r) (r' E RE A (r' r) E Ep)}.
For any two distinct nodes u, v E RE, (u v) E EE if (u v) E Ep and (u v) E EE if
(u D v) Ep. <
Simply stated, the node set RE consists of a UTRS plus those rules that are reachable from
rules in the UTRS through trigger paths in PG. The edge set EE is a set of trigger and directed
dependency edges that connect nodes in RE.

Example 4.4 Figure 7 shows an execution graph derived from a priority graph of Figure 6 when a
UTRS has rules r3, r5, and rio. A rule schedule can be obtained by performing the topological sort
on the execution graph. The canonical RES for the equivalence class represented by the execution
graph is (r3 r6 r77 r75 rs rg rl10 r11). Note that priority graphs shown earlier in Figure 4 are,
in fact, execution graphs as well.

Lemma 2 Given an execution graph EG = (RE, EE), a set of rule execution sequences corre-
- '....'I./ to all feasible ',,./,,1,,.' ii sorts on EG constitutes an equivalence class, independent of the
initial database state.

Proof of lemma 2 Since EG is acyclic and all pairs of conflicting rules in EG are ordered (i.e.,
have an edge between them), all topological sorts on EG should have the same relative orders of

ri ri

rk O, rk Ar k
r,l r, o"r\

(a) (b)

Figure 8: Overlapping trigger paths and extended execution graph

conflicting rules. Then, by Lemma 1, RESs represented by the topological sorts are equivalent each
other. Also, since Lemma 1 holds without any premise on initial database states, Lemma 2 also
holds regardless of initial database states. o

5 Strict Order-Preserving Rule Execution Model

Thus far, only simple cases were taken into account. Specifically, trigger graphs are of a tree
structure, all rules in a UTRS are distinct, and no parent/child relationship exists among the rules.
As a result, no trigger paths in the execution graph overlapped with one another. When rules
in a UTRS have overlapping trigger paths, the priority graph and execution graph defined in the
previous section does not capture the semantics. For example, consider Figure 8(a) which is the
same as Figure 2(a). When ri and rj are tl _-. I. .1 by a transaction, both rules instantiate their own
trigger paths, and these trigger paths overlap with each other 5he overlapping of trigger paths is not
directly visible in Figure 8(a). Treating the graph as an execution graph yields two partial RESs :
(ri rj rk r1) and (rj rk r4). Therefore, the rule schedule or alternately the complete RES should
be a merged RES of the two partial RES's. A possible merge RES is (ri rj r rkj r1 rk rk). In
order to accomplish, we need to (i) obtain a complete RES using topological sort and (ii) determine
the equivalence class of an execution. These issues are addressed in this section.

5.1 Extended Execution Graph
In order to understand the effect of overlapping trigger paths, we introduce an extended execution
graph, used only for illustration purposes. Recall that given a rule set along with its trigger graph,
each rule in a UTRS instantiates a subgraph of the trigger graph, whose sole root is that rule.
However it is possible to derive an execution graph, from a given priority graph and a UTRS, such
that every rule in the UTRS becomes a root node in the resulting extended execution graph.

Example 5.1 Figure 8(b) shows the extended execution graph of Figure 8(a). In the extended
execution graph, rj and r (similarly other rules as well) are the same rule and only represent
different instantiations. Since a dependency exists between rules rk and ri, it may be present
between all instantiations of rj and ri as shown in Figure 8(b). Directions of dependency edges
in an extended execution graph may be either inferred from the priority graph or specified by the
user. Figure 9 shows three different acyclic orderings of relevant dependency edges of Figure 8(b).


rj 0 Or1
ri r

rk k


ri *

ro U rj




r, 0r


Figure 9: Three different orderings of dependency edges in Figure 8(b)

Figure 10: Extended execution graph in strict order-preserving executions

Once an acyclic extended execution graph is given, the rule scheduler can schedule rule executions
using topological sort. All possible topological sorts constitute one equivalence class.

The extended execution graph, however, cannot be used for priority specification; it is created
only at rule execution time and priorities need to be specified before that. Thus we need to find
alternative ways to interpret a priority graph.

5.2 Strict Order-Preserving Executions

One way to derive an extended execution graph is to faithfully follow what the user specifies in the
priority graph, i.e., priorities between conflicting rules. In strict order-preserving executions, if rule
ri has precedence over rule rj in a priority graph, all instances of ri precede all instances of rj in
resulting rule schedules. Given a priority graph, an extended execution graph is obtained by simply
adding directed dependency edges in the priority graph to duplicated overlapping trigger paths.
This scheme provides a simple solution for overlapping trigger paths, regardless of the number of
times trigger paths overlap.

Example 5.2 Figure 10(a) shows a priority graph where rules rl, r2, and r3 are in UTRS and
their overlapping trigger paths are denoted by partial RESs, (ri r2 r4 rs), (r2 r4. r 5), and
(r3 r 74 75). Figure 10(b) illustrates how an extended execution graph is built using strict order-
preserving executions. First, overlapping trigger paths are separated. Second, any dependency
edges connecting a rule in an overlapping trigger path with a rule in any trigger path is also
introduced in the extended execution graph. For example, (r2 r4) and (r'3 r). Given the

r l> m(l)

m (2)
r m2 r3 m(l)

r4 m(3);

r5 Otkm(3)

Figure 11: Extended execution graph with rule_counts

extended execution graph, the rule scheduler can schedule rule execution by performing a topological
sort. All feasible topological sorts should constitute one equivalence class since in the topological
sorts, executions of all conflicting rules are ordered in the same ways. The canonical RES for the
extended execution graph of Figure 10(b) is (r r2 r r22 r 3 r4 r4 r4 r5 r5 r5). (Note that r,, r',
and r" are the same rule.)

5.3 Implementation

In order to implement a rule scheduler conforming to strict order-preserving execution, one could
directly use extended execution graphs shown in Figure 10(b). However, a simpler way for deriv-
ing an execution graph without duplicating every overlapping trigger path exists. Consider the
extended execution graph of Figure 10(b). In the strict order-preserving execution, directions of
all dependency edges incoming to and outgoing from overlapping trigger paths are all the same,
as shown in the graph. Therefore, it is unnecessary to duplicate overlapping trigger paths. We,
instead, add a rule_count to each node of a plain execution graph. A rule_count attached to a node
indicates how many rules in UTRS share the trigger path which the node (i.e., rule) belongs to.
Figure 11 depicts how the plain execution graph of Figure 10(a) is extended using rule_counts. In
the new graph, m(i) denotes the sharing of the trigger by i instances of the associated rule.
Now the new extended execution graph can be used with a minor modification to perform the
topological sort. Whenever a rule is scheduled, its rule_count in the execution graph is decreased
by 1. If the rule_count reaches 0, the node and outgoing edges are removed from the execution
Figure 12 describes an algorithm, Build_EGO for building an execution graph for given a priority
graph (PG) and a UTRS. It uses M[], an array of size of the system rule set R, to hold rule_count
values of rules in EG. If rule r' is (to be) in EG, M[i] represents the rule_count attached to
r'. Build_EGO calls a subroutine, DFSCopy_Tree() for every instance in UTRS. Remember that
UTRS is a multiset. It can have multiple instances of the same rule due to multiple triggers.
DFSCopy_Tree() traverses the PG in the depth-first search fashion and copies a portion of the PG
that are reachable through trigger edges in PG. It also increases rule_count of each node that it
visits. The execution graph of Figure 11 is obtained by applying Build_EGO to the priority graph
of Figure 10(a) with UTRS = {ri, r2, r3}.
Once an execution graph is built by Build_EG), the rule scheduler can schedule rule executions.
It is possible that some rules in a trigger path in an execution graph not be ti;-.-. i .1 at all by
its parent rule at run time. In such a case, other rules in other trigger paths, having incoming
dependency edges from that rule, should not wait. Furthermore, if a rule is not ti;.- .1 all its
descendant rules in the trigger path will not be t ;i.-. d.1 either. This should be applied recursively
down trigger paths.

Given PG and UTRS:

EG = 0;
initialize array M[ ] to 0's; // M[ ] is rule_count array
for every ri E UTRS do
call DFS_Copy_Tree(ri);

DFS_Copy_Tree(r) {
if (ri EG) then
copy ri into EG;
M[i]++; // increase rule_count of node ri
// copy trigger edges
for all rj such that 3(ri rj) E PG do{
call DFS_Copy_Tree(rj);
if ((ri T rj) EG) then
copy (ri rj) into EG;
// copy dependency edges
for all rj such that 3(r D rj) E PG do{
if (rj E EG) and ((ri D rj) ( EG) then
copy (r D rj) into EG;

Figure 12: Algorithm Build_EG(

Figure 13 describes the rule scheduling algorithm, Schedule(), which is a modified version of
topological sort. Given an execution graph EG, it arbitrarily selects a node (i.e., a rule) with
indegree 0. Since EG is acyclic, there should always be at least one node with indegree 0. After
executing the selected rule, the scheduler decreases the node's rule_count by 1. If a node's rule_count
reaches 0, the node is removed along with any trigger and dependency edges outgoing from the
node. However, before the removal, it checks whether the executed rule has tI;--'. i I child rules
in trigger paths. If there are child rules that are not til--'. I..1 then Schedule() calls a subroutine
DFSDec_M( for those child rules. DFSDec_M( traverses down EG in a depth-first fashion and
decreases rule_count of each node it visits by 1. If a node's rule_count becomes 0, it removes the
node and all outgoing edges.

Theorem 1 The strict order-preserving rule execution model guarantees confluent rule executions.

Proof of theorem 1 Based on Lemma 2, algorithms Build_EG( and Schedule) together serve
as a constructive proof for the theorem since by the algorithms, overlapping trigger paths are
separated, effectively making them ordinary acyclic graphs, and the topological sort is performed
on the graphs. o

Given EG:

while (EG Q0) do{
choose a node ri with indegree 0;
execute ri;
M[i]--; // decrease rule_count of node ri
for all rj such that 3(r rj) E EG do
if (rj was not triggered by execution of ri) then
call DFSDecM(rj);
if ( M[i] = 0 ) then
delete node ri and edges (ri rk) and (r D rl), for any k and 1, from EG;

for all rk such that (rj Irk) do
call DFS_DecM(rk);
if ( M[j] = 0 ) then
delete node rj and edges (rj ri) and (rj rm), for any I and m, from EG;
// don't need to delete dependency edges incoming to rj!

Figure 13: Algorithm -Schedule()

5.4 Parallel Rule Execution

The execution graph naturally allows parallel execution of rules. In the extended form, such as
Figure 10(b), all rules with indegree 0 can be launched in parallel for execution. Since there should
be no dependency edges between nodes with indegree 0 in an execution graph,6 relative execution
order of those independent rules does not affect the final outcome. Note also that multiple instances
of the same rule can be scheduled for execution at the same time.
In an execution graph with rule_counts, which we use for our work, all rules with indegree 0 are
scheduled simultaneously as many times as the rule_count associated with the rules. In Figure 11,
for instance, after scheduling and executing each one instance of rl and r3 in parallel, two instances
of r2 can be scheduled for execution since rule_count of r2 is 2. In order to implement the parallel
rule executions, we have to make some changes to the algorithm of Figure 13 which we will not
elaborate in this paper. Whenever execution of one instance of a rule is completed, the associated
rule_count need be decreased by 1 and its child rules have to be checked to see whether they are
til.--. i.. or not by the parent rule. If some are not ti-.-. ..1 DFSDec_M( should be called to
recursively decrease rule_counts along trigger paths. Since the rule_count array M[] and execution
6Note that an execution graph reduces is size as rules are executed.

graph are shared data structures, some locking mechanism need be used to avoid update anomalies
within the data structures.
One important measure in parallel processing is the degree of parallelism. In the active rule
system, the maximum parallelism is bounded by dependencies between rules in the system rule
set. For instance, if all the rules are independent of each other, ideally all til-.-. .1 rules can
be executed in parallel. As dependencies between rules increase, the degree of parallelism would
decrease. However, other components too can restrict parallelism. As discussed in Section 2,
improper priority specification and rule execution model may execute a given rule set serially which
could be executed in parallel. Specifically in our work, two components can hamper parallelism, all
resulted from static analysis. First, precision of dependency analysis between two rules can affect
parallelism. Even though there is data dependency between two rules, they can be commutative
in reality. Being unable to detect such a hidden commutativity results in a false dependency edge
in an execution graph, likely costing parallelism. Second, precision of trigger relationship analysis
can similarly affect parallelism. If we know for sure that one rule triggers another rule, the trigger
edge between the two rules can be deleted after all rule_count values are computed. This way, the
two rules can be scheduled in parallel if there is no other path connecting them in the resultant
execution graph. Using static analysis, we cannot completely avoid uncertain trigger edges, and
presence of the uncertain trigger edges can cost parallelism. However, ignoring the loss caused
by imprecision of static analysis, the strict order-preserving rule executions exploit the maximum
parallelism existing in a given system rule set. We state it in Theorem 2.

Theorem 2 Using the strict order-preserving rule executions, the active rule execution model
achieve the maximum parallelism within limitations of static trigger and dependency analysis.

Proof of theorem 2 Given any acyclic extended execution graph, there are two kinds of edges;
trigger edges and dependency edges. We first assume that no trigger edges can be removed, that
is, they are all uncertain trigger edges. Now suppose there are superfluous dependency edges in the
execution graph whose absence does not affect the final database state. (Therefore we can remove
them safely to increase parallelism.) There can be only two types of dependency edges in an acyclic
execution graph. Given any dependency edge (ri -D rj), ri is either a proper ancestor of rj in a
trigger path containing both ri and rj or not an ancestor of rj in any trigger path. In the first
case, even though the dependency edge is redundant in terms of representation, removal of that
edge does not allow rj to execute before ri since rj is yet to be tib:.-. 1 .1 by ri or its descendant.
Thus, removal of the first type of dependency edges has no effect of increasing parallelism. In
the second case, if (ri D rj) is the only dependency path that can be interconnected by trigger
edges and dependency edges to connect ri to rj, obviously this cannot be removed at any rate. If
there exist other dependency paths connecting ri to rj whose lengths are longer than (ri D rj)
(of course, if such paths exist, they should be longer than one-edge path (ri rj)), (ri rj) is
redundant, but again, removal of the dependency edge deos not allow rj to execute before ri. By
applying this argument to all dependency edges present in the extended execution graph, we can
see that dependency edges are either necessary or redundant, but removal of redundant edges does
not increase parallelism. Since the execution graph with rule_counts are equivalent to the extended
execution graph under the strict order-preserving rule executions, we can conclude that the rule
scheduler exploit the maximum parallelism inherent in the system rule set. O

6 Conclusions

In this paper we have proposed a new active-rule execution model, along with priority specifica-
tion schemes, to achieve confluent rule execution in active databases. We employ prioritization to
resolve conflicts between rules. Ideally, by prioritizing executions of conflicting rules, whose dif-
ferent relative execution orders can yield different database states, one can achieve confluent rule
execution. It is necessary, however, to prioritize as few rules as possible primarily for two reasons:
i) prioritizing many rules in a meaningful way is itself a challenge, and ii) the less rules prioritized
increases the potential for parallel execution of rules. Prioritizing conflicting rules only, on the other
hand, may yield incorrect results; execution of seemingly independent rules can trigger and execute
conflicting rules in the wrong way. Also, additional problems arise when rules (in the same trigger
path) are ti -.-. i' and result in overlapped trigger paths. Unlike previous rule execution models,
our model uses a rule scheduler based on the topological sort to respect all the specified priorities
if applicable. This way, rules being ti -.-. -. I and executed from a user transaction can follow the
execution sequence imposed by priority specifications to make their execution confluent. We also
have proposed strict order-preserving rule execution to deal with overlapping trigger paths. In
strict order-preserving rule execution, when a part of or the whole trigger path is multiply executed
and there are priorities between rules in the trigger path, the rules are executed in such a way that
no rule appears before rules with higher priorities if any. It has been shown that our rule execution
model can exploit maximum parallelism in rule execution.
In order to handle overlapping trigger paths, we have explored other alternatives than the
strict order-preserving rule execution. Serial trigger-path execution and serializable trigger-path
execution are them, but due to space limit they are omitted in this paper. The full description of
these alternative is found in [K("C'.]
We are currently investigating other issues not addressed in this paper. One issue is the precision
of data dependency (or dependency in general). Our definition in Section 3.2 may be too coarse
as some rules might be commutative despite presence of the defined dependencies. Another issue
is related to coupling modes defined in HiPAC [C+89]. In this paper, we assumed the immediate
coupling mode between. The semantics of confluent rule execution in the deferred and detached
coupling modes needs to be addressed.


[ACL91] R. Agrawal, R. Cochrane, and B. Lindsay. On maintaining priorities in a production rule system.
In Proceedings International Conference on Very Large Data Bases, pages Il'1 1-7, Barcelona,
Spain, 1991.
[AMC93] E. Anwar, L. Maugis, and S. Chakravarthy. A new perspective on rule support for object-
oriented databases. In Proceedings International Conference on Management of Data, pages
99-108, Washington, D.C., May 1993.
[AWH92] A. Aiken, J. Widom, and J. Hellerstein. Behavior of database production rules: Termination,
confluence, and observable determinism. In Proceedings International Conference on Manage-
ment of Data, pages 59-68, San Diego, CA, 1992.
[BFK \I .] L. Brownston, R. Farrell, E. Kant, and N. Martin. Programming Expert Systems in OPS5: An
Introduction to Rule-Based Programming. Addison-Wesley, Reading, MA, 1 I".
[C'+i] S. Chakravarthy et al. Hipac: A research project in active, time-constrained database manage-
ment (final report). Technical Report XAIT-89-02, Xerox Advanced Information Technology,
Cambridge, MA, Aug. 1989.

[CKAK94] S. Chakravarthy, V. Krishnaprasad, E. Anwar, and S.-K. Kim. Composite events for active
databases: Semantics, contexts, and detection. In Proceedings International Conference on Very
Large Data Bases, pages 606-617, Santiago, Chile, Sep. 1994.
[C\\' l] S. Ceri and J. Widom. Deriving production rules for constraint maintenance. In Proceedings
International Conference on Very Large Data Bases, pages 566-. -' Brisbane, Australia, 1990.
[C\\'Il] S. Ceri and J. Widom. Deriving production rules for incremental view maintenance. In Pro-
ceedings International Conference on Very Large Data Bases, pages .';-589, Barcelona, Spain,

[GJ91] N. Gehani and H. Jagadish. Ode as an active database: Constraints and triggers. In Proceedings
International Conference on Very Large Data Bases, pages 327-and 336, Barcelona, Spain, 1991.
[Han92] E. Hanson. The design and implementation of the Ariel active database rule system. Technical
Report UF-CIS-018-92, CIS Department, University of Florida, Gainesville, FL 32611, 1992.

[HW93] E. Hanson and J. Widom. An overview of production rules in database systems. The Knowledge
Engineering Review, 8(3):121-143, Sep. 1993.
[K(C' ] Seung-Kyum Kim and S. Chakravarthy. A confluent rule execution model for active databases.
Technical Report UF-CISE-, CISE Department, University of Florida, Gainesville, FL 32611,

[SHP88] M. Stonebraker, E. Hanson, and S. Potamianos. The POSTGRES rule manager. IEEE Trans-
actions on Software Engineering, 14(7):897-907, July 1988.
[SJGP90] M. Stonebraker, A. Jhingran, J. Goh, and S. Potamianos. On rules, procedures, caching and
views in database systems. In Proceedings International Conference on Management of Data,
pages 281-290, Atlantic City, NJ, 1990.

[WCL91] J. Widom, R. Cochrane, and B. Lindsay. Implementing set-oriented production rules as an
extension to starburst. In Proceedings International Conference on Very Large Data Bases,
pages '', -'' Barcelona, Spain, 1991.

[WF90] J. Widom and S. Finkelstein. Set-oriented production rules in relational database systems. In
Proceedings International Conference on Management of Data, pages ''".' 270, Atlantic City, NJ,

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