extending bcdm to support cooperative work

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