References. 6. Conclusions

Transcription

1 insert((1, 2), R 1 ). Suppose further two local updates insert((2, 5), R 2 ) and delete((5, 6), R 3 ) occurred before the maintenance sub-queries for insert((1, 2), R 1 ) are evaluated by S 2 and S 3, respectively, and their corresponding notifications are stored right after the notification for insert((1, 2), R 1 ) in EQ(V) in the given order. (1) The maintenance for insert((1, 2), R 1 ): 1. Send query ( 11./ R 2 ) to S 2 ; /* 11 = f(1, 2)g */ 2. r 12 = f(1, 2, 3)(1, 2, 5)g; /* note that (2, 5) has been inserted into R 2 */ 3. Delete (1, 2)./ (2, 5) = (1, 2, 5) from r 12 since insert((2, 5), R 2 ) causes an anomaly; = r 12 = f(1, 2, 3)g; 5. Send query ( 12./ R 3 ) to S 3 ; 6. r 13 = f(1, 2, 3, 4)g; 7. Delete((5, 6), R 3 ) does not cause any anomaly since (1, 2, 3)./ (5, 6) = ; = r 13 = f(1, 2, 3, 4)g; 9. Insert tuples in 13 into V; /* V = f(1, 2, 3, 4)g */ (2) The maintenance for insert((2, 5), R 2 ): 1. Send query ( 22./ R 3 ) to S 3 ; /* 22 = f(2, 5)g */ 2. r 23 = ; /* note that (5, 6) has been deleted from R 3 */ 3. Insert (2, 5)./ (5, 6) = (2, 5, 6) into r 23 since delete((5, 6), R 3 ) causes an anomaly; = r 23 = f(2, 5, 6)g; 5. Send query (R 1./ 23 ) to S 1 ; = r 13 = f(1, 2, 5, 6)g; 7. Insert tuples in 13 into V; /*V=f(1, 2, 3, 4),(1, 2, 5, 6)g*/ (3) The maintenance for delete((5, 6), R 3 ): 1. Send query (R 2./ 33 ) to S 2 ; /* 22 = f(5, 6)g */ = r 23 = f(2, 5, 6)g; 3. Send query (R 1./ 23 ) to S 1 ; /* 23 = f(2, 5, 6)g */ = r 13 = f(1, 2, 5, 6)g; 5. Delete tuples in 13 from V; /* Finally, view V = f(1, 2, 3, 4)g */ Based on our view maintenance algorithm, the maintenances for three local updates, including the anomaly detection and handling, are properly handled by the front-end, and view V is maintained consistently with its corresponding local relations. 6. Conclusions In a distributed environment, it is possible for messages to be delivered and received in different orders. As such, a notification message sent earlier than a result message may be received by the front-end later than that result message, and vice versa. We have confirmed this observation through experiments using our prototype view maintenance system. Examples were used to show that under such a circumstance, precise detection of maintenance anomalies is essential for achieving correct view maintenance. In this paper, we proposed a new method for precisely detecting the occurrence of view maintenance anomalies for global views that are defined by SPJ queries (i.e., p (R 1./ R 2./.../ R n )) in a multidatabase system. The method takes into account the possibility that messages sent from one site may arrive at another site with different orders due to network routing and delay. As part of the method, a scheduler is devised at the front-end to synchronize different maintenance requests from the underlying local database systems. A necessary and sufficient condition for identifying anomalies is proved based on the scheduler. Our current effort is focused on the correct detection and handling of maintenance anomalies for global views defined by SPJ queries. Next, We will investigate possible extensions of our method to the views that are defined by more complicated integration operators, such as outerjoin. References [1] J.A. Blakeley, P-A. Larson, and F.W. Tompa, Efficiently Updating Materialized Views. In Proceedings of the ACM SIG- MOD [2] R. Chen, and W. Meng, Efficient View Maintenance in a Multidatabase Environment. In Proceeding of fifth International Conference on Database Systems for Advanced Applications, Melbourne, Australia, April [3] R. Chen, and W. Meng, Precise Detection and Proper Handling of View Maintenance Anomalies in a Multidatabase Environment. CS-TR-97-01, Department of Computer Science, State University of New York at Binghamton, 1997 [4] L. Colby, T. Griffin, L. Libkin, I. Mumick, and H. Trickey, Algorithms for Deferred View Maintenance. In Proceedings of the ACM SIGMOD [5] A. Gupta, I.S. Mumick, and K.A. Ross, Adapting Materialized Views after Redefinitions. In Proceedings of the ACM SIGMOD [6] A. Gupta, I.S. Mumick, and V.S. Subrahmanian, Maintaining Views Incrementally. In Proceedings of the ACM SIGMOD [7] E.N. Hanson, A Performance Analysis of View Maintenance Strategies. In Proceedings of the ACM SIGMOD [8] J.V. Harrison and S.W. Dietrich, Maintenance of Materialized View in a Deductive Database: An Update Propagation Approach. In Proceedings of the 1992 JICLSP Workshop on Deductive Databases, [9] R. Hull and G. Zhou, A framework for supporting data integration using the materialized and virtual approaches. In Proceedings of the ACM SIGMOD [10] X. Qian and G. Wiederhold, Incremental Recomputation of Active Relational Expression. IEEE Transactions on Knowledge and Data Engineering, Sep., [11] O. Shmueli and A. Itai, Maintenance of View. In Proceedings of the ACM SIGMOD [12] J. L. Wiener, H. Gupta, W. J. Labio, Y. Zhuge, H. Garcia- Molina, and J. Widom, A System Prototype for Warehouse View Maintenance. Workshop on Materialized Views, [13] Y. Zhuge, H. Garcia-Molina, J. Hammer, and J. Widom, View Maintenance in a Warehousing Environment. In Proceedings of the ACM SIGMOD [14] Y. Zhuge, H. Garcia-Molina, and J. Widom, The Strobe Algorithms for Multi-Source Warehouse Consistency. In Proceedings of Fourth International Conference on Parallel and Distributed Information Systems, [15] Y. Zhuge, J. Widom, and H. Garcia-Molina, Multiple View Consistency for Data Warehousing. In Proceedings of 13th International Conference on Data Engineering, 1997.

