extending bcdm to support cooperative work
Post on 22-Jan-2016
32 Views
Preview:
DESCRIPTION
TRANSCRIPT
Extending BCDM to support cooperative work
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 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”: attribute (however, author cannot be modified)
13
Data Model (3/9)
Super user data
• Standard BCDM
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
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 on r
Property: uniqueness of representation
20
Manipulation operations
• E.g.: propose update
***
* Notice: value equivalent proposals for the same origin are not allowed
21
Manipulation operations
• E.g.: accept update proposal
***
• Notice: the alternatives of the selected updated are not allowed
22
Manipulation Operations
“two level” check on legal operations
• 1) Proposal Time– Super: <a, vt1>– Propose_update (x | <a, vt2>)
REJECTED
• 2) Evaluation Time
23
Manipulation operations
Property 1. Upward compatibility
Moreover, if Policy 1 is adopted:
Property 2. “Semantic” upward compatibility
24
Algebraic operations
• Standard BCDM algebraic operations for super-user and for pi and pd
• Conversion operations on pu:
origin(pu(r)) = { o \ <o, {a1,…, an}> pu(r)}
alternative(pu(r)) = Schema(r)BCDM({{a1,…, an} \
<o, {a1,…, an}> pu(r)}
25
Algebraic operations
E.g.: natural join:
***
26
Algebraic operations
Definition: conv
***
Property
conv( OpA( pu(r) ) ) = opBCDM( conv( pu(r) ) )
* Note: underlying possible implementation
27
Conclusions
• Problem of cooperative update is important
• New problem in DB field
• BCDM extended to support:– Data model– Manipulation operations– Algebra
• Upward compatibility
• Implementation
top related