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. * Guideline to be stored in a DB
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 specialize E.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. Data Model (8/9) update proposals
Definition: proposal tuple
An origin
A non empty set of (bi)temporal tuples t
<a1,T1>
<an,Tn>
………
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. Manipulation operations
E.g.: propose update(r,origin,old,new,VT)
<origin,old> identify the update proposal to be modified
origin
old t
<a1,T1>
<an,Tn>
………
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)
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. Manipulation operations
Property 1.
Upward compatibility with BCDM
Moreover, if Policy 1 is adopted:
Property 2. “Semantic” upward compatibility
propose(OP)
accept OP
Our approach
BCDM

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. 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) } t
<a1,T1>
<an,Tn>
………
Semantic level Tn t an T1 a1 …
Relational level
conv

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

31. Implementation (idea)
(Data Abstraction)
SEMANTIC Level
PROPOSAL
RELATION
Conv
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