A Semantic Framework for Supporting Cooperative Work in Relational Temporal Databases

1. A Semantic Framework for Supporting Cooperative Work in Relational Temporal Databases Paolo Terenziani, Alessio Bottrighi, Stefania Montani Dipartimento di Informatica, Univ. Piemonte Orientale, Alessandria, Italy Luca Anselma, Dipartimento di Informatica, Univ. Torino, Italy

2. Outline • Introduction • Goals and Criteria • Data Model • Manipulation operations • Algebra • Conclusions

3. Introduction (1/5) Cooperative work: • Important, e.g. software development - Multiple alternative proposals - Selection • Software engineering tools

4. Introduction (2/5) Cooperative work: Analogous problems using DBs to model complex domains Incremental modeling, cooperative work

5. Introduction (3/5) The case of clinical guidelines: • General guideline proposed by a standardization committee • Proposals of update • Local contextualization • New therapies • Evaluation of proposals * Guideline to be stored in a DB

6. Introduction (4/5)Open issues Augmenting DB approaches to support cooperative work, i.e.: • Distinction between two phases: proposals and acceptance/rejection • History of the evolution of the proposals • Alternative proposals * Notice: usual semantics of (relational) DBs, conjunction of tuples

7. Introduction (5/5)Context • Both VT and TT should be supported • “Consensus” approach (TSQL2) with a high-level semantics (BCDM) • BCDM supports several TDB implementations (not only TSQL2)

8. Goals (1/3) • Extending BCDM to support cooperative updates • Propose vs accept/reject • Alternative proposals of updates Notice: underlined implementation

9. Criteria (2/3) • Under-constrained policy: • Super user vs user • Super user operations:standard + accept/reject proposals • User operations: • delete (not proposals) • Insert • Update (chains allowed) * Notice: easy to specializeE.g.: policy 1: super users can only accept/reject

10. Criteria (3/3) • “Minimal” extension of BCDM: • Upward compatibility (manipulation operations) • Reducibility (algebra)

11. Data Model (1/9) Two data levels needed: • Super users (accepted) data • User proposals * Notice: proposals need to be maintained and affect super-user data only if/when accepted

12. Data Model (2/9) Authoring Note: author as a data attribute - Basically a “standard” data attribute (however, author cannot be modified)

13. Data Model (3/9) Super user data • Standard BCDM semantics

14. Data Model (4/9)user proposals For each super-user relation r: • pi(r):set of insert proposals in r • pd(r):set of proposals of deletion of tuples in r • pu(r):set of updates of tuples (in r, pi(r), pu(r))

15. Data Model (5/9)insert proposals pi(r) is a set of standard BCDM tuples

16. Data Model (6/9)delete proposals pd(r) is a set of standard transaction-time tuples * Notice: no value-equivalent data in r VT not needed

17. Data Model (7/9)update proposals Update involves: • An origin tuple to be updated (time not needed) • A new temporal tuple (standard BCDM tuple) * Notice: multiple update proposals involving the same origin are in alternative

18. <a1,T1> t ……… <an,Tn> Data Model (8/9)update proposals Definition: proposal tuple • An origin • A non empty set of (bi)temporal tuples Semantic interpretation: disjunctive set of alternative proposals (each one is a BCDM tuple)

19. Data Model (9/9)update proposals pu(r) is a set of proposal tuples Property: uniqueness of representation (two Proposal-relations defined over the same schema are snapshot equivalent iff they are identical)

20. <a1,T1> t ……… <an,Tn> Manipulation operations • E.g.: propose update(r,origin,old,new,VT) <origin,old> identify the update proposal to be modified origin old IF origin=old a super-user tuple must be modified

21. Manipulation operations • E.g.: propose update(r,origin,old,new,VT) IF admissible IF  ptpu(r) with origin(pt)=origin THEN add <origin, <new,user,UCVT>> in pu(r) IF  ptpu(r) with origin(pt)=origin  ( a1  alternatives(pt)\ a1 value equivalent to ‘new’ OR  a1  alternatives(pt)\ a1 value equivalent to ‘new’  user(a) user) THEN add ‘new’ to alternatives(pt) IF  ptpu(r) with origin(pt)=origin   a1  alternatives(pt)\ a1 value equivalent to ‘new’  user(a) = user THEN add (UCVT) to the bitemporal of a1 * Notice: value equivalent proposals for the same origin are not allowed