2 Op(ti, R i ) is being processed, then no anomaly can occur. That is, to ensure that the global view is maintained consistently with the local databases, the result of the maintenance query for Op(ti, R i ) should be p (R 1 (ti)./.../ ti./.../ R n (ti)). However, due to local autonomy, the state of R j may be changed to a state different from R j (ti) by local updates occurred before the maintenance sub-query for Op(ti, R i ) is evaluated at S j but the maintenances for those local updates have not been completed. Consequently, potential anomalies may occur. We now provide an execution strategy for R 1./.../ ti./.../ R n to obtain R 1 (ti)./.../ ti./.../ R n (ti). Based on this strategy, we extend our previous view maintenance mechanism to handle general SPJ views. All anomalies can be precisely detected and properly handled. Our execution strategy for obtaining R 1 (ti)./.../ ti./.../ R n (ti) consists of two phases. In the first phase, ti is first joined with R i+1(ti), whose result is then joined with R i+2(ti). This phase continues till R n (ti) is joined. This phase is called the forward phase. In the second phase (called the backward phase), the result of the forward phase is first joined with R i?1(ti), then with R i?2(ti),..., eventually with R 1 (ti). This execution strategy is reasonably efficient as it starts with a very small relation (with exactly one tuple ti). The detail of this strategy together with anomaly detection and handling is described below. We now show how to perform maintenance for Op(ti, R i ) based on the above execution strategy for R 1./.../ ti./.../ R n. Anomaly detection and handling will be incorporated. Due to the similarity of the maintenance techniques, we consider the forward phase only. Let ik, i k n, be the intermediate result of ti./ R i+1(ti)./.../ R k (ti) (note that ii = ti). With the above execution strategy, the joins will be performed one at a time. Each join is between an intermediate result, say i(j?1), and a local relation, say R j. Such a join is the maintenance sub-query to be processed at S j. Let r ij be the result of i(j?1)./ R j returned from S j. If R j is in the state R j (ti) when i(j?1)./ R j is performed at S j, then ij = r ij. Otherwise, if R j is in a state, denoted by R j (*), other than R j (ti) when i(j?1)./ R j is performed at S j, then, according to Lemma 1, those local updates that have changed R j from the state R j (ti) to the state R j (*) have the potential to cause anomaly to the maintenance for Op(ti, R i ). Suppose Op1(tk, R j ) is one of those local updates, and Ti is a tuple in i(j?1). If Ti./ tk =, then Op1(tk, R j ) will have no impact on the evaluation of the maintenance sub-query. If Ti./ tk 6= then Op1(tk, R j ) will affect the evaluation of the maintenance sub-query. As a result, an anomaly occurs. More specifically, if Op1 is insert, then an additional occurrence of (Ti./ tk) will be in r ij due to Op1(tk; R j ). If Op1 is delete, then the number of occurrences of (Ti./ tk) in r ij will be reduced by 1 due to Op1(tk; R j ). Therefore, if an anomaly is detected, the compensation (insert (Ti./ tk) into r ij if Op1 is delete; delete (Ti./ tk) from r ij if Op1 is insert) is immediately taken to the result r ij by the front-end. In summary, if R j is not in the state R j (ti), then r ij needs to be compensated for each anomaly. In this case, ij is the result r ij after compensations are performed. After 1n is obtained, the materialized view V can be updated using p ( 1n ). In the follows, the algorithm view maintenance is invoked by the front-end when (Op(ti, R i ), Ci, R i ) appears at the head of EQ(V). view maintenance can handle the maintenance for views defined by general SPJ queries. The anomaly detection and handling algorithm will precisely detect and properly handle maintenance anomalies with the consideration of network delay. The materialized view V is updated by the front-endonly after the final result p ( 1n ) is obtained. Algorithm view maintenance ((Op(ti; R i ), Ci, R i )) 1. for j =i+1 to n do /* forward phase */ 2. send maintenance sub-query ( i(j?1)./ R j ) to S j ; 3. receive the query result (r ij, Cj, R j ) from S j ; 4. call anomaly detection and handling( i(j?1), r ij ); 5. ij = r ij ; 6. for j = i-1 to 1 do / backward phase */ 7. send maintenance sub-query (R j./ (j+1)n) to S j ; 8. receive the query result (r jn, Cj, R j ) from S j ; 9. call anomaly detection and handling((j+1)n, r jn ); 10. jn = r jn ; 11. if (Op = delete) then 12. delete tuples in p ( 1n ) from V; 13. else /* Op = insert */ 14. insert tuples in p ( 1n ) into V; 15. update gcounterr i ; 16. remove (Op(ti, R i ), Ci, R i ) from EQ(V); Algorithm anomaly detection and handling(, r) 1. compute potential anomaly(r j ; Op(ti; R i )); 2. if (potential anomaly(r j ; Op(ti; R i )) 6= ) 3. for each Ti in do 4. for each notification (Op1(tk, R j ), Ck, R j ) whose Ck is in potential anomaly(r j ; Op(ti; R i )) do 5. if (Ti./ tk 6= ) then 6. if (Op1 = delete) then 7. insert (Ti./ tk) into r; 8. else /* Op1 = insert */ 9. delete (Ti./ tk) from r; Example 5 (example for views defined by general SPJ queries) (A, B) R1: R2: (B, C) (2, 3) R3: (C, D) (3, 4) (5, 6) Consider a view V = R 1./ R 2./ R 3. For simplicity of illustration, suppose V = initially. Suppose the maintenance notification for local update insert((1, 2), R 1 ) appears at the head of EQ(V). The front-end initiates the maintenance for

