The PARK Semantics for Active Rules Georg Gottlob
Guido Moerkotte
Institut fur Informationssysteme Technische Universitat Wien A-1040 Wien, Austria
Lehrstuhl fur Informatik III RWTH-Aachen 52056 Aachen
[email protected]
[email protected]
V.S. Subrahmanian
Department of Computer Science University of Maryland College Park, MD 29742
[email protected]
October 26, 1995
Abstract Active databases are an important topic of current database research. However, the semantics of the underlying mechanism, event-condition-action rules (or ECA rules for short), is unclear so far. In order to de ne a clear semantics for sets of active rules, we rst derive the requirements such a semantics must ful ll. Since currently no semantics ful lls these requirements, we continue with the de nition of the PARK semantics adhering to all requirements. The PARK semantics is a smooth integration of in ationary xpoint semantics [6] with con ict resolution. Through this approach, the PARK semantics is powerful enough to deal with recursive active rules. Furthermore, the actual con ict resolution strategy is a parameter of the PARK semantics. This guarantees a wide range of applicability.
1 Introduction During the last few years, there has been increasing interest in active database systems. Independent of the underlying data model, event-condition-action rules [7] are at the core of all approaches. Since the introduction of ECA rules, many di erent languages for ECA rules have been proposed and quite a few prototype systems have been built. (For an overview see [2, 1].) Nevertheless, current research falls short of supplying a clean semantics for these systems. It is our intention to ll this gap. When it comes to de ning a semantics for active rule systems, several challenges have to be met. Besides recursion, the most striking challenge is inconsistency, i.e., the possibility of situations where two con icting rules are rable. Whereas this situation can naturally occur in active databases, it does not occur in pure deductive rule systems. Hence, their semantics cannot directly be applied to active rule systems. 1
Nevertheless, research in semantics for deductive rule systems should not be neglected: if no two con icting rules are ever rable, some xpoint semantics maybe appropriate. It is only in the case of con icts that deviations become necessary. These deviations, i.e., the special treatment necessary to deal with con icts, are typically referred to as the con ict resolution strategy. Following these lines, our approach to de ne a semantics for active rule systems o ers a smooth integration of an existing well-known semantics for deductive rule systems (the in ationary semantics [6]) with con ict resolution. Furthermore, since con ict resolution strategies are highly system and application dependent, any semantics should be parameterizable with a special con ict resolution strategy. This avoids the necessity to de ne a new semantics each time the con ict resolution strategy changes. The PARK semantics for active rule systems as de ned in this paper provides this modularity. Before one can study the semantics of active rule systems, the requirements and obstacles should be made clear. Section 3 gives a list of requirements a semantics for active rule systems should ful ll. Further, this section lists existing semantics for deductive and active rule systems together with the requirements they fail on. Keeping these requirements in mind, we discuss, by means of examples, the obstacles of active semantics (Sec. 4.1). Then, we are well prepared to introduce the PARK semantics of active rule systems in Section 4.2 for condition action rules. In a later step, the semantics is enhanced in order to capture full ECA rules (Sec. 4.3). Several more involved examples demonstrate the exibility and naturalness of the PARK semantics (Sec. 5). Section 6 concludes the paper. Before we start with the requirements, let us rst introduce the basic concepts used throughout the paper.
2 Basic Concepts An active rule is a rule of the form
l1 ; l2; : : :; ln ! l0 where the following holds:
The body literals li for 1 i n may be positive or negated atoms. Negation :a of an atom a is understood as negation by failure and not as classical negation.
The head literal l0 is positive and pre xed by a \+" or \?". The intuition is that it should be inserted into the database or deleted from the database, respectively.
So far, active rules do not allow the speci cation of events within their body. That is, the rules are restricted to a condition-action form. At the end of Section 4 we give a treatment for event speci cations within rule bodies, thus yielding full event-condition-action rules. As an example of a condition-action rule, consider the rules
emp(X ); :active(X ); payroll(X; SALARY )! ? payroll(X; SALARY ) which speci es that if a non-active employee has a record in the salary relation, then this record should be deleted. 2
As is common for datalog, we require active rules to ful ll the following safety conditions: 1. Each variable occurring in a rule head should also occur in the body of the same rule. 2. Each variable occurring in a negated literal in the rule body must also occur in some positive literal in the rule body. A database instance, D, is a set of (positive) ground atoms. The semantics of a set of active rules w.r.t. a database instance D will be de ned in Section 4, after discussing the requirements for a semantics of active rules in the next section.
3 Desired Properties of Active Rule Semantics In this section we will discuss the desired properties of a good active rule semantics and conclude that none of the existing semantics has these properties:
Unambiguous Semantics. Since the evaluation of active rules implies updates to the database
instance D, we do not want to end-up with two or more di erent database states. This is possible in logic programming (e.g. stable model semantics) or for query answering, but inconceivable in the case of active databases.
Independence from Con ict Resolution Policies. In all known active database systems, con icts may arise naturally. A con ict is a situation where two or more active rules are rable and one of these rules requires the insertion of some atom a while (at least) one of the others requires the deletion of a. A con ict resolution policy is a method of determining which of these con icting actions is to be performed and which is to be suppressed. Each existing approach to active databases has a xed con ict resolution policy which is an integral part of the semantics. We postulate that given any con ict resolution policy SELECT, there must be a uniform method of de ning a semantics of active databases based on that policy. In other words, the overall semantics of active databases has two components: an inference component and a con ict resolution component that work together. The design of these two components should be largely independent. This will ensure that it is not necessary to rede ne the semantics of active databases over and over again just because new con ict resolution policies are required in new domains. Instead, when designing the inference engine, the con ict resolution policy can be treated as a \black-box" or an \oracle." Flexible Con ict Resolution. Consider a situation where two active rules are rable { one
of these requires addition of a, while the other requires the deletion of a. As we shall demonstrate later in the paper (through an example), which of these two actions must be performed may depend critically upon the atom in question. Therefore, con ict resolution must be exible and allow for the articulation of sophisticated policies that vary from atom to atom depending, perhaps, on other properties in the database and the program, or via interactive input from the user. This means that in the formal semantics for active databases, a con ict resolution policy 3
may be viewed as a function, SELECT, which, given all the context information of the con ict yields for a ground atom either insert or delete. The context information includes the database instance D, the program P , the current state of the computation I , and a description of a con ict c. (The constituents I and c will be formalized later on.) Intuitively, SELECT(D; P; I; c) = insert means that in the event of a con ict about whether to insert or delete a, a should be inserted. The actual implementation of the function can be logical, or procedural, depending upon the needs of the application.
Basic Inference Engine. In the absence of con icts, the basic inference engine which com-
putes the updates must be compatible with some well-understood semantics, e.g., for Datalog. Further, it must be powerful enough to deal with recursive active rules. The semantics should preferably be explained by a xed-point construction which can be directly implemented. We believe that a xed point semantics combines the advantages of being both mathematically clean and directly implementable. Summarizing, we can state the following: ActiveDBSemantics = DeclarativeSemantics + Con ictResolutionPolicy : Further, the semantics has to treat full event-condition-action rules.
Polynomial Tractability. The method should be tractable, i.e., the result database state
should be computable in time polynomial in the size of the input database instance. This immediately implies that they should at least terminate.
Implementability on top of commercial DBMS. The method should be easily imple-
mentable on the top of a commercial DBMS. All existing semantics fall short on at least one of the above requirements. Those developed for deductive rules do not have any con ict resolution strategy [6, 4]. Special semantics for active databases are not only rare but also fail on the requirements above. Some do not necessarily terminate [3, 11], are not polynomial [8], or do not always result in a unique state [3, 8].
4 The PARK semantics 4.1 Introductory Examples The major problem with the semantics of active rules is that the straightforward processing of rules may lead to con icting actions, i.e. insertion and deletion of the same data item. In this subsection we use examples to illustrate how the in ationary semantics of Kolaitis and Papadimitriou [6] may be used in conjunction with appropriate con ict resolution policies to de ne a semantics for active databases. 4
In order to simplify discussion, in this section we will use a speci c xed con ict resolution policy called the principle of inertia. This principle ignores con icting actions. For instance if actions +a and ?a are both implied by some rable rules r1 and r2, respectively, then both actions are ignored as they are con icting commands, and the status of a in the result remains the same as in the input database (hence the name inertia). A con ict c of the above kind is described by a triple (a; fr1g; fr2g) where a is the atom for which the con ict arizes and the second (third) component is the set of all ground rule instances with valid body that require the addition (deletion) of a. Here, the validity of the body of the rule depends on the validity of the literals with respect to a given state of computation I (see below for a formalization). In other words, the principle of inertia corresponds to the case where the function SELECT is de ned as follows: SELECT(D; P; I; (a; ins; del)) = insert i a was present in the original database instance D; SELECT(D; P; I; (a; ins; del)) = delete otherwise. It is important to note that the con ict resolution policy (whatever it may be) is enforced even if +a and ?a are not computed in the same computation step. For example, consider the following rule-set P1 operating on a database D = fpg: 1. p! + q 2. p! ? a 3. q ! + a During the computation, we will mark added facts with + and deleted facts with ? while facts that were present in the original database remain unmarked in order to distinguish them later from computed actions. If we envisage, as usual, a step by step computation which at each step applies all rules in parallel (producing immediate consequences), then, after the rst step, we would get the intermediate result fp; +q; ?ag and after the second step the nal xed point fp; +q; ?a; +ag. This includes a con ict which must be resolved using the con ict resolution policy (which in our case, happens to be the principle of inertia). This causes us to eliminate +a; ?a getting fp; +q g. Finally, we e ectively apply the remaining non con icting actions, in our case, the unique action +q , getting the result database state fp; q g. Note that by eliminating the con icting pair +a, ?a, the status of a remains the one of the original database (namely, \absent"), since no action whatsoever on a is executed. So far so good. However, a slightly more complicated program may create considerable confusion. This confusion is due to the fact that some intermediately asserted (or deleted) facts which will later become obsolete entail some further deletions or insertions. Consider, for instance, the same database D = fpg and the program P2 1. p! + q 2. p! ? a 3. q ! + a 5
4. :a! + r 5. a! + s If we stubbornly apply the immediate consequence operator, we get the following intermediate results after each step: after step 1: fp; +q; ?a; +rg after step 2: fp; +q; ?a; +r; +ag after step 3: fp; +q; ?a; +r; +a; +sg = nal xed point. Now, in this nal xed point, as before, we recognize that ?a and +a are con icting and eliminate these two marked atoms using the principle of inertia as the con ict resolution policy. We are thus left with fp; +q; +r; +sg. After e ectively incorporating the updates, we get the result database state fp; q; r; sg. But is this what we really want? Note that +s was obtained by rule (5) based on the presence of +a. However, +a was afterwards recognized to be con icting and was eliminated. Since a was not present in the original database and is not present in the result, rule (5) should not re. As a consequence, s should not stay in the nal result. In a similar manner, atom r is introduced based on rule (4) whose body depends on the con icting atom a. However, in this case, since a is not present in the original nor in the nal database, rule (4) may well re and produce r. The desired result database state is thus fp; q; rg. In summary, in order to get the correct result, we cannot just compute the xed point of the immediate consequence operator and then eliminate con icting marked literals. Whether a marked fact will stay in the result or not should depend on the reasons why it was asserted. Basically, if the reason for existence of such a literal is solely grounded on con icting literals that are afterwards invalidated, then the literal should stay out. If, however, there are valid reasons for the literal, such as nondeleted atoms of the original database or noncon icting marked literals, etc., then it should stay in. Yet another problem is the problem of false con icts. Consider, for example, the following program P3 on database instance D = fpg. 1. 2. 3. 4. 5.
p! + q p! ? q q! + a q! ? a p! + a
Applying the immediate consequence operator, we get the following intermediate results after each step: 6
after step 1: fp; +q; ?q; +ag after step 2: fp; +q; ?q; +a; ?ag = nal xed point. It would thus seem that a is ambiguous. However, the ambiguity of a is a false ambiguity! Since q , which is derived before a is ambiguous, and thus maintains its original status (=absent from the database according to the principle of inertia), we should not use q to derive +a or ?a. Therefore, ?a should not be derivable and thus a should not be an ambiguous literal. However, since we can derive +a by rule (5), +a should stay in the nal xed point. The correct result is therefore fp; +ag, or, after incorporating the updates, fp; ag. The last example shows that it is very important to forbid that any consequences are drawn from ambiguous marked literals. But how are we to achieve this? The algorithm in the next subsection will show that this is e ectively { and easily { possible.
4.2 The PARK xed-point semantics In this subsection we give a complete formal de nition of the PARK semantics. The semantics is illustrated by means of two examples with di erent con ict resolution strategies in Section 5. Let us start with the de nition of some relevant concepts. The Herbrand base H (P; D) of a database instance D and a program P is de ned as usual. It consists of all ground positive literals made from predicate and constant symbols found in P and D. Extended Herbrand base. The extended Herbrand base H (P; D) corresponding to a set of active rules P operating on a database instance D is de ned by:
H (P; D) = fa; +a; ?a j a 2 H (P; D)g: If P and D are understood, we just write H . Intermediate interpretations. An intermediate interpretation (shortly i-interpretation) consists of a set of positive atoms plus a set of atoms marked by + or ?. We say that an i-interpretation is consistent if it does not contain a pair of literals +a, ?a. If I is an iinterpretation, then I ? denotes all atoms in I marked by ?, I + denotes all atoms in I marked by +, and I ? denotes all unmarked atoms in I . If P is a set of active rules and D a database, then an i ? interpretation of (P; D) is a subset of H (P; D). Literal validity. The validity of a ground literal a in an i-interpretation I is de ned as follows. If a is positive, then a is valid in I i I \ fa; +ag = 6 ;, thus, i at least one, a or +a is contained in I . If a = :b is a negative literal, then a is valid in I i one of the following conditions applies: (1) ?b 2 I or (2) I \fb; +bg = ;, in words, i either there exists a delete action on b or neither b nor +b appear in I (and hence, :b is true by negation as failure or the closed world assumption). If a literal a is valid in an i-interpretation I , we write valid(a; I ). Con icts. A tuple (r; ) where r is a rule and is a ground substitution for r is called a rule grounding . Let P be a set of active rules and I an i-interpretation. Then conflicts(P; I ) is a set of maximal triples of the form (a; ins; del) such that a is a ground atom and ins and del are sets of rule groundings. For each such triple the following conditions must hold: 7
1. a is a ground atom and there exist 2. rules r and r0 in P and ground substitutions and 0 such that
valid(li; I ) for all body literals li of r, valid(li00; I ) for all body literals li0 of r0, and for the heads +l0 of r and ?l00 of r0, l0 = l00 0 = a holds. 3. For all possible r; r0 and ; 0 ful lling 2), (r; ) 2 ins and (r0 ; 0) 2 del. Each tuple (a; ins; del) 2 conflicts(P; I ) is called a con ict . Consider the program P containing the rules r1 : p(x)! + q (x) and r2 : p(x)! ? q (x) together with the i-interpretation I = fp(a)g. Then
conflicts(P; I ) = f(q(a); f(r1; [x
a])g; f(r2; [x
a])g)g:
Note that con icts looks one step into the future. That is, con icts detected need not be present in I . Con ict resolution policy. A con ict resolution policy is a map SELECT from 1. a database instance D, 2. a program P , 3. an i-interpretation I , and 4. a con ict c to insert, delete. Intuitively, SELECT(D; P; I; (a; ins; del)) = delete (resp. insert) means that for the current con ict, the action to take on atom a is deletion (resp. insertion). The subsequent de nition is motivated as follows. Whenever a con ict arises, its derivation must be hindered. In order to do so, we block rule instances from being red. Blocked Rule Instances. Let P be a set of active rules, SELECT be a con ict resolution policy, and I an i-interpretation. Suppose we set
X = fdel j (a; ins; del) 2 conflicts(P; I ) and SEL(D; P; I; (a; ins; del)) = insertg Y = fins j (a; ins; del) 2 conflicts(P; I ) and SEL(D; P; I; (a; ins; del)) = deleteg: Then
1 0 [ [ delA blocked(D; P; I; SELECT) = @ del2X
8
[ ins2Y
!
ins :
As an example, suppose D = fp(a)g and P consists of the rules
r1 : p(x)! + q(x) r2 : p(x)! ? q(x) and I = fp(a); +q (a); ?q (a)g. Then
con icts(P,I) = f(q(a); f(r1; [x a])g; f(r2; [x a])g)g and for
SELECT(D; P; I; (q (a); f(r1; [x
a])g; f(r2; [x
a])g)) = insert
we have
blocked(D,P,I,SELECT) = f(r2; [x a])g
The incorporate operator. The operator incorp transforms a consistent i-interpretation into a traditional (2-valued) Herbrand interpretation by incorporating the updates: incorp(I ) := (I ? [ faj + a 2 I +g) ? faj ? a 2 I ? g = (I ? ? faj ? a 2 I ? g) [ faj + a 2 I + g):
Immediate consequence operator ?P;B . After these important de nitions, we are ready
to de ne the immediate consequence operator ?P;B for a set P of active rules and a set of blocked rule instances B . For each i-interpretation I , ?P;B (I ) is the smallest set U satisfying the following conditions:
IU If r = l1; : : :; ln ! l0 is a rule in P and a ground substitution for r such that { (r; ) 62 B and
{ valid(li; I ) for all body literals li of r
then l0 2 U . So far, this is an almost traditional de nition of the immediate consequence operator except that in the traditional de nition 1. the rst condition is omitted and 2. certain rule instances can not be blocked in classical LP. However, as we have seen in the last section, we can not just compute its least xed-point due to con icts without paying attention to con icting rules. So far, B captures part of the mechanism to cope with con icts. As already indicated by the de nition of ?, it does not 9
suce to compute a xpoint starting from some i-interpretation. Instead of i-interpretations, we have to work on bi-structures which we introduce next. Bi-structures. A bi-structure < B; I > consists of a set B of blocked rule instances and an i-interpretation I . Bi-structures are ordered according to the ordering :
(
< B; I > < B 0 ; I 0 > i
B B0 or 0 0 B = B and I I :
For two bi-structures A and B, let us write A B if either A = B or A B. Note that is a partial ordering on bi-structures. For a bi-structure A = (B; I ) we write int(A) to denote I . The idea is now to operate on bi-structures instead of operating on i-interpretations. We therefore de ne a transition operator from bi-structures to bi-structures as follows. Let A = (B; I ) be a bi-structure and SELECT be a con ict resolution policy. Then we de ne P (A) by ( if ?P;B (I ) is consistent P (A) = < B; ?P;B (I ) > ? < B [ blocked(P; I; SELECT); I > otherwise: Strictly speaking, the operator should be subscripted with SELECT { however, for the sake of simplicity, we will omit such subscripts whenever this is clear from context. Note that as shown in the theorem below, the operator is growing; this means that for each bi-structure A, A (A). Let us denote the repeated applications of as follows: 0P (A) = A; iP+1 (A) = P (iP (A)); as there are only nitely many pairs (B; I ), it follows that there must be a minimal integer k such that kP (A) = kP+1 (A); instead of explicitly talking of this minimal integer k, we will usually denote kP (A) by !P (A). It follows immediately from the fact that P is growing that !P (A) is a well-de ned bi-structure and that !P (A) is a xed-point of P . Moreover, if !P (A) = (B; I ), then I = lfp (?P ). Let us discuss the relationship of with the in ationary xpoint operator [6]. If no con ict arises does not change the program P ; only the i-interpretation of the bistructure is changed by . This is done the following way. The operator successively applies ? to some i-interpretation and unions the result with the original i-interpretation. This strongly resembles the in ationary xpoint [6]. On the other hand, as soon as a con ict arises, the operator immediately stops its in ationary computation and performs instead a con ict resolution step. Thus, the PARK semantics | building on | may be viewed as a smooth cycle integrating in ationary xpoint computation and con ict resolution policies.
Theorem 4.1 Suppose P is a set of active rules, and A = (B; I ) is a bi-structure. Then: 1. A P (A), and 2. !P (A) is a xed-point of P , and 3. if !P (A) = (B 0 ; I 0), then I 0 = lfp (?P ;B ). 0
0
10
Proof. (1) Let P (A) = (B0; I 0). If I 0 is a consistent i-interpretation, then B0 = B and
I 0 = ?P;B (I ) I ; hence, (B; I ) (B 0 ; I 0). On the other hand, if I 0 is an inconsistent iinterpretation, then B 0 is obtained from B by adding one or more blocked rule instances to B , i.e. B B 0 ; therefore, (B; I ) (B 0 ; I 0).
(2) Immediate consequence of (1) above. (3) As !P (A) is a xed-point of P , P (B0; I 0) = (B0; I 0). As the P 0 component of the pair
(P 0 ; I 0) remains unchanged upon application of the operator, it follows that I 0 = ?P;B (I 0), by de nition of the operator. Thus, I 0 is a xed-point of ?P;B . Suppose now that I 0 is not the least xed-point of ?P;B , i.e there is a J I 0 such that J is a xed-point of ?P;B . Since ?P;B is monotonic, ?P;B (J ) ?P;B (I 0). Thus, ?P (J ) is a consistent i-interpretation. Then P (B 0 ; J ) = (B 0 ; ?P;B (J )) = (B 0 ; J ); i.e. (B 0 ; J ) is a xed-point of , contradicting the fact that (B 0 ; I 0) is the least xed-point of . 0
0
0
0
0
0
0
0
0
2
We are now ready for de ning the PARK semantics. To a given set of active rules P , database instance D, and a con ict resolution policy SELECT, the result database instance PARK (P; D) is de ned as follows: PARK (P; D) = incorp(int(!P ((;; D)))): Clearly, if P is a nite rule set and if D is a nite database, then !P is computable in polynomial time in the size of D when the con ict resolution policy SELECT is implementable in polynomial time. Notice that any con ict that arises during the PARK computation does so because of two atoms of the form +A and ?A occurring in the xpoint computation procedure. For any given atom A involved in such a con ict, the sets ins and del are bounded by the size of P . Thus, the total complexity of identifying all con icts is bounded by the product of the sizes of D and P . It is now clear that when the con ict resolution policy is implementable in polynomial-time, the PARK semantics is implementable in polynomial time as well because the above iterative procedure is only executed at most size(P ) times where size(P ) is the number of rules in P { to see this recall that at each step of the iteration,. after con ict resolution, at least one rule from P is eliminated. A good example of a polynomial-time con ict resolution policy is the principle of inertia. Informally, PARK (P; D) is computed as follows: apply all rules in parallel (operator ?) and repeat this process until some con icting literals are computed. When these literals, say +a and ?a, are detected, the computation is interrupted. All blocked rule instances are collected. This means that in the course of the further computation these rule instances will not be allowed to derive any updates. The computation is then resumed with a larger set of blocked rule instances and the initial database instance (D = I ? ). We must resort to the initial database instance because some facts depending on ?a or +a may have been computed which are now obsolete. The process is repeated until the nal xed-point is reached. Again, note the similarity between in ationary xpoint and PARK in the case that no con ict occurs. The PARK semantics is illustrated by the subsequent example. The next section contains two more examples illuminating the PARK semantics for two di erent select strategies. 11
Consider a database instance D = fp(a); p(b); p(c)g together with the program P containing the rules
r1: p(x); p(y) ! +q(x; y) r2: q(x; x) ! ?q(x; x) r3: q(x; y); q(x; z); q(z; y) ! ?q(x; y) The intuition is that we want to build some irre exive graph not containing any arc implied by transitivity of existing edges. The rst application of ?P;; to D results in I1
I1 = fp(a); p(b); p(c); +q(a; a); +q(a; b); +q(a; c); +q (b; a); +q (b; b); +q (b; c); +q (c; a); +q (c; b); +q (c; c)g Since ?P;; (I1 ) = fp(a); p(b); p(c); +q (a; a); +q (a; b); +q (a; c); +q (b; a); +q (b; b); +q (b; c); +q (c; a); +q (c; b); +q (c; c); ?q(a; a); ?q(a; b); ?q(a; c); ?q(b; a); ?q(b; b); ?q(b; c); ?q(c; a); ?q(c; b); ?q(c; c)g is inconsistent, we have to follow the second case of P . We rst compute conflicts(P; I1) which is (q (a; a); f (r1; [x a; y a])g; f (r2; [x a]) (r3; [x a; y a; z a]) (r3; [x a; y a; z b]) (r3; [x a; y a; z c])g) (q (b; b); : : : ) (q (c; c); : : : ) (q (a; b); f (r1; [x a; y b])g; f (r3; [x a; y b; z a]) (r3; [x a; y b; z b]) (r3; [x a; y b; z c])g) (q (a; c); f (r1; [x a; y c])g; f (r3; [x a; y c; z a]) (r3; [x a; y c; z b]) (r3; [x a; y c; z c])g)
::: In order to get blocked(D; P; I1; SELECT), we have to x the con ict resolution strategy SELECT. We decide to block all instances of rule r1 with x = y and those connecting a and c. In all other
12
cases, the instances of r3 are blocked. (r1; (r1; (r1; (r1; (r1; (r3; (r3; (r3;
:::
This results in B := blocked(D; P; I1; SELECT) = [x a; y a]) [x b; y b]) [x c; y c]) [x a; y c]) [x c; y a]) [x a; y b; z a]) [x a; y b; z b]) [x a; y b; z c])
Then I2 := ?B;P (I1?) =
fp(a); p(b); p(c); +q(a; b); +q(b; a); +q(b; c); +q(c; b)g:
Further, (B; I2) is the nal xpoint of P and PARK (P; D) = fp(a); p(b); p(c); q(a; b); q(b; a); q(b; c); q(c; b)g: Note that we had to block the rule instances of rule r3 unnecessarily, since they can no longer be involved in any con ict. This minor disadvantage of the PARK semantics can be overcome by allowing to include only (a non-empty) part of conflicts into blocked.
4.3 Full ECA-rules Last in this section, we discuss the extensions necessary to capture full event-condition-action rules. We de ne an event as the occurrence of an update, i.e., the insertion or deletion of a literal. As before, updates for a literal l are denoted by +l or ?l. In order to allow an active rule to be triggered by an event and not just a condition, we allow update literals to occur within the rules body. In order to capture the semantics of full ECA-rules some extensions on the way to the PARK semantics are necessary. We extend the PARK semantics for the case that during the user's transaction a set U of updates, i.e. of insertions +l and deletions ?l for positive ground literals l, occurred. There exist several possibilities to capture these initial updates. One could argue that these cannot be overwritten by some rules but this unnecessarily constrains the semantics. But remembering the generality of the con ict resolution mechanism, it is easy to code the semantics where transaction updates cannot be overwritten into the con ict resolution policy. Hence, we allow a transaction's update to be overwritten. Nevertheless, some care has to be taken in case a con ict arises. There are two major points to consider: 1. In case of a con ict | witness the de nition of | we restart with I ? . This results in discarding not only con icting updates but all the transaction's updates. This clearly is not what we want. 2. Con icts may not only occur between rules but also between transaction updates and rules. This case is not covered by the de nition of con icts . 13
To solve these problems, we model the transaction updates U by a set of new rules ! a for all a 2 U . These rules then enhance the program P . More formally, we de ne for a given program P and a set of transaction updates U the modi ed program
PU := P [ faj a 2 U g: The second extension necessary concerns the de nition of validity of a literal. In order to allow an event to trigger a rule with l in its body, we must enhance the original de nition of valid for events by two cases. For an i-interpretation and a positive ground literal a, we de ne
valid(+a; I ) if and only if +a 2 I and valid(?a; I ) if and only if ?a 2 I . Now, we can state the PARK semantics for a database instance D, a program P and a set of transaction updates U :
PARK (D; P; U ) := incorp(int(!PU ((;; D)))) We illustrate the semantics for full event-condition-action rules by the following example. The database instance under consideration is D = fp(a); s(a); s(b)g and the program P consists of the rules
r1: p(x) ! +q(x) r2: q(x) ! +r(x) r3: +r(x) ! ?s(x) The transaction update is U = f+q (b)g. Then, PU becomes
r1 : r2 : r3 : r4 : and
p(x) ! +q(x) q(x) ! +r(x) +r(x) ! ?s(x) ! +q(b) I1 := ?;;PU (D) = fp(a); +q(a); +q(b); s(a); s(b)g I2 := ?;;PU (I1) = fp(a); +q(a); +q(b); +r(a); +r(b); s(a); s(b)g I3 := ?;;PU (I2) = fp(a); +q(a); +q(b); +r(a); +r(b); s(a); s(b); ?s(a); ?s(b)g
(;; I3) is the nal xpoint of PU and after incorporating the updates, we obtain
PARK (D; P; U ) = fp(a); q(a); q(b); r(a); r(b)g: 14
The preceding example does not contain any con icts. Let us consider yet another example to see how con icts are handled; for this example, we assume that the con ict resolution policy being used is the principle of inertia. Suppose D = fp(a; a); p(a; b); p(a; c)g and program P has three rules:
r1: q(x; a) ! ?p(x; a) r2: q(a; x) ! +r(a; x). r3: +r(x; y) ! +p(x; y). Suppose the transaction update is f+q (a; a)g. Then PU becomes
r1 : r2 : r3 : r4 :
q(x; a) ! ?p(x; a) q(a; x) ! +r(a; x). +r(x; a) ! +p(x; a). ! +q(a; a).
The PARK- xpoint construction procedure now works as follows:
I1 := ?;;PU (D) = fp(a; a); p(a; b); p(a; c); q(a; a)g I2 := ?;;PU (I1) = fp(a; a); p(a; b); p(a; c); q(a; a); ?p(a; a); +r(a; a)g I3 := ?;;PU (I2 ) = fp(a; a); p(a; b); p(a; c); q(a; a); ?p(a; a) + r(a; a); +p(a; a)g At this point, an inconsistency is detected involving rules r1 and r3 { so we re-start the computation with
I4 := ?fr1 ;r3 g;PU (D) = fp(a; a); p(a; b); p(a; c); q(a; a)g I5 := ?fr1 ;r3 g;PU (I4) = fp(a; a); p(a; b); p(a; c); q(a; a); +r(a; a)g: This is the nal xpoint; after incorporating the updates, we get
PARK (D; P; U ) = fp(a; a); p(a; b); p(a; c); r(a; a)g:
5 Examples of di erent con ict resolution strategies A con ict resolution strategy is a means to resolve con icts by making a choice between two sets of rule groundings | one voting for the insertion and one voting for the deletion of a ground atom. It is important to note that the con ict resolution strategy is orthogonal to the xpoint computation. This point is illuminated by the two subsequent examples where the same database instances and programs are used. The same xpoint procedure | as de ned by the PARK semantics | is applied. Nevertheless, the outcome is di erent due to the di erent con ict resolution strategies is applied. This by itself is not surprising, but the major point here is that the xpoint procedure is exible enough to capture this. 15
In order to keep the discussion simple, we restrict ourselves to the propositional case of condition-action rules. Both examples are based on the same database instance D and program P . The only di erence is the con ict resolution strategy. The database instance is D = fpg and P consists of the following rules:
r1 : r2 : r3 : r4 : r5 :
p ! +a p ! +q a ! +b a ! ?q b ! +q
The Principle of Inertia: The con ict resolution strategy in this paragraph is the already discussed principle of inertia. The rst application of ? results in (1) fp; +a; +q g which is consistent. However, the next iteration yields (2) fp; +a; +q; +b; ?q g which is inconsistent. Hence, the second case in the de nition of takes place. Since we deal with the propositional case only, we can neglect the substitutions for blocked rule instances. Instead, we can deal with rules directly. Since we apply the principle of inertia, we have
blocked(D; P; fp; +a; +q; +b; ?qg; SELECT ) = fr2g Now, the iteration starts over with B = fr2g and I ? = fpg. The next two applications of ? yield (3) fp; +ag (4) fp; +a; +b; ?q g The next step again results in an inconsistent i-interpretation: (5) fp; +a; +b; ?q; +q g The set B of blocked rule instances is supplemented by
blocked(D; P; fp; +a; +b; ?q; +qg; SELECT ) = fr5g 16
The last iterations are (6) fp; +ag (7) fp; +a; ?q; +bg. At this state the nal xpoint
< fr2; r5g; fp; +a; ?q; +bg > is reached letting fp; a; bg be the new database instance. Consider yet another example, where the principle of inertia leads to counterintuitive results. Let the database instance D be D = fag and the program P contain the following rules:
r1 : r2 : r3 : r4 : r5 :
a ! +b a ! +d b ! +c b ! ?d c ! ?b
Due to the con ict in the chain a ! +b ! +c ! ?b one would expect this chain to be withdrawn, and by the principle of inertia assume :b within the nal result. Further, any o spring of this contradictory chain should be neglected. In this case ?d should not be considered. However, this is not what happens under the principle of inertia: The rst two applications of ? result in fa; b; c; +d; ?dg. A con ict concerning d arises and, by the principle of inertia is resolved by assuring ?d since d was not present within D. The rule a ! +d is blocked. Resuming the computation the next con ict, now due to the contradictory chain shows up at fa; b; c; ?d; ?bg. The resolution is by blocking a ! b, since b 62 D. The nal result is fag and di ers from the expected | more intuitive | fa; +dg.
Rule Priority: The next con ict resolution strategy is based on rule priorities. Rule priorities
can be found in several proposals for active rules processing. Among these are the proposals for the systems Ariel [5], Postgres [9], and Starburst [10]. For our example, we assume that rule ri has priority i. Within the sets ins and del of the set of con icts , the set containing the rule with the highest priority is chosen by SELECT. As above, the rst two applications of ? result in (1) fp; +a; +q g (2) fp; +a; +q; +b; ?q g
Since +q is derived by a rule with priority 2 and ?q by a rule with priority 4, 17
blocked(D; P; fp; +a; +q; +b; ?qg; SELECT ) = fr2g We proceed as above with (3) fp; +ag (4) fp; +a; +b; ?q g (5) fp; +a; +b; ?q; +q g Since ?q has been derived by a rule with priority 4 and +q has been derived by a rule with priority 5, we enhance the set of blocked rule instances B by
blocked(D; P; fp; +a; +b; ?q; +qg; SELECT ) = fr4g The computation resumes at I ? and subsequent applications of ? yield (6) fp; +ag (7) fp; +a; +bg (8) fp; +a; +b; +q g. resulting in the nal database instance fp; a; b; q g. In addition to the above con ict resolution strategies, it is possible to develop several others as well { we brie y describe four more strategies below { due to space restrictions, we are unable to give a comprehensive description in this paper.
Speci city-based Con ict Resolution: An old AI principle says that more \speci c" rules
(i.e., rules dealing with a more speci c subset of facts) should be given priority over more general rules. For example bird(X ) ! +flies(X ) is more general than penguin(X ) ! ?flies(X ), hence in the case of a penguin, even though both rules apply, the second should be preferred. This principle is not a complete con ict resolution strategy, since there may exist con icting rules of equal or of incomparable speci city, but this principle may be combined with other con ict resolution strategies.
Interactive Con ict Resolution: In this scheme, as soon as a con ict is found, the user is queried and may resolve the con ict by choosing one among the con icting rules. Voting Scheme: In this scheme, it is assumed that a set of critics are available to the system.
A critic is a program that takes as input, a con ict (as de ned earlier), and returns the value insert or delete. When a con ict occurs, the PARK semantics invokes the set of critics and asks each of them for \its vote". The majority opinion of the critics is then adopted to resolve the con ict. An interesting aspect of critics is that each critic may use a di erent intuition in order to resolve a con ict. For instance, one critic may use background information it possesses on when various tuples were placed in the database (e.g. later information may be preferred by this critic). Another critic may use source-based approach (it may know that the two rules 18
that are involved in the con ict came from two di erent sources, and that one of these sources is \more reliable" than the other). The Interactive con ict resolution scheme above is a special case of the voting scheme where there is one critic { viz. the human user.
Random Con ict-Resolution: In some cases it may be convenient that the system just randomly chooses one from the con icting rules in order to resolve the con ict. Which of the above strategies is picked for a particular application depends critically upon the declarative needs of the application as well as eciency concerns.
Declarative Needs: For instance, in banking applications, the principle of inertia may be
used by the system, delaying a transaction, until the human banker can be queried. In many cases where the preconditions of rules de ne classes and a clear object-class hierarchy exists, then the principle of speci city may be used. The voting scheme can be used when good critics are available for the application at hand. In databases that monitor critical systems (e.g. power plants, machine tools, etc.), the interactive con ict resolution scheme is perhaps the most appropriate strategy. Furthermore, in many applications, humans may prefer to adopt this strategy anyway.
Eciency Needs: From the point of eciency, the principles of inertia, rule priority, inter-
active con ict resolution and random con ict resolution are all easy to implement and can be viewed as constant time operations (i.e., operations that require a constant number of database accesses). In contrast, the principle of speci city may be more intensive computationally, in particular, if speci city of rules is not determined a-priori, but is determined on the y by computing and comparing the sets of ground factsd to which the rules apply. (There may be, however completely di erent and much simpler ways of de ning and determining rule speci city). Lastly, the voting scheme's computational properties are constant-time modulo the complexity of the critics themselves. If the critics take large amounts of time for their processing, then this scheme could be time-consuming.
6 Conclusion Over the last few years, there has been extensive work on active database systems { [2] provides a nice summary of this work. However, most of the formal treatments of active databases have been ad-hoc, and have failed to satisfy at least one of the following criteria that we consider critical to active databases { either they result in an update generate a multiplicity of database states, or they take non-polynomial (exponential) time to compute, or they are unable to resolve con icts. In this paper, we rst outlined the requirements for a semantics of active rule systems. Subsequently, we de ned the PARK semantics for active rules { this semantics satis es the 19
previously articulated criteria. The PARK semantics can be seen as a smooth integration of in ationary xpoint semantics [6] and con ict resolution. It ful lls all our requirements including the treatment of recursive rules.
References [1] A. Buchmann. Active object systems. In A. Dogac, M. Ozsu, A. Biliris, and T. Sellis, editors, Advances in Object-Oriented Database Systems, pages 201{224, 1994. [2] U. Dayal, E. Hanson, and J. Widom. Active database systems. In W. Kim, editor, Modern Database Systems, pages 434{456. Addison Wesley, 1995. [3] P. Fraternelli and L. Tanca. A toolkit for the design of active database semantics. Rapporto Interno 93-078, Politecnico di Milano, Milano, Italy, 1993. [4] A. Van Gelder, K. Ross, and J. S. Schlipf. The well-founded semantics for general logic programs. Journal of the ACM, 38(3):620{650, July 1991. [5] E. Hanson. Rule condition testing and action execution in ariel. In Proc. of the ACM SIGMOD Conf. on Management of Data, pages 49{58, San Diego, CA, Jun. 1992. [6] P. Kolaitis and C. Papadimitriou. Why not negation by xpoint? Journal of Computer and System Sciences, 43:125{144, 1991. [7] A.M. Kotz. Trigger Mechanisms for Maintaining Design Data Consistency in Database Systems. PhD thesis, Univ. of Karlsruhe, 1988. [8] W. Marek and M. Truszczynski. Revision Programming, Database Updates, and Integrity Constraints. In Int. Conf. on Database Theory, pages 368{382, Prague, Jan. 1995. Springer. [9] M. Stonebraker, A. Jhingran, J. Goh, and S. Potamianos. On rules, procedures, caching and views in data base systems. In Proc. ACM SIGMOD Int. Conf. on Management of Data, pages 281{290, 1990. [10] J. Widom and S. Finkelstein. Set-oriented production rules in relational databases. In Proc. of the ACM SIGMOD Conf. on Management of Data, pages 259{270, 1990. [11] C. Zaniolo. On the uni cation of active databases and deductive databases. In Rules in Database Systems, (N. Paton, ed.), Springer Verlag, 1994.
20
