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

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. enroll fee new fee enroll A2 paid fee all std type paid fee rollno payment std new std std new std 0..F 20..F 0..24 22..F 0..F 22.F 0..F 0..24 22..F 0..24 22..F (before) (after) (unaffected process)

12. Another way : create new STD table, move current data with defaults for category and modify fee enroll fee paid fee std type payment std 20..F 0..20 20..F 0..F 20..F 0..20 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