1. Copyright © C. J. Date 2005page 1 AGENDA : 1. A few preliminaries 2. Laying the foundations 3.Building on the foundations

2. Copyright © C. J. Date 2005page 2 OBJECTIVES OF THIS PRESENTATION : l Time dimension is becoming increasingly important —especially in data warehouse context l No one has done it right yet! l We’re lobbying to get it done right... "If you do it the stupid way, then you’ll have to do it again" (Gregory Chudnovsky) l In particular: The relational model is THE RIGHT AND PROPER FOUNDATION for temporal support Requires NO extension / revision / violations!

3. Copyright © C. J. Date 2005page 3 THE RUNNING EXAMPLE : SUPPLIERS AND SHIPMENTS (nontemporal version—sample values) : SS#SNAMESTATUSCITYSPS#P# S1Smith20London S2Jones10Paris S3Blake30Paris S4Clark20London S5Adams30Athens Note supplier S5 in particular Potential shipments: Supplier Sx is currently able to supply part Py S1P1 S1P2 S1P3 S1P4 S1P5 S1P6 S2P1 S2P2 S3P2 S4P2 S4P4 S4P5

4. Copyright © C. J. Date 2005page 4 DB consists of relation variables or RELVARS Relvar value at any time = RELATION Relvar represents a PREDICATE Tuples represent PROPOSITIONS Relvar at time t contains ALL AND ONLY the tuples that represent TRUE propositions (= true "instantiations" of corresponding predicate): CLOSED WORLD ASSUMPTION (CWA) Double underlining used in figures to indicate primary key attributes

5. Copyright © C. J. Date 2005page 5 FOR EXAMPLE : relvar atsame relvar time t1at time t2 SPS#P#SPS#P# S1P1S1P1 S2P1S2P1 S3P2 relations Predicate:Supplier S# is able to supply part P# Propositions:Supplier S1 is able to supply part P1 (etc.)

6. Copyright © C. J. Date 2005page 6 AGENDA : 1. A few preliminaries 2. Laying the foundations 3.Building on the foundations

7. Copyright © C. J. Date 2005page 7 2. LAYING THE FOUNDATIONS : Z Time and the DB What’s the problem? Intervals Interval operators The EXPAND and COLLAPSE operators The PACK and UNPACK operators Relational operators

8. Copyright © C. J. Date 2005page 8 TEMPORAL vs. NONTEMPORAL DATABASES : l Nontemporal DB (i.e., DB as conventionally understood— sometimes unfortunately called a "snapshot DB"): Current data only—e.g., status of supplier S1 is currently ("now") 20 l Temporal DB: Historical data instead of or as well as current data —e.g., status of supplier S1 is currently 20 AND has been 20 ever since July 1st AND was 15 from April 5th to June 30th (etc., etc.) If no DELETE or UPDATE then historical data only (as in some data warehouses)

9. Copyright © C. J. Date 2005page 9 WHY ARE TEMPORAL DATABASES BECOMING IMPORTANT ? l Cheap disk storage means we can now store large volumes of historical data (data warehouses again) l Direct consequence: Users beginning to be faced with temporal DB problems … and they want solutions!  A note on the research (there’s been some controversy): l Two approaches: Treat temporal data as special and depart from relational principles? … OR … Abide firmly by those principles? Fortunately, the good guys won!

10. Copyright © C. J. Date 2005page 10 CAVEAT : Various questions regarding nature of time—e.g., l Does time have a beginning or an end? l Is time a continuum or is it divided into discrete quanta? l How can we best characterize the concept now (aka "the moving point now")? —aren’t really DB questions as such! So we won’t try to answer them definitively, but just make what we hope are reasonable assumptions as we proceed...

11. Copyright © C. J. Date 2005page 11 NOTE, HOWEVER, THAT (important!) : l The (good) temporal DB research has led to certain INTERESTING GENERALIZATIONS … l We’ll be touching on some of those generalizations from time to time l However, we follow convention in referring to (e.g.) "temporal" ops, "temporal" relations, etc., even though the concepts are often not exclusive to temporal data as such We also take "history" to include the future, where approp

12. Copyright © C. J. Date 2005page 12 SOME TENTATIVE DEFINITIONS : l If data = encoded representation of propositions, then temporal data = encoded representation of timestamped propositions … l Temporal relation:relation in which each tuple includes at least one timestamp (i.e., heading includes at least one attrib of some timestamp type) l Temporal relvar:relvar whose heading is that of a temporal relation l Temporal DB: DB in which all relvars are temporal

13. Copyright © C. J. Date 2005page 13 BUT … !!! "Temporal DB" concept as just defined isn’t very useful! (Why not?) So … from this point forward, we take a temporal DB to be a DB that includes but is not limited to temporal relvars  Note:With one exception, all of the new ops and other constructs to be discussed are just shorthand! Exception = INTERVAL type generator (see later)

