Optimization and Serializability of Update Transactions in ... - CiteSeerX

Optimization and Serializability of Update Transactions in Marked Databases D. Laurent*, N. Spyratos*, G. Vossen2



LIFO Universite d'Orleans BP 6759 - Orleans Cedex 2 FRANCE F-45067 email: [email protected]

* LRI, U.R.A. 410 du CNRS B^at. 490 - Universite de Paris-Sud Orsay Cedex FRANCE F-91405 email: [email protected]

2

Institut fur Wirtschaftsinformatik Universitat Munster, Grevenerstrasse 91 D-48159 Munster, GERMANY email: [email protected]

Abstract

Marked databases are a generalization of relational databases in which there are no xed schemas, and in which tuples are never deleted, but eventually marked as invalid. The study of marked databases has recently gained considerable interest, since they allow elegant solutions to various problems arising in conventional relational databases. In this paper update transactions operating on marked databases are investigated. The rst focus of this study is on transaction optimization and equivalence; the second is on correctness criteria for corresponding schedules which describe the concurrent execution of multiple transactions. In particular, a sequence of increasingly weaker notions of correctness is presented, which exhibits interesting and novel properties of a variety of classes of schedules on marked databases. These notions range from state-based serializability, which here can be decided in polynomial time even in the absence of syntactic restrictions (like con ict relations), to the recently proposed goal-correctness. The results provide further evidence that marked databases are a valuable generalization of relational databases.

1 Introduction Marked databases are a generalization of relational databases which have gained considerable interest recently, for example in the context of updating through a universal schema interface [LPS92, LaS94] or of deductive databases [LPS93c, HLS95]. Moreover, they allow for transactional schemas in the sense of [AbV85, AbV89] as a dynamic way to specify databases [LPS93b]. In this paper we investigate update transactions operating on marked databases, rst with respect to issues of transaction optimization and equivalence, and then with respect to concurrency control. We present a general notion of (state-based) serializability for schedules comprising concurrent transactions, which in this database model turns out to have a polynomial-time decision problem. We also discuss weaker notions of correctness for schedules, con ict-based serializability and goal-correctness, and study their relationship to state-serializability. A marked database is an ordinary relational database in which the schema is not xed, i.e., the database is a set of tuples in which we can insert or delete any tuple that we wish, and the deletion of a tuple does not remove it physically from the database, but simply marks it as being deleted. The study of transactions in the context of marked databases was recently begun in [LPS93b], where several results on transaction speci cation and optimization were obtained. In particular, it could be shown that the approach of [AbV85, AbV89] to dynamic database speci cation can be generalized to marked databases. In this approach, a database schema is speci ed by providing a set of relation schemas together with a nite set of parametrized transactions. The result, transactional schemas, are a valuable alternative to traditional static speci cations (in which a database schema is speci ed by providing a set of relation schemas together with a set of integrity constraints), since they can make integrity checking obsolete. Indeed, using a transactional schema a user can only employ transactions which maintain all required integrity constraints \automatically." In this paper, we investigate transaction optimization and equivalence for marked databases, in order to pave the way for a corresponding theory of concurrency control. This is motivated by the fact that taking semantic information into account when processing concurrent database transactions has proven useful in a variety of contexts. For example, it has been shown in [ViV92] that update transactions on relational databases allow for eciently testable notions of serializability which go beyond a purely syntactic consideration of con icts between pairs of elementary operations. In addition, in [ViV93] a new notion of correctness for schedules of update transactions was proposed which is orthogonal to classical serializability, and which seems more appropriate than serializability in contexts where semantic information is available and tractable. The approach to transactions described in this paper is based on the perception that from a user's point of view, a transaction is a sequence of insertions and deletions of tuples, and these insertions and deletions are translated by the system into a sequence of add's and remove's that operate on the sets ut and mt of unmarked tuples and marked tuples of a marked database, respectively. Moreover, optimization techniques concern sequences of updates issued by users, whereas in the translation into add's and remove's, we are concerned with serializability. In other words, transactions are optimized one by 1

one, before they are sent to the scheduler. Then, these transactions are translated into low-level transactions that are interleaved by the scheduler. By doing so, we put a clear frontier between two distinct problems (namely, transaction optimization and serializability); furthermore, we will be able to obtain ecient algorithms for transaction execution. Our study of serializability of schedules on marked databases additionally reveals interesting and novel properties. For example, state-based serializability has a polynomialtime decision problem, basically due to the fact that the semantic information on transactions which is available in a marked database can be exploited appropriately. Also, goal-correctness, so far known to be orthogonal to any notion of serializability, turns out to be weaker than the latter for marked databases. As a result, marked databases provide a framework in which a notion of correctness for schedules can be adopted which needs no syntactic restrictions. The paper is organized as follows. In Section 2, we review the model of marked databases and their update semantics, both at an informal and at a formal level. In Section 3, we introduce update sequences, present our main results concerning their optimization and equivalence, and describe the transaction language used in the remainder of this paper. In Section 4, we turn to concurrency control issues, and in particular look at correctness of transaction schedules; we characterize nal-state serializability in our context, and study the restricted correctness criterion of con ict-serializability as well as that of goal-correctness. In Section 5, we consider the eect of functional dependencies. Finally, in Section 6, we oer some concluding remarks and suggestions for further research.

2 Marked Databases In this section, we review the model of marked databases for the sake of completeness; more details can be found, for example, in [LPS92, LaS93, LPS93a].

2.1 Informal Discussion

As was mentioned in the Introduction, a marked database is a relational database in which the schema is not xed, i.e., the database is a set of tuples in which we can insert or delete any tuple that we wish, and the deletion of a tuple does not remove it physically from the database but simply marks it as being deleted. If we wish to delete a tuple t from a marked database, we proceed as follows: if t is present in the database then we mark it else we place it in the database and mark it. As a consequence, at any given moment a marked database consists of two parts: the set of all unmarked tuples, denoted ut (for \unmarked tuples"), and the set of all marked tuples, denoted mt (for \marked tuples"). Example 1. Let U = fA; B; C g be a relational universe, and let F = fA ! C; B ! C g be a set of functional dependencies over U: Consider a marked database de ned by ut = fab; bcg and mt = ;: 2

If we insert the tuple ac0 , we simply place it in the set ut; which results in the following database: ut = fab; bc; ac0 g and mt = ;: If the tuple ac is deleted next, we place this tuple in the set mt; and the updated database becomes: ut = fab; bc; ac0 g

and

mt = facg:

Similarly, if we wish to delete bc0 , we place it in mt; and end up with ut = fab; bc; ac0 g and mt = fac; bc0g:

2

Intuitively, when we insert a tuple in a database we consider it as true, and when we delete a tuple we consider it to be false. It turns out that the semantics of a marked database is related to the weak-instance model [AtT89, MUV84], in the following sense: In the weak-instance model of relational databases, there are two ways to declare that a tuple is true: either explicitly, by placing the tuple physically in the database, or implicitly, by ensuring the derivation of the tuple from other true tuples, through inference rules. Two such inference rules are available for the derivation of true tuples: restriction rule: if t is a subtuple of a true tuple then t is true, join rule: if t is the join of two true tuples ly and la; and if the functional dependency L ! A is in F; then t is true. However, under the weak-instance model, there is no way to declare that a tuple is false. Indeed, there are simply \assumptions" on the status of non-true tuples, such as the closed world assumption [Rei84], which states that if a tuple is not true then it is false. Marked databases try to overcome this de ciency of the weak-instance model by allowing to declare that a tuple is false in exactly the same ways in which we declare that a tuple is true. That is, in a marked database, there are two ways to declare that a tuple is false: either explicitly, by placing the tuple physically in the database and by marking it (as being false), or implicitly, by ensuring the derivation of the tuple from other false tuples, through inference rules. For the purposes of this paper, we shall restrict our attention to only one such inference rule for the derivation of false tuples: extension rule: if t is a supertuple of a false tuple then t is false. We note that the extension rule is the counterpart of the restriction rule seen earlier, and that there is also a counterpart of the join rule seen above, a decomposition rule [LaS88], which will not be considered here. It is easily seen that considering inserted tuples as true, and deleted ones as false may lead to inconsistencies. For example, if we insert abc and then delete ac; we end up regarding abc as both true and false. Indeed, by inserting abc we render abc true and by deleting ac we render ac false; if we now apply the extension rule to ac then we nd that abc is false. We can avoid such inconsistencies if we proceed as follows: We accept every 3

derivation of true tuples (using the restriction and join rules) except if the derivation produces a false tuple. In other words, deleted tuples (and their supertuples) act as explicit exceptions during the derivation of true tuples. Now, in a marked database, if there is no tuple which is both true and false, and if the true tuples satisfy the functional dependencies, then the marked database is called consistent. It has been shown in [LPS92] that marked databases provide a framework in which every insertion or deletion of a tuple can be done in a deterministic way. Thus, marked databases avoid the problems of non-deterministic updating in traditional approaches [Abi88, AtT92, BDM88, LaS94, LeS88, Win88].

