Showing papers by "Christian S. Jensen published in 1997"

The Consensus Glossary of Temporal Database Concepts - February 1998 Version.

Abstract: This document1 contains definitions of a wide range of concepts specific to and widely used within temporal databases. In addition to providing definitions, the document also includes explanations of concepts as well as discussions of the adopted names.

On the semantics of “now” in databases

Abstract: Although “now” is expressed in SQL and CURRENT_TIMESTAMP within queries, this value cannot be stored in the database. How ever, this notion of an ever-increasing current-time value has been reflected in some temporal data models by inclusion of database-resident variables, such as “now” “until-changed, ” “**,” “@,” and “-”. Time variables are very desirable, but their used also leads to a new type of database, consisting of tuples with variables, termed a variable database.

Transitioning Temporal Support in TSQL2 to SQL3.

Abstract: This document summarizes the proposals before the SQL3 committees to allow the addition of tables with valid-time and transactiontime support into SQL/Temporal, and explains how to use these facilities to migrate smoothly from a conventional relational system to one encompassing temporal support. Initially, important requirements to a tdiscussed. The proposal then describes the language additions necessary emporal system that may facilitate such a transition are motivated and to add valid-time support to SQL3 while fulfilling these requirements. The constructs of the language are divided into four levels, with each level adding increased temporal functionality to its predecessor. A prototype system implementing these constructs on top of a conventional DBMS is publicly available.

Notions of upward compatibility of temporal query languages

Abstract: Migrating applications from conventional to temporal database management technology has received scant mention in the research literature. This paper formally defines three increasingly restrictive notions of upward compatibility which capture properties of a temporal SQL with respect to conventional SQL that, when satisfied, provide for a smooth migration of legacy applications to a temporal system. The notions of upward compatibility dictate the semantics of conventional SQL statements and constrain the semantics of extensions to these statements. The paper evaluates the seven extant temporal extensions to SQL, all of which are shown to complicate migration through design decisions that violate one or more of these notions. We then outline how SQL–92 can be systematically extended to become a temporal query language that satisfies all three notions.

Layered Temporal DBMS: Concepts and Techniques

Abstract: A wide range of database applications manage timevarying data, and it is well-known that querying and correctly updating time-varying data is dificult and error-prone when using standard SQL. Temporal extensions of SQL ofSeer substantial benefits over SQL when managing time-varying data. The topic of this paper is the effective implementation of temporally extended SQL’s. Traditionally, it has been assumed that a temporal DBMS must be built from scratch, utilizing new technologies for storage, indexing, query optimization, concurrency control, and recovery. In contrast, this paper explores the concepts and techniques involved in implementing a temporally enhanced SQL while maximally reusing the facilities of an existing SQL implementation. The topics covered span the choice of an adequate timestamp domain that includes the time van’able “NOW,” a comparison. of query processing architectures, and transaction processing, the latter including how to ensure ACID properties and assign timestamps to updates.

A Notation for Spatiotemporal Queries

Abstract: Any software made available via TIMECENTER is provided " as is " and without any express or implied warranties , including, without limitation, the implied warranty of merchantability and fitness for a particular purpose. The TIMECENTER icon on the cover combines two " arrows. " These " arrows " are letters in the so-called Rune alphabet used one millennium ago by the Vikings, as well as by their precedessors and successors, The Rune alphabet (second phase) has 16 letters. They all have angular shapes and lack horizontal lines because the primary storage medium was wood. However, runes may also be found on jewelry, tools, and weapons. Runes were perceived by many as having magic, hidden powers. The two Rune arrows in the icon denote " T " and " C, " respectively. Abstract: Temporal, spatial and spatiotemporal queries are inherently multidimensional, combining predicates on time dimension(s) with predicates on explicit attributes and/or several spatial dimensions. In the past there was no consistent way to refer to temporal or spatiotemporal queries, thus leading to considerable confusion. In an attempt to eliminate this problem, we propose a new notation for such queries. Our notation is simple and extensible and can be easily applied to multidimensional queries in general.

Correct and Efficient Timestamping of Temporal Data

Abstract: Previous approaches to timestamping temporal data have implicitly assumed that transactions have no duration. In this paper we identify several situations where a sequence of operations over time within a single transaction can violate ACID properties. It has been previously shown that the transaction-time dimension must be timestamped after commit. This time is not known within the transaction. We describe how to correctly implement most queries that make explicit reference to this (unknown) transaction time, and argue that the rest, which can be syntactically identified, can only be answered with an approximation of the correct value. The drawback of timestamping after commit is that it requires revisiting tuples. We show that this expensive revisiting step is required only before any queries or modifications in subsequent transactions that access prior states; in most cases, revisiting tuples can be postponed, and when to revisit can be syntactically determined. We propose several strategies for revisiting tuples, and we empirically evaluate these strategies in order to determine under which circumstances each is best.