3 Op(ti, R i ) even if the base relations used to form view V continue to be updated. Algorithm view maintenance ((Op(ti; R i ), Ci, R i )) 1. append (Op(ti, R i ), Ci, R i ) to EQ(V); 2. send a maintenance query p (ti./ R j ) to S j ; 3. receive the query result (ri, Cj, R j ) from S j ; 4. while ((Op(ti, R i ), Ci, R i ) at the head of EQ(V)) do /*start to perform the global view update process*/ 5. compute potential anomaly(r j ; Op(ti; R i )); /* = fa j gcounterr j a < Cjg */ 6. if (potential anomaly(r j ; Op(ti; R i )) 6= ) /* anomaly detection and handling */ 7. for each notification (Op1(tk, R j ), Ck, R j ) whose Ck is in potential anomaly(r j ; Op(ti; R i )) do 8. if (ti./ tk 6= ^ P (ti./ tk) = true) then /* do compensation */ 9. if (Op1 = delete) then 10. insert p (ti./ tk) into ri; 11. else /* Op1 = insert */ 12. delete p (ti./ tk) from ri; 13. if (Op = delete) 14. delete tuples in ri from V; 15. else /* Op = insert */ 16. insert tuples in ri into V; 17. update gcounterr i ;/*gcounterr i =gcounterr i +1*/ 18.remove (Op(ti, R i ), Ci, R i ) from EQ(V); After maintenance for Op(ti; R i ) is initiated, the frontend appends the notification (Op(ti, R i ), Ci, R i ) to queue EQ(V) (line 1). The front-end sends the maintenance query to S j and receives the result from S j (lines 2 and 3). The global view update process w.r.t. Op(ti, R i ) is not started until (Op(ti, R i ), Ci, R i ) appears at the head of queue EQ(V) (line 4). The frontend computes potential anomaly(r j ; Op(ti; R i )) from Cj and the current value of gcounterr j (line 5). For example, suppose the current gcounterr j = 4 and Cj = 6. Then, potential anomaly(r j ; Op(ti; R i )) = f4, 5g. That is, the local updates on R j whose notifications have counter values equal to 4 or 5 have the potential to cause anomalies to the maintenance for Op(ti, R i ). If potential anomaly(r j ; Op(ti; R i )) 6=, a further anomaly detection and handling is processed (lines 6 to 12). The correctness of the anomaly detection (lines 6 to 8) and the handling of real anomalies (lines 9 to 12) have been proved, respectively, in the necessity part and sufficiency part of Proposition 1. The front-end updates the view V according to the result ri (lines 13 to 16). After V is updated, the front-end updates gcounterr i (line 17). By now, the maintenance for Op(ti,R i ) is processed completely. The front-end then removes (Op(ti,R i ),Ci,R i ) from EQ(V) (line 18). Proposition 2. The maintenance for Op(ti, R i ) can be processed completely even if the base relations used to form view V continue to be updated. Proposition 2 shows that our maintenance algorithm has the property that can complete the the maintenance for Op(ti, R i ) even if the base relations used to form view V continue to be updated. This property allows view V to be maintained in more timely manner[14]. The proof of Proposition 2 can be found in [3]. 5. Maintenance for General SPJ Views Previously, we discussed the maintenance for views defined by the join of two relations. In this section, we will discuss how to extend our view maintenance algorithm to views defined by the join of two or more relations. Consider the materialized global view V = p (R 1./ R 2./.../ R n ), where R k is from local database system S k, k = 1,.., n. Suppose ti of R i is the tuple involving Op, and (Op(ti, R i ), Ci, R i ), from S i, is its corresponding maintenance notification received by the front-end. In our previous maintenance mechanism for views defined by the join of two relations, after the maintenance for a local update is initiated, the notification w.r.t. that local update is appended to the end of EV(Q), and the corresponding maintenance query is sent to the relevant local database system. In our extended maintenance mechanism, after the maintenance for the local update, Op(ti, R i ), is initiated, the notification, (Op(ti, R i ), Ci, R i ), is appended to the end of EV(Q), and the front-end decomposes the maintenance query (i.e., p (R 1./.../ ti./.../ R n )) into a number of maintenance sub-queries according to an execution strategy to be discussed shortly. The front-end starts to send the maintenance sub-queries to relevant local database systems only when (Op(ti, R i ), Ci, R i ) appears at the head of EV(Q). The synchronization method discussed in Section 3 is also applied by the front-end to ensure that the maintenances for local updates on the same local relation are initiated in the same order as that in which those local updates are performed locally. Each local relation can be updated locally. After a local update is completed, the local relation is changed from one state to another state. Suppose there is a state, denoted by R j (ti), for each local relation R j, 1 j n and j 6= i, which is obtained by completing exactly those local updates, if there is any, whose maintenances are initiated before the maintenance for Op(ti, R i ). According to Lemma 1, a local update, say luj, on R j has the potential to cause an anomaly to the maintenance for Op(ti, R i ) only if luj occurred before the evaluation of the maintenance sub-query for Op(ti, R i ) at S j, and its corresponding maintenance is processed completely after the maintenance for Op(ti, R i ) is processed completely (i.e., the maintenance for luj is initiated after the maintenance for Op(ti, R i )). Therefore, if each local relation R j is in the state of R j (ti) while the maintenance for local update