14. Copyright © C. J. Date 2005page 14 CONSIDER THIS 2-TUPLE : S#FROM S1July 1st, 1999 Possible interpretations include: T1:Supplier S1 was placed under contract on July 1st, 1999 T2:Supplier S1 has been under contract since July 1st, 1999 T3:Supplier S1 was under contract during the interval from July 1st, 1999, to the present day

15. Copyright © C. J. Date 2005page 15 TIMESTAMPED PROPOSITIONS : Any of T1, T2, T3 could be intended interpretation, depending on applicable predicate Prepositions on, since, and during characterize the three interpretations  l On= "at some instant" (not very interesting) l Since= "ever since" l During= "throughout (the interval in question)"

16. Copyright © C. J. Date 2005page 16 TIMESTAMPED PROPOSITIONS (cont.) : But don’t T1, T2, T3 really all say the same thing? Well … they need to be tightened up! T1:Supplier S1 was most recently appointed on July 1st, 1999 (but the contract might subsequently have been terminated) T2:Supplier S1 was not under contract on June 30th, 1999, but has been so ever since July 1st, 1999 T3:Supplier S1 was not under contract on June 30th, 1999, but has been so during the interval from July 1st, 1999, to the present day T2 and T3 are equivalent to each other but not to T1

17. Copyright © C. J. Date 2005page 17 TIMESTAMPED PROPOSITIONS (cont.) : T2 and T3 are logically equivalent but significantly different in form … Reverting to simpler versions for brevity: T2:Supplier Sx has been under contract since date d T3:Supplier Sx was under contract during the interval from date b to date e l Form of T3 can be used for historical records! —which do usually involve intervals l Concept of DURING is important (all-pervasive)

18. Copyright © C. J. Date 2005page 18 "VALID TIME" vs. "TRANSACTION TIME" : l Can historical data be updated ??? l Well … "historical data" in the DB represents, not history as such, but rather our beliefs about that history … and beliefs can change Valid time for p :set of times at which (updatable)(by our current knowledge) p is/was/will be true Transaction time for q:set of times at which q is (not updatable)represented in DB as true

19. Copyright © C. J. Date 2005page 19 FOR EXAMPLE : Let p be "Supplier S1 was under contract" Suppose we currently believe this state of affairs held from July 1st, 1999, until May 1st, 2000, so we insert: S#FROMTO S1July 1st, 1999May 1st, 2000 l This tuple does not correspond to proposition p! —but to a timestamped extension of p l FROM/TO represents "valid time" for p—time when (according to our current beliefs) p represented a "true fact"

20. Copyright © C. J. Date 2005page 20 Later we discover date of appointment was June 1st, so we "update the tuple" S#FROMTO S1June 1st, 1999May 1st, 2000 l Changes "valid time", not p! Later we discover S1 was never under contract at all and therefore delete the tuple—p now known to be false and has no "valid time" at all

21. Copyright © C. J. Date 2005page 21 Suppose tuple was INSERT’d at time t1 UPDATE’d at time t2 DELETE’d at time t3 Interval from t1 to t3 = "transaction time"—not for p, but for proposition "p was true throughout some interval"  Interval from t1 to t2 = "transaction time" for timestamped extension of p with timestamp July 1st, 1999 - May 1st, 2000 Interval from t2 to t3 = "transaction time" for timestamped extension of p with timestamp June 1st, 1999 - May 1st, 2000 We will revisit these concepts later...

22. Copyright © C. J. Date 2005page 22 OBVIOUS BUT FAR-REACHING ASIDE : interval with begin time b and end time e can be thought of as set of all times t such that b < t < e (where "<" means "earlier than")

23. Copyright © C. J. Date 2005page 23 SOME FUNDAMENTAL QUESTIONS : Doesn’t "all times t such that b < t < e" mean we’re dealing with infinite sets? l Assumption: Timeline =finite sequence of discrete, indivisible time quanta Time quantum =smallest time unit representable in the system or chronon

24. Copyright © C. J. Date 2005page 24 Propositions T1-T3 seem to assume time quanta are days … Doesn’t the system support time units down to (e.g.) microseconds? If S1 was appointed on July 1st, what do we do about the interval from the beginning of July 1st up to the very instant of appointment? l Distinguish time quanta vs. time units relevant for some particular purpose (e.g., years, months, days, msecs) = time points aka "points" aka "granules” l Granularity = "size" of applicable time points = "size" of gap between adjacent points

25. Copyright © C. J. Date 2005page 25 If we regard the timeline (for some given purpose) as a finite sequence of time points, each time point has a unique successor and a unique predecessor—right? l Yes—except for the points corresponding to "the end of time" and "the beginning of time", of course

