Embed Size (px)
Citation preview
Papers• Handling of alternatives and events in Temporal
databases– Intl Jour. Of Knowledge & Info Systems (KAIS), to
appear, 1999
• A framework for Application Evolution Management– 10th Australasian Database Conf, New Zealand, Jan.
1999
Handling alternatives and events• Future plans contain alternatives to deal with
uncertainties• should be part of DB for evaluation/comparisons• Temporal DBs do not support alternatives• We propose a model based on events, branching in
time and actions for handling different outcomes of events
• Event : a critical happening with multiple outcomes; an event may depend on outcomes of other events; defined by an event expression
• action : affect state of entities
E1
E2
E3
x
10
30
Instant (40, E1~E2)
• DB entities may have different states along different paths• real-world time follows a path• actions have an occurrence time and affect some entities• events may be unrelated too; multiple event trees• all events can be superimposed in a single tree
Time and data model• Branching cronon : (v, e) where v is linear time
value and e is an event expression• branching element ( a set of cronons) and interval• Conceptual (BT) temporal relation : a set of
explicit attributes and an implicit branching element, defining state at those points
• Operations : – EXPAND : define validity over same set of events
– update operations : insert, delete, update
– algebra : time-slice, selection, projection, join, etc
Efficient representation• Conceptual relation not in 1NF• a tuple could define a state over a branch or
sequence of branches along a path : branch-explicit or change-explicit representation
• Coalesce operation• Extension to TSQL2 : for event definition, time
domain, schema definitions => natural extension• Handling uncertainty in event occurrence times
and in different probabilities of outcomes• prototype implementation
Application Evolution• Components of an application : schema, time-
varying DB, and processing code• DBMS manages schema and DB• Applications evolve where both schema and
processing change; history of both required• Examples :
– new tuition fees from 1998 based on student type
– new consultancy rules (fixed rates to slab rates)
• Implications : schema changes, DB transformations, changes to processing; old and new rules need to coexist => considerable maintenance activity
Schema evolution• Well researched in OO context : exploit
inheritance and views• Limited facilities in relational DBs• Bi-temporal schema evolution to support proactive
and retroactive changes, single/multi-pool data storage, (a)synchronous validity
• Important to maintain temporal consistency between schema, data and processing => need for application evolution framework
Framework• Schema and processing change often together• changes have temporal validity• old and new processing rules often overlap;
selection based on some temporal characteristic of involved entities
• Proposed AMS framework contains :– a set of activities
– a set of processes
– database and a set of views
– entities
– bridge specifications for mapping schema versions
Framework ...• All components have unique ids and temporal
validities, although no specific temporal relationship between them prescribed
• by default, current components accessed• formulate policy for change implementation wrt
schema changes, data transformations, process changes and bridge specifications
• Example : change in fees based on student type :– add ‘category’ attribute to STD table
– define new ‘fee’ process
– modify ‘enroll’ activity to choose ‘fee’ based on start-time of student entity
enroll fee
fee
newfee
enroll
A2
paidfee
allstd
stdtype
paidfee
rollno
rollno
payment
payment
std
std
new std
std
new std
0..F0..F 0..F0..F
20..F
0..24
22..F
0..F
22.F
0..F
0..F
0..24
22..F
0..24
22..F
(before)
(after)
(unaffected process)
• Another way : create new STD table, move current data with defaults for category and modify fee
enroll
enroll
fee
fee
paid fee
stdtype
payment
std
std
20..F
0..20
0..20
20..F0..F 0..F
20..F
0..20
• history components generated
Conclusions
• Modeling events and alternatives important in all planning applications
• Application management goes beyond data management; addresses application evolution
• history (warehouse ?) of both data and processing important