4 S1 no impact on the evaluation of the maintenance query for Op(ti, R i ), namely p (ti./ R j ), since p (ti./ tk) =. (c) That Ck must be in potential anomaly(r j ; Op(ti; R i )) in order for Op1(tk, R k ) to have the potential to cause an anomaly to the maintenance for Op(ti, R i ) is the direct consequence of Lemma 1 and the fact that R i and R k (= R j ) are used to form view V. Sufficiency: (a) If conditions(1), (2), and (3) are satisfied, then Op1(tk; R k ) (or Op1(tk; R j )) will make a difference on the result ri of the maintenance query for Op(ti, R i ), namely p (ti./ R j ), if Op1(tk; R k ) occurred before the evaluation of this maintenance query. Specifically, let t = p (ti./ tk). If Op1 is insert, then an additional occurrence of t (the one derived from ti and tk) will be in ri due to Op1(tk; R j ). If Op1 is delete, then the number of occurrences of t in ri will be reduced by 1 due to Op1(tk; R j ). (b) If Ck is in potential anomaly(r j ; Op(ti; R i )) (i.e., condition (4) is satisfied), then the local update Op1(tk; R k ) must have occurred before the maintenance query for Op(ti; R i ) is evaluated (since Ck < Cj) and the maintenance for Op1(tk; R k ) has not been processed completely (since Ck gcounterr j ). From (a) and (b), it can be derived that if all of the four conditions are satisfied, then the local update Op1(tk; R k ) will affect the result of the maintenance query for Op(ti; R i ). Furthermore, since the global view update for Op1(tk; R k ) will be processed after the global view update for Op(ti, R i ), the problem created by Op1(tk; R k ) on the result ri will not be taken care of by the global view update for Op1(tk; R k ) by the time when the global view update for Op(ti, R i ) is to be performed. An anomaly will occur as a result. Specifically, if Op and Op1 are both insert, then an extra occurrence of t will be inserted into the global view V by the global view update for Op(ti, R i ); if Op is insert and Op1 is delete, then one fewer occurrence of t will be inserted into V; if Op is delete and Op1 is insert, then an extra occurrence of t will be deleted from V; if Op and Op1 are both delete, then one fewer occurrence of t will be deleted from V. In conclusion, if all of the four conditions are satisfied, the local update Op1(tk; R k ) will cause an anomaly to the maintenance for Op(ti; R i ). Example 4 (detection of real anomaly) lu1:delete(t1, R1) (delete(t1, R1), c, R1) m1: gu1 (compensation : delete J(t1, t2)) e2 q2 r2 gu2 front-end q1 m2:(delete(t2, R2), n, R2) time lu2:delete(t2, R2) r1:(r1, n+1, R2) S2 e1 Figure 5. Event sequence of Example 4 In Example 2, the local update lu2, i.e., delete(t2; R 2 ), caused an anomaly to the maintenance for another local update lu1, i.e., delete(t1; R 1 ). However, this anomaly could not be detected previously because the maintenance notification corresponding to lu2, namely m2, arrived at the front-end later than the result, namely r1, of the maintenance query corresponding to lu1 due to the network delay (see Figures 3 and 5). We now apply Proposition 1 to detect the anomaly. Suppose lcounterr 2 = n, gcounterr 2 = n, and indexr 2 = n before delete(t2; R 2 ) is made. According to the order in which messages are sent out from S 2, the notification delete(t2; R 2 ) will be modified to (delete(t2; R 2 ), n, R 2 ) before it is sent to the front-end; the result r1 of the maintenance query q1 will be modified to (r1, n+1, R 2 ) before it is sent to the frontend (note that lcounterr 2 has been increased by 1 after (delete(t2; R 2 ), n, R 2 ) was sent to the front-end). Suppose all maintenances for local updates related to view V have been processed if they are initiated before the maintenance for lu1. After (r1, n+1, R 2 ) is received, the front-end starts the global view update process for delete(t1; R 1 ). First, potential anomaly(r 2 ; delete(t1; R 1 )) = fng is computed from n+1 and gcounterr 2. This means that the global view update process for delete(t1; R 1 ) will wait for a notification concerning R 2 with local counter value equal to n to arrive. After (delete(t2; R 2 ), n, R 2 ) is received by the front-end, we can use the conditions in Proposition 1 to check if delete(t2; R 2 ) will cause a real anomaly to the maintenance for delete(t1; R 1 ). Using the notations in Proposition 1, we have ti = t1, R i = R 1, tk = t2, R k = R 2, Ck = n. Conditions (1) and (2) are satisfied from the assumptions that V is integrated from R 1 and R 2 (recall V = (R 1./ R 2 )), and t is formed from t1 and t2. Condition (3) is trivially satisfied since no predicate condition is used to define V. Condition (4) is satisfied because Ck = n is in potential anomaly(r 2 ; delete(t1; R 1 )). Therefore, according to Proposition 1, delete(t2; R 2 ) will cause an anomaly to the maintenance for delete(t1; R 1 ). A compensation which deletes t = (t1./ t2) from r1 is then made by the front-end. Readers can verify that with our new maintenance mechanism, the false anomaly shown in Example 3 can also be precisely detected. 4. View Maintenance with Possible Anomalies The following view maintenance algorithm is invoked to update view V defined by the join of two relations each time when the maintenance for a local update w.r.t. V, say Op(ti, R i ), is initiated. The view maintenance algorithm will (1) precisely detect which local update will cause an anomaly to the maintenance for Op(ti, R i ) without making any assumption about the delivering and receiving order of messages, and (2) complete the maintenance process for