26. Copyright © C. J. Date 2005page 26 T3:Supplier Sx was under contract during the interval from date b to date e If corresp relation includes 3-tuple— S#FROMTO S1July 1st, 1999September 25th, 2000 —doesn’t CWA imply it must also include: S#FROMTOetc., etc., S1July 2nd, 1999September 24th, 2000etc.?

27. Copyright © C. J. Date 2005page 27 GOOD POINT !!! Clearly, T3 needs to be tightened up: T3:Supplier Sx was under contract on every day from date b to date e, but not on the day immediately before b, nor on the day immediately after e  l Since = "ever since and not immediately before" l During= "throughout and not immediately before or immediately after (the interval in question)"

28. Copyright © C. J. Date 2005page 28 SOME ASSUMPTIONS : Henceforth we assume that: l No supplier can end one contract on one day and start another on the very next day l No supplier can be under two distinct contracts at the same time l Contracts can be open-ended—i.e., a supplier can be currently under contract and the end date for that contract can be currently unknown

29. Copyright © C. J. Date 2005page 29 2. LAYING THE FOUNDATIONS :  Time and the DB  What’s the problem? Intervals Interval operators The EXPAND and COLLAPSE operators The PACK and UNPACK operators Relational operators

30. Copyright © C. J. Date 2005page 30 SUPPLIERS AND SHIPMENTS—SIMPLIFIED VERSION (sample values) : SS#SPS#P# S1Supplier Sx isS1P1 S2currentlyS1P2 S3under contractS1P3 S4S1P4 S5S1P5 S1P6 S2P1 S2P2 S3P2 Potential shipments:S4P2 Supplier Sx is currentlyS4P4 able to supply part PyS4P5