Example 1. (continued) Consider the marked database de ned earlier: ut = fab; bc; ac0 g and mt = fac; bc0 g: The tuples ac and bc0 are false (as they are in mt) and so is every supertuple of ac (according to the extension rule). On the other hand, the tuples ab; bc and ac0 are true (as they are in ut) and so are their subtuples a; b; c and c0 (according to the restriction rule). However, although ab; bc and B ! C derive the tuple abc (using the join rule), this derivation is not accepted because abc is false (being a supertuple of ac). Similarly, although ab; ac0 and A ! C derive the tuple abc0 (using the join rule), this derivation is not accepted because abc0 is false (being a supertuple of bc0 ). So, we have: true tuples: ab; bc; ac0 ; a; b; c; c0 false tuples: ac; bc0 and all their supertuples. As no tuple is both true and false and as the true tuples satisfy the given dependencies A ! C and B ! C; we conclude that the marked database is consistent. 2 Clearly, in a marked database (ut; mt); if mt = ; then the database is consistent i ut is consistent in the sense of the weak-instance model, i.e., if the chase applied to ut succeeds. It follows that every relational database  which is consistent under the weak-instance semantics can be associated with the consistent marked database de ned by ut =  and mt = ;: However, it can be shown that there exist consistent marked databases (ut; mt) s.t. ut is not consistent under weak-instance semantics. Let U be a relational universe and let F be a set of functional dependencies over U: For every relational database  over U and F; de ne the marked database (; ;); i.e., the marked database with ut =  and mt = ;: Let satm (F ) = f(; ;) j  2 sat(F )g and let us denote by cons(F ) the set of all marked databases over U that are consistent. In view of our earlier discussions, we have that: satm (F )  cons(F ); for every relational universe U and for every set F of functional dependencies over U; and this inclusion can be strict. As a consequence, the expressive power of marked databases is strictly larger than that of relational databases.

2.2 The Formal Model

We now give the formal de nitions concerning marked databases, their semantics and their update semantics, based on the formalism introduced in [LPS93a]. 4

First, we recall brie y some basic de nitions from the relational model, slightly recast for the purposes of this paper. Let U = fA1; : : : ; Ang be a nite universe of attributes. Each attribute Ai is associated with a set of values called the domain of Ai and denoted by dom(Ai). A non-empty subset of U is called a relation scheme and is denoted by the juxtaposition of its attributes (in some order). A tuple r over a relation scheme R is a function de ned on R such that r(Ai) is in dom(Ai), for all Ai in R. We denote by dom(R) the set of all tuples over R. If r is a tuple over R = A1 : : : Am , and if r(Aj ) = aj , j = 1; : : : ; m, then we denote the tuple r as a1 : : : am and we write sch(r) = R to mean that the schema of r is R: Furthermore, if S = Ai1 Ai2 : : : Aik is a subset of R, we denote the restriction of r to S as r:S : That is, sch(r:S ) = S and r:S = ai1 ai2 : : : aik where, for every j = 1; 2; : : : k, aij = r(Aij ). Such a restriction of r is also called a subtuple of r; and r is called a supertuple of this restriction. Let  be a set of tuples, and let X and Y be two relation schemes. We say that  satis es the functional dependency (FD) X ! Y if for all tuples q and q0 in  s.t. XY  sch(q) and XY  sch(q0); q:X = q0:X implies q:Y = q0:Y (following common practice, XY denotes the union of X and Y ). Without loss of generality [Mai83, Ull89], we only consider dependencies of the form L ! A where L is a set of attributes and A is a single attribute not in L. Finally, given a set F of FDs, a set  of tuples satis es F if  satis es every FD in F: In the remainder of this paper, we consider a xed relational universe, denoted by U; together with a xed set of functional dependencies, denoted by F: We now de ne formally what we call a marked database. De nition 1. Given a relational universe U and a set F of FDs over U; a marked database is a pair
= (ut; mt) where ut and mt are sets of tuples such that ut contains no supertuples of tuples in mt: 2 For instance, the marked database of our running Example 1 satis es this de nition, since ut = fab; bc; ac0 g contains no supertuples of tuples in mt = fac; bc0g: Given a marked database
= (ut; mt) we de ne its semantics, i.e., the set of tuples derived by
, by means of the following two operators (see also [LPS93a]): 1. The exception operator, denoted by  and de ned by


