Recent research : Temporal databases

1. Recent research : Temporal databases N. L. Sarda nls@cse.iitb.ernet.in

2. 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

3. 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

4. Instant (40, E1~E2) E2 x E1 E3 10 30 • 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

5. 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

6. 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

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

8. 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

9. 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

10. 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

11. 0..F 0..F 0..F 0..F payment enroll paid fee fee 0..F rollno std (before) 0..F 0..24 0..F paid fee fee payment 20..F enroll rollno 0..24 22..F 22.F std new fee std type 22..F (after) new std 0..24 std all std A2 22..F new std (unaffected process)

12. Another way : create new STD table, move current data with defaults for category and modify fee 0..F 0..F 20..F 20..F paid fee payment enroll fee 20..F std std type 0..20 0..20 enroll 0..20 fee std • history components generated

13. 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