22. Manipulation operations ADMISSIBILITY OF PROPOSE UPDATE OP. origin: in r or in pi(r) & current old: old (old=origin OR old origin) & current new: ( tuple t r & current & t value equivalent to ‘new’  t value equivalent to origin) &  proposal value equivalent to t with same VT

23. Manipulation operations ADMISSIBILITY OF PROPOSE UPDATE OP. Condition on ‘new’: example r: {<a,Ta>,<b,Tb>,…..} (r is a super-user relation) Admissible update: a  <a,T’> NOT admissible: b  <a,T’>

24. Manipulation operations • E.g.: accept update proposal • IF admissible • IF  tr \ t value equivalent to origin  current(t) • THEN DELETE(t); INSERT(new); close UC to all alternative proposals concerning origin • IF  tr \ t value equivalent to origin  current(t)  •  tpi(r) \ t value equivalent to origin  current(t) • THEN INSERT(new); close UC to all alternative proposals concerning origin • admissible:  ptpu(r) with origin(pt)=origin  newalternatives(pt)  current(new)  [( tr \ t value equivalent to new  current(t))  t value equivalent to origin] Notice: the alternatives of the selected updated are no longer allowed

25. Manipulation Operations “two level” check on legal operations • 1) Proposal Time • Super: <a, vt1> • Propose_update (x | <a, vt2>) REJECTED • 2) Evaluation Time • Super: <y, vt3>, <x, vt4> (1) Propose_update (y | <a, vt2>) • Propose_update (x | <a, vt3>) Accept (1) Accept (2) REJECTED

26. propose(OP) accept OP Our approach BCDM Manipulation operations Property 1. Upward compatibility with BCDM Moreover, if Policy 1 is adopted: Property 2. “Semantic” upward compatibility

27. Algebraic operations • Standard BCDM algebraic operations for super-user and for pi and pd • Conversion operations on pu: origin(pu(r)) = {o \ pt pu(r)  o origin(pt)} = { o \ <o, (a1,…, an)>  pu(r)} alternatives(pu(r)) = {a \ ptpu(r)  a alternatives(pt)} = {(a1,…, an) \ <o, {a1,…, an}>  pu(r)}

28. Algebraic operations E.g.: natural join: r⋈A s = { z=<origin(z),alternatives(z)> \ IF $pt1Îr, $pt2Îs \ origin(pt1)[A]= origin(pt2) [A] Ù $a1Îalternatives(pt1), $a2Îalternatives(pt2)\ a1[A]=a2[A] Ù a1[T]a2[T]  THEN origin(z)[A]=origin(pt1)[A] Ù z[B]=origin(pt1)[B] Ù z[C]=origin(pt2)[C] Ù altÎalternatives(z), where alt[A]=a1[A]=a2[A] Ù alt[B]=a1[B] Ù alt[C]=a2[C] Ù alt[T]=a1[T]a2[T] }

29. <a1,T1> t ……… Semantic level <an,Tn> Relational level t a1 T1 conv … … … t an Tn Algebraic operations Definition: conv conv(pu(r))={(a1,…,an,a’1,…,a’n,T)\ ptpu(r) \ (a1,…,an)=origin(pt)  (a’1,…,a’n)=alternatives(pt) }

30. Algebraic operations Property: reducibility (!?) conv( OpA( pu(r) ) ) = OpBCDM( conv( pu(r) ) ) * Note: underlying possible implementation

31. Conv Implementation (idea) IMPLEMENTATION (Data Abstraction) SEMANTIC Level PROPOSAL RELATION Accept Op Propose Op Algebraic Op Accept Op Propose Op Algebraic Op

32. Conclusions • Problem of cooperative update to DB’s is important • New problem in DB field • Semantic approach extending BCDM to support (1) proposal\evaluation & (2) alternative proposals • Data model • Manipulation operations • Algebra • Upward compatibility\reducibility • Easy Implementability