5 rialized global view under consideration, where R i is from local database system S i and R j is from local system S j. Lemma 1. For a local update Op1(tj, R j ) to cause an anomaly to the maintenance for another local update Op(ti, R i ), the following two conditions must be satisfied: 1. Op1(tj, R j ) occurred before the evaluation of the maintenance query for Op(ti, R i ) at S j. 2. The maintenance for Op1(tj, R j ) is processed completely after the maintenance for Op(ti, R i ) is processed completely. Proof: Consider condition (1) first. If Op1(tj, R j ) occurs after the evaluation of the maintenance query for Op(ti, R i ), then Op1(tj, R j ) will have no way to impact the maintenance for Op(ti, R i ). This is true because of the following two reasons. First, Op1(tj, R j ) will have no impact on the evaluation of the maintenance query corresponding to Op(ti, R i ). Second, the maintenance for Op(ti, R i ) is initiated by the front-end before the maintenance for Op1(tj, R j ) is initiated. Based on our maintenance algorithm described above, the global view update w.r.t. Op(ti, R i ) will be performed before the global view update w.r.t. Op1(tj, R j ). This means that the global view update w.r.t. Op1(tj, R j ) can not affect the global view update w.r.t. Op(ti, R i ). Therefore, condition (1) must be true for Op1(tj, R j ) to cause an anomaly to the maintenance for Op(ti, R i ). Now consider the case when condition (1) is satisfied but condition (2) is not, i.e., the maintenance for Op1(tj, R j ) is processed completely before the maintenance for Op(ti, R i ). The following subcases may occur: (i) Op(ti, R i ) occurs after the evaluation of maintenance query for Op1(tj, R j ). In this case, no interference between the maintenances for the two updates is possible. (ii) Op(ti, R i ) occurred before the evaluation of maintenance query for Op1(tj, R j ). In this case, the impact of Op1(tj, R j ) on the maintenance for Op(ti, R i ) is the same as that in case (i) (although the impact of Op(ti, R i ) on the maintenance for Op1(tj, R j ) is no longer the same as that in case (i)). As a result, Op1(tj, R j ) can not cause any anomaly to the maintenance for Op(ti, R i ). Therefore, both conditions (1) and (2) must be satisfied for Op1(tj, R j ) to cause an anomaly to the maintenance for Op(ti, R i ). The two conditions in Lemma 1 are only necessary but not sufficient (see Proposition 1 below for a necessary and sufficient condition). In other words, local updates on R j that satisfy the two conditions have the potential to cause anomalies to the maintenance for Op(ti, R i ). Let potential anomaly(r j ; Op(ti; R i )) be the set of local counter values for those local updates on R j that satisfy the two conditions in Lemma 1. Suppose (ri, Cj, R j ) is the result message, returned from S j, of the maintenance query for Op(ti, R i ). Each time when the front-end starts the global view update process for Op(ti, R i ), potential anomaly(r j ; Op(ti; R i )) is computed to find out what local updates on R j could cause anomaly to the maintenance for Op(ti, R i ). potential anomaly(r j ; Op(ti; R i )) can be computed as fa gcounterr j a < Cjg, where a < Cj indicates that the local update on R j at S j with a local counter value equal to a (denote the local update as Op1(tj, R j )) occurred before the maintenance query for Op(ti, R i ) is evaluated; gcounterr j a indicates that the maintenance for Op1(tj, R j ) has not been processed completely just before the global view update corresponding to Op(ti, R i ) is about to start. With the above discussion, our maintenance algorithm can be refined as follows. The front-end sends a maintenance query for Op(ti, R i ) to S j. After the result message (ri, Cj, R j ) of the maintenance query is received, and the maintenance notification for Op(ti, R i ) appears at the head of queue EQ(V) (i.e., the maintenances for local updates related to V which are initiated before the maintenance for Op(ti, R i ) have been processed), the global view update process for Op(ti, R i ) is performed as follows: (i) compute potential anomaly(r j, Op(ti, R i )); (ii) check if the local updates whose corresponding local counter values appear in potential anomaly(r j, Op(ti, R i )) will cause real anomalies; (iii) perform necessary compensation to the query result if an anomaly is detected; (iv) update global view V according to the query result; (v) update gcounterr i. We now present a necessary and sufficient condition to detect the occurrence of each maintenance anomaly. Suppose the maintenance for local update Op(ti, R i ) from S i is being processed by the front-end, where Op could be delete or insert 1, ti of R i is the tuple involving the Op, Ci is the value of local counter attached to Op(ti; R i ). Suppose further the result message, (ri, Cj, R j ), of the maintenance query for Op(ti, R i ) has been received, and the notification (Op(ti, R i ), Ci, R i ) appears at the head of EQ(V). The frontend then starts to perform the global view update process w.r.t. Op(ti, R i ). Proposition 1. A local update Op1(tk; R k ) will cause an anomaly to the maintenance for Op(ti; R i ) if and only if the notification message corresponding to Op1(tk; R k ), say (Op1(tk; R k ), Ck, R k ), satisfies the following conditions: (1) R k = R j ; (2) ti./ tk 6= ; (3) P (ti./ tk) = true (i.e., the join of ti and tk satisfies the predicate condition P ); and (4) Ck is in the current potential anomaly(r j ; Op(ti; R i )). Proof: Necessity: (a) Since view V is integrated from R i and R j, any update to a local relation other than R j (i.e., condition (1) is not satisfied) will have no impact on the evaluation of the maintenance query for Op(ti, R i ). As a result, such an update will not cause any anomaly to the maintenance for Op(ti; R i ). Thus, condition (1) must be true. (b) If condition (1) is true but at least one of the conditions (2) and (3) is not satisfied, then Op1(tk, R k ) will have 1 To simplify the discussion, an update is considered as a deletion followed by an insertion.

