1. Temporal and Real-Time Databases: A Survey by Gultekin Ozsoyoglu and Richard T. Snodgrass Presentation by Didi Yao

2. Introduction Survey two areas that can benefit from cross infusion: temporal and real-time DBs Temporal: time-varying info Real-time: transactions w/ time constraints Both can benefit from one another

3. Real-Time Databases Transactions have deadlines and timing constraints Time constraints on: queries, insertions, deletions, updates, database integrity More work has been done on temporal than real-time DBs (600 temporal papers, 150 real-time papers)

4. The Time Domain 2 structures: linear and branching Densities of the time line: – Discrete models naturals – Dense models reals or rationals – Continuous models reals (no gaps) Most proposals for adding temporal to relational data models use discrete

5. The Time Domain (cont.) Relative (unanchored): 3PM, Nov 9, 2000 Relative has direction Absolute (anchored): 3 hours Absolute, in a way, is also relative

6. The Time Domain (cont.) Valid time – When a fact was true in reality – Bounded or unbounded Transaction time – When a fact was stored – Grows monotonically Others: user-defined time, decision time Indeterminacy- “don’t know exactly when”

7. Time in Real-Time DBs Valid time – Used for data that have real-world counterparts Transaction time – Transactions affecting real-time systems – Never aborted or rolled back Does not assume future, linear, bounded Does not deal with temporal indeterminacy

8. Temporal Data Models (relational) Time support in conventional DBs is only user-defined time: Date, Time, Timestamp Table I (temporal relational data models) : – 14 “valid time” models – 3 “transaction time” models – 9 “valid and transaction time” models “Valid time” wins

9. Temporal Data Models (OO) Table II (temporal OO data models) : – 3 “valid” models – 5 “transaction” models – 4 “both” models

10. Valid Time (Temporal Model) Single chronon – Event timestamp Interval – Interval timestamp Valid-time – Set of intervals

11. Transaction Time (Temporal Model) Often used to support versioning which allows user-supplied identifiers to be attached to versions. Versioning support generally implies OO. Conclusion to temporal data models: a coordinated suite of data models can best achieve temporal goals

12. Real-time Data Models Relational model is used for real-time DBs OO model may benefit real-time DBs: – rich data semantics, complex objects, encapsulation, methods, messages However, the added complexity affects real- timeliness

13. Temporal Query Languages User-defined time supported by most DBs 3 approaches to supporting Valid-time: – Use relational or OO model directly – Include general extensions to data model and query languages (only used on OO query languages) – add new constructs and temporal operators

14. Temporal Query Languages Transaction-time is used for rollbacks and versioning (extension and schema) Extension versioning (tuples, object instances or attributes are versioned) – Use model directly, general extensions, or modify data model and language Schema versioning (object definition versioned) – Multiple schemas in effect

15. Real-Time Data and Transaction Properties Hard transaction: missing a deadline is disastrous Soft transaction: missing a deadline will not kill you Factors that affect real-time transactions: – Transaction arrival pattern: periodic, sporadic – Data access type: random, round-robin – Knowing whether an item will be accessed beforehand – Knowing the CPU and I/O usage beforehand

16. Real-Time Properties (cont.) It is not possible to have both external consistency AND integrity constraint sat. External consistency may: – Lead to triggers (more coolant) – Require aborts (abort objects from furnace) Internal consistency may need resolution through new transactions. Cooperate, not compete

17. Conventional vs. Real-Time Conventional DBs: – Fair in data and resource allocation – Use response time and throughput as measures Real-Time DBs: – Timely transaction execution – Fairness is secondary – Use % of non-missed deadlines as a measure – Transactions prioritized on deadlines

18. Real-Time Consistency Absolute data consistency Relative data consistency – A set of data items that are relatively consistent to each other

19. Real-Time Query Languages none

20. Architectural Issues Temporal query optimization is more involved than conventional query opt. Predicates are harder to optimize – Joins with more inequalities are frequent Time advances in one direction – Natural clustering on sort order Methods to optimize query: – Replace algebraic expression with a more efficient, equivalent one – Change access method of an operator – Change implementation of an operator

21. Architectural Issues (cont.) Temporal joins: proposed extensions to nested loop and merge joins Temporal indices are important because of the size of temporal data but no work has been done to empirically compare them

22. Architectural Issues (cont.) Transaction processing – Adapt existing concurrency control and transaction management to support transaction time – Timestamp at the end of transaction Processing transaction with hard deadlines – Arrival patterns, items to be accessed, CPU, I/O access times must all be known

23. Architectural Issues (cont.) Processing transaction with soft deadlines – Priority assignment policies: Earliest-deadline-first, least-slack-time-first, etc… Concurrency control protocols – Lock-based protocols – Timestamp-ordering protocols (timestamp start) – Optimistic concurrency control protocols (timestamp end)

24. Architectural Issues (cont.) Lock-based protocols – Transaction blocks or aborts depending on transactions priority Priority inheritance approach – Lower-priority transaction inherits a higher priority in order to block Priority abort approach – Higher-priority request can cause lower-priority transaction to abort

25. Architectural Issues (cont.) Timestamp-ordering protocols – Timestamps transaction start – Early conflict resolution – Suffers from priority inversion Optimistic concurrency control protocols – Timestamps transaction end – Nonblocking and deadlock-free – Aborts and restart wastes resources

26. Architectural Issues (cont.) Stored data manager structures – Reverse chaining, accession lists, clustering, stacking, cellular chaining Buffering for real-time scheduling – Priority-LRU, priority-DBMIN Scheduling disk I/O for real-time processing – FD-SCAN decides scanning direction by location I/O request with earliest deadline

27. Conclusion Temporal relational database (25 years) Temporal OO database (15 years) Real-time databases (since 1986) Accomplishments – No data model is good enough, need suite of models – Real-time and temporal people are interacting and starting to use the same language Needs – Real-time models that capture semantic knowledge – Too many temporal data models, not many real-time models and no real-time query language – Performance is still a challenge