31. Copyright © C. J. Date 2005page 31 SAMPLE CONSTRAINTS : Consider key constraints only (until further notice): l {S#} is primary key for S l {S#,P#} is primary key for SP l {S#} is foreign key in SP matching primary key of S

32. Copyright © C. J. Date 2005page 32 SAMPLE QUERIES : l Query A:Get supplier numbers of suppliers who are currently able to supply at least one part SP { S# } /* projection */ l Query B:Get supplier numbers of suppliers who are currently unable to supply any part at all S { S# } MINUS SP { S# } /* difference between two projections */

33. Copyright © C. J. Date 2005page 33 "SEMITEMPORALIZING" SUPPLIERS AND SHIPMENTS : S_SINCESP_SINCE S#SINCES#P#SINCE S1d04S1P1d04 S2d07S1P2d05 S3d03S1P3d09 S4d04S1P4d05 S5d02S1P5d04 S1P6d06 S2P1d08 Granularity = one dayS2P2d09 S3P2d08 Assume day 1 immediately precedesS4P2d06 day 2, etc., etc.S4P4d04 S4P5d05

34. Copyright © C. J. Date 2005page 34 PREDICATES : l S_SINCE: Ever since day SINCE (and not on the day immediately before day SINCE), supplier S# has been under contract l SP_SINCE: Ever since day SINCE (and not on the day immediately before day SINCE), supplier S# has been able to supply part P#

35. Copyright © C. J. Date 2005page 35 SAMPLE CONSTRAINTS : PK and FK constraints are as for nontemporal version But we also need to "augment" the FK constraint to say no supplier can supply any part before that supplier is under contract … CONSTRAINT XST1 IS_EMPTY ( ( ( S_SINCE RENAME (SINCE AS SS) ) JOIN ( SP_SINCE RENAME (SINCE AS SPS) ) ) WHERE SPS < SS ) ; /* if tuple sp in SP_SINCE references tuple s in S_SINCE,*/ /* SINCE value in sp must not be less than that in s */ Nice to have some convenient shorthand...

36. Copyright © C. J. Date 2005page 36 SAMPLE QUERIES : l Query A:Get supplier numbers of suppliers who are currently able to supply at least one part, together with the date since when they have been able to do so SUMMARIZE SP_SINCE BY { S# } ADD (MIN ( SINCE ) AS SINCE) S#SINCE S1d04 S2d08 S3d08 S4d04

37. Copyright © C. J. Date 2005page 37 l Query B:Get supplier numbers of suppliers who are currently unable to supply any part at all, together with the date since when they have been unable to do so Supplier S5 is currently unable to supply any parts at all … But we don’t know the date since when S5 has been unable to supply any parts (insufficient information in the DB)— DB is still only "semitemporalized" I.e., we need to keep historical records!

38. Copyright © C. J. Date 2005page 38 FULLY TEMPORALIZING SUPPLIERS AND SHIPMENTS (first attempt) : S_FROM_TOSP_FROM_TO S#FROMTOS#P#FROMTO S1d04d10S1P1d04d10 S2d02d04S1P2d05d10 S2 d07d10S1P3d09d10 S3d03d10S1P4d05d10 S4d04d10S1P5d04d10 S5d02d10S1P6d06d10 S2P1d02d04 S2P1d08d10 S2P2d03d03 S2P2d09d10 S3P2d08d10 S4P2d06d09 S4P4d04d08 S4P5d05d10

39. Copyright © C. J. Date 2005page 39 POINTS ARISING : l Assume for definiteness that "date today" = d10 Have shown d10 as TO value for each tuple pertaining to current state of affairs How can all of those d10’s become d11’s on the stroke of midnight? See later! l More tuples than before … This fully temporal DB includes everything from semitemporal DB,* plus historical records regarding previous interval of time (from d02 to d04) during which S2 was also under contract and able to supply certain parts Except that TO value for two of S4’s shipments < today— i.e., those shipments now "historical" instead of "current" *

40. Copyright © C. J. Date 2005page 40 PREDICATES : l S_FROM_TO: From day FROM (and not on the day immediately before FROM) to day TO (and not on the day immediately after TO), supplier S# was under contract l SP_FROM_TO: From day FROM (and not on the day immediately before FROM) to day TO (and not on the day immediately after TO), supplier S# was able to supply part P#

41. Copyright © C. J. Date 2005page 41 SAMPLE CONSTRAINTS : l Must prohibit FROM-TO pairs in which TO < FROM: CONSTRAINT S_FROM_TO_OK IS_EMPTY ( S_FROM_TO WHERE TO < FROM ) ; CONSTRAINT SP_FROM_TO_OK IS_EMPTY ( SP_FROM_TO WHERE TO < FROM ) ; l Primary keys: For S_FROM_TO= {S#,FROM}—or {S#,TO}? For SP_FROM_TO= {S#,P#,FROM}—or {S#,P#,TO}? But these constraints aren’t sufficient!

42. Copyright © C. J. Date 2005page 42 SAMPLE CONSTRAINTS (cont.) : l If S_FROM_TO includes (e.g.)— S#FROMTO S1 d04d10 —then it mustn’t also include (e.g.): S#FROMTO S1 d02d06

43. Copyright © C. J. Date 2005page 43 SAMPLE CONSTRAINTS (cont.) : l These two tuples need to be combined into one … S#FROMTO S1d02d10 l Note that not combining the tuples would be as bad as permitting duplicates!—and would mean S_FROM_TO violated its own predicate (contains contradiction) l PK constraint insufficient to prohibit overlapping tuples

44. Copyright © C. J. Date 2005page 44 SAMPLE CONSTRAINTS (cont.) : If S_FROM_TO includes (e.g.)— S#FROMTO S1 d04d10 —then it mustn’t also include (e.g.): S#FROMTO S1 d02d03

45. Copyright © C. J. Date 2005page 45 SAMPLE CONSTRAINTS (cont.) : l These two tuples need to be combined into one … S#FROMTO S1d02d10 l No redundancy as such, but circumlocution (and violation of predicate)—containing contradiction l PK constraint insufficient to prohibit abutting tuples

46. Copyright © C. J. Date 2005page 46 SAMPLE CONSTRAINTS (cont.) : CONSTRAINT XFT1 IS_EMPTY ( ( ( S_FROM_TO RENAME ( FROM AS F1, TO AS T1 ) ) JOIN ( S_FROM_TO RENAME ( FROM AS F2, TO AS T2 ) ) ) WHERE ( T1 > F2 AND T2 > F1 ) ) OR ( F2 = T1+1 OR F1 = T2+1 ) ) ; Complicated !!! "T1+1" ??? "T2+1" ??? Do we begin to see the problem ???

47. Copyright © C. J. Date 2005page 47 SAMPLE CONSTRAINTS (cont.) : l {S#,FROM} is not a FK from SP_FROM_TO to S_FROM_TO l But if supplier s appears in SP_FROM_TO, then supplier s must appear in S_FROM_TO as well: CONSTRAINT XFT2 SP_FROM_TO { S# }  S_FROM_TO { S# } ; Example of an inclusion dependency (FK constraints are a special case) Note the relation comparison in this example

48. Copyright © C. J. Date 2005page 48 SAMPLE CONSTRAINTS (cont.) : l But Constraint XFT2 is not enough! … If SP_FROM_TO shows supplier s is able to supply some part during some interval of time, then S_FROM_TO must show supplier s is under contract during that same interval of time CONSTRAINT XFT3 COUNT ( S_FROM_TO { ALL BUT P# } ) = COUNT ( ( ( SP_FROM_TO RENAME ( FROM AS SPF,TO AS SPT ) ) { ALL BUT P# } JOIN ( S_FROM_TO RENAME ( FROM AS SF, TO AS ST ) ) ) WHERE SF SPT ) ; Draw your own conclusions... Next…