1. Temporal Data Modeling
N. L. Sarda
IIT Bombay

2. Temporal Data Modeling
All activities have context of time
No explicit support from database systems
Approaches
Schema for current data
Past data in archived, not accessible thru DB schema
Or, include history explicitly by time-stamping
Alternative : provide support for temporal data

3. Applications Administrative – personnel, accounting, …
Medical applications
Insurance
Reservation systems
Planning, …

4. Conventional way Add attributes for time, its granularity, meaning
Write statements differently
Explicitly co-relate data over time
Example : Emp table with FROM and TO columns to indicate employment data period
Emp (Eno, Dno, Salary, Rank, From, To)
Insert new emp : what value for To ?
Get current salary of Mahesh
Change salary of Mahesh : no UPDATE st !
Another table Dept : how to find when Mahesh worked in Toy department

5. Time : Semantics and representation
Many clocks (a physical process that ‘measures’ time) and representations exist
Day clock, year clock, etc
Representations differ in range, granularity, storage size, efficiency of operations
Models of time
continuous, discrete
Linear or branching
Basic units : instant, interval (unanchored), span
Temporal element : as a set of instants on spans
Operations on time : arithmetic, comparisons on instants and intervals (+, <, overlaps, …)
Calendar notion – human interpretation; defines new units and constants
Gregorian calendar most common

6. Time dimensions Different interpretations Basic dimensions: Orthogonal
Real-world or valid time
System or transaction time
Orthogonal
Leads to 4 basic database types :
No time : snap-shot DBs
Only valid time : historical DBs
Only transaction time : Rollback DBs
Both : Bi-temporal DBs

7. Transaction time DBMS records system time with data
System time advances automatically : represent by UC
Example : insert Mohan with 10K salary at system time 15
System is aware of this fact, and continues to ‘know’ it from 15 onwards (until changed)
Tuple <Mohan, 10K, 15, TC> captures this
Removing (deleting) this (at time 35) means this data is not ‘known’ to system anymore after 35. Example :
<Mohan, 10K, 15, 35>
<Mohan, 12K, 36, UC>
We can rollback system time

8. Valid Time Is External for the system
Defines real-world validity of data
Data can be past, current or future with respect to current time
<Mahesh, 10K, , >
Updates change valid time stamp
Some facts may be valid now and in future
Use NOW as a ‘moving’ time variable

9. Bi-temporal data model
Each fact is associated with both times
Effectively, system stores everything and never forgets anything !
A tuple in pure Bi-temporal model contains a set of bi-temporal ‘cronons’ telling when the fact was valid and when it was known to the system
A 2-dim temporal space
A fact represented by graph/area in this space
Example {time by (valid, tran time) pairs}
<Mahesh, CSE, {(5,7), (5,9), (5,10), (6,7), …>

10. Update semantics Need to be clearly understood for insert, delete
Insert <Meera, CSE> valid over <15..25>:
This fact exists and is current >> reject !
Does not exist at all : add with tran time UC which will keep expanding
Exists but not current : merge with newer cronon values
Need to be carefully implemented

11. Choosing interval-based representation
The conceptual model uses temporal element
Not normalized and in-efficient
Use valid and tran time intervals with a fact
<Mahesh, CSE, (15..35), (20..UC)>
Define update semantics carefully
At tran time 28, we find that Mahesh was in fact in EE during valid time 21 to 24
Updating should now give us the following
<Mahesh, CSE, (15..35), (20..27)>
<Mahesh, CSE, (15..20), (28..UC)>
<Mahesh, EE, (21..24), (28, UC)>
<Mahesh, CSE, (25..35), (28, UC)>
Need to split intervals carefully

12. Temporal Normalization
A table now contains user defined and temporal attributes
Time applies to the whole tuple
User defined attributes may have different rates of change, and every change produces ‘history’
Better to decompose a relation based on rate of change
Salary changes more frequently than Dept
Split Emp (Eno, Salary, Dept) into 2 relations

13. Temporal algebra and query language
Algebra defines how time to be considered
Usual selection, projection, etc can be defined
Product gives two timestamps >> not a temporal relation !
Join should relate data with overlapping validity and currency
R JOIN S : check that tuple r in R and s in S have overlapping valid time and they are both current
Result should contain intersection of time elements
Exact definition will depend on representation

14. Coalesce operation
Interval based representation, while simpler to understand and implement, requires time intervals across result tuples to be compacted
Coalesce operation produces tuples with proper time intervals
Bitemporal tuple has a rectangular time element
Projection, union, etc requires 2 rectangles to be converted into multiple tuples with proper rectangular regions

15. Event Vs Interval semantics
An application may choose to represent events or states of entities : salary change or salary interval
<Mohan, 10K, 15> <Mohan, 10K, >
<Mohan, 15K, 27> <Mohan, 15K, 27..NOW>
Maybe done for both time dimensions
Algebra and query language will need to be oriented towards a specific representation

16. Choosing a representation
Literature has suggested many representation
Tuple level time stamping Vs attribute level time stamping
Event or interval or set of these
Entity level or tuple level
Entire history in a single tuple
One tuple gives full history across all attributes
Each attribute is multi-valued, each value tome-stamped
<e21, Mohan, {(10K, 15) (12K, 27)}, {(CSE, 10),(EE, 18)}>

17. Modeling Temporal Entities
Entity has key and a set of attributes
Temporal entities have ‘lifespan’, non-changing key (or, surrogate)
Identify non-temporal (non-changing) and temporal attributes
Attribute values also have a time stamp
Contained in the lifespan of the entity
Modeling using valid time characteristics
How much change an entity can ‘tolerate’ ?
Application dependent issue

18. Modeling Temporal Relationships
Relationship also has a lifespan
May have changing temporal attributes
Mohan works in CSE at various points in time in different roles (student, programmer, faculty)
Works relationship with attribute Role and valid time interval
Relationship instance validity must be contained in the lifespan of the entities it relates
Temporal characteristics can be associated with inheritance and aggregation relationships also

19. Exercise !
Consider student, course, registrations as per the bulletin, etc
Courses are modified
Bulletins change every few years and may overlap
Students repeat courses when they fail
Students change departments, may get credits for a few course, may have a special schedule (==bulletin !)

20. Summary Time is ubiquitous Requirements must be understood clearly
Ad hoc solutions create problems
Specialized representations and query languages simplify time management