1. Grigoris Karvounarakis Zachary G. Ives University of Pennsylvania Bidirectional Mappings for Data and Update Exchange WebDB 2008

2. 2 ● Each peer has a local instance ● Relate peers by schema mappings ● Support update exchange according to different administrator policies Collaborative Data Sharing Systems [CIDR05] DBMS Queries, edits PUBLISH ∆ B +/− ∆ C +/− Peer A Peer B Peer C ∆ A +/−

3. 3 T T Unidirectional update exchange ● O RCHESTRA [ SIGMOD06,VLDB07 ]: ▪ Each mapping (tgd[ Fagin+03 ]/GLAV[ Lenzerini02 ]) has source and target peers ▪ Propagate effects of updates forward, to target ● Related to view maintenance (1,2) U U m1m1 m2m2 (1,3) + m2m2 m 1 : R (xy) Æ S(yz) ! T(xyz) m 2 : T(xyz) ! U(xyz) (1,2) (1,3) – R R (1,2) + S S (2,3) +

4. 4 Bidirectional mappings and update exchange ● Goal: Tighter coupling between peers ▪ Both forward and backward propagation of updates (insertions/deletions) along mappings ▪ E.g., for mirroring of content between peers ● Our contributions: ▪ Language for specifying bidirectional mappings and update policies (for backwards propagation of deletions) ▪ Algorithms for propagation of updates in both directions and for propagation with detection and prevention of side effects [Dayal+82] at run-time ▪ Experimental evaluation, illustrating feasibility

5. 5 m 1 :T(xyz) Æ V(wx) ! R(xy) Æ S(xzw) S Bidirectional update exchange: insertions R (3, 3, 5) T (1, 1, 1) (1, 1, 2) (3, 2, 3) + (1, 1, 4) (1, 2, 4) + (1, 1) + (3, 2) m1m1 m1m1 m1m1 m 1 :R(xy) Æ S(xzw) $ T(xyz) Æ V(wx) U (1, 1, 1) (1, 1, 2) (3, 2, 3) m2m2 m2m2 m2m2 + + m 2 :T(xyz) $ U(xyz) m 1 :R(xy) Æ S(xzw) ! T(xyz) Æ V(wx) m 2 : U(xyz) ! T(xyz) m 2 : T(xyz) ! U(xyz) V (4,1) (5,3) +

6. 6 Propagating deletions to source tuples ● Need to track down and delete source tuples from which deleted ones were derived ● Multiple options for propagating updates backwards over joins ● User specified update policies resolve this ambiguity: ● Guaranteed to perform any deletion, as long as there is at least one * in each side R (xy) Æ S(xzw) $ T(xyz) Æ V(wx) **

7. 7 S Bidirectional update exchange: deletions R (3, 3, 5) T (1, 1, 1) (1, 1, 2) (3, 2, 3) + (1, 1, 4) (1, 2, 4) + (1, 1) + (3, 2) m1m1 m1m1 m1m1 m 1 : * R(xy) Æ S(xzw) $ T(xyz) Æ * V(wx) U (1, 1, 1) (1, 1, 2) (3, 2, 3) m2m2 m2m2 m2m2 + + m 2 : * T(xyz) $ * U(xyz) V (4,1) (5,3) + (1, 1, 2) (3, 3, 5) (1, 1, 2)

8. 8 S Avoiding side effects on T R (3, 3, 5) T (1, 1, 1) (1, 1, 2) (3, 2, 3) + (1, 1, 4) (1, 2, 4) + (1, 1) + (3, 2) m1m1 m1m1 m1m1 m 1 : * R(xy) Æ S(xzw) $ T(xyz) Æ * V(wx) U (1, 1, 1) (1, 1, 2) (3, 2, 3) m2m2 m2m2 m2m2 + + m 2 : * T(xyz) $ * U(xyz) V (4,1) (5,3) +

9. 9 Experimental evaluation ● Implementation strategy: Mappings -> Datalog programs -> SQL + fixpoint ▪ Java layer over RDBMS (DB2) ● Synthetic update workload sampled from SWISS- PROT biological data set ▪ Randomly-generated schemas and mappings ▪ 2000 initial tuples in each peer before propagation ● Questions: ▪ Overhead of bidirectional over unidirectional (in paper) ▪ Feasibility of deletion propagation and overhead of side effect detection

10. 10 Propagation of 10% dels is feasible for 5 peers

11. 11 Related work ● Data exchange [Haas+99, Miller+00, Popa+02, Fagin+03, Hernich+07], peer data exchange [Fuxman+05] ● View update [Dayal+82, Bancilhon+81], Harmony [Bohannon+06], [Matsuda+07] ● Incremental view maintenance [Gupta+93] ● Peer data management systems (PDMS) Piazza[Halevy+03,04],Hyperion[Kementsietsidis+04], [Bernstein+02], [Calvanese+04],...

12. 12 Conclusions and future work ● Contributions: ▪ Bidirectional mappings for update exchange between peers that want closer collaboration ▪ Combine forward and backward propagation to compute peer instances incrementally ▪ Incorporate update policies for backward propagation ▪ Dynamic detection and prevention of side effects ● Future work: ▪ Combine unidirectional and bidirectional mappings, to also guarantee that all initial deletions are performed ▪ Study opportunities for performance optimization