6 user, it forwards the request to the associated local database system. If the request is an update, then after the local update is completed, the wrapper sends a maintenance notification message to the front-end. On the other hand, when a wrapper receives a maintenance query from the front-end, it forwards the query to the associated local database system. After the query is evaluated, the wrapper sends the result of the query back to the front-end. To synchronize the message transmission, each wrapper maintains a local counter lcounterr i for each local relation R i that contributes to the formation of a materialized global view. All local counters are initially set to one. Each time before the wrapper for a local database system S i sends a message (either a maintenance notification or the result of a maintenance query) related to a local relation R i to the front-end, it constructs a new message by attaching the current value of lcounterr i to the original message, and then sends the new message. For example, if the original message is M, then the new message would be (M, lcounterr i, R i ). In addition, if the message is a maintenance notification, the value of the local counter will be increased by one after the new message is sent out; if the message is the result of a maintenance query, the value of the local counter will not be changed. Note that, each time after a request (either a local update or a maintenance query) is received, the wrapper generates a new process to handle this request. Therefore, to prevent concurrent conflicting operations on local counters, some facilities for interprocess communication, like a read (or write) lock on a local counter, is required before the counter can be retrieved (or updated). For convenience, for the rest of the paper, we use messages sent out by a local database system to mean messages sent out by the wrapper associated with the local database system. The front-end also maintains a global counter gcounterr i and a maintenance index indexr i for each participating local relation R i. Each global counter and maintenance index also starts from one. gcounterr i is used to tell which maintenances for local updates on R i have been processed. The maintenance for a local update is processed completely (or simply processed) if the corresponding global view update (including necessary compensation) has been carried out by the front-end. When gcounterr i = n, it means that all maintenances for local updates on R i, whose corresponding notifications have local counter values smaller than n, have been processed completely by the front-end. gcounterr i is updated to n+1 if the maintenance for a local update on R i, whose notification has a local counter value equal to n, has been processed completely. indexr i is used to indicate which maintenance for a local update on R i can be initiated. The initiation of a maintenance for a local update is to form the maintenance query w.r.t. that local update and send the maintenance query to a relevant local database system. When indexr i = m, it means that the front-end will initiate the maintenance for the local update on R i, whose notification will have a local counter value equal to m. indexr i is updated to m+1 if the maintenance for a local update on R i, whose notification having a local counter value equal to m, has been initiated. Due to the network delay, the notification messages on R i may be received in an order different from the order in which they are delivered. If the notification for a local update on R i, received from S i, has a local counter value k which is greater than the current indexr i, then the front-end will save this notification into a waiting buffer. The maintenance for that local update will not be initiated until indexr i = k. Maintaining this indexr i is to ensure that the maintenances for local updates on the same local relation will be processed by the front-end in the same order as that those local updates are performed locally. Note that, each time after a notification message is received, the front-end also generates a new process to handle this new maintenance request. Therefore, locking is also employed by the front-end to control concurrent accesses to the data items, such as gcounterr i and indexr i for each R i. Since different maintenances to different materialized views will not interfere with each other, in our maintenance algorithm (details will be provided in Section 4) we only synchronize the maintenances for local updates w.r.t. the same materialized view. The front-end will process the maintenances for notifications to the same materialized view in a first-initiate-first-complete order. This has the following implications: For any two local updates lu1 and lu2 which will incur changes to the same view, if the front-end initiates the maintenance for lu1 before the maintenance for lu2, then (1) the front-end will form the maintenance query corresponding to lu1, say q1, and send q1 out before it forms the maintenance query corresponding to lu2, say q2, and sends q2 out; (2) the front-end will perform the global view update (including compensation if needed) w.r.t. lu1 before it performs the global view update w.r.t. lu2. Compensation is performed only when a real anomaly is detected. This can be enforced by maintaining an Execution Queue for each materialized view V (denoted by EQ(V)). After the maintenance for a local update, lui, w.r.t. V is initiated, the notification, mi, for lui is appended to the end of the queue EQ(V) before the maintenance query for lui is sent out. The global view update process w.r.t. lui, is not started until all maintenances for local updates whose notifications stored before mi in EQ(V) have been processed completely. As mentioned earlier, concurrent maintenance operations may interfere with each other and cause maintenance anomalies. We now provide a necessary condition for an anomaly to occur. For simplicity, we first consider a global view which is defined by the join of two local relations. Later on, in Section 5, we will discuss how to extend our maintenance algorithm for views defined by the join of two or more relations. Suppose V = p (R i./ R j ) is the mate-

