Recent research : Temporal databases

1
Recent research Temporal databases

• N. L. Sarda
• nls_at_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
E2
Instant (40, E1E2)
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 gt 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 gt 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 gt 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