SpyTime --- a Performance Benchmark for Bitemporal Databases

Dennis Shasha
Prof, Computer Science Dept, Department of Computer Science
Courant Institute of Mathematical Sciences
New York University
(shasha@cs.nyu.edu)

Yunyue Zhu
Department of Computer Science
Courant Institute of Mathematical Sciences
New York University
(yunyue@cs.nyu.edu)

Abstract

A bitemporal table records both the history of the facts and the history of changes to the records in the database. In addition to normal non-temporal queries, bitemporal databases permit queries over two orthogonal time dimensions: valid time and transaction time. Valid time is the time when a fact is effective in reality. Transaction time denotes the time when the record is effective in the database. The diversity of possible queries makes bitemporal tables versatile and useful in many applications. Numerous indexing methods for temporal (as well as bitemporal) databases have been proposed and a comparison [2] has been made among these access methods. It is our hope that the SpyTime benchmark will be used as a basis for comparing the performance of different bitemporal database management systems.

It should also be noted that our benchmark is not intended for the comparison of the descriptive and expressive power of query languages. One can turn to a semantic benchmark [3,6] for those comparisons. In fact, a system satisfies the requirements of SpyTime regardless of the query language it supports, as long as that query language is powerful enough to support the semantics of the queries listed here.
 

Models for a Bitemporal Benchmark

The scheme we use as our bitemporal benchmark is a database that records spy activities in different cities. The uncertainty surrounding spy activity is reflected in our bitemporal database. Each tuple in the database represents the assertion that a specific spy was reported to appear in a specific city during a specific (valid time) interval. The transaction time interval is the time period during which the database believed this fact to be true.

The following table describes the data in this benchmark.

Spy-City Information Table

Field Name

Type

Comments

Spy

Char(10)

The name of the spy.

City

Char(10)

The city where the spy was reported to appear in.

Vt_begin

Date

Begin of the Valid Time period. The spy was supposed to be in the specific city from this date.

Vt_end

Date

End of the Valid Time period. The spy was supposed to be in the specific city until this date.

Tt_begin

Date

Begin of the Transaction Time period. The database records the fact on this date.

Tt_end

Date

End of the Transaction Time period. The database finds out the data is no longer true on this date.

Reporter

Char(10)

The reporter who report the spy event. This can be other information that is relevant to the bitemporal data.


 
 

Query characteristics. There will be basically two types of queries.