7 Inserting a tuple t into V is carried out as follows: if t already exists in V, increase c(t) by 1; otherwise, add t into V and set c(t) to 1. Similarly, deleting a tuple t from V is carried out as follows: if c(t) > 1, decrease c(t) by 1; Otherwise, delete t and its associated c(t) from V. We adopt the counting approach in our discussions. Example 2: Unawareness of view maintenance anomaly S1 lu1 m1 (no compensation) gu1 q2 e2 r2 gu2 front-end q1 m2 time r1 S2 lu2 e1 Figure 3. Event sequence of Example 2 In Example 1, the deletion of t2 from R 2 (lu2 in Figure 2 and Figure 3) occurred before the maintenance query q1 is received by S 2. This causes a real anomaly to occur. According to the first-come-first-serve order, S 2 sends the deletion notification of t2 (m2 in Figures 2 and 3) to the front-end before it evaluates the query q1 (e1 in Figures 2 and 3) and sends the result (r1 in Figures 2 and 3) to the front-end. However, if the front-end receives r1 before it receives m2 due to the network delay on m2 (see Figure 3), then the anomaly will not be detected by the methods in [2, 13, 14] (i.e., lu2 would be thought to have occurred after the evaluation of q1). As a result, no compensation will be made by the front-end system for this anomaly. This is incorrect since a compensation that deletes (t1./ t2) from r1 is needed in this case. Example 3: False alarm of view maintenance anomaly S1 lu1 m1 e2 q2 gu2 front-end gu1 q1 r1 compensation : time e1 m2 delete J(t1, t2) S2 lu2 Figure 4. Event sequence of Example 3 Consider Example 1 again but with the following changes. Suppose there are 4 different derivations of tuple t in V, i.e. c(t) = 4. Suppose further the maintenance query q1 is received by S 2 before S 2 deletes t2 from R 2 (lu2 in Figure 4). According to the first-come-first-serve order, S 2 evaluates (e1 in Figure 4) the query q1 and sends the result (r1 in Figure 4) to the front-end before it deletes tuple t2 from R 2 and sends the deletion notification of t2 (m2 in Figure 4) to the front-end. This means that there is no real anomaly (i.e., the local update lu2 has no effect on the maintenance for lu1). Therefore, if the maintenances for m1 and m2 are carried out correctly, global view V should be modified by r2 decreasing c(t) by 1, i.e., c(t) = 3. However, if the front-end receives m2 before r1 due to the network delay on r1 (see Figure 4), then the front-end will deduce, incorrectly, based on the methods in [2, 13, 14], that an anomaly occurs (i.e., lu2 would be thought to have occurred before the evaluation of q1). Consequently, an unnecessary compensation that deletes (t1./ t2) from r1 will be carried out, and that will further decrease c(t) by 1 (i.e., the value of c(t) will become 2), resulting in an incorrect view maintenance. The above two examples illustrate that the compensation method proposed in [2, 13, 14] may handle maintenance anomalies incorrectly when it is possible for messages to be delivered and received in different orders. To overcome the problem, it is necessary to precisely detect the occurrence of each anomaly. This includes to detect all real anomalies and to identify all false anomalies. As a result, correct view maintenance can be achieved by compensating only real anomalies and ignoring false anomalies. In the next section, we present a method to precisely detect the occurrence of each anomaly even when it is possible for messages to be delivered and received in different orders across the network. A new maintenance algorithm for carrying out correct view maintenance will be discussed in Section Detection of Maintenance Anomaly In this section, we present a mechanism to synchronize the message (maintenance notification and query result) transmission from local database systems to the front-end system with the consideration of possible network delay. This mechanism can help the front-end system to detect each real anomaly precisely. In a multidatabase system, each local database system has its autonomy in managing its own local database. The responsibilities of local database systems in supporting view maintenance are to execute the requests from local database users and to answer the maintenance queries from the frontend system. The front-end system has no control on when a local database can be updated by local database users (e.g., the front-end can not lock a local database to prevent it from being updated when it is performing a view maintenance). Similarly, after sending a maintenance query to a local database system, the front-end system has no control on how the query will be processed and when the result will be sent back. All the front-end system can do are to precisely detect each anomaly and properly handle it once it occurs. Without compromising the autonomy of local database systems, we construct a synchronization wrapper for each local database system as the interface between local database users, the local database system, and the front-end system. When a wrapper accepts a request from a local database

8 will execute the local update and send the maintenance notification to the front-end before it evaluates the maintenance query from the front-end; (2) if a local database system receives a maintenance query on a base relation from the front-end earlier than a local update request to the same base relation, then the local database system will evaluate the maintenance query from the front-end before it executes the local update and sends the maintenance notification to the front-end. In general, we assume that locking is employed by each local database system to control concurrent accesses to data items. Specifically, a read (write) lock on a relation is required for the relation to be retrieved (modified). Example 1: View maintenance anomaly Consider the special case when the global view V is defined by the expression: (R 1./ R 2 ). Suppose a tuple t in V is formed from tuples t1 in R 1 and t2 in R 2. The following describes the interleaved steps of two incremental maintenance cycles (see Figure 2). S1 front-end S2 lu1 m1 q1 q2 m2 e1 e2 r1 gu1 r2 gu2 lu2 Figure 2. Event sequence of Example 1 time 1. A local deletion of t1 from R 1 (denoted by lu1) is made by S S 1 sends a notification, delete(t1, R 1 ) (denoted by m1), to the front-end containing the view V. 3. After receiving the notification, the front-end realizes that some modification has been made to R 1. The front-end forms a maintenance query, q1 = (t1./ R 2 ), and sends it to S 2 to find out what changes need to be made to V due to the deletion of t1 from R A local deletion of t2 from R 2 (denoted by lu2) is made before S 2 receives the query q1. 5. S 2 sends a notification, delete(t2, R 2 ) (denoted by m2), to the front-end system. 6. After receiving the notification delete(t2, R 2 ), the frontend forms a maintenance query, q2 = (R 1./ t2), and sends it to S 1 to find out what changes need to be made to V due to the deletion of t2 from R S 2 evaluates (denoted by e1) the maintenance query q1. 8. S 2 sends the result (denoted by r1) to the front-end system. Since t2 has been deleted from R 2, r1 will not contain t. 9. After receiving r1 from S 2, the front-end system removes the tuples that appear in r1 from V (denote this global update by gu1). Since t is not in r1, t will not be deleted from V. 10. S 1 evaluates (denoted by e2) the maintenance query q S 1 sends the result (denoted by r2), which will not contain t either, to the front-end. 12. After receiving r2 from S 1, the front-end system removes the tuples that appear in r2 from V (denote this global update by gu2). Again, t will not be deleted from V in this step. Clearly, the final result is incorrect since tuple t should be removed from V after the deletion of t1 and t2. In this example, a maintenance anomaly occurs to the maintenance for the local update lu1 since R 2 is updated (lu2 in Figure 2) by S 2 before S 2 evaluates (e1 in Figure 2) the maintenance query (q1 in Figure 2) sent from the front-end system, and the maintenance for lu2 has not been completed by the front-end before the global view update (gu1 in Figure 2) for lu1 is performed. When a maintenance anomaly occurs, a special measure is needed to correct the problem in order to guarantee that the materialized global view is consistent with the corresponding base relations. To tackle this problem, the front-end needs to compensate the error effect caused by the maintenance anomaly[2, 13, 14]. For instance, to correct the problem in Example 1, the frontend system can execute the compensation query (t1./ t2) and remove the result, which contains only tuple t, from V. The correctness of the approaches in [2, 13, 14] is based on the assumption that messages transmitted from one site to another site always keep their order, i.e., if a message is delivered earlier, then it must be received earlier. However, due to the unpredictable routing path and possibility of retransmission (we use the term network delay for the remaining discussion), it is possible that messages may be delivered and received in different orders. From our preliminary experimental results, we observed that on the average about 1% of all messages are delivered and received in different orders when a local area network is heavily loaded. In other words, the assumption made in [2, 13, 14] is not always realistic. In the following, we use two examples to show that network delay may cause serious problems for correctly detecting maintenance anomalies. More specifically, with network delay, it becomes possible for some real anomalies to go undetected and for some non-anomalies to be classified as anomalies. For the former, due compensation may be missed, and for the latter, wrong compensation may be carried out. Both cases may cause the materialized global view to be incorrectly maintained. Note that after materialization, duplicate tuples may appear in a global view. Since duplicate tuples often represent different derivations from the base relations, they should be kept in the view. Let t be a tuple in V which have k different derivations. Instead of storing t k times, the counting approach in [1, 6] stores t only once with an associated count value k. Let c(t) denote the count value of t. c(t) is stored with tuple t in the materialized view V. For example, suppose that a materialized view V, whose schema is (A, B), originally contains tuples f(1, 2), (1, 2), (3, 4)g. With the counting approach, the schema of V will be changed to (A, B, c(t)), and the tuples in V become f(1, 2, 2), (3, 4, 1)g.

