Temporal and Real-Time Temporal and Real-Time Databases: A SurveyDatabases: A Survey

by Gultekin Ozsoyoglu and

Richard T. Snodgrass

Presentation by Didi Yao

IntroductionIntroduction

Survey two areas that can benefit from cross infusion: temporal and real-time DBs

Temporal: time-varying infoReal-time: transactions w/ time constraintsBoth can benefit from one another

Real-Time DatabasesReal-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)

The Time DomainThe Time Domain

2 structures: linear and branchingDensities 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

The Time Domain (cont.)The Time Domain (cont.)

Relative (unanchored): 3PM, Nov 9, 2000Relative has directionAbsolute (anchored): 3 hoursAbsolute, in a way, is also relative

The Time Domain (cont.)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 timeIndeterminacy- “don’t know exactly when”

Time in Real-Time DBsTime 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, boundedDoes not deal with temporal indeterminacy

Temporal Data Models Temporal Data Models (relational)(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

Temporal Data Models Temporal Data Models (OO)(OO)

Table II

(temporal OO data models):– 3 “valid” models– 5 “transaction” models– 4 “both” models

Valid Time (Temporal Model)Valid Time (Temporal Model)

Single chronon– Event timestamp

Interval– Interval timestamp

Valid-time– Set of intervals

Transaction Time (Temporal Model)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

Real-time Data ModelsReal-time Data Models

Relational model is used for real-time DBsOO model may benefit real-time DBs:

– rich data semantics, complex objects, encapsulation, methods, messages

However, the added complexity affects real-timeliness

Temporal Query LanguagesTemporal Query Languages

User-defined time supported by most DBs3 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

Temporal Query LanguagesTemporal 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

Real-Time Data and Real-Time Data and Transaction PropertiesTransaction 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

Real-Time Properties (cont.)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

Conventional vs. Real-TimeConventional 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

Real-Time ConsistencyReal-Time Consistency

Absolute data consistencyRelative data consistency

– A set of data items that are relatively consistent to each other

Real-Time Query LanguagesReal-Time Query Languages

none

Architectural IssuesArchitectural 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

Architectural Issues (cont.)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

Architectural Issues (cont.)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

Architectural Issues (cont.)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)

Architectural Issues (cont.)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

Architectural Issues (cont.)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

Architectural Issues (cont.)Architectural Issues (cont.)

Stored data manager structures– Reverse chaining, accession lists, clustering,

stacking, cellular chainingBuffering for real-time scheduling

– Priority-LRU, priority-DBMINScheduling disk I/O for real-time

processing– FD-SCAN decides scanning direction by

location I/O request with earliest deadline

ConclusionConclusion 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