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