A Semantic Framework for Supporting Cooperative Work in Relational Temporal Databases

transcript

Paolo Terenziani, Alessio Bottrighi, Stefania Montani

Dipartimento di Informatica, Univ. Piemonte Orientale, Alessandria, Italy

Luca Anselma,

Dipartimento di Informatica, Univ. Torino, Italy

Outline

• Introduction

• Goals and Criteria

• Data Model

• Manipulation operations

• Algebra

• Conclusions

Introduction (1/5)

Cooperative work:

• Important, e.g. software development

- Multiple alternative proposals

- Selection

• Software engineering tools

Introduction (2/5)

Cooperative work:

Analogous problems using DBs to model complex domains

Incremental modeling, cooperative work

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

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

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)

Goals (1/3)

• Extending BCDM to support cooperative updates

• Propose vs accept/reject

• Alternative proposals of updates

Notice: underlined implementation

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

Criteria (3/3)

•“Minimal” extension of BCDM:

– Upward compatibility (manipulation operations)

– Reducibility (algebra)

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

Data Model (2/9)

Authoring

Note: author as a data attribute

- Basically a “standard” data attribute (however, author cannot be modified)

Data Model (3/9)

Super user data

• Standard BCDM semantics

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))

Data Model (5/9) insert proposals

pi(r) is a set of standard BCDM tuples

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

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

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)

t<a1,T1>

<an,Tn>

………

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 )

Manipulation operations• E.g.: propose update(r,origin,old,new,VT)

<origin,old> identify the update proposal to be modified

IF origin=old a super-user tuple must be modified

t<a1,T1>

<an,Tn>

………

origin old

Manipulation operations• E.g.: propose update(r,origin,old,new,VT)IF admissible

IF ptpu(r) with origin(pt)=originTHEN add <origin, <new,user,UCVT>> in pu(r)IF ptpu(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 ptpu(r) with origin(pt)=origin a1 alternatives(pt)\ a1 value equivalent to ‘new’

user(a) = userTHEN add (UCVT) to the bitemporal of a1

* Notice: value equivalent proposals for the same origin are not allowed

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

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’>

Notice: the alternatives of the selected updated are no longer allowed

• E.g.: accept update proposalIF admissible

IF tr \ t value equivalent to origin current(t)THEN DELETE(t); INSERT(new); close UC to all alternative proposals

concerning originIF tr \ t value equivalent to origin current(t)

tpi(r) \ t value equivalent to origin current(t) THEN INSERT(new); close UC to all alternative proposals concerning origin

admissible: ptpu(r) with origin(pt)=origin newalternatives(pt) current(new) [( tr \ t value equivalent to new current(t)) t value equivalent to origin]

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>)(2) Propose_update (x | <a, vt3>)

Accept (1)Accept (2) REJECTED

Property 1.

Upward compatibility with BCDM

Moreover, if Policy 1 is adopted:

Property 2. “Semantic” upward compatibility

propose(OP)

accept

Our approach BCDM

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 \ ptpu(r) a alternatives(pt)} =

{(a1,…, an) \ <o, {a1,…, an}> pu(r)}

E.g.: natural join:r⋈A s = { z=<origin(z),alternatives(z)> \

IF pt1r , pt2s \ origin(pt1)[A]= origin(pt2) [A]

a1alternatives(pt1), a2alternatives(pt2) \ a1[A]=a2[A]

a1[T]a2[T]

origin(z)[A]=origin(pt1)[A] z[B]=origin(pt1)[B]

z[C]=origin(pt2)[C]

altalternatives(z), where alt[A]=a1[A]=a2[A] alt[B]=a1[B]

alt[C]=a2[C] alt[T]=a1[T]a2[T] }

Algebraic operationsDefinition: conv

conv(pu(r))={(a1,…,an,a’1,…,a’n,T)\

ptpu(r) \ (a1,…,an)=origin(pt)

(a’1,…,a’n)=alternatives(pt) }

<a1,T1>

<an,Tn>

………

Semantic level

Tnt an

T1t a1

… … …

Relational level

Property: reducibility (!?)

conv( OpA( pu(r) ) ) = OpBCDM( conv( pu(r) ) )

* Note: underlying possible implementation

Implementation (idea)

SEMANTIC Level IMPLEMENTATION(Data Abstraction)

PROPOSAL

RELATION

Accept Op

Propose Op

Algebraic Op

Accept Op

Propose Op

Algebraic Op

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

A Semantic Framework for Supporting Cooperative Work in Relational Temporal Databases

Documents