9 in this case is to perform incremental view maintenance [1, 2, 4, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]. When a base relation is modified (i.e., some tuples are inserted, deleted or updated), this approach first identifies which portion of the materialized view is affected and then update that portion only. Consider a materialized global view V which is formed from two base relations R 1 and R 2 by a join. Suppose R 1 and R 2 reside at local database systems S 1 and S 2, respectively. A typical incremental view maintenance cycle can be described as consisting of the following six steps (see Figure 1). (1) A local modification (lu1) occurs, say some tuple in R 1 is modified by S 1. (2) S 1 sends a maintenance notification (m1) to the front-end. (3) Upon receiving m1 from S 1, the front-end realizes that some modification has been made to R 1. The front-end forms a maintenance query (q1) corresponding to the modification, and sends it to S 2 to find out what changes need to be made to V. (4) After q1 is received, S 2 evaluates (e1) the query. (5) S 2 returns the result (r1) to the front-end. (6) The front-end performs the global view update (gu1) using the result received from S 2. S1 lu1 m1 gu1 front-end q1 e1 r1 time S2 Figure1. 6-step incremental view maintenance The above approach works fine when different maintenance cycles for the same global view do not overlap. However, overlapping maintenance cycles may interfere with each other and result in incorrect maintenance (an example will be provided in Section 2). This phenomenon is called view maintenance anomaly [13]. In [13], the authors showed the possible occurrences of view maintenance anomalies. They also provided a method, named eager compensating algorithm (ECA), to solve the problem. However, if the base relations of a global view are continuously updated by a sequence of queries such that there is always a maintenance query that has been sent out but whose answer has not been returned, then no maintenance to the materialized view will be carried out by the ECA algorithm. Although this problem was later resolved by new maintenance algorithms provided in [14], their new maintenance algorithms may still fail to detect the occurrence of an anomaly, especially when messages may be sent and received in different orders. Currently, several transport protocols have been provided for communication over the Internet. Among them, two most referred ones are UDP (User Datagram Protocol) and TCP (Transmission Control Protocol). UDP is a connectionless and unreliable protocol which will not guarantee that messages sent will reach their intended destination. On the other hand, the connection-oriented and reliable protocol, TCP, guarantees that messages will eventually reach their destination, and the delivering and receiving orders of messages will be the same from the applications point of view as long as they are transmitted through the same connection. Unfortunately, if two messages are transmitted through two different connections, then it can t be guaranteed that the receiving order of the two messages will be the same as their delivering order due to network routing and delay in a distributed environment. Our experiments conducted on a prototype view maintenance system have confirmed this. As such, it is possible for a real anomaly to go undetected and for a non-anomaly to be wrongly identified as an anomaly (see examples in Section 2). In both cases, incorrect maintenance may be obtained. In this paper, we propose a synchronization method to precisely detect maintenance anomalies for views that are constructed by SPJ (Select-Project-Join) queries. The SPJ queries we consider are of the format: p (R 1./ R 2./.../ R n ), following the examples in [13, 14, 15], where is a set of projection attributes, p is a set of predicate conditions, and R i (i = 1,.., n) is the base relation from the local database system S i. We make no assumption about the delivering and receiving orders of messages across the network. In other words, our method will detect maintenance anomalies correctly even when messages are delivered and received in different orders due to network routing and delay. Although view maintenance has been discussed extensively in the literature [1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15], we are not aware of any other work that addresses the network delay issues. The rest of the paper is organized as follows. In Section 2, we use a number of examples to illustrate the existence of view maintenance anomalies, and how different message delivering and receiving orders can cause some anomalies to go undetected and some non-anomalies to be identified as anomalies. In Section 3, a synchronization method is proposed to precisely detect the occurrence of maintenance anomalies without making any assumption about the delivering and receiving orders of messages. In Section 4, we present an maintenance algorithm for handling a view defined by the join of two relations. The algorithm will also handle anomalies correctly. In Section 5, we will show how to extend our maintenance algorithm to the views defined by the join of two or more relations. Finally, the conclusion is given in Section View Maintenance Anomaly We assume that database requests for each local database system are queued and processed in a first-come-first-serve manner. This has the following implications: (1) if a local database system receives a local update request to a base relation earlier than a maintenance query on the same base relation from the front-end, then the local database system