= fq j 9r 2  : sch(r)  sch(q) ^ q:sch(r) = rg; where  is a set of tuples. 2. The positive operator, denoted by  and de ned by () = fq j 9r 2  : sch(q)  sch(r) ^ r:sch(q) = qg [ fq j 9L ! A 2 F : LA  sch(q) ^ q:LA 2  ^ q:(sch(q) n fAg) 2 g where  is a set of tuples. Roughly speaking,  computes the set of all supertuples of marked tuples. These in turn act as exceptions in the derivation process de ned through the operator : We note that 5

the de nition of  re ects the restriction and join rules seen earlier: A tuple q is in () if q is a subtuple of a tuple in  or if  contains two tuples ly and la (over LY and LA; respectively) such that L ! A is a dependency in F and q = lya: Now, we associate the marked database
with an operator  that takes a set of tuples  as argument and returns the set of tuples 
() = () n 
: It has been shown in [LPS93a] that, given a marked database
= (ut; mt); the sequence of sets of tuples de ned by: 0 (ut) = ut and  i (ut) = mt ( i?1 (ut)); for i > 0 mt mt mt has a limit. This limit is the least xpoint of  with respect to
; and is denoted by 
: Thus, we note that 
and 
are respectively the true and false tuples that can be derived from
: Therefore, we de ne the semantics of a marked database
to be the pair (
; 
): De nition 2. Given a marked database
= (ut; mt); the semantics of
; denoted by (
); is the pair (
; 
): 2 Moreover, it can be easily seen that, since we assume that ut contains no supertuples of tuples in mt; we have ut \  (mt) = ;: Following [LPS93a], this entails that ut  
; meaning that every inserted tuple is true in
: On the other hand, as mt  
; every deleted tuple is false in
:

Example 1. (continued) We recall that we consider a relational universe U = fA; B; C g; a set of functional dependencies F = fA ! C; B ! C g and a marked database
= (ut; mt) de ned by:

ut = fab; bc; ac0 g

and

mt = fac; bc0 g

We now compute the semantics of
: First, it is clear that  (mt) is the set containing all supertuples of ac and all supertuples of bc0 : Now, the set 
is computed as follows: Step 0:  0(ut) = fab; bc; ac0 g:

Step 1: We have (ut) = ut [ fa; b; c; c0 ; abc; abc0 g: Indeed a; b; c; c0 are obtained through the restriction rule applied to the tuples in ut: The tuples abc and abc0 are obtained by the join rule as follows: ab; bc and B ! C derive the tuple abc and ab; ac0 and A ! C derive the tuple abc0 : However, the tuples abc and abc0 are in  (mt) and so, we obtain

1 (ut) = fab; bc; ac0 ; a; b; c; c0g: Step 2: We have (fab; bc; ac0 ; a; b; c; c0 g) = (ut): Indeed, the restriction rule applied to the tuples in fab; bc; ac0 ; a; b; c; c0g generates no new tuples and the join rule applies as above. Thus, we obtain 2 (ut) = 1(ut); which terminates the computation.

6

Therefore, the semantics (
) of
is de ned by: ( 
= fab; bc; ac0 ; a; b; c; c0g 
= fq j q is a supertuple of ac or of bc0g: We note that 
satis es F:

2

We next de ne the consistency of a marked database as follows: De nition 3. A marked database
is consistent (w.r.t. F ) if 
satis es the dependencies in F: 2 Clearly, the marked database
of Example 1 above is consistent in the sense of De nition 3. Traditional relational databases can be regarded as marked databases of the form
 = (; ;), i.e., with no marked tuples. As has been shown in [LPS93b], such a database
 is consistent i  is consistent under the weak-instance semantics. It follows that the model of marked databases strictly subsumes the relational model of databases under weak-instance semantics. We de ne the insertion and deletion of a tuple in a marked database as follows: De nition 4. Let
= (ut; mt) be a consistent database and let t be a tuple. The insertion of t in
; denoted by ins(t;
); is de ned to be the marked database (ut0; mt0) such that:

 ut0 = ut [ ftg , and  mt0 = mt n fq j sch(q)  sch(t) ^ t:sch(q) = qg; if (ut0; mt0 ) is consistent, and it is unde ned otherwise. The deletion of t in
; denoted by del(t;
); is de ned to be the marked database (ut0; mt0) such that:

 ut0 = ut n fq j sch(t)  sch(q) ^ q:sch(t) = tg  mt0 = mt [ ftg: 2 Roughly speaking, in order to insert t in
we rst do the following: 1. we add t in ut; and 2. we remove from mt all subtuples of t: If the resulting database is consistent then the insertion is accepted, else the insertion is rejected. In order to delete t from
we do the following: 1. we remove from ut all supertuples of t; and 2. we add t in mt: 7

Unlike for insertions, no further test is required in the case of a deletion, as the resulting marked database is always consistent.

Example 1. (continued) We recall that we consider a relational universe U = fA; B; C g; a set of functional dependencies F = fA ! C; B ! C g and a marked database de ned by:

ut = fab; bc; ac0 g

and

mt = fac; bc0 g

We rst note that the insertion of abc0 would be rejected, since it would allow to derive the tuples bc0 and bc: Deletion of bc produces the marked database de ned by: ut0 = fab; ac0 g

mt0 = fac; bc0 ; bcg:

and

If we insert now abc0 we obtain: ut00 = fab; ac0 ; abc0 g

and

mt00 = fac; bcg:

We note that this insertion is accepted and the semantics of the resulting database is the set fab; ac0 ; abc0; bc0 ; a; b; c0g: 2 In view of De nition 4 and our examples, we note that, during updating, 1. The sets ut and mt are modi ed in such a way that ut never contains supertuples of tuples in mt (thus complying with De nition 1). 2. The insertion of a tuple may be rejected (because the presence of a new tuple in ut may lead to contradictions with respect to some FD in F ). If the insertion is accepted, then the inserted tuple appears as true in the semantics of the updated database. 3. The deletion of a tuple is always accepted as a deletion never introduces new tuples in ut: Moreover, the deleted tuple appears as false in the semantics of the updated database. These remarks show that, starting with a consistent marked database and a tuple t; the functions ins and del always compute a consistent marked database. Moreover, if not rejected, the update is performed correctly, since the inserted [deleted] tuple is derivable [not derivable] from the updated database, resp.

3 Update Sequences and Transactions 3.1 Introduction

In this section, we rst generalize single insertions or deletions on marked databases into so-called update sequences. As we mentioned in the Introduction, our perception is that update sequences are what a user issues to a marked database, and these will rst 8

abstraction level user: ins(ert), del(ete)

#

system: add, remove

subject issue update sequence, optimization applied to database transaction, correctness of applied to (ut; mt) translation, execution

Figure 1: User- vs. system-view of updates on marked databases. undergo optimization. Once optimized, update sequences are translated into transactions, which are to be executed by the system; this view of the situation is illustrated in Figure 1. The translation transforms each ins or del operation into a sequence of add and remove operations s.t. the latter describes, at the level of individual tuples, how the user-intended changes to the given database are made. The advantage of the approach can be seen in the fact that it allows to consider distinct issues related to updating marked databases separately. Indeed, optimization is done independent of the underlying database state; this is in line with common approaches to query optimization, in which high-level rewriting is done before a given query is transformed into an execution plan. On the other hand, the decision of whether a schedule for a given set of transactions is correct is only made when the schedule is about to be executed. Also, our two-level approach is similar in spirit to multi-level transactions, which consider the issues related to distinct abstraction layers separately [Wei91]. In the remainder of this section, we rst de ne, based on an equivalence relation between databases, when two update sequences are equivalent; after that we show that each update sequence has an equivalent optimized one. Optimized sequences will then be translated into transactions in a canonical way, which simply replaces each operation in a given sequence by corresponding add and remove operations.

3.2 Update Sequences

We now de ne what we call an update sequence, and what we mean by the eect of such a sequence on a given database. De nition 5. (i) An update sequence is a sequence

S = (u1; r1); (u2; r2); : : : ; (un; rn) of pairs s.t. for all i = 1; 2; : : : ; n, ui stands for ins or del and ri is a tuple. (ii) Let
be a database over U . The eect of an update sequence S on
, denoted S (
), is the composition of the eects of the updates in S: 2 Our perception of an update sequence is that it gets speci ed by a user; however, a user may put updates in a sequence which do not have an eect on the given database, 9

or which might even be contradictory. Update sequences are to be evaluated updateby-update, where in each step an update without eect is ignored. In order to state our results on update sequence optimization, we rst need the following: De nition 6. Two databases
and
0 are equivalent, denoted

0; if
and
0 are consistent and have the same semantics, i.e., 
= 
and 
= 
: 2 As an example, databases
= (fab; abcg; ;) and
0 = (fabcg; ;) are equivalent, since whatever the FDs are, we have: ( 
= 
= fa; b; c; ab; ac; bc; abcg 
= 
= ;: 0

0

0

0

It is important to note that equivalence as de ned above is restricted to consistent databases. In other words, we do not consider here that two inconsistent databases might be equivalent. Now we are ready to de ne equivalence between update sequences; intuitively, two sequences S1 and S2 are equivalent if they have equivalent eects on every marked database, provided that they both leave the database consistent. This is formalized as follows. De nition 7. Two update sequences S1 and S2 are equivalent, denoted S1  S2; if, for every consistent marked database
; such that S1(
) and S2(
) are de ned, then S1(
)  S2 (
): 2 For example, the update sequences S1 = (ins; ab); (ins; abc) and S2 = (ins; abc) are equivalent; notice that S1 and S2 do not have the same eect, but only have \equivalent" eects. We mention that requiring equivalent update sequences to have identical eects would be an unnecessary restriction, resulting in less potential for optimization, as will be discussed next.

3.3 Optimization of Update Sequences

We now turn to the issue of optimizing update sequences: we show that, for every update sequence S; there exists a subsequence S0 of S such that S0 is equivalent to S; and S0 contains less updates than S: The construction of S0 from S requires some straightforward properties of update sequences which are summarized below; notice that some of these are commutativity rules, while others are simpli cation rules, and they are similar in spirit to commutativity and simpli cation rules stated in [AbV88, KaV91] for relational update transactions. Proposition 1. Let t1 and t2 be two tuples. 1. (ins; t1 ); (ins; t2)  (ins; t2 ); (ins; t1): 2. If t2 is a subtuple of t1 then (ins; t1); (ins; t2 )  (ins; t1): 3. (del; t1); (del; t2)  (del; t2 ); (del; t1): 4. If t2 is a supertuple of t1 then (del; t1); (del; t2)  (del; t1): 10

5. If t1 is not a supertuple of t2; then (ins; t1 ); (del; t2)  (del; t2); (ins; t1 ): 6. If t1 is not a subtuple of t2; then (del; t1 ); (ins; t2)  (ins; t2 ); (del; t1): 2 Proof: First, consider cases 1, 3, 5 and 6. In each of these cases, it can be seen from De nition 4 that both sequences applied to a given database produce the same databases. Therefore, the sequences are equivalent. Next consider case 2. Starting from a given database
= (ut; mt); assume that (ins; t1); (ins; t2 ) and (ins; t1 ) produce databases
1 = (ut1 ; mt1) and
2 = (ut2 ; mt2); resp. If both of these databases are de ned, we have: ut1 = ut [ ft1 ; t2 g mt1 = mt n fq j q is a subtuple of t1 or of t2 g ut2 = ut [ ft1 g mt2 = mt n fq j q is a subtuple of t1 g Since t2 is a subtuple of t1 ; mt1 = mt2; entailing that 
1 = 
2 : Moreover, as t2 can be derived from ut2 by projection of t1 ; we also have 
1 = 
2 : Therefore,
1 
2: Considering case 4, we use the same notations as above. That is, given a database
= (ut; mt); assume that (del; t1 ); (del; t2) and (del; t1) produce databases
1 = (ut1; mt1) and
2 = (ut2 ; mt2); resp. Note that both of these databases are de ned (since the update sequences contain no insertions). We have: ut1 = ut n fq j q is a supertuple of t1 or of t2 g mt1 = mt [ ft1 ; t2 g ut2 = ut n fq j q is a supertuple of t1 g mt2 = mt [ ft1 g Since t2 is a supertuple of t1; we have ut1 = ut2 and, moreover, it is clear that 
1 = 
2:: Thus,
1 
2 : Now given an update sequence S; the above properties can be used to compute a simpli ed sequence S0 which is equivalent to S: To do so, we introduce the following notations: For every update sequence S; ins(S ) is the set of tuples t such that (ins; t) occurs in S and del(S ) is the set of tuples t such that (del; t) occurs in S: We rst note that, based on Proposition 1, for a given update sequence S; there exists an update sequence Simp(S ) with the following properties: 1. Simp(S )  S: 2. ins(Simp(S ))  ins(S ) and del(Simp(S ))  del(S ): Indeed, given an update sequence S; we can apply the commutativity rules 1, 3, 5, 6 from Proposition 1, in order to transform S in such a way that the simpli cation rules 2 and 4 from Proposition 1 can be applied. This can be summarized as follows, in the case of an insertion: for (ins; t) in S , look for every (ins; t0) in S s.t. t0 is a subtuple of t: For each such t0; if there is no (del; t00 ) in S between (ins; t) and (ins; t0 ) s.t. t00 is a subtuple of t or of t0 ; then by applying the commutativity rules, (ins; t) and (ins; t0 ) can be brought together in S . Finally, with the simpli cation rule 2, (ins; t0) can be removed from S: We note that the case of a deletion is similar. However, some important remarks are in order with respect to this way of simplifying update sequences. Remark 1. The simpli cations performed against a given sequence S according to Proposition 1 are not always optimal, in other words, there may exist a subsequence of Simp(S ); say S 0; such that S 0  Simp(S ): 11

For example, if S1 = (ins; ab); (del; a); (del; b) then Simp(S1) = S1 : However, let 1 = (del; a); (del; b); and let
= (ut; mt) be a consistent marked database for which the insertion of ab is de ned. Then, S1 (
) = (ut0; mt0 ) is de ned by: ut0 = ut n fq j q is a supertuple of a or of bg mt0 = mt [ fa; bg: Moreover, it is easily seen that S10 (
) is de ned and is equal to S1(
): Thus we have S1  S10 : This example suggests that the insertion of ab is \cancelled" by the deletions of a and b: On the other hand, it should be noticed that the only deletion of a is not equivalent to S1; that is, if S100 denotes the sequence (del; a); it is not the case that S1 and S100 are equivalent. Indeed, if
= (ut; mt) is de ned by ut = ; and mt = fbg; 0 then S1(
) = (ut ; mt0) and S100 (
) = (ut00; mt00 ) are respectively de ned by: ut0 = ; and mt0 = fag 00 ut = ; and mt00 = fb; ag It is easy to see that S1(
) and S100(
) are not equivalent, which shows that S1 and S100 are not equivalent either. Thus, cancelling an insertion through deletions is not always possible under equivalence of update sequences. Remark 2. Similarly, we now show that cancelling a deletion through insertions is not always possible under equivalence of update sequences. For that, we consider the update sequence S2 = (del; ab); (ins; abc): Although S2 cannot be simpli ed according to Proposition 1 (we have Simp(S2) = S2 ); one would expect that the insertion of abc \cancels" the deletion of ab: In other words, one would expect that S2 is equivalent to S20 = (ins; abc); as in [AbV88, KaV91]. Following is a counter-example, showing that this property does not hold in our approach. Let
= (ut; mt) be de ned over the universe fA; B; C; Dg by ut = fabdg and by mt = facg: Then S2 (
) = (ut2 ; mt2 ) and S20 (
) = (ut02 ; mt02 ) are de ned by: ut2 = fabcg and mt2 = ; ut02 = fabd; abcg and mt02 = ; Clearly, S2(
) and S20 (
) are not equivalent. Note moreover, that, applied to the empty database, the update sequences S1 and S2 above produce the same database. The two remarks above motivate why we introduce the notion of weakly equivalent update sequences. In the following de nition, the empty database (;; ;) is denoted by
;: Intuitively speaking, two weakly equivalent update sequences are sequences that \contain" the same information. De nition 8. Two update sequences S1 and S2 are weakly equivalent, denoted S1 w S2; if S1 (
;) and S2 (
; ) are de ned and S1 (
;)  S2 (
;): 2

S0

Clearly, two equivalent update sequences are weakly equivalent, whereas the converse is false, as shown in the above two remarks. As a consequence, optimizing update sequences under weak equivalence can be done using Proposition 1. Moreover, as shown 12

by the following proposition, weak equivalence allows for those additional simpli cation rules that have been dealt with in the above two remarks: the insertion (resp. deletion) of t is cancelled by any subsequent deletion (resp. insertion) of a subtuple (resp. supertuple) of t: Proposition 2. Let t1 and t2 be two tuples. 1. If t1 is a supertuple of t2 then (ins; t1); (del; t2 ) w (del; t2): 2. If t1 is a subtuple of t2 then (del; t1); (ins; t2 ) w (ins; t2 ): 2 Proof: It is easily seen that in case 1 as well as in case 2, both sequences applied to the empty database produce the same database.

According to Proposition 2 above, we have that, for every tuple t; (ins; t); (del; t) w (del; t) and (del; t); (ins; t) w (ins; t): Thus, (ins; t); (del; t) and (del; t); (ins; t) are not weakly equivalent, and thus these update sequences are not weakly equivalent to the empty sequence either. The following algorithm allows for simpli cations of update sequences under weak equivalence. Algorithm WSIMP Input: an update sequence S Output: an update sequence Simpw (S ) (s.t. S w Simpw (S ), see below) Method: begin while S changes do Let i be the smallest integer such that there exists j; i < j and (ui; ti) = (del; ti) and (uj ; tj ) = (ins; tj ) are in S and ti is a subtuple of tj , or (ui; ti) = ins(ti) and (uj ; tj ) = (del; tj ) are in S and ti is a supertuple of tj if i and j as above exist then remove (ui; ti) from S end-while ; remove from S every (ins; ti ) such that ins(S ) contains a strict supertuple of ti ; remove from S every (del; ti ) such that del(S ) contains a strict subtuple of ti ; Simpw (S ) := S end. The following theorem shows that algorithm WSIMP is correct for weak equivalence. Moreover, when no FDs are considered, these simpli cations are optimal. Theorem 1. 1. Given an update sequence S; S w Simpw (S ): 2. If no FDs are present, then, for every subsequence S 0 of Simpw (S ); S 0 6w S: 2 Proof: 1. We rst show that every update (ui ; ti ) removed from S in the while loop does not appear in S (
; ): For this, we denote by
1 = (ut1; mt1 ); : : : ;
n = (utn; mtn) the sequence of databases obtained by performing successively the n updates in S; starting from the empty database
; : Let us consider i and j as in the algorithm above, in the case where ui = del and uj = ins: In this case, there is no subtuple of ti in uti?1 : Thus, the deletion of ti from

13


i?1 simply adds ti in mti?1 and, moreover, ti remains present in the database until uj is performed. On the other hand, inserting tj in
j?1 removes ti from mtj?1 and adds ti in utj?1: Thus, the addition of ti in mti?1 performed by ui is cancelled by uj : The case where ui = ins and uj = del is similar, thus we have shown that every simpli cation in the while loop does not change the eect of S on
; : The application of the last two simpli cations in the algorithm is straightforward, as in Proposition 1 above. 2. Let S 0 be a subsequence of Simpw (S ) obtained by removing the update (u;  ) from Simpw (S ): Let us rst consider the case where u is ins: Since (ins;  ) has not been removed from S; S contains neither (ins;  0 ) where  0 is a supertuple of  , nor (del;  00 ) where  00 is a subtuple of : Thus,  is among the unmarked tuples of
= Simpw (S )(
;); that is,
derives : Let
0 = S 0(
;) = (ut0; mt0): Clearly, ut0 contains no supertuples of  (including  itself). Since no FDs are considered, the only way to derive tuples as true is by projection of tuples in ut (see the de nition of the operator  in subsection 2.2). As a consequence,  cannot be derived as true in
0: The case where S 0 is obtained from Simpw (S ) by removing a deletion being similar, the proof is complete. We note that, in the second point of Theorem 1, the assumption that no FDs are considered cannot be relaxed. Indeed, assume that B ! C is to be considered over the universe fA; B; C; Dg; and let S = (ins; abd); (ins; bcd); (ins; abc): Clearly, S = Simpw (S ); but S is equivalent to S 0 = (ins; abd); (ins; bcd); since abc can be derived from abd and bcd by projection and join. Moreover, it should be noted that if S (
) is de ned for a given database
, then so is Simpw (S )(
), since Simpw (S ) contains less insertions than S . Considering the time complexity of the algorithm Simpw ; it runs in time O(n2); where n is the length of S: Thus, update-sequence optimization has polynomial time complexity. As an example of how algorithm WSIMP works, consider the following update sequence: S = (del; abc); (ins; ab); (ins; abc0 ); (ins; abc); (del; ab0 c0); (del; ac0) During the execution of the while loop, the rst update (del; abc) gets removed due to the presence of the second update, and (ins; abc0 ) gets removed due to the last update in the sequence. Thus, the while loop reduces S to the following update sequence: S 0 = (ins; ab); (ins; abc); (del; ab0 c0); (del; ac0) The rst statement following the while loop will now remove (ins; ab) because of the second update in S 0; nally, the second statement following the while loop will remove (del; ac0). Hence, the result is Simpw (S ) = (ins; abc); (del; ab0 c0) We mention that the while loop in algorithm WSIMP deals with con icting updates in the original sequence, i.e., it removes all those updates which will be cancelled by 14

subsequent ones. We also note that, every update in Simpw (S ) is an update of S: Moreover, as ins(Simpw (S )) contains no subtuples of tuples in del(Simpw (S )); Conditions 5 and 6 of Proposition 1 show that the order in which updates appear in Simpw (S ) is immaterial. Therefore, we can consider that, given an update sequence S; the sequence Simpw (S ) is of the form: (ins; t1 ); (ins; t2 ); : : : ; (ins; tk ); (del; tk+1); (del; tk+2); : : : ; (del; tn) with ins(Simpw (S )) = ft1; t2 ; : : : ; tk g and del(Simpw (S )) = ftk+1; tk+2; : : : ; tng: As a consequence, every tuple in ins(Simpw (S )) will be inserted, and every tuple in del(Simpw (S )) deleted.

3.4 Update Transactions

We next consider transactions on marked databases. The transaction language used here has been introduced in [LPS93b], and is a variant of the language previously proposed in [AbV85, AbV88]. The main database operations of this language are add and remove, which will be employed to realize insertions and deletions, i.e., to modify the sets ut and mt according to the de nitions given above. If an (optimized) update sequence arrives, the idea is to translate it into a sequence of add and remove operations prior to execution. In the presence of several such sequences, or corresponding transactions, it will clearly be necessary to introduce some kind of synchronization mechanism, for example in order to avoid cyclic con icts between updates. Synchronization in turn needs to be based on a correctness criterion; to this end, we study serializability [ViV92] and the more recent notion of goal-correctness [ViV93]. In order to describe formally the transaction language of our model, we assume that the underlying universe U is xed. We also assume that no FDs are present, i.e., every insertion is accepted and no test has to be done in this respect. (The impact of functional dependencies will be outlined in Section 5.) First, we need the notion of a condition: De nition 9. (i) An elementary condition is an expression of the form  =  0 ;  6=  0 ;  2 E ;  62 E ; RR0, where  and  0 are terms (i.e., tuples or tuple variables or of the form :R for a relation schema R), R and R0 are relation schemas, E is a set-variable, and  stands for =; 6=;  or 6 . (ii) A condition is either an elementary condition, a conjunction of conditions, or of the form ?; L ! A 2 F , where ? is a condition, L is a relation scheme and A is in U: (iii) A valuation v of a condition ? replaces all variables occurring in ? with a tuple over the domains of the respective attributes. Let sat(?) denote the set of all tuples t such that there exists a valuation v with v(x) = t and v(?) is true. 2 Examples of conditions and their associated sets of satisfying tuples are as follows; let  be a tuple:  If ? is the condition sch( )  sch(y); y:sch( ) = ; then sat(?) is the set of all supertuples of : We denote this set by sup( ) in the remainder of the paper.  If ? is the condition sch(y)  sch( ); :sch(y) = y; then sat(?) is the set of all subtuples of : We denote this set by sub( ) in the remainder of the paper. 15

 If ? is the condition X ! A 2 F; XA  sch( ); XA  sch(y); :X = y:X; :A 6=

q:A, then sat(?) is equal to the set F of all possible tuples that contribute with  to contradict an FD of F: Clearly, we will consider conditions only which are satis able. Now we are ready to introduce the syntax of transactions: De nition 10. (i) Let  be a term, and let E stand for ut or mt: An elementary transaction is an expression of the form either add(; E ); where  is a term without variables, or remove( j?; E ); where ? is a condition. (ii) A transaction is a nite sequence of elementary transactions, i.e., if T1 and T2 are transactions then so is T1 ; T2. 2 We are now ready to de ne our translation: If S is an (optimized) update sequence, each operation of the form (del,  ) occurring in S will be translated as follows: remove(yj(sch( )  sch(y); y:sch( ) =  ); ut) ; add(; mt) Intuitively, this transaction rst removes from the set ut of a marked database
= (ut; mt) all supertuples of t and then adds t to the set mt (which is precisely what De nition 4 says). We notice that, when no confusion is possible, remove( j?; E ) is simply written as remove(?; E ): Moreover, the above transaction can be written in simpler form as Tdel : remove(sup( ); ut) ; add(; mt) Similarly, the translation of an operation of the form (ins,  ) occurring in a given update sequence S will remove from mt all subtuples of  and adds  to ut (thus modifying the database according to the insertion as de ned in De nition 4); it is de ned as follows: add(; ut) ; remove(yj(sch( )  sch(y); y:sch( ) =  ); mt) Again, a simpli ed version of this translation can be stated as Tins : add(; ut) ; remove(sub( ); mt) The translation of a given update sequence S = (u1; r1); (u2; r2); : : : ; (un; rn) is de ned as being the translation denoted by T (S ) that is the \concatenation" of the translations of the updates in S: For example, the sequence S = (ins; abc); (del; ab0 c0) is translated into the following transaction T (S ) : T (S ) : add(abc; ut) ; remove(sub(abc); mt) ; remove(sup(ab0c0); ut) ; add(ab0 c0; mt) Now, we de ne the eect of transactions formally; again we consider elementary transactions rst and then extend the de nition to sequences of elementary transactions. De nition 11. (i) Let
= (ut; mt) be a consistent database and T an elementary transaction. The eect of T on (ut; mt) is de ned as the pair (ut0; mt0 ) such that:  If T has the form add(t; E ); where t is a tuple, then { if E stands for ut then ut0 = ut [ ftg and mt0 = mt { if E stands for mt then ut0 = ut and mt0 = mt [ ftg: 16

 If T has the form remove(xj?; E ); where x is a variable, then { if E stands for ut then ut0 = ut ? sat(?) and mt0 = mt { if E stands for mt then ut0 = ut and mt0 = mt ? sat(?): (ii) If T has the form T1; : : : ; Tn, then the eect of T is the composition of the eects of the Ti; 1  i  n: 2 In the next section we consider the problem of combining the translations of several update sequences into one transaction (then called a schedule). To do so, we assume, as previously, that we are in the case where no FDs are present, and, moreover, we assume that all update sequences under consideration are weakly optimized.

4 Correctness of Transaction Schedules

4.1 State-Serializability

We now turn to issues arising in the concurrent processing of transactions. To this end we will deal with transactions that result from several (optimized) update sequences. If such transactions are to be executed, it is natural to do this via schedules in which the elementary transactions from distinct transactions are interleaved. Clearly, not every such schedule will be acceptable, for example due to cyclic con icts that may exist between the transactions. In order to sort out unacceptable schedules, we look at serializability as a well-known paradigm for schedule correctness. We mention that our study here is motivated by similar studies for relational update transactions, as undertaken, for example, in [ViV92, ViV93]. The notion of a schedule we will use here is the standard one: A schedule for a given set T of transactions is an element of the shue product of T . For being able to distinguish the elements of distinct transactions within a schedule, we will use indices. Note that without indices, a schedule is itself a transaction in the sense de ned above; hence the semantics of a schedule has implicitly been introduced already. As a rst example, consider two update sequences S1 = (ins; abc) and S2 = (del; ab): Translating these into transactions as de ned above may result in schedules like the following: T1 : add1(abc; ut) ; remove1 (sub(abc); mt) ; remove2(sup(ab); ut) ; add2(ab; mt)

T2 : add1(abc; ut) ; remove2 (sup(ab); ut) ; add2(ab; mt) ; remove1 (sub(abc); mt) Assuming that we start with a database
for which the insertion of abc is de ned, it should be clear that the eect of T1 corresponds to the execution of S1 followed by the execution of S2 ; in other words, T1 is a serial schedule. On the other hand, looking at T2 above, we note that its eect corresponds neither to the processing of S1 and then of S2 nor to the processing of S1 and then of S2 : Indeed, starting with the empty database, T2 leaves the database empty, whereas processing S1 and then S2 adds abc in mt (and, similarly, processing S2 and then S1 adds ab in ut). Hence, T2 is not \serializable", since its eect is not equivalent to any serial execution of the two transactions. 17

As a third example, consider the three update sequences S1 = (ins; abc); S2 = (del; ab) and S3 = (ins; abc0 ): Translating this into a transaction may result in a schedule like the following: T3 : add1(abc; ut) ; remove2 (sup(ab); ut) ; add2(ab; mt) ; add3(abc0 ; ut) ; remove1(sub(abc); mt) ; remove3(sub(abc0 ); mt) Assuming that we start with a database
for which the insertions of abc and of abc0 are de ned, the eect of T3 corresponds to the execution of S1; followed by the execution of S2 and followed by the execution of S3: In other words, T3 is a serial schedule. It is important to note that, in T3 ; if we only consider S1 and S2; then ut and mt are modi ed as in T2; which in not a serial schedule. In general, we assume that n weakly optimized update sequences S1 ; S2; : : : ; Sn are submitted to the scheduler. Each is translated into a transaction, say T (Si), and sent for execution. From these transactions, a schedule will be produced that is nally executed. In what follows, we consider only schedules T that result from the translation of some update sequences into transactions. We now de ne what it means for such a schedule to be serializable. De nition 12. Let S1 ; : : : ; Sn be n (optimized) update sequences, and let T be a schedule for the set T of transactions resulting from S1; : : : ; Sn. T is state-serializable if there exists a serial schedule for T with the same eect. Let SSR denote the class of all state-serializable schedules. 2 Clearly, serializability of a given schedule T for n transactions can be tested by considering each of the n! possible serial schedules and testing whether one is equivalent to T ; however, this is unacceptable. We next exhibit an ecient test for serializability, which is based on a graph G(T ) associated with a schedule T : G(T ) has the original update sequences as nodes, and has labelled directed edges which are de ned as follows. Let E stand for ut or mt, and let Si and Sj be two nodes, then there is an edge from Si to Sj if, in T; one of the following two cases is satis ed: 1. removej (?j ; E ) occurs after addi(; E ) such that  2 sat(?j ); and there is no transaction addk (; E ) occurring after removej (?j ; E ): 2. removej (?j ; E ) occurs before addi(; E ) with  2 sat(?j ); and there is no transaction removek (?k ; E ) with  2 sat(?k ) occurring after addi(; E ): In the rst case, the label associated to the edge is the triple hE; ; ?i; and in the second case, the label associated to the edge is the triple hE; ?;  i: For example, for the schedule T1 above, the graph G(T1 ) has two nodes, S1 and S2 , as well as two edges from S1 to S2 , one labelled hut; abc; sup(ab)i and the other labelled hmt; sub(abc); abi: The graph G(T1); shown in Figure 2, suggests that T1 is serializable: it has the same eect as the execution of S1 followed by the execution of S2: On the other hand, for schedule T2 above, the graph G(T2) has the same nodes, but now an edge labelled hut; abc; sup(ab)i from S1 to S2 and an edge labelled hmt; ab; sub(abc)i in the reverse direction. The graph G(T2); shown in Figure 2, suggests that T2 is not serializable, since it contains a cycle. 18

hUT;abc;sup(ab)i

hUT;abc;sup(ab)i

S1 hMT;sub(abc);abi .. S2

S1 / hMT;ab;sub(abc)i . S2

The graph G(T1)

The graph G(T2 ) hUT;sup(ab);abc i

hUT;abc;sup(ab)i

S1 / hMT;ab;sub(abc)i . S2 hMT;ab;sub(abc )i .. S3 0

0

The graph G(T3) Figure 2: Graphs associated to schedules T1 ; T2 and T3: Let us now consider the construction of the graph G(T3) of the schedule T3 given previously. The graph has three nodes S1; S2 and S3; as well as four edges, as shown in Figure 2. We recall that, although G(T3 ) contains a cycle, T3 is serializable, since it has the same eect as the serial executions of S1 ; S2 and S3: The test of serializability is based on the following algorithm SER: We note that, as in [ViV92], given a schedule T; the algorithm computes from right to left a serial schedule T 0 having the same eect as T i T is serializable. Algorithm SER Input: a schedule T and its graph G(T ) Output: a serializable schedule T 0 having the same eect as T if T is serializable. an error message otherwise. Method: begin T 0 := " ; stop := false ; while G(T ) 6= ; and not stop do trans := fSi j Si has no outcoming edge in G(T )g ; if trans = ; then begin stop := true ; return(error message) ; end else % trans = fSi1 ; : : : ; Sik g% begin T 0 := T (Si1 ) : : : T (Sik ):T 0 ; remove from G(T ) every edge labelled hE; ; ?i (resp. hE; ?;  i) such that there is Sik in trans such that G(T ) contains an edge to Sik labelled hE; ; ?0i (resp. hE; ?0;  i) ; remove from G(T ) all nodes Sik in trans ; end ; 19

end-while ; end. Algorithm SER allows for testing eciently the serializability of a given schedule T: Indeed, we rst note that algorithm SER runs in polynomial time and that, according to the following theorem, algorithm SER either outputs an error message when T is not serializable, or outputs a serial schedule T 0 having the same eect as T on every consistent database. Theorem 2. For a given schedule T , it can be decided in polynomial time whether or not T 2 SSR. 2 In order to prove Theorem 2, we will show that a schedule T is state-serializable i Algorithm SER applied to G(T ) outputs no error message. To this end, we need a lemma where the following notation is used. Let E stand for ut or mt; then add(T; E ) is the set of tuples  such that add(; E ) occurs in T; but G(T ) contains no edge labelled hE; ; ?i: We have the following lemma: Lemma 1. Let T and T 0 be two schedules associated to the same sequences S1 ; : : : ; Sk : T and T 0 have the same eect on every consistent database
i add(T; E ) = add(T 0; E ); for E = ut and for E = mt: 2 Proof: (If) We rst note that every tuple in add(T; E ) is added to the set E by the execution of T: Thus, if add(T; E ) = add(T 0; E ); for E = ut and for E = mt; then T and T 0 add the sames tuples in both sets ut and mt de ning the database. Similarly, every tuple in remove(T; E ) is removed from the set E by the execution of T: Moreover, assume that T removes from E a tuple t that is not removed by T 0: Then, T contains a transaction remove(?; E ) with t in sat(?): Therefore, so does T 0 and, furthermore, in T 0; this transaction if followed by add(t; E ) (because t is not removed by T 0): As a consequence, t is in add(T 0; E ) and not in add(T; E ); a contradiction. (Only If) We have to show that T and T 0 as in the lemma have the same eect on any consistent database. If such is not the case, then there exists a database
= (ut; mt) for which the eects of T and T 0 produce two distinct databases
1 = (ut1 ; mt1 ) and
2 = (ut2; mt2): Let E stand for ut or mt and assume that E1 6= E2 : Assume moreover that there is a tuple t in E1 that is not in E2 : Then, in T and in T 0; there are elementary transactions of the form tri = addi(t; E ); and trj = removej (?; E ) with t 2 sat(?): Moreover, in T; trj has been executed after tri ; and, in T 0; trj has been executed before tri: Therefore, in G(T ); there is edge from Si to Sj labelled hE; ?; ti and, in G(T 0); there is edge from Sj to Si labelled hE; t; ?i: Referring to the de nitions of add(T; E ) and of remove(T; E ); this means that t 2 add(T; E ) and t 62 add(T 0; E ); which completes the proof of the lemma. Proof of Theorem 2: If algorithm SER outputs no error message, G(T ) has become empty. In this case, we have add(T; E ) = add(T 0; E ): Indeed, T and T 0 contain the same elementary transactions, and, moreover, if t is in add(T; E ); then for every sequence Si such that add(t; E ) is in T (Si); G(T ) contains no edge from Si labelled hE; ; ?i: Thus, T contains no transaction remove(?; E ) with t 2 sat(?) occurring after add(t; E ): On the other hand, if t is not in add(T 0; E ); then there exists Si such that add(t; E ) is in T 0(Si); 20

and G(T 0) contains an edge from Si to Sik labelled hE; ; ?i: Thus, in T; remove(?; E ) occurs before add(t; E ); meaning that G(T ) contains an edge from Sik to Si: Thus, in T 0; T (Sik ) occurs before T (Si); which is a contradiction with the presence in G(T 0) of an edge from Si to Sik labelled hE; ; ?i: If we assume that t is in add(T 0; E ); but ot in add(T; E ); we have a similar case, which shows that add(T; E ) = add(T 0; E ): Thus, according to Lemma 1, T and T 0 have the same eect. Conversely, assume that T is serializable. There exists a serial schedule T1 having the same eect as T: If algorithm SER applied to G(T ) returns an error message, then at some iteration step, the set trans is empty. This means that, at this step, every node of G(T ) has at least one outcoming edge; in other words, each path from a node in G(T ) leads to a cycle. On the other hand, we note from Lemma 1 that, if G(T ) contains an edge from a node Si to a node Sj with label  then, in every serial schedule having the same eect as T; T (Si) must occur before at least one T (Sk ); such that G(T ) contains an edge from Si to Sk with a label 0 which diers from  only on its condition ?: Indeed, assume that G(T ) contains an edge from Si to Sj : If the label of this edge is hE; ; ?i; then  is not in add(T; E ): Therefore,  is not in add(T 0; E ); which implies that the transaction add(; E ) must be followed by a remove(?0 ; E ) with  2 sat(?0 ) appearing in a transaction T (Sk ): That is, G(T ) contains an edge from Si to Sk with label hE; ; ?0i; and Sk must follow Si in T 0: We note moreover that, if the label of the edge is hE; ?;  i; then the situation is similar. Thus, given any node S in G(T ); every path from S has the form S; S1; : : : Sk ; Sk+1; : : : Sk ; and, as a consequence of the previous remark, in every serial schedule having the same eect as T; T (Sk ) must occur before and after T (Sk+1); which is impossible, since we assume that at least one such serial schedule exists. As a consequence, the proof is complete. Applying Theorem 2 to our schedules T1; T2 and T3 above, we nd that T1 and T3 are serializable, while T2 is not. Theorem 2 in particular shows that state-based serializability, which has an NPcomplete decision problem in general, can be decided in polynomial time in speci c contexts, in which semantic information on the transactions is available. Theorem 2 is hence in line with a result in [ViV92], where it was shown that serializability of schedules which do not contain modify operations (but only inserts and deletes) can be decided in polynomial time.

4.2 Con ict-Serializability

In this subsection we look at restricted notions of correctness which have been considered in the literature, con ict-based serializability and goal-correctness. Since stateserializability generally has an NP-complete decision problem (even for transaction models taking semantic information into account, see [ViV92]), it is common in concurrency control theory to consider restricted notions of serializability which can be decided in polynomial time. The most common such notion is con ict-serializability, which has 21

been intensively studied in various contexts, and which is even the most widely adopted one in practice. In our transaction model for marked databases, con ict-serializability can be de ned in a standard way, which we now describe. Let T be a schedule built from transactions T (S1); T (S2); : : : ; T (Sn); where S1; S2; : : : ; Sn are n weakly optimized update sequences. T is said to be con ictserializable if all con icting elementary transactions in T from two arbitrary transactions T (Si) and T (Sj ) occur in the same order. More formally, we say that the elementary transactions tr and tr0 con ict if tr is add(; E ); and tr0 is remove(?; E ) with  in sat(?): Moreover, given two transactions T (Si) and T (Sj ); we denote by conf ji (T ) the set of transactions tri in T (Si) that con ict with at least one transaction trj in T (Sj ) occurring in T after tri: Using the above notations, con ict-serializability is de ned as follows: De nition 13. Let T be a schedule built from transactions T (S1); T (S2); : : : ; T (Sn); where S1 ; S2; : : : ; Sn are n weakly optimized update sequences. T is con ict-serializable if there exists a serial schedule T 0 such that, for every distinct i; j = 1; 2; : : : ; n; conf ji (T ) = conf ji (T 0): Let CSR denote the class of all con ict-serializable schedules. 2 In order to characterize schedules in CSR, we associate T with a directed graph, called the CS-graph of T and denoted by GCS (T ); as follows:  The nodes of GCS (T ) are the update sequences S1; S2; : : : ; Sn from which T1; T2 ; : : : ; Tn have been obtained.  There is an edge from Si to Sj if, in T; { addi(; E ) occurs before removej (?; E ) or addj (; E ) occurs after removei(?; E ); { and  belongs to sat(?): In other words, using the notations introduced just above, there is an edge from Si to Sj in GCS (T ) if and only if the set conf ji (T ) is not empty. Using the graph GCS (T ) as de ned above, the class CSR can easily been characterized. Theorem 3. Let T be a schedule built from transactions T1; T2; : : : ; Tn; and let GCS (T ) be its associated CS-graph. Then, T is con ict-serializable if and only if GCS (T ) is acyclic. 2 Proof: According to De nition 13, T is in CSR if there is a serial schedule T 0 such that conf ji (T ) = conf ji (T 0); for all distinct i; j = 1; 2; : : : ; n: Thus, GCS (T ) = GCS (T 0): Since T 0 is serial, GCS (T 0) is acyclic, and this completes the proof of the theorem. As is easily seen, the graph G(T ) (where the labels are ignored) is a subgraph of GCS (T ) for each T . Moreover, when G(T ) is acyclic, the set trans in algorithm SER is not empty if the graph G(T ) is not empty. Thus, assuming that T is a schedule in CSR, Theorem 3 implies that GCS (T ) is acyclic, which in turn implies that G(T ) is acyclic. Using Theorem 2 and the above remark, we obtain that T is in SSR. Thus, we have: Proposition 3. CSR  SSR. 2 Moreover, the schedule T3 from the previous subsection even shows that this inclusion is strict, since T3 is in SSR, but not in CSR. 22

4.3 Goal-Correctness

Another notion of correctness for schedules, recently introduced in [ViV93], is goalcorrectness, which is based on the intuition that transactions have goals associated with them, and a concurrent execution of given transactions is acceptable only if their goals are mutually consistent. As an example, consider the following two update sequences: Hire(Joe; CS 176) = (ins; hJoe; CS 176i) and Fire(Joe) = (del; hJoei) whose meaning is to update the database in order to assign Joe as a teacher for course CS 176 and in order to remove Joe from the database, resp. Clearly, the \goals" of the above updates are contradictory, and every state-serializable schedule built up from both Hire(Joe; CS 176) and Fire(Joe) will have one of the following eects: either Joe is hired or Joe is red! In other words, if Hire(Joe; CS 176) and Fire(Joe) are issued simultaneously by two distinct users, only one of them will have his update performed by the system, and, furthermore, none of them will be aware that a con icting situation has occurred. As argued in [ViV93], is seems that rejecting the transactions (and, for example, informing the users that their requests are in con ict) is preferable to resolving the con ict in an arbitrary fashion, as done by serializability. As has been shown in [ViV93] for a transaction model that contains a modify operation, goal-correctness is orthogonal to serializability, in contrast to serializability has a polynomial-time decision problem, but can be used in a dynamic setting only in restricted cases. In the context considered in this paper, the situation is remarkably dierent: Indeed, the notion of serializability introduced above is polynomial-time, so goal-correctness can only have the appealing aspect that it makes more appropriate use of the semantic information available. We now indicate that, for the model in question here, this is apparently not the case, since goal-correctness turns out to be a strict subset of the class CSR. In our model, due to the distinction between user and system levels (see Figure 1), goals are associated to updates. Intuitively, the goal of an insertion (resp. a deletion) is to render true (resp. false) the tuple to be inserted (resp. deleted). Going one step further, the goal of an update sequence S is to render true (resp. false) any tuple that is to be inserted (resp. deleted) in S; unless this update is followed in S by a con icting deletion (resp. insertion). This intuition of a goal associated to a given update sequence is captured by the following de nition. Notice that in this de nition the use of
; , denoting the marked database (;; ;), is appropriate, since intuitively goals are speci ed independent of a database contents. De nition 14. Let S be an update sequence. The goal of S is the marked database S (
;): 2 We note that, according to De nition 8, S (
;)  Simpw (S )(
;): As a consequence, the goals of an update sequence and the goal of its weakly optimized version are the same, up to database equivalence. This justi es why we feel allowed to restrict again our attention to weakly optimized update sequences. For example, the goal associated to the sequence S1 = (ins; abc) is the marked 23

database de ned by (fabcg; ;): Similarly, the goal associated to the sequence S2 = (del; ab); (ins; ab0 ) is the marked database de ned by (fab0 g; fabg): We next de ne the goal of a schedule T as being the \union" of the goals of the (weakly optimized) update sequences from which it is built. More formally, let T be a schedule obtained from update sequences S1 ; S2; : : : ; Sn and let Si(
; ) = (uti; mti ) denote the goal of Si(1  i  n): The goal of T is the pair of sets of tuples (GUT(T ); GMT(T )) de ned by: ( GUT(T ) = ut1 [ ut2 [ : : : [ utn GMT(T ) = mt1 [ mt2 [ : : : [ mtn It is important to note that the goal of T depends only on the update sequences T is obtained from. That is, the goal of T does not depend on the order following which the elementary transactions T (Si) appear in T: Finally, a schedule T obtained from update sequences S1; S2; : : : ; Sn is said to be goal-correct if the pair (GUT (T ); GMT (T )) de nes a consistent marked database, that is, if GUT(T ) contains no supertuples of tuples in GMT(T ): For example, let T be any schedule obtained from the above update sequences S1 and S2 : The goal of T is de ned by: ( GUT(T ) = fabc; ab0 g GMT(T ) = fabg Therefore, T is not goal-correct: the insertion of abc in S1 is in con ict with the deletion of ab in S2: On the other hand, let T be the following schedule obtained from S1 and S2 : T : add1(abc; ut) ; remove2(sup(ab); ut) ; remove1(sub(abc); mt) ; add1(ab0 ; ut) ; add2(ab; mt) ; remove1(sub(ab0 ); mt) The graph GCS (T ) has two nodes, S1 and S2 ; together with one edge from S1 to S2 : Therefore, according to Theorem 3, the schedule T is in CSR. More generally, it is easily seen that a goal-correct schedule always has a CS-graph containing no edges. Therefore, every goal-correct schedule belongs to CSR, and the previous example shows that the inclusion is strict. As a consequence, denoting by GCS the class of all goal-correct schedules, we have: Proposition 4. GCS  CSR. 2

4.4 Dynamic Aspects

To conclude our section on schedule correctness, we mention two additional issues which require attention in order to make an approach like the one discussed in this paper feasible for practical purposes. The rst is commit-serializability, which adopts the correctness criterion of serializability to a situation in which transactions are processed dynamically, i.e., are not fully known in advance. The second regards the design of scheduling protocols through which correct schedules can be produced in an online fashion. 24

In our investigations above, we always considered a set of transactions (or update sequences) to be processed as given. In a database system, this situation does not always hold, since often transactions arrive at the scheduler in some unpredictable way, i.e., the scheduler not always has full knowledge about the transactions to schedule in advance. As a consequence, correctness notions for schedules established for a static setting need to corrected appropriately. The common way to do this is to consider closure properties of schedule properties, in particular closure under commit operations as well as under taking pre xes; this has been described for the read-write of transactions, for example in [BHG87], and studied for the Abiteboul-Vianu model in [Vos92]. Since we do not consider commit operations in this paper, we here restrict our attention to pre x closures, applied to membership in CSR. Let CMCSR denote the class of all schedules from CSR for which each pre x is also in CSR. The following is now easily veri ed: Since membership in our class CSR, according to Theorem 3, can be characterized in terms of con ict graphs associated with schedules, and since subgraphs of acyclic graphs are still acyclic, it follows that, even in our setting, membership in CSR is unaected by considering pre xes of schedules. Thus we have: Proposition 5. CMCSR = CSR. 2 We nally mention that graph-based characterizations of notions of serializability always give rise to a straightforward protocol, serialization-graph testing (SGT), for the online generation of correct schedules; indeed, this can be found in [BHG87] for readwrite transactions, or in [ViV92] for relational update transactions. It should be clear that an SGT protocol can also be designed for the type of transactions and schedules we have considered in this paper. The idea is to have the scheduler maintain a dynamically changing graph, in which transactions are represented as nodes, and in which edges represent con icts between transactions. A transaction is aborted as soon as a new operation from this transaction gives rise to a cycle in this graph; details are omitted.

5 Taking Functional Dependencies into Account We next describe what can additionally be done w.r.t. optimization of update sequences when FDs are taken into account. When FDs are to be considered, not all insertions are de ned, as seen in De nition 4. However, instead of rejecting an insertion that generates a contradiction with respect to some functional dependency in F; it is usual to accept the insertion. Consequently, in order to restore consistency, all tuples that were in the database before the insertion and that are responsible of the inconsistency are deleted. For example, in Example 1, instead of rejecting the insertion of abc0 ; we can accept it and delete bc from
: This gives the following database
0 = (ut0 ; mt0); where: ut0 = fab; ac0 ; abc0 g and mt0 = fac; bcg: It is important to note that
0 is consistent and derives the tuple to be inserted, i.e., the tuple abc0 : However, as shown in [LPS93c], this processing of insertions requires the computation of the semantics of the updated database. 25

This is clearly unacceptable in the context of ecient transaction processing. This is why we shall consider here restrictions under which no computation is required to ensure the consistency of the resulting database. This restriction can be roughly stated as follows: the consistency of the tuples in ut (usually referred to as local consistency) implies the consistency of the database (usually referred to as global consistency). It is important to note that this property has been widely studied in the context of universal relation interfaces where the underlying relational database has a xed schema ([Sag93, Pha93]). However, we recall that, in our model, the database schema is not xed, and the problem of inferring global consistency from local consistency is subject to current investigation. We assume here that F satis es the following property:

(R) Every database
= (ut; mt) where F is assumed is consistent if and only if the tuples in ut satisfy the dependencies in F:

We now characterize sets F of FDs satisfying restriction (R) above as follows: for every X ! A in F; XA satis es

8Y ! B 2 F; B 2 XA =) XA  Y B: Schemas having the above property have been called prime in [LPS92, Pha93]. It is shown in [LPS92, Pha93] that a tuple t over a prime schema can be derived i the database contains a supertuple of t. Hence, restriction (R) holds i every FD in F has a prime scheme. Moreover, we note that, under restriction (R), every insertion can be accepted, provided it is processed as follows: Let
= (ut; mt) be a consistent database and let t be a tuple. De ne the set Ft as the set of all tuples that, together with t, contradict a functional dependency of F: More formally,

Ft = fq j 9X ! A 2 F : XA  sch(t); XA  sch(q); t:X = q:X; t:A 6= q:Ag: The consistent insertion of t in
; denoted by cons ins(t;
); is de ned to be the marked database
0 = (ut0 ; mt0) such that:  ut0 = (ut [ ftg) n Ft , and  mt0 = mt n fq j sch(q)  sch(t); t:sch(q) = qg: The following proposition states that every insertion processed as above against a consistent database returns a consistent database in which the update has been performed. Proposition 6. For every consistent database
= (ut; mt) such that F satis es restriction (R), and for every tuple t; the database cons ins(t;
) is a consistent database which derives t: 2 Proof: As
is assumed to be consistent, the set ut satis es F: Therefore, ut0 also satis es F which implies that cons ins(t;
) is consistent. The fact that cons ins(t;
) derives t comes from the fact that t is in ut0: 26

We note that under restriction (R), every update sequence for which the insertions are processed through cons ins instead of ins has a well-de ned eect. Moreover, it is easily seen that Proposition 1 still holds if ins is replaced by cons ins: In order to consider the impact of functional dependencies on update-sequence optimization, we shall assume in the remainder of this subsection that all insertions are processed through cons ins: Thus, as no confusion is possible, we denote cons ins by ins: Functional dependencies allow for the following additional case of optimization, namely the case where S contains two contradictory insertions. More precisely, we have: Proposition 7. Let S be an update sequence, and let F be a set of FDs satisfying restriction (R). Assume that 1. S contains (ins; ti ) and (ins; tj ) s.t. j > i and tj 2 Fti and that 2. there is no (uk ; tk ) in S s.t. k < i; uk = del and tk is a suptuple of ti: Then S w S 0, where S 0 is obtained from S by removing (ins; ti) from S: 2 Proof: It is easy to see that we have: S (
; ) = S 0(
; ): As a consequence of Proposition 5, the optimization of a given update sequence S in the presence of FDs satisfying restriction (R) can be achieved according to Algorithm Simpw where the while loop contains a new condition. The modi ed while loop is the following: while S changes do Let i be the smallest integer such that there exists j; i < j and (ui; ti); (uj ; tj ) in S and [(ui; ti) = (del; ti) and (uj ; tj ) = (ins; tj ) and ti is a subtuple of tj ] or [(ui; ti) = ins(ti ) and (uj ; tj ) = (del; tj ) and ti is a supertuple of tj ] or [ui = uj = ins and ti 2 Ftj ] if i and j as above exist then remove (ui; ti) from S end-while As an example of how the modi ed algorithm Simpw works, consider the FD B ! C and the following update sequence: S = (ins; ab0 c); (ins; abc0 ); (del; ab0c0); (ins; abc); (del; b0 c0); (del; b0c): During the execution of the modi ed while loop, the rst update (ins; ab0 c) gets removed due to the presence of the last update. As the insertions of abc0 and of abc in S con ict, (ins; abc0 ) gets removed. Thus, the modi ed while loop reduces S to the following update sequence: S 0 = (del; ab0 c0); (ins; abc); (del; b0 c0); (del; b0c): The second statement following the while loop will now remove (del; b0c0). Hence, the simpli ed sequence is Simpw (S ) = (del; ab0c0 ); (ins; abc); (del; b0c): Finally, the next transaction is intended to perform a modi cation of given sets ut and mt; according to the de nition of cons ins given previously: 27

cons insert( ) : add(; ut) ; remove(yj(X ! A 2 F; XA  sch( ); XA  sch(y); :X = y:X; :A 6= q:A); ut) ; remove(yj(sch( )  sch(y); y:sch( ) =  ); mt) Given a tuple ; cons insert( ) can be simpli ed into the following transaction: Tcons ins : add(; ut) ; remove(F ; ut) ; remove(sup( ); mt): We nally note that Theorem 2 still applies in the presence of Tcons ins; instead of Tins:

6 Conclusions and Future Work In this paper, we have studied update transactions in marked databases from the point of view of optimization and concurrent execution. We recall that a marked database is a relational database in which the schema is not xed and in which deleted tuples are physically stored and marked. We have used a previously presented language for the speci cation of transactions on marked databases to study the problems of ecient and of correct execution of transactions. This has been carried out using a new notion of update-sequence equivalence which is based on database semantics. This equivalence allows to associate with every update sequence an optimized one, containing less updates. Moreover, we have considered in this framework the serializability of schedules involving transactions resulting from the submission of several optimized update sequences. As we could show, unrestricted serializability is eciently decidable for marked databases, and even subsumes a notion of correctness which previously was orthogonal to serializability. Future research on this topic will include considering a more realistic language for specifying updates, i.e., a language allowing updates such as \delete all tuples such that some condition holds," and extending the transaction model in the direction of active databases. Another area of future research concerns the use of deleted tuples in recoverability of transaction schedules. Indeed, traditional recovery mechanisms, applied, for example, when aborting transactions, are based on a log which stores before- and after-images of database objects. In a marked database, updates are mostly preserved, so the need to keep a separate log might disappear. Most likely, such an approach to recovery of transactions would require a dierent organization of a marked database, e.g., as a labelled graph, so that previous states of the database can easily be identi ed. This may even carry over to temporal issues as well as to multiple versions.

References

[Abi88] S. Abiteboul, \Updates, a New Frontier," Proc. 2nd ICDT 1988, Springer LNCS 326, 1{18.

[AbV85] S. Abiteboul, V. Vianu, \Transactions and Integrity Constraints," Proc. 4th ACM PODS 1985, 193{204.

28

[AbV88] S. Abiteboul, V. Vianu, \Equivalence and Optimization of Relational Transactions,"

JACM 35, 1988, 70{120 [AbV89] S. Abiteboul, V. Vianu, \A Transaction-Based Approach to Relational Database Speci cation," JACM 36, 1989, 758{789. [AtT92] P. Atzeni, R. Torlone, \Updating Relational Databases through Weak Instance Interfaces," ACM TODS 17, 1992, 718{745 [BaS81] F. Bancilhon, N. Spyratos \Update Semantics of Relational Views," ACM TODS 6, 1981, 557{575. [BHG87] P.A. Bernstein, V. Hadzilacos, N. Goodman, Concurrency Control and Recovery in Database Systems, Addison-Wesley, 1987. [BDM88] F. Bry, H. Decker, R. Manthey, \A Uniform Approach to Constraint Satisfaction and Constraint Speci cation in Deductive Databases," Proc. 1st EDBT 1988, Springer LNCS 303. [KaV91] D. Karabeg, V. Vianu, \Simpli cation Rules and Complete Axiomatization for Relational Update Transactions," ACM TODS 16, 1991, 439{475. [LaS88] D. Laurent, N. Spyratos, \Introducing Negative Information in Relational Databases," Proc. MFCS 1988, Springer LNCS 324. [LaS94] D. Laurent, N. Spyratos, \A Partition Model Approach to Updating Universal Scheme Interfaces," IEEE TKDE 6, 1994, 316{330. [LPS92] D. Laurent, V. Phan Luong, N. Spyratos, \Deleted Tuples are Useful when Updating through Universal Scheme Interfaces," Proc. 8th IEEE ICDE 1992. [LPS93a] D. Laurent, V. Phan Luong, N. Spyratos, \Database Updating Made Deterministic," Proc. 2nd CNKBS Workshop 1993. [LPS93b] D. Laurent, V. Phan Luong, N. Spyratos, \Transaction Speci cation in Marked Databases," LIFO Techn. Rep. 93-5, Orleans 1993. [LPS93c] D. Laurent, V. Phan Luong, N. Spyratos, \Database Updating Revisited," Proc. 3rd DOOD 1993, Springer LNCS 760, 296{309. [LeS88] Ch. Lecluse, N. Spyratos, \Implementing Queries and Updates on Universal Scheme Interfaces," Proc. 14th VLDB 1988, 62{75. [Mai83] D. Maier, The Theory of Relational Databases, Computer Science Press, 1983. [MUV84] D. Maier, J.D. Ullman, M.Y. Vardi, \On the Foundations of Universal Relation Model," ACM TODS 9, 1984, 283{308. [Pha93] V. Phan Luong, Une Nouvelle Approche des Fonctions-Fenetre et des Mises a jour pour Interface de type Relation Universelle, Ph.D. Dissertation, Universite de Paris-Sud, 1993. [Rei84] R. Reiter, \Towards a Logical Reconstruction of Relational Database Theory," in On Conceptual Modelling (M. L. Brodie, J. Mylopoulos, J. W. Schmidt), Springer-Verlag, 1984. [Sag83] Y. Sagiv, \A Characterization of Globally Consistent Databases and their Correct Access Paths," ACM TODS 8, 1983, 266{286 [Ull89] J.D. Ullman, Principles of Databases and Knowledge Base Systems, Vols. I, II, Computer Science Press, 1988, 1989.

29

[ViV92] V. Vianu, G. Vossen, \Conceptual Level Concurrency Control for Relational Update

Transactions," TCS 95, 1992, 1{42. [ViV93] V. Vianu, G. Vossen, \Static and Dynamic Aspects of Goal-Oriented Concurrency Control," AMAI 7, 1993, 257{287. [Vos91] G. Vossen, Data Models, Database Languages and Database Management Systems, Addison-Wesley, 1991. [Vos92] G. Vossen, \Commit-Serializability of Schedules for Relational Update Transactions," FCDS 17, 1992, 153{169. [Wei91] G. Weikum, \Principles and Realization Strategies of Multilevel Transaction Management," ACM TODS 16, 1991, 132{180. [Win88] M. Winslett, \A Model-Based Approach to Updating Databases with Incomplete Information," ACM TODS 13, 1988, 167{196.

30