Temporal Databases: Research and Practice

Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis and J. van Leeuwen 1399 Opher Etzion Sushil Jajodia...

Author: Opher Etzion | Sushil Jajodia | Suryanarayana Sripada

68 downloads 1806 Views 6MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis and J. van Leeuwen

1399

Opher Etzion Sushil Jajodia Suryanarayana Sripada (Eds.)

Temporal Databases: Research and Practice

~ Springer

Series Editors Gerhard Goos, Karlsruhe University, Germany Juris Hartmanis, Cornell University, NY, USA Jan van Leeuwen, Utrecht University, The Netherlands Volume Editors Opher Etzion IBM Research Laboratory in Haifa Matam, Haifa 31905, Israel E-mail: opher @haifa.vnet.ibm.com Sushil Jajodia Center for Secure Information Systems and Department of Information and Software Systems Engineering George Mason University Fairfax, VA 22030-4444, USA E-mail: [email protected] Suryanarayana Sripada RWTH Aachen, Informatik V Ahornstr. 55, D-52074 Aachen, Germany Currently at: Light Software GmbH,Aachen E-mail: sripada@ compuserve.com Cataloging-in-Publication data applied for Die Deutsche Bibliothek - CIP-Einheitsaufnahme Temporal databases : research and practice / Opher Etzion ... (ed.). Berlin ; Heidelberg ; New York ; Barcelona ; Budapest ; Hong Kong ; London ; Milan ; Paris ; Santa Clara ; Singapore ; Tokyo : Springer, 1998 (Lecture notes in computer science ; 1399) ISBN 3-540-64519-5 CR Subject Classification (1991): H.2-4 ISSN 0302-9743 ISBN 3-540-64519-5 Springer-Verlag Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer -Verlag. Violations are liable for prosecution under the German Copyright Law. 9 Springer-Verlag Berlin Heidelberg 1998 Printed in Germany Typesetting: Camera-ready by author SPIN 10637053 06/3142 - 5 4 3 2 1 0

Printed on acid-free paper

Preface

Temporal databases incorporate the concept of time to create high-level abstractions useful in database applications. This has been an active area of research for about twenty years. In the last few years the importance of the temporal database area has been recognized by the international scientific community. This recognition came in part in the form of the ARPA/NSF sponsored International Workshop on Temporal Database Infrastructure in 1993, a VLDB-affiliated temporal workshop in 1995 , a special section of the IEEE Transactions on Knowledge and Data Engineering on temporal and real-time databases published in August 1995, and the incorporation of temporal constructs, proposed by the temporal database community, in the soon-to-be standardized SQL3 language. This book arose out of the Dagstuhl seminar that was organized by us during June 23-27, 1997. This seminar focused on the future directions of this discipline, with respect to both research issues and the means to incorporate temporal databases into mainstream application development. List of topics discussed at this seminar included: 1. Temporal data models: relational, object-oriented, deductive, and hybrid models. Where do the temporal capabilities fit in? 2. Temporal languages: TSQL2 and beyond. Update and retrieval languages for various types of temporal data models. 3. The interrelationships between temporal databases and other disciplines: spatial databases, active databases, deductive databases, real-time databases, information uncertainty, belief revision, etc. 4. Implementation issues in temporal databases. Issues that arise from experience of implementors and users and the agenda for research into these areas and transition to use in practice. 5. Strategic discussions about the future of "temporal databases" as a discipline. Evaluation of the current state of the art and "call for action" to the community. The Dagstuhl seminar brought together researchers who have dealt with different perspectives on temporal databases: temporal data models, temporal retrieval and update languages, interrelationships between temporal databases and other database technologies (e.g., spatial databases, active databases, realtime databases), and interrelationships between temporal databases and temporal reasoning in artificial intelligence. Some of the invited participants have also been involved in the standardization activities of the temporal community. Having a diverse group that shared a focus on temporal information processing ensured critical evaluation of the activities that have occurred thus far, and enriched the discussions. As with any Dagstuhl seminar, the participants respresented a selected group of prominent researchers in the subject area. We solicited from the Dagstuhl

VI

Preface

seminar invitees submissiens for this book and aimed to include high-quality original papers about the state of the art in the temporal database area. The number of submissions exceeded our expectations, and we used a peer-review process to select the high-quality papers for this book. The book consists of the following parts: P a r t 1: T e m p o r a l D a t a b a s e I n f r a s t r u c t u r e : This part consists of five papers that discuss infrastructure topics. The relationship between object-oriented modeling and temporal databases is one of the emerging issues, because of the inherent data complexity of temporal applications. The paper A n O b j e c t - O r i e n t e d F r a m e w o r k for T e m p o r a l D a t a M o d e l s by Goralwalla~ Ozsu~ and Szafron presents an object-oriented basis for the design and implementation of different temporal data models, to capture alternative temporal models for different applications and to compare and analyze different temporal object models with respect to design dimensions. Heterogeneous system problems of semantic differences with respect to timerelated data do not escape temporal database applications. These differences can materialize in point versus interval semantics, different granularities, and different data types. The paper A n A r c h i t e c t u r e for S u p p o r t i n g I n t e r o p e r a b i l i t y a m o n g T e m p o r a l D a t a b a s e s by Bettini~ Wang~ and J a j o d i a proposes a multidatabase architecture where an appropriate formalization of the intended semantics is associated with each temporal relation. This allows the construction of a temporal mediator, described in this paper. While retrieval queries in temporal databases have been thoroughly discussed, the update process deserves some attention. The paper E x t e n d e d Update F u n c t i o n a l i t y by Etzion~ Gal~ and Segev provides an enhanced collection of update operation types that are possible in append-only temporal database applications (such as: freeze along an interval, revise an erroneous value over an interval keeping the previous value for historical queries). The paper discusses different possible semantics for simultaneous values (values that are valid during the same valid time), and discusses the concept of decision time as a temporal primitive. The execution of temporal database updates and queries can be optimized, due to the fact that an operation refers to specific time points. The paper On T r a n s a c t i o n M a n a g e m e n t in T e m p o r a l D a t a b a s e s by Gal provides a framework for concurrent processing of retrieval and update operations in temporal databases. The paper presents a series of modifications and tuning facilities for traditional concepts in transaction management, especially the locking mechanism. The paper I m p l e m e n t a t i o n O p t i o n s for Time-Series D a t a by E l m a s r i and Lee concentrates on a special topic of temporal databases: time-series management systems. This paper compares and demonstrates different implementation schemes of mapping time-series into relational and object-oriented databases. P a r t 2: T e m p o r a l Q u e r y Languages: This part consists of four papers that deal with query languages and their relationships to modeling and implementation.

Preface

VII

Nested relations have been mentioned as a representation scheme for temporal data. The paper E x p r e s s i v e P o w e r of T e m p o r a l R e l a t i o n a l Q u e r y L a n g u a g e s a n d T e m p o r a l C o m p l e t e n e s s by Tansel and T i n introduces an extension to the relational data model to handle temporal data and queries, based on a nested relational data model. This model captures tuple and attribute time-stamping. The paper discusses requirements for such a model and temporal relational completeness. One of the efforts in the last few years has been the attempt to incorporate temporal capabilities in the SQL standard. The TSQL2 language is the proposed language that has been devised by a committee consisting of many of the leading researchers in the temporal database community. The paper Transitioning T e m p o r a l S u p p o r t in T S Q L 2 to SQL3 by Snodgrass~ Bohlen~ Jensen~ and S t e i n e r summarizes the proposals before the SQL3 committees to allow the addition of tables with valid-time and transactiontime support and explains how to migrate from a regular relational database into the proposed scheme. The efforts to incorporate temporal capabilities into SQL have stimulated some discussion with respect to the nature of the desired target language. The paper Valid T i m e a n d T r a n s a c t i o n T i m e P r o p o s a l s : L a n g u a g e D e s i g n A s p e c t s by D a r w e n suggests language design principles, such as parsimony and conceptual integrity, and argues that current proposals deviate from these design principles. This language debate was discussed at length during the Dagstuhl seminar. P o i n t - B a s e d T e m p o r a l E x t e n s i o n s of SQL a n d T h e i r Efficient Imp l e m e n t a t i o n by T o m a n is the topic of the next paper. This paper proposes another extension to the SQL language by adding a single data type to represent a linearly ordered universe of individual time-instants. In addition it introduces an efficient query evaluation procedure over a compact interval-based encoding of temporal relations. P a r t 3: A d v a n c e d A p p l i c a t i o n s of T e m p o r a l D a t a b a s e s : This part consists of four papers that discuss the utilization of temporal databases for security, business event managers, knowledge discovery, and querying moving objects. The paper A p p l i c a b i l i t y of T e m p o r a l D a t a M o d e l s to Q u e r y M u l t i level S e c u r i t y D a t a b a s e s : A Case S t u d y by G a d i a points out that the multiple value abstraction, required for temporal databases, is also useful for other domains, such as spatial databases and multiple beliefs, and that these are special cases of parametric databases. This concept is discussed, along with its applicability to multilevel security databases. The paper A n A r c h i t e c t u r e a n d C o n s t r u c t i o n of a B u s i n e s s E v e n t M a n a g e r by P a t a n k a r and Segev introduces the concept of a business event, and discusses types of temporal events, and event histories. The paper introduces an architecture and an SQL-like language to define these events. Decision support and decision analysis systems serve as important motivation areas for temporal database applications. In the paper Discovering U n e x p e c t e d P a t t e r n s in T e m p o r a l D a t a Using T e m p o r a l Logic by

VIII

Preface

B e r g e r and Tuzhilin, the task of finding interesting patterns in temporal databases is discussed. The paper presents a categorization of different discovery tasks, and focuses on the task of discovering interesting patterns of events in temporal sequences. The area of spatio-temporal databases is emerging as an independent area. The paper Q u e r y i n g t h e U n c e r t a i n P o s i t i o n of M o v i n g O b j e c t s by Sistla, Wolfson~ C h a m b e r l a i n , and D a o proposes a data model for representing moving objects with uncertain positions in database systems. It also introduces a query language based on this model. P a r t 4: G e n e r a l Reference: This part provides general information about the state of the art in temporal databases. It contains a T e m p o r a l D a t a b a s e B i b l i o g r a p h y U p d a t e by Wu, J a j o d i a , and W a n g that provides current references on models, database designs, query languages, constraints, time granularities, implementations, access methods, real-time databases, sequence databases, data mining, concurrency, and other papers. An up-todate temporal database glossary prepared by J e n s e n and D y r e s o n and a glossary on time granularities by Bettini~ Wang, Snodgrass, D y r e s o n , and E v a n s follows. A p p e n d i x : S u m m a r i e s of C u r r e n t Work: At the conclusion of the seminar, all participants were invited to submit a brief summary of their activities in the temporal database area. These summaries, presented in the Appendix, provide a glimpse into some of the developments that we can expect to see in the coming years.

March 1998

Opher Etzion Sushil Jajodia Sury Sripada

Table of C o n t e n t s

P a r t 1: T e m p o r a l D a t a b a s e I n f r a s t r u c t u r e An Object-Oriented Framework for Temporal Data Models L A. Goralwalla, M. T. Ozsu, and D. Szafron

An Architecture for Supporting Interoperability among Temporal Databases C. Bettini, X. S. Wang, and S. .Jajodia

36

Extended Update Functionality in Temporal Databases O. Etzion, A. Gal, and A. Segev

56

On Transaction Management in Temporal Databases A. Gal

96

Implementation Options for Time-Series Data R. Elmasri and J. Y. Lee

115

P a r t 2: T e m p o r a l Q u e r y L a n g u a g e s Expressive Power of Temporal Relational Query Languages and Temporal Completeness A. U. Tansel and E. Tm

129

Transitioning Temporal Support in TSQL2 to SQL3 R. T. Snodgrass, M. H. B5hlen, C. S. Jensen, and A. Steiner

150

Valid Time and Transaction Time Proposals: Language Design Aspects H. Da~ven

195

Point-Based Temporal Extensions of SQL and Their Efficient Implementation D. Toman

211

X

Table of Contents

Part 3: Advanced Applications of Temporal Databases Applicability of Temporal Data Models to Query Multilevel Security Databases: A Case Study S. K. Gadia

238

An Architecture and Construction of a Business Event Manager A. K. Patankar and A. Segev

257

Discovering Unexpected Patterns in Temporal Data Using Temporal Logic G. Berger and A. Tuzhilin

281

Quering the Uncertain Position of Moving Objects A. P. Sistla, O. Wolfson, S. Chamberlain, and S. Dao

310

Part 4: General Reference Temporal Database Bibliography Update Y. Wu, S. Jajodia, and X. S. Wang

338

The Consensus Glossary of Temporal Database Concepts - February 1998 Version C. S. Jensen, C. E. Dyreson (Eds.), M. BShlen, J. Clifford, R. Elmasri, S. K. Gadia, F. Grandi, P. Hayes, S. Jajodia, W. Kiifer, N. Kline, N. Lorentzos, Y. Mitsopoulos, A. Montanari, D. Nonen, E. Peressi, B. Pernici, J. F. Roddick, iV. L. Sarda, M. R. Scalas, A. Segev, R. T. Snodgrass, M. D. Soo, A. Tansel, P. Tiberio, and G. Wiederhold

367

A Glossary of Time Granularity Concepts C. Bettini, C. E. Dyreson, W. S. Evans, R. T. Snodgrass, and X. S. Wang

406

Appendix Summaries of Current Work The Dagstuhl Seminar Researchers

414

Index of A u t h o r s

429

An Object-Oriented Framework for Temporal Data Models ¨ Iqbal A. Goralwalla, M. Tamer Ozsu, and Duane Szafron Laboratory for Database Systems Research Department of Computing Science University of Alberta Edmonton, Alberta, Canada T6G 2H1 {iqbal,ozsu,duane}@cs.ualberta.ca

Abstract. Most of the database research on modeling time has concentrated on the definition of a particular temporal model and its incorporation into a (relational or object) database management system. This has resulted in quite a large number of different temporal models, each providing a specific set of temporal features. Therefore, the first step of this work is a design space for temporal models which accommodates multiple notions of time, thereby classifying design alternatives for temporal models. The design space is then represented by exploiting object-oriented features to model the different aspects of time. An object-oriented approach allows us to capture the complex semantics of time by representing it as a basic entity. Furthermore, the typing and inheritance mechanisms of object-oriented systems allow the various notions of time to be reflected in a single framework. The framework can be used to accommodate the temporal needs of different applications, and derive existing temporal models by making a series of design decisions through subclass specialization. It can also be used to derive a series of new more general temporal models that meet the needs of a growing number of emerging applications. Furthermore, it can be used to compare and analyze different temporal object models with respect to the design dimensions.

1

Introduction

The ability to model the temporal dimension of the real world is essential for many applications such as econometrics, banking, inventory control, medical records, real-time systems, multimedia, airline reservations, versions in CAD/CAM applications, statistical and scientific applications, etc. Database management systems (DBMSs) that support these applications have to be able to satisfy temporal requirements. To accommodate the temporal needs of different applications, there has been extensive research activity on temporal data models in the last decade [Sno86,SS88,Soo91,Kli93,TK96]. Most of this research has concentrated on the O. Etzion, S. Jajodia, and S. Sripada (Eds.): Temporal Databases - Research and Practice c Springer–Verlag Berlin Heidelberg 1998 LNCS 1399, pp. 1–35, 1998.

2

¨ Iqbal A. Goralwalla, M. Tamer Ozsu, and Duane Szafron

definition of a particular temporal model and its incorporation into a (relational or object-oriented) database management system (DBMS). The early research on temporal data models concentrated on extending the relational data model to handle time in an appropriate manner. The notion of time, with its multiple facets, is difficult (if not impossible) to represent in one single relational model since it does not adequately capture data or application semantics. This is substantiated by most of the relational temporal models that only support a discrete and linear model of time. The general limitation of the relational model in supporting complex applications has led to research into next-generation data models, specifically object data models. The research on temporal models has generally followed this trend. Temporal object models can more accurately capture the semantics of complex objects and treat time as a basic component. There have been many temporal object model proposals (for example, [RS91,SC91,WD92,KS92,CITB92,BFG97]). These models differ in the functionality that they offer, however as in relational systems, they assume a set of fixed notions of time. Wuu & Dayal [WD92] provide an abstract time type to model the most general semantics of time which can then be subtyped (by the user or database designer) to model the various notions of time required by specific applications. However, this requires significant support from the user, including specification of the temporal schema. Both (relational and object-oriented) approaches have led to the definition and design of a multitude of temporal models. Many of these assume a set of fixed notions about time, and therefore do not incorporate sufficient functionality or extensibility to meet the varying temporal requirements of today’s applications. Instead, similar functionality is re-engineered every time a temporal model is created for a new application. Although most temporal models were designed to support the temporal needs of a particular application, or group of similar applications, if we look at the functionality offered by the temporal models at an abstract level, there are notable similarities in their temporal features: – Each temporal model has one or more temporal primitives, namely, time instant, time interval, time span, etc. The discrete or the continuous domain is used by each temporal model as a temporal domain over the primitives. – Some temporal models require their temporal primitives to have the same underlying granularity, while others support multiple granularities and allow temporal primitives to be specified in different granularities. – Most temporal models support a linear model of time, while a few support a branching model. In the former, temporal primitives are totally ordered, while in the latter they have a partial order defined on them. – All temporal models provide some means of modeling historical information about real-world entities and/or histories of entities in the database. Two of the most popular types of histories that have been employed are valid and transaction time histories [Sno87], respectively. These commonalities suggest a need for combining the diverse features of time under a single infrastructure that is extensible and allows design reuse. In this pa-

An Object-Oriented Framework for Temporal Data Models

3

per, we present an object-oriented framework [JF88] that provides such a unified infrastructure. An object-oriented approach allows us to capture the complex semantics of time by representing it as a basic entity. Furthermore, the typing and inheritance mechanisms of object-oriented systems directly enable the various notions of time to be reflected in a single framework. The objectives of this work are fourfold. The first objective is to identify the design dimensions that span the design space for temporal models. This will classify design alternatives for temporal models. The design space is then represented by exploiting object-oriented features to model the different aspects of time. The second objective is to show how the temporal framework can be tailored to accommodate real-world applications that have different temporal needs. The third objective is to show how the various existing temporal object models can be represented within this framework. The final objective is to use the framework to analyze and compare the different temporal object models based on the design dimensions. In particular, the [RS91,SC91,KS92,PM92,CITB92,BFG97] temporal object models are considered. The work of Wuu & Dayal [WD92] and Cheng & Gadia [CG93] (which follows a similar methodology as [WD92]) are not considered since they do not provide concrete notions of time in their models. Object models supporting versioning using time usually follow a structural embedding of temporality within type definitions [KGBW90,WLH90,SRH90], [Sci94]. Thus, the notion of temporal objects is lost since the model knows nothing about temporality. Moreover, most temporal version models use the Date function call which is provided by the system. For example, though the EXTRAV version model [Sci94] supports “valid” and “transaction” time, it does so by timestamping attributes using system provided dates. This is limited in scope as no semantics of the various notions of time are provided. Since these models are not “temporal object models” in the strict sense of the term, we do not include them in this study. We can draw a parallel between our work and similar (albeit on a much larger scale) approaches used in Choices [CJR87] and cmcc [ATGL96]. Choices is a framework for operating system construction which was designed to provide a family of operating systems that could be reconfigured to meet diverse user/application requirements. cmcc is an optimizing compiler that makes use of frameworks to facilitate code reuse for different modules of a compiler. Similar to Choices and cmcc, the temporal framework presented in this paper can be regarded as an attempt to construct a family of temporal models. The framework can then be tailored to reflect a particular temporal model which best suits the needs of an application. A particular temporal model would be one of the many “instances” of the framework. The presentation of this paper is divided into five sections. Section 2 presents the temporal framework by identifying the design dimensions (key abstractions) for temporal models and the interactions between them. Section 3 illustrates how the temporal framework can be tailored to accommodate the temporal needs of different applications, and the temporal features of temporal object models. In Section 4 object-oriented techniques are used to compare and analyze different

4


temporal object models with respect to the design dimensions. Section 5 summarizes the work presented in this paper, discusses related work, and outlines avenues for future research.

2

The Architecture of the Temporal Framework

In order to accommodate the varying requirements that many applications have for temporal support, we first identify the design dimensions that span the design space for temporal models. Next, we identify the components or features of each design dimension. Finally, we explore the interactions between the design dimensions in order to structure the design space. These steps produce a framework which consists of abstract and concrete object types, and properties (abstractions of methods and attributes in traditional object-oriented terminology). The types are used to model the different design dimensions and their corresponding components. The properties are used to model the different operations on each component, and to represent the relationships (constraints) between the design dimensions. The framework classifies design alternatives for temporal models by providing types and properties that can be used to define the semantics of many different specific notions of time. 2.1

Design Dimensions

The design alternatives for temporal models can be classified along four design dimensions: 1. Temporal Structure − provides the underlying ontology and domains for time. 2. Temporal Representation − provides a means to represent time so that it is human readable. 3. Temporal Order − gives an ordering to time. 4. Temporal History − allows events and activities to be associated with time. There are two parts to the description of a design dimension. First, we define a set of temporal features that the design dimension encompasses. Second, we explore relationships between the temporal features and describe the resulting design space for the design dimension. The design space consists of an architectural overview of abstract and concrete types corresponding to the temporal features, and a design overview which describes some of the key properties (operations) defined in the interface of the types. We do not describe the properties in detail since many of these are traditional temporal operations that have already appeared in the literature on temporal databases. We assume the availability of commonly used object-oriented features − atomic entities (reals, integers, strings, etc.); types for defining common features of objects; properties (which represent methods and instance variables) for specifying the semantics of operations that may be performed on objects; classes


5

which represent the extents of types; and collections for supporting general heterogeneous groupings of objects. In this paper, a reference prefixed by “T ” refers to a type, and “P ” to a property. A type is represented by a rounded box. An abstract type is shaded with a black triangle in its upper left corner, while a concrete type is unshaded. In Figures 5, 8, 9, and 15 the rectangular boxes are objects. Objects have an outgoing edge for each property applicable to the object which is labeled with the name of the property and which leads to an object resulting from the application of the property to the given object. A circle labeled with the symbols { } represents a container object and has outgoing edges labeled with “∈” to each member object. Temporal Structure The first question about a temporal model is “what is its underlying temporal structure?” More specifically, what are the temporal primitives supported in the model, what temporal domains are available over these primitives, and what is the temporal determinacy of the primitives? Indeed, the temporal structure dimension with its various constituents forms the basic building block of the design space of any temporal model since it is comprised of the basic temporal features that underlie the model. We now give an overview of the features of a temporal structure and then identify the relationships that exist between them. Components 1. Temporal Primitives Temporal primitives can either be anchored (absolute) or unanchored (relative) [Sno92]. For example, 31 July 1995 is an anchored temporal primitive since we know exactly where it is located on the time axis, whereas 31 days is an unanchored temporal primitive since it can stand for any block of 31 consecutive days on the time axis. There is only one unanchored primitive, called the span. A span is a duration of time with a known length, but no specific starting and ending anchor points. There are two anchored primitives, the instant (moment, chronon) and the interval. An instant is a specific anchored moment in time, e.g., 31 July 1995. An interval is a duration of time between two specific anchor points (instants) which are the lower and upper bounds of the interval, e.g., [15 June 1995, 31 July 1995]. 2. Temporal Domain The temporal domain of a temporal structure defines a scale for the temporal primitives. A temporal domain can be continuous or discrete. Discrete domains map temporal primitives to the set of integers. That is, for any temporal primitive in a discrete time domain, there is a unique successor and predecessor. Continuous domains map temporal primitives to the set of real numbers. Between any two temporal primitives of a continuous time domain, another temporal primitive exists. Most of the research in the context of temporal databases has assumed that the temporal domain is discrete. Several arguments in favor of using a discrete temporal domain are made by Snodgrass [Sno92] including the

6


imprecision of clocking instruments, compatibility with natural language references, possibility of modeling events which have duration, and practicality of implementing a continuous temporal data model. However, Chomicki [Cho94] argues that the continuous (dense) temporal domain is very useful in mathematics and physics. Furthermore, continuous time provides a useful abstraction if time is thought of as discrete but with instants that are very close. In this case, the set of time instants may be very large which in turn may be difficult to implement efficiently. Chomicki further argues that query evaluation in the context of constraint databases [KKR90,Rev90] has been shown to be easier in continuous domains than in discrete domains. Continuous temporal domains have also been used to facilitate full abstract semantics in reasoning about concurrent programs [BKP86]. 3. Temporal Determinacy There are many real world cases where we have complete knowledge of the time or the duration of a particular activity. For example, the time interval allowed for students to complete their Introduction to Database Management Systems examination is known for certain. This is an example of a determinate temporal primitive. However, there are cases when the knowledge of the time or the duration of a particular activity is known only to a certain extent. For example, we do not know the exact time instant when the Earth was formed though we may speculate on an approximate time for this event. In this case, the temporal primitive is indeterminate. Indeterminate temporal information is also prevalent in various sources such as granularity, dating techniques, future planning, and unknown or imprecise event times [DS93]. Since the ultimate purpose of a temporal model is to represent real temporal information, it is desirable for such a model to be able to capture both determinate and indeterminate temporal primitives. Design Space Figure 1 shows the building block hierarchy of a temporal structure. The basic building block consists of anchored and unanchored temporal primitives. The next building block provides a domain for the primitives that consists of discrete or continuous temporal primitives. Finally, the last building block of Figure 1 adds determinacy. Thus, a temporal structure can be defined by a series of progressively enhanced temporal primitives. Figure 2 gives a detailed hierarchy of the different types of temporal primitives that exist in each of the building blocks of Figure 1. Based on the features of a temporal structure, its design space consists of 11 different kinds of temporal primitives. These are the determinacy-domain-based temporal primitives shown in Figure 2 and described below. Continuous time instants and intervals. Continuous instants are just points on the (continuous) line of all anchored time specifications. They are totally ordered by the relation “later than.” Since in theory, continuous instants have infinite precision, they cannot have a period of indeterminacy. Therefore, continuous indeterminate time instants do not


7

Determinacy-Domain-based Domain-based Temporal Temporal Primitives Primitives Temporal Primitives

+ determinacy/ indeterminacy + discrete/continuous domain

Fig. 1. Building a Temporal Structure exist in Figure 2. However, continuous intervals can be determinate or indeterminate. The difference between them is that a continuous determinate interval denotes that the activity associated with it occurs during the whole interval, while a continuous indeterminate interval denotes that the activity associated with it occurs sometime during the interval. Continuous intervals have lower and upper bounds which are continuous instants. Discrete time instants and intervals. Assume that somebody has been on a train the whole day of 5 January 1997. This fact can be expressed using a determinate time instant 5 January 1997det (which means the whole day of). However, the fact that somebody is leaving for Paris on 5 January 1997 can be represented as an indeterminate time instant 5 January 1997indet (which means some time on that day). Hence, each discrete time instant is either determinate or indeterminate, corresponding to the two different interpretations. Discrete time instants are analogous to continuous time intervals. Every determinate (indeterminate) discrete time instant has a granularity (Gi ) associated with it. This granularity determines the mapping of the given determinate (indeterminate) discrete time instant Idet (Iindet ) to the domain of continuous time instants. The mapping is defined as follows: Idet 7→ [Icont , Icont + Gi ) Iindet 7→ [Icont ∼ Icont + Gi ) Here Icont denotes the counterpart of Idet and Iindet in the domain of continuous time instants. This is exemplified by the mapping of the discrete determinate instant 5 January 1997det to the continuous determinate interval [5 January 1997cont, 6 January 1997cont). In this case Gi = Gdays = 1 day. A formal treatment of the different types of instants ¨ and mappings is given in [GLOS97]. Discrete time instants can be used to form discrete time intervals. Since we have determinate and indeterminate discrete instants, we also have determinate and indeterminate discrete intervals. Determinate (indeterminate) time instants can be used as boundaries of determinate (indeterminate) time intervals. Time spans. Discrete and continuous determinate spans represent complete information about a duration of time. A discrete determinate span

8

¨ Iqbal A. Goralwalla, M. Tamer Ozsu, and Duane Szafron Temporal Structure Design Space Domain-based Temporal Primitives

Determinacy-Domain-based Temporal Primitives Determinate Discrete Instants

Discrete Instants

Temporal Primitives

Indeterminate Discrete Instants Instants

Continuous Instants

Determinate Continuous Instants

Anchored Primitives Determinate Discrete Intervals Discrete Intervals Indeterminate Discrete Intervals Temporal Structure Intervals Determinate Continuous Intervals Continuous Intervals Indeterminate Continuous Intervals

Determinate Discrete Spans Discrete Spans Indeterminate Discrete Spans Unanchored Primitives Determinate Continuous Spans Continuous Spans Indeterminate Continuous Spans

Fig. 2. Design Space of a Temporal Structure

is a summation of distinct granularities with integer coefficients e.g., 5 days or 2 months + 5 days. Similarly, a continuous determinate span is a summation of distinct granularities with real coefficients e.g., 0.31 hours or 5.2 minutes + 0.15 seconds. Discrete and continuous indeterminate spans represent incomplete information about a duration of time. They have lower and upper bounds that are determinate spans. For example, 1 day ∼ 2 days is a discrete indeterminate span that can be interpreted as “a time period between one and two days.” The mapping of the temporal structure to an object type hierarchy is given in Figure 3 which shows the types and generic properties that are used to model various kinds of determinacy-domain-based temporal primitives. Properties defined on time instants allow an instant to be compared with another instant; an instant to be subtracted from another instant to find the time duration between the two; and a time span to be added to or subtracted from an instant to return another instant. Furthermore, properties P calendar and P calElements are used to link time instants to calendars which serve as a representational scheme for temporal primitives (see Section 2.1). P calendar returns the calendar which the instant belongs to and P calElements returns a list of the calendric elements in a time instant. For example P calendar applied to the time instant 15 June 1995 would return


9

P_succ, P_pred

T_detDiscInstant T_indetDiscInstant

P_succ, P_pred

T_instant P_leq, P_geq P_elapsed

T_detContInstant

P_calendar P_calElements

T_anchPrim T_detDiscInterval P_addDuration P_subDuration

T_indetDiscInterval T_temporalStructure T_interval P_before P_after

P_lb, P_ub, P_length P_overlaps, P_during P_starts, P_finishes, P_meets P_union P_intersection P_difference

T_detContInterval T_indetContInterval

T_detDiscSpan T_indetDiscSpan

P_succ, P_pred P_lb, P_ub P_succ, P_pred

T_unanchPrim P_add, P_subtract P_coefficient P_calGranularities

T_detContSpan T_indetContSpan

P_lb, P_ub

Supertype

Subtype

Fig. 3. The Inheritance Hierarchy of a Temporal Structure Gregorian, while the application of P calElements to the same time instant would return (1995, June, 15). Similarly, properties defined on time intervals include unary operations which return the lower bound, upper bound and length of the interval; ordering operations which define Allen’s interval algebra [All84]; and set-theoretic operations. Properties defined on time spans enable comparison and arithmetic operations between spans. The P before and P after properties are refined for time spans to model the semantics of < and >, respectively. Additionally, properties P coefficient and P calGranularities are used as representational properties and provide a link between time spans and calendars (see Section 2.1). P coefficient returns the (real) coefficient of a time span given a specific calendric granularity. For example, (5 days)· P coefficient(day) returns 5.0. P calGranularities returns a collection of calendric granularities in a time span. For example, the property application (1 month + 5 days)· P calGranularities returns {day, month}.

10


We note that (see Figure 3) the properties P succ and P pred are defined in all the types involving both discrete instant and span primitives. This redundancy can be eliminated by refactoring the concerned types and using multiple inheritance. More specifically, an abstract type called T discrete can be introduced, and the properties P succ and and P pred defined on it. All the types involving discrete primitives can then be made subtypes of T discrete. A similar approach can be used to factor the types that define properties P lb and P ub. An abstract type called T bounds can be introduced with the properties P lb and P ub defined on it. The T interval type and the types involving indeterminate spans can then be made subtypes of T bounds. Alternatively, the concept of multiple subtyping hierarchies can be used to collect semantically related types together and avoid the duplication of properties [HKOS96]. For example, the unanchored primitives hierarchy can be re-structured as shown in Figure 4. P_succ, P_pred

T_discSpan

T_detDiscSpan T_indetDiscSpan

T_unanchPrim P_add, P_subtract P_coefficient P_calGranularities

T_indetSpan P_lb, P_ub

T_indetContSpan

T_contSpan T_detContSpan

Supertype

Subtype

Fig. 4. Multiple Subtyping Hierarchy for Unanchored Temporal Primitives

Temporal Representation Components. For human readability, it is important to have a representational scheme in which the temporal primitives can be made human readable and usable. This is achieved by means of calendars. Common calendars include the Gregorian and Lunar calendars. Educational institutions also use Academic calendars. Calendars are comprised of different time units of varying granularities that enable the representation of different temporal primitives. In many applications, it is desirable to have multiple calendars that have different calendric granularities. For example, in financial trading, multiple calendars with different time units and operations need to be available to capture the semantics of financial data [CS93,CSS94]. In time series management, extensive calendar support is also required [DDS94,LEW96]. A calendar should be able to support multiple granularities since temporal information processed by a DBMS is usually available in multiple granularities. Such information is prevalent in various sources. For example:


11

– clinical data − Physicians usually specify temporal clinical information for patients with varying granularities [CPP95,CPP96]. For example, “the patient suffered from abdominal pain for 2 hours and 20 minutes on June 15, 1996,” “in 1990, the patient took a calcium antagonist for 3 months,” “in October 1993, the patient had a second heart seizure.” – real-time systems − A process is usually composed of sub-processes that evolve according to times that have different granularities [CMR91]. For example, the temporal evolution of the basin in a hydroelectric plant depends on different sub-processes: the flow of water is measured daily; the opening and closing of radial gates is monitored every minute; and the electronic control has a granularity of microseconds. – geographic information systems − Geographic information is usually specified according to a varying time scale [Flo91]. For example, vegetation fluctuates according to a seasonal cycle, while temperature varies daily. – office information systems − temporal information is available in different time units of the Gregorian calendar [BP85,CR88,MPB92]. For example, employee wages are usually recorded in the time unit of hours while the history of sales are categorized according to months. Design Space. A calendar is composed of an origin, a set of calendric granularities, and a set of conversion functions. The origin marks the start of a calendar1 . Calendric granularities define the reasonable time units (e.g., minute, day, month) that can be used in conjunction with this calendar to represent temporal primitives. A calendric granularity also has a list of calendric elements. For example in the Gregorian calendar, the calendric granularity day has the calendric elements Sunday, Monday, . . . , Saturday. Similarly in the Academic calendar, the calendric granularity semester has the calendric elements Fall, Winter, Spring, and Summer. The conversion functions establish the conversion rules between calendric granularities of a calendar. Since all calendars have the same structure, a single type, called T calendar can be used to model different calendars, where instances represent different calendars. The basic properties of a calendar are, P origin, P calGranularities, and P functions. These allow each calendar to define its origin, calendric granularities, and the conversion functions between different calendric granularities. Example 1. Figure 5 shows four instances of T calendar − the Gregorian, Lunar, Academic, and Fiscal calendars. The origin of the Gregorian calendar is 1

We note that our definition of a calendar is different from that defined in [CS93,CSS94,LEW96] where structured collections of time intervals are termed as “calendars.” Our definition adheres closely to the human understanding of a calendar. However, the extensibility feature of the framework allows any other notions of calendars to be incoporated easily under the temporal representation design dimension.

12


given as the span 1582 years from the start of time since it was proclaimed in 1582 by Pope Gregory XIII as a reform of the Julian calendar. The calendric granularities in the Gregorian calendar are the standard ones, year, month, day, etc. The origin of the Academic calendar shown in Figure 5 is assumed to be the span 1908 academicY ears having started in the year 1908, which is the establishment date of the University of Alberta. The Academic calendar has similar calendric granularities as the Gregorian calendar and defines a new calendric granularity of semester. The semantics of the Lunar and Fiscal calendars could similarly be defined.

academicYear

semester

ε

academicMonth

ε

ε

ε

{}

1908 years

ε

P_calGranularities P_origin P_functions

Academic

T_calendar

Fiscal

Lunar

P_functions

Gregorian

{}

{}

P_origin P_calGranularities 1582 years

{}

ε year

ε month

ε ε

ε day

Fig. 5. Temporal Representational Examples

Temporal Order We now have the means of designing the temporal structure and the temporal representation of a temporal model. The next step is to provide an ordering scheme for the temporal primitives. This constitutes the third building block of our design space. Components. A temporal order can be classified as being linear or branching In a linear order, time flows from past to future in an ordered manner. In


13

a branching order, time is linear in the past up to a certain point, when it branches out into alternate futures. The structure of a branching order can be thought of as a tree defining a partial order of times. The trunk (stem) of the tree is a linear order and each of its branches is a branching order. The linear model is used in applications such as office information systems. The branching order is useful in applications such as computer aided design and planning or version control which allow objects to evolve over a nonlinear (branching) time dimension (e.g., multiple futures, or partially ordered design alternatives). Design Space. The different types of temporal orders are dependent on each other. A sub-linear order is one in which the temporal primitives (time intervals) are allowed to overlap, while a linear order is one in which the temporal primitives (time intervals) are not allowed to overlap. Every linear order is also a sub-linear order. A branching order is essentially made up of sub-linear orders. The relationship between temporal orders is shown in Figure 6.

is-a

sub-Linear Order

is-a

Linear Order

Temporal Order composed-of

is-a

Branching Order

Fig. 6. Temporal Order Relationships

The hierarchy in Figure 7 gives the various types and properties which model different temporal orders2 .

T_subLinearOrder

T_linearOrder

P_branchingOrder T_temporalOrder P_temporalPrimitives

T_branchingOrder P_root P_branches P_in

Supertype

Subtype

Fig. 7. The Hierarchy of Temporal Orders

2

We do not consider periodic temporal orders in this work. These can easily be incorporated as a subtype of T temporalOrder.

14


Example 2. Consider the operations that take place in a hospital on any particular day. It is usually the case that at any given time multiple operations are taking place. Let us assume an eye cataract surgery took place between 8am and 10am, a brain tumor surgery took place between 9am and 12pm, and an open heart surgery took place between 7am and 2pm on a certain day. Figure 8 shows a pictorial representation of operationsOrder, which is an object of type T subLinearOrder. operationsOrder consists of the time intervals [08:00,10:00], [09:00,12:00], [07:00,14:00], and does not belong to any branching timeline. As seen in the figure, operationsOrder consists of intervals (representing the time periods during which the different surgeries took place) that overlap each other. Hence, operationsOrder is an example of a sub-linear order.

operationsOrder

P_branchingOrder

null

P_temporalPrimitives {}

ε

ε

ε

[08:00, 10:00] [09:00, 12:00] [07:00, 14:00]

Fig. 8. An Example of a Sub-Linear Order.

Example 3. To illustrate the use of objects of type T linearOrder which are total linear temporal orders, consider a patient with multiple pathologies, for example as a result of diabetes. The patient has to attend several special clinics, each on a different day. Hence, it follows that since the patient cannot attend more than one special clinic on any day, the temporal order of the patient’s special clinics visit history is linear and totally ordered. Suppose the patient visited the opthalmology clinic on 10 January 1995, the cardiology clinic on 12 January 1995, and the neurology clinic on 3 February 1995. Figure 9 shows a pictorial representation of specialClinicOrder, which is an object of type T linearOrder. As seen in the figure, specialClinicOrder is totally ordered as its time intervals do not overlap. Example 4. Consider an observational pharmacoeconomic analysis of the changing trends, over a period of time, in the treatment of a chronic illness such as ¨ asthma [GOS97]. The analysis would be performed using information gathered over a time period. At a fixed point during this period new guidelines for the treatment of asthma were released. At that point the population of patients

An Object-Oriented Framework for Temporal Data Models specialClinicOrder

P_branchingOrder

15

null

P_temporalPrimitives {}

ε 10 January 1995

ε

ε

12 January 1995

3 February 1995

Fig. 9. An Example of a Linear Order. known to have asthma are divided into those whose doctors continue the old established treatment, and those whose doctors, in accordance with new recommendations, change their treatment. Thus, the patients are divided into two groups, each group undergoing a different treatment for the same illness. The costs and benefits accrued over the trial period for each treatment are calculated. Since such a study consists of several alternative treatments to an illness, a branching timeline is the natural choice for modeling the timeline of the study. The point of branching is the time when the new guidelines for the treatment of the illness are implemented. Figure 10 shows the branching timeline for such a medical trial history.

Regular treatment Treatment A The medical trial branching timeline which includes the Regular Treatment, Treatment A, and Treatment B Treatment B Branching point (time when new guidelines are released)

Fig. 10. An Example of a Branching Order. The same branching timeline could as easily handle the situation where different versions of a particular treatment, say Treatment A, are implemented based on certain parameters. In this case, the “Treatment A” branch would in turn branch at a certain point into different Treatment A versions. This situation is also depicted in Figure 10. Temporal History So far we have considered the various features of time; its structure, the way it is represented, and how it is ordered. The final building

16


block of the design space of temporal models makes it possible to associate time with entities to model different temporal histories. Components. One requirement of a temporal model is an ability to represent and manage real-world entities as they evolve over time and assume different states (values). The set of these values forms the temporal history of the entity. Two basic types of temporal histories are considered in databases which incorporate time. These are valid and transaction time histories [SA85]. Valid time denotes the time when an entity is effective (models reality), while transaction time represents the time when a transaction is posted to the database. Usually valid and transaction times are the same. Other temporal histories include event time [RS91,CK94] and decision time [EGS93] histories. Event (decision) time denotes the time the event occured in the real-world. Valid, transaction, and event times have been shown to be adequate in modeling temporal histories [CK94]. Design Space. Since valid, transaction, and event time histories have different semantics, they are orthogonal. Figure 11 shows the various types that could be used to model these different histories. A temporal history consists of objects and their associated timestamps.

T_history

T_validHistory

T_transactionHistory

P_history P_temporalOrder P_insert P_remove P_getObjects

T_eventHistory

Fig. 11. The Types and Properties for Temporal Histories

Property P history defined in T history returns a collection of all timestamped objects that comprise the history. A history object also knows the temporal order of its temporal primitives. The property P temporalOrder returns the temporal order (which is an object of type T temporalOrder) associated with a history object. The temporal order basically orders the time intervals (or time instants) in the history. Another property defined on history objects, P insert, timestamps and inserts an object in the history. Property P remove drops a given object from the history at a specified temporal primitive. The P getObjects property allows the user to get the objects in the history at (during) a given temporal primitive. The properties defined on T history are refined in T validHistory, T transactionHistory, and T eventHistory types to model the semantics of the different kinds of histories. Moreover, each history type can define additional properties, if nec-


17

essary, to model its particular semantics. The clinical example described in Section 3.1 illustrates the use of the properties defined on T history.

2.2

Relationships between Design Dimensions

In the previous section we described the building blocks (design dimensions) for temporal models and identified the design space of each dimension. We now look at the interactions between the design dimensions. This will enable us to put the building blocks together and structure the design space for temporal models. A temporal history is composed of entities which are ordered in time. This temporal ordering is over a collection of temporal primitives in the history, which in turn are represented in a certain manner. Hence, the four dimensions can be linked via the “has-a” relationship shown in Figure 12.

Temporal Model Design Space Valid Temporal History

Transaction Event

has sub-Linear Temporal Order

Linear Branching

has Determinate Discrete Instants Indeterminate Discrete Instants Temporal Structure

Determinate Continuous Instants Determinate Discrete Intervals

has

Indeterminate Discrete Intervals Determinate Continuous Intervals Indeterminate Continuous Intervals Determinate Discrete Spans Indeterminate Discrete Spans Determinate Continuous Spans Indeterminate Continuous Spans Gregorian Academic

Temporal Representation

Business Financial

Fig. 12. Design Space for Temporal Models

18


Basically, a temporal model can be envisioned as having a notion of time, which has an underlying temporal structure, a means to represent the temporal structure, and different temporal orders to order the temporal primitives within a temporal structure. This notion of time, when combined with application objects can be used to represent various temporal histories of the objects in the temporal model. Figure 12 gives the design space for temporal models. A temporal model can support one or more of valid, transaction, event, and user-defined histories. Each history in turn has a certain temporal order. This temporal order has properties which are defined by the type of temporal history (linear or branching). A linear history may or may not allow overlapping of anchored temporal primitives that belong to it. If it does not allow overlapping, then such a history defines a total order on the anchored temporal primitives that belong to it. Otherwise, it defines a partial order on its anchored temporal primitives. Each order can then have a temporal structure which is comprised of all or a subset of the 11 different temporal primitives that are shown in Figure 2. Finally, different calendars can be defined as a means to represent the temporal primitives. The four dimensions are modeled in an object system by the respective types shown in Figure 13. The “has a” relationship between the dimensions is modeled using properties as shown in the figure. An object of T temporalHistory represents a temporal history. Its temporal order is obtained using the P temporalOrder property. A temporal order is an object of type T temporalOrder and has a certain temporal structure which is obtained using the P temporalPrimitives property. The temporal structure is an object of type T temporalStructure. The property P calendar gives the instance of T calendar which is used to represent the temporal structure.

T_temporalFramework

T_calendar

T_temporalStructure

P_calendar

T_temporalOrder

P_temporalPrimitives

T_temporalHistory

P_temporalOrder

Fig. 13. Relationships between Design Dimensions Types

The relationships shown in Figure 13 provide a temporal framework which encompasses the design space for temporal models. The detailed type system, shown in Figure 14, is based on the design dimensions identified in Section 2 and their various features which are given in Figures 3, 7, and 11. As described in Section 2.1, refactoring of types and multiple inheritance can be used to handle identical properties that are defined over different types in the inheritance


19

hierarchy shown in Figure 14. The framework can now be tailored for the temporal needs of different applications and temporal models. This is illustrated in Section 3.

P_succ, P_pred

T_detDiscInstant T_indetDiscInstant

T_instant

P_succ, P_pred

P_leq, P_geq P_elapsed P_calendar

T_detContInstant

P_calElements

T_anchPrim P_addDuration

T_detDiscInterval

P_subDuration

T_temporalStructure

T_indetDiscInterval

T_interval P_before P_lb, P_ub, P_length

P_after

P_overlaps, P_during P_starts, P_finishes, P_meets

T_detContInterval

P_union P_intersection P_difference

T_indetContInterval

P_succ, P_pred

T_unanchPrim

T_temporalFramework

T_indetDiscSpan

P_add, P_subtract

P_lb, P_ub, P_succ, P_pred

P_coefficient P_calGranularities

T_detContSpan

T_calendar P_origin P_calGranularities P_functions

T_detDiscSpan

T_indetContSpan P_lb, P_ub

T_subLinearOrder

T_linearOrder

P_branchingOrder T_temporalOrder P_temporalPrimitives

T_branchingOrder

P_root P_branches P_in T_validHistory

T_history

Supertype


T_transactionHistory T_eventHistory Subtype

Fig. 14. The Inheritance Hierarchy for the Temporal Framework

3

Tailoring the Temporal Framework

In this section, we illustrate how the temporal framework that is defined in Section 2 can be tailored to accommodate applications and temporal models

20


Temporal History timeStampedHematology1

timeStampedMicrobiology

ε

ε

ε

timeStampedHematology2

{} P_insert ( aBloodTest,aTimeStamp ) P_remove ( aBloodTest,aTimeStamp )

{}

P_history

timestamped blood tests

P_getObjects( aTimeStamp )

bloodTestHistory

P_temporalOrder

Temporal Order

bloodTestOrder

P_branchingOrder

null


ε

{}

15 January 1995

ε

20 February 1995

Temporal Structure P_calendar

P_calendar Gregorian

{}

P_calGranularities

P_origin

Temporal Representation

P_functions

{}

1582 years

ε year

ε month

ε day

Fig. 15. A Patient’s Blood Test History which have different temporal requirements. In the first two sub-sections, we give examples of two real-world applications that have different temporal needs. In the last sub-section, we give an example of a temporal object model and show how the model can be derived from the temporal framework. 3.1

Clinical Data Management

In this section we give a real-world example from clinical data management that illustrates the four design dimensions and the relationships between them which were discussed in Section 2. During the course of a patient’s illness, different blood tests are administered. It is usually the case that multiple blood tests of the patient are carried out on the same day. Suppose the patient was suspected of having an infection of the blood, and therefore had two different blood tests on 15 January 1995. These were the diagnostic hematology and microbiology blood tests. As a result of a very raised white cell count the patient was given a course of antibiotics while


21

the results of the tests were awaited. A repeat hematology test was ordered on 20 February 1995. Suppose each blood test is represented by an object of the type T bloodTest. The valid history of the patient’s blood tests can then be represented in the object database as an object of type T validHistory. Let us call this object bloodTestHistory. To record the hematology and microbiology blood tests, the objects microbiology, hematology1, and hematology2 with type T bloodTest are first created and then entered into the object database using the following property applications:

bloodTestHistory.P insert(microbiology, 15 January 1995) bloodTestHistory.P insert(hematology1, 15 January 1995) bloodTestHistory.P insert(hematology2, 20 F ebruary 1995) If subsequently there is a need to determine which blood tests the patient took in January 1995, this would be accomplished by the following property application: bloodTestHistory.P getObjects([1 January 1995, 31 January 1995]) This would return a collection of timestamped objects of T bloodTest representing all the blood tests the patient took in January 1995. These objects would be the (timestamped) hematology1 and the (timestamped) microbiology. Figure 15 shows the different temporal features that are needed to keep track of a patient’s blood tests over the course of a particular illness. The figure also illustrates the relationships between the different design dimensions of the temporal framework. The patient has a blood test history represented by the object bloodTestHistory. The P history property when applied to bloodTestHistory results in a collection object whose members are the timestamped objects timeStampedMicrobiology, timeStampedHematology1, and timeStampedHematology2. The P insert property updates the blood test history (bloodTestHistory) by inserting an object of type T bloodTest at a given anchored temporal primitive. Similarly, the property P remove updates the bloodTestHistory by removing an object of type T bloodTest at a given anchored temporal primitive. The P getObjects property returns a collection of timestamped blood test objects when given an anchored temporal primitive. Applying the property P temporalOrder to bloodTestHistory results in the object bloodTestOrder which represents the temporal order on different blood tests in bloodTestHistory. bloodTestOrder has a certain temporal structure which is obtained by applying the P temporalPrimitives property. Finally, the primitives in the temporal structure are represented using the Gregorian calendar, Gregorian and the calendric granularities year, month, and day. Let us now consider the various temporal features required to represent the different blood tests taken by a patient. Anchored, discrete, and determinate temporal primitives are required to model the dates on which the patient takes different blood tests. These dates are represented using the Gregorian calendar.

22


Since the blood tests take place on specific days, the temporal primitives during which the patient took blood tests form a total order. Lastly, a valid time history is used to keep track of the different times the blood tests were carried out. To support these temporal features, the temporal framework can be reconfigured with the appropriate types and properties. These are given in Figure 16.

T_instant

T_temporalStructure P_before P_after

P_leq, P_geq P_elapsed P_calendar

T_anchPrim

T_detDiscInstant P_succ, P_pred

P_calElements

P_addDuration P_subDuration

T_interval

T_detDiscInterval

P_lb, P_ub, P_length P_overlaps, P_during P_starts, P_finishes, P_meets

T_calendar

T_temporalFramework

P_origin P_calGranularities P_functions

T_temporalOrder

P_union P_intersection P_difference

T_linearOrder

P_temporalPrimitives T_history

Supertype


T_validHistory

Subtype

Fig. 16. The Temporal Framework Inheritance Hierarchy for the Clinical Application

3.2

Time Series Management

The management of time series is important in many application areas such as finance, banking, and economic research. One of the main features of time series management is extensive calendar support [DDS94,LEW96]. Calendars map time points to their corresponding data and provide a platform for granularity conversions and temporal queries. Therefore, the temporal requirements of a time series management system include elaborate calendric functionality (which allows the definition of multiple calendars and granularities) and variable temporal structure (which supports both anchored and unanchored temporal primitives, and the different operations on them). Figure 17 shows how the temporal requirements of a time series management system can be modeled using the types and properties of the temporal

An Object-Oriented Framework for Temporal Data Models T_instant

23

T_detDiscInstant

P_leq, P_geq P_elapsed P_calendar P_calElements

T_anchPrim P_addDuration P_subDuration


T_temporalFramework

T_calendar

Supertype

P_origin P_calGranularities P_functions

T_interval

T_detDiscInterval

P_lb, p_ub, P_length P_overlaps, P_during P_starts, P_finishes, P_meets P_union P_intersection B_difference

T_unanchPrim

T_detDiscSpan

P_add, P_subtract P_coefficient P_calGranularities

Subtype

Fig. 17. The Temporal Framework Inheritance Hierarchy for Time Series Management framework. We note from the figure that only the temporal structure and temporal representation design dimensions are used to represent the temporal needs of a time series. This demonstrates that it is not necessary for an application requiring temporal features to have all four design dimensions in order to be accommodated in the framework. One or more of the design dimensions specified in Section 2.1 can be used as long as the design criteria shown in Figure 12 holds.

3.3

TOODM - A Temporal Object-Oriented Data Model

In this section, we identify the temporal features of Rose & Segev’s temporal object-oriented data model (TOODM) [RS91] according to the design dimensions described in Section 2.1, and show how these can be accommodated in the temporal framework. We specifically concentrate on TOODM since it uses object types and inheritance to model temporality. The temporal features of the rest of the reported temporal object models [SC91,KS92,CITB92,PM92,BFG97] are summarized and compared in Section 4. We first give an overview of the temporal features of TOODM and then show how these features can be derived using the types and properties of our temporal framework. There is no doubt that TOODM has more functionality to offer in addition to temporality, but presenting that is beyond the scope of this work. Overview of Temporal Features TOODM was designed by extending an object-oriented entity-relationship data model to incorporate temporal struc-

24


Structure Representation Order History Primitives Domain Determinacy Anchored Continuous Determinate Gregorian Calendar Total Linear Valid Unanchored Transaction Event

Table 1. Temporal Design Dimension Features of TOODM

tures and constraints. The functionality of TOODM includes: specification and enforcement of temporal constraints; support for past, present, and future time; support for different type and instance histories; and allowance for retro/proactive updates. The type hierarchy of the TOODM system defined types used to model temporality is given in Figure 18. The boxes with a dashed border represent types that have been introduced to model time, while the rest of the boxes represent basic types.

Class

Object

Collections

Ptypes

V-Class

Sequence[T]

TS[T]

Time

Relative

Absolute

TI

TP

Fig. 18. System Defined Temporal Types in TOODM The Object type is the root of the type tree. The type V-Class is used to represent user-defined versionable classes. More specifically, if the instance variables, messages/methods, or constraints of a type are allowed to change (maintain histories), the type must be defined as a subtype of V-Class. The Ptypes type models primitive types and is used to represent objects which do not have any instance variables. Ptypes usually serve as domains for the instance variables of other objects. The Time primitive type is used to represent temporal primitives. The TP type represents time points, while the TI type represents time intervals. Time points can have specific different calendar granularities, namely Year, Month, Day, Week, Hour, Minute, and Second. The TS[T] type represents a time sequence which is a collection of objects ordered on time. TS[T] is a parametric type with the type T representing a


25

user or system defined type upon which a time sequence is being defined. For every time-varying attribute in a (versionable) class, a corresponding subclass (of TS[T]) is defined to represent the time sequence (history) of that attribute. For example, if the salary history of an employee is to be maintained, a subclass (e.g., TS[Salary]) of TS[T] has to be defined so that the salary instance variable in the employee class (which is defined as a subclass of V-Class) can refer to it to obtain the salary history of a particular employee. The history of an object of type TS[T] is represented as a pair , where T is the data type and T L defines the different timelines and their granularities that are associated with T . Three timelines are allowed in TOODM: valid time, record (transaction) time, and event time (the time an event occurred). Each timeline associated with an object is comprised of time points or time intervals and has an underlying granularity.

Representing the Temporal Features of TOODM in the Temporal Framework TOODM supports both anchored and unanchored primitives. These are modeled by the Absolute and Relative types shown in Figure 18. The anchored temporal primitives supported are time instants and time intervals. A continuous time domain is used to perceive the temporal primitives. Finally, the temporal primitives are determinate. Time points and time intervals are represented by using the Gregorian calendar with granularities Year, Month, Day, Week, Hour, Minute, and Second. Translations between granularities in operations are provided, with the default being to convert to the coarser granularity. A (presumably total) linear order of time is used to order the primitives in a temporal sequence. TOODM combines time with facts to model different temporal histories, namely, valid, transaction, and event time histories. Table 1 summarizes the temporal features (design space) of TOODM according to the design dimensions for temporal models that were described in Section 2.1. Figure 19 shows the type system instance of our temporal framework that corresponds to the TOODM time types shown in Figure 18 and described in Table 1. The Time primitive type is represented using the T temporalStructure type. The TP and TI types are represented using the T instant and T interval types, respectively. Similarly, the Relative type is represented using the T unanchPrim type. Since TOODM supports continuous and determinate temporal primitives, the (concrete) types T detContInstant, T detContInterval, and T detContSpan are used to model continuous and determinate instants, intervals, and spans, respectively. The Gregorian calendar and its different calendric granularities are modeled using the T calendar type. Time points and time intervals are ordered using the T linearOrder type. Time sequences represented by the TS[T] type are modeled by the history types in the temporal framework. More specifically, valid time (vt), record time (rt), and event time (et) are modeled using the T validHistory, T transactionHistory, and T eventHistory types.

26

¨ Iqbal A. Goralwalla, M. Tamer Ozsu, and Duane Szafron T_instant

T_detContInstant

P_leq, P_geq P_elapsed P_calendar P_calElements

T_anchPrim P_addDuration P_subDuration


T_calendar P_origin P_calGranularities P_functions T_temporalFramework

T_temporalOrder

T_interval

T_detContInterval

P_lb, p_ub, P_length P_overlaps, P_during P_starts, P_finishes, P_meets P_union P_intersection B_difference

T_unanchPrim

T_detContSpan

P_add, P_subtract P_coefficient P_calGranularities

T_linearOrder

P_temporalPrimitives T_validHistory T_history

Supertype


T_transactionHistory T_eventHistory

Subtype

Fig. 19. The Temporal Framework Inheritance Hierarchy for TOODM

TOODM models valid, transaction and event histories all together in one structure as shown by the TS[Salary] type in the previous section. Our temporal framework, however, provides different types to model valid, transaction, and event histories to allow their respective semantics to be modeled. Moreover, it uses properties to access the various components of histories. For example, to represent the valid history of an employee’s salary an object of type T validHistory is first created. The P insert property then inserts objects of type T integer (representing salary values) and objects of type T interval (representing time intervals) into the salary valid history object. The transaction and event time histories of the salary are similarly represented, except in these histories the P insert property inserts timestamps which are time instants (i.e., objects of type T instant).

4

Comparison of Temporal Object Models

In this section we use the temporal framework to compare and analyze the temporal object models [RS91,SC91,KS92,CITB92,PM92,BFG97] that have ap-


27

peared in recent literature. The temporal features of these models are summarized in Tables 1 and 2. Our criteria in comparing different temporal object models is based on the design dimensions identified in Section 2.1. It is true that the models may have other (salient) temporal differences, but our concern in this work is comparing their temporal features in terms of the framework defined in Section 2. Similar to the methodology used in Section 2, object-oriented techniques are used to classify temporal object models according to each design dimension. This gives us an indication of how temporal object models range in their provision for different temporal features of a design dimension − from the most powerful model (i.e., the one having the most number of temporal features) to the least powerful model (i.e., the one having the least number of temporal features).

Model

Structure Representation Primitives Domain Determinacy OSAM*/T Anchored Discrete Determinate N/A TMAD Anchored Discrete Determinate Gregorian Calendar TEDM Anchored Discrete Determinate N/A

T-3DIS

Anchored Discrete Determinate Gregorian Calendar T-Chimera Anchored Discrete Determinate N/A

Order

History

Linear Valid Linear Valid Transaction Linear Valid Transaction Event Partial Valid Linear Valid

Table 2. Design Dimension Features of different Temporal Object Models

Temporal Structure. It can be noticed from Tables 1 and 2 that most of the models support a very simple temporal structure, consisting of anchored primitives which are discrete and determinate. In fact, all models in Table 2 support the same temporal structure, which consists of discrete and determinate anchored temporal primitives. These primitives can be accommodated in the temporal framework by the T anchPrim, T instant, T detDiscinstant, T interval, and T detDiscInterval types, and their respective properties. The temporal structure of TOODM is slightly enhanced with the presence of unanchored primitives. TOODM is also the only model that supports the continuous temporal domain. Figure 20 shows how the type inheritance hierarchy is used to classify temporal object models according to their temporal structures. The temporal structures of OSAM*/T, TMAD, TEDM, T-3DIS, and T-Chimera can be modeled by a single type − that representing temporal primitives that are anchored, discrete, and determinate. This means that any of these models

28


can be used to provide temporal support for applications that need a temporal structure comprised of anchored temporal primitives which are discrete and determinate. Similarly, the temporal structure of TOODM can be be modeled by a type which represents anchored and unanchored temporal primitives that are continuous and determinate. This implies that TOODM is the only model that can support applications requiring a continuous time domain, or unanchored temporal primitives. OSAM*/T, TMAD, TEDM, T-3DIS, T_Chimera

Anchored, Determinate, & Discrete Temporal Primitives Anchored & Determinate Temporal Primitives Anchored & Unanchored, Determinate & Continuous Temporal Primitives

Supertype

TOODM

Subtype

Fig. 20. Classification of Temporal Object Models according to their Temporal Structures Temporal Representation. Temporal primitives in the OSAM*/T [SC91], TEDM [CITB92], and T-Chimera [BFG97] models are simply represented using natural numbers. The models do not provide any additional representational scheme which supports calendars and different granularities. The granularity of the temporal primitives is dependent on the application using the model. When a calendric representational scheme is provided for the temporal primitives, it is comprised of a single underlying calendar, which is usually Gregorian. This is the case in the TOODM [RS91], TMAD[KS92], and T-3DIS [PM92] models. Temporal Order. All models shown in Tables 1 and 2, except T-3DIS, support a linear temporal order. The T-3DIS model supports a sub-linear temporal order. These temporal orders are accommodated in the temporal framework using the T subLinearOrder and T linearOrder types. Figure 21 shows how the models can be classified in an inheritance type hierarchy according to their temporal orders. The type modeling a partial linear order of time sits at the root of the hierarchy and represents the T-3DIS model. Since a total linear order is also a partial order, the models supporting total linear orders can be represented by a direct subtype of the root type. Temporal History. Tables 1 and 2 show how the temporal object models range in their support for the different types of temporal histories. Figure 22 shows


29

TOODM, OSAM*/T,TMAD, TEDM, T-Chimera

T-3DIS

Partial Linear Orders Supertype

Linear Orders Subtype

Fig. 21. Classification of Temporal Object Models according to their Temporal Orders how the models can be classified according to the temporal histories they support using a type inheritance hierarchy. The root type in Figure 22 represents the models which only support valid time histories. These are the OSAM*/T, T-3DIS, and T-Chimera models. A direct subtype of the root type inherits the valid time history and provides transaction time history as well. This type represents the TMAD model. Similarly, the rest of the subtypes inherit different histories from their supertypes and add new histories to their type as shown in Figure 22. From Figure 22, we see that applications requiring only valid time histories can be supported by all models; applications requiring valid and transaction time can be supported by the TMAD, TEDM, and TOODM models; and applications requiring valid, transaction, and event time can be supported by the TEDM and TOODM models. OSAM*/T, T-3DIS, T-Chimera

Valid Time History Supertype

TMAD

Valid & Transaction Time History

TOODM, TEDM

Valid & Transaction & Event Time History Subtype

Fig. 22. Classification of Temporal Object Models according to their Temporal Histories Overall Classification. Having classified the temporal object models according to the individual design dimensions, we now treat the models as points in the design space and use the object-oriented inheritance hierarchy to compare the models on all the temporal features of the design dimensions that they support. Figure 23 gives an inheritance hierarchy in which types are used to represent the different models, and the temporal features supported by the models are used as a criteria for inheritance. The abstract type at the root of the hierarchy represents the least powerful temporal object model which supports a temporal structure comprised of anchored primitives which are discrete and determinate, no temporal repre-

30


fewer features (types)

Temporal Structure: Anchored, Discrete, & Determinate Temporal Representation: None Temporal Order: Partial Linear Temporal History: Valid

OSAM*/T, T-Chimera

T-3DIS

Temporal Structure: Anchored, Discrete, & Determinate


Temporal Representation: None

Temporal Representation: Gregorian

Temporal Order: Total Linear

Temporal Order: Partial Linear

Temporal History: Valid


TEDM

TMAD



Temporal Representation: None




Temporal History: Valid, Transaction, Event

Temporal History: Valid, Transaction

Temporal Structure: Anchored, Unanchored, Continuous & Determinate Temporal Representation: Gregorian

TOODM


more features (types)

Temporal History: Valid, Transaction, Event

Fig. 23. Overall Classification of Temporal Object Models


31

sentational scheme, a partial linear order, and a valid time history. This type has two immediate subtypes. The first subtype represents the OSAM*/T and the T-Chimera models. It inherits all the features of the root type and refines its partial linear order to a total linear order. Similarly, the second subtype represents the T-3DIS model, inherits all the features of the root type, and adds a representational scheme which supports the Gregorian calendar. The type representing OSAM*/T and T-Chimera also has two subtypes. The first subtype represents the TEDM model and has all the features of its supertype with the additional features of transaction and event time histories. The second subtype (which is also a subtype of the type representing T-3DIS from which it inherits the representational scheme) represents the TMAD model. This type has the additional feature of the transaction time history. A direct subtype of the types representing TEDM and TMAD represents the TOODM model. The type representing TOODM inherits the representational scheme from the type representing TMAD and the event time history from the type representing TEDM. It also adds unanchored primitives and the continuous time domain to its temporal structure. From Figure 23 it can reasonably be concluded that OSAM*/T and T-Chimera are the two least powerful temporal object models since they provide the least number of temporal features. The TOODM model is the most powerful since it provides the most number of temporal features. The comparison of different temporal object models made in this section shows that there is significant similarity in the temporal features supported by the models. In fact, the temporal features supported by OSAM*/T and T-Chimera are identical. The temporal features of TEDM are identical to those of OSAM*/T and T-Chimera in the temporal structure, temporal representation, and temporal order design dimensions. These commonalities substantiate the need for a temporal framework which combines the diverse features of time under a single infrastructure that allows design reuse. We also note that temporal object models have not really taken advantage of the richness of their underlying object model in supporting alternate features of a design dimension. They have assumed a set of fixed particular underlying notions of time. From a range of different temporal features, a single temporal feature is supported in most of the design dimensions. As such, not much advantage has been gained over the temporal relational models in supporting applications that have different temporal needs. For example, engineering applications like CAD would benefit from a branching time model, while time series and financial applications require multiple calendars and granularities. The temporal framework proposed in this work aims to exploit object-oriented technology in supporting a wide range of applications with diverse temporal needs.

5

Discussion and Conclusions

In this work the different design dimensions that span the design space of temporal object models are identified. Object-oriented techniques are used to design an

32


infrastructure which supports the diverse notions of time under a single framework. We demonstrate the expressiveness of the framework by showing how it can be used to accommodate the temporal needs of different real-world applications, and also reflect different temporal object models that have been reported in the literature. A similar objective is pursued by Wuu & Dayal [WD92] who provide an abstract time type to model the most general semantics of time which can then be subtyped (by the user or database designer) to model the various notions of time required by specific applications. The temporal framework presented here subsumes the work of Wuu & Dayal in that it provides the user or database designer with explicit types and properties to model the diverse features of time. Their approach requires significant support from the user, including specification of the temporal schema, which is a complex, and non-trivial task. It is therefore imperative for temporal object models to have a temporal infrastructure from which users can choose the temporal features they need. Using the object-oriented type system to structure the design space of temporal object models and identify the dependencies within and among the design dimensions helps us simplify the presentation of the otherwise complex domain of time. The framework is extensible in that additional temporal features can be added as long as the relationships between the design dimensions are maintained. The focus in this work is on the unified provision of temporal features which can be used by temporal object models according to their temporal needs. Once these are in place, the model can then define other object-oriented features to support its application domain. The temporal framework also provides a means of comparing temporal objects models according to the design dimensions identified in Section 2.1. This helps identify the strengths and weaknesses of the different models. The diverse features of time are also identified in [Sno95]. The focus however, is on comparing various temporal object models and query languages based on their ability to support valid and transaction time histories. In this work we show how the generic aspects of temporal models can be captured and described using a single framework. In [PLL96] a temporal reference framework for multimedia synchronization is proposed and used to compare existing temporal specification schemes and their relationships to multimedia synchronization. The focus however, is on different forms of temporal specification, and not on different notions of time. The model of time used concentrates only on temporal primitives and their representation schemes. The temporal framework has been implemented in C++. A toolkit has been developed which allows users/temporal model designers to interact with the framework at a high level and generate specific framework instances for their own applications. The next step is to build query semantics on top of the framework. This will involve addressing issues such as: how the choices of different design dimensions affect the query semantics; what kind of query constructs are needed; what properties should be provided; and how are these properties used, to name a few.


33

References All84. ATGL96.

BFG97.

BKP86.

BP85.

CG93.

Cho94.

CITB92.

CJR87.

CK94. CMR91.

CPP95.

CPP96.

CR88.

CS93.

J. F. Allen. Towards a General Theory of Action and Time. Artificial Intelligence, 23(123):123–154, July 1984. A-R. Adl-Tabatabai, T. Gross, and G-Y. Lueh. Code Reuse in an Optimizing Compiler. In Proc. of the Int’l Conf on Object-Oriented Programming: Systems, Languages, and Applications - OOPSLA ’96, pages 51–68, October 1996. E. Bertino, E. Ferrari, and G. Guerrini. T Chimera - A Temporal ObjectOriented Data Model. Theory and Practice of Object Systems, 3(2):103– 125, 1997. H. Barringer, R. Kuiper, and A. Pnueli. A Really Abstract Concurrent Model and its Temporal Logic. In Proc. of the 13th ACM Symposium on Principles of Programming Languages, pages 173–183, 1986. F. Barbic and B. Pernici. Time Modeling in Office Information Systems. In Proc. ACM SIGMOD Int’l. Conf. on Management of Data, pages 51–62, May 1985. T.S. Cheng and S.K. Gadia. An Object-Oriented Model for Temporal Databases. In Proceedings of the International Workshop on an Infrastructure for Temporal Databases, pages N1–N19, June 1993. J. Chomicki. Temporal Query Languages: A Survey. In D. Gabbay and H. Ohlbach, editors, Proceedings of the International Conference on Temporal Logic, pages 506–534. Lecture Notes in Computer Science, Vol. 827, Springer Verlag, July 1994. W.W. Chu, I.T. Ieong, R.K. Taira, and C.M. Breant. A Temporal Evolutionary Object-Oriented Data Model and Its Query Language for Medical Image Management. In Proc. 18th Int’l Conf. on Very Large Data Bases, pages 53–64, August 1992. R.H. Campbell, G.M. Johnston, and V.F. Russo. Choices (Class Hierarchical Open Interface for Custom Embedded Systems). Operating Systems Review, 21(3):9–17, 1987. S. Chakravarthy and S-K. Kim. Resolution of Time Concepts in Temporal Databases. Information Sciences, 80(1-2):91–125, September 1994. E. Corsetti, A. Montanari, and E. Ratto. Dealing with Different Time Granularities in Formal Specifications of Real-Time Systems. The Journal of Real-Time Systems, 3(2):191–215, 1991. C. Combi, F. Pinciroli, and G. Pozzi. Managing Different Time Granularities of Clinical Information by an Interval-Based Temporal Data Model. Methods of Information in Medicine, 34(5):458–474, 1995. C. Combi, F. Pinciroli, and G. Pozzi. Managing Time Granularity of Narrative Clinical Information: The Temporal Data Model TIME-NESIS. In L. Chittaro, S. Goodwin, H. Hamilton, and A. Montanari, editors, Third International Workshop on Temporal Representation and Reasoning (TIME’96), pages 88–93. IEEE Computer Society Press, 1996. J. Clifford and A. Rao. A Simple, General Structure for Temporal Domains. In C. Rolland, F. Bodart, and M. Leonard, editors, Temporal Aspects in Information Systems, pages 17–30. North-Holland, 1988. R. Chandra and A. Segev. Managing Temporal Financial Data in an Extensible Database. In Proc. 19th Int’l Conf. on Very Large Data Bases, pages 302–313, August 1993.

34 CSS94.


R. Chandra, A. Segev, and M. Stonebraker. Implementing Calendars and Temporal Rules in Next-Generation Databases. In Proc. 10th Int’l. Conf. on Data Engineering, pages 264–273, February 1994. DDS94. W. Dreyer, A.K. Dittrich, and D. Schmidt. An Object-Oriented Data Model for a Time Series Management System. In Proc. 7th International Working Conference on Scientific and Statistical Database Management, pages 186– 195, September 1994. DS93. C.E. Dyreson and R.T. Snodgrass. Valid-time Indeterminacy. In Proc. 9th Int’l. Conf. on Data Engineering, pages 335–343, April 1993. EGS93. O. Etzion, A. Gal, and A. Segev. Temporal Active Databases. In Proceedings of the International Workshop on an Infrastructure for Temporal Databases, June 1993. Flo91. R. Flowerdew. Geographical Information Systems. John Wiley and Sons, 1991. Volume 1. ¨ ¨ GLOS97. I.A. Goralwalla, Yuri Leontiev, M.T. Ozsu, and Duane Szafron. Modeling Temporal Primitives: Back to Basics. In Proc. Sixth Int’l. Conf. on Information and Knowledge Management, pages 24–31, November 1997. ¨ ¨ GOS97. I.A. Goralwalla, M.T. Ozsu, and D. Szafron. Modeling Medical Trials in Pharmacoeconomics using a Temporal Object Model. Computers in Biology and Medicine - Special Issue on Time-Oriented Systems in Medicine, 27(5):369 – 387, 1997. HKOS96. W.H. Harrison, H. Kilov, H.L. Ossher, and I. Simmonds. From Dynamic Supertypes to Subjects: a Natural way to Specify and Develop Systems. IBM Systems Journal, 35(2):244–256, 1996. JF88. R.E. Johnson and B. Foote. Designing Reusable Classes. Journal of ObjectOriented Programming, 1(2):22–35, 1988. KGBW90. W. Kim, J.F. Garza, N. Ballou, and D. Wolek. Architecture of the ORION Next-Generation Database System. IEEE Transactions on Knowledge and Data Engineering, 2(1):109–124, March 1990. KKR90. P.C. Kanellakis, G.M. Kuper, and P.Z. Revesz. Constraint Query Languages. In Proc. of the 9th ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, pages 299–313, April 1990. Kli93. N. Kline. An Update of the Temporal Database Bibliography. ACM SIGMOD Record, 22(4):66–80, December 1993. KS92. W. Kafer and H. Schoning. Realizing a Temporal Complex-Object Data Model. In Proc. ACM SIGMOD Int’l. Conf. on Management of Data, pages 266–275, June 1992. LEW96. J.Y. Lee, R. Elmasri, and J. Won. Specification of Calendars and Time Series for Temporal Databases. In Proc. 15th International Conference on Conceptual Modeling (ER’96), pages 341–356, October 1996. Proceedings published as Lecture Notes in Computer Science, Volume 1157, Bernhard Thalheim (editor), Springer-Verlag, 1996. MPB92. R. Maiocchi, B. Pernici, and F. Barbic. Automatic Deduction of Temporal Information. ACM Transactions on Database Systems, 17(4):647–688, 1992. PLL96. M.J. Perez-Luque and T.D.C. Little. A Temporal Reference Framework for Multimedia Synchronization. IEEE Journal on Selected Areas in Communications, 14(1):36–51, January 1996. PM92. N. Pissinou and K. Makki. A Framework for Temporal Object Databases. In Proc. First Int’l. Conf. on Information and Knowledge Management, pages 86–97, November 1992.

An Object-Oriented Framework for Temporal Data Models Rev90. RS91.

SA85.

SC91.

Sci94. Sno86. Sno87. Sno92.

Sno95.

Soo91. SRH90.

SS88. TK96. WD92.

WLH90.

35

P.Z. Revesz. A Closed Form for Datalog Queries with Integer Order. In International Conference on Database Theory, pages 187–201, 1990. E. Rose and A. Segev. TOODM - A Temporal Object-Oriented Data Model with Temporal Constraints. In Proc. 10th Int’l Conf. on the Entity Relationship Approach, pages 205–229, October 1991. R. Snodgrass and I. Ahn. A Taxonomy of Time in Databases. In Proc. ACM SIGMOD Int’l. Conf. on Management of Data, pages 236–246, May 1985. S.Y.W. Su and H.M. Chen. A Temporal Knowledge Representation Model OSAM*/T and its Query Language OQL/T. In Proc. 17th Int’l Conf. on Very Large Data bases, pages 431–442, 1991. E. Sciore. Versioning and Configuration Management in an ObjectOriented Data Model. The VLDB Journal, 3:77–106, 1994. R. Snodgrass. Research Concerning Time in Databases: Project Summaries. ACM SIGMOD Record, 15(4), December 1986. R.T. Snodgrass. The Temporal Query Language TQuel. ACM Transactions on Database Systems, 12(2):247–298, June 1987. R.T. Snodgrass. Temporal Databases. In Theories and Methods of SpatioTemporal Reasoning in Geographic Space, pages 22–64. Springer-Verlag, LNCS 639, 1992. R. Snodgrass. Temporal Object-Oriented Databases: A Critical Comparison. In W. Kim, editor, Modern Database Systems: The Object Model, Interoperability and Beyond, pages 386–408. Addison-Wesley/ACM Press, 1995. M.D. Soo. Bibliography on Temporal Databases. ACM SIGMOD Record, 20(1):14–23, 1991. M. Stonebraker, L.A. Rowe, and M. Hirohama. The Implementation of POSTGRES. IEEE Transactions on Knowledge and Data Engineering, 2(1):125–142, March 1990. R. Stam and R. Snodgrass. A Bibliography on Temporal Databases1. IEEE Database Engineering, 7(4):231–239, December 1988. V.J. Tsotras and A. Kumar. Temporal Database Bibliography Update. ACM SIGMOD Record, 25(1):41–51, March 1996. G. Wuu and U. Dayal. A Uniform Model for Temporal Object-Oriented Databases. In Proc. 8th Int’l. Conf. on Data Engineering, pages 584–593, Tempe, USA, February 1992. K. Wilkinson, P. Lyngbaek, and W. Hasan. The Iris Architecture and Implementation. IEEE Transactions on Knowledge and Data Engineering, 2(1):63–75, March 1990.

An Object-Oriented Framework for Temporal Data Models Iqbal A. Goralwalla, M. Tamer Ozsu, and Duane Szafron Laboratory for Database Systems Research Department of Computing Science University of Alberta Edmonton, Alberta, Canada T6G 2H1 {iqbal,ozsu,duane}@cs.ualberta.ca

A b s t r a c t . Most of the database research on modeling time has con-

centrated on the definition of a particular temporal model and its incorporation into a (relational or object) database management system. This has resulted in quite a large number of different temporal models, each providing a specific set of temporal features. Therefore, the first step of this work is a design space for temporal models which accommodates multiple notions of time, thereby classifying design alternatives for temporal models. The design space is then represented by exploiting object-oriented features to model the different aspects of time. An object-oriented approach allows us to capture the complex semantics of time by representing it as a basic entity. Furthermore, the typing and inheritance mechanisms of object-oriented systems allow the various notions of time to be reflected in a single framework. The framework can be used to accommodate the temporal needs of different applications, and derive existing temporal models by making a series of design decisions through subclass specialization. It can also be used to derive a series of new more general temporal models that meet the needs of a growing number of emerging applications. Furthermore, it can be used to compare and analyze different temporal object models with respect to the design dimensions.

1

Introduction

The ability to model the temporal dimension of the real world is essential for m a n y applications such as econometrics, banking, inventory control, medical records, real-time systems, multimedia, airline reservations, versions in C A D / C A M applications, statistical and scientific applications, etc. Database m a n a g e m e n t systems (DBMSs) that support these applications have to be able to satisfy temporal requirements. To a c c o m m o d a t e the temporal needs of different applications, there has been extensive research activity on temporal d a t a models in the last decade Sno86,SS88,Soo91,Kli93,TK96. Most of this research has concentrated on the O. Etzion, S. Jajodia, and S. Sripada (Eds,): Temporal Databases- Research and Practice

LNCS 1399, pp. 1-35, 1998.

(~) Springer-Verlag Berlin Heidelberg 1998

2

Iqbal A. Goralwalla, M. Tamer Ozsu, and Duane Szafron

definition of a particular temporal model and its incorporation into a (relational or object-oriented) database management system (DBMS). The early research on temporal data models concentrated on extending the relational data model to handle time in an appropriate manner. The notion of time, with its multiple facets, is difficult (if not impossible) to represent in one single relational model since it does not adequately capture data or application semantics. This is substantiated by most of the relational temporal models that only support a discrete and linear model of time. The general limitation of the relational model in supporting complex applications has led to research into next-generation data models, specifically object data models. The research on temporal models has generally followed this trend. Temporal object models can more accurately capture the semantics of complex objects and treat time as a basic component. There have been many temporal object model proposals (for example, RS91,SC91,WD92,KS92,CITB92,BFG97). These models differ in the functionality that they offer, however as in relational systems, they assume a set of fixed notions of time. Wuu & Dayal WD92 provide an abstract time type to model the most general semantics of time which can then be subtyped (by the user or database designer) to model the various notions of time required by specific applications. However, this requires significant support from the user, including specification of the temporal schema. Both (relational and object-oriented) approaches have led to the definition and design of a multitude of temporal models. Many of these assume a set of fixed notions about time, and therefore do not incorporate sufficient functionality or extensibility to meet the varying temporal requirements of today's applications. Instead, similar functionality is re-engineered every time a temporal model is created for a new application. Although most temporal models were designed to support the temporal needs of a particular application, or group of similar applications, if we look at the functionality offered by the temporal models at an abstract level, there are notable similarities in their temporal features: - Each temporal model has one or more temporal primitives, namely, time instant, time interval, time span, etc. The discrete or the continuous domain is used by each temporal model as a temporal domain over the primitives. Some temporal models require their temporal primitives to have the same underlying granularity, while others support multiple granularities and allow temporal primitives to be specified in different granularities. - Most temporal models support a linear model of time, while a few support a branching model. In the former, temporal primitives are totally ordered, while in the latter they have a partial order defined on them. All temporal models provide some means of modeling historical information about real-world entities and/or histories of entities in the database. Two of the most popular types of histories that have been employed are valid and transaction'time histories Sno87, respectively. -

-

These commonalities suggest a need for combining the diverse features of time under a single infrastructure that is extensible and allows design reuse. In this pa-


3

per, we present an object-oriented framework JF88 that provides such a unified infrastructure. An object-oriented approach allows us to capture the complex semantics of time by representing it as a basic entity. Furthermore, the typing and inheritance mechanisms of object-oriented systems directly enable the various notions of time to be reflected in a single framework. The objectives of this work are fourfold. Tile first objective is to identify the design dimensions that span the design space for temporal models. This will classify design alternatives for temporal models. The design space is then represented by exploiting object-oriented features to model the different aspects of time. The second objective is to show how the temporal framework can be tailored to accommodate real-world applications that have different temporal needs. The third objective is to show how the various existing temporal object models can be represented within this framework. The final objective is to use the framework to analyze and compare the different temporal object models based on the design dimensions. In particular, the RS91,SC91,KS92,PM92,CITB92,BFG97 temporal object models are considered. The work of Wuu &: Dayal WD92 and Cheng & Gadia CG93 (which follows a similar methodology as WD92) are not considered since they do not provide concrete notions of time in their models. Object models supporting versioning using time usually follow a structural embedding of temporality within type definitions KGBW90,WLH90,SRH90, Sci94. Thus, the notion of temporal objects is lost since the model knows nothing about temporality. Moreover, most temporal version models use the Bate function call which is provided by the system. For example, though the EXTRAV version model Sci94 supports "valid" and "transaction" time, it does so by timestamping attributes using system provided dates. This is limited in scope as no semantics of the various notions of time are provided. Since these models are not "temporal object models" in the strict sense of the term, we do not include them in this study. We can draw a parallel between our work and similar (albeit on a much larger scale) approaches used in Choices C JR87 and cmec ATGL96. Choices is a framework for operating system construction which was designed to provide a family of operating systems that could be reconfigured to meet diverse user~application requirements, cmcc is an optimizing compiler that makes use of frameworks to facilitate code reuse for different modules of a compiler. Similar to Choices and cmcc, the temporal framework presented in this paper can be regarded as an attempt to construct a family of temporal models. The framework can then be tailored to reflect a particular temporal model which best suits the needs of an application. A particular temporal model would be one of the many "instances" of the framework. The presentation of this paper is divided into five sections. Section 2 presents the temporal framework by identifying the design dimensions (key abstractions) for temporal models and the interactions between them. Section 3 illustrates how the temporal framework can be tailored to accommodate the temporal needs of different applications, and the temporal features of temporal object models. In Section 4 object-oriented techniques are used to compare and analyze different

4


temporal object models with respect to the design dimensions. Section 5 summarizes the work presented in this paper, discusses related work, and outlines avenues for future research.

2

The Architecture of the Temporal Framework

In order to accommodate the varying requirements that many applications have for temporal support, we first identify the design dimensions that span the design space for temporal models. Next, we identify the components or features of each design dimension. Finally, we explore the interactions between the design dimensions in order to structure the design space. These steps produce a framework which consists of abstract and concrete object types, and properties (abstractions of methods and attributes in traditional object-oriented terminology). The types are used to model the different design dimensions and their corresponding components. The properties are used to model the different operations on each component, and to represent the relationships (constraints) between the design dimensions. The framework classifies design alternatives for temporal models by providing types and properties that can be used to define the semantics of many different specific notions of time.

2.1

Design Dimensions

The design alternatives for temporal models can be classified along four design dimensions: 1. Temporal S t r u c t u r e -

provides the underlying ontology and domains for

time. 2. Temporal R e p r e s e n t a t i o n - provides a means to represent time so that it is

human readable. 3. Temporal Order - gives an ordering to time. 4. Temporal H i s t o r y - allows events and activities to be associated with time.

There are two parts to the description of a design dimension. First, we define a set of temporal features that the design dimension encompasses. Second, we explore relationships between the temporal features and describe the resulting design space for the design dimension. The design space consists of an architectural overview of abstract and concrete types corresponding to the temporal features, and a design overview which describes some of the key properties (operations) defined in the interface of the types. We do not describe the properties in detail since many of these are traditional temporal operations that have already appeared in the literature on temporal databases. We assume the availability of commonly used object-oriented features a t o m i c entities (reals, integers, strings, etc.); types for defining common features of objects; properties (which represent methods and instance variables) for specifying the semantics of operations that may be performed on objects; classes


5

which represent the extents of types; and collections for supporting general heterogeneous groupings of objects. In this paper, a reference prefixed by "T_" refers to a type, and "P_" to a property. A type is represented by a rounded box. An abstract type is shaded with a black triangle in its upper left corner, while a concrete type is unshaded. In Figures 5, 8, 9, and 15 the rectangular boxes are objects. Objects have an outgoing edge for each property applicable to the object which is labeled with the name of the property and which leads to an object resulting from the application of the property to the given object. A circle labeled with the symbols ~ } represents a container object and has outgoing edges labeled with "E" to each member object. T e m p o r a l S t r u c t u r e The first question about a temporal model is "what is its underlying temporal structure?" More specifically, what are the temporal primitives supported in the model, what temporal domains are available over these primitives, and what is the temporal determinacy of the primitives? Indeed, the temporal structure dimension with i~s various constituents forms the basic building block of the design space of any temporal model since it is comprised of the basic temporal features that underlie the model. We now give an overview of the features of a temporal structure and then identify the relationships that exist between them. Components 1. T e m p o r a l P r i m i t i v e s Temporal primitives can either be anchored (absolute) or unanchored (relative) Sno92. For example, 31 July 1995 is an anchored temporal primitive since we know exactly where it is located on the time axis, whereas 31 days is an unanchored temporal primitive since it can stand for any block of 31 consecutive days on the time axis. There is only one unanchored primitive, called the span. A span is a duration of time with a known length, but no specific starting and ending anchor points. There are two anchored primitives, the instant (moment, chronon) and the interval. An instant is a specific anchored moment in time, e.g., 31 July 1995. An interval is a duration of time between two specific anchor points (instants) which are the lower and upper bounds of the interval, e.g., 15 June 1995, 31 July 1995. 2. T e m p o r a l D o m a i n The temporal domain of a temporal structure defines a scale for the temporal primitives. A temporal domain can be continuous or discrete. Discrete domains map temporal primitives to the set of integers. That is, for any temporal primitive in a discrete time domain, there is a unique successor and predecessor. Continuous domains map temporal primitives to the set of real numbers. Between any two temporal primitives of a continuous time domain, another temporal primitive exists. Most of the research in the context of temporal databases has assumed that the temporal domain is discrete. Several arguments in favor of using a discrete temporal domain are made by Snodgrass Sno92 including the

6

Iqbal A. Goralwalla, M. Tamer C}zsu, and Duane Szafron

imprecision of clocking instruments, compatibility with natural language references, possibility of modeling events which have duration, and practicality of implementing a continuous temporal data model. However, Chomicki Cho94 argues that the continuous (dense) temporal domain is very useful in mathematics and physics. Furthermore, continuous time provides a useful abstraction if time is thought of as discrete but with instants that are very close. In this case, the set of time instants may be very large which in turn may be difficult to implement efficiently. Chomicki further argues that query evaluation in the context of constraint databases KKR90,Revg0 has been shown to be easier in continuous domains than in discrete domains. Continuous temporal domains have also been used to facilitate full abstract semantics in reasoning about concurrent programs BKP86. 3. T e m p o r a l D e t e r m i n a c y There are many real world cases where we have complete knowledge of the time or the duration of a particular activity. For example, the time interval allowed for students to complete their Introduction to Database Management Systems examination is known for certain. This is an example of a determinate temporal primitive. However, there are cases when the knowledge of the time or the duration of a particular activity is known only to a certain extent. For example, we do not know the exact time instant when the Earth was formed though we may speculate on an approximate time for this event. In this case, the temporal primitive is indeterminate. Indeterminate temporal information is also prevalent in various sources such as granularity, dating techniques, future planning, and unknown or imprecise event times DS93. Since the ultimate purpose of a temporal model is to represent real temporal information, it is desirable for such a model to be able to capture both determinate and indeterminate temporal primitives. D e s i g n S p ace Figure 1 shows the building block hierarchy of a temporal structure. The basic building block consists of anchored and unanchored temporal primitives. The next building block provides a domain for the primitives that consists of discrete or continuous temporal primitives. Finally, the last building block of Figure 1 adds determinacy. Thus, a temporal structure can be defined by a series of progressively enhanced temporal primitives. Figure 2 gives a detailed hierarchy of the different types of temporal primitives that exist in each of the building blocks of Figure 1. Based on the features of a temporal structure, its design space consists of 11 different kinds of temporal primitives. These are the determinacy-domain-based temporal primitives shown in Figure 2 and described below. C o n t i n u o u s t i m e i n s t a n t s a n d intervals. Continuous instants are just points on the (continuous) line of all anchored time specifications. They are totally ordered by the relation "later than." Since in theory, continuous instants have infinite precision, they cannot have a period of indeterminacy. Therefore, continuous indeterminate time instants do not


7

Determinacy-Domain-based I I Domain-base6 Temporal I Temporal Primitives Primitives Temporal

~.=_;,.. ^~ v,,,,,,t,vu=

I i _ I '

+

Ij

'r determinacy/ ~, indeterminacy discrete/continuous domain W-+

Fig. 1. Building a Temporal Structure

exist in Figure 2. However, continuous intervals can be determinate or indeterminate. The difference between them is that a continuous determinate interval denotes that the activity associated with it occurs during the whole interval, while a continuous indeterminate interval denotes that the activity associated with it occurs sometime during the interval. Continuous intervals have lower and upper bounds which are continuous instants. Discrete t i m e i n s t a n t s a n d i n t e r v a l s . Assume that somebody has been on a train the whole day of 5 January 1997. This fact can be expressed using a determinate time instant 5 January 1997get (which means the whole day oJ). However, the fact that somebody is leaving for Paris on 5 January 1997 can be represented as an indeterminate time instant 5 January 1997indet (which means some time on that day). Hence, each discrete time instant is either determinate or indeterminate, corresponding to the two different interpretations. Discrete time instants are analogous to continuous time intervals. Every determinate (indeterminate) discrete time instant has a granularity (Gi) associated with it. This granularity determines the mapping of the given determinate (indeterminate) discrete time instant Idet (Iindet) to the domain of continuous time instants. The mapping is defined as follows:

Idet ~ Icont, Icont + Gi) ~naet ~-~ cont "~ Icont + G~) Here Icont denotes the counterpart of Idet and Iindet in the domain of continuous time instants. This is exemplified by the mapping of the discrete determinate instant 5 January 1997det to the continuous determinate interval 5 January 1997cont, 6 January 1997eont). In this case Gi = Gdays = 1 day. A formal treatment of the different types of instants and mappings is given in GL(}S97. Discrete time instants can be used to form discrete time inte~als. Since we have determinate and indeterminate discrete instants, we also have determinate and indeterminate discrete intervals. Determinate (indeterminate) time instants can be used as boundaries of determinate (indeterminate) time intervals. T i m e s p a n s . Discrete and continuous determinate spans represent complete information about a duration of time. A discrete determinate span

8

Iqbal A. Goralwalla, M. Tamer Ozsu, and Duane Szafron Temporal Structure Design Space

........................... Determlnacy-Oornain-lbased TemporalPrimitives ~.: DeterminateDiscreteInstants i IndeterminateDiscreteInstarCs

Domain-baNd Temporal Primitives

,- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i TemporalPrimittvm

~ i Z

',

: AnchoredPrimitives

', /

~

\

~

i ', TemporalStructure/

', " "

DiscreteInstants ~

', ContinuousInstants ',

' = DeterminateContinuousInstants

', ', ', ', ', ' DeterminateDiscrete Intewals i : DiscretelateP~Lsi,~--~ ~--~"~" : , : , IndeterminateDiscreteIntervals Z ' "

'ate~~

P_calGranularities 1582years

(

Fig. 5. Temporal Representational Examples

T e m p o r a l O r d e r We now have the means of designing the temporal structure and the temporal representation of a temporal model. The next step is to provide an ordering scheme for the temporal primitives. This constitutes the third building block of our design space. C o m p o n e n t s . A temporal order can be classified as being linear or branching In a linear order, time flows from past to future in an ordered manner. In


13

a branching order, time is linear in the past up to a certain point, when it branches out into alternate futures. The structure of a branching order can be thought of as a tree defining a partial order of times. The trunk (stem) of the tree is a linear order and each of its branches is a branching order. The linear model is used in applications such as office information systems9 The branching order is useful in applications such as computer aided design and planning or version control which allow objects to evolve over a nonlinear (branching) time dimension (e.g., multiple futures, or partially ordered design alternatives). D e s i g n Space. The different types of temporal orders are dependent on each other. A sub-linearorder is one in which the temporal primitives (time intervals) are allowed to overlap, while a linearorder is one in which the temporal primitives (time intervals) are not allowed to overlap9 Every linear order is also a sub-linear order. A branching order is essentially made up of sub-linear orders. The relationship between temporal orders is shown in Figure 6.

9

sub-Linear

Order Temporal Order

js-a Linear Order

I composed-of Branching Order

Fig. 6. Temporal Order Relationships

The hierarchy in Figure 7 gives the various types and properties which model different temporal orders 2.

~T T_temporalOrder

T_linearOrder

~ P_branchingOrder


Supertype

subLinearO~er )----~(

T branchingOrder )

P__root Pbranches Pin

Subtype

Fig. 7. The Hierarchy of Temporal Orders

We do not consider periodictemporal orders in this work. These can easily be incorporated as a subtype of T_temporalOrder.

14

Iqbal A. Goralwalla, M. Tamer (gzsu, and Duane Szafron

Example 2. Consider the operations that take place in a hospital on any particular day. It is usually the case that at any given time multiple operations are taking place. Let us assume an eye cataract surgery took place between 8am and 10am, a brain tumor surgery took place between 9am and 12pm, and an open heart surgery took place between 7am and 2pm on a certain day. Figure 8 shows a pictorial representation of operationsOrder, which is an object of type T_subLinear0rder. operationsOrder consists of the time intervals 08:00,10:00, 09:00,12:00, 07:00,14:00, and does not belong to any branching timeline. As seen in the figure, operationsOrder consists of intervals (representing the time periods during which the different surgeries took place) that overlap each other. Hence, operationsOrder is an example of a sub-linear order.

operationsOrderP_branchingOrder~ ~P_temporalPrimitives

08:00,10: 800~ 09:00,12:00 I ~ 07:00,14:00 Fig. 8. An Example of a Sub-Linear Order.

Example 3. To illustrate the use of objects of type T_linearOrder which are total linear temporal orders, consider a patient with multiple pathologies, for example as a result of diabetes. The patient has to attend several special clinics, each on a different day. Hence, it follows that since the patient cannot attend more than one special clinic on any day, the temporal order of the patient's special clinics visit history is linear and totally ordered. Suppose the patient visited the opthalmology clinic on 10 January 1995, the cardiology clinic on 12 January 1995, and the neurology clinic on 3 February 1995. Figure 9 shows a pictorial representation of specialClinicOrder, which is an object of type T _ l i n e a r 0 r d e r . As seen in the figure, speciaiClinicOrder is totally ordered as its time intervals do not overlap. Example 4. Consider an observational pharmacoeconomic analysis of the changing trends, over a period of time, in the treatment of a chronic illness such as asthma GC)$97. The analysis would be performed using information gathered over a time period. At a fixed point during this period new guidelines for the treatment of asthma were released. At that point the population of patients


I specialClinicOrder

15

IP-branchingOrder~-~


()

Fig. 9. An Example of a Linear Order.

known to have asthma are divided into those whose doctors continue the old established treatment, and those whose doctors, in accordance with new recommendations, change their treatment. Thus, the patients are divided into two groups, each group undergoing a different treatment for the same illness. The costs and benefits accrued over the trial period for each treatment are calculated. Since such a study consists of several alternative treatments to an illness, a branching timeline is the natural choice for modeling the timeline of the study. The point of branching is the time when the new guidelines for the treatment of the illness are implemented. Figure 10 shows the branching timeline for such a medical trial history.

(time when new guidelines

are

released)

Fig. 10. An Example of a Branching Order.

The same branching timeline could as easily handle the situation where different versions of a particular treatment, say Treatment A, are implemented based on certain parameters. In this case, the "Treatment A" branch would in turn branch at a certain point into different Treatment A versions. This situation is also depicted in Figure 10.

Temporal H i s t o r y

So far we have considered the various features of time; its structure, the way it is represented, and how it is ordered. The final building

16


block of the design space of temporal models makes it possible to associate time with entities to model different temporal histories. C o m p o n e n t s . One requirement of a temporal model is an ability to represent and manage real-world entities as they evolve over time and assume different states (values). The set of these values forms the temporal history of the entity. Two basic types of temporal histories are considered in databases which incorporate time. These are valid and transaction time histories SA85. Valid time denotes the time when an entity is effective (models reality), while transaction time represents the time when a transaction is posted to the database. Usually valid and transaction times are the same. Other temporal histories include event time RS91,CK94 and decision time EGS93 histories. Event (decision) time denotes the time the event occured in the reM-world. Valid, transaction, and event times have been shown to be adequate in modeling temporal histories CK94. Design Space. Since valid, transaction, and event time histories have different semantics, they are orthogonal. Figure 11 shows the various types that could be used to model these different histories. A temporal history consists of objects and their associated timestamps.

P_history

T_history

~

0

) P_temporalOrder P_insert P_remove bjects

( T_validHistory; IT_transactionHistory1 I "l_eventHistory) Fig. 11. The Types and Properties for Temporal Histories

Property P_history defined in T_history returns a collection of all timestamped objects that comprise the history. A history object also knows the temporal order of its temporal primitives. The property P_temporalOrder returns the temporal order (which is an object of type T_temporal0rder) associated with a history object. The temporal order basically orders the time intervals (or time instants) in the history. Another property defined on history objects, P_insert, timestamps and inserts an object in the history. Property P_remove drops a given object from the history at a specified temporal primitive. The P_getObjects property allows the user to get the objects in the history at (during) a given temporal primitive. The properties defined on T_history are refined in T_validHistory, T _ t r a n s a c t i o n H i s t o r y , and T_eventHistory types to model the semantics of the different kinds of histories. Moreover, each history type can define additional properties, if nec-


17

essaxy, to model its particular semantics. The clinical example described in Section 3.1 illustrates the use of the properties defined on T_history.

2.2

Relationships between Design Dimensions

In the previous section we described the building blocks (design dimensions) for temporal models and identified the design space of each dimension. We now look at the interactions between the design dimensions. This will enable us to put the building blocks together and structure the design space for temporal models. A temporal history is composed of entities which are ordered in time. This temporal ordering is over a collection of temporal primitives in the history, which in turn are represented in a certain manner. Hence, the four dimensions can be linked via the "has-a" relationship shown in Figure 12.

TemporalModelOesignSpace ~ _ ~ Temporal History

Valid Transaction Event

hasI Temporal O r ~ r

~

|

has~ Temporal Structure

has

~ - - sub-Linear Linear ~ Branching

- -

Determinate Discrete Instants

-~

Indeterminate Discrete Instants Determinate Continuous Instants

--

Determinate Discrete Intervals

--

Indeterminate Discrete Intervals

---

Determinate Continuous Intervals Indeterminate Continuous Intervals

--

Determinate Discrete Spans

--

Indeterminate Discrete Spans

--

Determinate Continuous Spans

--

Indeterminate Continuous Spans

Gregorian Temporal Ropm~nmtian

i

Academic Business Financial

Fig. 12. Design Space for Temporal Models

18

Iqbal A. Goralwalla, M. Tamer C)zsu, and Duane Szafron

Basically, a temporal model can be envisioned as having a notion of time, which has an underlying temporal structure, a means to represent the temporal structure, and different temporal orders to order the temporal primitives within a temporal structure. This notion of time, when combined with application objects can be used to represent various temporal histories of the objects in the temporal model. Figure 12 gives the design space for temporal models. A temporal model can support one or more of valid, transaction, event, and user-defined histories. Each history in turn has a certain temporal order. This temporal order has properties which are defined by the type of temporal history (linear or branching). A linear history may or may not allow overlapping of anchored temporal primitives that belong to it. If it does not allow overlapping, then such a history defines a total order on the anchored temporal primitives that belong to it. Otherwise, it defines a partial order on its anchored temporal primitives. Each order can then have a temporal structure which is comprised of all or a subset of the 11 different temporal primitives that are shown in Figure 2. Finally, different calendars can be defined as a means to represent the temporal primitives. The four dimensions are modeled in an object system by the respective types shown in Figure 13. The "has a" relationship between the dimensions is modeled using properties as shown in the figure. An object of T_ternporalHistory represents a temporal history. Its temporal order is obtained using the P_tempora1Order property. A temporal order is an object of type T_temporali3rder and has a certain temporal structure which is obtained using the P_temporaIPrimitives property. The temporal structure is an object of type T _ t e m p o r a l S t r u c t u r e . The property P_calendar gives the instance of T_calendar which is used to represent the temporal structure.

~ T temporalFramework 1

I T_calendar ) ~rT_tePOalStructure) ~T_temporalOrderI ~T_temporalHistory 1 P_calendar

P_temporaIPrimitives

P_temporatOrder

Fig. 13. Relationships between Design Dimensions Types

The relationships shown in Figure 13 provide a temporal framework which encompasses the design space for temporal models. The detailed type system, shown in Figure 14, is based on the design dimensions identified in Section 2 and their various features which are given in Figures 3, 7, and 11. As described in Section 2.1, refactoring of types and multiple inheritance can be used to handle identical properties that are defined over different types in the inheritance


19

hierarchy shown in Figure 14. The framework can now be tailored for the temporal needs of different applications and temporal models. This is illustrated in Section 3.

~ 'cus

P_~red I_OOtDlSelnstant

\

Pjucc. p~red

p calElements /PjddD~ra~ion

~_cletDisclnterval1

P subD.~a,~

P after

detContlnstant

P lb, pub, P_leng~h P overlaps, P durin$ _ etCont|r~te~tal P_starts, P~ni~les, P_meets P uniaa ~-P_inter-~ctz~ IndetContlnterval1 P di~rer, ce

~1~temporalFramewe~ ,~ P_calGranularities

PJb, P_ub

3//

P_branchingOrder

temporalOrder K

Su~,~pe

=

\ P temporaIPrimitives

~.(

I

.~

T - history Phistory

~

P - temporalOrder

~

P insert P_remove e~etObjects

"l P branches

)

~

~

~ T__transactionHistory1 T .... tHistoryl J Subtype

Fig. 14. The Inheritance Hierarchy for the Temporal Framework

3

Tailoring the Temporal Framework

In this section, we illustrate how the temporal framework that is defined in Section 2 can be tailored to accommodate applications and temporal models

20

Iqbal A. Goralwalla, M. Tamer (~zsu, and Duane Szafron

TemporalHistory tlmeStampedMIcrobiology ItlmeStampedHematologyl ~

tlmeStampedHematology2

(aBIoodTest,aTImeStamp)~ , . .

P_insert

P"N"

T'??m?

~

TP history j x ~ j ,

.~

timestampedbloodtests ,?me??m?! ..........

P_temporalOrder

P

'- .......................

: i

~

;_-;Z:L;;4.;;&-,:I

r ~ I '5~a~ .

.

.

.

.

.

..............................

~ F .

.

.

kLSJ ~ q20,e~r..~m,,5 I .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

I P_funaions

TemporalRepresentation

1582years

..............................~

-

~

Fig. 15. A Patient's Blood Test History

which have different temporal requirements. In the first two sub-sections, we give examples of two real-world applications that have different temporal needs. In the last sub-section, we give an example of a temporal object model and show how the model can be derived from the temporal framework.

3.1

Clinical D a t a M a n a g e m e n t

In this section we give a real-world example from clinical data management that illustrates the four design dimensions and the relationships between them which were discussed in Section 2. During the course of a patient's illness, different blood tests are administered. It is usually the case that multiple blood tests of the patient are carried out on the same day. Suppose the patient was suspected of having an infection of the blood, and therefore had two different blood tests on 15 January 1995. These were the diagnostic hematology and microbiology blood tests. As a result of a very raised white cell count the patient was given a course of antibiotics while


21

the results of the tests were awaited. A repeat hematology test was ordered on 20 February 1995. Suppose each blood test is represented by an object of the type T_bloodTest. The valid history of the patient's blood tests can then be represented in the object database as an object of type T_validHistory. Let us call this object bloodTestHistory. To record the hematology and microbiology blood tests, the objects microbiology, hematologyl, and hematology2 with type T_bloodTest are first created and then entered into the object database using the following property applications:

bloodTestHistory.P_insert (microbiology, 15 January 1995) bloodTestHistory.P_insert(hematologyl, 15 January 1995) bloodTestNistory.P_insert (hematology2, 20 February 1995) If subsequently there is a need to determine which blood tests the patient took in January 1995, this would be accomplished by the following property application:

bloodTestHistory.P_getObjeets(1 January 1995, 31 January 1995) This would return a collection of timestamped objects of T_bloodTest representing all the blood tests the patient took in January 1995. These objects would be the (timestamped) hematologyl and the (timestamped) microbiology. Figure 15 shows the different temporal features that are needed to keep track of a patient's blood tests over the course of a particular illness. The figure also illustrates the relationships between the different design dimensions of the temporal framework. The patient has a blood test history represented by the object bloodTestHistory. The P_history property when applied to bloodTestHistory results in a collection object whose members are the timestamped objects timeStampedMicrobiology, timeStampedHematologyl, and timeStampedHematology2. The P_insert property updates the blood test history (bloodTestHistory) by inserting an object of type T_bloodTest at a given anchored temporal primitive. Similarly, the property P_remove updates the bloodTestHistory by removing an object of type T_bloodTest at a given anchored temporal primitive. The P_getObjects property returns a collection of timestamped blood test objects when given an anchored temporal primitive. Applying the property P_temporalOrder to bloodTestHistory results in the object bloodTestOrder which represents the temporal order on different blood tests in bloodTestHistory, bloodTestOrder has a certain temporal structure which is obtained by applying the P_temporalPrimitives property. Finally, the primitives in the temporal structure are represented using the Gregorian calendar, Gregorian and the calendric granularities year, month, and day. Let us now consider the various temporal features required to represent the different blood tests taken by a patient. Anchored, discrete, and determinate temporal primitives are required to model the dates on which the patient takes different blood tests. These dates are represented using the Gregorian calendar.

22


Since the blood tests take place on specific days, the temporal primitives during which the patient took blood tests form a total order. Lastly, a valid time history is used to keep track of the different times the blood tests were carried out. To support these temporal features, the temporal framework can be reconfigured with the appropriate types and properties. These are given in Figure 16.

_

/ 2_~ P_origin P_caIGranularities P_functions

T _ t e m p o r a l F r a m e w o r k

T_temporalOrder~

P_lb,P_ub,P_length P_overlaps,P_during Pjtarts,P~nishes,Pmeets P_union P_intersection

~

_

9

J

'

p_difference

T_linearOrder1

P_temporaIPrimitives

~V

T_history

~-~

T validHistory1

P_history P temporalOrder P_insert

super~pe

P remoye P ~O~

subtype,.

Fig. 16. The Temporal Framework Inheritance Hierarchy for the Clinical Application

3.2

Time Series Management

The management of time series is important in many application areas such as finance, banking, and economic research. One of the main features of time series management is extensive calendar support DDS94,LEW96. Calendars map time points to their corresponding data and provide a platform for granularity conversions and temporal queries. Therefore, the temporal requirements of a time series management system include elaborate calendric functionality (which allows the definition of multiple calendars and granularities) and variable temporal structure (which supports both anchored and unanchored temporal primitives, and the different operations on them). Figure 17 shows how the temporal requirements of a time series management system can be modeled using the types and properties of the temporal


~

23

T_OetDisclnst1ant

P calendar

T temporalStructum /

~_temporalFramework

P_before

~

\

e_lb, pub,

P length p_overlaps, P_during p_sta~s, P.finishes, Pmeets P_union

P_int~Cfi:

LT_ea.ndarI ~upertype

J\

P origin P calGranularities P Junctions

(

~~~T-detDiscSpan1 P_add,P_subtract P_coefficient P_calGranularities

Subtype=

Fig. 17. The Temporal Framework Inheritance Hierarchy for Time Series Management

framework. We note from the figure that only the temporal structure and temporal representation design dimensions are used to represent the temporal needs of a time series. This demonstrates that it is not necessary for art application requiring temporal features to have all four design dimensions in order to be accommodated in the framework. One or more of the design dimensions specified in Section 2.1 can be used as long as the design criteria shown in Figure 12 holds.

3.3

TOODM - A Temporal Object-Oriented Data Model

In this section, we identify the temporal features of Rose & Segev's temporal object-oriented data model (TOODM) RS91 according to the design dimensions described in Section 2.1, and show how these can be accommodated in the temporal framework. We specifically concentrate on TOODM since it uses object types and inheritance to model temporality. The temporal features of the rest of the reported temporal object models SC91,KS92,CITB92,PM92,BFG97 are summarized and compared in Section 4. We first give an overview of the temporal features of TOODM and then show how these features can be derived using the types and properties of our temporal framework. There is no doubt that TOODM has more functionality to offer in addition to temporality, but presenting that is beyond the scope of this work. O v e r v i e w of T e m p o r a l F e a t u r e s TOODM was designed by extending an object-oriented entity-relationship data model to incorporate temporal structures and constraints. The functionality of TOODM includes: specification and

24

II


Structure

II Representation

Order

I History

Primitives Domain Determinacy Anchored Continuous Determinate Gregorian Calendar Total Linear Valid Unanchored Transaction Event Table 1. Temporal Design Dimension Features of TOODM

enforcement of temporal constraints; support for past, present, and future time; support for different type and instance histories; and allowance for retro/proactive updates. The type hierarchy of the TOODM system defined types used to model temporality is given in Figure 18. The boxes with a dashed border represent types that have been introduced to model time, while the rest of the boxes represent basic types.

TST

i.........

l J

,,

"i

i ,

t ,

, ,

,.__%.,

Fig. 18. System Defined Temporal Types in TOODM

The Object type is the root of the type tree. The type V-Class is used to represent user-defined versionable classes. More specifically, if the instance variables, messages/methods, or constraints of a type are allowed to change (maintain histories), the type must be defined as a subtype of V-Class. The Ptypes type models primitive types and is used to represent objects which do not have any instance variables. Ptypes usually serve as domains for the instance variables of other objects. The Time primitive type is used to represent temporal primitives. The TP type represents time points, while the TI type represents time intervals. Time points can have specific different calendar granularities, namely Year, Month, Day, Week, Hour, Minute, and Second. The TS T type represents a time sequence which is a collection of objects ordered on time. TS IT is a parametric type with the type T representing a user or system defined type upon which a time sequence is being defined. For


25

every time-varying attribute in a (versionable) class, a corresponding subclass (of IS T ) is defined to represent the time sequence (history) of that attribute. For example, if the salary history of an employee is to be maintained, a subclass (e.g., TS Salary ) of TS IT has to be defined so that the salary instance variable in the employee class (which is defined as a subclass of V-Class) can refer to it to obtain the salary history of a particular employee. The history of an object of type TS IT is represented as a pair , where T is the data type and TL defines the different timelines and their granularities that are associated with T. Three timelines are allowed in TOODM: valid time, record (transaction) time, and event time (the time an event occurred). Each timeline associated with an object is comprised of time points or time intervals and has an underlying granularity. R e p r e s e n t i n g t h e T e m p o r a l F e a t u r e s of T O O D M in t h e T e m p o r a l F r a m e w o r k TOODM supports both anchored and unanchored primitives. These are modeled by the Absolute and R e l a t i v e types shown in Figure 18. The anchored temporal primitives supported are time instants and time intervals. A continuous time domain is used to perceive the temporal primitives. Finally, the temporal primitives are determinate. Time points and time intervals are represented by using the Gregorian calendar with granularities Year, Month, Day, Week, Hour, Minute, and Second. Translations between granularities in operations are provided, with the default being to convert to the coarser granularity. A (presumably total) linear order of time is used to order the primitives in a temporal sequence. TOODM combines time with facts to model different temporal histories, namely, valid, transaction, and event time histories. Table 1 summarizes the temporal features (design space) of TOODM according to the design dimensions for temporal models that were described in Section 2.1. Figure 19 shows the type system instance of our temporal framework that corresponds to the TOODM time types shown in Figure 18 and described in Table 1. The Time primitive type is represented using the T_temporalStructure type. The TP and TI types are represented using the T_instant and T_interval types, respectively. Similarly, the R e l a t i v e type is represented using the T_unanchPrim type. Since TOODM supports continuous and determinate temporal primitives, the (concrete) types T_detContInstant, T_detContInterval, and T_detContSpan are used to model continuous and determinate instants, intervals, and spans, respectively. The Gregorian calendar and its different calendric granularities are modeled using the T_calendar type. Time points and time intervals are ordered using the T_linear{rder type. Time sequences represented by the TS IT type are modeled by the history types in the temporal framework. More specifically, valid time (vt), record time (rt), and event time (et) are modeled using the T_validHistory, T _ t r a n s a c t i o n H i s t o r y , and T_eventHistory types. TOODM models valid, transaction and event histories all together in one structure as shown by the TS Salary type in the previous section. Our tern-

26


~T_detContlnstant 1 / P-~q,P~'~ P_elapsed P calendar P_calEleme~s

~T_detContlnter 3

~r_temporalStructure j\ P before

P_Ib, p_ub, p~'n~h

l"_,n,,ert,~s, e_du,ing pjtarts, Pjinishes, P_meets P union P_inter'~ction

\

Pafter

P_origin P_calGranularities P.functions

P_add, Pjubtmct P_coefficient P_caIGranularities

T_temporalFramework P3emporaIPrimitives

t

T hi~ory P_history P_iemporalOrder P insert Premove P_getObjects

Subtype

Fig. 19. The Temporal Framework Inheritance Hierarchy for TOODM

poral framework, however, provides different types to model valid, transaction, and event histories to allow their respective semantics to be modeled. Moreover, it uses properties to access the various components of histories. For example, to represent the valid history of an employee's salary an object of type T_validHistory is first created. The P_insert property then inserts objects of type T_integer (representing salary values) and objects of type T_interval (representing time intervals) into the salary valid history object. The transaction and event time histories of the salary are similarly represented, except in these histories the P_insert property inserts timestamps which are time instants (i.e., objects of type T_instant). 4

Comparison

of Temporal

Object

Models

In this section we use the temporal framework to compare and analyze the temporal object models RS91,SC91,KS92,CITB92,PM92,BFG97 that have appeared in recent literature, The temporal features of these models are summarized in Tables 1 and 2. Our criteria in comparing different temporal object


27

models is based on the design dimensions identified in Section 2.1. It is true that the models may have other (salient) temporal differences, but our concern in this work is comparing their temporal features in terms of the framework defined in Section 2. Similar to the methodology used in Section 2, object-oriented techniques are used to classify temporal object models according to each design dimension. This gives us an indication of how temporal object models range in their provision for different temporal features of a design dimension - from the most powerful model (i.e., the one having the most number of temporal features) to the least powerful model (i.e., the one having the least number of temporal features).

Model )

Structure

Representation)) Order History

Primitives Domain Determinacy OSAM*/T Anchored Discrete Determinate N/A TMAD Anchored Discrete Determinate Gregorian Calendar TEDM Anchored Discrete Determinate N/A Anchored Discrete Determinate Gregorian Calendar T-Chimera Anchored Discrete Determinate N/A T-3DIS

Linear Valid Linear Valid Transaction Linear Valid Transaction Event Partial Valid Linear Valid

Table 2. Design Dimension Features of different Temporal Object Models

T e m p o r a l S t r u c t u r e . It can be noticed from Tables 1 and 2 that most of the models support a very simple temporal structure, consisting of anchored primitives which are discrete and determinate. In fact, all models in Table 2 support the s a m e temporal structure, which consists of discrete and determinate anchored temporal primitives. These primitives can be accommodated in the temporal framework by the T_anchPrim, T_insZant, T_detDiscinstant, T_interval, and T _ d e t D i s c l n t e r v a l types, and their respective properties. The temporal structure of TOODM is slightly enhanced with the presence of unanchored primitives. TOODM is also the only model that supports the continuous temporal domain. Figure 20 shows how the type inheritance hierarchy is used to classify temporal object models according to their temporal structures. The temporal structures of OSAM*/T, TMAD, TEDM, T-3DIS, and T-Chimera can be modeled by a single type - that representing temporal primitives that are anchored, discrete, and determinate. This means that any of these models can be used to provide temporal support for applications that need a temporal structure comprised of anchored temporal primitives which are discrete and determinate. Similarly, the temporal structure of TOODM can be

28

Iqbal A. Goralwalla, M. Tamer Ozsu, and Duane Szafron be modeled by a type which represents anchored and unanchored temporal primitives that are continuous and determinate. This implies that TOODM is the only model that can support applications requiring a continuous time domain, or unanchored temporal primitives.

OSAM*rr,TMAD,TEDM,T-3DIS,T_Chimera /-

.~'Anchored, Determinate,& Discrete 1 nchored & Determinate

t

~'~(

TemporalPrimitives

)

TemporalPrimitives

L,"~ Supertype

Anchored&Unanchomd,TemporaiDeterm &iContinuous nateprimitves 1 TOODM

Subtype

Fig. 20. Classification of Temporal Object Models according to their Temporal Structures T e m p o r a l R e p r e s e n t a t i o n . Temporal primitives in the OSAM*/T SC91, TEDM CITB92, and T-Chimera BFG97 models are simply represented using natural numbers. The models do not provide any additional representational scheme which supports calendars and different granularities. The granularity of the temporal primitives is dependent on the application using the model. When a calendric representational scheme is provided for the temporal primitives, it is comprised of a single underlying calendar, which is usually Gregorian. This is the case in the TOODM RS91, TMADKS92, and T-3DIS PM92 models. T e m p o r a l O r d e r . All models shown in Tables 1 and 2, except T-3DIS, support a linear temporal order. The T-3DIS model supports a sub-linear temporal order. These temporal orders are accommodated in the temporal framework using the T_subLinear0rder and T_linear0rder types. Figure 21 shows how the models can be classified in an inheritance type hierarchy according to their temporal orders. The type modeling a partial linear order of time sits at the root of the hierarchy and represents the T-3DIS model. Since a total linear order is also a partial order, the models supporting total linear orders can be represented by a direct subtype of the root type. T e m p o r a l History. Tables 1 and 2 show how the temporal object models range in their support for the different types of temporal histories. Figure 22 shows how the models can be classified according to the temporal histories they support using a type inheritance hierarchy. The root type in Figure 22 represents the models which only support valid time histories. These are the


29

TOODM,OSAM*/T,TMAD, TEDM,T~-Chimera

T-3#OIS (

(

~ PartialLinearOrders. ~ ' ~

LinearOrders I

Supertype

Subtype

Fig. 21. Classification of Temporal Object Models according to their Temporal Orders

OSAM*/T, T-3DIS, and T-Chimera models. A direct subtype of the root type inherits the valid time history and provides transaction time history as well. This type represents the TMAD model. Similarly, the rest of the subtypes inherit different histories from their supertypes and add new histories to their type as shown in Figure 22. From Figure 22, we see that applications requiring only valid time histories can be supported by all models; applications requiring valid and transaction time can be supported by the TMAD, TEDM, and TOODM models; and applications requiring valid, transaction, and event time can be supported by the TEDM and TOODM models.

OSAM*/T,T-3DIS, T-Chimer~ I ValidTime "~ History ~ Supertype

TM#AD Valid&Transaction~ TimeHistory

TOOD~,TEDM Valid&Transaction& Event 1 TimeHistory Subtype

Fig. 22. Classification of Temporal Object Models according to their Temporal Histories Overall Classification. Having classified the temporal object models according to the individual design dimensions, we now treat the models as points in the design space and use the object-oriented inheritance hierarchy to compare the models on all the temporal features of the design dimensions that they support. Figure 23 gives an inheritance hierarchy in which types are used to represent the different models, and the temporal features supported by the models are used as a criteria for inheritance. The abstract type at the root of the hierarchy represents the least powerful temporal object model which supports a temporal structure comprised of anchored primitives which are discrete and determinate, no temporal representational scheme, a partial linear order, and a valid time history. This type has two immediate subtypes. The first subtype represents the OSAM*/T and the T-Chimera models. It inherits all the features of the root type and refines its partial linear order to a total linear order. Similarly, the second subtype

30


f e w e r f e a t u r e s (types)

rTemporal Structure: Anchored, Discrete, & Determinate

Temporal Representation: None Temporal Order:

Partial Linear


OSAM*/T, T-Chimera

T-3DIS ~.

2 r

Temporal Structure:

Temporal Structure:

Anchored, Discrete, & Determinate


Temporal Representation:


None

Gregorian

Temporal Order:

Temporal Order:

Total Linear


J~

\

Pae~ajo~:eH;story:

Volid

TEDM I g r

Temporal Structure:

"

Tempolal Structure-

Anchored,Discrete,& Determinate




None

Gregorian

Temporal Order:

Temporal Order:

Total Linear

Total Linear

Temporal History:

Temporal History:

Valid, Transaction, Event

Valid, Transaction

\

/

Temporal Structure: Anchored, Unanchored, Continuous & Determinate


/',/~

TOODM


Temporal History: m o r e features (types)

Valid, Transaction,Event

Fig. 23. Overall Classification of Temporal Object Models


31

represents the T-3DIS model, inherits all the features of the root type, and adds a representational scheme which supports the Gregorian calendar. The type representing OSAM*/T and T-Chimera also has two subtypes. The first subtype represents the TEDM model and has all the features of its supertype with the additional features of transaction and event time histories. The second subtype (which is also a subtype of the type representing T-3DIS from which it inherits the representational scheme) represents the TMAD model. This type has the additional feature of the transaction time history. A direct subtype of the types representing TEDM and TMAD represents the TOODM model. The type representing TOODM inherits the representational scheme from the type representing TMAD and the event time history from the type representing TEDM. It also adds unanchored primitives and the continuous time domain to its temporal structure. From Figure 23 it can reasonably be concluded that OSAM*/T and T-Chimera are the two least powerful temporal object models since they provide the least number of temporal features. The TOODM model is the most powerful since it provides the most number of temporal features. The comparison of different temporal object models made in this section shows that there is significant similarity in the temporal features supported by the models. In fact, the temporal features supported by OSAM*/T and T-Chimera are identical. The temporal features of TEDM are identical to those of OSAM*/T and T-Chimera in the temporal structure, temporal representation, and temporal order design dimensions. These commonalities substantiate the need for a temporal framework which combines the diverse features of time under a single infrastructure that allows design reuse. We also note that temporal object models have not really taken advantage of the richness of their underlying object model in supporting alternate features of a design dimension. They have assumed a set of fixed particular underlying notions of time. From a range of different temporal features, a single temporal feature is supported in most of the design dimensions. As such, not much advantage has been gained over the temporal relational models in supporting applications that have different temporal needs. For example, engineering applications like CAD would benefit from a branching time model, while time series and financial applications require multiple calendars and granularities. The temporal framework proposed in this work aims to exploit object-oriented technology in supporting a wide range of applications with diverse temporal needs.

5

Discussion and Conclusions

In this work the different design dimensions that span the design space of temporal object models are identified. Object-oriented techniques are used to design an infrastructure which supports the diverse notions of time under a single framework. We demonstrate the expressiveness of the framework by showing how it can be used to accommodate the temporal needs of different real-world applica-

32

Iqbal A. Goralwalla, M. Tamer 0zsu, and Duane Szafron

tions, and also reflect different temporal object models that have been reported in the literature. A similar objective is pursued by Wuu & Dayal WD92 who provide an abstract time type to model the most general semantics of time which can then be subtyped (by the user or database designer) to model the various notions of time required by specific applications. The temporal framework presented here subsumes the work of Wuu & Dayal in that it provides the user or database designer with explicit types and properties to model the diverse features of time. Their approach requires significant support from the user, including specification of the temporal schema, which is a complex, and non-trivial task. It is therefore imperative for temporal object models to have a temporal infrastructure from which users can choose the temporal features they need. Using the object-oriented type system to structure the design space of temporal object models and identify the dependencies within and among the design dimensions helps us simplify the presentation of the otherwise complex domain of time. The framework is extensible in that additional temporal features can be added as long as the relationships between the design dimensions are maintained. The focus in this work is on the unified provision of temporal features which can be used by temporal object models according to their temporal needs. Once these are in place, the model can then define other object-oriented features to support its application domain. The temporal framework also provides a means of comparing temporal objects models according to the design dimensions identified in Section 2.1. This helps identify the strengths and weaknesses of the different models. The diverse features of time are also identified in Sno95. The focus however, is on comparing various temporal object models and query languages based on their ability to support valid and transaction time histories. In this work we show how the generic aspects of temporal models can be captured and described using a single framework. In PLL96 a temporal reference framework for multimedia synchronization is proposed and used to compare existing temporal specification schemes and their relationships to multimedia synchronization. The focus however, is on different forms of temporal specification, and not on different notions of time. The model of time used concentrates only on temporal primitives and their representation schemes. The temporal framework has been implemented in C + § A toolkit has been developed which allows users/temporal model designers to interact with the framework at a high level and generate specific framework instances for their own applications. The next step is to build query semantics on top of the framework. This will involve addressing issues such as: how the choices of different design dimensions affect the query semantics; what kind of query constructs are needed; what properties should be provided; and how are these properties used, to name a few.


33

References All84 ATGL96

BFG97

BKP86

BP85

CG93 Cho94

CITB92

CJR8~

CK941 CMR91

CPP95

CPP96

CR88

CS93

J. F. Allen. Towards a General Theory of Action and Time. Artificial Intelligence, 23(123):123-154, July 1984. A-R. Adl-Tabatabai, T. Gross, and G-Y. Lueh. Code Reuse in an Optimizing Compiler. In Proc. of the Int'l Conf on Object-Oriented Programming: Systems, Languages, and Applications - OOPSLA '96, pages 51-68, October 1996. E. Bertino, E. Ferrari, and G. Guerrini. T_Chimera - A Temporal ObjectOriented Data Model. Theory and Practice of Object Systems, 3(2):103125, 1997. H. Barringer, R. Kuiper, and A. Pnueli. A Really Abstract Concurrent Model and its Temporal Logic. In Proc. of the 13th ACM Symposium on Principles of Programming Languages, pages 173-183, 1986. F. Barbic and B. Pernici. Time Modeling in Office Information Systems. In Proc. ACM SIGMOD Int'l. Conf. on Management of Data, pages 51-62, May 1985. T.S. Cheng and S.K. Gadia. An Object-Oriented Model for Temporal Databases. In Proceedings of the International Workshop on an Infrastructure for Temporal Databases, pages N1-N19, June 1993. J. Chomicki. Temporal Query Languages: A Survey. In D. Gabbay and H. Ohlbach, editors, Proceedings of the International Conference on Temporal Logic, pages 506-534. Lecture Notes in Computer Science, Vol. 827, Springer Verlag, July 1994. W.W. Chu, I.T. Ieong, R.K. Taira, and C.M. Breant. A Temporal Evolutionary Object-Oriented Data Model and Its Query Language for Medical Image Management. In Proc. 18th Int'l Conf. on Very Large Data Bases, pages 53-64, August 1992. R.H. Campbell, G.M. Johnston, and V.F. Russo. Choices (Class Hierarchical Open Interface for Custom Embedded Systems). Operating Systems Review, 21(3):9-17, 1987. S. Chakravarthy and S-K. Kim. Resolution of Time Concepts in Temporal Databases. Information Sciences, 80(1-2):91-125, September 1994. E. Corsetti, A. Montanari, and E. Ratto. Dealing with Different Time Granularities in Formal Specifications of Real-Time Systems. The Journal of Real-Time Systems, 3(2):191-215, 1991. C. Combi, F. Pinciroli, and G. Pozzi. Managing Different Time Granularities of Clinical Information by an Interval-Based Temporal Data Model. Methods of Information in Medicine, 34(5):458-474, 1995. C. Combi, F. Pinciroli, and G. Pozzi. Managing Time Granularity of Narrative Clinical Information: The Temporal Data Model TIME-NESIS. In L. Chittaro, S. Goodwin, H. Hamilton, and A. Montanari, editors, Third International Workshop on Temporal Representation and Reasoning (TIME'96), pages 88-93. IEEE Computer Society Press, 1996. J. Clifford and A. Rao. A Simple, General Structure for Temporal Domains. In C. Rolland, F. Bodart, and M. Leonard, editors, Temporal Aspects in Information Systems, pages 17-30. North-Holland, 1988. R. Chandra and A. Segev. Managing Temporal Financial Data in an Extensible Database. In Proc. 19th Int'l Conf. on Very Large Data Bases, pages 302-313, August 1993.

34


CSS94

DDS94

DS93 lEGS93

Flo91 GLOS97

G6S97

HKOS96

JF88 KGBW90

KKR90

Kli93 KS92

LEW96

MPB92 PLL96

PM92

R. Chandra, A. Segev, and M. Stonebraker. Implementing Calendars and Temporal Rules in Next-Generation Databases. In Proc. lOth Int'l. Conf. on Data Engineering, pages 264-273, February 1994. W. Dreyer, A.K. Dittrich, and D. Schmidt. An Object-Oriented Data Model for a Time Series Management System. In Prec. 7th International Working Conference on Scientific and Statistical Database Management, pages 186195, September 1994. C.E. Dyreson and R.T. Snodgrass. Valid-time Indeterminacy. In Proc. 9th Int'l. Conf. on Data Engineering, pages 335-343, April 1993. O. Etzion, A. Gal, and A. Segev. Temporal Active Databases. In Proceedings of the International Workshop on an Infrastructure for Temporal Databases, June 1993. R. Flowerdew. Geographical Information Systems. John Wiley and Sons, 1991. Volume 1. I.A. Goralwalla, Yuri Leontiev, M.T. Ozsu, and Duane Szafron. Modeling Temporal Primitives: Back to Basics. In Proc. Siz2h lnt'l. Conf. on Information and Knowledge Management, pages 24-31, November 1997. I.A. Goralwalla, M.T. Ozsu, and D. Szafron. Modeling Medical Trials in Pharmacoeconomics using a Temporal Object Model. Computers in Biology and Medicine - Special Issue on Time-Oriented Systems in Medicine, 27(5):369 - 387, 1997. W.H. Harrison, H. Kilov, H.L. Ossher, and I. Simmonds. From Dynamic Supertypes to Subjects: a Natural way to Specify and Develop Systems. IBM Systems Journal, 35(2):244-256, 1996. R.E. Johnson and B. Foote. Designing Reusable Classes. Journal of ObjectOriented Programming, 1(2):22-35, 1988. W. Kim, J.F. Garza, N. Ballou, and D. Wolek. Architecture of the ORION Next-Generation Database System. IEEE Transactions on Knowledge and Data Engineering, 2(1):109-124, March 1990. P.C. Kanellakis, G.M. Kuper, and P.Z. Revesz. Constraint Query Languages. In Proc. of the 9th ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, pages 299-313, April 1990. N. Kline. An Update of the Temporal Database Bibliography. ACM SIGMOD Record, 22(4):66-80, December 1993. W. Kafer and H. Schoning. Realizing a Temporal Complex-Object Data Model. In Proc. ACM SIGMOD Int'l. Conf. on Management of Data, pages 266-275, June 1992. J.Y. Lee, R. Elmasri, and J. Won. Specification of Calendars and Time Series for Temporal Databases. In Proc. 15th International Conference on Conceptual Modeling (ER'96), pages 341-356, October 1996. Proceedings published as Lecture Notes in Computer Science, Volume 1157, Bernhard Thalheim (editor), Springer-Verlag, 1996. R. Maiocchi, B. Pernici, and F. Barbic. Automatic Deduction of Temporal Information. A CM Transactions on Database Systems, 17(4):647-688, 1992. M.J. Perez-Luque and T.D.C. Little. A Temporal Reference Framework for Multimedia Synchronization. IEEE Journal on Selected Areas in Communications, 14(1):36-51, January 1996. N. Pissinou and K. Makki. A Framework for Temporal Object Databases. In Proc. First Int'l. Conf. on Information and Knowledge Management, pages 86-97, November 1992.

An Object-Oriented Framework for Temporal Data Models Rev90 RS91

SA85 sc911 Sci941 Sno86

Sno87 Sno92

Sno95

Soo91 SRH90

ss88 TK96 WD92 WLH90

35

P.Z. Revesz. A Closed Form for Datalog Queries with Integer Order. In International Conference on Database Theory, pages 187-201, 1990. E. Rose and A. Segev. TOODM - A Temporal Object-Oriented Data Model with Temporal Constraints. In Proc. lOth Int'l Conf. on the Entity Relationship Approach, pages 205-229, October 1991. R. Snodgrass and I. Ahn. A Taxonomy of Time in Databases. In Proc. ACM SIGMOD Int'l. Conf. on Management of Data, pages 236-246, May 1985. S.Y.W. Su and H.M. Chen. A Temporal Knowledge Representation Model OSAM*/T and its Query Language OQL/T. In Proc. 17th Int'l Conf. on Very Large Data bases, pages 431-442, 1991. E. Sciore. Versioning and Configuration Management in an ObjectOriented Data Model. The VLDB Journal, 3:77-106, 1994. R. Snodgrass. Research Concerning Time in Databases: Project Summaries. ACM SIGMOD Record, 15(4), December 1986. R.T. Snodgrass. The Temporal Query Language TQuel. ACM Transactions on Database Systems, 12(2):247-298, June 1987. R.T. Snodgrass. Temporal Databases. In Theories and Methods of SpatioTemporal Reasoning in Geographic Space, pages 22-64. Springer-Verlag, LNCS 639, 1992. R. Snodgrass. Temporal Object-Oriented Databases: A Critical Comparison. In W. Kim, editor, Modern Database Systems: The Object Model, Interoperability and Beyond, pages 386-408. Addison-Wesley/ACM Press, 1995. M.D. Soo. Bibliography on Temporal Databases. ACM SIGMOD Record, 20(1):14-23, 1991. M. Stonebraker, L.A. Rowe, and M. Hirohama. The Implementation of POSTGRES. IEEE Transactions on Knowledge and Data Engineering, 2(1):125-142, March 1990. R. Stain and R. Snodgrass. A Bibliography on Temporal Databasesl. IEEE Database Engineering, 7(4):231-239, December 1988. V.J. Tsotras and A. Kumar. Temporal Database Bibliography Update. ACM SIGMOD Record, 25(1):41-51, March 1996. G. Wuu and U. Dayal. A Uniform Model for Temporal Object-Oriented Databases. In Proc. 8th Int'l. Conf. on Data Engineering, pages 584-593, Tempe, USA, February 1992. K. Wilkinson, P. Lyngbaek, and W. Hasan. The Iris Architecture and Implementation. IEEE Transactions on Knowledge and Data Engineering, 2(1):63-75, March 1990.

An Architecture for Supporting Interoperability among Temporal Databases* Claudio Bettini 1, X. Sean Wang 2, and Sushil J a j o d i a 2 1 Dipartimento di Scienze dell'Informazione, University of Milano, Italy. Department of Information and Software Systems Engineering, George Mason University, Falrfax, VA.

A b s t r a c t . A significant property of temporal data is their richness of

semantics. Although several temporal data models and query languages have been designed specifically to handle the temporal data, users must still deal with much of the implicit temporal information, which can be automatically derived from the stored data in certain situations. We propose a multidatabase architecture where an appropriate formalization of the intended semantics is associated with each temporal relation and temporal database. This allows a temporal mediator to access the databases to retrieve implicit information in terms of time granularities different from those used to store data. We also describe how the temporal mediator can provide a user interface to the multidatabase system allowing temporal queries in terms of arbitrary granularities and involving relations in different TDBMS.

1

Introduction

A significant property of temporal d a t a is their richness of semantics. Although several t e m p o r a l d a t a models and query languages have been designed specifically to handle the temporal d a t a Tan93, users must still deal with much of the implicit temporal information, which can be automatically derived from the stored d a t a in certain situations. As a running example, consider the temporal relation SALES, which is used by a computer product company to keep track of items sold and the income realized by each of its branches. Specifically, the relation SALES records for each branch (Branch) and the product identifier ( P r o d u c t ) , the number of items sold ( I S o l d ) and the total income (Income) during each day (Day). We assume t h a t the database is u p d a t e d at the end of each business-day by inserting a tuple if at least one item of a particular product has been sold by t h a t branch. The values of Day are t i m e s t a m p s consisting of the date ( m o n t h / d a y / y e a r ) . An instance of SALES is shown in Figure 1. * The work was partially supported by the National Science Foundation (NSF) under the grant IRI-9633541. The work of Wang was also partially supported by the NSF grant IRI-9409769.

O. Etzion, S. Jajodia, and S. Sripada (Eds.): Temporal Databases- Research and Practice LNCS 1399, pp. 36-55, 1998. (~) Springer-Verlag Berlin Heidelberg 1998

An Architecture for Supporting Interoperability among Temporal Databases Branch

Product ISold Income

Austin Austin Chicago Chicago Los Angeles Austin

k123 k123 pl00 pl00 m87 k123

37

Day

100 16,500 3/13/97 50 8,2503/14/97 12 9,000 3/14/97 100 80,000 3/17/97 400 180,000 4/14/97 300 48,000 4/14/97

Fig. 1. An instance of the relation SALES

From the example temporal relation in Figure 1, it is clear that the total number of item k123 sold in a month by a particular branch can be obtained by aggregating sales figures for item k123 for all those days that lie within that month. Temporal database systems, however, usually leave this task to the users of the databases; users must perform aggregation in their queries if they wish to obtain the monthly data. It is obviously desirable that the temporal database systems have the ability to automatically apply the aggregation operation and present the user with the monthly sales data, without any explicit manipulations by the users. Our research on semantic assumptions BWJa is aimed toward building such a database system. The basic idea is to provide the system with the knowledge about the relationship between months and days, as well as with the fact that sum should be used to derive monthly sales data from the daily data. Semantics assumptions are also useful in a multidatabase system consisting of autonomous databases. In a multidatabase system, a global query is one whose answer depends on the information from more than one databases. To illustrate, consider, in addition to the database having SALES information, the existence of market research information systems offering access to street prices of products. Suppose that this information is stored in the temporal relation P R I C E that records for each product (Product), its average street price (SPrice) during a quarter (Quarter). (Note that the granularity used to store this data could be different for different information providers. It is possible that some offer more accurate average street prices, in terms of months, weeks, or even days.) A typical instance of P R I C E is shown in Figure 2. A global query that asks for "which branch sold items at a price lower than the street prices" needs information from the database containing SALES as well as from the one containing the street prices. In such a multidatabase environment, we probably cannot assume that each participating database system can be extended so that each is aware of the relationships among different time granularities. Indeed, the database system may not have an extensible temporal granularity system. Furthermore, some temporal granularities may be of interest only to some global users who draw information from different databases. In order to preserve autonomy, it may be desirable that the participating databases would not be required to change their system for the convenience of some global users with specialized needs.

38

Claudio Bettini, X. Sean Wang, and Sushil Jajodia Product S P r i c e Quarter

k123 pl00 m87 133 k123 pl00 k123

175 1st-q-97 700 1st-q-97 400 1st-q-97 300 2nd-q-97 160 2nd-q-97 650 2nd-q-97 200 3rd-q-97

Fig. 2. An instance of the relation PRICE

In order to facilitate the evaluation of global queries, we adopt the idea of a which is defined as "a software module that exploits encoded knowledge about certain sets or subsets of data to create information for higher layer of applications". We propose a temporal mediator that can answer queries posed by users (or application programs) on the implicit data in granularities that are perhaps not understood by some participating databases. For example, the corporate headquarters of a company may want to analyze the sales data against the street prices in terms of the fiscal calendar of that company. The market research firm database may not have the knowledge of the fiscal calendar of that company. When some data, stored in one of the databases, must be presented in terms of a time granularity not understood by that database, the automatic reasoning that derives the implicit data in that granularity is done by the proposed temporal mediator. The temporal mediator requires two kinds of semantic information for data at a local database: (1) Semantic assumption, specifying the method (e.g., sum) and how it should be applied to derive implicit information, and (2) Specification of intended temporal granularities. In the SALES example, we may specify that the method to use is 'sum' on the set of values with timestamps included in the same tick of the target granularities. The target granularities are those that are coarser than days (intuitively, these are the granularities that are partitioned by the granularity day) (see BWJa for a precise definition). Based on these observations, we propose an architecture of a multidatabase system that can derive implicit data in terms of multiple granularities. The central component is the temporal mediator itself, which answers queries by using multiple databases. The architecture also includes a "common" knowledge to which each participating database is assumed to have access. The common knowledge includes typical system-wide time granularities (like seconds, days, etc), as well as "conversion methods" to derive implicit information. In order to use the temporal mediator, multidatabase system has for each constituent database its semantic assumptions using the names of conversion methods (part of common knowledge) as well as the specification of target granularities. The mediator uses this information to process user queries. Semantic assumptions used in our multidatabase system architecture are related to the idea of "semantic values" SSR94. A semantic value is a value m e d i a t o r Wie92,

An Architecture for Supporting Interoperability among Temporal Databases

39

that has an associated environment. For example, a value 10 may be associated with "US dollar" specifying that this value is in terms of the US currency. SSR94 discusses issues involved in using semantic values in a multidatabase system. Our semantic assumptions are different from semantic values in two different aspects. Firstly, our semantic assumptions are temporal concepts, while semantic values are more general. Moreover, our semantic assumptions deal with derivation of implicit information from a set of data (e.g., monthly information from a set of daily data), while semantic values are single-valued. Various semantic assumptions in the temporal database setting were perhaps first recognized by Clifford and Warren CW83. The earliest systematic study, however, was performed by Segev and Shoshani SS87. They recognized various properties of time sequences, such as stepwise constant, continuous, discrete, and user-defined, and provided a number of functions to be used in user query languages to accommodate these properties. However, while these earlier works essentially provided a set of functions to implement specific assumptions, we formalize a general notion of semantic assumption that turns out to be a crucial element for the interoperability of temporal databases. Clifford and Isakowitz CI94 formalized the semantics of variables that many temporal data models employ to denote various semantic assumptions. The work clarified many vague, although intuitive, notions. However, this paper did not address how user queries could be answered on databases with such variables. In CDIJS97 a framework is proposed to specify the semantics of the particular variable now used to denote the current time in temporal databases, and several aspects are discussed regarding how queries on databases with such variables should be handled. However, both papers CI94,CDIJS97 do not address issues related to time granularities. The rest of this paper is organized as follows. In Section 2, we introduce the notions of temporal types and semantic assumptions. In Section 3, the general architecture is presented, analyzing the functionalities of each of its components. In Section 4, we consider a specific case study and describe preliminary results on the implementation of some of the architecture components.

2

Multiple granularities and semantic assumptions

In this section, we briefly present two notions that we have introduced elsewhere BWJb,BWJa; these provide the basis for the architecture investigated in this paper. The notion of temporal type is a formalization of what is intuitively called a granularity. The notion of semantic assumptions is a formalization of temporal semantic properties of attributes that are often implicitly used in the design of temporal schemas. This notion has been defined for the relational data model, hence in this paper we consider only relational databases.

40

2.1

Claudio Bettini, X. Sean Wang, and Sushil Jajodia

Temporal types

The definition of temporal types identifies an instance of the temporal type systems introduced in BWJb. We assume there is an underlying notion of absolute time, represented by the set Af of all positive integers. D e f i n i t i o n (Temporal type) A temporal type is a mapping # from the set of the positive integers (the time ticks) to 2N (the set of absolute time sets) such that for all positive integers i and j with i < j, the following two conditions are satisfied: 1. #(i) ~ @and #(j) ~ @ imply that each number in #(i) is less than all numbers in #(j), and 2. #(i) = O implies #(j) = O. Hence, a time tick for a given temporal type # identifies a set of instants on the time line. Property (1) states that the mapping must be monotonic. Property (2) disallows an empty set to be the value of a mapping for a certain time tick unless the empty set will be the value of the mapping for all subsequent time ticks. Typical granularities such as day, month, week, year, and b u s i n e s s - d a y can be defined as temporal types. As an example, suppose the underlying time is measured in terms of seconds. Then, the granularity day (assuming it starts on the first day of 1990) is a mapping such that day(l) is the set of all the seconds that comprise the first day of 1990, and day(2) maps to all the seconds of the second day of 1990, and so on. When the set of instants corresponding to a tick #(i) is equal to or contained by the set corresponding to a tick v(j) (i.e., ~t(i) C_ v(j)), we say that ~(j) covers #(i). There is a natural "finer-than" relation among temporal types. The temporal type # is said to be finer than the temporal type v if each tick of # is covered by a tick of ~. Thus, for example, day is finer than week and month is finer than year. It is easily seen that the finer than relation is a partial order BWJb. Finer-than is not a total order since, for example, week and month are incomparable (i.e., week is not finer than month, and month is not finer than

week). More formal properties of temporal types are investigated in BWJb. For this formal model, a specific finite representation of the temporal types must be defined (see e.g., NS92,CSS94). Using this representation, it should also be possible to implement functions to test the aforementioned finer-than relation as well as other common operations on granularities such as containment and intersection among ticks of different granularities, for example.

2.2

Point a n d i n t e r v a l - b a s e d s e m a n t i c assumptions

Semantic assumptions provide a formal specification of how unknown, yet implicit, values can be deduced from data explicitly present in the database. In particular, we are interested in information unknown for a particular tick of the


41

time granularity used by the database, and in information unknown for ticks in different granularities. We distinguish semantic assumptions used to derive these two different types of information into point-based and interval-based semantic assumptions. Point-based assumptions are those semantic assumptions that can be used to derive information at certain ticks of time, based on the information explicitly given at different ticks of the same temporal type. Such derivation can be done in a variety of ways. For example, (i) we may assume that the values of certain attributes persist in time unless they are explicitly changed; (ii) we may assume that a missing value is taken as the average of the last and next explicitly given values; or (iii) we may take the sum of the last three values. We adopt a general notion of point-based assumptions such that, in principle, any interpolation function to derive information from explicit values can be used BWJa. The persistence assumption has been widely used in practice. With PxOZpersis~ we denote the assumption of the attributes X Y being persistent with respect to the attributes X. This means that if we have explicit values for X and Y at a certain tick of time, these values will persist in time until we find a tick at which we have explicit values that are the same for the attributes X but different for Y. Note that the information derived by a persistence assumption always includes the original information (projected on X Y ) and the information implied by the assumption. Consider the P R I C E temporal relation. The designer of this relation could decide that when the street price for a month is not available, the previously stored street price is provided. This is formally specified by the assumption (P1)

Pp~oduct(SPrice pers~s)

which says that the values of these two attributes persist in time until a different value for S P r i c e with respect to the same value of P r o d u c t is found. For example, there is no value in the PRICE table for the street price of product 'm87' for the second quarter of 1997. However, if the designer specified the above semantic assumption, the same value as for the first quarter is implicitly associated with the product for the second quarter. In the temporal database literature a notion similar to persistence is found when the value of a tuple is given for an interval 1, uc, where uc is a short hand for "until changed" WJL91,CI94, or the common notation k, oc is used. However, the notion of until changed is not well formulated. For example, it is not clear which attributes must actually change to be qualified as "changed". In the persistence semantic assumption shown above, it is not sufficient to say that S p r i c e is persistent; the P r o d u c t attribute, based on which S p r i c e is persistent, has to be specified in order to have a clear semantics. The formal specification of persistence is also needed. If we generalize the persistence example, a point-based semantic assumption relies on the use of certain methods (called interpolation methods) to derive implicit values from explicit ones. An interpolation method is used to derive a value of an attribute by "interpolating" values of the same attribute at different ticks of time. Examples of other interpolation methods are average (taking

42

Claudio Bettini, X. Seem Wang, and Sushil Jajodia

the average of the previous and next stored value), or last-k-avg (taking the average of the last k stored values). If X, 1"1, ..., Yn are pair-wise disjoint attribute sets, and methl,...,methn are interpolation methods, the expression px(y~nethl ... ymeth~) denotes the assumption using method methi to derive implicit values of attributes Yi with respect to attributes X, for each i -- 1 , . . . , n. We call interval-based those assumptions that can be used to derive information for a certain tick of one temporal type from information at ticks of a different temporal type. The word interval indicates the fact that these "source" ticks must be intervals in the absolute time having a certain relationship (containment or intersection) with respect to the interval in the absolute time corresponding to the "target" tick for which the value is being derived. Referring to our PRICE relation, the designer could have associated with this relation an assumption that roughly says that, if a given product price is stored in the relation for a given quarter, the same price can be considered a good estimate for any month (or day, hour, etc.) of that quarter. In general, with Ix (A t) we denote the assumption of the attribute A being downward hereditary with respect to the attributes in X. This means that if we have an explicit value for the attribute A with respect to certain values for X at a certain tick of type #, then for each tick of any other type that is covered by it, A has that same value with respect to the same values for X. Hence the above assumption on P R I C E would be specified by (I1)

Iproaucz(SPricel).

Similarly, with Ix (A T) we denote the assumption of the attribute A being upward hereditary with respect to X. Roughly speaking, if we have the same value for the attribute A with respect to the same X at different ticks, that value is also the value of A for the same X for each tick of any other type that is the union of some of these ticks. With I x ( A I) we denote the assumption of the attribute A being liquid with respect to X; i.e., it is both downward and upward hereditary. A broad class of interval-based semantic assumptions is formed by so-called

aggregate assumptions. The value for an attribute at a certain tick v(i) of a target granularity v can be obtained by aggregating the values present in the database relation for ticks included in v(i). Several aggregation methods can be applied: average, sum, last, etc.. Referring to our example, let us assume that the designers of the two relations specify these additional assumptions: (I2) (I3)

Income sum) Iproduct(SPri ceaV9).

Isranch,Product(ISold,

The designers also specify that the assumptions should be applied only to target temporal types coarser than the source type they are using (day and q u a r t e r resp.). Hence, the first assumption states that the values for attributes I S o l d and I n c o m e in a tick of a granularity coarser than day can be obtained by summation of the values of these attributes corresponding to the same branch and product for all the days included in that tick. The second states that the street price in a tick of a granularity coarser than month can be obtained by taking the average of the street prices for the same product in all the months included in that tick.


43

In general, interval-based semantic assumptions can be used to answer queries that involve granularities different from those used in the database. Consider the query: "Give me the yearly income reached by the Austin branch for product k123". This query asks for information in terms of years, while the SALES relation is stored in day. The assumptions provide sufficient semantic information for the system to offer to the user a view of the relation in terms of year. In particular, for a certain branch, product, and year, the value of Income is taken as the sum of all the incomes stored for that product in a day contained in that year. Note that otherwise, the user has to properly code the query to perform the necessary conversions and different users could have a different interpretation of the semantics of the stored data. The example shown is obviously a simple case but more involved conversions and semantics are very likely to appear in real databases. Similarly to point-based assumptions, an interval-based assumption relies on the use of certain "conversion" methods. In general, if X, I1, . . . , Y, are pair-wise disjoint attribute sets, and cony1, . . . , convn are conversion methods, I x (y~onvl ... ynconv~) is the interval assumption that allows to convert values of Yi according to method conv~ with respect to values of attributes X, for each i-~ l , . . . , n . Formal definitions of methods, assumptions, their semantics and their formal properties can be found in BWJa. Note that the definition of assumptions is quite general. For example, the downward hereditary assumption (I1) can be used to derive street prices in terms of any (target) granularity that is finer than quarters, including second and minisecond. In a real application, there are usally some restrictions on the set of target granularities. These restrictions are specified along with the semantic assumptions.

2.3

Semantic environment

In order to participate in the architecture for database interoperability that we are defining, a temporal database management system (TDBMS) must provide to the external world its meta-data information, including semantic assumptions. By semantic environment of a TDBMS we mean a collection of meta-data information regarding the database. A semantic environment includes (1) the schema specification, (2) the native granularity used in each database relation to represent temporal data, (3) the set of temporal types known to the TDBMS, and (4) the semantic assumptions defined on the database relations with their associated restrictions on the target granularities. These restrictions must be formulated through a general specification, since they must not be limited to the temporal types known by the TDBMS. For example, a particular s u m conversion method, could be applicable to all pairs of temporal types (source, target) such that source is finer than target. As will be explained in the next section, this information is essential for the construction of the database schema for a mediator.

44 3

Claudio Bettini, X. Sean Wang, and Sushil Jajodia The temporal

mediator

architecture

In this section we illustrate a general architecture for querying a heterogeneous set of temporal databases having different semantic environments. The main components of the architecture are: (a) a temporal mediator, (b) a set of active subjects (users and/or applications), (c) a set of temporal databases each with an associated semantic environment, and (d) a common knowledge among components (a), (b), and (c). An instance of the temporal mediator architecture with a single active subject and two temporal databases is shown in Figure 3.

I1)BMS-2 (c) .....................

i

DB

=====================.... - ~,Temporal

Common

. . . . _K_n~_~_~(d)_.

)

Mediator (a)

User/

Processor

1. & C. M O h o d s = lnteq~lation and Conversion Methods

Application (b)

TDBMS-1 (c)

Fig. 3. An instance of the temporal mediator architecture.

The temporal mediator is the central component of the architecture. By using the mediator, an active subject can make queries referring to relations stored in different databases, and asking for information in terms of granularities possibly different from those used locally by the databases to store their data. Each active subject is seen in the architecture as a client process accessing the information contained in each participating TDBMS through the interface provided by the temporal mediator. Active subjects can be information mining processes, simple query interfaces, browsers, or more specialized applications. Each TDBMS in addition to its data, provides a semantic environment, so that the temporal mediator has access to the knowledge about which attributes and relations are locally available, and how interpolations and conversions on


45

their values should be performed. We assume that a network interface on each TDBMS local site allows the communication with the temporal mediator. A common knowledge is assumed among the different components: the formal specification of interpolation and conversion methods and a naming convention for a basic set of granularities. Indeed, day, for example, should denote the same temporal type in each database 1, and the semantic assumptions given in each database environment must refer to the same interpolation and conversion methods; the mediator itself has to know the methods specification to correctly interpret the semantic assumptions. The global set of interpolation and conversion methods should be specified in a formal language with a well-defined semantics (e.g., multi-sorted first order logic is used in BWJa). The different modules within the temporal mediator operate using a common data model and query language, that we call the TM-language. This can be an abstract query language (e.g. the M Q L F logic of BWJa) on an abstract data model (e.g. the temporal modules of WJS93), or a concrete one (e.g., the TSQL2 data model and query language Sno95). The best choice essentially depends on the presence or absence of a common interface language (like SQL for conventional databases) among the different TDBMSs and active subjects. In Section 4 we consider the case where every database provides a TSQL2 interface, hence, in that case, TSQL2 is used as the TM-language. We describe the architecture in more detail, considering each module in a temporal mediator. 3.1

The methods library

The methods library contains an implementation in the TM-language of the interpolation and conversion methods specifications. This implementation consists of what we call view templates that are essentially parametric TM-language queries. The parameters are the attribute names on which the method must be applied, and, for conversion methods, the source and target temporal types. Once the parameters are instantiated, the view template becomes a view, and hence, a query providing a view of the involved attributes in the target granularity. The methods library is used by the meta-data and query processor module. Examples of view templates and their instantiation are reported in Section 4. 3.2

The temporal type system

The temporal type system represents the knowledge that the mediator has on time granularities. The set of granularities must include at least the basic types assumed as the common knowledge; the richer is the temporal type system of the mediator the better will be its ability to answer user/application queries. The set of types included in the mediator temporal type system can be specialized based on the particular applications that the mediator is supposed to support. 1 If this is not the case we assume that appropriate synchronization tools are employed to simulate this common knowledge.

46


A temporal type system must also provide some functionalities to deal with its types. We distinguish local, and global functionalities. Among the first, the system should provide a mapping from ticks of one type into ticks of an other, and a set of arithmetic operators to add/subtract ticks. For example, the system may need to determine the month that contains a given business-day, the weeks properly contained in a given year, or the week obtained by adding 6 months to the first week of a given year. The specific operations that are necessary depend on the adopted TM-language. Global functionalities refer to relationships between temporal types. They should include a function to check the finer-than relationship, as well as functions to retrieve the maximum/minimum number of ticks of a temporal type covered by one (arbitrary) tick of another type. For example, it may need to determine that business-days are finer than weeks, that weeks are not finer than months, as well as knowing that months are at least 28 days and at most 31 days long. While local functionalities are routinely used by the query processor for temporal queries, the global functionalities seem to be particularly useful for optimization purposes. For example, when a finer-than relation holds among the two types involved in a conversion, a more efficient implementation of a conversion method can be used, as shown in Section 4. The temporal type system module is only used by the meta-data and query processor. 3.3

The DB interface

The DB interface is the module of the temporal mediator that interacts with the temporal databases. It receives transformed queries from the query processor that have to be sent to specific databases. If some of the databases do not provide an interface to the temporal mediator query language, a query transformation process has to be carried out by the DB interface to obtain a query in the target database query language, and another transformation process has to be done on the answer from the database to obtain a table in the mediator data model. An example of such interface is TimeDB Boh95 that supports a subset of TSQL2 query language over a conventional Oracle database. Under the assumption of a uniform query language, 2 the DB interface only performs the task of dispatching queries to the databases and returning the results to the query processor. 3.4

The mediator schema

The mediator schema module contains a schema specification on which user queries can be formulated. The mediator schema essentially provides a set of temporal relations, each one associated with the set of temporal types such that sufficient meta-data information is available to obtain the relation in terms of 2 The assumption that a set of heterogeneous databases provide the same query language is reasonable for conventional relational databases using SQL, and we believe that an SQL extension, or a similar standard will be adopted for temporal relational databases.


47

those types. Hence, an active subject can formulate a query on these relations in terms of each of the associated temporal types. The generation of the mediator schema is in general a complex task that shares many of the complexities involved in the specification of a global schema in a multidatabase system (see e.g., DS96). These complexities have been investigated in the literature, and tools are usually provided to facilitate this task. We assume each relation scheme as defined by a non-temporal relational algebra expression. Here we consider the aspects concerning the granularities. We associate with the mediator relation a set of temporal types; a type is included in this set if each TDBMS relation (or view) appearing in the relational expression can be obtained by the mediator in terms of that type using the semantic assumptions provided by the TDBMS. For example, consider a relation R defined as R1 ~ R2, where R1 is in TDB1 and R2 in TDB2. We include type # in its set of associated types, if R1 and R2 can be obtained in terms of # using the semantic assumptions and their type restrictions in TDB and TDB2, respectively. Note that # could be a temporal type unknown to the databases; the temporal mediator can determine based on the conversion methods in the assumptions (provided by TDBMS), on the specification of types allowed for those methods (provided by the TDBMS), and on the specification of # (provided by the mediator temporal type system), whether those relations can be obtained in terms of #. Semantic assumptions also help to solve some of the naming problems typical of multidatabases. For example, if the same attribute name appears in two TDBMSs relations, the semantic assumptions involving that attribute should be the same in the two YDBMSs, otherwise it means they have different semantics and should be given different names in the mediator schema. 3.5

The meta-data and query processor

The meta-data and query processor is the most important module of the temporal mediator. We schematically describe the several steps performed by this module in the processing of a query issued by an active subject component: 1. retrieve the necessary view templates from the methods library; 2. instantiate the templates according to the target temporal type and produce a view corresponding to each mediator relation appearing in the query; 3. substitute each relation name with its corresponding view obtaining a trans:formed query; 4. decompose the query and send each TDBMS-query to the DB interface module; 5. process the TDBMS-query results to obtain the global query result. We now consider each step in more detail. In Step 1, for each mediator relation R, whose name is appearing in the user query, the query processor has to identify the semantic assumptions on the TDBMS relations appearing in the specification of R. We suppose that this

48


meta-data information has been previously obtained and stored as part of the schema. Based on the semantic assumptions, as well as on the target temporal types required in the query, the appropriate view templates are retrieved from the methods library. A conversion method, like, for example, avg or sum, provided by a semantic assumption is usually independent from the source and target temporal types. Similarly, the corresponding template view implementation in the methods library is usually parametric with respect to the source and target types. However, for optimization purposes different view templates can implement the same method depending on the relationship between the source and target temporal types involved in the conversion. For example, we have experienced that conversions into target types that are either finer3 or coarser than the source type have more efficient implementations. (A concrete example is shown in Figures 5 and 6.) Hence, the most appropriate view template is selected by the query processor according to the specific source and target types. In Step 2, the templates, identified as explained above, are instantiated according to the temporal types required in the query. If multiple (point and interval) assumptions are present, the templates are composed accordingly (see BWJa for details). This results in a view in terms of the target temporal type for each TDBMS relation appearing in the definition of a mediator relation involved in the query. Applying the relational operators in the definition, a view in terms of the target temporal type for each involved mediator relation is obtained. In Step 3, the query processor substitutes each relation name in the user query with the corresponding view. The resulting query has all the necessary semantic information on conversions and interpolation embedded in it. The query contains TM-language constructs for basic temporal type operations, such as tick containment or intersection predicates, for example. In Steps 4 and 5, the query processor has to adopt a strategy to evaluate the global query. In principle, known strategies for multidatabase query evaluation can be adopted (see e.g., DS96). Informally, sub-queries will be sent to the appropriate databases and part of the evaluation (operations on the results) will be done by the query processor. However, the query processor has to check, by the semantic environment of each TDBMS, that it knows the temporal types involved in the corresponding sub-query and, hence it can perform the necessary basic temporal type operations. If this is not the case, these operations must be performed by the query processor in the mediator, after retrieving the data from the TDBMS. Several optimization strategies can be applied here. In the above discussion we assumed that the active subjects submit their query in the same query language used within the mediator. 4 If this is not the case the necessary transformation has to be carried out by the query processor.

3 Accordingly to the formally defined finer-than relation. a As pointed out above, the assumption that most temporal databases will provide an interface through a common query language seems to be reasonable in the long term.

An Architecture for Supporting Interoperability among Temporal Databases 4

Towards

a system

49

prototype

In Section 3, we described the functionality of each component in the temporal mediator architecture independently from a specific TM-language. The description is sufficiently general to allow TDBMSs with different data models and query languages. In this section, we present a particular case study in which a simple extension of TSQL2 is used as the TM-language, and each participating TDBMS provides a TSQL2 interface to the mediator. As mentioned earlier, TimeDB can be used to support a TSQL2-1ike query language over conventional relational databases. As we propose in BWJa, the extension of TSQL2 should allow a syntactic construct "TABLE IN g r a n u l a r i t y " that can be used in the FROM clause to specify a relation in terms of a particular granularity. For example the construct PRICE IN month is allowed wherever a relation name is allowed in TSQL2 in the FROMclause. We also assume that the use of the keyword INSTANT, allowed for event tables is extended to every kind of table. That is, it allows to de-coalesce a period into its constituents ticks. For example, if a tuple is timestamped with Jan96, Feb96, the application of INSTANTon the table that contains the tuple would return a table containing two copies of that tuple, one timestamped with Jan96 and the other with Feb96. Finally, we assume a slightly different semantics for CAST on periods: casting of period Jan96, Feb96 into days should return 1/1/96,2/29/96 and not 1/1/96,2/1/96 as with current TSQL2 casting, i.e. the last (and not first) tick of the set corresponding to the right endpoint is taken. We now illustrate, through an example, preliminary results on how certain mediator modules can be implemented using this language. We consider a temporal mediator interfacing with two TDBMSs. The first is a company TDBMS containing, among other relations, the SALES relation introduced in Section 1. The second is an information provider TDBMS containing, among other relations, the PRICE relation also introduced in Section 1. Figures 1 and 2 can be seen as TSQL2 tables where each timestamp is a single valued period. The only semantic assumption specified in the first TDBMS on SALES is (I2), illustrated in Subsection 2.2. The application of the assumption has also been restricted from that TDBMS schema designer to temporal types coarser than day. The semantic assumptions specified in the second TDBMS on PRICE are (P1), (I1), and (I3), with target types for (I1) restricted to those finer than q u a r t e r and target types for (I3) restricted to those having at least one tick covering a tick of q u a r t e r . Hence, the mediator schema provides to the active subjects, among other relations, the relation SALES associated with a list of all temporal types (known to the mediator) coarser than day. Assuming a reasonably rich mediator temporal type system, these would certainly include week, business-week, month, etc.. The schema also provides the relation PRICE associated with a set of temporal types (known to the mediator). Since month satisfies the restrictions for (I3), it is part of this set.

50


Suppose that the following query is formulated by an active subject: "Which branch sold product k123 for less than the street price considering monthly sales of 'k123' and corresponding street prices?" Since the "TABLEIN g r a n u l a r i t y " construct is available, the query is easily expressed in TSQL2 as shown in Figure 4. SELECT el.Branch FROM SALES IN month AS el, PRICE IN month AS e2 WHERE el.Product = 'k123' AND e2.Product = 'k123 c AND el. Income < e2.SPrice * el. ISold AND VALID(el) = VALID(e2);

Fig. 4. A user query The type month is among the types supported by the mediator for SALES because of the semantic assumption IBr~ch,Product(ISold, Income sum) given in TDBMS1, and it is among the types supported by the mediator for PRICE because of the semantic assumption/Product (SPrice 1). To process the query, the mediator has to use these assumptions to derive a view of both relations in month. The first step consists in retrieving the view templates corresponding to the conversion methods I and sum from the methods library. Note that the view templates needs to be applied to a particular relation. As observed in Section 3, it is possible that more efficient implementation of the same conversion method exist in the library depending on the relationship between the source and target type. In Figures 5 and 6 we show two template implementations for each conversion method needed by our example query. Since month is coarser than day and finer than q u a r t e r the simpler templates can be used. For finer target types SELECT e. V ,

e. W

VALID CAST(VALID(e) AS u)

FROMM(V,W) AS e;

For arbitrary target types SELECT e2. V , e2. W FROM (SELECT *

VALID CAST(VALID(el) AS u) FROM M(V, W) AS el) (INSTANT) AS e2 WHERE EXISTS (SELECT 9 FROM M(V, W ) (INSTANT) AS e3 WHERE CAST(VALID(e2) AS ~) = VALID(e3) AND e2,V = e3.V AND e2.~V = e 3 , W ) ;

Fig. 5. Two template views for the ~ conversion method

The template for target types that are finer than the source type simply retrieves the projection of the table Mon attributes in V and W coalescing tu-


51

pies with the same value for V and W, and then casts the timestamp of each tuple to the target granularity. Note that M, V, W, and v are parameters that will be instantiated according to the specific table, attributes in the assumption, and target granularity. Considering as an example the P R I C E table, if tuple /k123,100 / has timestamp lst-quarter-97,2nd-quarter97, after the parameters instantiation, the casting as used above would return the same tuple timestamped Jan97,Jun97, i.e., from the first month of the first quarter to the last month of the second. The same method is much more complex if it has to be applied to arbitrary target types. Indeed, in this case, only some of the ticks of the source type could be covered by ticks of the target. Thus, the method implementation must guarantee that the values for attributes W are "inherited" only by tuples timestamped with ticks c o v e r e d by ticks of the target. If there is no particular knowledge about the relationship among source and target type, the comparison has to be done "tick by tick". This explains the need for the (INSTANT) construct in the template.

For coarser target types SELECT e 2 . V , sual(e2.W) VALID(e2) FROM (SELECT * VALID CAST(VkLID(el) AS v) FROM M AS el) AS e2 GROUP BY e2.V, VALID(e2) USING 1;

For arbitrary target types SELECT e 2 . V , sum(e2.W) VhLID(e2) FROM (SELECT 9 VALID CAST(VALID(el) AS v) FROM M AS el)(INSTANT) AS e2, M (INSTANT) AS e3 WHERE CAST(VALID(e2) AS ~) CONTAINS VALID (e3) AND e2.V = e3.V AND e2.M/ = e3.M/ GROUP BY e2.V, VALID(e2) USING 1;

Fig. 6. Two template views for the

sum

conversion method

The s u m template for target types that are coarser than the source type first (in the external FROMclause) translates the timestamp of each tuple in Min terms of the target type (without coalescing). Then, it applies the sum aggregate, summing all values in W being in the same tick (specified by USING 1) of the target type, and having the same value for V (GROUP BY e 2 . V , VALID(e2) USING i). When the target type is coarser, we are always guaranteed that given a tick in the target type any tick of the source type is either fully covered by it or has no intersection with it. If this is not the case, ticks not fully contained must be identified and excluded from participating in the sum. This is basically what the more involved sum method implementation does for arbitrary types. Note that,

52


in our example, the application of this method to types not coarser than day has been explicitly ruled out by the meta-data associated with the SALES relation. Since templates are parametric with respect to the relation name, attribute names, source and target temporal types, they must be instantiated according to the semantic assumption in which they appear and to the required target granularity. For example, the template in Figure 6 is instantiated considering M----SALES, V ----{Branch, Product}, W = {ISold, Income}, day as source type, and /=month. In this case, the resulting view is indeed a view of the SALES relation in terms of month. When point-based assumptions are also present, a n d / o r more interval-based assumptions are present, the process is more involved since point-based assumptions have to be applied first, and the resulting views have to be appropriately combined. This step has been implemented in PIC97 by a C program working on TSQL view templates. Figure 7 shows the two instantiated views in our example.

SALES-VIEW-IN-MONTH

PRICE-VIEW-IN-MONTH

SELECT e2.Branch, e2.Product, SELECT e.Product, e.SPrice sum(e2.ISold), sum(e2.Income) VALID CAST(VALID(e) AS month) VALID(e2) FROM PRICE(Product,SPrice) AS e; FROM (SELECT * VALID CAST(VALID(el) AS month) FROM SALES AS el) AS e2 GROUP BY e2.Branch, e2.Product, VALID(e2) USING i;

Fig. 7. The views derived from SALESand PRICE.

In our simple example, the query processor would now substitute the expressions "SALES IN month" and "PRICE IN month" in the FRDM clause of the query with the corresponding derived views. At this point, the query is a standard TSQL2 query, except that relations in multiple databases are involved. Several optimization strategies for query decomposition, common to multidatabases, can be applied. In the specific case of our query, an optimal decomposition is probably that shown in Figure 8, where SALES-VIEW-IN-MONTH and PRICE-VIEWIN-MONTH are the views instantiated from the s u m and I conversion methods, respectively, assuming that each TDBMS knows month.

Send to TDBMS1

Send to TDBMS2

SELECT el.Branch, el.ISold, el. Income SELECT e2.SPrice FROM SALES-VIEW-IN-MONTHAS el FROM PRICE-VIEW-IN-MONTH AS e2 WHERE el.Product ffi 'k123'; WHERE e2.Product = 'k123';

Fig. 8. A decomposition of the transformed query


53

Once the query answers from each TDBMS are received, the query processor can easily obtain the answer to the user query. In our example, it simply selects the Branch attribute from the table returned by TDBMS1, checking the condition that the corresponding Income value in each selected tuple is less than the SPrice*ISold value for the same valid time. No general strategy is likely to give the optimal decomposition for all queries. In the worst case, the query processor retrieves from the TDBMSs the complete view that is needed, applying locally all of the query conditions. As briefly mentioned in Section 3, it is also possible that a TDBMS does not have knowledge about a certain temporal type used by the mediator. In this case the query addressed to this TDBMS cannot contain, for example, CASTing operations involving this type. The mediator has access to sufficient meta-data information to recognize this situation, and has to adopt an adequate strategy. In the worst case, it simply retrieves the data and perform locally all the operations requiring casting. A simplified version of the mediator has been implemented at the University of Milan, Italy PIC97 and a World Wide Web demo site can be found at h t t p : / / ~ w , i s s e . g m u . e d u / ~ c s i s / t d b . The currently implemented system allows to make queries using the "TABLE IN g r a n u l a r i t y " construct as an extension to the ATSQL language, which is essentially a subset of TSQL2. The mediator is currently interfaced with a single TDBMS implemented using TimeDB (Boh95), a temporal relational database system supporting the ATSQL query language. Since TimeDB currently does not support time granularities, all casting operations are simulated in PIC97 using ad-hoc tables. The mediator temporal type system includes standard granularities as well as non-standard ones like b u s i n e s s - d a y and business-week. The formal specification of some common methods has been given in BWJa as well as their TSQL2 implementation. The TSQL2 methods library has been enriched in PIC97.

5

Conclusion

In this paper, we presented a general architecture for temporal database interoperability. We focused in particular on time granularity issues, proposing that the notion of temporal semantic assumptions should be the formal tool to express the semantics intended by each TDBMS designer. The temporal mediator component of our architecture plays the crucial role of collecting and using the semantic information from the different TDBMSs, to provide a uniform interface to users and applications. The feasibility of the proposed approach is supported by the implementation of some basic functionalities of the architecture for a case study where TSQL2 is used as the TM-language. However, several issues regarding the mediator schema design and the decomposition and evaluation strategies in presence of multiple databases deserve a deeper investigation before a real system prototype for the whole architecture can be implemented.

54


Interesting extensions to this work include the study of "information quality" issues. From the point of view of time granularities, for example, when different T D B M S provide the same information, but using different native granularities, the mediator has to evaluate which T D B M S to use to provide the most accurate answer to the user query. Another interesting extension is to enrich the notion of semantic environment adding semantic values as proposed in SSR94, to formalize the semantics of single attributes in the T D B M S schema.

References BWJa

BWJb

Boh95

cw83 CI94

CDIJS97 CSS941

DS96

NS921

PIC97 SSR94

ss87 Sno95

C. Bettini, X. Wang, and S. Jajodia. Temporal Semantic Assumptions and Their Use in Databases. IEEE Transactions on Knowledge and Data Engineering. To appear. C. Bettini, X. Wang, and S. Jajodia. A General Framework for Time Granularity and its Application to Temporal Reasoning. Annals of Mathematics and Artificial Intelligence, to appear. A preliminary version of this paper appeared in Proc. of TIME-96, IEEE Computer Society Press. M. H. Bohlen. Temporal Database System Implementations. SICMOD Record, 24(4), ACM, December 1995. J. Clifford and D.S. Warren. Formal semantics for time in databases. A C M Transactions on Database Systems, 8(2):214-254, June 1983. J. Clifford and T. Isakowitz. On the semantics of (bi)temporal variable databases. In M. Jarke, J. Bubenko, and K. Jeffery, editors, Proceedings of 4th International Conference on Extending Database Technology, pages 215-230, March 1994. J. Clifford, C.E. Dyreson, T. Isakowitz, C.S. Jensen and R. Snodgrass. On the Semantics of "Now" in Databases. ACM Transactions on Database Systems, 1997. To appear. R. Chandra, A. Segev, and M. Stonebraker, Implementing calendars and temporal rules in next generation databases, in Proc. of ICDE, 1994, pp. 264-273. W. Du and M. Shan. Query Processing in Pegasus. In Object-oriented multidatabase systems, O.A. Bukhres and A.K. Elmagarmid Eds., Prentice Hall, 1996. M. Niezette and J. Stevenne. An efficient symbolic representation of periodic time. In First International Conference on Information and Knowledge Management, Baltimore, MD, November 1992. N. Piccioni. Using semantic assumptions to answer temporal queries. Master Thesis. DSI - University of Milan, 1997. (In Italian) E. Sciore, M. Siegel, and A.S. Rosenthal. Using semantic values to facilitate interoperability among heterogeneous information systems. A C M Transactions on Database Systems, 19(2):254-290, June 1994. A. Segev and A. Shoshani. Logical modeling of temporal data. In U. Dayal and I. Traiger, editors, Proceedings of the ACM SIGMOD Annual Conference on Management of Data, pages 454-466, San Francisco, CA, May 1987. R. T. Snodgrass, editor. The TSQL2 Temporal Query Language. Kluwer Academic Publishers, 1995.

An Architecture for Supporting Interoperability among Temporal Databases Tan93

Wie92 WJL91I

WJS93

55

A.U. Tansel, J. Clifford, S. Gadia, S. Jajodia, A. Segev, and R. Snodgrass. Temporal Databases: Theory, Design, and Implementation. Benjamin/Cummings, 1993. G. Wiederhold. Mediators in the architecture of future information systems. IEEE Computer, March, 1992, pages 38-49. G. Wiederhold, S. Jajodia, and W. Litwin. Dealing with granularity of time in temporal databases. In Proc. 3rd Nordic Conf. on Advanced Information Systems Engineering, Trondheim, Norway, May 1991. X. Wang, S. Jajodia, and V.S. Subrahmanian. Temporal modules: An approach toward federated temporal data bases. In Proc. of ACM SIGMOD International Conference on the Management of Data, Washington, D.C., 1993.

Extended Update Functionality in Temporal Databases O p h e r E t z i o n 1, A v i g d o r G a l 2, a n d A r i e Segev 3 1

- Haifa Research Lab, M a t a m 31905, Haifa, Israel 2 Rutgers University, Department of MSIS a Haas School of Business, University of California and Information & Computing Sciences Division, Lawrence Berkeley Laboratory Berkeley, CA 94720, USA IBM

A b s t r a c t . This paper presents an extended update functionality in temporal databases. In temporal databases, the information is associated with several time dimensions that designate the validity of the information in the application domain as well as the database domain. The complexity of information, coupled with the fact that historical d a t a is being kept in the database, requires the use of an u p d a t e model t h a t provides the user with high-level abstractions. In this paper we provide an enhanced schema language and an enhanced collection of update operation types that help the system designer and the user to cope with the added complexities of such a model. One of the major issues dealt with in this paper is the situation of simultaneous values of a single d a t a item; this situation occurs when multiple values, valid at the same time, were assigned to a d a t a item at different times over the database history. Unlike the fixed semantics in conventional and existing temporal database models, we provide a flexible mechanism to handle simultaneous values which also distinguishes between regular modifications and error corrections. The extended update functionality is part of an u p d a t e model that is currently being implemented in a prototype for a simulation project in a hospital's training center. Issues related to the implementation of this functionality in various d a t a models are discussed. In particular, a mapping of the basic primitive operation types to TSQL2, and suggestions for its augmentation are provided.

K e y w o r d s : T e m p o r a l d a t a b a s e s , D a t a b a s e u p d a t e s , S i m u l t a n e o u s values, Decision T i m e , T S Q L 2


Extended Update Functionality in Temporal Databases 1

Introduction

and

57

motivation

Temporal databases enable the accumulation of information over time, and provide the ability to store different values of the same data item I with different time characteristics, thus enabling queries as if they were issued from past observation times (e.g. what was the known patient's situation at the time that a treatment was prescribed.) The capability to update past or future values of the database requires handling the following three issues: S i m u l t a n e o u s V a l u e s : a situation of simultaneous values of a single data item in a temporal database occurs when multiple values that are valid at the same (real-world) time were assigned to a data item at different times over the database history. Simultaneous values is a temporal notion that may exist implicitly in non-temporal databases, with a fixed and implicit semantics to handle such a case. Temporal databases allow to refine the semantics associated with simultaneous values, which requires a supporting update model. The concept of SVS (Simultaneous Values Semantics) defined in this paper supports the different possible answers to the question: which of the simultaneous values should be returned, as a response to a retrieve operation? A single abstraction that captures the possible answers to that question, coupled with linguistic features to define and modify them are discussed in this paper. M o d i f i c a t i o n C o n t r o l : In certain cases, it is required to restrict the ability to update the past and future states of the database. This can be done both in a static way (for all the instances of some data item in the database) or in a dynamic way (both at the object level and at the property level). Linguistic abstractions for modification control are also discussed. R e v i s i o n C o n t r o l : In temporal databases, any information that has ever been stored in the database is kept and not deleted when newer information is available for the same data item (deletions are likely to eventually occur, but they are considered storage management operations). However, erroneous values, that have been corrected later, are also kept. A concept of r e v i s i o n distinct from the concept of m o d i f i c a t i o n should be established in order to retrieve the appropriate values relative to an observation time that is later than the revision time. In this paper we devise a model that help the system designer and the users of such systems to cope with these complexities by providing enhanced schema language and enhanced set of update operation types. This section serves as an introduction and motivation, and consists of the following sub-sections. Section 1.1 provides background and basic definitions in the context of temporal databases, Section 1.2 presents a motivating example, Section 1.3 outlines the rest of the paper. 1 We use the term data item to denote a basic, not necessarily atomic, unit stored in the database, regardless of the specific data model. Examples: field, attribute, column.

58

1.1

Opher Etzion, Avigdor Gal, and Arie Segev

Background: Temporal Databases

Time plays an important role in various application areas including decision support, decision analysis, computer integrated manufacturing, computer aided design, office information systems, to name a few. Due to its complexity, the functionality required by many of those applications is only partially supported by current database technology, resulting in the use of ad-hoc and expensive solutions for each application. The temporal database research area draws an ever growing attention in the research community, summarized in a series of detailed bibliographies Kli93, Soo91 and TK96) and a survey (OS95). Taking an historic perspective, the incorporation of time in databases began in the '70s FD71; Bra78; A+79. Research has concentrated on extending the relational model to include the time concept during the '80s; a survey of algebras is introduced in MS91. The modeling of temporal databases has been addressed in many papers including KL83, CC87, Gad88, SS88, and CK94. The reader is referred to the book TCG+93, for some basic readings on the subject. In June 1993, the temporal database community organized the "ARPA/NSF International Workshop on an Infrastructure for Temporal Databases", which was held in Arlington, Texas. The results of the workshop were documented in an infrastructure recommendations report Pis94, and a consensus glossary of temporal database concepts J+94. Since then, substantial efforts have been invested in improving and unifying the many existing temporal query languages (e.g. HSQL Sar93 and TQUEL Sno87) through a unified temporal relational query language called TSQL2S+94. The infrastructure work forms a basis for temporal technology development, such that additional functionality can be incorporated either through mapping to or augmentation of such infrastructure. Another workshop was held in Zurich in September 1995 for further discussion of these issuesSJS95. Following these works, we adopt a discrete model of time CT85, which is isomorphic to the natural numbers. In this paper we use the following terms: Definition 11 C h r o n o n J+ 94 is a nondecomposable unit o/time, whose granularity is application dependent. In our case study we use the composition of date;hh:mm (date, hour and minute) to designate a chronon; date is specified as: M M M DD Y Y Y Y , where: M M M designates a month's abbreviation (e.g., Feb), DD designates the day in the month, and Y Y Y Y designates the year. Definition 12 t i m e interval designated as Its, re) is a set o/ all chronons t such that ts 1), such that Vi: t 9 tv(vi). Note that the n updates are a subset of the total number of updates to that data item, and n must be at least two for simultaneous values to exist. In Section 2.1.1. we define the term SVS, in Section 2.1.2. we introduce single value interpretations of SVS, in Section 2.1.3. we introduce multiple value interpretations of SVS. This discussion entails a need to consider an additional time dimension called D e c i s i o n T i m e . This issue is discussed in Section 2.1.4. S i m u l t a n e o u s Value Semantics D e f i n i t i o n 22 A p p l i c a b l e value(s) of a data i t e m 5 at t: The value, or values that are being selected in response to a retrieval request about the value of 5 at the valid time chronon t.

Definition 23 SVS: an abstraction that denotes a decision procedure at retrieval time to determine which of the simultaneous values are applicable. The possible values of SVS are determined according to the result of two separate decisions: 9 Should the applicable value be a single value for a given chronon t , or are multiple values allowed to be applicable? 9 What determines which value is applicable?

Extended Update Functionality in Temporal Databases

63

Single Applicable Values If there are multiple values for a chronon t on the valid time dimension, a criterion has to be devised of how to choose a single applicable value. We discuss three possible strategies: the first value, last value and single user defined value. The approach that selects value on the basis of chronological order is rooted in the semantics of the i n s e r t and m o d i f y operation types in conventional databases. D e f i n i t i o n 24 first value semantics: The first known value of the dataelement 5 at the chronon t is the only applicable value. The term first known value may be implemented using the earliest value on the transaction time (tx) dimension, however this interpretation designates the order in which the values have been reported to the database. This order may be different from the real order of events. Applications for which this distinction is significant, should employ another time dimension to maintain the correct order. This issue is further discussed in Section 2.1.4. The insert operation type in conventional databases is a case of first value semantics. In conventional databases, the first insert operation for a given primary key value is stored in the database, while later insert operations of the same instance are considered as integrity constraint violations and thus rejected. At the attribute level, first value semantics exists in unchangeable attributes N+87.

tx,! Feb 1 92 9: I Oam

Legend: + + + + + 1st v a l i d t i m e

_

t +++

I

'~******

.......

'

2nd valid time 3rd v a l i d t i m e

Feb 1 92 9:00am

m

Feb 1 92 8:00am

"

+-t'+++

I i

Aug

I l

91

Sep91

i i

Oct91

*******

i l

N o v 91

I i

Dec91

I i

Jan 92

.~V

Fig. 3. A fixed first value semantics update protocol

In temporal databases, a kind of first value semantics update protocol as proposed in Sno87 is illustrated in Figure 3. The two bottom lines represent

64


update operations, and the upper one represents a response to a retrieve operation. Note that the values denoted by § and * have not been overridden by the later update, due to the first value s e m a n t i c s . D e f i n i t i o n 25 last value s em a nt i c s : The last known value of the data-element 5 at the chronon t is the only applicable value.

The last v alu e semantics is compatible with the m o d i f y operation type in conventional databases, the last modified value overrides all the previous ones. Some temporal models (e.g, SK86, WJL91) employ last val ue semantics, in which the value with the latest transaction time is considered to be the applicable value. D e f i n i t i o n 26 s i n g l e u s e r d e f i n e d value s e m a n t i c s : The selection criterion among the values is provided by the user using a query language. The selection is constrained to any selection criterion that selects a single value (which can be an aggregate value).

Examples: the minimal value, the median value, the average value, a value that is selected according to other parameters, such as source and level of confidence, if such information is stored in the database GES94, and an explicit selection by the user. A special case is to look at the different values as possible interpretations, in which only one is applicable. This is compatible with the possible worlds semantics that has been thoroughly discussed in the knowledge representation area F+94, and mentioned also in the database context AKG91. Retrieval queries, under this interpretation, can include modal operators.

M u l t i p l e V a l u e d A p p r o a c h In the multiple valued approach, there is no restriction on the number of applicable values. Any subset of the set of simultaneous values of the data item 5 at chronon t may be selected. There are two types of SVS applicable to this case: the all semantics, and the m u l t i v a l u e d user defined semantics D e f i n i t i o n 27 T h e all v a l u e s s e m a n t i c s : all the simultaneous values of the data-element 5 at chronon t are applicable.

Under the all values s em a nt i c s , all the values (except for the revised ones) are being selected. This approach was referred to in semantic data models as a multi-valued attribute, in which a data item's value consists of several values HK87. For example, a data item that designates the languages that a person speaks can have a set of grouped values. The interpretation is All, designating that the person speaks all the languages in the designated set. D e f i n i t i o n 28 M u l t i p l e u s e r d e f i n e d v a l u e s e m a n t i c s : The selection criterion among the values is provided by the user using a query language.


65

Examples to selection criteria are: all values > 5, all values whose transaction time is earlier than to, and the differences between the original values and their average. Similar notion was defined in databases that support uncertain multiple values ZP93. In our case study, the physician's diagnosis consists of a set of disorders, any subset of which may reflect the patient situation. In this case, the values employed as part of the retrieval requests by some selection criteria or aggregation of values. Current temporal database models employ a single interpretation of simultaneous values either at the database or at the schema level. Some of the models (e.g., Sno87,NA89) enforce a s i n g l e v a l u e a p p r o a c h at the database level. Other models (e.g., Tan86) enable the support of different semantics at the schema level by making a distinction between a single valued attributes and a multi-valued attributes; however, the semantics of the multi-valued attributes is not explicit. Many other models (such as Ari86, SK86, ABN87, WJL91, and CK94) also enforce a single value for each chronon. As a result, a mechanism to handle non-unique interpretations is not available. In CK94, a mechanism for storing multiple past views is provided, but a predefined preference relation for choosing a single value of a property for each chronon is enforced. Our case study demonstrate the need for all the spectrum of simultaneous values semantics. 9 The Physician-id follows the first v a l u e semantics; 9 The Symptoms property has an all v a l u e s semantics; all the reported symptoms are considered to be applicable. 9 The Diagnosis has a last v a l u e s e m a n t i c s . The last diagnosis is the applicable one. However, as shown in our example, the transaction time is not necessarily a good measure in determining the correct order of diagnoses. 9 The Disorder property within a context of a single Diagnosis has a m u l t i v a l u e d u s e r d e f i n e d s e m a n t i c s ; any subset of the set of disorders may be applicable. 9 The Patients- Treated for a physician has a single u s e r - d e f i n e d s e m a n t i c s with respect to the question: which patient is being treated by Dr. Livingston at chronon t. If we assume that a physician can handle a single case in any given chronon, then it is known that at chronon t he treated o n e of the patients whose assignment to him is valid at t. These examples show cases of SVS that can be determined during the schema design phase. However, in some cases the semantics should be determined only at run-time. For example, Dr. Flinstone is not allowed, from a certain date on, to be responsible for more than one patient, thus for this instance, the assignment semantics should be modified to first v a l u e s e m a n t i c s . As a requirement, the model should provide both static and dynamic SVS definition. The static definitions are implemented at the schema level (with a possible schema evolution), and the dynamic level is implemented as updates at the instance level.

66


D e c i s i o n t i m e Some of the S V S options are based on the order of events, which lead us to discuss another important aspect for the required functionality, the issue of decision time. The transaction time (tx) in some temporal database models has two major roles (in addition to the traditional role of backup and recovery): 9 It is used to determine the order of events, necessary to support first v a l u e or last v a l u e semantics; 9 It is used to answer temporal retrieval queries, such as: What was the answer to the query q, if issued from the observation point of a past chronon t?

To answer such a temporal query, the database is required to know the values committed before t; the transaction time is a means to record this knowledge. The second role concerns events in the database domain only (the commit time), thus the transaction time can be used for achieving this role without additional assmnptious. However, the first role may refer to events in the application domain and not to the database domain. There is an implicit assumption that the transaction time reflects the correct order of events in the application domain. Thus, the transaction time is sufficient to achieve the first role. Contrary to that, there are applications in which the order of events is important and the order of updates to the database does not necessarily reflect the order of events in reality; in this case, we need a time type that belongs to the application domain and not to the database domain. In our case study example, diagnosis Da occurred before diagnosis D~, but due to the batch process of reporting, diagnosis D~ was committed in the database before diagnosis D~. In general, the commit order of transactions is non-deterministic under the standard two phase locking protocol, consequently the transaction time may not reflect the order of occurrences in the modeled reality. In our context, the decision analysis context, we use the term d e c i s i o n t i m e for this time type. D e f i n i t i o n 29 D e c i s i o n T i m e (td) is the chronon at which a data item's value was decided in the application's domain of discourse EGS92. This chronon denotes the time at which an event occurred, or the time at which a decision was made (even if the value is complex, a decision about each modification is made in a single chronon). From the database's point of view, td reflects the chronon at which an event in the modeled reality entails a decision to initiate a database update transaction. The following example shows the three different types of times. Dr. Flinstone is hired as a physician in our hospital, the hiring decision has occurred on July 20 1996, and recorded in the database on July 24 1996. The hiring period is for a year starting August 1 1996. In this case td = July 20 1996, tx ----July 24 1996, and t , -- August 1 1996, July 31 1997). We assume that the d e c i s i o n t i m e dimension is the one, according to which the first and last value semantics is being determined, this means that the value having the earliest (or latest) d e c i s i o n t i m e is the applicable one.


67

The decision time concept was introduced in lEGS92, and is also mentioned in OS95. A similar concept has been referred to as event time CK94. It is argued in OS95 that it is still an open question whether the functionality achieved by using decision time, as a third time type is justified with respect to its overhead. In this paper we assume that the system designer and user recognize the decision time as a primitive concept; the discussion about implementation as a separate concept vs. implementation on top of existing concepts is deferred to Section 5. 2.2

Modification Control

In temporal databases, values that are valid in the past or the future may be updated. While this ability provides flexibility, it is sometimes required to restrict it and not allow to modify data items during part or all of their validity time. For example, actions that have been performed, such as the values of laboratory tests that have been reported, cannot be altered. Thus, this data item is unchangeable in the entire valid time dimension. In other cases, a data item can be changeable in some valid times and unchangeable in other valid times. The modification control can be issued either in a static way or in a dynamic way, and either at the object level or the property level. D e f i n i t i o n 210 A s t a t i c m o d i f i c a t i o n c o n t r o l is a modification control that applies to all instances of the class (or property) of the same type for any chronon on the valid time dimension. D e f i n i t i o n 211 A d y n a m i c m o d i f i c a t i o n c o n t r o l is a modification control that overrides the s t a t i c m o d i f i c a t i o n c o n t r o l for a certain object (or a dataitem) during some chronons on the valid time dimension. In a similar way to the SVS case, The s t a t i c m o d i f i c a t i o n c o n t r o l is implemented by a modified schema definition (with a possibility of evolving schema) and the dynamic one is implemented at the instance level. 2.3

Revision Control

The revision requirement is a result of the ability to ask queries from different view points, example for such a query is: what are the known symptoms of the patient John Gait, as was known at Dec 12, 1995; 10:00 pm. Such a query is

vital for decision analysis and auditing purposes. In regular database, the last value overrides the previous one, thus it is not important whether the value was replaced because some change had occurred, or the value was replaced because it was erroneous. However, in temporal databases this distinction is important. Consider the following example: The symptoms Sa, Sb, Sc for a certain patient were reported to the database at the chronon tl. at t2 > tl, it was noticed that the symptom Sb had been reported by mistake, and it should have been reported as Sd. The requirement is that a query issued from the observation point of any

68


chronon t, such that tl < t < t2, about this patient's symptoms should return < Sa, Sb, Sc >, while the same query issued from the observation point of t _> t2 should return < Sa, Sd, Sc >. This is consistent with the knowledge that can be obtained from the database at each observation point. In our example, the value was replaced with another value for its entire validity time, but in the general case the revision control should allow either revision by another value, or just logical deletion of the revised value. The revision may apply to the entire validity time of the revised value, or to any part of it. The revision control is implemented at the instance level, dynamically.

3

The Modeling Primitives

In this section we present the primitives of the temporal database model that is intended to satisfy the requirements posed in the previous sections. These primitives are used by the system designer when constructing the application. This issue is further elaborated in Section 4. Section 3.1 presents the information modeling primitives. Section 3.2 discusses the enhanced schema language support for the static SVS and modification control definitions, Section 3.3 introduces the set of update operation types, which are the major implementation vehicle for the dynamic SVS and modification control definitions. The semantics of these components is discussed in Section 4.

3.1

Information M o d e l i n g Primitives

This section presents the information modeling primitives that are used in this paper. This data model can be implemented on top of various lower-level data models, such as relational or object-based. Information about an object is maintained as a set of variables (instances of the class' properties). Each variable contains an information about the history of values as well as the different components of the variable status (SVS, modification control, revision control) of the variable. Each component is represented using a set of state-elements; state-element is the most basic object in the database. We assume that the database is an append only database. New information is added while existing information is left intact. The append only approach is necessary to support operations that require past database states. For example, a medical examiner investigating a malpractice complaint issues the query: "What were the known laboratory test results of a given patient at 10:30pm on December 12, 19937"

This information is crucial in deciding whether the attending physician provided a reasonable treatment given the available information at that time. Since the information may have been incomplete or even erroneous at the time, the treatment decision may seem wrong from a later observation point. Unlike


69

some other temporal models ABN87 that employ a non-strict form of appendonly, we employ the append-only in the strictest fashion. Consequently, the data can be stored on W O R M (write once read many) devices, in which no changes can be made to a state-element after the transaction that created it had committed. A state-element is a tuple of the form: 2

(se-id, old, value, t~, td, tv ) * ix, td, tv designate the time types (as defined, tx and td are chronons and tv is a temporal element). 9 The value of a state-element designate a value assigned to the variable (e.g., Dr. Livingston), 9 A state-element includes a uniquely created system-wide identifier se-id. 9 oid designates the object-identity of the object the state-element is associated with. A state-element example is: T ~ a t ? n e n t ~-

se-id=s9, oid=86,~5~5, value=antibiotic, 12 1993; lO:3Opm, td----Dec 12 1993; lO:lOpm, tv=Dec 12 1993; 10:12pm, D e c 19 1993; 8:00pro) tx=Dec

A Bucket fl is a set of state-elements having a well-defined semantics. In our model there are four types of buckets, as defined below. A variable 5 is as a set of four buckets:

(5.data, &variable-SVS, 5.modify-control, &void-SJb-~ The data bucket contains the state-elements whose values issue the history of the data associated with the variable 5. The rest of the buckets are control buckets. The variable-SVS contains state-elements whose value designate dynamic modifications of the SVS of the variable 5. The values consists of a pair (SVS, query-id ). The query-id designates a query to be activated for user defined SVS. The modify-control is a collection of state-elements whose value (changeable or frozen) designate the history of modifications to the variable's modify control status. The void-SE is a collection of state-elements, whose value are state-elements that are being voided at the tv of the void state-element. An object c~ is represented as a set of variables:

(~.object-id, ~.class-ref, ~.object-status, (~.Pl,...,~.Pn)). The data bucket of the object-id variable consists of a single unique state-element whose value designates the object identity. Its modify-control bucket consists of a single state-element with the value frozen. The class-tel is a variable that 2 Additional attributes of information about source, validity, accessibility, etc., can be added. These extensions are discussed in GES94.

70


classifies an object to be an instance of a specific class. The SVS of this variable can be adjusted to the specific application's assumption. If an object can be classified to multiple classes, then the SVS of class-tel is set to A N D ; if an object's classification is fixed then the SVS is set to first value SVS. This is an example of using the SVS concept to support data model independence. The object-status variable's values are stored in state-elements, with last value SVS, based on decision time. The possible values of this variables' data are: active~ suspended~ disabled. See Section 4 for the exact definition. An object's state is a set of all its variables' states, i.e the entire collection of state-elements associated with this object. In the general case, the user may not be familiar with the object-identity, and instead identifies the object using an object identifier (primary key), which is a subset of the object's state. For example, the underlined properties (Record-Number and Patient-Name) in Figure 1, are the object-identifiers. The level of granularity of temporal support was discussed in various papers (e.g. SA86). The common claim is that an attribute level support (which is equivalent to our interpretation of a state-element) reduces the space complexity relative to an object level support, because any change in any attribute results in the need to duplicate the entire object, also if the level of granularity required in the application is of an attribute, then an object level support increases the time complexity of obtaining information about the evolution of a single attribute. In any event, the concepts discussed in this paper are model independent, the concept of s t a t e - e l e m e n t can also be implemented on top of a model whose temporal granularity is in the object level, by creating an object to represent each state-element.

3.2

The Enhanced Schema Language

The schema language is the system designer's tool to express static decisions about the data representation and semantics of updates and retrieval requests. The schema definition consists of classes and properties; each property may have characteristics that are common in existing schema languages (e.g., type, default, set of legM values, reference to other objects), and additional characteristics required to support the static definitions of extended requirements (SVS and modification control) By using keywords. The SVS keywords are: first~ last, and, single~ multi. The single and multi keywords designate the user defined SVS modes. An additional keyword query ---- q i d i s allowed with the single and multi SVS options, to designate the id of a query that is activated, 3 whenever a query is issued that require the value of any variable that belongs to this property, qid is a query id. Example: if a property p has a single SVS mode associated with it, and the query associated with it is average value, then anytime that any query attempts to retrieve any instance of p, the average of the values of all the state-elements valid at the specified valid time are returned. If none of the SVS keywords is specified 3 queries are represented as objects in the database.


71

then the default is last. If a single or m u l t i SVS have been specified, and no query has been indicated, then the user is prompted at run-time for a selection queryGES94. The m o d i f i c a t i o n control employs two keywords: frozen and changeable. The default is changeable. In Figure 4, we re-visit the schema presented in Figure 1 with the additional keywords. Since changeable is the default, it is omitted. Note that a nested structure can have a different SVS in the different

class= Medical-Record properties= Record-Number: last Patient: first; frozen Symptoms: all Signs: all Laboratory-Tests: all Laboratory-Feature first; frozen Test-Results: all; frozen Diagnosis: last Diagnosis-Id: first; frozen Disorders: multi Treatments: last Assigned-Physician: last class = Patient properties = Patient-Name: last Social-Security-Number: last Records: all Class = Assigned-Physician properties = Physician-Id: first; frozen Patients-Treated: single

Fig. 4. The revised partial schema of a medical database

levels; Diagnosis obeys the last value SVS, while its component Disorder has a m u l t i SVS, consequently there can be only a single valid Diagnosis at each single chronon, nevertheless, within this Diagnosis multiple disorders may be simultaneously valid. In this example all the properties SVS were explicitly defined. To ease the system designer task, we suggest to use the following defaults that are compatible with update assumptions in conventional databases: 1. When the property is an object-;d, the default is first; frozen value (this is an unchangeable default). 2. When the property is an object-status (see Section 3.3), the SVS is last value; changeable (this is an unchangeable default).

72


3. If the data type of the property is a set, a bag or a sequence, then the default is all; c ha nge a bl e . In this case insert means add a new element, while modify means change existing element(s). 4. If the data type of the property is an atomic data type, then the SVS is last; changeable. The extended schema language supports static definitions of the required options. These definitions affect all instances of the properties defined in the schema, unless a dynamic definition overrides it. The schema level is not entirely static, in the sense that a schema may evolve with time, although we assume that schema changes are not frequent. If a schema evolves, the valid schema is used. For a comprehensive discussion of the schema evolution issue the reader is referred to GE98.

3.3

The Update O p e r a t i o n T y p e s

Update operation types are the linguistic primitives of a database update language. We express the required dynamic functionality by augmenting this set of primitives, hence, providing the user a uniform linguistic commands for the entire update process that include update of data, modification control at the object and variable levels, revision control and SVS definitions. Earlier works in the temporal database area were confined to the update operation types of insert, modify and delete while assigning to these operations a slightly different meaning than in conventional databases. For example, in several works (e.g., EW90) the difference between updates in non-temporal databases and in temporal databases is that modifications of an attribute's value in the latter case retain the old value in addition to adding the new value. Others (e.g., HRDM CC87, McKS8, GE98 expanded the modify operation to include meta-data, thus allowing schema versioning, as well as data evolution. Our extended set includes the insert~ modify~ suspend~ resume~ disable~ freeze~ unfreeze~ revise~ s e t - S V S operations, as explained next. I n s e r t : This operation creates a new object in the database. Along with the object insertion, the user may assign initial data values to some or all the object variables. For example, a new patient is registered at the emergency room. The database creates a new instance of the class Patient and initializes the values Patient-Name=Dan Cohen and Social-Security-Number=1234 5678. M o d i f y : This operation adds new information about an existing object. For example, in Dec 12, 1993, 11:10pm, the results of a laboratory test of Dan Cohen caused a modification to the Diagnosis variable. Unlike non-temporal databases, the m o d i f y operation does not remove previous values. The modify operation can be applied to valid time chronons that are different than now, to an interval, or even to the entire database valid time line. S u s p e n d : This operation establishes a reversible constraint that prevents any modification to the object in the given valid time, except for the object status


73

which is still changeable. 4 For example, we can use the s u s p e n d operation to prevent the assignment of a treatment until the completion of appropriate tests. The s u s p e n d operation is a modify-control operation that sets an object to be u n c h a n g e a b l e For example, when a physician is off-duty it is not possible to assign any record to him. R e s u m e : This operation makes a suspended object changeable again. As in the insert operation, the resume operation may be used to set the values of some of the object's variables. The r e s u m e operation is necessary to eliminate an u n c h a n g e a b l e constraint of an object. D i s a b l e : An operation that establishes an irreversible constraint that makes the object logically deleted as of the beginning of the tv specified in the disable operation, and consequently prevents any modification to the specified object. For example, when a physician retires (assuming that a retired physician cannot practice again), the object representing this physician is disabled, however we may still want to investigate his past action, thus the history of records assigned to him is kept. The d i s a b l e operation type has two major differences from the s u s p e n d operation type: 9 d i s a b l e is irreversible; 5 9 d i s a b l e has ontological implications, because it means that an object is logically deleted, i.e. ceases to belong to the application's domain of discourse, while suspend is only a constraint that prevents updates. We use the term disable rather than delete since the history of the disabled object is preserved and there are no physical deletions. F r e e z e : This operation establishes a reversible constraint that prevents the modification of a variable (except in the case of revising erroneous values as explained below). 6 For example, the laboratory results are measured values that should not be altered, thus the laboratory results' variable is updated with a freeze constraint. The f r e e z e operation is vital to the support of the u n c h a n g e a b l e v a l u e at the variable level. U n f r e e z e : Any frozen data may be unfrozen. An unfreeze operation applied to a variable, designates the removal of the freezing constraint. Any modification to that variable is allowed from that time on. The u n f r e e z e operation is required for the retraction of the u n c h a n g e a b l e v a l u e constraint at the variable level. R e v i s e : This operation "corrects" an erroneous value of a variable at certain collection of chronons. It tags values that currently exist in the database as false ones and adds a new correct value instead. The revise operation allows the replacement of a frozen value, marking the previous value as an erroneous one. The revise operation type is the means to implement the a The object status is required to remain changeable in order to reverse the suspend constraint. 5 A Database Administrator (DBA) can use low level update primitives to "rescue" an object that was mistakenly disabled. 6 The freeze and unfreeze operation at the variable level are similar to the s u s p e n d and r e s u m e at the object level. The different names are intended to avoid semantic overloading.

74


revision control requirement. The separation of the revise operation from the modify operation makes a semantic distinction between a change in the real world and a correction of a wrong value that was reported to the database. The user can instruct the database to include or exclude the revised values in retrieval operations. S e t - S V S : The operation dynamically sets an SVS at the variable level. Data may only be changed in a temporal database by adding new objects or adding new state-elements to the variables of an existing object. The semantics of the update model are reflected in allowable new state-elements. A new stateelement is allowed to be inserted if it obeys some general syntactic rules, such as legal value in its valid time, and other rules that are contingent on the status of the object and the variable, the update operation type, and the SVS for this variable. Section 4 discusses the exact semantics of each update operation.

4

The Semantics of the Model's Components

In this section, the formal update semantics of the various components of the model is presented. The validity semantics is presented in Section 4.1, the retrieval semantics is presented in Section 4.2, the update operation types are combined from a set of low-level primitives, presented in Section 4.3. Section 4.4 describes the semantics of the update operation types, followed by a discussion in Section 4.5. We shall use Figure 5 to demonstrate each of the functions and operations, presented in this section. The figure presents a set of state-elements, labeled according to the se-id, of an object that is an instance of the Patient class. The se-id are identified as Snn. Each state-element is preceded by the name of the bucket it belongs to. 4.1

Validity Semantics

An object is considered to be a c t i v e at chronons in which it is neither disabled nor suspended on the valid time axis. The state transition diagram of the objectstatus is presented in Figure 6. An arrow's label represents the name of the update operation that changes the object's status. Note that the disabled state is a terminal state, unlike suspended and active. The variable's states are applicable only within the context of the active object status. An object is valid when it is not disabled. When an object is disabled, all its variables are considered to be invalid, except for the Object-Status that continues to be valid, because it provides information about the validity of an object. In the example, the object is invalid in Aug 25 1994; 8:00am, c~), which is the valid time of (s22). A d i s a b l e operation sets an actual upper bound for the valid time (tv) of all the state-elements associated with the disabled objects to be the starting point of the disabled status valid time interval. Thus, the chronon Aug 25 1994; 8:00am marks the upper bound for actual valid time of


75

all the state-elements associated with this object. Note that the recorded t. of the state-elements cannot be modified, however, the upper bound is reflected in the update and retrieval operations semantics. An object cannot be referenced by other objects, at a valid time chronon in which it is disabled. The collection of chronons in which an object (~ is active or valid is denoted by AR (c~) or VR (a), designating the activity range and the validity range, respectively.

Object-ld. data (sl) 884555, t x =Dec 12 1993; lO:OSpm, td=Dec 12 1993; XO;OOpm,tv =Dec 12 1993; lO:OOpm, ~ ) Class-tel.data (sS) Patient, t x ~ D e c 15 1998; lO:Qgpm, td~Dec 19 1998; lO:90pm, t~=De~ 19 1995; lO:OOpm, oo) Ob~ct-xtat~.dats (st) Actwe, tw~Dec 12 1998; lO:Otpm, td=Dec 1~ 1993; lO:OOpm, iv=/Dee 12 1992; lO:OOpm, r Patient-Name.data (~4) Dan Gohen, t~=Dec 1$ 1993; lO:O~pm, $d=Dec 15 1993; lO:OOpm, tv=Dec 15 1998; lO:OOpm, oo) Soc~al-Sevurlty-Number. data (s5) 158~5678,~x=Dec 12 1998; IO:OSpm, td=Dec 15 1998; lO:OOpm, iv=Dec 15 1998; IO:OOpm, oo) Socsal-Secu~ty- Number.Modi~J-Oontro| (s6) frozen~t x ~ D e c 15 1993; lO:Otpm, td=Dec 12 1998; lO:OOpra, ~v=Dec 15 1993; lO:OOpm, ~ ) Record-Number.data (sT) 15S55678-1, ix=Dec 15 1998; IO:OSpm, td=Dec 15 1998; lO:OOpm, tv=Dec 15 1998; 10:OOpm, oo) Record-Number.Mod~f~l-Control (sS) frozen g~e=Dec 1~ 1998; lO:05pm, td=Dec 18 1998; 1O:OOpm, tv~Dee 1~ 1998; lO:OOpm, o~) ~reatment.data (89) ant*b~ot*c,tx=Dec 15 1998; IO:SOpra, td=Dec 1~ 1998; lO:lOpm, tv=Dec 12 1998; IO:12pm, Dec 19 1998; 8:OOpm) Disorder.data (slO) partial treatment, i x = D e c 12 1998; ll:80pm) $d=Dec 12 1993; 11:15pm, tv=Dec 12 1993; ll:lSpm, c~) Disorder.data ( sl l ) bra~nabscess, t~=Dec 12 1993; ll:SOpm, td=Dec 1~ 1993; ll:15pm, t v =Dec 1~ 199S; ll:15pm, oo) Disorder. data (sl~) v~na~Meningitis, t~ =Dec 1~ 1993; ll:80p~, td=Dec 15 1993; ll:15pm, t~ =Dec 12 1999; II:15pm, o~) Social-Security-Number. Vo~d-Se ~slS) sS, tw= Dec 19 I998; lI:gSp~,~d=Dec 1~ 1999;11:30pm, iv=Dec I~ t99S; lI:gOpm, oo) 8oc~a~-S~cur4ty-Number.data (s14) 053~5678, t~ =Dec 12 1998; 11:33pm, t d = D e c 18 1999; ll:30prn, Cv =Dec 15 1999; ll:80pm, o~) D~order.data (s15) bacterial Mentngitia, gw=Dec 12 1993; ll:35pm, td=Dec 12 1993; lO:05pm, iv =Dec 12 1993; lO:O5pm, oo) Disorder.data (s16) wral Men~nyit~s, g~=Dec 1~ 1998; ll:35p~a, td=Dec 12 1999; 10:05pm, t v =Dec 12 199S; lO:05pm, ~ ) ~order.data (sl 7) spontancov~ 8ubarachnout Hemorrhage , tw=Dec 1~ 1998; ll:35pm, td=Dec 19 199S; lO:05pm, iv=Dec 1~ 1993; lO:OSpm, oo) Treatment,data (slS) acyclovir, tw=Dec 12 1993; ll:85pm, td=Dec 1~ 199S; ll:lTpra~ tv=Dec 12 I993; ll:19pm, Dec 5~ 1993; 8:OOam Record-Number.modify-control (slg) changeable, t~ =Dec 13 199S; IO:OSpm, td=Dec 1S 1998; IO:OOprn, iv =Dec 13 1993; 10:OOpm, oo) Object-Status.data (sSO) Suspended, ~x=Dec 19 1993; 8:0Sam, td=Dec 19 1993; 8:OOam, iv=Dec 19 1993; 8:OOam, oo) Ob2ect-~tat~.data (sS1) Active, t x ~Au 9 25 199~; 15:0gain, id=Aug 25 1994; 15:OOum, i v =Aug 54 1994; 15:OOam, oo) Ob2ect-Statu~.data (a$5) D~abled, t~ =Aug 55 1995; 8:0Sam, td=Aug 25 1995; 8:00am, t~ =An 9 55 1994; 8:OOara, oo) Oblect-Status.modi~y-co~troi (s9~) freeze, ~x=Au9 95 1995; 8:lSar~, td=Au 9 ~5 1995; 8:lBam, tv~Dec 19 1993; 8:0Dam, r

Fig. 5. An example set of state-elements

A variable has a valid value only when its associated object is valid. The CSE function (Candidate State-Elements) returns the state-elements of a given variable which are valid at chronon t, i.e. the state-elements whose valid-time contains the chronon t. All these state-elements are candidates to be applicable, depending upon the SVS semantics.

76


Definition 41 CSE(var, t) is a function that returns the set of state-elements of the data bucket of the variable v a t that are possibly valid at a chronon t . A state-element se belongs to this set if it satisfies the following conditions: 1. t E V R ( s e . o i d ) //* the object is valid at t ~//; 2. t E tv(se) / * se is valid at t */; 3. -~3se t I se.se-id = set.value A t E tv(se t) A se t E var.void-se A t x ( s e t) >

tx(se) //~ se is not voided at t. *//;

For example, CSE(c~.Gbject-Status, Aug 24 1994; 12:00am)={s3, s20, s21}, where ce is the object whose state-elements are presented in Figure 5.

Insert

/'~. ..

Active

Suspend Resume

=.J Yl Suspended

Disabled

Fig. 6. The state transition diagram of the object-status

Extended Update Y~nctionality in Temporal Databases

77

The applicable state-elements among those included in the CSE set are determined according to the SVS semantics. For example: in the all SVS, the whole set is considered to be applicable. In the last v a l u e SVS, the applicable stateelement is a state-element whose td is the latest among the CSE set. td may be used when the variable belongs to the application domain. We denote the stateelement chosen by the last v a l u e SVS as ASE (Applicable State Element). We assume that each decision is made at a unique chronon, thus ASE is an atom. For example, ASE(c~.Object-Status, Aug 24 1994; 12:00am)={s21}, where c~ is the object whose state-elements are presented in Figure 5. The frozen range of a variable is the range in which the variable is frozen. This is defined by the function F R (var). The function F R returns a collection of valid time chronons in which the applicable state-element is frozen, i.e., it cannot be altered. This function returns the unions of tv of all sate-element in vat.modify-control, whose value is "frozen". 4.2

Retrieval Semantics

The retrieval semantics is determined according to the variable's SVS, the validity semantics and additional information that may be obtained from the user. The basic retrieval request is: find the value of a variable vat at chronon t. By satisfying this retrieval request, many complex queries can be answered. The basic retrieval request has the following interpretation: 1. If the SVS is first v a l u e then the state-element with the earliest decision time among those returned by the CSE function is selected. 2. If the SVS is last v a l u e then the ASE function returns the value. 3. If the SVS is all then the set of all values in the CSE set is returned. 4. If the SVS is u s e r d e f i n e d then if a query is referred to at the schema or the variable level, the result of this query is returned, else the user is prompted for a selection query (in this case the SVS is deferred to run-time interpretation). An example of such query is t d < ~0, which selects only the set of state-elements decided prior to to. This semantics can be implemented on top of various query languages such as T O O S Q L RS91 that also support retrieval from various observation points (an answer to the query as-of to) that restricts the selection of values to those whose tx < to. The following examples illustrate the retrieval semantics (all of the following queries were issued on December 13, 1993). 1. Query: What is the disorder of Dan Cohen? Answer: The possible Disorders of Dan Cohen are partial treatment, brain abscess, and viral Meningitis. T h e answer is based on state-elements (sl0)-(sl2). Since Diagnosis has a l a s t value SVS, the diagnosis with the highest decision time (t4) is selected by the ASE function. The Disorders within a Diagnosis have a u s e r d e f i n e d SVS, thus the answer is interpreted as possible disorders.

78


2. Query: What was the known Social-Security-Number of Dan Cohen at 10:30pm on December 12, 1993? Answer: The known Social-Security-Number of Dan Cohen on December 12, 1993 at 10:30pro is 12345678. An intelligent query language can point out that the value was erroneous, and was revised to 02345678 on December 12 1993, at 11:33pm. 4.3

Low-level Update Primitives

This section presents the low-level primitives the system use to update the database. These primitives are the building constructs of the update operation types and are not accessible to the user. However, the DBA may use these primitives in handling exceptional situations. The primitives are defined at three different levels: state-element primitives, variable primitives and object primitives. Throughout this section, we use the symbols @ and | The symbol @ denotes an application of an update operation to a database. The symbol @ is a separator between two successive operations; in case of an abort as part of one of the operations, subsequent operations are not performed. We also use two constants, now designates the chronon at which an operation is being performed, co designates an unlimited known upper bound, for example a state-element having a valid-time interval of now, co is considered to be valid starting from the time it was inserted, and valid at any later chronon, unless voided or overridden by other value. S t a t e - e l e m e n t L e v e l P r i m i t i v e s We introduce the basic primitive of the model: C r e a t e - s e . Prior to its introduction, we introduce three system functions that are used by it. l e g a l - t e m p o r a l ( t v , td) is a boolean function that returns "true" if the predetermined temporal constraints are satisfied. These temporal constraints are: 1. tv is a legal temporal element (not empty, contains non intersecting interval); 2. ~d is a legal chronon (according to the application's granularity); 3. td ~_ now (now is the current chronon, read from the system's clock). legal-type(val, p) is a boolean function that returns "true" only if val is in the domain of the property p. a s s o c i a t e ( s e , a.p.~) is a function that associates the state-element with a the bucket j3 in a variable of the property p of the object a. a denotes the object as identified by its identifier (primary key), this is translated to the OID using a translation function. C r e a t e - s e : creates a new state-element. S y n t a x : create-se (old, p, /3, val, Td, %). S e m a n t i c s : DB @ create-se (old, p,/3, val, Td, Tv) -(-~ legal-temporal(T,, Td) V ~ legal-type(val, p) )--* abort |


79

DB' :--DB U{se} l se = (se-id, oid, val, Tx, Td, T,) Ase-id=generate-se-id O | associate(se, ~.p./~) I c~.Object-id = oid. This primitive adds a single state-element se to the bucket f~ of a variable c~.p (the instance of the property p in the object (~), after checking if certain integrity constraints are satisfied. It consists of two phases: adding the stateelement to the database (each state-element is a separate entity with a unique identity in the database), and associating it with a variable and a bucket. DB p is the new database state, se-id and T~ are generated by the system; se-id is generated according to the object-identifiers' generation conventions CK86; the ~'x (transaction time) is determined at commit time. For example: The operation create-se(oid=864545, p=Patient-Name, ~=data, val=Dan Cohen, "rd=Dec 12 1993; lO:OOpm, rv =Dee 12 1993; lO:OOpm, co)) applied in a transaction that committed on Dec 12 1993; 10:02pro, resulted in the state-element (s4) in Figure 5. V a r i a b l e L e v e l U p d a t e P r i m i t i v e s This section presents the semantics of the variable level primitives. To provide upward compatibility for non-temporal databases and to provide a shortcut for the standard cases and ease the use, omission of the time values is allowed, and thus a default should be provided. We define T~ to be: now if ra=nil Ta otherwise That is, ~-~ is assigned a default value of now (the current chronon read from the system's clock of the transaction start time), only if no value has been provided for Td. This default can be adjusted by the DBA at the application initiation, to be either the start time of the transaction, or to be left as a null value, and be interpreted at retrieval time according to a user-requested interpretation (e.g., tx whose value could not be used before commit time). S e t - v a r assigns a new value to a variable's data. S y n t a x : set-vat (old, p, val, Td, Tv) S e m a n t i c s : set-vat (oid, p, val, Td, Tv) =-create-se(oid, p, data, val, T~, Tv~) I ~.Object-id = oid A , f now, oc) N AR((~) - FR((~.p) if rv=nil T~ := ~ Tv n AR(~) - FR(~.p) otherwise The default value for Tv, in this primitive, is now, co)'. This default has been used by other researchers (e.g., BZ82) assuming that the value was not valid from -co. This default is a natural extension of the update logic in conventional databases, where a new value replaces an older one as of the time it is inserted to the database. The functions F R and AR have been defined in Section 4.1. AR returns the set of chronons in which a given object is active, and FR returns the chronons in which a given variable is frozen. The actual valid time (T~) is derived by intersecting Tv with the times in which the variable can be modified A R ( ~ ) - FR(~.p) (the modifiable range). The modification of the valid time provided by the user, stems from considering a temporal database as a set

80

Opher Etzion, Avigdor Gal, and Arie Segev of many conventional databases, each of which is valid in a single chronon. Consequently, an update that affects a valid time interval in a temporal database is, in fact, a set of several independent updates, where each update can either succeed or fail in a given valid time chronon. A similar approach, in different contexts, was taken in other works as well (e.g., Sno87). For example, the operation set-vat ( oid=86~5~5, p= Social-Security-Number, va1=02345678, Td=nil, vv=ni O, applied to the database on Dec 12, 1993; ll:30pm, results in the creation of state-element (s14) in Figure 5.

F r e e z e - v a t freezes a variable. Syntax: freeze-var (old, p, Td, Tv) Semantics: freeze-var (old, p, Td, ~v) -create-se(oid, p, modify-control,"frozen", T~, Tv~) I c~.Object-id = oid A , r now, oh) n iR(c~) if Tv=nil ~-~ := ~ ~-, n AR(~) otherwise The default value for Tv in this primitive is now, co). The actual valid time (Tv~) is derived by intersecting Tv with the activity range of the object. For example, the operation freeze-vat (oid=86~5~5, p-- Social-SecurityNumber, Td=nil, Tv =nil), applied to the database on Dec 12, 1993; 10:00pm, results in the creation of state-element (s6) in Figur e 5. U n f r e e z e - v a r unfreezes a given variable. Syntax: unfreeze-var (old, p, Td, Tv) Semantics: unfreeze-var (oid, p, Td, Tv) -create-se(oid, p, modify-control, "changeable", T~, Tv') a.Object-id = oid A , ~ now, co) n AR(a) if Tv=nil Tv := ~ Tv N AR(a) otherwise

Tv~ is not calculated with respect to the frozen range of the variable. Thus, an unfreeze-var operation can override an earlier freeze decision. For example, the operation unfreeze-var ( oid=86~5~5, p= Record-Number, Td=nil, Tv----niO, that was applied to the database on Dec 13 1993; 10:02pm, resulted in the generation of state-element (s19) in Figure 5.


81

Object Level Update Primitives Create-obj: creates a new object that is an instance of a given class. Syntax: oid := create-obj (class) Semantics: oid := create-obj (c) old := generate-obj-id 0 | create-se-oid (oid) | create-se-class-ref (c, old). create-se-oid(oid) _-- create-se (old, p--"object-id', data, old, Td, vv)l Td=nOW A rv=now, co) create-se-class-ref (c, old) - create-se (old, p= "class-ref" ,data, c, Td, Tv) I ra=now A rv=now, co). The create-obj primitive creates two new state-elements. The first stateelement designates an object identity; the object identity is generated by the database and is returned as a result of applying the generate-obj-id builtin function. The object identity is a frozen state-element, the frozen status is protected by a meta-data integrity constraint that prevents the change of its status. The second state-element is a reference to the class c that is given as an argument using the object-id that was created earlier. The values of the time types of both state-elements are generated by the system and represent the systems defaults. They do n o t represent the object's validtime activespan, i.e., the time during which the object exists in the modeled reality. The activespan of an object is explicitly controlled by the user, and is associated with the Object-Status variable. For example, the operation create-obj (Patient), that was applied to the database on Dec 12 1993; 10:00pm resulted in the generation of state-elements (sl) and (s2) as presented in Figure 5 and returns the value 864545. S e t - o b j - s t a t u s changes the object status in a given valid-time temporal element. Possible values of the object status are Active, Suspended and Disabled. Object-Status is a special variable that cannot be handled by regular variable operations, thus it has its own set of operations that includes S e t - o b j - s t a t u s to set the value, and f r e e z e - o b j - s t a t u s and unfreeze-oh j - s t a t u s to freeze and unfreeze this status, respectively. Syntax: set-obj-status (oid, sval, Td, Tv ) Semantics: set-obj-status (old, sval, Td, %) -create-se (old, "object-status", data, sval, r~, T~) I (~.Object-id = old A sval C ("active", "suspended", "disabled" } A now, co) -- FR(~.Object-Status) if %=nil r~ = % - FR(a.Object-Status) otherwise v~ has a default value of the temporal element now, co). T~vand T~ determine the object's valid-time activespan. For example, the operation set-obj-status (oid=86~5~5, sval--"Active", Td=nil, %----nil), applied to the database on Dec 12 1993; 10:00pro, results in the generation of state-element (s3) in Figure 5. Freeze-obj-status freezes the object status in a given interval. Syntax: freeze-obj-status (oid, td, tv)

82


Semantics: freeze-obj-status (oid, Td, Tv) -freeze-vax (oid, "Object-Status", T~, Tv~). Tv~ has a default value of the temporal element now, co). T~v and T~ are used to determine the object's valid-time activespan. For example, the operation freeze-obj-status (oid=86~5~5, td=nil, tv = Dec 12 1993; lO:OOpm, co), applied to the database on Aug 25 1994; 8:15am, resulted in the generation of state-element (s23) in Figure 5. This operation freezes the object status retroactively during its entire activespan. U n f r e e z e - o b j - s t a t u s Unfreezes the variable Object-Status. S y n t a x : unfreeze-obj-status ( oid, Td, "iv) Semantics: unfreeze-obj-status (oid, Td, Tv ) unfreeze-vat (oid, "Object-Status", Td, Tv). Disable-Obj changes the object status to Disabled in the interval Its, co), where ts is the start time associated with the valid time, given as a parameter by the user. Only the start time of the interval is used since this status is final in the sense that the object can never be revived again. Consequently, the end chronon is set to co. S y n t a x : disable-obj (old, Td, "iv) Semantics: disable-obj (oid, Td, Tv) -- a.Object-id = old A , ~ now, co) - FR(~.Object-Status) if Tv=nil Tv := ~ Its, CO) -- FR(~.Object-Status) otherwise | Tv~ r t~, co) ---, abort | Set-obj-status (oid, "disabled", v4, %) Tv~ receives a default value of now, co). The disable-obj operation assumes that the object is disabled as of a certain chronon to infinity. If the object status is frozen at some chronon during the interval of the disable-obj operation, then the object-status cannot be changed in this chronon. Thus, the disable-obj operation cannot be completed and the transaction should be either aborted or treated as an exception. For example, the result of the operation disable-obj (oid=8645~5, Td=nil, Tv =nil), applied to the database on Aug 25 1994; 8:05am, is the same as the freeze-obj operation, as given above. In the general case, the disable-obj operation is not reversible. However, in exceptional cases, an authorized DBA can use the unfreeze-obj-status to reverse the disable-obj operation and "rescue" the object. I

4.4

I

Update Operation Types

The update operation types that have been discussed in Section 2 are defined using the primitives of Section 4.3. These update operation types are the only ones that are accessible to users.


83

Insert : S y n t a x : insert (c, rdt, Tvt, ( V l , . . . , Vn}) lVi=(pi, vali, Tdi, Tvi). Semantics: insert (c, Tat, rvt, (//1, .-., Vn} I v~=(pi, vali, rd~, rye) -(exists-identifier (e, {Vl, ..., vn}) --* abort | oid := create-obj (c) | set-obj-status (oid, "active", Tat, rvt) | set-var (oid, Pl, Vall, Tdl, T v l ) | . . . | set-var (oid, Pn, valn rdn, rvn) exists-identifier is a function, it takes as an argument a class id and the set of input variables, according to the class definition determines the object identifier (primary key) and checks if there exists an instance of the class c with the given identifier. If this function returns true then the transaction should abort. oid is set to be the new object's id, using the create-obj operation. The insert operation creates the object, using create-obj, sets its status to be active, using set-obj-status and then updates its variables, using set-van TdZ and Tvt are the decision and valid times of the object's valid-time activespan. i.e., the temporal element in which the object is active. The generated o/d is returned to the user. Example: A new patient is inserted to the database. The following operation provides the patient's name. insert (c=Patient, tall----Dec 12 1993; lO:OOpm, Tvt=Dec 12 1993; lO:OOpm,

o0) {Vl--(pl--Patient-Name, vail=Dan Cohen, Tall=nil, Tvl----Dec 12 1993; lO:OOpm, oo))}) (sl)-(s4) of Figure 5 are the state-elements added to the database as a result of this operation. Modify : S y n t a x : modify (c, obj, rdl , rvl , {Vl,..., vn}) v~ = (Pi, vali , Tdi , Tvi ). Semantics: modify (c, obj, rdl , Tvl , {//1, "" ", Vrt} lYi=(Pi, vali, rai, rvi)) = old := identify-obj (c, obj) | (oid = nil) --* abort | (r,l ~ nil) --* set-obj-status (old, "active", Tat, rvt) | set-var (old, Pl, vail, Tall, rvl) | ... | set-var (old, Pn, valn, ran, r,n) The modify operation retrieves the object identity, based on an identifier given by the user, using identify-obj. If the user assigns a value to the t,t, then it resets the object's valid-time activespan. Finally, it updates its variables, using set-van c denotes the class-id of the object. identify-obj is a function that converts object-identifiers (primary keys) to object-identities (surrogates). If the sought object does not exist in the database, then the modify operation cannot be completed and the transaction should be either aborted or treated as an exception. If there is more

84

Opher Etzion, Avigdor Gal, and Arie Segev than one qualifying object with the same object-identifier, then the user is prompted to decide which object is the required one. Example: The operation

modify ( c=Medical-Record, obj=12345678-1, Tvl=nil, Tall=nil, {vl---(pl=Disorder, vail--partial treatment 7 ,Tm =Dec 12 1993; 11:15pm, Tvl =Dec 12 1993; 11:15pm, co))}) changes one of the disorder's alternatives in the Diagnosis. It generates the state-element (sl0) in Figure 5. Suspend : S y n t a x : suspend (c, obj, Tdt, TvZ). Semantics: suspend (c, obj, Tall, TvZ) -oid := identify-obj (c, obj) | (oid = nil) -~ abort | set-obj-status (oid, "suspended", Tdl, TvZ). The suspend operation generates a new state-element of the variable ObjectStatus with the value "suspended," using set-obj-status. The operation uses the object identity that is given by the identify-obj function. For example, the following operation suspends the patient Dan Cohen as an active patient in the emergency room. As a result, state-element (s20) of Figure 5 is added to the database.

suspend (e=Patient, obj=Dan Cohen, Tall----Dec 19 1993; 8:00am, Tvl =Dec 19 1993; 8:00am, co)). Resume : S y n t a x : resume (c, obj, Tall,~-vt, {Vl, 999 Un}) I Ui ----(Pi, vali, Td~,V~i). Semantics: r e s u m e (c, o b j , r d l , . . , I = Yah, -oid :-- identify-obj (c, obj) | (oid = nil) --~ abort | set-obj-status (old, "active", Tdl, ~'vl) | set-var (oid, Pl, vall, Tall, ~'vl) | .-. | set-vat (old, Pn, valn, Tdn, Tvn) For example, the following operation resumes the patient Dan Cohen as an active patient when he is admitted again to the emergency room.

resume (c=Patient, obj=Dan Cohen, Td~=Aug 24 1994; 12:00am, %~=IAug 24 1994; 12:00am, co)) As a result, state-element (s21) of Figure 5 is added to the database. Disable : S y n t a x : disable (c, obj, Td, 7-v) Semantics: disable (c, obj, Td, Tv) =-oid := identify-obj (c, obj) | 7 The medical term partial treatment refers to cases in which a treatment has not been completed, for example: a patient has failed to take the entire quantity of antibiotics assigned to him.


85

(oid = nil) --* abort | disable-obj (oid, Td, Tv) In non-temporal databases, when an object is deleted, its information is removed from the database. In temporal databases, historical information is kept and the user can retrieve the contents of each object that was disabled, during its activity range. Moreover, modifications to the state of the object at times before it was disabled are allowed. For example, it is possible to retroactively update a medical record in the period it was open, during the time in which the record is already closed. The semantics of the disable operation is compatible with the "real world semantics," since it is possible that new information is discovered after an object is no longer in the active domain. Freeze

:

S y n t a x : freeze (c, obj, Tdl , Tvl , { Vl , . . . , l/n} ) V i = (Pi , Tdi , Tvi )" Semantics: freeze (c, obj, Tall , Tvl, {l/1, "" ", l/n} l/~=(P~, Tdi, Tvi) -~ oid := identify-obj (c, obj) | (old = nil) -~ abort | (Tvl r nil) --* freeze-obj-status (oid, Tdl, Tvl) | freeze-var (oid, Pl, Tall, Tvl) | ... | freeze-var (oid, Pn, Tdn, Tvn) A freeze operation can be applied to a single chronon, to an interval or to the entire variable history. This operation can be applied to non-temporal databases as well, such that a freeze operation always refers to the current state. For example, the following operation freezes the Social-Security-Number of

Dan Cohen freeze (c--Patient, obj=Dan Cohen, td~=nil, tvz=nil, ( vl = (pl---SocialSecurity-Number, tall----Dec 12 1993; lO:OOpm, tvl=Dec 12 1993; lO:OOpm, As a result, state-element (s6) of Figure 5 is added to the database. Unfreeze : S y n t a x : unfreeze (c, obj, Tall , Tvl , { t l , . . . , I/n} ) l/i ~- (Pi, Tdi, Tvi). Semantics:

unfreeze (c, obj, Tdl, 7vl, {l/l, "" ", l/n}) I l/i'~-(Pi, mdi, Tvi) -~ oid := identify-obj (c, obj) | (oid = nil) -~ abort | (Tvl ~ nil) --* unfreeze-obj-status (oid, Tdl, Tvt) | unfreeze-var (oid, Pl, Tall, Tvl) | ... | unfreeze-vat (oid, Pn, Tdn, Tvn) An unfreeze operation eliminates the "freeze" constraint (if it exists) for the specified valid time. For example, the following operation unfreezes the Record-Number variable.

unfreeze (c--Medical-Record, obj=123~5678-1, Tall----nil,Tvl----nil, (Vl =(pl=Record-Number, Tall=Dec 13 1993; lO:OOpm, rvl=Dec 13 1993;

10:0@m, As a result, state-element (s19) of Figure 5 is added to the database.

86


Revise : Syntax:

revise ( c, obj, ~-dl, Tvl , {71,.-., 7n}) "Y~ = ( vi , sq~ ), v~ = (p~ , vali , Td~, Tvi ) Semantics:

revise (c, obj,

T.L,

9

I

=

Sqd,

=

VaZ , Td ,

--

old :-- identify-obj (c, obj) |

(old -= nil) --* abort | (Tvl ~ nil) --+ set-obj-status (old, "active", rdt, TvZ) | vall ~ nil ~ modify (c, obj, Tdl, Tvl, { V l , . . . , gn})| Vse~ E sql 0 . . . 0 sqn: create-se(oid, pi, void-SE, se~,~'dz,Tvi). The r e v i s e operation replaces existing values with new ones, voiding the old values. Each revised value may cause the revision of multiple state-elements, selected by a selection query sqi. A revise operation can affect more than one state-elements in the following cases: 1. The valid time of the correction covers the valid time of several existing state-elements. 2. A change from a multi-valued semantics to a unique value semantics requires to void several state-elements. The r e v i s e operation has two parts. The first part adds state-elements with new values if there is at least one value that is not nil. If this part is not activated, then the state-elements are voided without replacing them with new values; the second part uses a selection query sqi for each revised value, to locate the state-elements t h a t should be voided, and voids these stateelements, or any part of their validity time that is specified by the Tv variable. For example, the operation revise (c=Patient, obj---Dan Cohen, { ~1 = ( p l = Social-Security-Number, va11=023~5678, ~'dl =Dec 12 1993; 11:30pm, %l--Dec 12 1993; 11:30pm, oc), sql---select t h e s t a t e - e l e m e n t w i t h value----12345678) applied in a transaction that committed at Dec 12 1993; 11:33pm, resulted in the creation state-elements (s13), (s14) in Figure 5. The revise operation allows the replacement of a frozen value, marking it as an erroneous one. The revise operation is necessary, along with the modify operation, in order to make a semantic distinction between a change in the real world and between a correction of a wrong value that was reported to the database. The default retrieve operations exclude revised values in retrieval operations (this default can be overridden). Additional use of the revise operation is to void state-elements without replacing them. In this case, vi -- nil and only the second part of the revise operation is applied. Set-SVS : Syntax: s e t - S V S ( c, obj, Tdl , Tvl , { b ~ l , . . . , 12n } ) 12i ---- O i , SVSi, qidi, Tdi, Tvi ) semantics: s e t - S Y S (c, obj, Tdt, TvZ, {Vl, 99 9 ~n}) I ~i = (Pi, SVSi, qid~, Td~, ~-vi) -old := identify-obj (c, obj) | (old = nil) --~ abort | (rvz ~ nil) --* set-obj-status(oid, "active',Tdl, 7vl) | create-se (oid, Pl, variable-SVS, (svsl, qidl), Tdl, Tvl) | | create-se (oid, Pl, variable-SVS, (svsl, qidn), Tdn, Tvn)

Extended Update Fkmctionality in Temporal Databases

87

The set-SVS command sets the SVS interpretation of one or more variables that belong to the same object. The interpretation consists of two parts: the SVS keyword (first, last, all, single, multi) and a query id. A query id is meaningful only when the single or m u l t i keywords are used, otherwise it is ignored. 4.5

Discussion

The update operation types are used as a uniform linguistic abstraction that supports any type of database update, for the data and control parts. The I n s e r t operation type creates a new object, it can also update the data bucket of the variables in the created object. The M o d i f y operation updates the data bucket of the variables in an existing object. Their semantics are an extended version of the semantics of these operation types in regular databases. The extended semantics follow the temporal database's structure. These operations are implemented using the set-var operation. The S u s p e n d , R e s u m e , and Disable operation are operations that affect the object-status. The R e s u m e operation can also be used to update the data bucket of the variables that belong to the object it resumes. The Freeze and Unfreeze update the modify-control buckets of variables that belong to a given object, they use the freeze-var and unfreezevar operations. The Revise operation updates the data bucket of the revised variable, and marks the revised state-elements in the Void-SE bucket. Note that the R e v i s e semantics does not use set-var, but instead it uses state-elements operations directly. This is done to bypass the frozen constraint, if exists, because it is possible to revise any state-element, even if it's variable is frozen. The Set-SVS sets SVS interpretation that overrides the static interpretation in the variable's level. This set of update operation types is a minimal set, but it is not necessarily the set that is appropriate for each application. It is possible to eliminate certain operations (i.e., not allow the Revise operation, in applications that do not support revisions) or to construct new operations using the low level primitives. For example, the combination of M o d i f y and Freeze in a single operation would enable to update values and freeze them using a single linguistic primitive. A formal definition of a new update operation type can be based on the predefined low-level primitives and should consider the following issues: 1. Whether the update operation type is applied with respect to the frozen range of the variable, the changeable range of the variable, or both? 2. What are the appropriate defaults for tv and td? 3. What are the constraints whose violation lead to a transaction failure?

5

Implementation

Issues

Several implementation issues are discussed in this section. Section 5.1 discusses alternatives for implementing the additional functionalities. Section 5.2 discusses

88


the implementation of decision t i m e as a primitive, Section 5.3 discusses the implementation in a temporal relational model, Section 5.4 discusses the mapping of the proposed model to TSQL2, and proposes some changes to TSQL2 in order to facilitate the support for the extended functionality.

5.1

T h e I m p l e m e n t a t i o n Alternatives

The functionality discussed in this paper does not exist in TSQL2 or in any other temporal language, at the primitive level. The implementation alternatives are: 9 using the proposed primitives as system design tools, using the existing database primitives at the database implementation level; 9 developing a wrapper based on the temporal infrastructure, whose primitives are compatible with the primitives presented in this paper; 9 devising a separate implementation model bypassing the temporal database infrastructure, for the use of applications that require the extended functionalities. The first alternative cannot satisfy this study's objectives; the use of the existing primitives would make writing programs that satisfy these extended functionalities tedious, hard to verify, and ad-hoc. The third alternative of devising a new implementation model is consistent with our objectives and can result in optimized performance. The construction of a standard model that combines the desired object oriented and temporal features is a major task for future research and development in the temporal database community in general, and we intend to base our further implementation on such a model. Our current prototype implementation is based on a relational database, using a subset of TSQL2. In general, we propose to implement our model as a wrapper on top of an TSQL2 implementation.

5.2

T h e I m p l e m e n t a t i o n of the Decision T i m e P r i m i t i v e

The following discussion is relevant for applications that require the decision time functionality. We argued that the decision time in some applications is indispensable in determining the correct order of real-world events, and in making decision analysis inferences. The implementation choices are whether to implement decision time as an additional time dimension, or try to achieve this functionality in another way. The decision time has two major impacts on the model's representation and semantics: 9 It adds an additional chronon to each state-element; 9 The function ASE that selects the valid value according to the last value SVS may employ the decision time and not the transaction time to determine the last value (the same may apply for first value SVS).


89

It is possible to emulate the decision time functionality, without using an explicit time type, by adding objects that designate decisions,s and using the beginning of the tv interval of their variables to denote decision time. Such a solution is proposed in OS95, and it complies with the desire not to add more primitives. However, we argue that this requirement is general, and important enough to have a direct representation. Using decision-time objects is too cumbersome, even at the logical level. 9 From space complexity point of view, adding the decision time to the stateelement level requires substantially less space than the creation of a redundant object; 9 From time complexity point of view, having the decision time available at the state-element level is less expensive than joining the state-element and the decision-related object; 9 From the development and maintenance point of view, it is clearer to the user since the decision-related object is not a concrete object in the application's domain. This analysis leads to the conclusion that the support of decision time as a model primitive is cost effective in cases that this functionality is required. If the decision time functionality is not required, we may eliminate the space overhead, by supporting an initialization parameter that eliminates the decision time. In this case, the decision time support is an optional feature selected at the initialization time of the application's schema. If decision time is not selected, then no space is saved for td at the state-element's level and the transaction time (tx) replaces the decision time (td) in the interpretation of the ASE retrieval function. An existing application can be converted to include decision time, such that the value of tx will be used for any missing value of t4. 5.3

I m p l e m e n t a t i o n of t h e M o d e l

The update functionality presented in this paper is "data model independent" in the sense that it can be implemented on various data models. Although a natural implementation is in an object-oriented model, a standard object oriented temporal data model does not exist. We therefore restrict this discussion to the relational model and TSQL2. The structure defined in this paper can be trivially mapped into the nested relational model IRKS88 that has been suggested in Tan86 to be a basis for temporal database implementation. Mapping the data structure into a "fiat" relational model requires the use of normalization rules. The implementation in the temporal model is not unique. A possible implementation can use universal relations as discussed in N+87. Another possible implementation uses the ENF (Extension Normal Form), which is an extension of the TNF (Time Normal Form) NA89, as follows. s Recall that 'decision' is a generic reference to the real-world event that led to the database transaction. In many applications it represents an actual decision.

90


Each relation designates a set of synchronous attributes, which are attributes that have common state-element's additional information (td, tv, etc.) at any chronon. We extend the definition of T N F to include all the additional information in a state-element, rather then just the tvthat represents an atomic combination of property and bucket consists of values and the state-element's additional information (without the revised-se component). A state-element of a set property is represented by several tuples with the same se-id. Each tuple is identified by both the se-id and its value. T h e implementation using the ENF blurs the original schema structure. Thus, the relationship among a class and its properties is represented using an additional relation for each bucket. Another relation stores the classification of objects into classes. Each relation represents a single combination of property and bucket, with the state-element's additional information. Note that in this particular example, all attributes are asynchronous. Object-id-data, Class-ref-data, and Object-status-data are system variables. Treatment-Data is a user defined Property. The creation of a state-element involves the addition of new tuple(s) to the appropriate property-bucket relation. This representation is restricted since the tv can be an interval but not a temporal element. To eliminate this restriction, a separate relation for the tv element should be created, identified by the state-element-id and the interval values. Redundant timestamping exist in tx when multiple state-elements are updated in the same transaction, in tv, when multiple state-elements have the same valid time, and in td, when multiple state-elements have the same decision times. Y~rthermore, there can be an overlap among all of them, e.g., t= = td = ts(tv). A possible space optimization feature is the enumeration of chronons and its use instead of the full representation; this, however, requires a conversion table from the enumeration to time-stamps, increasing the retrieval time.

5.4

Supporting The Extended Update Functionality With TSQL2

In this section we present a mapping of the update functionality to TSQL2, and the additional clauses required to augment TSQL2

Mapping to TSQL2 TSQL2 supports a bitemporal database environment, and uses temporal clauses as an extension of SQL-92. It is sufficient to map the create-se operation. The rest of the operations are translated to create-se as shown in Section 3. For the translation we assume that we have an underlying ENF bitemporal relational database with TSQL2 embedded within a host language that controls integrity constraints and aborts

the transaction when necessary. create-se(oid, p,/3, val, Td,

rv,

s)-=INSERT INTO p-~ VALUES (NEW, val, oid, VALID TIMESTAMP Tv

Td,

s)


91

old is the object id. val is the set of all values that have a common stateelement's additional information (e.g., tv, td, etc.) s can be either "changeable" or "frozen." Since tv is part of the temporal infrastructure schema, it is updated using the TSQL2 feature VALID T I M E S T A M P and not as part of the V A L U E S clause. The retrieval selections CSE and ASE can be easily expressed by TSQL2 queries as well.

A P r o p o s a l to A u g m e n t TSQL2 In order to support that functionality described in this paper in a convenient way, the following features should be supported as a primitive level, this can be done as a shell on top of TSQL2S+94, or as direct extension to the TSQL2 language. 1. A mechanism for handling simultaneous values is required. This mechanism should include new functions and defaults to support the retrieval of simultaneous values. These functions consist of the CSE and ASE functions. 2. A third time type (decision time) that reflects the correct order of occurrences in the modeled reality is needed. 3. A mechanism for freezing object's values and enforcing freezing constraints should be added. 4. A correction operation, that is semantically distinct from modification, should be introduced. 5. Clauses that represent the functionality of the update operation types would make the update language more powerful. We suggest to include the following new clauses in the extension of TSQL2. SUSPEND p: This clause would have a similar effect as the suspend primitive presented in Section 4. The disable primitive can use the semantics of the DELETE clause of TSQL2. The use of delete as an alias to disable is necessary to guarantee the compatibility of TSQL2 with SQL-92. It should be noted that TSQL2 permits changes to existing tuples even after the transaction commits. This can prevent the ability to restore all past states of the database. For example, a DELETE operation in a bitemporal database changes the tx according to the parameter given in this clause. Since deletions can be proactive and retroactive as well as current, the time of issuing the DELETE operation is not known after the modification. Consequently, queries with a viewpoint earlier than the time of change cannot be answered. R E S U M E p: This clause would have a similar effect as the resume operation type that was presented in Section 4. The clause: RESUME p VALID TIMESTAMP rv would effect an existing tuple, and change its validity interval. F R E E Z E : This clause would have a similar effect as the freezing operation type, as presented in Section 4. For example, FREEZE VARIABLES (vat1, ..., varn) OF p VALID TIMESTAMP zv

92

Opher Etzion, Avigdor Gal, and Arie Segev The FREEZE clause would freeze a set of a variables in a given valid time interval, but it can be effective only when it is combined with a mechanism that enforces the frozen range of a variable. U N F R E E Z E : This clause would have a similar effect as the unfreeze operation type that was presented in Section 4. For example, the clause: UNFREEZE VARIABLES (vat1, ..., yarn) OF p VALID TIMESTAMP 7v would unfreeze a set of variables, in a given valid time interval. R E V I S E . . . W I T H : This clause would have a similar effect as the revise operation type that was presented in Section 4. For example, the clause: REVISE se WITH VALUE (val) would revise the state-element se with the value with the value val. S E T - S V S This clause would have a similar effect as the set-svs operation type that was presented in Section 4. For example, the clause: SET-SVS vat WITH VALUE (val) USING QUERY (qid) would set the SVS value and associated query of var.

6

Conclusion

This work extends the temporal database functionality to accommodate complex applications. These extensions are a step in the direction of bridging the gap between temporal database capability and the needs of real-life applications. The results presented in this paper support a model that support flexible interpretation of simultaneous values semantics as an integral part of a temporal database. This functionality facilitates the database modeling and manipulation of real-world concepts. The main contribution of this paper is in the construction of a model that supports extended update features in both the schema level and update operation levels. The features include: simultaneous values semantics, modify control and revision control, all of them are required due to the simultaneous values capability of temporal databases. The case study has exemplified the need for such a model in a decision analysis system, however these functionalities can be used for other types of system. For example, it can be used to tailor a data model's capabilities according to application's needs, by adjusting the meta-data property class-ref property single or multiple classification of an object and fixed or variable classification of objects. The model presented in this paper includes a third time type called decision time that maintains the correct order of events in the modeled reality. This time type is essential for many types of applications, and is optionally supported as a model primitive. The system designer can choose if this feature is included, during the application's initialization time.


93

T h e proposed update functionality is d a t a model independent, and thus it can be designed as a shell on top of existing d a t a models. A mapping of the u p d a t e primitives to TSQL2 was described, as well as a list of extensions to TSQL2 required for a more complete temporal database functionality. A p r o t o t y p e of this system is currently being developed. This p r o t o t y p e is to be used in a simulation project in a hospital's training center. Further research will deal with d a t a modeling implementation on top of an object oriented model, the impact of simultaneous values on schema versioning, and investigation of applying research that has been done in the artificial intelligence area a b o u t possible world semantics and belief revision to extend this model.

Acknowledgments T h e case study was established with the help of Gilad Rosenberg M.D. We t h a n k the reviewers for m a n y helpful comments.

References A + 79.

ABN87.

AKGgl. Ari86. BraT8. BZ82. CC87.

CK86. CK94. CT85.

EGS92.

V. De Antonellis et al. Extending the entity-relationship approach to take into account historical aspects of systems. In Proceedings of the International Conference on the E-R Approach to Systems Analysis and Design. North Holland, 1979. T. Abbod, K. Brown, and H. Noble. Providing time-related constraints for conventional database systems. In Proceedings of the 13th International Conference on VLDB, pages 167-175, Brighton, 1987. S. Abiteboul, P. Kanellakis, and G. Grahne. On the representation and querying of sets of possible worlds. Theoretical Computer Science, 78, 1991. G. Ariav. A temporally oriented data model. ACM Transactions on Database Systems, 11(4):499-527, Dec 1986. J. Bradely. Operations in databases. In Proceedings of the Fourth International Conference on VLDB, W. Berlin, 1978. J. Ben-Zvi. The Time Relational Model. PhD thesis, Computer Science Department, UCLA, 1982. J. Clifford and A. Crocker. The historical relational data model (hrdm) and algebra based on lifespans. In Proceedings of the International Conference on Data Engineering, pages 528-537, Feb 1987. G.P. Copeland and S. Khoshafian. Object identity. In Proceedings of Object Oriented Programming Systems, Languages and Applications. ACM, 1986. S. Chakravarthy and S.-K. Kim. Resolution of time concepts in temporal databases. Information Sciences, 80(1-2):43-89, Sept. 1994. J. Clifford and A. U. Tansel. On an algebra for historical relational databases: two views. In Proceedings of the ACM SIGMOD, pages 247265, May 1985. O. Etzion, A. Gal, and A. Segev. Temporal support in active databases. In Proceedings of the Workshop on Information Technologies 8_4 Systems (WITS), pages 245-254, Dec 1992.

94 EW90.

F+94. FD71.

Gad88. GE98.

GES94.

HK87. J+94. KL83.

Kli93. McK88.

MS91.

N+87.

NA89. OS95. Pis94. RKS88.

RS91.

S+94. SA86.

Opher Etzion, Avigdor Gal, and Arie Segev R. Elmasri and G. Wuu. A temporal model and query language for ER database. In Proceedings of the International Conference on Data Engineering, pages 76-83, Feb 1990. R. Fagin et al. Reasoning About Knowledge. MIT Press, Cambridge, MA, 1994. N. Findler and D.Chen. On the problems of time retrieval, temporal relations, causality and coexistence. In Proceedings of the International Conference on Artificial Intelligence. Imperial College, Sep 1971. S.K. Gadia. The role of temporal elements in temporal databases. Data Engineering Bulletin, 7:197-203, 1988. A. Gal and O. Etzion. A multi-agent update process in a database with temporal dependencies and schema versioning. IEEE Transaction on Knowledge and Data Engineering, 10(1), February 1998. A. Gal, O. Etzion, and A. Segev. Representation of highly-complex knowledge in a database. Journal of Intelligent Information Systems, 3(2):185203, Mar 1994. R. Hull and R. King. Semantic database modeling: Survey, application and research issues. ACM Computing Surveys, 19(3):201-260, Sep 1987. C.S. Jensen et al. A consensus glossary of temporal database concepts. A CM SIGMOD Record, 23(1):52-63, 1994. M.R. Klopprogge and P.C. Lockmann. Modeling information preserving databases; consequences of the concept of time. In Proceedings of the International Conference of VLDB, Florence, Italy, 1983. N. Kline. An update of the temporal database bibliography. ACM SIGMOD Record, 22(4):66-80, December 1993. E. McKenzie. An Algebraic Language for Query and Update of Temporal Databases. PhD thesis, Computer Science Department, University of North Carolina in Chapel Hill, Sep 1988. E. McKenzie and R. Snodgrass. An evaluation of relational algebras incorporating the time dimension in databases. ACM Computer Surveys, 23(4):501-543, Dec 1991. B.A. Nixon et al. Design of a compiler for a semantic data model. Technical Report CSRI-44, Computer Systems Research Institute, University of Toronto, May 1987. S.B. Navathe and R. Ahmed. A temporal relational model and a query language. Information Sciences, 49:147-175, 1989. G. Ozsoyoglu and R. Snodgrass. Temporal and real-time databases: A survey. IEEE Transaction on Knowledge and Data Engineering, 1995. N. Pissinou. Towards an infrastructure for temporal databases--A workshop report. ACM SIGMOD Record, 23(1):35, 1994. M.A. Roth, H.F. Korth, and A. Silberschatz. Extended algebra and calculus for nested relational databases. A CM Transactions on Database Systems, 13(4):390-417, Dec 1988. E. Rose and A. Segev. Toodm-a temporal, object-oriented data model with temporal constraints. In Proceedings of the International Conference on the Entity-Relationship Approach, pages 205-229, San Mateo, California, 1991. R. Snodgrass et al. TSQL2 language specification. ACM SIGMOD Record, 23(1):65-86, Mar 1994. R. Snodgrass and I. Ahn. Temporal databases. IEEE Computer, 19:35-42, Sep 1986.


95

N.L. Sarda. HSQL: Historical query language. In Temporal Databases, chapter 5, pages 110-140. The Benjamin/Commings Publishing Company, Inc., Redwood City, CA., 1993. A. Segev, C.J. Jensen, and R. Snodgrass. Report on the 1995 international SJS95. workshop on temporal databses. ACM Sigmod Record, 24(4):46-52, Dec 1995. A. Shoshani and K. Kawagoe. Temporal data management. In Proceedings SK86. of the International Conference of VLDB, pages 79-88, Aug 1986. R. Snodgrass. The temporal query language TQUEL. ACM Transactions Sno87. on Database Systems, 12(2):247-298, June 1987. M.D. Soo. Bibliography on temporal databases. ACM SIGMOD Record, Soo91. 20(1):14-24, 1991. A. Segev and A. Shoshani. The representation of a temporal data model in SS88. the relational enviromnent. Technical ReportLBL-25461, Lawrence Berkeley Laboratories, Aug 1988. Invited Paper to the 4th International Conference on Statistical and Scientific Database Management. Tan86. A.U. Tansel. Adding time dimension to relational model and extending relational algebra. Information Systems, 11(4):343-355, 1986. TCG+93. A.U. Tansel, J. Clifford, S. Gadia, S. Jajodia, A. Segev, and R. Snodgrass. Temporal Databases. The Benjamin/Commings Publishing Company, Inc., Redwood City, CA., 1993. V.J. Tsotras and A. Kumar. Temporal database bibliography. ACM SIGTK96. MOD Record, 25(1):41-51, March 1996. WJL91. G. Wiederhold, S. Jajodia, and W. Litwin. Dealing with granularity of time in temporal databases. In R. Anderson et al., editors, Lecture Notes in Computer Science 498, pages 124-140. Springer-Verlag, 1991. ZP93. E. Zimanyi and A. Pirotte. Imperfect knowledge in databases. In P. Smets and A. Motro, editors, Proceedings of the Workshop on Uncertainty Management in Information Systems: From Needs to Solutions, pages 136-186, Santa Catalins, CA., Apr 1993. Sar93.

On Transaction Management in Temporal Databases Avigdor Gal* Department of Computer Science University of Toronto

Abstract. A transaction model provides a framework for concurrent processing of retrieval and update operations in a database. Considerable research effort has focused on various techniques and protocols to ensure the ACID properties of transactions in conventional databases. However, the adoption of these techniques and protocols to temporal databases is not trivial. In particular, a refined locking mechanism based on temporal characteristics can provide better concurrency among transactions in temporal databases than a conventional locking mechanism. Accordingly, this paper presents a set of modifications and fine tuning of traditional concepts in transaction management, to enable a better performance of temporal databases. We also suggest a scheme for implementing a transaction protocol for temporal databases on top of a relational database. The contribution of the paper is in identifying the unique properties of transaction management in temporal databases and the use of these properties to provide a refined locking mechanism to enhance the concurrency of such databases. In particular, we show that the classic 2PL mechanism cannot ensure serializability in temporal databases. Instead, we suggest an alternative method to ensure serializability and reduce redundant abort operations, which is based on a temporal serializability graph. Keywords: temporal databases, transaction management

1

Introduction

A t r a n s a c t i o n m o d e l p r o v i d e s a f r a m e w o r k for c o n c u r r e n t p r o c e s s i n g of r e t r i e v a l a n d u p d a t e o p e r a t i o n s in a d a t a b a s e . A c o n v e n t i o n a l t r a n s a c t i o n m o d e l e n s u r e s t h e following p r o p e r t i e s ( A C I D ) : A t o m i c i t y : E i t h e r all t h e o p e r a t i o n s of a t r a n s a c t i o n a r e p r o p e r l y reflected in t h e d a t a b a s e or n o n e are. C o n s i s t e n c y : E x e c u t i o n of a t r a n s a c t i o n in i s o l a t i o n p r e s e r v e s t h e c o n s i s t e n c y of t h e d a t a b a s e . * The work was conducted while the author was at the University of Toronto. He is currently at the MSIS Department, Rutgers University, 94 Rockafeller Road, Piscataway, NJ 08854-8054


On Transaction Management in Temporal Databases

97

Isolation: Each transaction assumes that it is executed alone. Any intermediate transaction results are not available to other concurrently executed transactions. D u r a b i l i t y : The values changed by the transaction persists after the transaction was successfully completed. Considerable research was dedicated to various techniques and protocols to ensure the ACID properties of transactions in conventional databases, e.g. the locking mechanism and the 2PL (Two Phase Locking) protocol, using serializability as a correctness criteria. However, adopting these techniques to temporal databases 27, i.e. databases that enable the accumulation of information over time and provide the capability to store different values of the same data element with different time characteristics, is not trivial. When adopting conventional techniques to accommodate the needs of temporal databases, a refined locking mechanism based on temporal characteristics should be designed, to provide better concurrency among transactions in temporal databases. Also, conventional protocols cannot efficiently support transactions in temporal databases. For example, as suggested in 21 and demonstrated in this paper, the classic 2PL mechanism cannot ensure serializability in temporal databases. Therefore, the use of either a strict 2PL or a serial transaction processing is required, when using conventional methods, to prevent a non-serializable transaction management in temporal databases. This paper presents a set of modifications and fine tuning of traditional concepts in transaction management, which are required for a better performance of temporal databases. To exemplify these modifications, we provide a scheme for implementing a temporal transaction protocol on top of a relational database model. The approach of using add-on temporal facilities with an existing conventional database model is considered nowadays the most suitable approach to provide temporal capabilities in databases 28. The contribution of the paper lies in identifying the unique properties of transaction management in temporal databases and the use of these properties to provide a refined locking mechanism to enhance transactions' concurrent execution in such databases. In particular, we provide an alternative method to 2PL, based on a temporal serializability graph, to ensure concurrency while reducing the number of redundant abort operations. The issue of transaction modelling for temporal databases was suggested as one of the challenges for further research at the NSF International Workshop on an Infrastructure for Temporal Databases 4 and was first introduced in 21 and 30. While the former relates to a transaction time temporal database only, the latter uses a simplified temporal data model and therefore results in a much simpler transaction model. In particular, the temporal database in 30 does not support transaction time and is not append-only. Some consideration to the issue of using commit time as a transaction time was given in 8, 19, and 28. While several previous researches have discussed the refinement of transaction models (e.g. SAGAS 14 and ACTA 6), none of them relate specifically to the unique properties of temporal databases. Nonetheless, it is worth noting

98

Avigdor Gal

that an extended model like SAGAS can serve as an underlying model for implementing better transaction models for temporal databases by using temporal independence and the refined locking mechanism presented in this paper. Most transaction models deal with time by using histories and time stamps as useful tools for ensuring serializability, and some research was done on querying transaction logs to obtain temporal-oriented information 3. Yet, these time considerations provide a different dimension than the one we handle in this paper, i.e. providing temporal databases with a coherent transaction model. Time stamping mechanisms for ensuring serializability were discussed in the framework of conventional databases 2 and some research was even dedicated to multiversion systems 16. While this area of research bares similarity to the research presented in this paper, several major differences exist. First, the time stamping does not provide temporal capabilities on top of a conventional database. Second, a transaction in some temporal database types (e.g. bi-temporal databases) is time stamped at commit time, rather than at the beginning of its execution. Therefore, as we show in this paper, the assumptions that hold for a time stamping mechanism are not valid for transactions in bi-temporal databases. The rest of the paper is organized as follows. Section 2 provides a data model and an execution model of a temporal database that is utilized throughout the paper. A transaction model for temporal databases is introduced in Section 3 followed by a scheme for implementing a temporal transaction protocol on top of a relational database model (section 4). Section 5 concludes the paper. 2

A data

model

for temporal

databases

This section introduces the basic concepts of a data model for temporal databases. The terminology is based on 10, and it uses a semantic data model which is more adequate for representing sets of sets, a common requirements in temporal databases. The generic model can be easily translated into a relational as well as an object-based data model (see 10 for details). An object is defined as an instance of a class or a tuple in a relation and a property is defined as an attribute in the object-based model and a column in the relational model. The term class defines either a class in the object-based model, or a relation in the relational model. Let D B S = {C1,C2, ..., Cm} be a database schema that consists of m classes. A class C~ has n~ properties P~,P~, ..., P~n,, each with a domain Dom(Pj), where a domain is a set of values. An instance of a property F j is an element of the set Dom(P~), represented as c~.P~, where c~ is an object identifier instance of the appropriate class, a class name, or a variable. A class domain of a class C~ (CDOM(CO) is a subset of the Cartesian product Dom(P~) x Dom(P~) x ... x Dom(P~,). An object state os of an instance o of a class C~ at time t is an element (Pl,P2, ...,Pn,) E CDOM(Ci). An application state at t is a set {os(o) I o is an instance of Ci (1 < i < m) at t}. Following previous works in the temporal database area, we adopt a discrete model of time 7, isomorphic to the natural numbers. Hence, a temporal domain is a domain T ~ N. The discrete model defines a Chronon 17 to be a nondecom-


99

posable unit of time (t E T), whose granularity is application dependent. A time interval is designated as ts, re), the set of all chronons t such that t8 (2) read (a.P, TI> (3) write (a.P, TI> (4) commit (5) commit 4 A useless transaction is a transaction which effect on the database is lost due to later values written to the database 25.


105

Since T2 is committed before T1, a serialized execution should be T2 ~ T1, and therefore T2 cannot use the value of (~.P in T as written by T1. In Section 3.2 we shall show that due to such scenaria, a 2PL protocol cannot guarantee serializability in a temporal database. A t e m p o r a l transaction m o d e l

3.2

Having defined the required refinements of conventional terminology to support the temporal dimension, this section presents a temporal transaction model using schedules and a temporal serializability test. We use the convention that a serializable schedule of executed operations ensures the consistency and isolation properties, and show that while a 2PL cannot guarantee serializability in bi-temporal databases, a strict 2PL guarantees serializability. We also provide a new protocol, the a b o r t / c o m m i t / w a i t protocol to minimize the number of aborted transactions. In what follows, a transaction is either a transaction as submitted by a user (if using global atomicity) or a transaction as p r o d u c e d b y a pre-processing step (if using temporal independence, as defined in Section 3.1). A schedule S = for a set of transactions T1, ...,Tm is an ordered set of operations of T1, ..., Tm such that at = Tj: (tr/tw)lock (a.P, T> or at = T3: unlock (c~.P, T). The following definition defines equivalence of schedules, using the available sets of state-elements.

Definition 4. - E q u i v a l e n c e o f s c h e d u l e s : Two schedules $1 and $2 are equivalent if: 1. For each variable (~.P, S1 and $2 produce similar sets of state-elements. 2. Each temporal read lock of a variable (~.P in T applied by a given transaction occurs in S1 and $2 at times when (~.P has similar sets of state-elements in T.

A weaker definition of an equivalence of schedules utilizes the last value semantics as a comparison mechanism, rather than sets similarity. This weaker definition converges to the equivalence definition of schedulers in conventional databases. As explained in Section 3.1, the granularity of locks in temporal databases involves a temporal element as well as a variable. Therefore, some modifications are required to a precedence graph in order to identify whether a given set of transactions is serializable or not.

Definition 5. - A t e m p o r a l serilizability graph: Let S ~- (al, ...,an) be a schedule for a set of transactions T1, ..., Tin. A temporal serilizability graph G(V, E) is a polygraph such that: -

V={T~,...,Tm}

E is generated as follows: 1. W R conflict: an edge ((T',T">,T> is generated if." Write lock: 3ai -- T' :twlock (a.P, T' ) A

106

Avigdor Gal

R e a d lcok: 3a3 = T":trlock (a.P, T")A Write lock precedes R e a d lock: i < jA Valid t i m e overlap: T' n T" = V # OA N o intermediate conflicting lock: Vi < k < j, (ak ~ T* :twlock (~.P, T*) V ak = T* :twlock(~.P, T*) A T" N V" = O) ts * * . W W / R W conflict: an edge pair ( ( (T , T ), T), ( (T , T ), T) ) is generated if: E x i s t i n g e d g e : 2((T',T"),T') 6 E A Conflicting item: 3a.P (qai = T': twlock (a.P, T' ) A3aj = T" : trlock ( c ~ . P , T " ) A i < j A T ' n r " = r'" # O A A n o t h e r write lock: 3ak = T* : twlock (~.P, T*)A T'" n r * = r # 0 ) . According to Definition 5, an edge (or a pair of edges) of the temporal serializability graph connects two transactions only if the destination of the edge can only be performed after the source of the edge. This can occur in the following two situations: 1. A transaction T" reads a value that was written by a transaction T ' with an intersecting valid time. Therefore, in a serial schedule T' commits before

Tit.

2. A transaction T* writes a value to a variable a . P in a valid time that intersects with a valid time of ~ . P that is part of a W R conflict between two transactions T' and T". In this case, T* can commit either before T' or after

Tit.

Definition 5 takes into account the temporal effect, and therefore there should be an overlapping of the locked temporal elements to generate a dependency. It is wortlknoting that since the retrieval of past application states (using observation times) are not involved in any conflict, they do not require a read lock and therefore do not affect the transactions' priority. However, the order of writing state-elements of the same variable with an overlapping valid time generates a W W conflict. This conflict prevents an erroneous interpretation of version queries.

Definition 6. - A t e m p o r a l cycle: Let G(V, E) be a temporal serializabiliy graph and let G' be a graph that is derived from G by choosing a single edge of each pair. A temporal cycle in G' is a sequence n

(((Ti,T2), T1), ((T2,T3),T2), ..., ((Tn, Ti), Tn) such that N Ti # O. i=l

T h e o r e m 1. Let T1, T2, ..., Tm be m transactions with transaction times X l , x2, ..., xm , respectively. A schedule S for T1, T~, ..., Tm is serializable iff there is a derivative of the temporal serializability graph G' (V, E'), built using S such that:

1. For no two transactions Ti and Tj such that xi < xj, ( (Tj, Ti), T) E E'. 2. G' (V, E') has no temporal cycles.


107

S k e t c h o f proof'. 5 ~ A s s u m e that S is a serializable schedule, yet for any derivative of the temporal serializability graph G' (V, E'), built using S, there exist two transactions Ti and Tj such that xi < xj and ((Tj, T~), T) 9 E'. Let ((Tj, T~), r) be an edge of a derivative of a temporal serializability graph: , T~), T) Was generated due to a WR conflict. ~ Ti reads a value that written by Tj. Tj should commit before T~ in any serial schedule equivalent to S. xj < xi. contradiction to the assumption. (1) 2. ((Tj, T~), r) was generated due to a W W / R W conflict. ~ : 1.

was

(a)

Tj writes a value before Ti and there is some transaction T that reads the value written by T~. ==~ Tj should commit before Ti in any serial schedule equivalent to S. xj < xi. contradiction to_the assumption. (2) (b) Ti writes a value after Tj reads a value written by some transaction T. Tj should commit before Ti in any serial schedule equivalent to S. xj < xi. contradiction to the assumption. (3) (1), (2), (3) ~ no two transactions Ti and Tj exist, such that x, < xj, x2, in order for a serial schedule S' to be equivalent to S, T2 should precede T1. Therefore, S is not necessarily serializable. It should be noted that the equivalent schedule in a conventional database (where (a.P, 7) is replaced by a.P) is serializable, whether T1 commits before T2 or vice versa. Hence, the temporal 2PL is not sufficiently strict to enforce a specific order of commit commands. However, as the following theorem shows, a strict 2PL can enforce a specific order of commit commands and therefore can guarantee serializability. T h e o r e m 2. Let T1, T2, ..., Tm be m transactions with transaction times Xl,X2,...,Xm, respectively, and let S be a schedule for T1,T2,...,Tm. If S obeys strict temporal 2PL, then S is serializable. Sketch of proof: Let S be a schedule that obeys strict temporal 2PL and

assume that S is not serializable. Using Theorem 1, for any derivative of the temporal serializability graph G' (V, E') built using S, the following two scenaria are possible: 1. G' (V, E') has a temporal cycle. A contradiction is reached in a similar fashion to classic proofs (see 29 for an example). 2. G' (V, E') has notemporal cycles, yet there exist two transactions T' and T" such that x' < x and ((T",T'), T) e E'. ====>dueto the protocol strictness, T" should release all of its locks before T' can acquire a lock for some participant (c~.P,T'), where T' N T r 0. Let t be the time T" released all of its locks. ===>due to the protocol strictness, x < t. (1) Since T' is not completed by the time T" released all of its locks (it should still acquire at least one more lock), t < X + . (2) (1), (2)====>x" < x'. contradiction. tt

:::~If S obeys strict temporal 2PL, then S is serializable.D While strict 2PL ensures serializability, it is not necessarily the best protocol as it reduces concurrent activities. Thus, we present a protocol (commit/abort/wait) in Table 1 to increase concurrency while avoiding redundant aborts. Algorithm 1 provides the relevant activities of transactions during their life cycle. In addition to retrieving and updating the database, transactions lock and unlock variables and update the temporal serializability graph. A transaction that concluded its activities might be forced to wait before committing,


109

due to other transactions t h a t precede it in the temporal serializability graph and did not commit yet. It is worth noting t h a t any transaction would either commit or abort eventually, since the temporal 2PL prevents t e m p o r a l cycles (although it cannot ensure by itself the order of the committing transactions). Also, a transaction that reaches the e n d t r a n s a c t i o n 6 bares similarity to the t e r m distributed database systems (e.g. 15). We refrain from using this term to avoid confusion, phase would eventually commit, as nothing can prevent it from doing so (all activities were successful and there are no temporal cycles).

The commit/abort/wait protocol: On s t a r t t r a n s a c t i o n do: 1 generate a new node Ti in the temporal serializability graph 2 execute operations, using temporal 2PL for locking and unlocking and update the temporal serializability graph according to its definition

1 2 3 4 5

On e n d t r a n s a c t i o n do: release remaining locks obtained by Ti if exists (T, T~) E E then: wait else: commit O n c o m m i t do: remove T~ and all edges (T, T ~) s.t. T = Ti or T = T ~ end wait commit transaction

On a b o r t do: release remaining locks obtained by T~ remove T~ and all edges (T, T ~) s.t. T = T~ or T = T' end wait abort transaction O n end wait do: if exists (T, Ti) E E then: wait else:

commit T a b l e 1. Annotated listing of Algorithm 1--commit/abort/wait protocol

6 transaction

110

4

Avigdor Gal

I m p l e m e n t i n g a temporal transaction model

Having shown the temporal transaction model, in this section we provide a scheme of a temporal transaction model, based on the relational data model. We define the notion of a shadow relation and utilize it in an algorithm for a strict conservative temporal 2PL. Various methods were suggested to map a temporal data structure into a relational model, using normalization rules. A possible implementation can use universal relations as discussed in 24. Another possible implementation uses the ENF (Extension Normal Form) 12, which is an extension of the T N F (Time Normal Form) 23, as follows. Each relation designates a set of synchronous attributes, which are attributes that have common state-element's temporal information (i.e. x and v) at any chronon. Therefore, each relation is augmented with an attribute that represents x and two attributes (vs and ve) for the boundaries of a v interval. We can assume that if R is a relation and X c R is the object identifier, then X U {x, Vs, re} serves as a key for R. Using ENF, the update of the temporal database is a tuple-based without redundancies. It is worth noting that the representation is restricted since the v can be an interval but not a temporal element. To eliminate this restriction, a separate relation for the v element should be created, identified by a unique state-element identifier and the interval values. The use of a conventional locking mechanism for a temporal database based on a relational database is impossible. For example, let R be a relation in ENF (where the set {a, x, vs, ve} serves as a key):

Ia Ib Ix IvsIv l !al bl tilt2 t4 al b 2 t 2 t 2 t3 al b3 t3!t3 t4 Let T1 be a transaction that requires the locking of the latest value(s) of a variable b of R in t2,ta). Based on a conventional locking mechanism, the first tuple is locked (being the only one with vs =t2 and Ve =t4), while the other two tuples can be accessed. However, using the temporal semantics and assuming that tl llAt -

lnAt 3500 Employee Thereseisgiven a 10% raise.Sincethesalarytab~ has notemporal support, Therese's previous salary islost. UPDATE salary s SET amount = I.i * amount WHERE s.eno = (SELECT e.eno FROM employee e WHERE e.ename = 'Therese') COMMIT

5.2

Level 2: Temporal Upward Compatibility

Level 2 ensures temporal upward compatibility as depicted in Fig. 2. Temporal upward compatibility is straightforward for queries. They are evaluated over the current state of a database with valid-time support. SQL3 E x t e n s i o n s The create table statement is extended to define tables with valid-time support. Specifically, this statement can be followed by the clause "AS VALIDTIME", e.g., "AS VALIDTIME PERIOD(DATE)." This specifies that the table has valid-time support, with states indexed by particular days. The alter table statement is extended to permit valid-time support to be added to a table without such support or dropped from a table with valid-time support. A table with valid-time support is conceptually a sequence of states indexed with valid-time granules at the specified granularity. This is the view of a table with valid-time support adopted in temporal upward compatibility and sequenced semantics. At a more specific logical level, a table with valid-time support is also a collection of rows associated with valid-time periods. Indeed, our definition of the semantics of the addition to SQL/Temporal being proposed satisfies temporal upward compatibility and sequenced semantics. Quick Tour: P a r t 2 The fol~wing statements are executed on February 1, 1995. ALTER TABLE salary ADD VALIDTIMEPEKIOD(DATE) ALTER TABLE employee ADD VALIDTIME PEKIOD(DATE) The followingstatements are typed in the next day(February 2, 1995). INSERT INTO employee VALUES('Lilian', 3463, '46 Speedway', 'Tuscon', DATE '1970-03-09') INSERT INTO salary VALUES(3463, 3400) COMMIT

Transitioning Temporal Support in TSQL2 to SQL3

167

The employee table contains the following rows. (In these examples, we used open-closed (" ...)") for periods.) ename eno street city birthday ITherese 5873 Bahnhofstrasse 121 Zurich 1961-03-21 Franziska 6542 Rennweg 683 Zurich 1963-07-04 Lilian 3463 46 Speedway Tuscon 1970-03-09

Valid 1995-02-01 - 9999-12-31) 1995-02-01 - 9999-12-31) 1995-02-02- 9999-12-31)

Note that the valid time extends to the end of time, which in SQL3 is the largest date. The s a l a r y table contains the following rows. eno 6542 5873 3463

amount Valid 1995-02-01- 9999-12-31) 3200 1995-02-01- 9999-12-31) 3630 3400 1995-02-02- 9999712-31 )

We continue, still on February 2. Tables, views, and queries act like before, because temporal upward compatibility is satisfied. To find out where the highsalaried employees live, use the following. SELECT e n a m e , city FROM high_salary AS s, employee AS e WHERE s . e n o = e . e n o

Evaluated over the current state, this returns the employee Therese, in Zfirich. Assertions and referential integrity act like before, applying to the current state. The following transaction will abort due to (1) a violation of the PRIMARY KEY constraint, (2) a violation of the emp_has_sal assertion and (3) a referential integrity violation, respectively. INSERT INTO e m p l o y e e VALUES ('Eric', 3463, '701 Broadway', 'Tucson', DATE

'1 9 8 8 - 0 1 - 0 6 ' )

INSERT INTO employee VALUES ('Melanie', 1234, '701 Broadway', 'Tucson', DATE

'1 9 9 1 - 0 3 - 0 8 ' )

INSERT INTO salary VALUES(9999, 4900) COMMIT

5.3

Level 3: Sequenced Language C o n s t r u c t s

Level 3 adds syntactically similar, sequenced counterparts of existing queries, modifications, views, constraints, and assertions (see Fig. 3). Sequenced SQL/ Temporal queries produce tables with valid-time support. The state of a result table at each time is computed from the state of the underlying table(s) at the

168

Richard T. Snodgrass et al.

same time, via the semantics of the contained SQL3 query. In this way, users are able to express temporal queries in a natural fashion, exploiting their knowledge of SQL3. Temporal views, assertions and constrains can likewise be naturally expressed. S Q L 3 E x t e n s i o n s Temporal queries, modifications, views, assertions, and constraints are signaled by the reserved word VALIDTIME. This reserved word can appear in a number of locations. D e r i v e d t a b l e in a f r o m c l a u s e In the from clause, one can prepend VALIDTIME to a < q u e r y expression>. View definition Temporal views can be specified, with sequenced semantics. Assertion definition A sequenced assertion applies to each of the states of the underlying table(s). This is in contrast to a snapshot assertion, which is only evaluated on the current state. In both cases, the assertion is checked before a transaction is committed. Table and column constraints When specified with VALIDTIME,such constraints must apply to each state of the table with valid-time support. Cursor expression Cursors can range over tables with valid-time support. Single-row select Such a select can return a row with an associated valid time. Modification statements When specified with VALIDTIME, the modification applies to each state comprising the table with valid-time support. In all cases, the VALIDTIMEreserved word indicates that sequenced semantics is to be employed. An optional period expression after VALIDTIME specifies that the valid-time period of each row of the result is intersected with the value of the expression. This allows one to restrict the result of a select statement, cursor expression, or view definition to a specified period, and to restrict the time for which assertion definitions, table constraints and column constraints are checked. Q u i c k T o u r : P a r t 3 We evaluate the following statements on March 1, 1995. Prepending VhLIDTIME to any SELECT statement evaluates that query on all states, in a sequenced fashion. The first query provides the history of the monthly salaries paid to employees. This query is constructed by first writing the snapshot query, then prepending VALIDTIME. VALIDTIME SELECT ename, amount F R O M s a l a r y AS s, e m p l o y e e AS e W H E R E s.eno = e . e n o

This evaluates to the following. ename Franziska Therese Lilian

amount 3200 3630 3400

Valid 1995-02-01 - 9999-12-31) 1995-02-01- 9999-12-31) 1995-02-02- 9999-12-31)


169

List those for which no one makes a higher salary in a different city, over all time. VALIDTIME SELECT e n a m e FROM employee AS el, salary AS sl el.eno = sl.eno AND NOT EXISTS (SELECT e n a m e FROM employee AS e2, salary AS s2 WHERE e2.eno = s2.eno AND s2.amount > sl.amount AND el.city e2.city)

This gives the following result. ename Valid Therese 1995-02-01- 9999-12-31) Franziska 1995-02-01 1995-02-02) i Therese is listed because the only person in a different city, Lilian, makes a lower salary. Franziska is listed because for that one day, there was no one in a different city (Lilian did not join the company until February 2). The reserved word VALIDTIMEspecifies that the semantics of the query to which it is prepended is a sequenced semantics. Conceptually the query is evaluated independently on every state of the underlying tables (cf. Fig. 3). This ensures that the user's intuition about SQL carries over to sequenced queries and modifications. A formal semantics for sequenced queries has been developed 14, 3. While Fig. 3 provides the meaning of sequenced queries in terms of states, the formal semantics is expressed in terms of manipulations on the period timesta.mps of the underlying tables with valid-time support. We then create a temporal view, similar to the non-temporal view defined earlier. In fact, the only difference is the use of the reserved word VALIDTIME. C~EATE VIEW high_salary_history AS VALIDTIME SELECT * FROM salary WHERE s .salary > 3500

Finally, we define a temporal column constraint. ALTER TABLE s a l a r y ADD VALIDTIME CHECK (amount > 1000 AND amount < 12000) COMMIT

Rather than being checked on the current state only, this constraint is checked on each state of the s a l a r y table. This is useful to restrict retroactive changes 6, i.e., changes to past states and predictive changes, i.e., changes to future states. This constraint is satisfied for all states in the table. Sequenced modifications are similarly handled. To remove employee number 5873 for all states of the database, we use the following statement.

170


VALIDTIMEDELETE VALIDTIMEDELETE

F R O M e m p l o y e e W H E R E eno = 5873 F R O M s a l a r y W H E R E eno ffi 5873

COMMIT

To correct the common misspelling of Tucson, we use the following statement. VALIDTIMEUPDATEemployee

SET c i t y = 'Tucson' c i t y = 'Tuscon'

WHERE

COMMIT

This updates all incorrect values, at all times, including the past and future. Lillian's city is thus corrected.

5.4

Level 4: Non-Sequenced Language Constructs

Level 4 accounts for non-sequenced queries (see Fig. 5) and non-sequenced modifications (see Fig. 6). Many useful queries and modifications are in this category. However, their semantics is necessarily more complicated than that of sequenced queries, because non-sequenced queries cannot exploit that useful property. Instead, they must support the formulation of special-purpose user-defined temporal relationships between implicit timestamps, datetime values expressed in the query, and stored datetime columns in the database. Nonsequenced SQL/Temporal queries can produce tables with or without valid-time support, depending on whether the valid-time period of the resulting rows is provided in the query. The state of a result table, if a table is without valid-time support, or the state of a result table at each time, if a table has validtime support, is computed from potentially all of the states of the underlying table(s), at any time. The semantics are quite simple. A nonsequenced evaluation treats a table with valid-time support as a table without temporal support, but with an additional column containing the timestamp. We again emphasize that this semantics is quite different from temporally upward compatible semantics (where the query is evaluated only on the current state) and from sequenced semantics (where the query is effectively evaluated on each state independently). SQL3 E x t e n s i o n s Nonsequenced valid queries are signaled by the new reserved word NONSEQIIENCEDpreceding the reserved word VALIDTIME.This applies analogously to nonsequenced modifications, views, assertions, and constraints. This reserved word can appear in a number of locations. D e r i v e d table in a from clause In the from clause, one can prepend NONSEQUENCED VhLIDTIMEto a . This results in a table without temporal support, and is the means of removing the valid-time support of a table.


171

View definition Nonsequenced views can be specified. A s s e r t i o n definition A nonsequenced assertion applies to the underlying table(s), considered as snapshot tables with an additional explicit timestamp column. This is in contrast to a snapshot assertion, which is only evaluated on the current state. In both cases, the assertion is checked before a transaction is committed. Table a n d c o l u m n c o n s t r a i n t s When specified with NONSEQUENCED VALIDTIME~ such constraints apply to the table with the valid timestamp treated as an explicit column. C u r s o r expression Cursors can range over the result of a nonsequenced select. Single-row select A nonsequenced single-row select will return a row without temporal support, even when evaluated over tables with valid-time support. Modification statements When specified with NONSEQUENCED VALIDTIME, the modification applies to the table considered as a snapshot table. In all cases, the NONSEQUENCEDreserved word indicates that nonsequenced semantics is to be employed. The syntax of a is extended to the following. { { NONSEQUENCED } VALIDTIME { } } An optional period expression after NONSEQUENCED VhLIDTIMEspecifies the valid-time period of each row of the result, and thus renders the resulting table to have valid-time support. This enables a table without temporal support to be converted into a table with valid-time support within a query or other statement. For modification statements, the period expression after VALIDTIMEspecifies the temporal scope of the modification: the times at which the modification is to be applied. The value expression "VALIDTIME( )" is available; it evaluates to the valid-time period of the row associated with the correlation or table name. This is required because valid-time periods of tables with valid-time support are not explicit columns (the alternative violates temporal upward compatibility). The following quick tour provides examples of these constructs. Quick Tour: P a r t 4 This quick tour starts with the database as it was when we last left it, in the previous quick tour. The employee table has the following contents. ename eno street city birthday Valid Franziska 6542 Rennweg 683 Zurich 1963-07-04 1995-02-01 - 9999-12-31) Lilian 3463146Speedway lTucson 1970-03-09 1995-02-02- 9999-12-31)

172


The salary table has the following contents. eno amount Valid 6542 3200 1995-02-01 - 9999-12-31) 3463 3400 1995-02-02- 9999-12-31) A period expression after VALIDTIMEspecifies the temporal scope of the result. List those who were employed sometime during the first six months. VALIDTIME PERIOD '1995-01-01 SELECT ename FROM employee

- 1995-07-01)'

This returns the following table. ename Valid Franziska 1995-02-01- 1995-07-01) Lilian 1995-02-02- 1995-07-01) On April 1, 1995, we give Lilian a 57o raise, starting immediately. This is a temporally upward compatible modification, and so is already expressible in SQL. UPDATE salary SET amount = 1.05 * amount WHERE eno = (SELECT S.eno FROM salary AS S, employee as E WHEKE ename = 'Lilian' AND E.eno = S.eno) COMMIT

This results in the following s a l a r y table. eno amount Valid 6542 3200 1995-02-01- 9999-12-31)i 3463 3400 1995-02-02 1995-04-01) 1995-04-01 9999-12-31) 3463 3570 To determine who was given salary raises, we must simultaneously consider two consecutive states of the s a l a r y table, before and after the raise. This requires a nonsequenced query. NONSEQUENCED VALIDTIME SELECT ename FROM employee AS E, salary AS Sl, salary AS S2 WHERE E.eno = Sl.eno AND E.eno = S2.eno AND Sl.amount < S2.amount AND VALIDTIME(Sl) MEETS VALIDTIME(S2)


173

MEETS ensures that the valid-time period associated with Sl is immediately followed by the valid-time period associated with S2. Since the valid-time period of a row is not in an explicit column (as this would violate temporal upward compatibility), VALIDTIME() is used to extract the associated valid-time period. The result is a table without temporal support, because NONSEQUENCEDis not followed by a period expression.

If we instead wish to get back a table with valid-time support, i.e., "Who was given salary raises, and when did they receive the higher salary?", we place a after VALIDTIMEto specify when each resulting row is valid. Our first try is the following, in which the extracts the valid timestamp of S2. NONSEQUENCED VALIDTIME VALIDTIME(S2) SELECT ename FROM employee AS E, salary AS Sl, salary AS S2 WHERE E.eno = Sl.eno AND E.eno = S2.eno AND Sl.amount < S2.amount AND VALIDTIME(SI) MEETS VALIDTIME(S2) Because an expression is associated with NONSEQUENCED VALIDTIME, the result will be a table with valid-time support, with a valid timestamp of the value of the timestamp of S2. However, this is not quite correct, because the period expression following VALIDTIME can only mention the columns of the following select statement, and the timestamp of S2 is not available.So we put the value in the select listand use an enclosing (sequenced) selectstatement to get rid of this extra column. VALIDTIME SELECT ename FROM (NONSEQUENCED VALIDTIME S2valid SELECT ename, VALIDTIME(S2) AS S2valid FROM employee AS E, salary AS SI, salary AS S2 WHERE E.eno = Sl.eno AND E.eno = S2.eno AND Sl.amount < S2.amount AND VALIDTIME(Sl) MEETS VALIDTIME(S2) ) AS S

The inner query evaluates to two columns, ename and S2valid. The NONSEQUENCED VALIDTIME includes a , specifying that a table with valid-time support is desired. The valid timestamp of each row is the same as the value of the S2valid column. The outer query just projects out the ename column, retaining the valid timestamp. This query has the following result. ename Valid Lilian 1995-04-01 - 9999-12-31)

174


If we had desired the time when the person had received the lower salary, we would simply specify VALIDTIME(S1) instead. This query is admittedly more complex to specify than the sequenced queries given in the previous section. In nonsequenced queries the user is doing all the work of manipulating the timestamps, whereas in sequenced queries, the DBMS handles the timestamps automatically, freeing the user from this concern. The reason that nonsequenced queries are included is that some (very useful) queries cannot be expressed using the sequenced semantics, the query just given being one example. Following VALIDTIME with a period expression in a modification (whether sequenced or not) specifies the temporal scope of the modification. Two applications of this are retroactive and future changes. Assume it is now May 1, 1995. Franziska, employee 6542, will be taking a leave of absence the last half of the year. VALIDTIME PERIOD ' 1995-07-01DELETE FROM salary

WHERE eno

=

1996-01-01)'

6542

VALIDTIME PERIOD '1995-07-01 DELETE FROM employee WHERE eno = 6542

- 1996-01-01)'

COMMIT

The s a l a r y table now has the~llowingcontents. eno amount 6542 3200 6542 3200 3463 3400 3463 3570

Valid 1995-02-01- 1995-07-01) 1996-01-01 - 9999-12-31) 1995-02-02- 1995-04-01) 1995-04-01- 9999-12-31)

The employee table has the following contents. ename Franziska Franziska Lilian

eno street city 6542 Rennweg 683 Zurich 6542 Rennweg 683 Zurich 13463 46 Speedway Tucson

birthday Valid 1963-07-04 1995-02-01 - 1995-07-01) 1963-07-04 1996-01-01 - 9999-12-31) 1970-03-09 1995-02-02 - 9999-12-31)

Note that these deletions split single periods into two, with a lapse between them. M a n y modifications are greatly simplified in this way. Also note that previously specified sequenced valid referential integrity and other constraints and assertions must apply to each state. Hence, ifthe firstDELETE was performed, but not the second, the COMMIT will abort because the emp.has_sal constraint is violated for certain states, such as the one on August 1, 1995. The period expression following VALIDTIME is also allowed for assertions and constraints. Assume that no employee m a y make less than 3000 during 1996.

Transitioning Temporal Support in TSQL2 to SQL3 CREATE ASSERTION s a l a r y _ c h e c k VALIDTIME PERIOD ' 1 9 9 6 - 0 1 - 0 1 -

175

1 9 9 7 - 0 1 - 0 1 ) ' CHECK

(NOT EXISTS ( SELECT * FROM salary WHERE amount < 3000 ) )

This is a sequenced assertion, and thus applies separately to each state in 1996. Nonsequenced assertions and constraints apply to all states at once. To assert that there is only one employee with a particular name, we use the following constraint within the employee table definition. CONSTRAINT unique_name ~I~IQUE (ename)

This is interpreted with temporal upward compatible semantics, and so applies only to the current state. If all we do is temporal upward compatible modifications, this will be sufficient. However, if we perform future updates, violations may be missed. To always check all states, a sequenced constraint is used. CONSTRAINT unique_name_per_time VALIDTIHE UNIQUE (ename)

This will ensure that at any time, each ename value is unique. To ensure that each ename is unique, across all states simultaneously, a nonsequenced constraint is required. CONSTRAINT unique_name_over_all_time NONSEOUENCED VALIDTIME UNIQUE (ename)

The above employee table satisfies the first two constraints, but not the third (the nonsequenced one), because there are two rows with an ename of Franziska. As with VALIDTIME, NONSEQUENCED VALIDTIMEcan appear in a from clause. To give employees a 5% raise if they never had a raise before, we first write a temporal upward compatible modification (i.e., without VALIDTIME) to give the raise. UPDATE s a l a r y AS S SET amount = i .05 * amount We can augment this statement to use a non-sequenced query in the from clause to look for raises in the past. UPDATE salary AS S SET amount = 1.05 * amount WHERE NOT EXISTS (SELECT * FROM (NONSEQUENCED VALIDTIME SELECT * FROM salary AS $1, salary AS $2 WHERE Sl.amount < S2.amount AND VALIDTIME(S1) MEETS VALIDTIME(S2) AND Sl.eno = S.eno) AS S3

) AND S.eno = S3.eno COMMIT

176


The N0T EXISTS was added. Assume that the update was entered on J u n e 1, 1995. The following s a l a r y table results. eno 6542 6542 6542 3463 3463

Valid amount 1995-02-01- 1995-06-01) 3200 3360 1995-06-01 - 1995-07-01) 1996-01-01- 9999-12-31) 3360 1995-02-02 - 1995-04-01) 3400 1995-04-01- 9999-12-31) 3570

Since the u p d a t e is evaluated with temporal upward compatible semantics, it changes the salary for valid times after June 1. Finally, we wish to define a snapshot view of the s a l a r y table in which the row's t i m e s t a m p appears as an explicit column, here when. CREATE VIEW snapshot_salary (eno, amount, when) AS NONSEQUENCED VALIDTIME SELECT S.*, VALIDTIME(S) FROM salary AS S

Coming around full circle, we can define a valid-time view on s n a p s h o t _ s a l a r y t h a t uses the explicit column v a l i d t i m e as an implicit timestamp. CREATE VIEW temporal_salary (eno, amount) AS VALIDTIME SELECT eno, amount FROM (NONSEQUENCEDVALIDTIME when SELECT * FROM snapshot_salary AS S) AS S2

This conversion can also be applied within queries and cursors.

6

Transaction-Time Support

Transaction time identifies when d a t a was asserted in the database. If transaction time is supported, the states of the database at all previous points of time are retained and modifications are append-only. Unlike valid time, transaction time cannot be entirely simulated with tables with explicit t i m e s t a m p columns. The reason is t h a t tables with transaction-time support are append-only: they grow monotonically. Specifically, while the query functionality can be simulated on tables with no temporal support, in the same way t h a t valid-time query functionality can be translated into queries on tables with no temporal support, there is no way to restrict the user to modifications t h a t ensure the table is append-only. While one can revoke permission to use DELETE,it is still possible for the user to corrupt the transaction t i m e s t a m p via database updates and insertions. This means that the user can never be sure t h a t w h a t the table says was stored at some time in the past was actually in the table at t h a t time. T h e only way to ensure the consistency of the d a t a is to have the DBMS maintain the transaction timestamps automatically. Many applications need to keep track of the past states of the database, often for audit traceability requirements. Changes are not allowed on the past states;


177

that would prevent secure auditing. Instead, compensating transactions are used to correct errors. When an error is encountered, often the analyst will look at the state of the database at a previous point in time to determine where and how the error occurred. However, SQL-92 (nor the current SQL3 draft) does not support such modifications or queries well. The following example will illustrate the problems. - Assume that we wish to keep track of the changes and deletions of the employee table. If standard SQL was used, this table would have six columns: ename, eno, s t r e e t , c i t y , b i r t h d a t e , and When (a PERIOD indicating when the row was valid). To know when rows are inserted and (logically) deleted, we add two more columns, InsertTime and DeleteTime, both of the data type TIMESTAMP.Of course, adding these two columns breaks the referential integrity constraint between s a l a r y , eno and employee, eno. The reader is invited to write this referential integrity constraint to take into account the three time columns. - We ask "How many highly paid employees have been in each city?" This query is quite complex to formulate in SQL. It turns out that one of the cities shows an unreasonable number of highlypaid current employees (more than 25). When was the error introduced? Is this inconsistency in the database widespread? How long has the database been incorrect? The query "When did we think that there were many highlypaid employees in Tuscon?" provides an initial answer, but is also very difficult to express in SQL.

-

These queries are very challenging, even for SQL experts, when time is involved. Modifications are even more of a problem. A logical deletion must be implemented as an update and an insertion, because we do not want to change the previously stored information. However, there is no way of preventing an application from inadvertently corrupting past states (by incorrectly altering the values of the InsertTime or DeleteTime columns), or a white-collar criminal from intentionally "changing history" to cover up his tracks. The solution is to have the DBMS maintain transaction time automatically, so that the integrity of the previous states of the database is preserved. The query language can also help out, by making it easy to write queries and modifications. With the small syntactic additions proposed here, transaction time can be easily added. ALTER TABLE employee ADD TBANSACTIONTIME

Because the DBMS is maintaining transaction time for us, for this table, we do not have to worry about the integrity of the previous states. The DBMS simply would not let us modify past states. The previously specified sequenced valid referential integrity still applies, always on the current state of the database. No rephrasing of this integrity constraint is necessary.

178


The query "How many highly paid employees have been in each city?" asks for the history in valid time of the current transaction-time state. Hence, it is particularly easy to specify, by exploiting transaction-time upward compatibility. VALIDTIME SELECT city, COUNT(*) FROM employee, salary WHERE employee.eno = salary.eno AND amount > 5000 GROUP BY city

To find where the error was made, we write the query "When did we think that there are many highly-paid employees in Tucson?" This uses the current time in valid time ("are"), but looks at past states of the database ("when did we think"). This requires a sequenced transaction query, with valid-time upward compatibility. T R A N S A C T I O N T I M E S E L E C T COUNT(*) FROM employee, salary WHERE employee.eno = salary.eno AND amount > 5000 AND city = 'Tucson' GROUP BY city HAVING COUNT(*) > 25

By having the DBMS maintain transaction time, applications that need to retain past states of tables for auditing purposes can have these past states maintained automatically, correctly, and securely. As well, the proposed language extensions enable queries to be written in minutes instead of hours. The concepts of temporal upward compatibility (TUC), sequenced (SEQ), and nonsequenced (NONSEQ)semantics apply orthogonally to valid time and transaction time. The semantics is dictated by three simple rules. The absence of VALIDTIME (respectively, TRANSACTIONTIME) indicates validtime (resp., transaction-time) upward compatibility. The result does not include valid-time (resp., transaction-time) support. - VALIDTIME(respectively, TRANSACTIONTIME)indicates sequenced valid (resp., transaction) semantics. An optional period expression temporally scopes the result. The result includes valid-time (resp., transaction-time) support. NONSEQUENCEDdenotes nonsequenced valid (resp., transaction) semantics. An optional period expression after NONSEQUENCEDVALIDTIME provides a valid-time timestamp, yielding valid-time support in the result. -

-

EXAMPLE 8: Starting with the simple query "Which Tucson employees are paid highly?" we can state queries that are different combinations of TUC, SEQ, and NONSEQ in valid and transaction time. In the following, we indicate valid time, then transaction time. Hence, "TUC/SEQ" means valid-time upward compatible and sequenced transaction-time semantics.


179

TUC//TUC

Which Tucson employees are current paid highly? A table with no temporal support results. SEQ//TUC Which Tucson employees are or were paid highly (as best known)? Note the the employee had to be in Tucson at the same time they were highly paid. A table with valid-time support results. TUC//SEQ Who did we think are the highly-paid Tucson employees? A table with transaction-time support results. NONSEQ/TUC Which highly-paid employees lived at some time in Tucson, as best known? A table with no temporal support results. TUC/N'ONSEQ When was it recorded that a Tucson employee is currently paid highly? A table with no temporal support results. SEQ//SEQ When did we think that some Tucson employee was paid highly, at the same time? A table with both valid-time and transaction-time support results. BEQ//NONSEQ When did we correct the information to record that some Tucson employee was paid highly? A table with valid-time support results. For each transaction time, we get a row with valid-time support, indicating when the employee is now considered to be in Tucson and be highly paid. NONSEQ//SEQ Who was recorded, perhaps erroneously, to have resided in Tucson at some time and was paid highly, perhaps at some other time? Here we get a table with transaction-time support, indicating when the perhaps erroneous data was in the table. NONSEQ//NONSEQ When did we correct the information, to record that some Tucson employee was paid highly, perhaps at some other time? Here a table with no temporal support results.

TUC in valid time translates in English to "at now;" SEQ translates to "at the same time;" and NONSEQ translates to "at any time." TUC in transaction time translates to "as best known;" SEQ translates to "when did we think ... at the same time;" and NONSEQ translates to "when was it recorded that." This example illustrates that all combinations are meaningful and useful. D While this example emphasized the orthogonally of valid and transaction time, that TUC, SEQ, and NONSEQ can be applied equally to both, there are still some differences between the two types of time. First, valid time can have a precision specified by the user at table creation time. The transaction timestamps have an implementation-dependent range and precision. Second, valid time extends into the future, whereas transaction time always ends at now. Third, unlike a following NONSEQUF_~CEDVALIDTIME, a is not permitted after NONSEQUENCED TI~NSACTIONTIME, because it is not possible to compute a transaction timestamp. Such a timestamp may only be inferred via a sequenced transaction query. Finally, during modifications the DBMS provides the transaction time of facts, in contrast with

180


the valid time, which is provided by the user. This derives from the different semantics of transaction time and valid time. Specifically, when a fact is (logically) deleted from a table with transaction-time support, its transaction stop time is set automatically by the DBMS to the current time. When a fact is inserted into the table, its transaction start time is set by the DBMS, again to the current time. An update is treated, concerning the transaction timestamps, as a deletion followed by an insertion. The transaction times that a set of modification transactions give to the modified rows must be consistent with the serialization order of those transactions. The following examples will emphasize the parallel between valid-time and transaction-time support. Specifically, temporal upward compatibility guarantees that conventional, nontemporal queries, updates, etc. work as before, with the same semantics. Since the history of the database is recorded in tables with both valid-time and transaction-time support, we can find out when corrections were made, using a nonsequenced transaction query. Modifications take effect at the current transaction time. However, we can still specify the scope of the change in valid time, both before and after now (retroactive and postactive changes, respectively). Finally, arbitrarily complex queries in transaction time can be expressed with nonsequenced transaction queries. As always, the concepts also apply to views, cursors, constraints, and assertions. Quick Tour: P a r t 5 This quick tour starts with the database as it was when we last left it, at the end of the previous quick tour. The employee table has the following contents. Recall that closed-open periods are used here for the valid-time and transaction-time periods. ename eno street city birthday Valid Franziska 6542 Rennweg 683 Zurich 1963-07-04 1995-02-01 - 1995-07-01) Franziska 6542 Rennweg 683 Zurich 1963-07-04 1996-01-01 - 9999-12-31) Lilian 3463 46 Speedway Tucson 1970-03-09! 1995-02-02 - 9999-12-31) The s a l a r y table has the following contents. eno 6542 6542 6542 3463 3463

amount 3200 3360 3360 3400 3570

Valid 1995-02-01- 1995-06-01) 1995-06-01- 1995-07-01) 1996-01-01- 9999-12-31) 1995-02-02- 1995-04-01) 1995-04-01- 9999-12-31)

We can alter the employee table to be a table with both valid-time and transaction-time support, by adding transaction-time support. Assume that the current date is July 1, 1995. ALTER TABLE employee ADD TRANSACTIONTIME COMMIT


181

Since employee was a table with valid-time support, this statement converts it to the following table with both valid-time and transaction-time support. Recall that an the ending bound of the transaction-time period equal to the end of time simply indicates that the row still logically resides in the table, i.e., has not been logically deleted. ename Franziska Franziska Lilian

eno 6542 6542 3463

street Rennweg 683 Rennweg 683 46 Speedway

city Zurich Zurich Tucson

birthday 1963-07-04 I... 1963-07-04 ... 1970-03-09 ...

Valid Transaction ... 1995-02-01 - 1995-07-01)1995-07-01 - 9999-12-31) I ... 1996-01-01 - 9999-12-31) 1995-07-01 - 9999-12-31) ... 1995-02-02- 9999-12-31) 1995-07-01 - 9999-12-31) We retain the s a l a r y table as a table with valid-time support. Temporal upward compatibility guarantees that conventional, nontemporal queries, updates, integrity constraints, etc. work as before, with the same semantics. We can list those for which (currently, as best known) no one makes a higher salary in a different city. SELECT

ename

FROM employee AS el, salary AS sl WHERE e l.eno = s l.eno AND NOT EXISTS (SELECT ename FROM employee AS e2, salary AS s2 WHERE e2.eno = s2.eno AND s2.amount > sl.amount AND el.city e2.city)

This takes a timeslice in both valid time and transaction time at now, and returns the result: Lilian. We can also ask, for all time, when this is true, by simply prepending "VALIDTIME." VALIDTIME SELECT ename FROM employee AS el, salary AS sl WHERE el. eno = sl. eno AND NOT EXISTS (SELECT ename FROM employee AS e2, salary AS s2 WHERE e2.eno = s2.eno AND s2.amount > sl.amount AND el.city e2.city)

This returns a table with valid-time support, evaluated with sequenced valid semantics, after the current transaction timeslice has been taken. ename Valid Franziska i1995-02-01- 1995-02-02) Lilian i1995-02-02- 1995-04-01) Lilian 1995-04-01 - 9999-12-31)

182


There are two rows for Lilian, because two rows of s a l a r y participated in computing the result. Interestingly, Franziska satisfied the where condition for exactly one day, before Lilian was hired. Temporally upward compatible modifications also work as before. Assume it is now August 1, 1995. Franziska just moved.

UPDATE employee SET street = 'Niederdorfstrasse 2' WHEKE ename = 'Fr~nziska' COMMIT This update yields the following employee table. Note that although Franziska is at the new address starting on August i, 1995, since she wo not be an employee for the next five months, her new address is recorded from January I, 1996 onward. ename eno street city birthday Franziska 6542 Rennweg 683 Zurich 1963-07-04 .. Franziska 6542 Rennweg 683 Zurich 1963-07-04 .. Franziska 6542 Niederdorfstrasse 2 Zurich 1963-07-04 .. Lilian 3463 i46 Speedway Tucson 1970-03-09 .. ... ... ... ...

Valid 1995-02-01 1996-01-01 1996-01-01 1995-02-02-

1995-07-01) 9999-12-31) 9999-12-31) 9999-12-31)

Transaction 1995-07-01 1995-07-01 1995-08-01 1995-07-01 -

9999-12-31) 1995-08-01) 9999-12-31) 9999-12-31)

Since the history of the database is recorded in tables with b o t h valid-time and transaction-time support, we can find out when corrections were made, using a nonsequenced transaction query. Assume it is now September 1, 1995. T h e query "When was the street corrected, and what were the old and new values?" combines nonsequenced transaction semantics with sequenced valid semantics.

NONSEQUENCED TRANSACTIONTIME AND VALIDTIME SELECT el.ename, el.street AS old_street, e2.street AS new_street, BEGIN(TKANSACTIONTIME(e2)) AS trans_time FROM employee AS el, employee AS e2 WHERE el.eno = e2.eno AND TKANSACTIONTIME(el) MEETS TRANSACTIONTIME(e2) This yields the following table with valid-time support. The trans_time column specifies when the change was made; the implicit timestamp indicates the validtime period of the fact that was changed. ename old_street new_street 21"1 Franziska Rennweg 683 Niederdorfstrasse .. trans_time Valid 9999_12_31)1 . . . 1995-08-011 1996-01-01 -


183

To extract all the information from the employee table, we can use a sequenced valid/sequenced transaction query. VALIDTIME AND TKANSACTIONTIME SELECT

*

FROM employee

Modifications take effect at the current transaction time. However, we can still specify the scope of the change in valid time, both before and after now (retroactive and postactive changes, respectively). Assume it is now October 1, 1995. Lilian moved last June 1. VALIDTIMEPERIOD '1995-06-01 SET street = '124 Alberca' WHERE ename = 'Lilian' COMMIT

- 9999-12-31)' UPDATE employee

This update yields the following employee table. ename eno street city birthday Franziska 6542 Rennweg 683 Zurich 1963-07-04 Franziska 16542 Rennweg 683 Zurich 1963-07-04 Franziska 16542 Niederdorfstrasse 2 Zurich 1963-07-04 Lilian 3463 46 Speedway Tucson ~1970-03-09 Lilian 3463 46 Speedway Tucson 1970-03-09 Lilian 3463 124 Alberca Tucson 1970-03-09 ... ... ... ...

Valid 1995-02-01- 1995-07-01) 1996-01-01- 9999-12-31) 1996-01-01- 9999-12-31) 1995-02-02- 9999-12-31) 1995-02-02- 1995-06-01) 1995-06-01- 9999-12-31)

.. .. .. .. .. .. Transaction 1995-07-01- 9999-12-31) 1995-07-01- 1995-08-01) 1995-08-01- 9999-12-31) 1995-0~01- 1995-10-01) 1995-10-01- 9999-12-31) 1995-10-01- 9999-12-31)

Finally, arbitrarily complex queries in transaction time can be expressed with nonsequenced transaction queries. The query, "When was an employee's address for 1995 corrected?", involves nonsequenced transaction semantics and sequenced valid semantics, with a temporal scope of 1995. Assume that it is November 1, 1995. NONSEQUENCEDTKANSACTIONTIMEAND VALIDTIME PERIOD '1995-01-01 - 1996-01-01)' SELECT el.ename, el.street AS old_street, e2.street AS new_street, BEGIN(TKANSACTIONTIME(e2)) AS trans_time FROM employee AS el, employee AS e2 WHERE el.eno = e2.eno AND TRANSACTIONTIME(el) MEETS TRANSACTIONTIME(e2) AND el.street e2.street

184


This evaluates to the following result, which has an explicit column denoting the date the change was made, and an implicit valid time indicating the time in reality in question. ename old_street Inew-street trans-time I/Valid I Lilian 46 Speedway 124 Alberca 1995-10-01/11995-06-01 - 1996-01-01)1 Note that the period from February through May is not included in the valid time, as the street did not change for that period. As always, the concepts also apply to views, cursors, constraints, and assertions. In Sec. 5.3 we gave an example of a sequenced constraint (VALIDTIME CHECK (amount > 1000 AND amount < 12000)) on the s a l a r y table. This constraint must hold independently on every (valid-time) state of the table. In Sec. 5.4 we gave a series of valid-time constraints on the ename column of the employee table. Those alternatives apply orthogonally to the transaction time. As an example, the assertion, "An entry in the security table can never be updated. It can only be deleted, and a new entry, with another key value, inserted.", can be expressed with a nonsequenced transaction semantics, stating in effect that the key value is unique over all transaction time. CREATE TABLE s e c u r i t y ( keyvalue NUMERIC(8) NONSEQUENCED TRANSACTIONTIME UNIQUE,

)

7

Comparison with the UK Proposal

We end by comparing the above constructs, termed the US proposal, with the UK proposal 18, which has been incorporated into Part 7, SQL/Temporal 8, by applying them to the simple case study introduced in Secs. 3 and 6. This comparison will revisit and exemplify many of the salient points made earlier. These examples illustrate that SQL/Temporal could be extended in a minimal fashion along the lines discussed in this paper to provide much better support for temporal applications. 1. An employee table has five columns, ename, eno, s t r e e t , c i t y , and b i r t h date. The related salary table has two colmnns, eno and amount. Column s a l a r y , eno is a foreign key referencing the column employee, eno.

SQL without time: CREATE TABLE employee (ename VARCHAR(12), eno INTEGER PRIMARY employee, street VARCHAR(22), city VARCHAR(IO), birthday DATE) CREATE TABLE salary(eno INTEGER PRIMARY KEY REFERENCES employee, amount INTEGER)


185

US proposal with time: (discussed in this paper): CREATE TABLE employee (ename VARCHAR(12), eno INTEGER VALIDTIME PRIMARY KEY, street VARCHAR(22), city VARCHAR(10), birthday DATE) AS VALIDTIME PERIOD(DATE) CREATE TABLE salary(eno INTEGER VALIDTIME PRIMARY KEY VALIDTIME REFERENCES employee, amount INTEGER) AS VALIDTIME PERIOD(DATE) "AS VALIDTIME PERIOD(DATE)" specifiesthat an unnamed column, maintained by the D B M S , will contain the row's timestamp. "VALIDTIME" specifiesthat the integrity constraints (primary key, referential integrity) are to

apply at each instant (in this case, each day). UK proposal with time: CREATE TABLE employee(ename VARCHAR(12), eno INTEGER, street VARCHAR(22), city VARCHAR(10), birthday DATE, When PERIOD(DATE) ) CREATE TABLE salary(eno INTEGER, amount INTEGER, When PERIOD(DATE) )

The UK proposal does not have support for referential integrity for such tables, nor for primary key constraints (adding When to the primary key does not work). Additional syntax is needed. Currently the only way to do this is with complex ASSERTIONs, left as an exercise for the reader. 2. "List the history of those employees who have or had no salary."

SQL without time: SELECT ename FROM employee WHERE eno N0T IN (SELECT eno FROM salary)

US proposal: VALIDTIME SELECT ename FROM employee WHERE eno N0T IN (SELECT eno FROM salary)

To get the history of any query using the US proposal, simply prepend VALIDTIME. The change proposal and public-domain prototype demonstrate that the semantics may be implemented via a period-based algebra. The large body of performance-related research in temporal databases is applicable to implementing this semantics.

UK proposal: WITH El AS (SELECT eno, ename, EXPAND(When) AS EW FROM employee) WITH Sl AS (SELECT eno, EXPAND(When) AS EW FROM salary)

186

Richard T. Snodgrass et al. SELECT ename, PERIOD When, When AS When FROM El, TABLE(EI.EW) AS E2(When) WHERE eno NOT IN (SELECT Sl.eno FROM Sl, TABLE(SI.EW) AS S2(When) WHERE S2.When = E2.When) NORMALIZE 0N When

The semantics of EXPANDis to duplicate each row of the argument table for each granule (day) in the When period. Once this table has been expanded, perform the NOT IN individually, for each day (examining only those s a l a r y rows valid on the day in question), then NORMALIZEthe When column back to a period (collecting contiguous days into a single period). If each row is valid on average for one year, then the result of the equijoin of E1 and E2 will have 360 times the number of rows of employee, with a dramatic decrease in performance. Changing the granularity to second generates additional tuples on the order of a factor l0 s, which could seriously affect performance. The approach of using EXPANDINGdoes not work here, because the aggregate should be evaluated between the EXPANDand the NORMALIZE. The UK committee has provided a construct, EXCEPT EXPANDING,which can also be used to express this particular special case. The user can take the original SQL query, above, and map it into the relational algebra, with NOT IN being mapped to relation difference. 7rename(employee ~>~ (Treno(employee) -- 7reno(salary))) Then the user can m a p this back into SQL. SELECT ename FROM employee WHERE eno IN (SELECT eno FROM employee EXCEPT SELECT eno FROM salary)

As a third step, the user can m a p t h i s i n t o a temporal query using EXPAND and NORMALIZE. W I T H E 1 AS (SELECT ename, eno, EXPAND(When) AS EW FROM employee), E2 AS (SELECT eno, EXPAND(When) AS EW FROM (SELECT eno FROM employee EXCEPT EXPANDING(When) SELECT eno FROM salary) AS E3) SELECT ename, PERIOD E3.When, E3.When AS When FROM El, TABLE(EI.EW) AS E3(When) WHF.SU~EI.eno IN (SELECT eno FKOM E2, TABLE(E2.EW) AS E4(When) WHERE El.eno = E2.eno AND E3.When = E4.When) NORMALIZE ON When


187

This trick of using EXCEPT can also be applied with the US proposal, but omitting the complex third step and the EXPANDsand NORMALIZEsentirely. VALIDTIME SELECT e n a m e FROM employee WHERE eno IN (SELECT eno FROM employee EXCEPT SELECT eno FROM salary)

All of the UK alternatives have the problem (not shared by the US alternatives) that if the left-hand table has duplicates, then NORMALIZEwill automatically remove them, yielding an incorrect result (the original SQL query did not specify DISTINCT). It is an exercise to the reader to show how this English query can be correctly expressed using an explicit When column. It is possible to do so, but it is exceedingly difficult. There have been essentially no results published on how to optimize queries with expansion or normalize operations. Also, no general procedure has been provided for converting an arbitrary, non-temporal query into its temporal analogue using the UK constructs. Finally, while EXCEPT EXPANDING has been provided, no other expanding variants have been defined for other relational operators. In contrast, in the US proposal a sequenced variant of any query can be specified by prepending the VALIDTIMEreserved word. 3. "Give the history of the munber of highly-paid employees in each city."

SQL without time: SELECT city, COUNT(*) FROM employee, salary WHERE employee, eno -- salary, eno AND amount > 5000 GROUP BY city

US proposal: VALIDTIME SELECT city, COUNT(*) FROM employee, salary WHERE employee.eno = salary.eno AND amount > 5000 GROUP BY city The VALIDTIME specifiesthat we are interested in the time-varying count. The syntax is declarative.The semantics is specifiedon a row-by-row basis; changing the granularityfrom day to second willnot impact its performance.

UK proposal: WITH E1 AS (SELECT eno, city, EXPAND(When) AS EW FROM employee), Sl AS (SELECT eno, EXPAND(When) AS EW FROM salary WHERE amount > 5000)

188

Richard T. Snodgrass et al. SELECT city, COUNT(*), PERIOD E2.When, E2.When AS When FROM El, TABLE(EI.EW) AS E2(When), SI, TABLE(SI.EW) AS S2(When) WHERE E2.When = S2.when AND El.eno = Sl.eno GROUP BY city, when NORMALIZE ON When

T h e syntax is procedural: first expand, then execute the select, then normalize. The EXPAND operator generates a SET of DAYs, which is then used to duplicate the rows of employee, one for each day each row is valid (the join in the from clause). The GROUP BY ensures t h a t the COUNTis performed separately for each day. T h e NORMALIZE converts the m a n y rows, one for each day, into periods. 4. "Give Therese a salary of $6,000 for 1994."

SQL without time: UPDATE salary SET amount = 6000 WHERE eno IN (SELECT eno FROM employee WHEKE ename = ' T h e r e s e ' )

US proposal: VALIDTIME PERIOD '1994-01-01 - 1 9 9 4 - 1 2 - 3 1 ' UPDATE salary SET amount 6000 WHERE eno IN (SELECT eno FROM employee WHERE ename -- ' T h e r e s e ' ) =

UK proposal: T h e U K proposal has no support for this operation. Instead, each row must be examined to determine the overlap with 1994, and adjusted with an UPDATE and two INSERT statements. This is left as an exercise for the reader. 5. To know when rows are inserted and (logically) deleted, we add transactiontime support.

US proposal: ALTER TABLE employee ADD TRANSACTIONTIME ALTER TABLE salary ADD TRANSACTIONTIME

Since transaction time is automatically managed by the DBMS, system integrity is ensured. Due to temporal upward compatibility, the integrity constraints work as before, as do updates, such as the one above.

UK proposal: ALTER TABLE employee ADD COLUMN InsertTime TIMESTAMP(3) DEFAULT CURRENT_TIMESTAMP

ALTER TABLE employee ADD COLUMN D e l e t e T i m e TIMESTAMP(3) DEFAULT NULL


189

ALTER TABLE salary ADD COLUMN InsertTime TIMESTAMP(3) DEFAULT CUKRENT_TIMESTAMP ALTER TABLE salary ADD COLUMN DeleteTime TIMESTAMP(3) DEFAULT NULL

There is no support for transaction time in the UK proposal. There is no way to ensure that the application correctly manages the information in these two columns. System integrity can easily be compromised. Adding these two columns also breaks the primary key and referential integrity constraints. Such constraints must be reformulated as complex assertions that take the three time columns into account. Updates are more complicated when these additional columns are present. 6. "How many highly-paid employees are in each city?"

SQL without time: SELECT city, COUNT(*) FKOM employee, salary WHERE employee.eno = salary.eno AND amount > 5000 GROUP BY city

US proposal: SELECT city, COUNT(*) FROM employee, salary WHERE employee.eno = salary.eno AND amount > 5000 GROUP BY city

This still works, because the default is to take the currently valid data that has not been deleted or updated (temporally upward compatible in both valid and transaction time).

UK proposal: WITH El AS (SELECT eno, city FROM employee WHERE DeleteTime IS NULL AND CURRENTDATE OVF2J~APS When), Sl AS (SELECT eno FROM salary WHERE DeleteTime IS NULL AND CURRENT_DATE OVEBLAPS When AND amount > 5000) SELECT city, COUNT(*) FROM El, Sl WHERE El.eno = Sl.eno GROUP BY city

Since temporal upward compatibility is not satisfied by the UK proposal, the user must explicitly select the current information.

190

Richard T. Snodgrass et al. To get the history of the number of highly-paid employees in each city, some changes are required.

US proposal: VALIDTIME SELECT city, COUNT(*) FROM employee, salary WHERE employee.eno = salary.eno AND amount > 5000 GROUP BY city

We retain temporal upward compatibility in transaction time (i.e., the data that has not been deleted or updated), but specify sequenced valid semantics to get the history, via VALIDTIME.

UK proposal: WITH E1 AS (SELECT eno, city, EXPAND(When) AS EW FROM employee WHERE DeleteTime IS NULL), $1 AS (SELECT eno, EXPAND(When) AS EW FROM salary WHERE DeleteTime IS NULL AND amount > 5000) SELECT city, COUNT(*), PERIOD E2.When, E2.When AS When FROM El, TABLE(EI.EW) AS E2(When), $I, TABLE(S1.EW) AS S2(when), WHERE El.eno = Sl.eno AND E2.When = S2.When GROUP BY city, When NORMALIZE ON When

The user must explicitly select the currently stored information in transaction time ("WHERE D e l e t e T i m e IS NULL") and must EXPANDand NORMALIZE to compute the aggregate. 7. "When did we think that there were many (> 25) highly-paid employees in Tucson?"

US proposal: TRANSACTIONTIME SELECT COUNT(*) FROM employee, s a l a r y WHERE e m p l o y e e . e n o = s a l a r y . e n o AND amount > 5000 AND city = 'Tucson' GROUP BY city HAVING COUNT(*) > 25

TR~NSACTIONTIMEspecifies that we wish to look over past states of the table. VALIDTIME is not specified, as we want to know only about the information about current employees. The execution is on a row-by-row basis, and is independent of both the valid time and transaction time granularities.


191

UK proposal: WITH E1 AS (SELECT eno, EXPAND(WhenP) AS EW FKOM (SELECT eno, PF/%IOD(InsertTime, DeleteTime) AS WhenP FROM employee WHERE CURKENT_TIMESTAMP OVERLAPS When AND city = 'Tucson') AS ET), Sl AS (SELECT eno, EXPAND(WhenP) AS EW FROM (SELECT eno, PEKIOD(InsertTime, DeleteTime) AS WhenP FROM salary WHERE CURRENT_DATE OVERLAPS When AND amount > 5000) AS ET) SELECT COUNT(*), PERIOD E2.When, E2.When AS When FROM El, TABLE(EI.EW) AS E2(When), Sl, TABLE(SI.EW) AS S2(When) WHERE El.eno = Sl.eno AND E2.When = S2.When GROUP BY When HAVING COUNT(*) > 25 NORMALIZE 0N When The transaction time granularityis generally no coarser than a millisecond. Compared with the U S proposal, this query will expand into 3.10 I~ times the number of rows in the employee table.The salary table willbe similarly exploded, then a join on the two tables taken. It is not clear how to optimize this query, as the resultcould change at any millisecond:the aggregate

must be computed for each millisecond. It is doubtful that the UK query can even be computed with currently known query optimization/evaluation technology.

8

Summary

In this paper, we first outlined several desirable features of SQL/Temporal relative to SQL3: upward compatibility, temporal upward compatibility, and sequenced semantics. A series of four levels of increasing functionality was elaborated. The specific syntactic additions were outlined and examples given to illustrate these constructs. The extensions involve (a) the use of the VALIDTIME and TRANSACTIONTINEreserved words, to indicate valid-time, resp. transactiontime, support (in the case of schema specification statements) and sequenced semantics (in the case of queries, modifications, views, cursors, assertions and constraints), (b) the use of the NONSEQUENCEDreserved word for nonsequenced semantics, and (c) the use of a period expression to temporally scope sequenced and nonsequenced queries, modifications, views, cursors, constraints, and assertions. In the change proposals now before the SQL3 committees 14, 15, we provide a formal semantics, in terms of the formal semantics of SQL3, that satisfied the sequenced semantics correspondence between temporal queries and

192


snapshot queries, and also provide the semantics for nonsequenced queries. In those change proposals we also list alternative implementation approaches which vary in the degree of implementation difficulty and the achievable performance. The implementation alternatives all compute the result by manipulating periods, and thus their performance is independent of the granularity of the underlying tables. We also introduced tables with transaction-time support, sequenced transaction semantics, nonsequenced transaction semantics, scoping on transaction time via an optional period expression, and modification semantics. The specific syntactic additions were outlined and examples given to illustrate these constructs. We end by listing some of the advantages of the approach espoused here. Upward compatibility is assured, permitting existing constructs to operate exactly as before. Only three new reserved words, NONSEOUENCED, VALIDTIME, and TKANSACTIONTIME, are required. Satisfactionof temporal upward compatibility ensures that existing applications do not break when tables without temporal support have such support added. - The availabilityof sequenced semantics ensures that temporal queries, modifications,views, assertions,and constraints are easy to formalize, write and implement. Nonsequenced semantics permits tables with temporal support to be converted to tables without such support, with explicit timestamp columns, and for temporal support to be added to tables, even within a query. A simple period expression permits the temporal scope to be specified. - The transaction-time extensions are compatible with, and orthogonal to, those for valid time. - A public-domain prototype 16 demonstrates the practical viability of the proposed constructs. The quick tour was validated on this prototype. -

-

-

-

-

We note that none of these benefits accrue from the UK proposal. Acknowledgments The inspiration for the constructs described here and proposed for incorporation into SQL/Temporal is the TSQL2 language. The participation of the TSQL2 Language Design Committee, which included Ilsoo Ahn, Gad Ariav, Don S. Batory, James Clifford, Curtis E. Dyreson, Ramez Elmasri, Fabio Grandi, Wolfgang Ks Nick Kline, Krishna Kulkarni, T.Y. Cliff Leung, Nikos Lorentzos, John F. Roddick, Arie Segev, Michael D. Soo and Surynarayana M. Sripada, was critical. David Toman provided helpful comments on a previous draft. We also appreciate the extensive feedback from the ANSI and ISO SQL3 committees, which helped shape the specifics of this proposal.


193

This research was supported in part by the National Science Foundation through grants ISI-9202244 and IRI-9632569, by grants from IBM, the AT&T Foundation, and DuPont, by the Danish Technical and Natural Science Research Councils through grants 9700780 and 9400911, respectively, and by the CHOROCHRONOS project, funded by the European Commission DG XII Science, Research and Development, as a Networks Activity of the Training and Mobility of Researchers Programme, contract no. FMRX-CT96-0056.

References 1. Balr, J., M. B6hlen, C.S. Jensen, and R.T. Snodgrass, "Notions of Upward Compatibility of Temporal Query Languages," Business Informatics (in Cerman, Wirtschaftsinformatik) 39(1):25-34, February 1997. 2. B6hlen, M. H., C. S. Jensen and 1%. T. Snodgrass,. "Evaluating the Completeness of TSQL2," in Proceedings of the VLDB International Workshop on Temporal Databases. Ed. J. Clifford and A. Tuzhilin. Springer Verlag, September 1995, pp. 153-172. 3. BShlen, M. H. and C. S. Jensen. Seamless Integration of Time into SQL. Technical Report R-962049, Aalborg University, Department of Computer Science, Denmark, December 1996. 4. Gadia, S. K. "A Homogeneous Relational Model and Query Languages for Temporal Databases." ACM Transactions on Database Systems 13(4):418-448, December 1988. 5. Jackson, M. A. System Development. Prentice-Hall International Series in Computer Science. Prentice-Hall International, Inc., 1983. 6. Jensen, C. S. and R. Snodgrass, "Temporal Specialization and Generalization." IEEE Transactions on Knowledge and Data Engineering 6(6):954-974, December 1994. 7. Jensen, C. S., J. Clifford, R. Elmasri, S. K. Gadia, P. Hayes and S. Jajodia (eds). "A Glossary of Temporal Database Concepts." ACM SIGMOD Record 23(1):52-64, March 1994. 8. Melton, J. (ed.) SQL/Temporal. July, 1997. (ISO/IEC JTC 1/SC 21/WG 3 DBLLGW-013.) 9. Pissinou, N., R. T. Snodgrass, R. Elmasri, I. S. Mumick, M. T. ()zsu, B. Pernici, A. Segev, and B. Theodoulidis, "Towards an Infrastructure for Temporal Databases: Report of an Invitational ARPA/NSF Workshop," SIGMOD Record 23(1):35-51, March, 1994. 10. Snodgrass, R.T., I. Ahn, G. Ariav, D.S. Batory, J. Clifford, C.E. Dyreson, R. Elmasri, F. Grandi, C.S. Jensen, W. K~ifer, N. Kline, K. Kulkarni, T.Y.C. Leung, N. Lorentzos, J.F. Roddick, A. Segev, M.D. Soo, and S.M. Sripada. "TSQL2 Language Specification," ACM SIGMOD Record 23(1):65-86, March, 1994. 11. Snodgrass, R. T. and H. Kucera. Rationale for Temporal Support in SQL3. 1994. (ISO/IEC JTC1/SC21/WG3 DBL SOU-177, SQL/MM SOU-02.) 12. Snodgrass, R. T., K. Kulkarni, H. Kucera and N. Mattos. Proposal for a new SQL Part--Temporal. 1994. (ISO/IEC JTC1/SC21/WG3 DBL RIO-75, X3H2-94-481.) 13. Snodgrass, R. T. (editor), Ilsoo Ahn, Gad Ariav, Don Batory, James Clifford, Curtis E. Dyreson, Ramez Elmasri, Fabio Grandi, Christian S. Jensen, Wolfgang K/ifer, Nick Kline, Krishna Kulkarni, T. Y. Cliff Leung, Nikos Lorentzos, John F. Roddick, Arie Segev, Michael D. Soo and Suryanarayana M. Sripada. The Temporal Query Language TSQL2. Kluwer Academic Pub., 1995.

194


14. Snodgrass, R. T., M. H. BShlen, C. S. Jensen and A. Steiner. Adding Valid Time to SQL/Temporal, change proposal, ANSI X3H2-96-501r2, ISO/IEC JTC 1/SC 21/WG 3 DBL-MAD-146r2, November 1996, 77 pages. At URL: (versioncurrent November 21, 1996).

15. Snodgrass, R. T., M. H. BShlen, C. S. Jensen and A. Steiner. Adding 7~ansaction Time to SQL/Tempo~l, change proposal, ANSI X3H2-96-502r2, ISO/IEC JTC1/SC21/WG3 DBL MAD-147r2, November 1996, 47 pages. At URL: (versioncurrent November 21, 1996).

16. Steiner, A. and M. H. BShlen. The TimeDB Temporal Database Prototype, Version 1.07, November 1996. At URL: or at URL: (version current March 26, 1997). 17. Tsotras, V. J. and A. Kumar. "Temporal Database Bibliography Update," ACM SIGMOD R~ord 25(1):41-51, March, 1996. 18. UK SQL Committee, Expanded Table Operations. 1 9 9 6 . (ISO/IEC JTC1/SC21/WG3 DBL MCI-67) 19. Yourdon, E. Managing the System Lie Cycle. Yourdon Press, 1982.

Valid Time and Transaction Time Proposals: Language Design Aspects Hugh Darwen IBM United Kingdom Limited PO Box 31 Warwick CV34 5JL England [email protected]

Abstract. Several proposals (such as 5, 6) have been presented to ISO for consideration as temporal extensions to SQL. These proposals are based on approaches to valid time and transaction time, wherein the regular syntax for invocation of SQL operators on tables is interpreted in a special manner, based on the existence of "hidden" timestarnps. Concerns about such an approach, with reference to these specific proposals, have been expressed (8). Those concerns have been responded to (4). We further clarify our concerns and align them with stated language design principles that we believe to be generally agreed upon. We respond to 4 in the context of these principles. Although this discussion is taking place in the specific context of proposals for international standardization, we believe its import is of wider concern than that, meriting the attention of the temporal database community in general. Furthermore, 5 and 6 appear to be the most precise specifications to date to be based on the approach in question; for that reason, we invite people who are not interested in standardization to examine the wider issues that might be emerging from discussions based on those proposals.

1 Introduction We start by proposing a list of nine principles o f good language design. Then we comment on the approach taken in 5 and 6 in the light o f these principles. Our comments take the form o f a list of deviations from these principles, observed in 5 and 6.

2 Language Design Principles The principles that follow are offered without reference to any definitive text. The author believes that they are so well established that this attempt to express them in his own words should not cause any surprise or offence. In particular, the principles listed here were written without reference to 1, except for the use o f the term parsimony, o f whose prior use in 1 the present author was aware.

O. Etzion, S. Jajodia, S. Sripada (Eds.): Temporal Databases-Research and Practice LNCS 1399, pp. 195-210, 1998. 9 Springer-Verlag Berlin Heidelberg 1998

196

H. Darwen

1. Precise Specification First and foremost, every construct should be precisely specified, so that users can

accurately predict the effect that will be obtained from any particular use of that construct.

2. Encouragement of Good Practice The distinction between what is good practice and what is bad practice is sometimes disputable. A good language, therefore, should not seek to implement restrictions that would contravene Generality (see Principle Number 3) by effectively legislating against practice that might be perceived to be bad. However, the choice of non-primitive operators to be included in language l favours those which embrace and promote l's own concepts against those which might be perceived as violating l's Conceptual Integrity (Principle Number 9). 3. Generality To avoid undue proliferation of languages, a language seeks generality, to be applicable in a wide variety of situations. Generality is often achieved by being based on well known concepts that have been shown to offer completeness in some useful sense. Non-modal two-valued logic, arithmetic and the Turing machine are among such concepts.

4. Semantic Consistency The meaning of an expression is independent of the context in which that expression appears. A consequence of adherence to semantic consistency is that if some common expression is required to be used in more than one place, it can be written just once, assigned to some name, and subsequently referenced by use of that name.

5. Syntactic Consistency A counterpart, perhaps, of semantic consistency is syntactic consistency, whereby one meaning is always expressed the same way. For example, with reference in particular to SQL's facilities for associating names with expressions, it is not consistent to require name AS expression in one context and expression AS name in another; nor is it syntactically consistent to successfully terminate an inner transaction with RELEASE SAVEPOINT while the outermost transaction must be successfully terminated by COMMIT.

6. Orthogonality Where concepts are perceived and generally agreed to fit together cleanly without "interfering" with each other, the language is designed to honour that and does not include any constructs that contravene it. For example, as noted in connection with Principle Number 7, many languages embrace simultaneously the concepts of

Valid Time and Transeation Time Proposals: Language Design Aspects

197

type, value, variable and operator. Where they do so orthogonally, the following agreeable statements will hold true. A variable of any type can be def'med. Any value in a type can be assigned to a variable of that type. An invocation of an operator that results in a value of type t is permitted anywhere where a literal of type t is permitted, including in particular as an argument to some operator invocation. Operators on variables, such as assignment, are available for all variables, regardless of their type. 7. Parsimony Carefully chosen agreed concepts should be small in number. They should also be clearly distinct from one another. For example, the four concepts of type, value, variable and operator might be thought to provide a sufficient basis in many languages. Some languages dispense with variable (functional programming languages). Some, it might be argued, dispense with type (e.g., Rexx, Smalltalk).

8. Syntactic Substitution A language definition should start with a few judiciously chosen primitive operators, embracing the few chosen concepts. Subsequent development is, where possible, by defining new operators in terms of expressions using previously defined operators. Most importantly, syntactic substitution does not refer to an imprecise principle such as might be expressed as "A is something like, possibly very like B", where A is some proposed new syntax and B is some expression using previously defined operators. If A is close in meaning to B but cannot be specified by true syntactic substitution, then we have a situation that is disagreeable and probably unacceptable, in stark contrast to true syntactic substitution, which can be very agreeable and acceptable indeed.

9. Conceptual Integrity We would like to think of Conceptual Integrity as the sum of all of the foregoing, in the sense that adherence to our first eight principles will ensure adherence to this, the ninth. A few distinct concepts having been carefully chosen and agreed upon, they must be rigidly adhered to, without any deviation whatsoever, in the entire design of the language. No compromise is acceptable. For example a database language, having chosen the concepts of the theory known as The Relational Model of Data, adheres rigidly to the concept that all information is represented by attribute values in tuples in relations. In particular, it is not acceptable to sacrifice conceptual integrity in pursuit of simple syntax. For the record, 1 uses the term yardstick rather than principle, and lists the following "desirable properties:

198

H. Darwen Orthogonality: keep unrelated features unrelated. Generality: use an operation for many purposes. Parsimony: delete unneeded operations. Completeness: can the language describe all objects of interest? Similarity: make the language as suggestive as possible. Extensibility: make sure the language can grow. Openness: let the user 'escape' to use related tools."

We have interpreted Generality somewhat differently, so that it overlaps with 1's Generality and Completeness. We have not included Similarity, but there is overlap between this and our Syntactic Consistency. Extensibility is akin, we believe, to our Syntactic Substitution.

3 Deviations Observed in the Proposed Approach We proceed to discuss various aspects of 5 in the light of the foregoing Language Design Principles. Recall that 4 is the paper in which the authors of 5 (and 6) respond to concerns about their proposals that are expressed in 8.

1. Precise Specification Section 4.1 of 4 addresses 8's concern that the result of a beginning with VALIDTIME is not precisely specified in 5. For example, if it can be calculated that employee E1 worked on project J1 from June 1st to June 5th, an implementation is permitted to return any number of identical rows expressing that very thing; it is also permitted, for example, to return a row expressing that E1 worked on J1 from June 1st to June 3rd and another row expressing that E1 worked on Jl from June 2nd to June 5th, each of those any number of times, et cetera. It is not disputed, in 4, that the result is not precisely specified, but it is claimed that it is not desirable to specify it precisely. We stand by our position that, on the contrary, precise specification is not only desirable but required. Further, we fred that the arguments given in this section of 4 are either based on incorrect assumptions or not germane, as we now argue. First, 4 appears to interpreting 8's concern as insistence that every result be normalized. By "normalized" we mean what is also often referred to as "coalesced". A set of periods SP is said to be normalized if and only if for all pairs of distinct elements P1 and P2 in SP, P1 neither overlaps nor meets P2. If two rows are identical in all column values except for some period valued column, if might be possible to "coalesce" them into a single row if the two periods happen to overlap or meet. A table in which all such pairs of rows have been eliminated by iterative coalescing is said to be normalized. Although requiring normalization would be one way of making a precise specification, 8 does not explicitly request that particular specification.

Valid Time and Transcation Time Proposals: Language Design Aspects

199

Second, 4 states "There is no canonical way to represent a sequence of states, each of which may contain duplicates, with a set of period-stamped rows." (We assume that "multiset" was really intended, here.) We claim that this is not the case. One such canonical form is presented algorithmicaUy in 2, in a section headed NORMALIZE ALL. Third, whether some canonical form is available is in any case not the point at hand. The concern expressed in 8 is only that the specification is not precise, not that it fails to use some canonical form. Fourth, 4 claims that if normalization is required it can be explicitly requested. This is not the case. For the result to be normalized on its hidden valid lime support, it will first have to be converted to a table without valid time support, so that the timestamps of the valid time support now appear in a regular column, on which normalization can be effected. The result of the normalization is a table without valid time support; if this is now converted to a table with valid time support, the normalization we have taken the trouble to obtain might well be lost. . E n c o u r a g e m e n t o f G o o d Practice

Under 5's principle of Temporal Upward Compatibility, one is encouraged to modify existing "snapshot" tables by ALTER TABLE ... ADD VALIDTIME, a result of which is that such tables will subsequently retain deleted rows as a timestamped historical record. Commonly accepted good practice, on the other hand, would suggest certain decompositions. First, attributes that reasonably belong together under Boyce-Codd Normal Form (BCNF) in the snapshot table do not always reasonably belong together in the same table with valid time support added. For example, SALARY and ADDRESS, both being functionally dependent on EMPNO in the snapshot table EMP, reasonably occur together in that table. However, those two dependent attributes are likely to vary independently of each other over time, strongly suggesting that further decomposition is now necessary. Second, normally recommended practice would suggest keeping historical data and current data in separate tables, because the predicate for the historical data is not the same as the predicate for the current data. The predicate for historical data is of the general form "P during the period tl to t2", while that for current data is "P since tl, up until now" (in each case P stands for some predicate appropriate to a snapshot table). Note that typically the "during" predicate further implies "and not at the instant immediately preceding tl, nor at the instant immediately following t2. The "since" predicate similarly implies "and not at the instant immediately preceding tl", but does not imply "and not at the instant immediately following now". If we fail to separate the historical data from the current data, the predicate for the combination is an awkward disjunction in which t2 and now have

200

H. Darwen somehow to merged into a tingle placeholder, with inevitable loss of possibly important semantics. In 3 such problems do not arise unless users choose to make them for themselves. Consider, for example, the table representing the relationship of employees working on assigned projects. Its temporal version might be Has__Worked On Since(Employee, Project, Since), where the Since column shows the date on which the employee started to work on the project. The historical record of assignments might then be Worked On During(Employee, Project, During), where During is a period-valued column indicating the start and end dates of an assignment. The view that includes both the historical data and the current data can be obtained, if needed, via the following expression: SELECT * FROM Worked On During UNION SELECT S.*, PERIOD(Since,CURRENT_DATE) AS During FROM Has_Worked On Since AS S In contrast, 5 actually makes it quite difficult for users to follow the recommendation illustrated by the foregoing "employees and projects" example. In section 3.6 of 4 it is mentioned, correctly, that 8 "glosses over the problems of ... moving rows from one table to the other ...". We conjecture that 5's proposed extensions to UPDATE and DELETE could be replaced by similar mechanisms involving the several tables of an appropriate decomposition. In any case, we need to be convinced that SQL3 triggers are insufficient for the purpose at hand here, as these can be used to make implicit changes to one table consequential on explicit changes to another. We have one fmal remark to make under the principle of encouragement of good practice. We make it gently, we hope. It is in response to the point made in section 3.8 of 4, following an illustration of how to record current state in a table that also includes history: "If the user instead wished to use a HasWorked On Since table, that is perfectly fine. Valid-time support is entirely optional ...". In its general form, this point is frequently advanced by software developers in counterargument to concerns such as those expressed in 8. This is the counterargument that says that users who don't like the offered solution are welcome not to use it if they prefer some more long-winded solution. Such an argument appeals to what is known in some circles as the Groucho Principle, an analogy with Groucho Marx's joke: "Doctor, doctor, please help me. Every time I hit myself on the head with this hammer, it hurts." "Then don't do that!" (or some such words). We do not deny that the Groucho Principle might occasionally be an appropriate crutch. Usually, though, our response, as here, is:


201

What about the people who have to teach it? Theycan't just ignore it. What about the people who have to make it, who have to maintain it from release to release, who have to write the documentation? They can't just ignore it. Why should those who go in for "good" practice be penalized, because of all the effort that their vendors are putting in to support the others? In other words, we think it would be better all round for the patient not to be in possession of a hammer at all. . Generality Several observers, including the authors of 8, have remarked that proposals such as those in 5 appear to offer a method of reasoning over intervals that is unnaturally constrained to intervals in time, to exactly one such temporal element per table, and to tables that contain at least one column in addition to the temporal element. The remark is made only in passing here, as it is not disputed that the problem is addressed by the inclusion of explicit operators in SQL/Temporal (3), such as NORMALIZE, and support for period types with non-temporal element types, such as PERIOD(INTEGER). . S e m a n t i c Consistency

(To be fair, we should mention that the point made in this section has been disputed by one of the authors of 5, though the reason given was not clear to us.) Consider the example referred to in 4: SELECT Name FROM Employee WHERE Name NOT IN ( SELECT Manager FROM Employee ) If Employee is a table with valid time support, under 5, we can also write VALIDTIME SELECT Name FROM Employee WHERE Name NOT IN ( SELECT Manager FROM Employee ) Now consider the case where, under the principle of semantic consistency, we replace the invocation of the built-in operator NOT IN by an invocation of the user-defined function NOT A MGR, defmed thus (in syntax def'med in SQL/PSM, ISO/IEC 9075-4:1996 and in the current draft of SQL3):

202

H. Darwen

CREATE FUNCTION NOT A MGR ( Name VARCHAR(30) ) RETURNS BOOLEAN RETURN Name NOT IN ( SELECT Manager FROM Employee ); The snapshot version of the "employees who are not managers" query can now be written thus: SELECT Name FROM Employee WHERE NOT A MGR ( Name ) However, if Employee is a table with valid time support, we cannot use VALIDTIME SELECT Name FROM Employee WHERE NOT- A MGR ( Name ) as a replacement for VALIDTIME SELECT Name FROM Employee WHERE Name NOT IN ( SELECT Manager FROM Employee ) because the invocation of the function NOT A MGR will always be evaluated against the current state of Employee, whereas the invocation of the built-in operator NOT IN is evaluated under sequenced semantics. The reason why every invocation of NOT A MGR is evaluated against the current state is that the query included in the RETURN statement that is the body of that function is an outermost query that does not begin with the word VALIDTIME. The breach of semantic consistency we have observed here would, we contend, certainly astonish and probably dismay anyone using an implementation of 5. Even the use of SQL views appears to contravene semantic consistency under 5's proposals. Continuing with the current example, one might create a view whose result is a one-column table of names of employees who are managers: CREATE VIEW Manager AS SELECT Manager FROM Employee (Please excuse the use of Manager as both a table name and a column name, arising from a desire to be consistent with two things at the same time.) This


203

allows the following snapshot query to replace our original snapshot query to discover the names of employees who are not managers: SELECT Name FROM Employee WHERE Name NOT IN Manager However, we cannot by the same token replace the VALIDTIME version of this with VALIDTIME SELECT Name FROM Employee WHERE Name NOT IN ( TABLE Manager ) because the view Manager still returns the names of employees who are currently managers. In fact, this example is a syntax error under 5, precisely because the view Manager is not a table with valid time support. If one wanted to use views in the same way, in the VALIDTIME query as well as in the snapshot query, one would have to create a second view, such as: CREATE VIEW ManagerVT AS VALIDTIME SELECT Manager FROM Employee and write VALIDTIME SELECT Name FROM Employee WHERE Name NOT IN ( TABLE ManagerVT ) Similarly unfortunate consequences can be observed in connection with 6's proposal to add TRANSACTIONTIME syntax, just like VALIDTIME. The present author feels that these observations might well give rise to reconsideration of the "Possible Way Forward" suggested in Section 6.0 of 8, as that suggestion would appear to suffer from the same problems. The suggestion in question was to store timestamps in a regular column, sacrificing Temporal Upward Compatibility in its strict interpretation. Then, to express valid-time queries, instead of just writing the word VALIDTIME followed by the desired query, one would write VALIDTIME(CN), where CN specifies the column name to be used for the timestamps in every table, input, intermediate and output, involved in the query. . Syntactic Consistency

The new syntax proposed in 5 and 6 does not suffer from inconsistency within itself, but we do observe an important inconsistency when it is considered in conjunction with the language (SQL) that it is proposing to extend. In SQL, the

204

H. Darwen syntax for accessing data in a table is the column reference, taking advantage of the table's column names. In 5, for example, new syntax is proposed for the same purpose, namely, VALIDTIME(CN), where CN is a correlation name. Because temporal information is not stored in a regular column there is no column name for it, so VALIDTIME(CN) has to used instead of the CN.VALIDTIME that would be the regular SQL way of accessing the data if it were stored in a column named VALIDTIME.

It might be counter-argued that the phenomenon we observe here is not really a breach of syntactic consistency, because it would obviously be inappropriate to use the syntax of column reference to access data that is not in a column. In that case we might have to agree, but we would just observe that the new syntax, for something very similar to referencing a column, is a consequence of breaches of certain other Principles (specifically, Number 7, Parsimony and Number 9, Conceptual Integrity). .

Orthogonality

Section 3 of 8 shows that the concept of rows and tables with valid time support is not orthogonal to existing SQL concepts. Some of the points made in that section are disputed in 4, but these disputations contain incorrect statements and are thus invalid. For example, it is claimed that the two assignments in the example shown in section 3.3.1 of 8 assign the same value to the variable T. The two expressions assigned are ( SELECT C, I FROM T ) and ( VALIDTIME SELECT C, I FROM VT ). The second of these is an expression that would be legal syntax if 5's proposals were adopted into the language. Because it returns a table with valid time support, it cannot possibly return the same value as the first, an expression that is legal in SQL:1992 and in several (probably all) predecessors of that language. All tables in SQL:1992 are tables without valid time support. Actually, whether the two expressions return the same value or not was not our point in 8, so we will not discuss this matter any further here. Our point was that they are patently expressions of different types. Thus, if the variable T is assigned the first expression, a subsequent VALIDTIME SELECT * FROM TABLE ( T ) should be a syntax error (because 5 proposes a syntax rule to require tables accessed by a VALIDTIME query to be tables with valid time support). This syntax error would be in keeping with SQL's existing concept of strong typing accompanied by static type checking. But it cannot be a syntax error if it is not known until m - t i m e whether the table assigned to T is one with valid time support. (There is nothing in 5 to address this problem, either at compile-time or at run-time.) Similar remarks apply to sections 3.2, 3.3.2 and 3.3.3 of 4.


205

A further contravention of orthogonality can be observed if one considers some hypothetical additional operator that might be proposed as an extension to SQL's syntax. For the sake of illustration, we consider the clause REPLICATE BY n AS column-name, where n is a non-negative integer. We suppose that the effect of such a clause, appended to an SQL QS, is, for each row r in the result of QS, to generate n rows constructed from r by addition of a column of the specified name, with each integer value in the range 1 to n appearing in that column in exactly one of the generated rows. The following example shows how this operator could be specified by substitution. Suppose table T contains an integer column N. Consider SELECT * FROM T REPLICATE BY N AS I. This is the same as SELECT * FROM T, ( WITH TABLE_NUM AS (VALUES(l) AS TN(I) UNION SELECT TN.I+I AS I FROM TABLE NUM AS TN WHERE TN.I < T.N ) SELECT * FROM TABLE NUM ) AS TN The second table in the outer FROM clause here is a recursive query, correlated with the fwst table, T, delivering a table of degree 1 whose column is of type INTEGER. The value T.N determines the number of rows in TABLE NUM, whose I values range from 1 to T.N. Thus, each row in T is joined in turn, loosely speaking, with the first T.N ordinal numbers. Rows in T in which T.N is zero or negative are not represented in the result of the*join. However, the given substitution would not work in the case of, for example, VALIDTIME SELECT * FROM T REPLICATE BY N AS I, where T is now a table with valid time support, because the second of the two tables in the FROM clause, in the substitution, is not a table with valid time support as required in such cases under the proposals of 5. Some additional specification would have to be made to cater for the case where T is a valid-time table, where the given specification of TABLE__NUM is replaced by an expression yielding a valid-time version of TABLE_NUM. Further additional specifications would have to be made for any other such expression modifying constructs (e.g. TRANSACTIONTIME) that might be proposed. Consider also that, regardless of how such an extension as REPLICATE BY might be specified, an existing implementation would surely have to address as a special case the possibility of REPLICATE BY being evaluated in a VALIDTIME context.

206

H. Darwen

7. Parsimony Several concepts that would be brand new to SQL are proposed in 5 and 6: Rows and tables with valid time support (5). Rows and tables with transaction time support (6). Operators on expressions (i.e., ones that make the semantics of an expression vary according to contex0. Continuing from the previous point, the attempted application of a temporal logic in place of troth-valued logic when an SQL expression is thus operated on. Occurrence of a variable at the intersection of a row and a column (to accommodate "the moving point, now"). This is not actually proposed in 5 or 6 but certain support documentation and discussions have indicated that the authors of 5 and 6 would like to add this concept at some future time. The concept of rows and tables with valid time and/or transaction time support is so close to the existing concept of rows and tables without such support as to be clearly redundant and disagreeable under the principle of parsimony. Various consequences of this new concept are catalogued in 8, Section 3. That catalogue of consequences is unaffected by 4 because 4 does not make any substantive changes to what is proposed in 5 and 6; nor does 4 show any of the consequences described in 8 to be invalid conclusions or based on incorrect assumptions.

8. Syntactic Substitution It is claimed in 4 that the specifications in 5 and 6 are in fact just "syntactic sugar" for certain operations that can be expressed using SQL operators already defined. Now, it can be seen at a glance that 4 is not here referring to syntactic substitution, even though we would claim that syntactic substitution is precisely what is usually meant by those members of the language design community (especially those who participate in ISO/IEC JTC1/SC21/WG3 Database Languages) who sometimes use the term "syntactic sugar". One reason why this can be seen at a glance is that the very firs example of "syntactic sugar" in 4 is the claim that ALTER TABLE Employee ADD VALIDTIME PERIOD(DAY) is syntactic sugar for ALTER TABLE Employee ADD COLUMN VALIDTIME PERIOD(DAY). It is clear that the first is not a substitute for the second, because the first does not yield a table such that SELECT * FROM Employee has a column called VALIDTIME, while the second

Valid Time and TranscationTime Proposals: LanguageDesign Aspects

207

does. A casual reading of 5 will quickly reveal all sorts of other differences in the effects of these two statements. The other "syntactic sugar" claims in 4 are subject to the same remarks. If "syntactic sugar" was being used in the sense of "something like", then the observations are irrelevant, to whatever extent anybody might agree with "something like" in each particular case. If it is being used in the agreeable sense of syntactic substitution, the claims are patently incorrect. For an example of syntactic substitution, consider the use of the SQL/Temporal EXPAND operator in a query of the general form SELECT FROM

R.C, XP.D R, TABLE ( EXPAND (R.P) ) AS XP(D)

In SQL3 without SQL/Temporal's EXPAND function and without SQUFoundation's TABLE syntax for "unnesting" nested tables, this could be expressed as SELECT DISTINCT R.C, XP.D FROM R, ( WITH x AS ( SELECT BEGIN(R.P) AS D, PERIOD (BEGIN(R.P), LAST(R.P) AS P FROM VALUES(R.P) AS R(P) WHERE DURATION(R.P) > 0 UNION SELECT NEXT(D) AS D, PERIOD (BEGIN(P), LAST(P) AS P FROM X WHERE DURATION(P) > 0 ) SELECT D FROM X ) AS XP 9. Conceptual Integrity The proposed new concept, rows and tables with valid time and/or transaction time support, is so close to the existing concept of rows and tables without such support that its differences from the existing concept would be perceived by many as a contravention of conceptual integrity. Requirements such as Temporal Upward Compatibility (disputed in 8), are not strong enough to warrant such a deviation. Temporal Upward Compatibility refers to the property of applications whereby they continue to work exactly as before after the addition of temporal information to the database; in particular, this includes the retention of historical records in a database that previously did not retain historical records. We dispute

208

H. Darwen the requirement, or at least the manner in which it is being pursued, by observing that SQL database administrators already have ways and means of protecting applications from addition of columns to existing tables. Further, if historical records are placed in new tables, then existing applications are obviously unaffected. It is claimed in 4 that the concept of special kinds of table is not at all new to SQL, and various categories mentioned in the current SQL3 specification are cited: "base table" versus "derived table", which is nothing more than a distinction between table variables and table values; "created table" versus "declared table", "global table" versus "local table", "subtable" versus "supertable", "temporary table" versus "permanent table", which are all distinctions between different kinds of table variable, not different kinds of table value; "grouped table" versus ungrouped table, where a grouped table is something that conceptually exists only during evaluation of a ; ordered table versus table with an implementation-dependent order, which is nothing to do with tables at all, but to do with the order in which a cursor ranges over the rows of a query result. In fact, there are no special kinds of table value in SQL. On the contrary, all and only the SQL operators on tables (SELECT, FROM, WHERE et cetera) are available on every table, and this concept is crucial. Furthermore, for all that there is a plethora of different kinds of table variable, any particular table value can equally well occupy any variable. We shall suggest, further, that 5 and 6 fail even to maintain integrity to their own declared new concepts. For example, it is claimed in Section 6.3 of 5 that a beginning with the word VALIDTIME is evaluated according to "sequenced" semantics (applying a temporal logic). As we show in point 5, below, this is not always the case. Finally, simplicity of syntax has been advanced by the proponents of 5 and 6 as the motivation for the chosen approach, apparently in justification for the various consequent contraventions of accepted language design principles. We have found no evidence in any of the background documentation (such as 7) that consideration had been given for the concerns expressed in 8, and in this present paper, when this approach was chosen.

4 Conclusion We have presented a set of proposed principles of language design. We have claimed that these principles are generally accepted as good ones in language design communities, such as, for example, the community involved in international standardization of SQL. We have observed extensive deviation from these principles in proposals, based on TSQL2, to provide temporal extensions to the ISO SQL


209

standard. We have stated that these observations are our justification our continuing opposition to those proposals. We invite others to consider these observations when considering their own positions on the proposals in question. Acknowledgments

The author thanks Mike Sykes and Chris Date for their critical reviews and suggestions.

References

1.

Bentley, J., Little Languages, in regular feature Programming Pearls, Communications of the ACM, Vol. 29, No. 8, August 1986.

.

Darwen, H., Planned UK Contributions to SQL/Temporal, December 17, 1996. (ISO/IEC JTC1/SC21/WG3 DBL MAD-221)

.

Melton, J. (ed), (ISO Worla'ng Draft) Temporal (SQL/Temporal), July, 1996. (ISO/IEC JTC1/SC21/WG3 DBL MCI-012)

.

Snodgrass, R.T., Response to MAD-220, January 1997. (ISO/IEC JTC 1/SC21/WG3 DBL MAD-245)

.

Snodgrass, R.T., M.H. B6hlen, C.S. Jensen and A. Steiner, Adding Valid Time to SQL/Temporal, 1996. (ISO/IEC JTC1/SC21/WG3 DBL MAD- 146r2)

.

Snodgrass, R.T., M.H. B6hlen, C.S. Jensen and A. Steiner, Adding Transaction Time to SQL/Temporal, 1996. (ISO/IEC JTC1/SC21/WG3 DBL MAD-147r2)

.

The TSQL2 Language Design Committee, The TSQL2 Language

Specification, September 1994. .

UK Response, On Proposals for Valid-Time and Transaction-Time Support, December 18, 1996. (ISO/IEC JTC1/SC21/WG3 DBL MAD-220)

References 2, 4, 5, 6 and 8 are to papers that have been presented to ISO, for discussion or to propose text for inclusion in Part 7 of SQL3, known as SQL/Temporal. They can be obtained via ftp from:

ftp://jerry.ece.umassd.edu/isowg3/dbl/MADdocs/madnnn.ps ftp://jerry.ece.umassd.edu/isowg3/dbl/BASEdocs/sql4hold/sql4-archivedtemporal.ps

210

H. Darwen

All of the ISO papers referenced here were tabled for presentation at the January 1997 meeting in Madrid, Spain, hence "MADdocs" and the "MAD-" prefix on paper numbers. As some kind of mnemonic, the reader may observe that the numerical order of these papers reflects the obvious sequence in which they were written: 146 and 147 made proposals for additional material in the SQL/Temporal base document (3); 220 responded to those proposals; 222 is not really part of the present discussion, but did outline ways in which one national body was interested in further developing the SQL/Temporal standard; 245 responded to 220.

Point-Based Temporal Extensions of SQL and Their Efficient Implementation David Toman* Department of Computer Science, University of Toronto Toronto, Ontario M5S 1A4, Canada david@cs, toronto, edu

A b s t r a c t . This chapter introduces a new approach to temporal extensions of SQL. In contrast with most of the current proposals we use single time points as references to time, while still achieving efficient query evaluation. The proposed language, SQL/TP, naturally extends the syntax of SQL/92 : it adds a single new data type that represents a linearly ordered universe of time instants. The semantics of the new language extends the standard SQL in the expected way: the new data type behaves identically to the existing types. We also eliminate or fix many of the problems connected with defining a precise semantics in interval-based languages. In addition we provide an efficient query evaluation procedure based on a compilation technique that translates SQL/TP queries to SQL/92. Therefore existing off-shelf database systems can be used as back-ends for managing temporal data.

1

Why yet another temporal extension of SQL?

After more t h a n a decade of research in the area temporal databases there is still no universal consensus on how temporal features should added to the standard relational model. Instead, there are dozens of mutually incompatible models and proposals. T h e more practical of these are often based on (often ad-hoc) extensions of existing relational languages, e.g., T Q U E L 17 and various temporal extensions of SQL: TSQL2 18, ATSQL2 5, and SQL/Wemporal 19, the current proposal of temporal extension of SQL3 to the ISO and ANSI standardization committees. T h e goal of this chapter is twofold: First, we point out severe problems comm o n to the majority of current proposals, namely representation dependent handling of temporal values and limited temporal dimensionality of the underlying temporal models. We argue t h a t these problems are inherently tied to the use of interval-valued temporal attributes and cause m a j o r problems when a precise semantics of the temporal query languages is to be defined. Second, we propose * The research was supported by a NATO/NSERC PDF fellowship, 1996-98. Extended abstract of this paper appeared in Proc. DOOD'97, Montreux, Switzerland, 1997.

O. Etzion, S. Jajodia, and S. Sripada (Eds.): Temporal Databases - Research and Practice LNCS 1399, pp. 211-237, 1998. 9 Springer-Verlag Berlin Heidelberg 1998

212

David Toman

an alternative solution that avoids these problems. Our proposal is based on a clean separation of the syntax and semantics (what is stored in the database and how do we query it) from the underlying compact representation of the temporal information (how is it stored in the database). While our technique can be applied to a wide range of relational query languages, we have chosen standard SQL with its duplicate semantics and aggregation operators as the starting point of our proposal. This choice demonstrates that we are indeed interested in real-life query languages rather than in toy examples. The rest of the chapter is organized as follows: the remainder of this section exposes problems inherent to the current proposals. Section 2 formally introduces the temporal data model: abstract and concrete (interval-based) temporal databases, following the terminology introduced in 9. Section 3 defines the syntax and semantics of SQL/TP and gives examples of temporal queries. We also include a brief discussion of compatibility issues and migration of SQL queries to SQL/TP (Section 3.5). Section 4 provides foundations for the proposed compilation technique. The chapter is concluded with several open questions and directions of future research. Appendix A summarizes the BNF of the core SQL/TP language and Appendix B briefly compares SQL/TP with the SQL/Temporal proposal to the ISO/ANSI SQL3 committee. 1.1

C u r r e n t Proposals

Most of the current proposals recognize that storing temporal data as ordinary tuples leads directly to enormous space requirements: a tuple has to be repeated for every time instant at which the represented fact holds in the modeled reality. Instead, tuples are associated with compact encodings of a set of time instants (often called period of validity). The sets of time instants are commonly represented by (finite sets of) intervals 17,19, bitemporal elements 4, 14, or other fixed-dimensional products of intervals (hyper-rectangles). The syntax of the chosen encoding then provides a domain of values for temporal attributes, e.g., pairs of interval endpoints. Indeed, ATSQL 5 and SQL/Temporal 19 use the BEGIN and END keywords to extract the endpoints of intervals, PERIOD keyword to construct new interval timestamps, and Allen's interval algebra 2 operators to compare the timestamps. However, this is only possible if the user knows that the timestamps are encoded using intervals. Moreover, this approach leads to a tension between the syntax of the query languages and their intended semantics: the data model and the semantics of the languages are point-based 1 4, 9, while temporal attributes refer to the actual encoding for sets of time instants (e.g., interval endpoints). This conflict leads to several unpleasant surprises when precise semantics needs to be defined. Most importantly, it is easy to show examples of queries whose answers depend on the choice of the particular encoding rather than on the underlying meaning of the data; cf. Example 1 below. Moreover, it is extremely hard to avoid this behavior in an elegant way. In many cases 1 The truth is associated with individual time instants rather than with sets of instants (intervals).

Point-Based Temporal Extensions of SQL

213

uniqueness of answers can only be guaranteed by operational means, e.g., by prescribing a particular evaluation order. This in turn leads to a very complicated and cumbersome semantics (if one exists at all). The problems become even more apparent and critical when a temporal extension for query languages with duplicate semantics has to be defined. Consider the following situation: E x a m p l e 1 Let D be a temporal relation (or an answer to a temporal query) that represents the region in the figures below.

(1)

-lll

(2)

1

(3)

I

It is important to understand that all the three figures represent the same relation. However, it is also clear that we can distinguish (2) and (3) using a first-order query in, e.g., SQL/Temporal. We call such queries representation dependent. These queries cannot be given meaningful semantics in the pointbased temporal models. Moreover, even very simple queries, e.g., counting the number of regions along the axes, give different results depending on the particular representation. The common temporal query languages, hoping to avoid representation dependencies (among other reasons), try to mimic a point-based semantics using set operations on the encoded timestamps and a normalization procedure on temporal relations. In a single-dimensional case, the representation dependency problem can indeed be successfully evaded using coalescing 6. TSQL2's informal semantics (including many examples of queries in TSQL2) is implicitly based on this assumption 3, 18. In the rest of this section we argue that the situation in Example 1 naturally arises during temporal query evaluation and cannot be avoided in general. First, we show that a single temporal dimension is not sufficient to formulate general temporal queries. Consider the query "are there two distinct time instants when a given relation contains exactly the same tuples?" 1 and 21 have independently shown that this query cannot be formulated in first-order temporal logic. A direct corollary of this result is that this query cannot be expressed in any single-dimensional temporal relational algebra 2, Moreover, 21 shows that to express all first-order queries the number of temporal dimensions cannot be bounded by any constant. Therefore, unbounded number of temporal dimensions cannot be avoided during query evaluation even if the final result is a single-dimensional temporal relation or boolean. This fact, combined with the use of explicit interval-valued temporal attributes, leads directly to situations similar to Example 1. There are other reasons for including multiple temporal dimensions in a temporal database system, e.g., the need for representing both valid and transaction 2 A relational algebra over the universe of single-dimensional temporal relations.

214

David Toman

time 14. However, we would like to emphasize that the need for unbounded number of temporal dimensions originates from the inherent properties of firstorder queries alone, even if the temporal database and the results of the queries are single-dimensional. Second, there is no unique normal form based on coalescing in the case the number of temporal attributes (the temporal dimension) is greater than one. Now it is easy to see why the coalescing-based approaches fail to guarantee representation independence: To guarantee fixed size of tuples in temporal relations, region (1) in Example 1 has to be represented by a finite union of rectangles, e.g., using the representation (2) or (3) above. While both (2) and (3) are coalesced, they can still be distinguished by a first-order query with interval-valued temporal attributes. In addition, in many cases the user has no control over the representation of intermediate results since the coalescing is performed implicitly by the system. With two or more temporal dimensions in queries coalescing leads to serious problems: the user has no knowledge if region (1) in Example 1 is actually represented as (2) or (3), but the results of queries often depend on this information. 1.2

T h e P o i n t - b a s e d Proposal: S Q L / T P

The above problems are inherent all temporal query languages with temporal attributes ranging over intervals. Therefore our proposal follows a different path to avoid all of the above problems: we let temporal attributes in our language range over the domain of single time instants. Our approach is based on several recent results in the area of temporal and constraint query languages 1, 15,20,21. In addition we define a meaningful approach to duplicate semantics and aggregation, independent of the chosen encoding (emending 10, 11). In addition to simple and elegant syntax and semantics we propose an eft/cient query evaluation procedure for SQL/TP over compactly encoded temporal databases. While we mostly concentrate on efficient evaluation of temporal queries over an interval-based encoding of time, the design of SQL/TP allows the use of additional encodings for sets of time instants, e.g., the linear repeating points 23 for periodic events, without the need for new syntax and semantics. There are several other features of the proposal: - SQL/TP statements can be compiled to standard SQL/923 12; the translated queries can be evaluated using an off-shelf database system. This way we can build a SQL/TP front-end to an existing RDBMS and provide temporal capabilities without modifying the underlying database system itself. - SQL/TP can express all representation independent SQL/Temporal queries. Moreover, SQL/TP is first-order complete (in the sense of 8). The results in 1, 21 show that this is not the case for any of the temporal query languages 3 Other relational languages can be used as well, provided they have sufficient expressive power.


215

based on a fixed-dimensional temporal relational algebra, e.g., 7; this issue is not clear for TSQL2-derived languages 5,18, 19 due to the presence of explicit coercion operators that convert encoded temporal attributes to data attributes. - The proposal can easily be extended to support migration requirements 19 for upward temporal compatibility with SQL. While SQL/TP itself does not literally follow these requirements, the compatibility can be easily achieved using a very simple syntactic manipulation of the source queries and adding tags to distinguish the particular compatibility modes, cf. Section 3.5. Before we start the technical part of the chapter, we would like to reiterate (to avoid any misunderstanding) that we are interested in intervals to store sets on time instants. This is the main difference between our approach and approaches taken by various interval logics 2, where intervals represent points in a two-dimensional (half-)space. However, due to the natural multidimensional character of SQL/TP, we can represent the true intervals using pairs temporal attributes. 1.3

S u m m a r y of C o n t r i b u t i o n s

The three main technical contributions of our proposal are: (1) the definition of a representation-independent temporal extension of SQL: we decouple the syntax and semantics of the language from the underlying data representation. We support both the set- and the duplicate-based semantics of SQL (including aggregation), (2) a query compilation technique for this extension that allows SQL/TP queries to be efficiently evaluated using a standard RDBMS, and (3) the definition of nouveau normalization technique that facilitates evaluation of temporal queries over an interval-based encoding of timestamps. We would also like to note that a naive direct translation of time instants to singleton intervals 16 fails as an efficient query evaluation technique: it causes an exponential blowup in complexity.

2

The Data Model for Temporal Databases

We start with the definition of the underlying data model: the domain of time is viewed as a discrete4 countably infinite linearly ordered set without endpoints (e.g., the integers). The individual elements of the set represent the actual time instants while the linear order represents the progression of time. The actual granularity of time is not important in our proposal 5. Besides the data type for time instants we also use all the other data types defined in standard SQL: strings, integers, floats, etc. As usual, these data types do not have an a-priori assigned interpretation. We summarily refer to those data types as the uninterpreted constants. 4 A dense linearly ordered time can be used with only a minor adjustment. 5 For our purposes any fixed granularity will do.

216

David Toman

The relationships between time instants and uninterpreted constants are captured in a finite set of temporal relations stored in the database. Following the terminology of 9 we distinguish the abstract temporal databases from the concrete temporal databases:

Definition 2 (Abstract Temporal Database) The signature of a predicate symbol R is the tuple (al : t l , . . . , ak : tk) where ai are distinct attribute names, ti the corresponding attribute types, and k the arity of R. Attributes of type time are the temporal attributes, the remaining attributes are the data attributes. A database schema is a finite set of relational symbols R1, . . . , Rk paired with their signatures. A n abstract temporal database is a set of tables defined by a database schema.

In general we do not restrict the cardinality of abstract temporal tables: we allow infinite tables in general. However, in order to define meaningful operations on the tables, we require that the number of occurrences (duplicates) is finite for every distinct tuple. E x a m p l e 3 In the rest of the chapter we use an abstract temporal database with the schema {indep(Name, Year)} as a running example. The particular instance of the indep relation we use in our examples captures independence of countries in Central Europe:

indep Czech Kingdom 1198

Name Poland . . .

Poland Poland Poland Poland

Czech Republic 1995

,. 9

1794 1918

Czech Kingdom 1620 Czechoslovakia 1918 Czechoslovakia 1938 Czechoslovakia 1945 Czechoslovakia 1992

~lovakia

1940

...

.~

Slovakia Slovakia

1944 1993

.,.

. . . ..

.~

We do not impose any restrictions on the number of temporal attributes in relations (unlike, e.g., TSQL2 18). Indeed, in general we may want to record relationships between different time instants as well. While we may want to restrict the users from creating such multi-dimensional tables, we need this feature in the later sections to translate SQL/TP queries to SQL/92. The abstract temporal databases provide a natural data model for representation and querying temporal data. However, it would be impractical (and often impossible) to store the temporal databases as plain bags of their tuples: a particular tuple is often related to a large and possibly infinite set of time instants. Rather than storing all these tuples one by one, we use a compact encoding of sets of time instants. The choice of a particular encoding--in our case the interval-based encoding~efines the class of concrete temporal databases:


217

D e f i n i t i o n 4 ( C o n c r e t e T e m p o r a l D a t a b a s e ) Let R be a relational symbol with signature E. A concrete signature corresponding to E is defined as a tuple of the attributes that contains (1) a for every data attribute a E E and (P) train and tmax for every temporal attribute t E E. The attributes train and tmax denote endpoints of intervals. We denote the concrete signature of R by E. A concrete temporal database schema corresponding to a given abstract database schema is a set of relation symbols and their concrete signatures derived from the signatures in the abstract database schema6. A concrete temporal database is a set of finite relations defined by a concrete database schema. To capture the relationship between an abstract and a concrete temporal database we define a semantic mapping that maps a concrete temporal database to its meaning--an abstract temporal database. The meaning of a single concrete tuple x = (tmin, tmax, a l , . . . ,ak) is a set of tuples IxI = {(t, a l , . . . ,ak) : train < t < tmax}; analogously for tuples with multiple temporal attributes. The meaning IIRII of a concrete relation R is the duplicate preserving union of Ilxll for all concrete x E R. We say that R encodes IIRII. We extend the I1.11to concrete temporal databases in the standard fashion. The encodes function also defines a subset of the abstract temporal databases that can be encoded using concrete temporal databases. We call this subset the finitary temporal databases. Note that the encoding is not unique and thus two or more distinct concrete temporal databases can encode the same abstract temporal database (cf. Example 1). We call such pairs of concrete temporal databases (ll.ll-)equivalent. E x a m p l e 5 The database instance from Example 3 is infinite. However, it is finitary and can be encoded using the following concrete temporal database: indep Name Yearmin...Yearmax Czech Kingdom 1198 ... 1620 Czechoslovakia 1918 ... 1938 Czechoslovakia 1945 ... 1992 Czech Republic 1993 ... cc

Slovakia Slovakia

1940.. 1 I 1993.." 944

Poland Poland Poland

1025.. 1794 1918.. 1 1945.. 9oo38

I

All queries in the rest of the chapter are evaluated over this database while preserving answers with respect to the original relation in Example 3.

3

The Language S Q L / T P

In this section we define the syntax and semantics of SQL/TP. This includes the data definition, data query, and data manipulation parts of the language. In all three cases we show that S Q L / T P is a natural syntactic extension of SQL over 6 We use the same names for both the abstract and concrete relations. The actual meaning of the symbol is always clear from the context.

218

David Toman

the abstract temporal databases. Moreover, the proposed semantics of SQL/TP is essentially identical to the semantics of SQL (safely) extended to abstract temporal relations. 3.1

Data

Definition

Language

We start with the Data Definition Language: it is essentially identical to standard SQL/92: create table ( <signat> ) create view ( ) where is a table identifier and <signat> is a signature of the new table. For views the signature is derived from the signature of the expression (cf. Section 3.2). The only difference is that the temporal attributes are declared using a new data type time that supports modifiers that determine how the sets of time instants are stored in a concrete temporal table: using points: The time instants are stored as atomic values similarly to all other data types. This choice is suitable for representing single atomic events that happen at a specific time, e.g., when a particular tuple was inserted in the database. using bounded I unbounded intervals: Continuous sets of time instants associated with a particular data tuple are encoded using intervals. This encoding is suitable for representing durations of time. The bounded and unbounded keywords specify if the -oo and oo m a y be used as endpoints of intervals. This choice affects, what aggregate operations are allowed for that particular attribute; cf. Section 3.2.

It is important to understand that these modifiers affect only the way the table is stored, not the semantics of the queries (similarly to specifying, e.g., a sort order or a key for the table). In the future this list may grow to accommodate different was of encoding sets of time instants. The modifiers are the only place in SQL/TP where the syntax reflects the chosen encoding. The default modifier unbounded time is assumed for all temporal attributes unless explicitly stated otherwise. The following table defines how the modifiers interact with standard relational operators ("p" is a shorthand for p o i n t s , "b" for bounded i n t e r v a l s , and "u" for unbounded i n t e r v a l s ) : oppopppopbpopuboppbopbbopuuoppuopbuopul A p p p p b b p b

u

-

p

p

p

b

b

b

u

u

u

U

p

b

u

b

b

u

u

u

u

The interaction of temporal attributes in joins and selections is captured by their behavior in the N (intersection) operation, projection does not affect the remainders of the tuples.


219

E x a m p l e 6 The table indep in Example 3 is created as follows: create table indep (name char(20),

year time using unbounded intervals) In the rest of the chapter we discuss only the interval-based encoding; encoding time instants using points does not introduce any problems over the traditional data types. In addition we assume the time instants can be represented by integers (using a fixed granularity) and we allow integer-like operations on the new data type to reduce the amount of superfluous syntax. 3.2

The Query Language

For sake of simplicity we discuss only a syntactic subset of full SQL/TP. This choice does not affect the generality of our proposal: it is an easy exercise to show that the proposed fragment forms a (first-order) complete query language 8. Moreover, all representation independent SQL/Temporal queries, including queries with aggregation and universal subqueries, can be equivalently formulated in this fragment. S y n t a x . The syntactic subset of SQL/TP uses two basic syntactic constructs: Select block. Similarly to the standard SQL the select block is the main building block of the query language. It has the usual form select <slist> from

where

group by

where < s l i s t > is a list of attribute identifiers, constants, and (aggregate) expressions with the possibility of renaming the output column using <sexp> as . Columns defined by expressions or aggregation have to be given a name in this way, < f l i s t > is a sequence of relation identifiers or subqueries, again with the usual possibility of assigning correlation names, is a selection condition built from atomic conditions using boolean connectives. The atomic conditions depend on the data types of the involved attributes: in the case of temporal attributes we allow conditions of the form op + C where op E {, >}, and C a constant denoting a length of a time period, and < g l i s t > is a list of attribute identifiers that specifies how the result of the select block is grouped. The usual SQL rules that govern the grouping operations apply here as well. We extend the definition of signature to SQL/TP expressions: The signature of an expression is tuple of attribute names in the result paired with the corresponding data types (including modifiers for the temporal types).

220

David Toman

Set Operations. Besides nesting queries in the from clause of the select block we can combine the individual select blocks using set operations as follows: ( <exp> ) <setop> ( <exp> ) where <setop> is one of the union (set union with duplicate elimination), union a l l (additive union), except (set difference with duplicate elimination), except a l l (monus), i n t e r s e c t (set intersection with duplicate elimination), and i n t e r s e c t a l l (duplicate preserving intersection). We require the signatures of both the expressions to match 7. The resulting signature is the common signature of the expressions involved in the operation. The proposed syntax omits two common SQL constructs: subqueries nested in the where clause and the having clause. Both these constructs can be expressed in the presented fragment using nesting in the from clause of the select block and therefore can be considered to be only syntactic sugar. To achieve signature compatibility for temporal attributes we allow the use of a special constant pseudo-relation t r u e ( t : time) true for all elements of the temporal domain. This relation allows us to pad the attribute lists involved in the set operations (cf. Section 3.3) and to formulate queries that involve, e.g., the complementation over the temporal domain. Semantics. SQL/TP is essentially SQL/92 extended with an additional data type time. The main feature of this proposal is that we can use the standard SQL-like semantics over the class of the abstract temporal databases. This way we completely avoid all problems connected with representation dependencies while maintaining compatibility with SQL. Moreover, changes in the encoding (the physical representation) do not affect the syntax and semantics of queries. However, we have to be careful when extending relational operations to infinite tables: we have to ensure that we never produce tables with infinite duplicates of a single tuple. It is easy to see that all the relational operations, with the exception of duplicate preserving projection, meet this requirement. However, the duplicate-preserving projection can produce such tables, e.g.: {("Poland", 1945, oc)}

I,.l, {("Poland",n) : n > 1945} ~1 {("Poland"),..., ("Poland"),...}

The result of the projection contains infinite duplication of the tuple ("Poland"). This cannot be allowed as other relational operators, e.g., the bag difference, are not well defined over such tables. Therefore we restrict the use of duplicatepreserving projection to attributes of bounded types, i.e., bounded intervals, time points, and data types. 7 SQL only requires the types to match. However, we require both the names of the attributes and their types to match. This is not a restriction as the renaming can be conveniently done within the select clauses.


221

C l o s u r e o v e r I n t e r v a l - b a s e d C o n c r e t e Databases. While the above restriction guarantees a well defined semantics, it is too weak to guarantee closure of SQL/TP queries over the chosen class of concrete temporal databases. The main source of problems are the order dependencies among temporal attributes. Consider the following example: E x a m p l e 7 It is easy to find SQL/TP expressions that do not preserve closure over the class of finitary abstract temporal databases, consider the expression: Q: select

from where

rl.name as name, rl.year as tl, r2.year as t2

indep rl, indep r2 rl.name = r2.name and rl.year < r2.year

The attributes t l and t2 are correlated by an inequality t l < t2 in the result of the query: {("Poland", 1945, 1946), ("Poland", 1945, 1947),.. ,("Poland", 1945, 1950),... ("Poland", 1946, 1947),.. ,("Poland", 1946, 1950),... ("Poland", 1949, 1950),...} Obviously the triangle-like result can not be described by a product of intervals. To avoid this problem we use the notion of attribute independence. Rather than a semantic definition of attribute independence 11 we use a syntactic inference system to guarantee attribute independence in a SQL/TP expression: D e f i n i t i o n 8 ( A t t r i b u t e I n d e p e n d e n c e ) Let tl and t2 be two temporal attributes in the signature of a S Q L / T P expression exp. We say that tl and t2 are independent in exp if 1. exp is a base relation, 2. exp is a select block, tl and t2 are names of t~ and t~2 assigned in the select clause, t~ and t~2 are independent in all expressions in the from list, and an order relationship between t~ and t~2 is not implied by the where clause. 3. exp is ( e l ) setop (e2) and tl and t2 are independent in both el and e2.

In addition all the data attributes (and point temporal attributes) are mutually independent. The inference system is sufficient to infer independence of attributes. We could also analyze the compositions of the selection conditions on temporal attributes and check for tautologies. We have chosen not to pursue this direction in the current version of the proposal for sake of simplicity. However, the theory of linear order is decidable and thus such an extension is feasible; note that these tests are performed at compile time and thus do not affect the data complexity of the queries. For similar reasons we restrict the use of aggregate operations: we require the aggregated attribute to be independent of the group by attributes 10. Moreover, the aggregation has to obey the restrictions in Figure 1.

222

David Toman

We also restrict the use of duplicate-preserving projection on all temporal attributes encoded by intervals. We have already seen that duplicate-preserving projection is not possible for unbounded data types. On the other hand, for bounded data types we could implement the duplicate preserving projection by creating the appropriate number of copies of the remainder of a tuple. However, such an operation would make the query evaluation very inefficient and almost certainly unusable in practice. Consider the following example: E x a m p l e 9 Let R(x, t) -- {(a, 0, 2n-l)} be a concrete temporal relation where n is a large integer. Clearly the size of R (in bits) is lal § n. However, the size of ~'x(R) is 2n 9 lal as the result of duplicate preserving projection has to contain 2n tuples (a). Allowing such projections would cause an exponential blowup in the (space) complexity of query evaluation. Note that the duplicate preserving projection is used in SQL for two main reasons: (1) to avoid duplicate elimination or (2) to facilitate correct aggregates. The first use does not apply to S Q L / T P - - w e deal with redundant duplicate elimination in the optimization phase of our compilation procedure. The aggregates are handled using a rewriting technique that allows us to avoid the duplicate-preserving projections. We can evaluate a vast majority of representation-independent aggregate queries even under the above restriction: note that all other relational operations preserve duplicates (cf. Section 3.3). Therefore we exclude the duplicate-preserving projections of all temporal attributes encoded by intervals in order to maintain the polynomial complexity bound. We define the SQL/TP queries to be the subset of SQL/TP expressions obeying the following rules: Definition 10 Let Q be a S Q L / T P expression that obeys the following rules: 1. temporal attributes encoded by intervals cannot projected out in a s e l e c t a l l clause. 2. all attributes in the (top-level) signature of the expression are pairwise independent. 3. the attributes in the group by clause are independent of the remaining attributes, and 4. the attributes used in aggregation operators follow the rules in Figure 1 Then we say that Q is a SQL/TP query over the class of concrete interval-based temporal databases. It is easy to verify that all SQL/TP queries preserve closure over the class of finitary temporal databases: T h e o r e m 11 Let D be a finitary database and Q a S Q L / T P query. Then Q(D) is finitary. The requirement of attribute independence seems like a rather severe restriction. However, the independence is required only for the temporal attributes present in

Point-Based Temporal Extensions of SQL Type of the group by attr's data bounded int unbounded int

223

Type of the aggregated attribute data min,max, sum, count rain,max, sum, count min, max

bounded i n t e r v a l s min,max, count rain,max, count min, max

unbounded i n t e r v a l s rain,max min,max min, max

When the group by clause contains multiple attributes we take the intersection of the allowed aggregate operations. We have excluded the sum aggregate on the temporal attributes: while it is definable in our framework, it makes little sense from the semantics point of view. Fig. 1. Allowed aggregates.

the signature of the top-level query, not for all temporal attributes that appear in the query. Therefore all the representation-independent TSQL2 queries, and all first order queries with a single temporal attribute in their signature in general, can be expressed as S Q L / T P queries. T h e o r e m 12 The first-order fragment of SQL//TP is expressively equivalent to

range restricted two-sorted first order logic (temporal relational calculus). We can also express queries shown not to be expressible in T R A 7, e.g., the query "is there a pair of distinct time instants, when exactly the same countries were independent?" 1, 21. This is not possible in any temporal query language that assumes a fixed number of temporal dimensions in its data model. 3.3

Examples of Queries

In this section we provide illustrative examples of S Q L / T P queries. The examples are chosen to highlight the ease of formulating queries in S Q L / T P . In addition some of the examples, e.g., example 3, can not be easily (and correctly) be formulated in TSQL2 derivatives. 1. The first example is a simple PSJ query "List all countries that were independent while Czech Kingdom was independent". select

from where

rl .name indep rl, indep r2 r2.name = 'Czech Kingdom'

and rl.year = r2.year

Note also that the result is a standard non-temporal relation. Over the database from Example 3 we get: name

Czech Kingdom

Poland 2. Formulating more complicated queries in S Q L / T P , e.g., the query "List all years when no country was independent", is also very natural:

224

David Toman (select t as year from true) except (select year from indep)

Note the use ofthetrue pseudo-relationto achievesignature compatibilit~ The result ofthequery is yearmin

yearmax

-infinity 1795 1939

1024 1917 1939

While the o u t p u t - - a concrete table containing all the periods when no country was independent--has two columns, it is essential to understand that it is only a compact representation of an abstract table with a single column Year. 3. In addition to first-order queries, the aggregate operations in S Q L / T p also naturally interact with the rest of the language, e.g., in the query "List all countries that became independent before Slovakia": select from where

name indep, ( select min(year) as yO from indep where name = 'Slovakia' ) year < yO

The result is: name

Czech Kingdom Czechoslovakia Poland 4. S Q L / T P also supports a natural way of aggregating over the temporal attributes: "For every country (that has been independent during the 20th century) list the number of years of independence within the 20th century": select from where group by

name, c o u n t ( y e a r ) as y e a r s indep 1900 where s, C and (t, a) respectively represent the surrogate or event identifier, the Calendar associated with the event, and the instantiation of the event history vector. The event history vector is a time series that is updated by every occurrences of an event. The model specifies atomicity (all or nothing) property for event occurrences. It is also reasonable to assume that no two events occur at the same time. Hence, we do not allow simultaneous events as proposed in MZ95. An alternate definition is given in Ter94 who considers an event as an interval of time. However, this definition is not proper for the following reasons (1)an interval oriented event can be always defined as a composite event using the beginAnterval and end_interval basic events. (2)the storage of interval based

An Architecture and Construction of a Business Event Manager

261

event histories may be infeasible as large (potentially infinite) number of the begin_interval points may have to be recorded. (3)unless efficient algorithms are developed, at every end_interval point, all the unmatched beginAntervals would have to be inspected.

Basic or Primitive Events. Basic or primitive events are a set of pre-defined events recognized by the event manager. These events cannot be infered from any other event in the system. Previous literature CKAK94 had simply assumed an availability of a mechanism for the detection of basic events. However, in this paper, we propose an algorithm for the definition and detection of all events.

Composite Events. A composite event is formed by a logical or temporal operation on a set of events. This set may include all previously defined composite events but not the event that is currently being defined. The framework does not support a recursive definition of composite events as the precise syntax of such an operation cannot be evaluated. Moreover, we have not encountered a business modeling scenario that requires recursive composite events.

Event Attributes. Each primitive event may have an optional number of attributes. Conceptually, there are no restrictions on the data type of an attribute. It can be a built-in data type or even a complex object. The attributes of a composite event are the union of the attributes of each component event. Note that, the selection of event parameters leads to different definitions of an event. Consider an event Machine_Breakdown with parameter machine id, and two occurrences of the event - (07 : 45, Furnace1), (08 : 10, Furnace2). An alternative system design is to define two separate events, one for each Furnace, i.e., Machine_Breakdown_Furnace1 and Machine_Breakdown_Furnace2. Rule System Rules in this framework are assumed to be of the form: On event do action. It is the responsibility of the event manager to notify the rule system about occurrences of interesting events in the system. Further issues in rule systems, such as an execution model or priority scheme, are orthogonal to the current research problem.

2.2

Event vector and Algebra

An event vector (EV) is a sequence of events. Formally, an EV is represented as a a E V < (A, T) > where A are the values of event attributes and T is a temporal vector. An event may have multiple attributes and it is assumed that each attribute is recorded (but may not have changed from the previous instantiation) at each event point. Thus, null as an event attribute is not allowed.

262

Ajit K. Patankar and Arie Segev

Event

Vector

Algebra

We introduce an event vector algebra t h a t facilitates the derivation of composite events. The Notation An array notation is used to identify the ith element of an event vector. For example, E V < (A, T) > i will provide the ita snapshot of the event vector. This snap shot will be a n-ary vector .4 of the event attributes. T h e first index of the event vector is 0. Event Attributes An E V m a y have n parameters and each one is accessed by a subscript notation - Ao,A1,A2,..An. It is possible t h a t a particular E V m a y have no attributes, i.e., the modeler m a y be interested in only storing the time points at which the event occurs. This E V is denoted by < (T) >. Aggregate Functions T h e event manager supports built-in aggregate functions as these are essentim for deriving new events from basic event vectors. Formally, an aggregate function (F) defined on the k th attribute of the E V is as follows: Let there be i -- 0, 1, 2, .. I events in an EV,

F(V i s.t. i i) Multiple aggregate functions can be defined over the same attribute. It is possible to generalize the above definition in at least two directions: a function can be defined over multiple attributes of an E V (e.g., < Akl,Ak2, ...,T > in the above definition), and not all time series elements need to be the function p a r a m e t e r s (e.g., i can be restricted to I, I - 1, I - 2 only). We have not experienced a need for the first type of extension. But the second extension simply leads to the truncation of event history so as to save memory. 2.3

Event

Classification

Basic Events are classified in the following categories: - D a t a b a s e Events. A database event occurs when there is a database operation such as select, insert, or delete. It is also possible to generalize the definition to include operations on metadata. In this research, we are not particularly concerned a b o u t the question of what constitutes a database event. It will be assumed t h a t the DBMS is responsible for reporting the occurrence of a database event to the event manager. - External Events. External events occur outside the realm of the DBMS. These m a y include events such as machine break-down in a manufacturing application or a stock price j u m p in a financial application. Notification of an external event can occur through only two means - polling or asynchronous notification. In the polling mechanism, the event manager polls (or


263

invokes) an external application to determine if an event has occurred. In the asynchronous notification scheme, the external application is responsible for notifying the event manager. - Temporal Events. A temporal event occurs at a specified point in time. For example, 8/29/30 4 : 30pm or every 2 hours are time events. The event manager is responsible self-notifying time events. This mechanism is described in a later section. - Calendar Events. Although, calendar events are a subset of temporal events, these are classified separately because of their usefulness in implementing application systems. A calendar event occurs at a specific point on the calendar. For example, Last Working Day in June or Every Wednesday are calendar events. The event manager also implements the notification scheme for Calendar events.

Schedulability P r o p e r t y All temporal and external pollable events are schedulable in the sense that their time of occurrence can be predicted a priori. This property is called schedulability and is used extensively in the implementation of the event manager. But note that, it is not necessary that an external event will be detected in each polling cycle.

3

EVENT MANAGER ARCHITECTURE

The event manager is an executable program that accepts event registration and detection commands from application programs. This program includes a parser for translating event specification language, the event queue for detecting schedulable events, and a composite event detection algorithm. Whenever an event is detected, either through the event queue implementation or by a detect command, the following actions are undertaken: (1)an entry in the event history table is inserted, (2)the rule manager is informed, and (3)the composite event detection algorithm is informed, if required, 4)a new schedulable event is inserted in the event queue, if necessary. In the rest of the section, these functions are described in details. The event manager architecture is shown in Figure 1. Its components are described next.

3.1

Event manager components

Event Registration and Detection Language The event specification language is described in section 4. This language is the interface through which users register, cancel and detect events.

264

Ajit K. Patanlmr and Arie Segev Composit~"-'---.,~

Even~/

IExternalIA< Poll vents synch Notification

~r

Clock

EVENT MANAGER

Evt/fnitcation

G Calendar iiiii IIIIIIII IIIIIIII IIIIIIII

iii

Temporal Events

( RAl:agerI Fig. 1. The Event Manager Architecture.

Event Metadata

and History Storage

T h e event m e t a d a t a is generated from the commands used in the event language. T h e m e t a d a t a is modeled by the database schema while the history is modeled as a time series. The event history and m e t a d a t a is stored in an objectrelational database that supports time series as a native d a t a type. The event history refers to the sequence of events t h a t have occured. It is i m p o r t a n t to store the event history because it is required for detecting composite events. Schedulable Event Implementation

Module

T h e event manager is responsible for detecting all schedulable events. A future event queue is maintained for detecting these events. The queue is itself stored as a time series which can be queried by users. We introduce a notion of Event Renewal for all schedulable events. Whenever a schedulable event is defined, the first occurrence of this event is inserted in the event queue. At the time of its detection, this event renews itself in the sense t h a t the next occurrence is again inserted in the event queue. This process continues until either an user cancels an event or the continuation function returns false.


265

External Process Communicators The event manager communicates with external processes to detect external events as well as to implement event queue. It is assumed that this communication is through standard operating system services, and is not discussed further in this paper. Composite Event Detection Algorithm The composite event detection module is distinct from the primitive event detection system. This scheme has two advantages: modularity in the implementation and the possibility of introducing additional composite event operators without having to modify the detection of primitive events. The Sentinel active OODB system CKAK94 also proposes a distinct composite event module.

4

E V E N T SPECIFICATION LANGUAGE

The event specification language is used to register and detect all events. Note that, unlike active databases, database events are also explicitly registered and detected using the language. Since the event manager is constructed using the database services, this may appear as an unnecessary overhead. However, a strict separation between the event originating and managing systems is essential for avoiding many problems in current active database systems such as a lack of robustness and inconsistent operations. The event specification language closely follows the SQL syntax and constructs. In particular, this language is intended as a superset of the rule specification language of the emerging SQL-3 standard. 4.1

Notation and Keywords

The language uses the create and delete statements from the SQL language, and introduces an additional detect statement. The create statement is used to register an event using a set of keywords described later in the section. The delete statement only cancels the detection of an event, however, the event history is not purged. The detect statement is used by either an external application or the database to notify the occurrences of an event. Note that this statement is not required for schedulable events as the event manager itself assumes the responsibility for their detection. A formal grammar is given in appendix A. This is followed by several examples. The most important keyword is E V E N T which is similar to keywords R U L E or F U N C T I O N in SQL-3 language. This keyword, along with the standard SQL commands such as create or delete, is used to register or cancel an event. Other keywords are described below: - C A L E N D A R . Specifies the calendar that is associated with a particular event. As our event framework (section 2) requires that a calendar be associated with each event, this is a mandatory keyword in a create statement.

266 -

-

-

-

-

-

-

-

Ajit K. Patankar and Arie Segev T E M P O R A L . Specifies a temporal event. D A T A B A S E . Specifies a database event. E X T E R N . Specifies an external event. C O M P O S I T E . This is used to specify a composite event formed from the algebraic operations on other events. F U T U R E . This is used to specify a relative event based on the future event queue. The operator is further explained in section 6. D E T E C T . This is used to inform the occurrence of an event to an event manager. This keyword will be followed by the event identifier and the parameter values. R E P E A T . The parameter after this keyword is a boolean function that is executed after each occurrence of the event. The function output determines whether the event manager should watch out for the next occurrence of the event. H I S T O R Y and N U M B E R . These keywords specify the length of time for which the event history should be maintained. The keyword N U M B E R specifies this length as the number of occurrences of an event rather than a time period. P A R A M . This keyword is followed by a list of event attributes and their data types. While the event framework places no restrictions on the data types of attributes, the current implementation allows only the native database data types. P O L L . This keyword is applicable only for external events, and is used to specify an optional polling frequency. It is also followed by the name of a function which is executed to determine if the event has occurred. E V E R Y . This keyword is applicable only for temporal events and is used specify the interval between two events.

C a l e n d a r

S p e c i f i c a t i o n

The specification of a calendar in this frame work is based on SC93. A similar specification was implemented in Illnstra time series datablade II195, hence it was directly used in the implementation. A calendar is composed of a calendar pattern and a set of calendar exceptions. A pattern specifies an interval duration and the pattern of valid (on) and invalid (off) intervals. A duration is a natural time interval, e.g., day, hour, week, etc. A working week pattern will be specified as: "{5 on, 2 off},day" A complete calendar requires the specification of the following parameters: a starting timestamp, an optional ending timestamp, a pattern, a pattern-starting timestamp, and an optional set of exceptions. An exception represents either deletions or additions to the pattern defining a calendar. The exceptions may be used to specify holidays or special working days.

An Architecture and Construction of a Business Event Manager 4.2

267

Examples

Temporal Events Consider a lot release policy that releases a new lot to the shop floor every two hours starting from the beginning of a work week. The maximum number of events stored in an event history are 200. This event can be cancelled only manually by an user. It is assumed that a function Return True is defined which always returns true. Also, there is a WeekHour calendar that models the hours in a work week. This event will be specified using the following query: create EVENT LotRel CALENDAR WeekHour REPEAT ReturnTrue NUMBER 200 EVERY 2 PARAM ( LotId char (10), ProdCode char (12) );

Database Event A database event AccConfrab is used to signal attempts to access a confidential data table. The history of this event is maintained for two years. This event would be registered using the following query: create EVENT AccConfTab DATABASE REPEAT ReturnTrue HISTORY 2 year PARAM ( UserNsmle char(12), TabName char (24) ); Once this event is detected, the database would inform the event manager by assertingthe following statement: detect AccConfTab ( 'Joe', 'Payroll' ) ; It is not necessary to include a time stamp in the above statement as it is implicitly understood to be the current time.

External Event A machine in a factory is directly interfaced to an event manager. A factory management application requires that the event manager monitor machine break-down and repair completion operations. The transition of an operational machine into the failed state is indicated by the MachFailure event. The transition from a failed state into the operational state is indicated by the MachRepairCompl event. It is assumed that a machine has only these two states.

268

Ajit K. Patankar and Arie Segev The definition of MachRepairCompl would be as follows:

create EVENT MachRepairCompl EXTEKN REPEAT ReturnFalse HISTOKY i year POLL 5 min PAKAM

(

MachName char(12), RepairPerson c h a r ( 2 4 ) , );

The event manager uses polling method to detect the MachRepairCompl event. The " R E P E A T ReturnFalse" part of the definition suggests that the event is detected only once. This is possible because a rule statment can include the definition of an event. Consider a rule that is invoked whenever the MachFailure event is detected: on MachFailure do

alert repairman; update_machine_usage_statistics; create EVENT MaclhKepairComplEXTERN -- other statements of the create event

Thus, the detection of event MachRepairCompl is started only when the event MachFailure is detected. This example shows that the event manager has the flexibility to intrinsically model and implement state transitions. The performance is expected to improve because only the events that are appropriate for a state are detected. 5

T H E IMPLEMENTATION

The implementation requires the development of three modules: Event queue, Event Storage manager, and Database interface. These modules are briefly described in the following sections, the details are given in PS95. 5.1

The Event Queue

It is the responsibility of the event manager to detect and notify the rule system if a schedulable event occurs. All these schedulable events are stored in a future event queue. One of the important features of our event manager is that users can access the event queue and use it in the definition of further events. This requirement forces the storage of the event queue as a database object so that it can be queried using standard query facilities.

An Example Consider the following set of schedulable events: 1)An external event (pl) with polling frequency of 5 min, 2)An absolute temporal event (al) at M o n 08 :


269

30, 3)A calendar event (cl) defined as End of the business day or at Mon 16 : 00 after conversion. Let current time (tnow) be Mon 08 : 00. These three events are scheduled to occur at 5, 30, and 400 time units from tnow. An event queue for this simple system is shown in Figure 2.

Events

tnow

pl

al

cl

5

30

400

Time line (Notto scale)

Fig. 2. The Event Queue

This implementation has three modules - Insert, Delete, and Detect. The first two modules, as the name suggests, are used to insert or delete a schedulable event from the event queue. The Detect algorithm uses a process called DBCRON which is modeled after the Unix process, CRON. The D B C R O N process performs the following functions:

Table 1. Event Queue Implementation Notation

Variable or Function now

~t next_event time_stamp_nth next_wake_up_time

Description Current Time The time interval accuracy used in detecting an event. A boolean function that determines if the current event has to be renewed. The t i m e u n t i l t h e n t h future event (from now on) ot a particular type. The time at which the event manager should be awakened.

At a scheduled time, it wakes up and detects events that were supposed to occur at that time. These events are notified to the rule manager. - It inserts an appropriate number and type of events on the future event queue. - It decides when to wake itself up for the next cycle. -

270


- It executes a special algorithm to maintain system integrity in case of changes in the time zone, such as daylight savings. Using the notation described in table 1, the event queue algorithm is described below. while(i){ / * forever * / now = current_clock_time() ; current_set_of_events = query_event_queue(now) ; while (not_empty(current_set_of_events)) { current_event = first_event (current_set_of_event) ; if (external_pollable(current_event)){ if (poll_extern(current_event.type) { inform rule_manager(current_event) ; store_event (current_event, now) ; insert_future_events (current_event, now) ; } /* external event occurred */ else { insert_future_events (current_event. type, poll_freq(current_event, type) ) ; } /* external event did not occur */ } /* This is an execution of polling mechanism. */ else { inform_rule_manager (current_event) ; store_event (current_event, now) ; insert_future_events(current_event, now) ; } /* event is temporal */ delete_event (current_set_of_events, current_event) ; } /* while event set is not empty */ next_wake_up_time = select_first_event_time(event_queue) ; if (next_wake_up_time = INFINITY) raise_error() ; sleep (next_wake_up_time) ; } / * do forever * /

Important function used in the above algorithm are explained next: -

-

insert_future_events. This function implements the event renewal process described in Section 3. This function requires the current time ( n o w ) a s an argument to ensure that no event is inserted in the now - now + 6t interval. Otherwise, the new event may not be detected in the next cycle. This leads to the discretization of the time line in the intervals of 6t for the sake of implementation. The value of 6t needs can be determined from performance studies, although, theoretically it is possible to have a value of z e r o . query_event_queue. This function selects all the events from the event queue which are scheduled in the range now - 6t and n o w + 6t. external_pollable. This function polls an external application and determines if the external event has occurred.

An Architecture and Construction of a Business Event Manager -

-

-

271

Once an event is detected, it has to be inserted in the event history. The function s t o r e _ e v e n t stores the event in an appropriate system table. select_first_event_time. This function selects the time of first event on the queue. first_event and d e l e t e _ e v e n t . These operators select and delete an event from the current event set. These are required as more than one event may be scheduled for wake up in a given time range. store_event.

An alternate algorithm for implementing temporal rules is given in CSS94. The differences between the two algorithms are as follows: The algorithm in CSS94 assumed that all the occurrences of a temporal events are known a priori as it did not consider quantifier operators on events (i.e., ONCE, EVERY, etc.). This is conceptually wrong because the algorithm requires infinite memory even if one event is specified with EVERY operator. Our algorithm also supports the concepts of pollable events and temporal event algebras. Furthermore, their work had assumed an integrated rule system which was also responsible for detecting events. Modification to the System Clock Small changes in the system clock, such as for synchronization with other external clocks, can be neglected in the algorithm. The above algorithm fails if the system clock is modified substantially, for instance, to accommodate summer daylight saving adjustment. This change causes either an extra hour or loss of an hour on the event queue. The semantics of such a change are unclear and need to be investigated. For example, all external pollable events can be either postponed or preponed by one hour without any loss of information. Absolute temporal events, like 7 : 30 a m 9/15/95, which do not lie in the one hour zone would also remain unaffected. However, more work is needed to determine the effect on temporal events which lie very close to the change time. 5.2

Event Metadata and History Storage

This research assumes that an object-relational database, such as described in Kim95, is available. Briefly, such a database supports the following features: columns of complex data types, inheritance, and a production rule system integrated with a database. E v e n t M e t a d a t a The event metadata storage is consistent with the m e t a d a t a storage approach followed in most relational databases, namely, metadata is stored as system tables. For example, in Illustra, even database rules, functions, and alerters are stored in system tables. The m e t a d a t a schema is shown in Figure 3. This schema is briefly described next, the implementation is described in PS95. The relations are depicted as boxes with the attributes listed inside. The primary keys are in b o l d whereas

272


the foreign keys have been underlined. T h e directed arcs indicate inheritance from a root table while undirected arcs show foreign key migration. T h e event classification, discussed in Section 2, is a natural hierarchy of object classes. Thus, it is directly implemented as an inheritance of tables. T h e root table E V E N T stores the attribute common to all events such as the surrogate, calendar, etc. T h e root table also manages the m e t a d a t a of events t h a t are detected only once or until manually cancelled by an user. Those events whose future detection is determined using a special function are sub-classed into a DYN_REP table. This table uses a virtual column which points to the function which needs to be executed after each occurrence of the event. T h e three basic event categories - External, Database, and Temporal all inherit from the DYN_REP table. A further sub-class of External events is the pollable events which are implemented using the P O L L table. M e t a d a t a of composite and scheduled events is managed in separate tables. T h e column E X P R E S N in table Composite stores the definition of a composite event using pre-defined operators such as SEQ, N O T , etc. The composite event detection algorithm parses these expressions as needed. T h e scheduled events table has two components - algorithm p a r a m e t e r s and the event queue. Algorithm parameters, such as tnow and St, are stored as regular columns of a table. However, the event queue is implemented using the time series d a t a type provided by an object-relational database. T h e internal representation of a large time series is a B-Tree for fast access.

Event History Recall from section 2 t h a t our event model is described by a tuple C = < s, C, (t, a) >. An event history is the (t, a) vector of the above tuple. An event history can be directly modeled as a irregular time series 1, and in fact has been implemented using Illustra irregular time series d a t a type. This d a t a type captures the precise semantics of an event history, and yet offers the benefits of using a temporal database. The storage requirements are minimized as well as support for temporal queries is possible. Although, conceptually the event attribute can be of any d a t a type, the limitations of the Illustra storage manager preclude the use of all but numeric d a t a types. Even with this limitation, the overall advantages of a temporal database make it much preferable to a relational database.

5.3

D a t a b a s e Interface

T h e database interface has two components - Event M e t a d a t a m a n a g e m e n t and Event Detection. These components are described next: 1 A regular time series has a data point associated with each point on the Calendar, an irregular time series does not have any such restriction.


ComposlteEV I EID I Exprn

I'~176 delta_t

I

Event

HISTORYTABLES

EI~"~ Calendar History Number

/

~

EID I Event History

"~

Dy epeat

I

273

I

IE ' ~ _

I

'

Event History

§

'=

I Fig. 3. Event Storage Schema.

Event Metadata

Interface

Users assert a "create event" c o m m a n d to define a new system event. T h e parser modifies such a statement into a SQL-3 statement so t h a t m e t a d a t a is inserted into an appropriate system table. The parser operation is illustrated with the following example: Consider the event LotRel described in section 4.2. Briefly, this create statement will be converted to a SQL-3 statement of the following form: insert into Temporal values( 'LotRel', 'WeekHour', 200, 1, 2); -- The WeekHour calendar is predefined and not described here.

T h e subscription to an event is cancelled whenever an user asserts a "delete event" command. T h e proposed model does not support modification to the event m e t a d a t a as its semantics are not precise. Event Detection Interface This interface makes an extensive use of the active database features. The parser converts any "detect event" statement into the following form: "update table Event_History( ..... )". For schedulable events, the event manager itself asserts the table update command.

274


This update statement triggers a rule defined over the event history table. The following actions need to be undertaken once an event is detected: execute application specific action and determine repeatability of the event. These actions are performed using database functions (in C language) whose internal implementation is secondary to the exposition in this paper.

6

SUPPORTING TEMPORAL REASONING AND CONSTRAINTS

Problems in real world applications such as those emerging from financial, manufacturing, and scheduling world, require extensive support for temporal events. The current work in temporal databases does not allow the possibility of specifying a temporal event in terms of its relative position with respect to other temporal events. For example, consider a process control rule - "during a furnace operation measure the pressure." Here the event "measurement of pressure" is constrained to occur relative to two events - the start and end of an operation. A very important advantage of our approach is the support for the implementation of temporal reasoning and constraints. First, we describe basic notions in temporal reasoning and then introduce temporal operators.

6.1

Temporal Reasoning Concepts

The completeness of any event manager has to be judged on the basis of its ability to support these constructs, and hence they are described next: 2

Event time constraint The event time may be constrainted by a lower and upper bound. The time constraint should be expressible using a natural language calendar. Interval Time (I-Time) I-Time is the periodic time interval over which a temporal event can take place. It is usually represented by granularity of a calendar, e.g., business day. Quantifier A temporal quantifier indicates the frequency of an event with respect to the I-Time. Typical examples of a Quant operator include EACH, ALL, EVERY, and ONCE. As shown in section 5, quantifiers are sub-cases of the more general functional form of validation to determine if future occurrences of an event are valid.

Past-dependent Events Let H be the event history. If an event e~ is called past-dependent if occurrence of ei is dependent on H. 2 Terenziani Ter94 uses the terms Frame-Time, Quant, I-Time, and Qual-Rel to describe the similar notions.


6.2

275

Supporting Temporal Reasoning

In this section, we briefly review the features of Event Manager that are useful for the implementation of temporal reasoning.

LATE Operator In MZ95 and in other event algebras, a negation operator is described, such as !E, where E is any primitive event. Although, such a definition is useful for defining composite events, it is wrong because this event occurs at all time points except the instances of E. Therefore, we introduce a L A T E operator that has the following syntax: create E V E N T eidl LATE (timestamp I tint} eid2. At either the timestamp or tnow+tint, the event manager checks if event eid2 has occurred, and if it has not then asserts event eidl.

Future Event Operations Let 9~ be the set of events on the event queue, and f be any particular event from this set with ft as its detection time. The event specification language supports creation of derived future event of the form: create event fd F U T U R E ft • time_dif f; If the - operator is used, then the new event fd has to obviously satisfy the requirement that tnow < ft - time_diff.

Event Constraints Event constraints are of two types - Calendric and Relative. In the event model, a calendar is associated with each event. Also, a temporal database, such as Illustra, prevents insertion of an element that is inconsistent with a calendar. Hence, calendric constraints are supported in a trivial fashion. To model relative constraints, operators such as A F T E R , STARTED BY, FINISHED BY, DURING. are introduced in temporal languages. However, we provide only two operators F U T U R E and LATE, and claim that these are adequate for supporting relative event constraints. Furthermore, our approach leads to precise semantics and implementation of tempora ! constraints. Note that, relative events cannot occur with reference to a database or asynchronous external event. Relative events are meaningful with respect to only schedulable events. A relative event may be constrained in two ways - (1)Before or after a scheduled event and (2)Between two scheduled events. The first case can be easily implemented using the F U T U R E event operator. For example, consider the following rule: Mary eats breakfast before going to work. The "going to work" event can be easily defined by a work-day calendar. The "eats-breakfast" event can be defined as follows: create event eats-breakfast as go-to-work - 30 min. Note that, Terenziani's approach does not require that a specific time operator (30 min) be used which is acceptable for modeling a temporal rule but clearly unsuitable for implementation.

276


The second case can also be implemented in the same fashion if both scheduled events are on the event queue at the same time. However, in certain cases this is not possible. Consider the event Measure temperature while the furnace operation is on-going. The event "temperature measurement" is constrained to occur between the operation start and end events. However, the operation end event cannot be inserted on the event queue until the operation start event occurs. Hence, such a temporal constraint has to be implemented in conjunction with the rule system. This is briefly explained with the help of the following rule (see PS95 for details): on event o p e r _ s t a r t { c r e a t e event oper_end . . . c r e a t e event temp_measure as oper_end - 10 }

7

RELATED W O R K

A database paradigm of application development was proposed in MD89. The notion of a powerful event manager, which is capable of sensing events in the database and external world, was described in SAD+94. However, they have completely ignored temporal events and an implementation of such an event manager. A conventional C + + object has been extended with an event interface in AMC93. This interface enables objects to designate some, possibly all, of their methods as primitive event generators. A classification of events similar to this paper is given in CKAK94, however, they have completely ignored calendar events and their implementation. To our knowledge, none of the active databases, in research or commercial world, maintain a history of database events. This forgetfulness of events makes it impossible to implement composite events. Alert SPAM91 claims to store a set of events as first clas tuples in an active table. However, this is not true because the effect of an event, i.e., updated, inserted or deleted tuples, have been referred to as events. Also time sequence of events is not maintained. There have been three important proposals regarding the definition and implementation of composite events GJS92, CKAK94, GD94. The composite event operators in all three proposals are quite similar, however, the detection mechanisms are different. ODE GJS92 uses finite automaton and Samos GD94 uses Petri nets. Snoop CKAK94 have used event graphs for detection and also introduced parameter contexts to alleviate the problem of monotonic increase in the storage space. A Past Temporal Logic (PTL) formalism for specifying events and conditions in active database systems is presented in PSW95. Their work assmnes that a database is designed to represent only the current information, and new values overwrite the old ones. The temporal conditions in rules determine which information is to be saved.


277

The idea of an extensible calendric system was first introduced in SS92,SS93. A system of calendars that allows specification of natural-language time-based expressions was proposed in CSS94. They also proposed an algorithm for implementing Temporal Rules in extensible databases. Many researchers have developed temporal data models. Also, surveys and a book on temporal databases are available in PSE+94, Sno94, TCG+93. It appears that the only other publication that extensively deals with the specification of temporal events is reported in Ter94. There is two key differences between our specification of temporal events and Terenziani's approach are as follows: (1)Definition of an event. An event occurs over an interval of time while this paper assumes that an event occurs instantaneously. (2)Causal relationship among events. In our framework, there is no direct causal relationship between any two events. A rule triggered by an event may deterministically trigger another event, however, it is not sensible to say that one event causes another event. 8

CONCLUSIONS AND R E S E A R C H ISSUES

This paper has presented an architecture and construction of an Event Manager which is a closely coupled extension to a temporal, object-relational database. A SQL-like language was proposed for the registration, subscription, and cancellation of events. This event manager supports external, database and temporal events in an uniform fashion. As event histories can be naturally modeled as time series, temporal database services have been utilized for storing event m e t a d a t a and histories. An event queue mechanism was implemented for the detection of temporal and pollable external events. The event queue allows the definition of context dependent and relative temporal events. There are several areas for further research in this context. Retro-active and pro-active database rules were proposed in lEGS94, and we are investigating if these can be implemented using the proposed event management framework. The current event history storage scheme allows only fixed-length data types as event parameters. A closer integration of composite event algorithms also needs to be evaluated. A graphical format for the specification of events would be also useful as the recent trend is towards the use of 4GL languages. A

LANGUAGE GRAMMAR

The event language notation is similar to the SQL-3 notation. The following notational conventions will be used: - A key word will be shown in Capital Letters. Square brackets indicate optional elements. Curly braces ( } enclose lists from which the user must select one element. Vertical bars - - are used to separate choices. - An identifier is enclosed in brackets < >. -

-

-

278


- A (0,...) shows a list from which items m a y be repeated any number of times. Event Registration

create EVENT <Ev_Id> {TEMPORAL DATABASE I EXTERN I COMPOSITE I FUTURE} CALENDAR REPEAT {HISTORY I NUMBER} {time interval Iint} Composite Event Expr Future Event Expr EVERY {time interval Iint} POLL {time_interval} PAKAM((attr data type) .... )

Event Detection

detect EVENT Ev_Id(attr_val, attr_val,...); Event Cancellation

delete EVENT Ev_Id;

References AMC93

CKAK94

cs931

css94 ECS94

GD94

E. Anwar, L. Maugis, and S. Chakravarthy. A New Perspective on Rule Support for Object-Oriented Databases. In Proceedings of ACM SIGMOD International Conference on the Management of Data, pages 99-109, Washington, D.C, 1993. S. Chakravarthy, V. Krishnaprasad, E. Anwar, and S.-K. Kim. Composite Events for Active Databases: Semantics, Contexts, and Detection. In Proc. of the POth Very Large Database (VLDB) Conference, pages 730-739, Santiago, Chile, 1994. R. Chandra and A. Segev. Managing Temporal Financial Data in an Extensible Database. In Proceedings of the 19th Int. Conf. on Very Large Databases, Dublin, Ireland, Dublin, Ireland, August 1993. R. Chandra, A. Segev, and M. Stonebraker. Implementing Calendars and Temporal Rules in Next-Generation Databases. In Proceedings of the 10th Int. Conf. on Data Engineering, February 1994. O. Etzion, A. Gal, and A. Segev. Retroactive and proactive database processing. In Proceedings of the Fourth International Workshop on Research Issues in Data Engineering (RIDE'94), pages 126-131, Houston, TX, 1994. S. Gatziu and K.R Dittrich. Detecting Composite Events in Active Databases using Petri Nets. In Proceedings of the Fourth International Workshop on Research Issues in Data Engineering (RIDE'94), pages 2-9, Houston, TX, February 1994.

An Architecture and Construction of a Business Event Manager GJS92

II195 Kim95

MD89 MZ95

PS95

PSE+94

PSW95

SAD+94

SC9~

SMP95

Sno94 SPAM91

ss87 SS92

SS93

279

N. Gehani, H.V. Jagadish, and O. Shmueli. Composite Event Specification in Active Databases : Model and Implementation. In Proc. of the 18th Int. Conf. on Very Large Databases, 1992. Illustra Time Series Data Blade Manual. Illustra Information Technologies, Inc., Oakland, CA, 1995. Won Kim. Object-Oriented Database Systems: Promises, Reality, and Future. In Won Kim, editor, Modern Database Systems: The Object Model, Interoperability, and Beyond, pages 255-280. ACM Press, New York, NY, 1995. D.R. McCarthy and U. Dayal. The architecture of an active database management system. In Proc. of ACM SIGMOD Conf., pages 215-224, 1989. I. Motakis and C. Zaniolo. Composite Temporal Events in Active Databases: A Formal Semantics. In International Workshop on Temporal Databases, pages 332-350, Zurich, Switzerland, 1995. Ajit K Patankar and Arie Segev. An Architecture and Construction of an Event Manager. Technical Report 37913, Lawrence Berkeley Laboratory, Berkeley, CA 94720, 1995. Niki Pissinou, Richard T. Snodgrass, Ramez Elmasri, Inderpal S. Mumick, M. Tamer Ozsu, Barbara Pernici, Arie Segev, Babis Theodoulidis, and Umeshwar Dayal. Towards an Infrastructure for Temporal Database: Report of an Invitational ARPA/NSF Workshop. SIGMOD Record, 23(1):35-51, 1994. A. Prasad Sistla and O. Wolfson. Temporal conditions and integrity constraints in active database systems. In Proceedings of A C M SIGMOD International Conference on the Management of Data, pages 269-280, San Jose, CA, 1995. Michael Stonebraker, Paul Aoki, Robert Devine, Witold Litwin, and Michael Olson. Mariposa: A New Architecture for Distributed Data. In Proc. lOth Int. Conf. on Data Engineering, pages 54-65, Houston, TX, Feb. 1994. Arie Segev and Rakesh Chandra. A data model for time-series analysis. In N. Adam and B. Bhargava, editors, Advanced Database Systems. Notes in Computer Science Series, Springer Verlag,, 1993. Arie Segev, Max Mendel, and Ajit Patankar. An Implementation of a Computer Integrated Manufacturing (CIM) system using an Active, objectrelational database. In Proceeding of the second International Conference on Applications of Databases, San Jose, CA, 1995. Richard T. Snodgrass. Overview of the Special Section on Temporal Database Infrastructure. SIGMOD Record, 23(1):34, 1994. U. Schreier, H. Pirahesh, R. Agrawal, and C Mohan. Alert: An Architecture for Transforming a Passive DBMS into an Active DBMS. In Proc. of the 17th VLDB Conference, Barcelona, Spain, 1991. A. Segev and A. Shoshani. A Logical Modeling of Temporal Databases. In Proceedings of A CM SIGMOD International Conference on the Management of Data, May 1987. M. Soo and R. Snodgrass. Mixed Calendar Query Language Support for Temporal Constants. Technical Report TempIS No.29, University of Arizona, 1992. M. Soo and R. Snodgrass. Multiple Calendar Support for Conventional Database Management Systems. In Proceedings of the Int. Workshop on an Infrastructure for Temporal Databases, June 1993.

280


TCG+93 Ter94

A. Tansel, J. Clifford, S. Gadia, S. Jajodia, A. Segev, and R. Snodgrass. Temporal Databases. Benjamin/Cummings Publishing Company, Inc., 1993. P. Terenziani. Dealing with qualitative and quantitative temporal information concerning periodic events. In Proceedings of the 8th Int. Symposium on Methodologies for Intelligent Systems (ISMIS' 94), pages 275-284, Charlotte, NC, 1994.

Discovering Unexpected Patterns in Temporal Data Using Temporal Logic Gideon Berger and Alexander Tuzhilin * 1 Computer Science Department Courant Institute New York University gideon@cs, nyu. edu 2 Information Systems Department Stern School of Business New York University atuzhili@stern, nyu. edu

A b s t r a c t . There has been much attention given recently to the task of finding interesting patterns in temporal databases. Since there are so many different approaches to the problem of discovering temporal patterns, we first present a characterization of different discovery tasks and then focus on one task of discovering interesting patterns of events in temporal sequences. Given an (infinite) temporal database or a sequence of events one can, in general, discover an infinite number of temporal patterns in this data. Therefore, it is important to specify some measure of interestingness for discovered patterns and then select only the patterns interesting according to this measure. We present a probabilistic measure of interestingness based on unexpectedness, whereby a pattern P is deemed interesting if the ratio of the actual number of occurrences of P exceeds the expected number of occurrences of P by some user defined threshold. We then make use of a subset of the propositional, linear temporal logic and present an efficient algorithm that discovers unexpected patterns in temporal data. Finally, we apply this algorithm to synthetic data, UNIX operating system calls, and Web logfiles and present the results of these experiments.

1

Introduction

There has been much work done recently on pattern discovery in temporal and sequential databases. Some examples of this work are 14, 27, 17, 10, 25, 16, 8, 18, 9, 22. Since there are many different types of discovery problems that were addressed in these references, it is important to characterize these problems using some framework. One such characterization was proposed in 1% In this chapter * This work was supported in part by the NSF under Grant IRI-93-18773.

O. Etzion, S. Jajodia, and S. Sripada (Eds.): Temporal Databases- Research and Practice LNCS 1399, pp. 281-309, 1998. ~ 5pringer-Verlag Berlin Heidelberg 1998

282

Gideon Berger and Alexander Tuzhilin

we review this framework and then focus on one specific problem of discovering unexpected patterns in temporal sequences. To find unexpected patterns in a sequence of events, we assume that each event in the sequence occurs with some probability and assume certain conditional distributions on the neighboring events. Based on this, we can compute an expected number of occurrences of a certain pattern in a sequence. If it turns out that the actual number of occurrences of a given pattern significantly differs for the expected number, then this pattern is certainly unexpected and, therefore, is interesting 23, 24. We present an algorithm for finding such patterns and test it on several types of temporal sequences, including Web logfiles and sequences of OS system calls.

5/1/97

7/12/97 Fig. 1. An example of the head_and_shoulder pattern.

2

Characterization of Knowledge Discovery Tasks in Temporal Databases

Characterization of knowledge discovery tasks in temporal databses, proposed in 10 is represented by the 2-by-2 matrix presented in Table 1. The first dimension in this matrix defines the two types of temporal patterns. The first type of a temporal pattern specifies how data changes over time and is defined in terms of temporal predicates. For example, the pattern

head_and_shoulder(IBM, 5/1/97, 7/12/97) indicates that the stock of IBM exhibited head_and_shoulder trading pattern 15 from 5/1/97 until 7/4/97, as is shown in Figure 1). The second type of temporal patterns is rules, such as "if a stock exhibits a head-and-shoulder pattern and investor cash levels are low, then bearish period is likely to follow." The second dimension, the validation/generation dimension, refers to the purpose of the discovery task. In validation the system focuses on a particular

Discovering Unexpected Patterns in Temporal Data Using Temporal Logic

283

pattern and determines whether it holds in the data. For example, we may want to validate if the head_and_shoulders pattern holds for the IBM stock in a given data set or that a certain rule "holds" on the data. The second purpose of discovery can be the generation of new predicates or rules that are previously unknown to the system. For example, the system may attempt to discover new types of trading rules in financial applications. Categorizing patterns in terms of the above two dimensions leads to a twoby-two classification framework of the knowledge discovery tasks, as presented in Table 1. We will describe each of the four categories in turn now.

IValidationl Generation Predicates I III ,I Rules II IV Table 1. Types of Knowledge Discovery Tasks.

C l a s s I. The discovery tasks of this type involve the validation of previously defined predicates over the underlying database. For example, assume that we have the temporal database of daily closing prices of stocks at some stock exchange, STOCK(SYMBOL,PRICE,DATE), where SYMBOL is the symbol of a security, PRICE is the closing price of that stock on the date DATE. Consider the following predicate specifying that the price of a certain stock bottomed out and is on the rise again over some time interval:

bottom_reversal(x, tl, t2)

=

(3t)(tl < t
Ae~/E H . While the expected values here are computed in the usual way, in this case, the actual values are not simply equal to the counts of 6 and e, respectively, but rather equal to the number of 6's and e's that could potentially be added to P. L e m m a 1 Given two events 6 and c where 6 occurs before e on the I N T E R E S T I N G N E S S _ L I S T then:

En'(o~N/~)op61

>

El(c~N/~)opd

P r o o f : W e prove this result for the next operator. Assume, EI(~Nf~)N6~ t (i.e. the query is considered on the infinite history starting at time tt). If the answer to a continuous query is presented to the user on a screen, the display may change over time, even if the database is not updated. Clearly, continuously evaluating a query would be very inefficient. Rather, when a continuous query is entered our processing algorithm evaluates the query once, and returns a set of tuples. Each tuple consists of an instantiation p of the predicate's variables (i.e. an answer to the query when considered in the noncontinuous sense) and a time interval begin to end. The tuple (p, begin, end) indicates that p is in the answer of the instantaneous queries from time begin until the time end. The set of tuples produced in response to a continuous query CQ is called Answer(CQ). Obviously, an explicit update of the database may change a tuple in Answer For example, it is possible that the query evaluation algorithm produces the tuple (o, 5, 7), indicating that o satisfies the query between times 5 and 7. If the speed of the object o is updated before time 5, the tuple may need to be replaced by, say (o, 6, 7), or it may need to be deleted. Therefore, a continuous query CQ has to be reevaluated when an update occurs that may change the set of tuples Answer( CQ ). In this sense Answer(CQ) is a materialized view. However, a continuous query in our model is different than a materialized view, since the answer to a continuous query may change over time even if the database is not updated.

(CQ).

Finally, the third type of query is a persistent query. Formally, a persistent query at time t is defined as a sequence of instantaneous queries at each future time t ~ > t, where the instantaneous query at t ~ has two argmnents (i) the database trace as of t ~ and (ii) the time value t; note that the semantics of this instantaneous query is defined using the possible histories with respect to the database trace at t ~. Observe that, in contrast to a continuous query, the different instantaneous queries comprising a persistent query have the same starting point in the possible histories. These histories may differ for the different instantaneous queries due to database updates executed after time t. To realize the need for persistence, consider the query R -- "retrieve the objects whose speed in the direction of the X-axis doubles within 10 minutes". Suppose that the query is entered as persistent at time 0. Assume that for some object o, at time 0 the value of the dynamic attribute P O S I T I O N . X changes according to the function 5t (recall, t is time, i.e. the speed is 5). At time 0 no objects will be retrieved, since for each object, the speed is identical in all future database states; only the location changes from state to state. Suppose further

320

A. Prasad Sistla, Ouri Wolfson, Sam Chamberlain, and Son Dao

that after one minute the function is explicitly updated to 7t, and after another minute it is explicitly updated to 10t. Then, the speed in the X direction has changed from 5 at time 0 to 10 at time 2, and hence, at time 2 object o should be retrieved as an answer to R. But if we consider the query R as instantaneous or continuous o will never be retrieved, since starting at any point in time, the speed of o is identical in all states of the future database history. When entered as persistent, the query R is considered as a sequence of instantaneous queries, all operating on the history that starts at time 0. At time 2 this history reflects a change of the speed from 2 to 4 within two minutes, thus o will be retrieved at that time. In summary, the three types of queries are illustrated in the following figure.

database history t i

I

|

I

I y

I

I

, *

H

Fig. 1. database history (a) An instantaneous query at time t is defined with respect to the set of possible future histories Ht (i.e. the future history beginning at t). (b) A continuous query at time t is a sequence of instantaneous queries at each time t' >_t. (e) A persistent query at time t is a sequence of instantaneous queries, all at time t. The queries are evaluated at each time t p >_ t when the database is updated.

In contrast to continuous queries, the evaluation of persistent queries requires saving of information about the way the database is updated over time, and we postpone the subject of persistent query evaluation to future research. Observe that persistent queries are relevant even in the absence of dynamic variables. In 15 we developed an algorithm for processing F T L persistent queries. Unfortunately, that algorithm does not work when the queries involve dynamic variables. Observe that continuous and persistent queries can be used to define temporal triggers. Such a trigger is simply one of these two types of queries, coupled with an action and possibly an event. 3

The

FTL

language

In this section we first motivate the need for our language (subsection 3.1), then we present the syntax (3.2) and semantics (3.3) of FTL. In subsection 3.4 we demonstrate the language through some example, and in subsection 3.6 we present our query processing algorithm.

Querying the Uncertain Position of Moving Objects

3.1

321

Motivation

A regular query language such as SQL or OQL can be used for expressing temporal queries on moving objects, however, this would be cumbersome. The reason is that these languages do not have temporal operators, i.e. keywords that are natural and intuitive in the temporal domain. Consider for example the query Q: "Retrieve the pairs of objects o and n such that the distance between o and n stays within 5 miles until they both enter polygon P". Assume that for each predicate G there are functions begin_time(G) and end_time(G) that give the beginning and ending times of the first time-interval during which G is satisfied; also assume that "now" denotes the current time. Then the query Q would be expressed as follows. RETRIEVE o,n FROM Moving-Objects WHERE begin_time(DIST(o, n) < 5) < now and end_time(DIST(o, n) < 5) >

begin_time(INSIDE(o, P)) A INSIDE(n, P)). At the end section 3.2 we show how the query Q is expressed in our proposed language, FTL. Clearly, the query in FTL is simpler and more intuitive. The SQL and OQL queries may be even more complex when considering the fact that the spatial predicates may be satisfied for more than one time interval. Thus, we may need the functions begin_time1 and end_time1 to denote the beginning and ending times of the first time interval, begin_time2 and end_time2 to denote the beginning and ending of the second time interval, etc.

3.2

Syntax

The FTL query language enables queries pertaining to the f u t u r e states of the system being modeled. Since the language and system are designed to be installed on top of an existing DBMS, the FTL language assumes an underlying nontemporal query language provided by the DBMS. However, the FTL language is not dependent on a specific underlying query language, or, in other words, can be installed on top of any DBMS. This installation is discussed in section 4.1. The formulas (i.e. queries) of FTL use two basic future temporal operators U n t i l and N e x t t i m e . Other temporal operators, such as E v e n t u a l l y , can be expressed in terms of the basic operators. The symbols of the logic include various type names, such as relations, integers, etc. These denote the different types of object classes and constants in the database. We assume that, for each n _> 0, we have a set of n-ary function symbols and a set of n-ary relation symbols. Each n-ary function symbol denotes a function that takes n-arguments of particular types, and returns a value. For example, § and * are function symbols denoting addition and multiplication on the integer type. Similarly, _ are binary relation symbols denoting arithmetic comparison operators. The functions symbols are also used to denote atomic queries, i.e. queries in the underlying

322


nontemporal query language (e.g. OQL). We assume that all atomic queries retrieve single values. For example, the function " R E T R I E V E (o.height) W H E R E o.id -- 100" denotes the query that retrieves the height of an object whose id is 100. Atomic queries can have variables appearing in them. For example, "RET R I E V E (o.height) W H E R E o.id -- y" has the variable y appearing free in it; for a given value to the variable y, it retrieves the height of the object whose id is given by y. Functions of arity zero denote constants and relations of arity zero denote propositions. The formulas of the logic are formed using the function and relation symbols, the object classes and variables, the logical symbols -1, A, the assignment quantifier ~--, square brackets , and the temporal modal operators U n t i l and N e x t t i m e . In our logic, the assignment is the only quantifier. It binds a variable to the result of a query in one of the database states of the history. One of the advantages of using this quantifier rather than the First Order Logic (FOL) quantifiers is that the problems of safety are avoided. This problem is more severe when database histories (rather than database states) are involved. Also, the full power of FOL is unnecessary for the sequence of database states in the history. The assignment quantifier allows us to capture the database atomic query values at some point in time and relate them to atomic query values at later points in time.

A term is a variable or the application of a function to other terms. For example, time+ 10 is a term; if x, y are variables and f is a binary function, then f(x, y) is a term; the query " R E T R I E V E o.height W H E R E o.id -- y" specified above is also a term. Well formed formulas of the logic are defined as follows. If tl, ..., tn are terms of appropriate type, and R is an n-ary relational symbol, then R(tl, ..., tn) is a well formed formula. If f and g are well formed formulas, then -~f, f A g, f U n t i l g, N e x t t i m e f and (x ~- tf) are also well formed formulas, where x is a variable and t is a term of the same type as x and may contain free variables; such a term t may represent a query on the database. A variable x appearing in a formula is free if it is not in the scope of an assignment quantifier of the form x r t. In our system, a query is specified by the following syntax: R E T R I E V E W H E R E <semantic-spec> . Here is an F T L formula in which all the free variables are object variables. The specification is a list of attributes of all object variables appearing free in the condition part. The clause <semantic-spec> can be one of the two key words m a y or m u s t , and it specifies the semantics to be used in processing the query. We call a query to be a "may" query if its semantic clause is the key word "may", otherwise the query is called a "must" query. For example, the following query retrieves the pairs of objects o and n such that, on all future histories, the distance between o and n stays within 5 miles until they both enter polygon P (the F T L formula is the argument of the W H E R E clause) in all possible future histories:

Querying the Uncertain Position of Moving Objects R E T R I E V E o,n W H E R E m u s t DIST(o, n) < 5 Until (INSIDE(o, P)) A INSIDE(n, 3.3

323

P)

Semantics

Intuitively, the semantics are specified in the following context. Let so be the state of the database when a query f is entered. The formula f is evaluated on the history starting with so. We define the formal semantics of our logic as follows. We assume t h a t each type used in the logic is associated with a domain, and all the objects of t h a t type take values from t h a t domain. We assume a standard interpretation for all the function and relation symbols used in the logic. For example, < denotes the standard less-than-or-equal-to relation, and + denotes the standard addition on integers. We will define the satisfaction of a formula at a state on a history with respect to an evaluation, where an evaluation is a m a p p i n g t h a t associates a value with each variable. For example, consider the formula Ix ~- RETRIEVE(o)NexttimeRETRIEVE(o) ~ x, t h a t is satisfied when the value of some attribute of o differs in two consecutive database states. The satisfaction of the subformula RETRIEVE(o) ~ x depends on the result of the atomic query t h a t retrieves o from the current database, as well as on the value of the variable x. The value associated with x by an evaluation is the value of o in the previous database state. T h e definition of the semantics proceeds inductively on the structure of the formula. If the formula contains no temporal operators and no assignment (to the variables) quantifiers, then its satisfaction at a state of the history depends exclusively on the values of the database variables in t h a t state and on the evaluation. A formula of the form f U n t i l g is satisfied at a state with respect to an evaluation p, if and only if one of the following two cases holds: either g is satisfied at t h a t state, or there exists a future state in the history where g is satisfied and until then f continues to be satisfied. A formula of the form N e x t t i m e f is satisfied at a state with respect to an evaluation, if and only if the formula f is satisfied at the next state of the history with respect to the same evaluation. A formula of the form x *-- tf is satisfied at a state with respect to an evaluation, if and only if the formula f is satisfied at the same state with respect to a new evaluation t h a t assigns the value of the t e r m t to x and keeps the values of the other variables unchanged. A formula of the form f A g is satisfied if and only if b o t h f and g are satisfied at the same state; a formula of the form -~f is satisfied at a state if and only if f is not satisfied at t h a t state. In our formulas we use the additional propositional connectives V (disjunction), ~ (logical implication) all of which can be defined using ~ and A. We will also use the additional temporal operators E v e n t u a l l y and A l w a y s which are defined as follows. The temporal operator E v e n t u a l l y f asserts t h a t f is satisfied at some future state, and it can be defined as t r u e U n t i l f . Actually, in our context a more intuitive notation is often l a t e r f , but we will use the

324


traditional E v e n t u a l l y f . The temporal operator Always f asserts that f is satisfied at all future states, including the present state, and it can be defined as ~ E v e n t u a l l y ~ f . We would like to emphasize that, although the above context implies that f is evaluated at each database state, our processing algorithm avoids this overhead. Let Q be an instantaneous query specified at time t using the syntax given at the end of the last subsection. Let the FTL formula f denote the condition part of Q, and let T denote the target list of Q. We define the semantics based on the isemantic-specs clause in Q. Let a be the database trace denoting the sequence of updates up to t. Let H be the set of all possible future database histories corresponding to ~ as of now, i.e. as of time t. For any h E H, let F h be the set of all evaluations p to the free variables in f such that f is satisfied at the beginning of h with respect to the evaluation p. Let Rh denote the set of all tuples t obtained by applying some evaluation in Fh to the target list T, i.e. Rh : (p(T) : p C Fh}. Let May_Answer(Q) = UhEFh Rh and Must_Answer(Q) = NheFu Rh. If Q is a "may" query, then we define the semantics of Q, i.e. the answer to Q, to be May_Answer(Q), and if Q is a "must" query its semantics is defined to be Must_Answer(Q). Thus, it is easy to see that the answer computed for the "may" query indicates possibility with respect to at least one of the future possible histories, while the answer computed with for a "must" query denotes definiteness of the result. Both these answers coincide when all the dynamic attributes are deterministic, i.e. H contains a single history.

3.4

Examples

In this subsection, we show how to express some queries in FTL. For expressive convenience, we also introduce the following real-time (i.e. bounded) temporal operators. These operators can be expressed using the previously defined temporal operators and the time object. (see 15). E v e n t u a l l y _ w i t h i n _ c (g) asserts that the formula g will be satisfied within c time units from the current position. E v e n t u a l l y _ a f t e r _ c (g) asserts that g holds after at least c units of time. AIways_for_c (g) asserts that the formula holds continuously for the next c units of time. The formula (g until_within_c h) asserts that there exists a future instance within c units of time where h holds, and until then g continues to be satisfied. The following query retrieves all the objects o of type "civilian" that may enter a restricted area P within three units of time from the current instance. (I)

RETRIEVE o WHERE m a y (o.type --"civilian" A P.type = "restricted"A E v e n t u a l l y _ w i t h i n _ c I N S I D E ( o , P))

The following query retrieves all the civilian objects o that definitely (i.e. must) enter a restricted area P within three units of time, and stay in P for another 2 units of time.

Querying the Uncertain Position of Moving Objects (II)

325

RETRIEVE o W H E R E m u s t (o.type ="civilian" A P.type =" restricted" A E v e n t u a l l y _ w i t h i n _ 3 (INSIDE(o, P)A Always_for_2 INSIDE(o, P)))

The following query retrieves all the objects o that may enter the polygon P within three units of time, stay in P for two units of time, and after at least five units of time enter another polygon Q. (III)

RETRIEVE o WHERE may (Eventually_within_3

(INSIDE(o, P)A Always_for_2

(INSIDE(o, P))A E v e n t u a l l y _ a f t e r _ 5 INSIDE(o, Q))

3.5

Algorithm for evaluation of MOST queries

Earlier in subsection 2.3, we have indicated two different ways for representing the positions of moving objects. In the reminder of this paper, we use the first of these schemes. For an object o moving on a route, we assume that o.ubs and o.lbs, respectively, denote the upper and lower bounds on the speed of the object and that these bounds are positive ; we also assume that the attribute o.route gives the identity of the route on which the object is traveling. We say that an object o is moving freely in 2-dimensional space if its velocities in the x and y directions are independent. For such an object o, we let o.X.ubs and o.X.lbs denote the upper and lower bound speeds in the direction of the x-axis, and o.Y.ubs and o.Y.lbs represent the corresponding speeds in the direction of the y-axis; each of these speeds can be positive or negative. (Note that for an object that moves on a route, the direction of its motion is determined by the route and its speed will give its state of motion at that point; on other hand for an object moving freely in 2-dimensional space we need to know its speeds in both the x and y directions). For a moving object, any of the above sub-attributes can be explicitly updated. In this subsection, we consider the problem of evaluating queries in the MOST model. An F T L formula f is said to be a restricted conjunctive formula, if it has no negations appearing in it, the only temporal operators appearing in it are u n t i l , u n t i l _ w i t h i n _ c and E v e n t u a l l y _ w i t h i n _ c , and the time_stamp or the time variable does not appear in it; the last condition implies that for every query q that appears on the right hand side of an assignment in f (i.e. as in x ~ q) the value returned by q at any time is independent of the time when it is evaluated and is only a function of the values to the free variables in q and the current positions of the objects. This condition also ensures that satisfaction of a non-temporal predicate when an object is at a particular position depends only on the position of the object but not the time when it reached the position. Also, note that f does not contain the n e x t t i m e operator.

326


The following theorem shows that the problem of evaluating a "may" query whose condition part is a conjunctive F T L formula is PSPACE-hard when the objects are moving freely in 2-dimensional space. This theorem is proved by exhibiting a straightforward reduction from the model-checking problem for conjunctive formulas which is a known PSPACE-hard problem 10. T H E O R E M 1: Given a MOST database D modeling objects moving freely in 2-dimensional space, and given a "may" query whose condition part is given by a conjunctive F T L formula containing one free moving object variable, the problem of evaluating the query is a PSPACE-hard problem. Now, we consider the problem of evaluating "may" queries where the objects are moving on routes. Consider a query Q whose condition part is given by a conjunctive formula f with one free moving object variable o. Now consider an object, say ol, whose speed is in the range 1, u. There are many possible histories corresponding to the varying speeds of ol. Let h be the possible history corresponding to the case where the object moves with the highest speed u at all times. Intuitively, it seems to be the case that if there is a possible history h ~ such that h ~ satisfies f at the first state with respect to the evaluation where the variable o is assigned object ol, then f is also satisfied at the beginning of h with respect to the same evaluation. This is due to the following properties: (a) in both the histories object ol goes through the same positions (possibly at different times), (b) all the time bounds in the formula f are only upper bounds, and if these bounds are met when the object is moving at a lower speed then they will definitely be met when the object is moving at a higher speed, and (c) time does not appear any where else in the formula; this ensures that satisfaction of a non-temporal predicate at a particular time only depends on the position of the object but not the time when it reached the position. Now, we have the following theorem. T H E O R E M 2: Let f be a conjunctive F T L formula with one free object variable o ranging over moving objects, ol be an object moving on a route with speed in the range l, u, p be an evaluation in which o is mapped to the object ol, and h be a history in which ol is moving with the maximum speed u. Then, f is satisfied at the beginning of some possible history with respect to the evaluation p iff it is satisfied at the beginning of h with respect to p. P r o o f : Let h ~ be any possible history that satisfies f at the beginning with respect to the evaluation p. For each i > 0, let s~ and t~ denote the i th states in h and h t respectively. Since, in a history a new state is added whenever the position of any object changes, it is the case that the distance of any object in successive states of a history either remains unchanged or changes by 1. Hence, we can divide a history in to a sequence of sub-sequences B o , B 1 , ..., B i , ... of successive states such that ,for each i > 0, the distance of object ol in any two states of B~ is same, and its distance in a state in B~ differs from a state in B~+I by 1. Let B0, B1, ...B~, ... be the sequence of sub-sequences corresponding to h; similarly, let Co, C1, ..., Ci, ... be such a sequence corresponding to h ~. Since, in both the histories ol starts from the same initial position, it is the case that for each i > 0, the distance of ol in any state in Bi equals its distance in any state


327

in Ci. For each i >_ 0, we say that every state in B~ corresponds to every state in Ci and vice versa. Let g be a subformula of f . Now, by a simple induction on the length of g, we show that (*) If g is satisfied at t~ in h t and sj is any state in h that corresponds to ti then g is also satisfied at sj in h ~. The proof is as follows. If g is an atomic formula then (*) holds because the satisfaction of g, with respect to an evaluation, only depends on the position of object ol, and it is independent of the time. The non-trivial case in the induction is when g is of the form g l u n t i l _ w i t h i n _ c g2 where c is a positive constant. Assume that g is satisfied at ti in h t. This implies that there exists some i t > i such that g2 is satisfied at ti,, and for all k, i < k < i t, gl is satisfied at tk; further more, the difference in the value of the time_stamp variable in the states t~, and t~ is bounded by c. Clearly, there is a state s j, in h that appears after si and that corresponds to ti,; furthermore, every state appearing between sj and s j, corresponds to some state appearing between t~ and t~,. By induction, we see that g2 is satisfied at sj,, and gl is satisfied at sj and at all states appearing after sj but before sy. Also, the distance traversed by ol from state sj to sj, is same as that between ti and t~,. Since, in history h, ol is traveling at a higher speed, it is the case that difference in the values of time_stamp in state sj, and sj is smaller than between ti, and t~. From all this, we see that the formula g l u n t i l _ w i t h i n _ c g2 is also satisfied at state sj in h. The other cases in the proof are straightforward. Theorem 2 shows that, in order to answer the "may" queries whose condition part is a restricted conjunctive formula with a single free variable that ranges over moving objects, it is enough if we consider the single history where the objects are moving at the maximum speed. This corresponds to the deterministic case. In the reminder of this section we present an algorithm for evaluating F T L queries for the case when the objects are moving at constant speeds on different routes. Our algorithm works for class of queries given by conjunctive formulas, and for the case when all the dynamic variables are deterministic. A conjunctive formula is an F T L formula without negation and without the n e x t t i m e operator and without any reference to the time_stamp variable. Even though conjunctive formulas can not explicitly refer to the time_stamp variable, one can express real-time properties using the real time temporal operators. Note that the class of conjunctive formulas is superset of the class of restricted conjunctive formulas. In practice, most queries are indeed expressed by conjunctive queries. For instance, all the example queries we use in this paper are such. One of the main reasons for the restriction to conjunctive formulas is safety (i.e. finiteness of the result); negation may introduce infinite answers. The handling of negation can be incorporated in the algorithm, but this is beyond the scope of this paper. An additional restriction of the algorithm is that it works only for continuous and instantaneous queries (i.e. not for persistent queries). For a query CQ specified by the formula f with free variables (Xl, ..., xk) the algorithm returns a relation called Answer(CQ) (this relation was originally discussed in subsection 2.4), having k § 2 attributes. The first k attributes give

328


an instantiation p to the variables, and the last two attributes give a time interval during which the instantiation p satisfies the formula. The system uses this relation to answer continuous and instantaneous queries as follows. For a continuous query CQ, the system presents to the user at each clock-tick t, the instantiations of the tuples having an interval that contains t. So, for example, if Answer(CQ) consists of the tuples (2, 10,15), and (5, 12,14), then the system displays the object with id = 2 between clock ticks 10 and 15, and between clock-ticks 12 and 14 it also displays the object with id = 5. For an instantaneous query, the system presents to the user the instantiations of the tuples having an interval that contains the current clock-tick.

The FTL query processing a l g o r i t h m Let f ( x l , x2, ..., xk) be a conjunctive F T L formula with free variables Xl, x2, ..., Xk such that the variable time_stamp is also not referenced in it. We assume that the system has a set of objects O. Some of these objects are stationary and the others are mobile. The positions (i.e. the X , Y and Z coordinates) of the stationary objects are assumed to be fixed, while the positions of the mobile objects are assumed to be dynamic variables. Without loss of generality we assume that the time when we are evaluating the query is zero. The current database state reflects the positions of objects as of this time, and furthermore, we assume that for each dynamic variable we have functions denoting how these variables change over time. As a consequence, the values of static variables at any time is the same as their value at time zero, and the values of dynamic variables at any time in the future are given by the functions which are stored in the database. Thus, the future history of the database is implicitly defined. For each subformula g of f (including f itself), our algorithm computes a relation Rg. Let g(xl,..., Xk) be a subformula containing free variables Xl, ..., xk. The relation Rg will have (k + 2) attributes; the first k attributes correspond to the k variables; the last two attributes in each tuple specify the beginning and ending of a time interval; we call this as the interval of the tuple. Each tuple in Rg denotes an instantiation p of values to the free variables in g and an interval I (specified by the last two columns) during which the formula g is satisfied with respect to p. The algorithm computes Rg, inductively, for each subformula g in increasing lengths of the subformula. To do this it executes a sequence of one or more SQL queries whose result will be the desired relation Rg. We only describe how to generate these SQL queries. After the termination of the algorithm, we will have the relation R f corresponding to the original formula f . The base case in our algorithm is when g is an atomic predicate R(Xl, ..., xk) such as a spatial relation etc. In this case, we assume that there is a routine, which for each possible relevant instantiation of values to the free variables in g, gives us the intervals during which the relation R is satisfied. Clearly, this algorithm has to use the initial positions and functions according to which the dynamic variables change. For example, if R is the predicate D I S T ( x l , x2) _< 5, then the algorithm gives, for each relevant object pair ol, o2, the time intervals


329

during which the distance between them is < 5 (for this example, if we assume that all objects are point objects, and that xl ranges over moving objects, and x2 ranges over stationary objects, and that we have a relational database containing information about the the routes and speeds of moving objects and about the positions of statinary objects on the routes, then we can write an SQL query that computes a relation denoting the the ids of objects and the time intervals during which the predicate R is satisfied). We assume that the relation given by the atomic predicates are all finite. For cases where these relations are infinite in size, we need to use some finite representations for them and work with these representations; this is beyond the scope of this paper and will be discussed in a later paper. For the case when g is not an atomic predicate, we compute the relation Rg inductively based on the outer most connective of g as given below. - Let g -- gl A g2. In this case, let R1, R2 be the relations computed for gl and g2 respectively, i.e P~ = Rg, for i = 1, 2. For a given instantiation p, if gl is satisfied during interval/1 and g2 is satisfied d u r i n g / 2 then g is satisfied during the interval 11 n / 2 . The relation R for g is computed by joining the relationships R1 and R2 as follows: the join condition is that common variable attributes should be equal and the interval attributes should intersect; the retrieved tuple copies all the variable values, and the interval in the tuple will be the intersection of the of the intervals of the joining tuples. It is faily easy to see how we can write a single SQL query that computes Rg from Rg 1 and Rg 2. - Let g = gl U n t i l g2, and let R1 and R2 be the relations corresponding to gl and g2 respectively. Let p § 2, q § 2 be the number of columns in R1 and R2 respectively. First, we compute another relation S from R1 as follows. We define a chain in R1 to be a set T of tuples in R1 that give same values to the first p columns and such that the following property is satisfied: if l denotes the lowest value of the left end points of all intervals of tuples in T and u denotes the highest value of the right end points of these tuples ,then every time point in the interval If, u is covered by an interval of some tuple in T (i.e., the interval /, u is the union of all the intervals in T); we define T to be a maximal chain if no proper super set of it is a chain. The relation S is obtained by having one tuple corresponding to each maximal chain T in R1 whose first p columns have the same values as those in T and whose interval is the interval /, u as defined above. For example, if a maximal chain has three tuples with intervals 10, 20, 15, 30 11,40 then these will be represented by a single tuple whose interval is 10, 40. The resulting relation S satisfies the following property. For any two tuples t, t r E S, if t, t ~ match on the first p columns (i.e. columns corresponding to the variables), then their intervals will be disjoint and furthermore these intervals will not even be consecutive; the non-consecutiveness of the interwls means that there is a non-zero gap separating intervals in tuples that give identical values to corresponding variables;

330

A. Prasad Sistla, Ouri Wolfson, Sam Chamberlain, and Son Dao The following SQL query computes S from R1. For any tuple t, we let t.1 and t.u denote the left and right end points of the interval of t. SELECT(< list >, tl.1, t2.u) FROM R1 tl, R1 t2 WHERE COND-B AND NOT EXISTS ( SELECT t3 FROM R1 t3, R1 t4 WHERE COND-C AND NOT EXISTS ( SELECT t5 FROM R1 t5 WHERE COND-D

-

))

In the above query, the < list > in the target list is the list of the first p attributes of tl. COND-B specifies that tl and t2 give identical values to the first p columns and that tl.l < t2.u, and there is no other tuple whose interval contains t2.u+ 1 or tl.1-1; the later condition guarantees maximality of the chain. The WHERE clause of the outermost query states that tl.l and t2.1 denote the left and right ends of a chain. This is indicated by stating that there are no tuples t3 and t4 whose intervals intersect with the interval tl.l, t2.u, and such that t3.u < t4.l and such that there is a gap between t3.u and t4.1; COND-C specifies the first of the two conditions; the existence of a gap between t3.u and t4.1 is indicated by the inner most subquery starting with the clause "NOT EXISTS"; this subquery states that there is no tuple t5 whose interval intersects with the interval t3.u, t4.l; COND-C states the later condition. COND-B,COND-C and COND-D also specify that the first p columns of tl thru t5 match. Observe that if tl, t2 are any two tuples belonging to S and R~, respectively, such that their intervals intersect, and tl.l where each of the fields month, day, and year cycle as time passes.

D i s c u s s i o n of N a m i n g The concept of calendar defined here subsumes commonly used calendars such as the Gregorian calendar, the Hebrew calendar, and the Lunar calendar, though the given definition is much more general. This usage is consistent with the conventional English meaning of the word (+E3). It is also intuitive for the same reason (-bE8). 3.21

Transaction-timeslice Operator

Definition The transaction timeslice operator may be applied to any relation with transaction time timestamps. It takes as one argument the relation and as a second argument a transaction-time element whose greatest value must not exceed the current transaction time. It returns the argument relation reduced in the transaction-time dimension to just those times specified by the transactiontime argument. E x p l a n a t i o n Several types of transaction-timeslice operators are possible. Some may restrict the type of the time argument to intervals or instants. Some operators may, given an instant as time argument, return a snapshot relation or a valid-time relation when applied to a transaction-time or a bitemporal relation, respectively; other operators may always return a result relation of the same type as the argument relation. P r e v i o u s l y Used N a m e s Rollback operator, timeslice operator, state query.

D i s c u s s i o n of N a m i n g The name "rollback operator" has procedural connotations, which in itself is inappropriate (-E8). The name indicates that the operator is computed by moving backwards in time, presumably from the current transaction time. However, the operator could equMly well be computed by a forward motion in time, from the time when the argument relation was created. This makes "rollforward operator" an equally acceptable term. Further, the transaction-timeslice operator may be computed using both rollback (decremental computation) and rollforward (incremental computation). "State query" seems less precise than transaction-timeslice operator (-E9). It is equally applicable as a name for the valid-timeslice operator (-E8). Further, "state operator" is better than "state query."

380

Christian S. Jensen and Curtis E. Dyreson (Editors)

The name "transaction timeslice" may be abbreviated to timeslice when the meaning is clear from the context.

3.22

Valid-timeslice Operator

Definition The valid-timeslice operator may be applied to any relation with valid time timestamps. It takes as one argument the relation and as a second argument a valid-time element. It returns the argument relation reduced in the valid-time dimension to just those times specified by the valid-time argument. Explanation Several types of valid-timeslice operators are possible. Some may restrict the type of the time argument to intervals or instants. Some operators may, given an instant as time argument, return a snapshot relation or a transaction-time relation when applied to a valid-time or a bitemporal relation, respectively; other operators may always return a result relation of the same type as the argument relation. P r e v i o u s l y U s e d N a m e s Timeslice operator.

Discussion of N a m i n g The term valid-timeslice operator is consistent with transaction-timeslice operator (+El). "Timeslice" is appropriate only in a disambiguating context (+E2). 3.23

Schema Evolution

Definition A database system supports schema evolution if it permits modification of the database schema without the loss of extant data. No support for previous schemas is required. P r e v i o u s l y U s e d N a m e s Schema versioning, data evolution.

Discussion of N a m i n g While support for "schema evolution" indicates that an evolving schema may be supported, the term "schema versioning" indicates that previous versions of an evolving schema are also supported. Therefore, "schema versioning" is appropriate for a more restrictive concept. The name "data evolution" is inappropriate because "data" refers to the schema contents, i.e., the extension rather than the intension. Data evolution is supported by conventional update operators. While some confusion exists as to its exact definition, "schema evolution" is an accepted name and is widely used already. 3.24

Schema Versioning

Definition A database system accommodates schema versioning if it allows the querying of all data, both retrospectively and prospectively, through userdefinable version interfaces. E x p l a n a t i o n While support for schema versioning implies the support for schema evolution, the reverse is not true. Support for schema versioning requires that a history of changes be maintained to enable the retention of past schema definitions.

The Consensus Glossary of Temporal Database Concepts

381

P r e v i o u s l y U s e d N a m e s Schema evolution, data evolution. D i s c u s s i o n o f N a m i n g The name "schema evolution" does not indicate that previously current versions of the evolving schema are also supported. It is thus less precise that "schema versioning." As schema evolution, schema versioning is an intensional concept; "data evolution" has extensional connotations and is inappropriate. 3.25

Event

D e f i n i t i o n An event is an instantaneous fact, i.e., something occurring at an instant. An event is said to occur at some granule t if it occurs at any instant during t. Previously Used Names

Event relation, instant relation.

D i s c u s s i o n o f N a m i n g "Event relation" is not consistent with the distinction between "instant and "event" ( - E T ) . "Instant relation" is longer than event (-E2). 3.26

Event Occurrence Time

D e f i n i t i o n The event occurrence time of an event is the instant at which the event occurs in the real-world. Previously Used Names

Event time.

D i s c u s s i o n o f N a m i n g Event occurrence time is more precise than event time (+E9). Nevertheless, when the context is clear, the event occurrence time may be shortened to the event time. 3.27

S p a t i o t e m p o r a l as M o d i f i e r

D e f i n i t i o n The modifier spatiotemporal is used to indicate that the modified concept concerns simultaneous support of some aspect of time and some aspect of space, in one or more dimensions. Previously Used Names ented.

Spatio-temporal, temporal-spatial, space-time-ori-

D i s c u s s i o n o f N a m i n g This term is already in use, interchangeably with "spatio-temporal," in the geographic information systems community (+E3) (hence, the preference over "temporal-spatial"), and is consistent with the "temporal" modifier (+E7). Avoiding the hyphen makes it easier to type (+E2), another reason to prefer it over "temporal-spatial." It may be applied generically as a modifier for "database," "algebra," "query language, .... data model," and "DBMS."

382


3.28

Spatial Q u a n t u m

D e f i n i t i o n A spatial quantum (or simply quantum, when the sense is clear) is the shortest distance (or area or volume) of space supported by a spatial DBMS--it is a non-decomposable region of space. It can be associated with one or more dimensions. A particular unidimensional quantum is an interval of fixed length along a single spatial dimension. A particular three-dimensional quantum is a fixed-sized, located cubic volume of space. A l t e r n a t i v e N a m e Spatial unit. D i s c u s s i o n of N a m i n g "Spatial quantum" is preferred over "spatial unit" because spatial distances and volumes are usually given as measurements of some unit (such as meters), but the "unit of measurement" is not the same as the "spatial quantum." The former term ("spatial quantum") is more precise (+E9), in part, because it avoids this possible confusion.

3.29

Spatiotemporal Quantum

Definition A spatiotemporal quantum (or simply quantum, when the sense is clear) is a non-decomposable region in two, three, or four-space, where one or more of the dimensions are spatial- and the rest, at least one, are temporal. A l t e r n a t i v e N a m e Spatiotemporal unit, spatiotemporal chronon. D i s c u s s i o n of N a m i n g This term generalizes chronon and spatial quantum. "Unit" is perhaps less precise (-E9). "Chronon" specifically relates to time, and thus is inconsistent with the adjective "spatiotemporal."

4 4.1

Concepts

of General

Temporal

Database

Interest

Absolute Time

D e f i n i t i o n When applied to valid time, the modifier absolute indicates that a specific valid time at a given timestamp granularity is associated with a fact. Such a time is independent of, e.g., the valid time of another fact and of the current time, now. E x p l a n a t i o n Examples are: "Mary's salary was raised on March 30, 1993" and "Jack was killed on xx/xx/1990." 4.2

Relative Time

D e f i n i t i o n The modifier relative indicates that the valid time of a fact is related to some other time, e.g., the valid time of another fact or the current time, now. As absolute time, relative time may be applied to other temporal aspects than valid time.


383

Explanation The relationship between times can be qualitative (before, after, etc.) as well as quantitative (3 days before, 397 years after, etc.). Examples are: "Mary's salary was raised yesterday," "it happened sometime last week," "it happened within 3 days of Easter," "the Jurassic is sometime after the Triassic," and "the French revolution occurred 397 years after the discovery of America." 4.3

T e m p o r a l Expression

D e f i n i t i o n A temporal expression is a syntactic construct used, e.g., in a query that evaluates to a temporal value, i.e., an instant, a time period, a time interval, or a temporal element. E x p l a n a t i o n All approaches to temporal database querying allow relational expressions. Some only allow relational expressions, and thus they are unisorted. Some allow relational expressions, temporal expressions, and also possibly boolean expressions. Such expressions may be defined through mutual recursion. Discussion of N a m i n g In snapshot databases, expressions evaluate to relations and therefore they may be called relational expressions to differentiate them from temporal expressions.

4.4

Fixed Span

Definition A span is fixed if it possesses the special property that its duration is independent of the context. E x p l a n a t i o n As an example of a fixed span, "one hour" always, independently of the context, has a duration of 60 minutes (discounting leap seconds). To see that not all spans are fixed, consider "one month," an example of a variable span in th e Gregorian calendar. The duration of this span may be any of 28, 29, 30, and 31 days, depending on the context. P r e v i o u s l y Used N a m e s Constant span. Discussion of N a m i n g Fixed span is short (+E2), precise (+E9), and has no conflicting meanings (+E5). "Constant" appears more precise (+E8) and intuitive (+E9), but it is also used as a keyword in several programming languages (-E5).

4.5

Variable Span

Definition A span is variable if its duration is dependent on the context. E x p l a n a t i o n Any span is either a fixed span or a variable span. An obvious example of a variable span is "one month," the duration of which may be any of 28, 29, 30, and 31 days, depending on the context. Disregarding the intricacies of leap seconds, the span "one hour" is fixed because it always, independently of the context, has a duration of 60 minutes.

384


P r e v i o u s l y U s e d N a m e s Moving span. D i s c u s s i o n of N a m i n g Variable span is intuitive (+E9), and precise (+E9). "Moving span" is unintuitive ( - E 9 ) and has informal spatial connotations (-E5). 4.6

Bitemporal Interval

Definition A bitemporal interval is a region, with sides parallel to the axes, in two-space of valid time and transaction time. When associated in the database with some fact, it identifies when that fact, recording that something was true in reality during the specified interval of valid time, was logically in the database during the specified interval of transaction time. A bitemporal interval can be represented with a non-empty set of bitemporal chronons (or granules). 4.7

Spatiotemporal Interval

A spatiotemporal interval is a region in n-space, where at least one of the axes is a spatial dimension and the remaining axes are temporal dimensions, with the region having sides that are parallel to all axes. When associated in the database with some fact, it identifies when and where that fact was true. A spatiotemporal interval can be represented by a non-empty set of spatiotemporal quanta.

4.8

Spatiotemporal Element

Definition A spatiotemporal element is a finite union of spatiotemporal intervals. Spatiotemporal elements are closed under the set theoretic operations of union, intersection and complementation. D i s c u s s i o n o f N a m i n g This is the natural generalization of "temporal element." It can be represented with a set of spatiotemporal quanta.

4.9

Snapshot Equivalent/Weakly Equivalent

Definition Informally, two tuples are snapshot equivalent or weakly equivalent if the snapshots of the tuples at all times are identical. Let temporal relation schema R have n time dimensions, Di, i = 1 , . . . , n, and let Ti, , i = 1 , . . . , n be corresponding timeslice operators, e.g., the valid timeslice and transaction timeslice operators. Then, formally, tuples x and y are snapshot equivalent if Vtl E D 1 . . . V t n E Dn(rtn (... (Tll (x) ) . . .) = Tin(... (Ttl~ (y) ) . . .) ) . Similarly, two relations are snapshot equivalent or weakly equivalent if at every instant their snapshots are equal. Snapshot equivalence, or weak equivalence, is a binary relation that can be applied to tuples and to relations.


385

P r e v i o u s l y Used N a m e s Temporally weak.

Discussion o f N a m i n g Both "snapshot equivalent" and "weakly equivalent" have strong support by members of the temporal database community, and it has not been possible to reach a consensus on which of these two names is preferable; we have therefore adopted both names, listed in alphabetical order, for this concept. "Weak equivalence" was originMly used by Ullman to relate two algebraic expressions (Ullman, Principles of Database Systems, Second Edition, page 309). We rely on the context to disambiguate this usage from the usage specific to temporal databases (-E5). "Temporally weak" is not intuitive--in what way is it weak? "Snapshot equivalent" explicitly identifies the source of the equivalence (+E8). 4.10

Snapshot-Equivalence Preserving O p e r a t o r / W e a k l y Invariant Operator

Definition A unary operator F is snapshot-equivalence preserving or weakly invariant if relation r is snapshot equivalent, or weakly equivalent, to r' implies F(r) is snapshot equivalent, or weakly equivalent, to F(r'). This definition may be extended to operators that accept two or more argument relation instances. P r e v i o u s l y Used N a m e s Invariant under weak binding of belongs to.

Discussion of N a m i n g As for snapshot equivalent and weakly equivalent, both names have strong support by members of the temporal database community. Because it has not been possible to reach a consensus on which of these two names is preferable, both names have been adopted, listed alphabetically, for this concept. This definition does not rely on the term "weak binding" (+E7). 4.11

Snapshot Equivalence Class/Weak Relation

Definition A snapshot equivalence class or weak relation is a set of relation instances that are all snapshot equivalent, or weakly equivalent, to each other. Discussion of Naming As for snapshot equivalent and weakly equivalent, both names have strong support by members of the temporal database community. Because it has not been possible to reach a consensus on which of these two names is preferable, both have been adopted in alphabetical order. "Weak relation" denotes a set of relation instances, not a single relation instance. It has therefore been argued that the name snapshot equivalence class is more intuitive. On the other hand, "weak relation" is shorter than "snapshot equivalence class."

386


4.12

Value Equivalence

Definition Informally, two tuples on the same (temporal) relation schema are value equivalent if they have identical non-timestamp attribute values. To formally define the concept, let temporal relation schema R have n time dimensions, Di, i = 1 , . . . , n, and let 7 i, i -- 1 , . . . , n be corresponding timeslice operators, e.g., the valid-timeslice and transaction-timeslice operators. Then tuples x and y are value equivalent if

3ti 9 D i . . . 3 t n 9 Dn(T~.(... (vti~(x))...) ~-@) A 381 9 D1... 3Sn 9 Dn(r~ (... (r~l (y))...) # O) :=~

UW,~D1...W~Do ~:~ (''" (T:~ (X))...) = UVs16~,l...Vso6~,o ~';~ (''" (~-~1(Y))"" ")" Thus the set of tuples in snapshots of x and the set of tuples in snapshots of y are required to be identical. This is required only when each tuple has some non-empty snapshot. E x p l a n a t i o n The concept of value equivalent tuples has been shaped to be convenient when addressing concepts such as coalescing, normal forms, etc. The concept is distinct from related notions of the normal form SG1NF and mergeable tuples. Phrases such as "having the same visible attribute values" and "having duplicate values" have been used previously. Discussion of N a m i n g The orthogonality criterion (+El) is satisfied. Further, the concept is a straightforward generalization of identity of tuples in the snapshot-relational model. There are no competing names (+E3), the name seems open-ended (+E4) and does not appear to have other meanings (+E5). Further, the name is consistent with existing terminology (+E7) and does not violate other criteria.

4.13 Coalesce Definition The coalesce operation is unary and takes as input a temporal relation and returns a temporal relation with the same schema. Its purpose is to effect a kind of normalization of a temporal relation with respect to one or multiple time dimensions. This is achieved by packing as many value-equivalent tuples as possible into a single value-equivalent one, thereby possibly enlarging the timestamps of the respective time "dimension(s). Explanation The concept of coalescing has found widespread use in connection with data models that employ interval-valued timestamps. In one-dimensional models where such timestamps are associated with tuples, two or more valueequivalent tuples with consecutive or overlapping intervals are replaced by a single, value-equivalent tuple with the union of the timestamps of the original tuples as its interval-valued timestamp. The coalesce operation eliminates duplicates from individual snapshots of a temporal relation. If the temporal data model permits duplicates in snapshots, the operation does not preserve snapshot-equivalence; otherwise, it does.


387

Tuples may be timestamped with higher-dimensional values, e.g., two-dimensional bitemporal intervals. In such multi-dimensional frameworks, the coalesce operation may, depending on the time data type employed, have to be annotated with the time dimension to be coalesced. P r e v i o u s l y U s e d N a m e s Merging, normalize. D i s c u s s i o n of N a m i n g There appears to be general consensus with respect to the name of this concept (+E3). The name "merging" is occasionally used when describing coalescing, but it has a less specific meaning and has not been proposed as a substitute for "coalescing" ( - E 3 , - E 9 ) . Because coalescing conflicts with the COALESCEoperation of SQL-92, the term NORMALIZEhas been adopted by the SQL3 standardization committee.

4.14

T i m e Sequence

D e f i n i t i o n A time sequence (TS) is a sequence (ordered by time) of pairs < v, t > where v is an arbitrary data object and t are granules of a given granularity designating past and/or future instants. A TS is identified by a surrogate (possibly a time-invariant key). If each v is a single value, the TS is said to be simple, and if v is a complex value (e.g., a set, a sequence, etc.), the TS is complex. A TS may have properties and/or constraints attached to it. E x p l a n a t i o n The above definition is model-independent and can have different representations in different models. For example in t h e relational model where a relation is attribute-value timestamped (granules), each point in the sequence will be a tuple. For tuple timestamping, v will be a set of attribute values. Note that temporal elements are derivable from a time sequence. P r e v i o u s l y U s e d N a m e s History, time-series. D i s c u s s i o n of N a m i n g The concept is specific to temporal databases (+R1) and is well defined and understood in the real world (+R2, +R3). It has been used and referred to in many works (+R4). The name is intuitive (+E8), it is not as widely used as "history" (-E3), but it describes the concept more accurately (+E9) than "history," i.e., the common use of history is in reference to the past, but a temporal database can have a time sequence that involves future times.

4.15

History

D e f i n i t i o n A history is the temporal representation of an "object" of the real world or of a database. Depending on the object, we can have attribute histories,

entity histories, relationship histories, schema histories, transaction histories, etc.

388


E x p l a n a t i o n "History" is a general concept, intended in the sense of "train of events connected with a person or thing." In the realm of temporal databases, the concept of history is intended to include multiple time dimensions as well as the data models (+R1). Thus we can have, e.g., valid-time histories, transaction-time histories, bitemporal histories, and user-defined time histories. However, multi-dimensional histories can be defined from mono-dimensional ones (e.g., a bitemporal history can be seen as the transaction-time history of a valid-time history). Formally or informally, the term "history" has been often used in many temporal database papers (+R4), also to explain other terms. For instance, salary history, object history, transaction history are all expressions used in this respect. P r e v i o u s l y U s e d N a m e s Time sequence, time-series, temporal value, temporal evolution. Discussion of N a m i n g Although "history" usually has to do with past events (-E5), its use for the future--as introduced by prophecies, science fiction, scientific forecasts---does not seem to present comprehension difficulties. (The adjective "historical" seems more problematic for some.) Talking about future history, requires the same extension of meaning as required by talking about future data. The alternative term "temporal value" is less general, since it applies when "history" specializes into attribute history (value history). Moreover, "history" is a slightly more general concept than "time sequence": different time sequences (with different time granularities) could be extracted from the same history. Therefore the definition of "history" does not prevent defining "time sequence." "History" is also preferred over alternative names because it allows a better definition of related terms. Since it implies the idea of time, "history" does not require further qualifications as "sequence" or "series" do (+E2). In particular, "history" well lends itself to be used as modifier (+El), even though "time sequence" is an alternative consolidated term ( - E 3 , - E 6 ) . "History" is natural (+E8) and precise (+E9), whereas "temporal value" may recall a temporal element (e.g., timestamp value) and "time sequence" may recall a sequence of temporal elements. 4.16

History-oriented

Definition A temporal data model or DBMS is said to be history-oriented if: 1. It supports history unique identification (e.g., via time-invariant keys, surrogates or OIDs); 2. The integrity of histories as first-class objects is inherent in the model, in the sense that history-related integrity constraints might be expressed and enforced, and the data manipulation language provides a mechanism (e.g., history variables and quantification) for direct reference to object-histories; P r e v i o u s l y U s e d N a m e s Temporal value integrity, grouped, object-oriented.


389

Discussion of N a m i n g "History-oriented" is preferred over "having temporal value integrity" since its meaning seems to be more direct. Further, in a more general perspective, integrity constraints can be introduced as well in a history-oriented model (e.g. history uniqueness, entity history integrity, referential history integrity). "History-oriented" is also preferred over "grouped" (+E7) in order to avoid confusion with other kinds of grouping (e.g., defined terms "dynamic/static valid-time grouping"). "History-oriented" is not a synonym for "object-oriented," even though a good temporal object-oriented model should also be history-oriented. In general, object-orientation requires more features that are inherited from snapshot O-O models (+E7). For instance, (attribute/tuplc point/interval-stamped) relational models can also be history-oriented, provided that suitable integrity constraints and algebraic operators are defined. Once history has been defined, "history-oriented" is quite intuitive (+E8). 4.17

History Equivalent

Definition History equivalence is a binary relation that can be applied to objects of any kind (of the real world or of a database). Specifically, two objects are history equivalent if their histories are snapshot equivalent. E x p l a n a t i o n Unlike value equivalence which concerns only explicit-attribute values and completely disregards time, history equivalence implies a common evolution along with time (implicitly assumes equality of timestamps as well as explicit-attributes values). P r e v i o u s l y U s e d N a m e s Snapshot equivalent.

Discussion of N a m i n g As indicated by the definition, "history equivalent" is closely related to snapshot equivalent (-E3). History equivalence is a natural extension to histories of the basic notion of snapshot equivalence (+E8). 4.18

Temporal Interpolation

Definition The derivation of the value of a history at a granule, for which a value is not explicitly stored in the database, is referred to as temporal interpolation. This derivation is typically expressed as a function of preceding and/or succeeding (in time) values of the history. E x p l a n a t i o n This concept is important for large histories (in particular, for continuous scientific data) where data is collected only for a subset of the granules in the history, or where all granules contain data, but interpolation is used as a form of compression. The alternative name of temporal derivation will apply if the definition is extended to encompass cases where the derivation is not based on interpolation, but on other computations or rules. P r e v i o u s l y U s e d N a m e s Temporal derivation.

390


Discussion of N a m i n g The concept is specific to temporal databases (+R1) and its essence---interpolation--is well-defined and understood in the real world (+R2, +R3). The name is intuitive (+E8). 4.19

Gregorian Calendar

Definition The Gregorian calendar is composed of 12 months, named in order, January, February, March, April, May, June, July, August, September, October, November, and December. The 12 months form a year. A year is either 365 or 366 days in length, where the extra day is used on "leap years." Leap years are defined as years evenly divisible by 4, with years evenly divisible by 100 being excluded, unless that year is evenly divisible by 400. Each month has a fixed number of days, except for February, the length of which varies by a day depending on whether or not the particular year is a leap year. Discussion of Naming "Gregorian calendar" is widely used and accepted (+E3,+E7). This term is defined and used elsewhere (-R1), but is in such common use in temporal databases that it should be defined. 4.20

Calendric System

Definition A calendric system is a collection of calendars. Each calendar in a calendric system is defined over contiguous and non-overlapping intervals of an underlying time-line. Calendric systems define the human interpretation of time for a particular locale as different calendars may be employed during different intervals. Discussion of Naming A calendric system is the abstraction of time available at the conceptual (query language) level. The term "calendric system" has been used to describe the calculation of events within a single calendar--it therefore has a conflicting meaning (-E7). The present definition generalizes that usage to multiple calendars in a very natural way, however. Furthermore, the meaning is intuitive in that the calendric system interprets time values at the conceptual level (+ES). 4.21

P h y s i c a l Clock

Definition A physical clock is a physical process coupled with a method of measuring that process. Although the underlying physical process is continuous, the physical clock measurements are discrete, hence a physical clock is discrete. E x p l a n a t i o n A physical clock by itself does not measure time; it only measures the process. For instance, the rotation of the Earth measured in solar days is a physical clock. Most physical clocks are based on cyclic physical processes (such as the rotation of the Earth).

Previously Used Names Clock.


391

Discussion of N a m i n g The modifier "physical" is used to distinguish this kind of clock from other kinds of clocks, e.g., the time-line clock (§ It is also descriptive in so far as physical clocks are based on recurring natural or man-made phenomena (§ 4.22

Time-line Clock

Definition In the discrete model of time, a time-line clock is defined as a set of physical clocks coupled with some specification of when each physical clock is authoritative. Each chronon in a time-line clock is a chronon (or a regular division of a chronon) in an identified, underlying physical clock. The time-line clock switches from one physical clock to the next at a synchronization point. A synchronization point correlates two, distinct physical clock measurements. The time-line clock must be anchored at some chronon to a unique physical state of the universe. E x p l a n a t i o n A time-line clock glues together a sequence of physical clocks to provide a consistent, clear semantics for a discrete time-line. A time-line clock provides a clear, consistent semantics for a discrete time-line by gluing together a sequence of physical clocks. Since the range of most physical clocks is limited, a time-line clock is usually composed of many physical clocks. For instance, a tree-ring clock can only be used to date past events, and the atomic clock can only be used to date events since the 1950s. P r e v i o u s l y Used N a m e s Base-line clock, time-segment clock.

Discussion of N a m i n g The term "time-line" has a well-understood informal meaning, as does "clock," which we coopt for this definition (+E5). This concept currently has no name (+E7)(-E3), but it is used for every timestamp (e.g., SQL2 uses the mean solar day clock--the basis of the Gregorian calendar-as its time-line clock). The modifier "time-line" distinguishes this clock from other kinds of clocks (+El). Time-line is more intuitive than "base-line" (+E8), but less precise (mathematically) than "time-segment," since the time-line clock usually describes a segment rather than a line (-E9). We prefer time-line clock to time-segment clock because the former term is more general (§ and is intuitively appealing. 4.23

T i m e - l i n e Clock G r a n u l a r i t y

Definition The time-line clock granularity is the uniform duration of each chronon in the time-line clock. Discussion of N a m i n g The modifier "time-line" distinguishes this kind of granularity from other kinds of granularity (+El) and describes precisely where this granularity applies (§ The term granularity is defined in the addendum of granularity-related concepts.

392


4.24

Beginning

D e f i n i t i o n The distinguished value beginning is a special valid-time instant preceding the earliest granule on the valid-time line. Beginning has no transactiontime semantics.

P r e v i o u s l y U s e d N a m e s Start, begin, commencement, origin, negative infinity. Discussion of N a m i n g Beginning has the advantage of being intuitive (+E8), and does not have conflicting meanings (+E5). 'Begin" appears to be more straightforward (+E8), but suffers from conflicting meanings because it is a common programming language keyword (-E5). "Start," "commencement," and "origin" are awkward to use, e.g., "Start precedes the event," "Commencement precedes the event," and "Origin precedes the event." (-E8). Furthermore, choosing start would require us to choose "end" for the opposite concept, and end is a common programming language keyword (-E5). Origin also has a conflicting meaning relative to calendars (-E5). Lastly, "negative infinity" is longer (-E2) and slightly misleading since it implies that time is infinite (-E9). This may or may not be true depending on theories about the creation of the universe. Also, negative infinity has a wellestablished mathematical meaning (-E5). 4.25

Forever

forever is a special valid-time instant following the largest granule on the valid-time line. Forever has no transaction-time semantics. D e f i n i t i o n The distinguished value

P r e v i o u s l y U s e d N a m e s Infinity, positive infinity. Discussion of N a m i n g Forever has the advantage of being intuitive (+E8) and does not have conflicting meanings (+E5). "Infinity" and "positive infinity" both appear to be more straightforward, but have conflicting mathematical meanings (-E5). Furthermore, positive infinity is longer and would require us to choose "negative infinity" for its opposite (-E2). 4.26

Initiation

initiation, associated with a relation, denotes the time instant when a relation was created. "Initiation" is a value in the domain of transaction times and has no valid-time semantics. D e f i n i t i o n The distinguished value

P r e v i o u s l y U s e d N a m e s Start, begin, commencement, origin, negative infinity, beginning, birth. Discussion of N a m i n g The arguments against "start," "begin," "commencement," "origin," and "negative infinity" are as in the discussion of beginning. "Birth" is an alternative that has been used by some authors. Initiation is preferred over beginning since transaction time is distinct from valid time. Using different terms for the two concepts avoids conflicting meanings (+E5).

The Consensus Glossary of Temporal Database Concepts 4.27

393

Timestamp Interpretation

Definition In the discrete model of time, the timestamp interpretation gives the meaning of each timestamp bit pattern in terms of some time-line clock chronon (or group of chronons), that is, the time to which each bit pattern corresponds. The timestamp interpretation is a many-to-one function from time-line clock chronons to timestamp bit patterns. Discussion of N a m i n g Timestamp interpretation is a concise (+E2), intuitive (+ES), precise (+E9) term for a widely-used but currently undefined concept

4.28

Timestamp Granularity

Definition In the discrete model of time, the timestamp granularity is the size of each chronon in a timestamp interpretation. For example, if the timestamp granularity is one second, then the duration of each chronon in the timestamp interpretation is one second (and vice-versa). E x p l a n a t i o n Each time dimension has a separate timestamp granularity. A time, stored in a database, must be stored in the timestamp granularity regardless of the granularity of that time (e.g., the valid-time date January 1st, 1990 stored in a database with a valid-time timestamp granularity of a second must be stored as a particular second during that day, perhaps midnight January 1st, 1990). If the context is clear, the modifier "timestamp" may be omitted, for example, "valid-time timestamp granularity" is equivalent to "valid-time granularity." P r e v i o u s l y Used N a m e s Time granularity. Discussion of N a m i n g Timestamp granularity is not an issue in the continuous model of time. The adjective "timestamp" is used to distinguish this kind of granularity from other kinds of granularity, such as the granularity of nontimestamp attributes (§247 "Time granularity" is much too vague a term since there is a different granularity associated with temporal constants, timestamps, physical clocks, and the time-line clock although all these concepts are time-related.

4.29

Temporal Selection

D e f i n i t i o n Facts are extracted from a temporal database by means of temporal selection when the selection predicate involves the times associated with the facts. The generic concept of temporal selection may be specialized to include validtime selection, transaction-time selection, and bitemporal selection. For example, in valid-time selection, facts are selected based on the values of their associated valid times.

394


Discussion of N a m i n g Query languages supporting, e.g., valid-time data, generally provide special facilities for valid-time selection which are built into the languages. The name has already been used extensively in the literature by a wide range of authors (§ it is consistent with the unmodified notion of selection in (non-temporal) databases (+El, +E7), and it appears intuitive and precise

(+E8, +Eg). 4.30

Temporal Projection

Definition In a query or update statement, temporal projection pairs the computed facts with their associated times, usually derived from the associated times of the underlying facts. The generic notion of temporal projection may be applied to various specific time dimensions. For example, valid-time projection associates with derived facts the times at which they are valid, usually based on the valid times of the underlying facts. E x p l a n a t i o n While almost all temporal query languages support temporal projection, the flexibility of that support varies greatly. In some languages, temporal projection is implicit and is based the intersection of the times of the underlying facts. Other languages have special constructs to specify temporal projection. The name has already been used extensively in the literature (+E3). It derives from the r e t r i e v e clause in Quel as well as the SELECT clause in SQL, which both serve the purpose of the relational algebra operator projection, in addition to allowing the specification of derived attribute values. P r e v i o u s l y U s e d N a m e s Temporal assignment.

Discussion of N a m i n g A related concept, denoted a temporal assignment, is roughly speaking a function that maps a set of time values to a set of values of an attribute. One purpose of a temporal assignment would be to indicate when different values of the attribute are valid. 4.31

Temporal Natural Join

Definition A temporal natural join is a binary operator that generalizes the snapshot natural join to incorporate one or more time dimensions. Tuples in a temporal natural join are merged if their explicit join attribute values match, and they are temporally coincident in the given time dimensions. As in the snapshot natural join, the relation schema resulting from a temporal natural join is the union of the explicit attribute values present in both operand schemas, along with one or more timestamps. The value of a result timestamp is the temporal intersection of the input timestamps, that is, the instants contained in both. P r e v i o u s l y Used N a m e s Natural time-join, time-equijoin.


395

Discussion of N a m i n g The snapshot natural join can be generalized to incorporate valid time (the valid-time natural join), transaction time (the transactiontime natural join), or both (the bitemporal natural join). In each case, the schema resulting from the join is identical to that of the snapshot natural join appended with the timestamp(s) of the input relations. "Temporal natural join" directly generalizes the snapshot term "natural join" in that "temporal" is used as a modifier consistent with its previously proposed glossary definition (+E7). "Natural time-join" is less precise since it is unclear what is natural, i.e., is the join over "natural time" or is the time-join "natural" (-E7, -E9). "Time-equijoin" is also less precise since, in the snapshot model, the natural join includes a projection while the equijoin does not (-E7, -E9).

4.32

Temporal D e p e n d e n c y

Definition Let X and Y be sets of explicit attributes of a temporal relation schema, R. A temporal functional dependency, denoted X Z Y, exists on R if, for all instances r of R, all snapshots of r satisfy the functional dependency X - * Y. Note that more specific notions of temporal functional dependency exist for valid-time, transaction-time, bitemporal, and spatiotemporal relations. Also observe that using the template for temporal functional dependencies, temporal multivalued dependencies may be defined in a straight-forward manner. Finally, the notions of temporal keys (super, candidate, primary) follow from the notion of temporal functional dependency. Explanation Temporal functional dependencies are generalizations of conventional functional dependencies. In the definition of a temporal functional dependency, a temporal relation is perceived as a collection of snapshot relations. Each such snapshot of any extension must satisfy the corresponding functional dependency. P r e v i o u s l y U s e d N a m e s Independence, dependence. Discussion of N a m i n g Other (conflicting) notions of of temporal dependencies and keys have been defined, but none are as closely paralleled by snapshot dependencies and keys as the above. The naming of the concepts is orthogonal with respect to existing snapshot concepts, and the new names are mutually consistent (+El, +E7). Related notions of independent and dependent attributes exist. Using temporal as a prefix distinguishes the concept from conventional dependencies and points to the specific nature of the dependency. Thus ambiguity is avoided (+E5), and precision is enhanced (+E9)--at the expense of brevity (-E2). "Temporal dependency" has also been used in a non-generic sense, to denote a different concept. The term "temporal" is often used in a generic sense, so ambiguity results when it is also used in a specific sense. Thus "temporal" is used here only in a generic sense.

396


4.33

Temporal Normal Form

Definition A pair (R, F) of a temporal relation schema R and a set of associated temporal functional dependencies F is in temporal Boyce-Codd normal form (TBCNF) if

V X - ~ Y E F+ (Y C X V X - ~ R) where F + denotes the closure of F and X and Y are sets of attributes of R. Similarly, (R, F) is in temporal third normal form (T3NF) if for all non-trivial temporal functional dependencies X -~ Y in F +, X is a temporal superkey for R or each attribute of Y is part of a minimal temporal key of R. The definition of temporal fourth normal form (T4NF) is similar to that of TBCNF, but also uses temporal multivalued dependencies. P r e v i o u s l y Used N a m e s Time normal form, P normal form, Q normal form, first temporal normal form. Discussion of N a m i n g The three temporal normal forms mentioned in the definition are not a complete account of temporal normal forms. Indeed, the alternative names refer to different and complementing notions of temporal normal forms. The naming of the concepts is orthogonal with respect to existing snapshot concepts, and the new names are mutually consistent (+El, +E7).

4.34

Time-invariant Attribute

Definition A time-invariant attribute is an attribute whose value is constrained to not change over time. In functional terms, it is a constant-valued function over time. 4.35

Time-varying Attribute

Definition A time-varying attribute is an attribute whose value is not constrained to be constant over time. In other words, it may or may not change over time. 4.36

Temporally H o m o g e n e o u s

Definition A temporal tuple is temporally homogeneous if the lifespan of all attribute values within it are identical. A temporal relation is said to be temporally homogeneous if its tuples are temporally homogeneous. A temporal database is said to be temporally homogeneous if all its relations are temporally homogeneous. In addition to being specific to a type of object (tuple, relation, database), homogeneity is also specific to some time dimension, as in "temporally homogeneous in the valid-time dimension" or "temporally homogeneous in the transaction-time dimension."


397

Explanation The motivation for homogeneity arises from the fact that no timeslices of a homogeneous relation produce null values. Therefore a homogeneous relational model is the temporal counterpart of the snapshot relational model without nulls. Certain data models assume temporal homogeneity. Models that employ tuple timestamping rather than attribute-value timestamping are necessarily temporally homogeneous--only temporally homogeneous relations are possible. P r e v i o u s l y U s e d N a m e s Homogeneous. Discussion of Naming In general, using simply "homogeneous" without "temporal" as qualifier may cause ambiguity because the unrelated notion of homogeneity exists also in distributed databases (-E5).

4.37 Temporal Specialization Definition Temporal specialization denotes the restriction of the interrelationship between otherwise independent (implicit or explicit) timestamps in relations. An example is a relation where facts are always inserted after they were valid in reality. In such a relation, the transaction time would always be after the valid time. Temporal specialization may be applied to relation schemas, relation instances, and individual tuples. E x p l a n a t i o n Data models exist where relations are required to be specialized, and temporal specializations often constitute important semantics about temporal relations that may be utilized for, e.g., query optimization and processing purposes. P r e v i o u s l y U s e d N a m e s Temporal restriction. Discussion of N a m i n g The chosen name is more widely used than the alternative name (+E3). The chosen name is new (+E5) and indicates that specialization is done with respect to the temporal aspects of facts (+E8). Temporal specialization seems to be open-ended (+E4). Thus, an opposite concept, temporal generalization, has been defined. "Temporal restriction" has no obvious opposite name (-E4).

4.38 Specialized Bitemporal Relationship Definition A temporal relation schema exhibits a specialized bitemporal rela-

tionship if all instances obey some given specialized relationship between the (implicit or explicit) valid and transaction times of the stored facts. Individual instances and tuples may also exhibit specialized bitemporal relationships. As the transaction times of tuples depend on when relations are updated, updates may also be characterized by specialized bitemporal relationships. P r e v i o u s l y U s e d N a m e s Restricted bitemporal relationship. Discussion of N a m i n g The primary reason for the choice of name is consistency with the naming of temporal specialization (+El). For additional discussions, see temporal specialization.

398


4.39

R e t r o a c t i v e Temporal Relation

Definition A temporal relation schema including at least valid time is retroactive if each stored fact of any instance is always valid in the past. The concept may be applied to temporal relation instances, individual tuples, and to updates. Discussion of N a m i n g The name is motivated by the observation that a retroactive bitemporal relation contains only information concerning the past (+E8). 4.40

P r e d i c t i v e T e m p o r a l Relation

Definition A temporal relation schema including at least valid time is predictive if each fact of any relation instance is valid in the future when it is being stored in the relation. The concept may be applied to temporal relation instances, individual tuples, and to updates. P r e v i o u s l y Used N a m e s Proactive bitemporal relation. Discussion of N a m i n g Note that the concept is applicable only to relations which support valid time, as facts valid in the future cannot be stored otherwise. The choice of "predictive" over "proactive" is due to the more frequent everyday use of "predictive," making it a more intuitive name (+E8). In fact, "proactire" is absent from many dictionaries. Tuples inserted into a predictive bitemporal relation instance are, in effect, predictions about the future of the modeled reality. Still, "proactive" is orthogonal to "retroactive" ( - E l ) . 4.41

D e g e n e r a t e B i t e m p o r a l Relation

Definition A bitemporal relation schema is degenerate if updates to its relation instances are made immediately when something changes in reality, with the result that the values of the valid and transaction times are identical. The concept may be applied to bitemporal relation instances, individual tuples, and to updates. Discussion of N a m i n g "Degenerate bitemporal relation" names a previously unnamed concept that is frequently used. A degenerate bitemporal relation resembles a transaction-time relation in that only one timestamp is necessary. Unlike a transaction-time relation, however, it is possible to pose both valid-time and transaction-time queries on a degenerate bitemporal relation. The use of "degenerate" is intended to reflect that the two time dimensions may be represented as one, with the resulting limited capabilities. 5 5.1

Concepts

of Specialized Interest

Valid-time P a r t i t i o n i n g

Definition Valid-time partitioning is the partitioning (in the mathematical sense) of the valid time-line into valid-time elements. For each valid-time element, we associate an interval of the valid time-line on which a cumulative aggregate may then be applied.


399

E x p l a n a t i o n To compute the aggregate, first partition the time-line into validtime elements, then associate an interval with each valid-time element, assemble the tuples valid over each interval, and finally compute the aggregate over each of these sets. The value at any instant is the value computed over the partitioning element that contains that instant. The reason for the associated interval with each temporal element is that we wish to perform a partition of the valid time-line, and not exclude certain queries. If we exclude computing the aggregate on overlapping intervals, we exclude queries such as "Find the average salary paid for one year before each hire." Such queries would be excluded because the one-year intervals before each hire might overlap. Partitioning the time-line is a useful capability for aggregates in temporal databases (+RI,+R3). One example of valid-time partitioning is to divide the time-line into years, based on the Gregorian calendar. Then for each year, compute the count of the tuples which overlap that year. There is no existing term for this concept. There is no partitioning attribute in valid-time partitioning, since the partitioning does not depend on attribute values, but instead on valid-times. Valid-time partitioning may occur before or after value partitioning. P r e v i o u s l y Used N a m e s Valid-time grouping.

Discussion of Naming "Grouping" is inappropriate because the valid-time elements form a true partition; they do not overlap and must cover the time line. However the associated intervals may be defined in any way. 5.2

Dynamic Valid-time Partitioning

Definition In dynamic valid-time partitioning the valid-time elements used in the partitioning are determined solely from the timestamps of the relation. E x p l a n a t i o n One example of dynamic valid-time partitioning would be to compute the average value of an attribute in a relation (say the salary attribute), for the previous year before the stop-time of each tuple. A technique which could be used to compute this query would be for each tuple, find all tuples valid in the previous year before the stop-time of the tuple in question, and combine these tuples into a set. Finally, compute the average of the salary attribute values in each set. It may seem inappropriate to use valid-time elements instead of intervals, however there is no reason to exclude valid-time elements. Perhaps the elements are the intervals during which the relation is constant. P r e v i o u s l y Used Names Moving window.

400


Discussion of N a m i n g The term dynamic is appropriate (as opposed to static) because if the information in the database changes, the partitioning intervals may change. The intervals are determined from intrinsic information. The existing term for this concept does not have an opposing term suitable to refer to static valid-time partitioning, and can not distinguish between the two types of valid-time partitioning (-E3, +E9). While various temporal query languages have used both dynamic and static valid-time partitioning, they have not always been clear about which type ()f partitioning they support (+El). Utilization of these terms will remove this ambiguity from future discussions.

5.3

Static Valid-time Partitioning

Definition In static valid-time partitioning the valid-time elements used are determined solely from fixed points on a calendar, such as the start of each year. E x p l a n a t i o n Computing the maximum salary of employees during each month is an example which requires using static valid-time partitioning. To compute this information, first divide the time-line into valid-time elements where each element represents a separate month on, say, the Gregorian calendar. Then, find the tuples valid over each valid-time element, and compute the maximum aggregate over the members of each set. P r e v i o u s l y Used N a m e s Moving window. Discussion of N a m i n g This term further distinguishes existing terms (-E3, +E9). It is an obvious parallel to dynamic valid-time partitioning (+El). Static is an appropriate term because the valid-time elements are determined from extrinsic information. The partitioning element would not change if the information in the database changed.

5.4

Valid-time Cumulative Aggregation

Definition In cumulative aggregation, for each valid-time element of the validtime partitioning (produced by either dynamic or static valid-time partitioning), the aggregate is applied to all tuples associated with that valid-time element. The value of the aggregate at any instant is the value computed over the partitioning element that contains that instant. E x p l a n a t i o n One example of cumulative aggregation would be find the total number of employees who had worked at some point for a company. To compute this value at the end of each calendar year, then, for each year, define a validtime element which is valid from the beginning of time up to the end of that year. For each valid-time element, find all tuples which overlap that element, and finally, count the number of tuples in each set. Instantaneous aggregation may be considered to be a degenerate case of cumulative aggregation where the partition is per granule and the associated interval is that granule. P r e v i o u s l y U s e d N a m e s Moving window.


401

Discussion of N a m i n g Cumulative is used because the interesting values are defined over a cumulative range of time (+E8). This term is more precise than the existing term ( - E 3 , § 5.5

Instantaneous Aggregation

Definition In instantaneous aggregation, for each granule in a granularity, the aggregate is applied to all tuples valid at that granule. Discussion of N a m i n g The term instantaneous is appropriate because the aggregate is applied over every granule, which are used to represent instants. It suggests an interest in the aggregate value over a very small time interval, much as acceleration is defined in physics over an (infinitesimally) small time (+R3). Many temporal query languages perform instantaneous aggregation, others use cumulative aggregation, while still others use a combination of the two. This term will be useful to distinguish between the various alternatives, and is already used by some researchers (+R4,+E3). 5.6

Temporal Modality

Definition Temporal modality concerns the way according to which a fact originally associated with a granule or interval at a given granularity distributes itself over the corresponding granules at "finer" granularities or within the interval at the same level of granularity. E x p l a n a t i o n (Nota Bene: The term "finer" in this discussion refers to granularities that are related by a groups-into relationship, see the granularity glossary for a discussion of granularity relationships.) We distinguish two basic temporal modalities, namely sometimes and always. The sometimes temporal modality states that the relevant fact is true in at least one of the corresponding granules at the finer granularity, or in at least one of the granules of the interval in case an interval is given. For instance: "The light was on yesterday afternoon," meaning that it was on at least for one minute in the afternoon (assuming minutes as the granularity). The always temporal modality states that the relevant fact is true in each corresponding granule at the finer granularity. This is the case, for instance, of the sentence: "The shop remained open on a Sunday in April 1990 all the day long" with respect to the granularity of hour. This issue is relate to attributes varying within their validity intervals.

5.7

Macro-event

Definition A macro-event is a holistic fact with duration, i.e., something occurring over an interval taken as a whole. A macro-event is said to occur over an interval I if it occurs over the set of contiguous granules representing I (considered as a whole). P r e v i o u s l y U s e d N a m e s Process.

402


Discussion o f N a m i n g "Process" is an over-loaded term, that is, a term having quite different meanings in different contexts ( - E 9 ) . Examples of macro-events are baking a cake, having a dinner party, flying from Rome to Paris. It is worth remarking the distinction between macro-events and interval relations. Saying that a macro-event relates to the structure of an interval as whole means that if it consumes a certain interval it cannot possibly transpire during any subinterval thereof.

5.8

Temporally Indeterminate

Definition Information that is temporally indeterminate can be characterized as "don't know when" information, or more precisely, "don't know exactly when" information. More precisely the modifier 'temporally indeterminate' indicates that the modified object, e.g., a fact or an event, has an associated time, but that the time is not known precisely. The most common kind of temporal indeterminacy is valid-time indeterminacy or user-defined time indeterminacy. Transaction-time indeterminacy is rare because transaction times are always known exactly. E x p l a n a t i o n Often a user knows only approximately when an event happened, when an interval began and ended, or even the duration of a span. For instance, she may know that an event happened "between 2 P.M. and 4 P.M., .... on Friday," "sometime last week," or "around the middle of the month." She may know that a airplane left "on Friday" and arrived "on Saturday." Or perhaps, she has information that suggests that a graduate student takes "four to fifteen" years to write a dissertation. These are examples of temporally indeterminate information. There are (at least) three possible sources of indeterminacy in a statement with respect to time: (i) a discrepancy between the granularities of the temporal reference, or qualification, and the occurrence time; (ii) an under-specification of the occurrence time, when the granularities of the temporal qualification and the occurrence time coincide; and (iii) relative times. As a first approximation, we can say that a statement is temporally indeterminate if the granularity of its reference to time (in the examples, the granularity of days) is coarser than the granularity of the time at which the denoted events (instantaneously) occur. Notice that temporal indeterminacy as well as relativity of references to time are mainly qualifications of statements rather than of the events they denote (that is, temporal indeterminacy characterizes the relation between the granularity of the time reference of a statement and the granularity of the event occurrence time). Notice also that it does not depend on the time at which the statement is evaluated. The crucial, and critical, point is clearly the determination of the time granularity of the event occurrence time. Some problems could be avoided by adopting the following weaker notion of temporally indeterminacy: a statement whose reference to time has granularity


403

G (e.g., days) is temporally determinate with respect to every coarser granularity (e.g., months) and temporally indeterminate with respect to every finer granularity (e.g., seconds). However, we do not like this solution because it does not take into account information about the denoted occurrence time. In particular, for a macro-event there exists a (finest) granularity at which its occurrence time can be specified, but with respect to finer granularities, the event as a whole does not make sense, and must, if possible, be decomposed into a set of components. But not all cases of temporally indeterminate information involve a discrepancy between the granularity of the reference to time and the granularity of the occurrence time. Consider the sentence: "The shop remained open on a Sunday in April 1990 all the day long." 'Days' is the granularity of both the time reference and the occurrence time. Nevertheless, this statement is temporally indeterminate because the precise day in which the shop remained open is unknown (we know only that it is one of the Sundays in April 1990). Statements that contain a relative reference to time are also temporally indeterminate, but the reverse does not hold: temporally-indeterminate statements can contain relative as well as absolute references to time. The statements "Jack was killed sometime in 1990" and "Michelle was born yesterday" contain absolute and relative references to time, respectively, but they are both temporally indeterminate.

Previously Used Names Fuzzy time, temporally imprecise, time incompleteHess.

Discussion of N a m i n g The adjective "temporal" allows parallel kinds of indeterminacy to be defined, such as spatial indeterminacy (+El). We prefer "temporally indeterminate" to "fuzzy time" since fuzzy has a specific, and different, meaning in database contexts (+E8). There is a subtle difference between indeterminate and imprecise. In this context, indeterminate is a more general term than imprecise since precision is commonly associated with making measurements. Typically, a precise measurement is preferred to an imprecise one. Imprecise time measurements, however, are just one source of temporally indeterminate information (+E9). On the other hand, "time incompleteness" is too general. Temporal indeterminacy is a specific kind of time incomplete information.

5.9

Temporally Determinate

Definition The modifier temporally determinate indicates that the modified object, e.g., a fact or an event, has an associated time that is known precisely. Explanation See the explanation for "temporally indeterminate." Previously Used Names Precise.

404


5.10

Temporally-indeterminate Instant

Definition A temporally-indeterminate instant (or just indeterminate instant, when the context is clear) is an instant that is known to be located sometime during an admissibiliW interval, which is a sequence of granules. Non-contiguous granules for the possible time of an instant can be modeled by an exclusive-or disjunction of (indeterminate) instants. E x p l a n a t i o n "Sometime between March 1 and March 5" is a typical indeterminate instant. Note that an instant with noncontiguous temporally-indeterminate information, such as "a Friday night in 1990," is not an indeterminate instant since the possible times for the instant are non-contiguous. The incomplete temporal information could be more substantial. For instance, an indeterminate instant could have an associated probability mass function which gives the probability that the instant occurred during each granule. P r e v i o u s l y U s e d N a m e s Temporally-incomplete instant, temporally-fuzzy instant, temporally-imprecise instant. D i s c u s s i o n of N a m i n g Currently, there is no name used in the literature to describe the incomplete temporal information associated with an event. The modifier "incomplete" is too vague (-E9), while "fuzzy" has unwanted connotations (i.e., with fuzzy sets) (-E9). "Indeterminate" is more general than "imprecise;" imprecise commonly refers to measurements, but imprecise clock measurements are only one source of indeterminate instants. 5.11

Temporally-indeterminate Interval

D e f i n i t i o n A temporally-indeterminate interval (or just indeterminate interval when the context is clear) is an interval bounded by at least one temporallyindeterminate instant. Since an interval cannot end before it starts, the possible times associated with the bounding instants can overlap on only a single granule. P r e v i o u s l y U s e d N a m e s Temporally-incomplete interval, temporally-fuzzy interval, temporally-imprecise interval. D i s c u s s i o n o f N a m i n g Currently, there is no name used in the literature to describe the incomplete temporal information associated with an interval. The modifier "incomplete" is too vague (-E9), while "fuzzy" has unwanted connotations (i.e., with fuzzy sets) (-E9). "Indeterminate" is more general than "imprecise;" imprecise commonly refers to measurements, but imprecise clock measurements are only one source of indeterminate intervals. 5.12

Admissibility Interval

D e f i n i t i o n The admissibility interval is either an anchored duration associated with an indeterminate instant or a duration associated with an indeterminate span, that delimits the range of possible times represented by the instant or span.


405

Previously Used N a m e s Period of indeterminacy. Discussion of N a m i n g The admissibility interval associated with an indeterminate instant is an anchored duration that delimits the range of possible times during which the instant occurred. The instant is located sometime during the admissibility interval but it is unknown exactly when. The name "admissibility interval" is more intuitive than "period of indeterminacy" (+E8). The name was used in the TSOS system (+E3).

Contributors An alphabetical listing of names, affiliations, and e-mail addresses of the contributors follows. M. BShlen, Computer Science Dept., Aalborg University, Denmark, boehlen~cs, auc. dk; C. Dyreson, Computer Science Dept., James Cook University, Australia, c u r t i s ~ c s , j cu. edu. au; R. Elmasri, Computer Science Engineering Dept., University of Texas at Arlington [email protected]; S. K. Gadin, Computer Science Dept., Iowa State University, gadia~cs, i a s t a t e . e d u ; F. Grandi, CIOC-CNR, DEIS, University of Bologna, Italy, f g r a n d i 9 c i n e c a , i t ; P. Hayes, Beckman Institute, phayes@cs .uiuc. edu; S. Jajodia, Information & Software Systems Engineering Dept., George Mason University, j ajodia@gmu, edu; W. Ks Mercedes Benz; N. Kline, Microsoft, k l i n e ~ c s . a r i z o n a , edu; N. Lorentzos, Informatics Laboratory, Agricultural University of Athens, Greece, lorentzos 9 aua. a r i a d n e - t , gr; Y. Mitsopoulos, Informatics Laboratory, Agricultural University of Athens, Greece; A. Montanari, Dip. di Matematica e Informatica, Universit~ di Udine, Italy, montana~dimi, uniud, it; D. Nonen, Computer Science Dept., Concordia University, Canada, daniel@c s . c o n c o r d i a , ca; E. Peressi, Dip. di Matematica e Informatica, Universit~ di Udine, Italy; B. Pernici, Electronic Engineering and Information Sciences Dept., Politecnico di Milano, Italy, pernici@elet .polimi. i t ; J. F. Roddick, School of Computer and Information Science, University of South Australia, roddickr u n i s a , edu. au; N. L. Sarda, Computer Science and Engineering Dept., Indian Institute of Technology, Bombay, India, nls@cse, i i t b . e r n e t , in; M. R. Scalas, University of Bologna, Italy, mrscalas@deis, unibo, i t ; A. Segev, School of Business Adm. and Computer Science Research Dept., University of California, segevr l b l .gov; R. T. Snodgrass, Computer Science Dept., University of Arizona, [email protected]; M. D. Soo, Computer Science and Engineering Dept., University of South Florida, soo~babbage, csee .usf .edu; A. Tansel, Bernard M. Baruch College, City University of New York uztbb@cunyvm, cuny. edu; P. Tiberio, CIOC-CNR., DEIS, University of Bologna, Italy, p t i b e r i o @ d e i s . u n i b o , it; G. Wiederhold, Computer Science Dept., Stanford University, gio@cs, s t a n f o r d , edu.

A G l o s s a r y of T i m e G r a n u l a r i t y C o n c e p t s Claudio Bettini 1, Curtis E. Dyreson 2, William S. Evans 3, Richard T. Snodgrass 3, and X. Sean Wang 4 1 Dipartimento di Scienze dell'Informazione, Universit~ degli Studi di Milano, Milano, Italy bettini@dsi, unimi, i t ,

http ://mercurio. sm. dsi. unimi, it/'bert ini/

2 Department of Computer Science, James Cook University, Townsville, Australia curtis@cs, j cu. edu. au, http: I/w~z. cs. j cu. edu. au/" curt is/ 3 Department of Computer Science, University of Arizona, Tucson, Arizona, U S A {will, rts }@cs. arizona, edu, http://~r~, cs. arizona, edu/people/{will, rts } a Department of Information and Software Systems Engineering, George Mason University, Falrfax, Virginia, U S A xywang@isse, gmu. edu, http://~r~, isse. gmu. edu/f aculty/xywang

1

Introduction

This paper is an extension of the preceding glossary, but focussed on time granularity concepts. We use the same structure as in the previous glossary.

2

Glossary Entries

This glossary contains revised definitions of calendar and granularity that appeared in the preceding glossary. 2.1

Time Domain

A time domain is a pair (T; _. This is consistent with the knowledge that can be obtained from the database at each observation point. In our example, the value was replaced with another value for its entire validity time, but in the general case the revision control should allow either revision by another value, or just logical deletion of the revised value. The revision may apply to the entire validity time of the revised value, or to any part of it. The revision control is implemented at the instance level, dynamically.

3

The Modeling Primitives

In this section we present the primitives of the temporal database model that is intended to satisfy the requirements posed in the previous sections. These primitives are used by the system designer when constructing the application. This issue is further elaborated in Section 4. Section 3.1 presents the information modeling primitives. Section 3.2 discusses the enhanced schema language support for the static SVS and modification control definitions, Section 3.3 introduces the set of update operation types, which are the major implementation vehicle for the dynamic SVS and modification control definitions. The semantics of these components is discussed in Section 4. 3.1

Information Modeling Primitives

This section presents the information modeling primitives that are used in this paper. This data model can be implemented on top of various lower-level data models, such as relational or object-based. Information about an object is maintained as a set of variables (instances of the class’ properties). Each variable contains an information about the history of values as well as the different components of the variable status (SVS, modification control, revision control) of the variable. Each component is represented using a set of state-elements; state-element is the most basic object in the database. We assume that the database is an append only database. New information is added while existing information is left intact. The append only approach is necessary to support operations that require past database states. For example, a medical examiner investigating a malpractice complaint issues the query: “What were the known laboratory test results of a given patient at 10:30pm on December 12, 1993?” This information is crucial in deciding whether the attending physician provided a reasonable treatment given the available information at that time. Since the information may have been incomplete or even erroneous at the time, the treatment decision may seem wrong from a later observation point. Unlike


69

some other temporal models [ABN87] that employ a non-strict form of appendonly, we employ the append-only in the strictest fashion. Consequently, the data can be stored on WORM (write once read many) devices, in which no changes can be made to a state-element after the transaction that created it had committed. A state-element is a tuple of the form:2 hse-id, oid, value, tx , td , tv i • tx , td , tv designate the time types (as defined, tx and td are chronons and tv is a temporal element). • The value of a state-element designate a value assigned to the variable (e.g., Dr. Livingston), • A state-element includes a uniquely created system-wide identifier se-id. • oid designates the object-identity of the object the state-element is associated with. A state-element example is: Treatment= se-id=s9, oid=864545, value=antibiotic, tx =Dec 12 1993; 10:30pm, td =Dec 12 1993; 10:10pm, tv =[Dec 12 1993; 10:12pm, Dec 19 1993; 8:00pm)

A Bucket β is a set of state-elements having a well-defined semantics. In our model there are four types of buckets, as defined below. A variable δ is as a set of four buckets: hδ.data, δ.variable-SVS, δ.modify-control, δ.void-SEi The data bucket contains the state-elements whose values issue the history of the data associated with the variable δ. The rest of the buckets are control buckets. The variable-SVS contains state-elements whose value designate dynamic modifications of the SVS of the variable δ. The values consists of a pair hSVS, query-id i. The query-id designates a query to be activated for user defined SVS. The modify-control is a collection of state-elements whose value (changeable or frozen) designate the history of modifications to the variable’s modify control status. The void-SE is a collection of state-elements, whose value are state-elements that are being voided at the tv of the void state-element. An object α is represented as a set of variables: hα.object-id, α.class-ref, α.object-status, (α.p1 , . . . , α.pn )i. The data bucket of the object-id variable consists of a single unique state-element whose value designates the object identity. Its modify-control bucket consists of a single state-element with the value frozen. The class-ref is a variable that 2

Additional attributes of information about source, validity, accessibility, etc., can be added. These extensions are discussed in [GES94].

70


classifies an object to be an instance of a specific class. The SVS of this variable can be adjusted to the specific application’s assumption. If an object can be classified to multiple classes, then the SVS of class-ref is set to AND; if an object’s classification is fixed then the SVS is set to first value SVS. This is an example of using the SVS concept to support data model independence. The object-status variable’s values are stored in state-elements, with last value SVS, based on decision time. The possible values of this variables’ data are: active, suspended, disabled. See Section 4 for the exact definition. An object’s state is a set of all its variables’ states, i.e the entire collection of state-elements associated with this object. In the general case, the user may not be familiar with the object-identity, and instead identifies the object using an object identifier (primary key), which is a subset of the object’s state. For example, the underlined properties (Record-Number and Patient-Name) in Figure 1, are the object-identifiers. The level of granularity of temporal support was discussed in various papers (e.g. [SA86]). The common claim is that an attribute level support (which is equivalent to our interpretation of a state-element) reduces the space complexity relative to an object level support, because any change in any attribute results in the need to duplicate the entire object, also if the level of granularity required in the application is of an attribute, then an object level support increases the time complexity of obtaining information about the evolution of a single attribute. In any event, the concepts discussed in this paper are model independent, the concept of state-element can also be implemented on top of a model whose temporal granularity is in the object level, by creating an object to represent each state-element. 3.2

The Enhanced Schema Language

The schema language is the system designer’s tool to express static decisions about the data representation and semantics of updates and retrieval requests. The schema definition consists of classes and properties; each property may have characteristics that are common in existing schema languages (e.g., type, default, set of legal values, reference to other objects), and additional characteristics required to support the static definitions of extended requirements (SVS and modification control) By using keywords. The SVS keywords are: first, last, and, single, multi. The single and multi keywords designate the user defined SVS modes. An additional keyword query = qid is allowed with the single and multi SVS options, to designate the id of a query that is activated,3 whenever a query is issued that require the value of any variable that belongs to this property. qid is a query id. Example: if a property p has a single SVS mode associated with it, and the query associated with it is average [value], then anytime that any query attempts to retrieve any instance of p, the average of the values of all the state-elements valid at the specified valid time are returned. If none of the SVS keywords is specified 3

queries are represented as objects in the database.


71

then the default is last. If a single or multi SVS have been specified, and no query has been indicated, then the user is prompted at run-time for a selection query[GES94]. The modification control employs two keywords: frozen and changeable. The default is changeable. In Figure 4, we re-visit the schema presented in Figure 1 with the additional keywords. Since changeable is the default, it is omitted. Note that a nested structure can have a different SVS in the different

class= Medical-Record properties= Record-Number: last Patient: first; frozen Symptoms: all Signs: all Laboratory-Tests: all Laboratory-Feature first; frozen Test-Results: all; frozen Diagnosis: last Diagnosis-Id: first; frozen Disorders: multi Treatments: last Assigned-Physician: last class = Patient properties = Patient-Name: last Social-Security-Number: last Records: all Class = Assigned-Physician properties = Physician-Id: first; frozen Patients-Treated: single

Fig. 4. The revised partial schema of a medical database

levels; Diagnosis obeys the last value SVS, while its component Disorder has a multi SVS, consequently there can be only a single valid Diagnosis at each single chronon, nevertheless, within this Diagnosis multiple disorders may be simultaneously valid. In this example all the properties SVS were explicitly defined. To ease the system designer task, we suggest to use the following defaults that are compatible with update assumptions in conventional databases: 1. When the property is an object-id, the default is first; frozen value (this is an unchangeable default). 2. When the property is an object-status (see Section 3.3), the SVS is last value; changeable (this is an unchangeable default).

72


3. If the data type of the property is a set, a bag or a sequence, then the default is all; changeable. In this case insert means add a new element, while modify means change existing element(s). 4. If the data type of the property is an atomic data type, then the SVS is last; changeable. The extended schema language supports static definitions of the required options. These definitions affect all instances of the properties defined in the schema, unless a dynamic definition overrides it. The schema level is not entirely static, in the sense that a schema may evolve with time, although we assume that schema changes are not frequent. If a schema evolves, the valid schema is used. For a comprehensive discussion of the schema evolution issue the reader is referred to [GE98]. 3.3

The Update Operation Types

Update operation types are the linguistic primitives of a database update language. We express the required dynamic functionality by augmenting this set of primitives, hence, providing the user a uniform linguistic commands for the entire update process that include update of data, modification control at the object and variable levels, revision control and SVS definitions. Earlier works in the temporal database area were confined to the update operation types of insert, modify and delete while assigning to these operations a slightly different meaning than in conventional databases. For example, in several works (e.g., [EW90]) the difference between updates in non-temporal databases and in temporal databases is that modifications of an attribute’s value in the latter case retain the old value in addition to adding the new value. Others (e.g., HRDM [CC87], [McK88], [GE98] expanded the modify operation to include meta-data, thus allowing schema versioning, as well as data evolution. Our extended set includes the insert, modify, suspend, resume, disable, freeze, unfreeze, revise, set-SVS operations, as explained next. Insert: This operation creates a new object in the database. Along with the object insertion, the user may assign initial data values to some or all the object variables. For example, a new patient is registered at the emergency room. The database creates a new instance of the class Patient and initializes the values Patient-Name=Dan Cohen and Social-Security-Number=12345678. Modify: This operation adds new information about an existing object. For example, in Dec 12, 1993, 11:10pm, the results of a laboratory test of Dan Cohen caused a modification to the Diagnosis variable. Unlike non-temporal databases, the modify operation does not remove previous values. The modify operation can be applied to valid time chronons that are different than now, to an interval, or even to the entire database valid time line. Suspend: This operation establishes a reversible constraint that prevents any modification to the object in the given valid time, except for the object status


73

which is still changeable.4 For example, we can use the suspend operation to prevent the assignment of a treatment until the completion of appropriate tests. The suspend operation is a modify-control operation that sets an object to be unchangeable For example, when a physician is off-duty it is not possible to assign any record to him. Resume: This operation makes a suspended object changeable again. As in the insert operation, the resume operation may be used to set the values of some of the object’s variables. The resume operation is necessary to eliminate an unchangeable constraint of an object. Disable: An operation that establishes an irreversible constraint that makes the object logically deleted as of the beginning of the tv specified in the disable operation, and consequently prevents any modification to the specified object. For example, when a physician retires (assuming that a retired physician cannot practice again), the object representing this physician is disabled, however we may still want to investigate his past action, thus the history of records assigned to him is kept. The disable operation type has two major differences from the suspend operation type: • disable is irreversible;5 • disable has ontological implications, because it means that an object is logically deleted, i.e. ceases to belong to the application’s domain of discourse, while suspend is only a constraint that prevents updates. We use the term disable rather than delete since the history of the disabled object is preserved and there are no physical deletions. Freeze: This operation establishes a reversible constraint that prevents the modification of a variable (except in the case of revising erroneous values as explained below).6 For example, the laboratory results are measured values that should not be altered, thus the laboratory results’ variable is updated with a freeze constraint. The freeze operation is vital to the support of the unchangeable value at the variable level. Unfreeze: Any frozen data may be unfrozen. An unfreeze operation applied to a variable, designates the removal of the freezing constraint. Any modification to that variable is allowed from that time on. The unfreeze operation is required for the retraction of the unchangeable value constraint at the variable level. Revise: This operation “corrects” an erroneous value of a variable at certain collection of chronons. It tags values that currently exist in the database as false ones and adds a new correct value instead. The revise operation allows the replacement of a frozen value, marking the previous value as an erroneous one. The revise operation type is the means to implement the 4 5 6

The object status is required to remain changeable in order to reverse the suspend constraint. A Database Administrator (DBA) can use low level update primitives to “rescue” an object that was mistakenly disabled. The freeze and unfreeze operation at the variable level are similar to the suspend and resume at the object level. The different names are intended to avoid semantic overloading.

74


revision control requirement. The separation of the revise operation from the modify operation makes a semantic distinction between a change in the real world and a correction of a wrong value that was reported to the database. The user can instruct the database to include or exclude the revised values in retrieval operations. Set-SVS: The operation dynamically sets an SVS at the variable level. Data may only be changed in a temporal database by adding new objects or adding new state-elements to the variables of an existing object. The semantics of the update model are reflected in allowable new state-elements. A new stateelement is allowed to be inserted if it obeys some general syntactic rules, such as legal value in its valid time, and other rules that are contingent on the status of the object and the variable, the update operation type, and the SVS for this variable. Section 4 discusses the exact semantics of each update operation.

4

The Semantics of the Model’s Components

In this section, the formal update semantics of the various components of the model is presented. The validity semantics is presented in Section 4.1, the retrieval semantics is presented in Section 4.2, the update operation types are combined from a set of low-level primitives, presented in Section 4.3. Section 4.4 describes the semantics of the update operation types, followed by a discussion in Section 4.5. We shall use Figure 5 to demonstrate each of the functions and operations, presented in this section. The figure presents a set of state-elements, labeled according to the se-id, of an object that is an instance of the Patient class. The se-id are identified as snn . Each state-element is preceded by the name of the bucket it belongs to. 4.1

Validity Semantics

An object is considered to be active at chronons in which it is neither disabled nor suspended on the valid time axis. The state transition diagram of the objectstatus is presented in Figure 6. An arrow’s label represents the name of the update operation that changes the object’s status. Note that the disabled state is a terminal state, unlike suspended and active. The variable’s states are applicable only within the context of the active object status. An object is valid when it is not disabled. When an object is disabled, all its variables are considered to be invalid, except for the Object-Status that continues to be valid, because it provides information about the validity of an object. In the example, the object is invalid in [Aug 25 1994; 8:00am, ∞), which is the valid time of (s22). A disable operation sets an actual upper bound for the valid time (tv ) of all the state-elements associated with the disabled objects to be the starting point of the disabled status valid time interval. Thus, the chronon Aug 25 1994; 8:00am marks the upper bound for actual valid time of


75

all the state-elements associated with this object. Note that the recorded tv of the state-elements cannot be modified, however, the upper bound is reflected in the update and retrieval operations semantics. An object cannot be referenced by other objects, at a valid time chronon in which it is disabled. The collection of chronons in which an object α is active or valid is denoted by AR (α) or VR (α), designating the activity range and the validity range, respectively.

Object-id.data (s1) 864545, tx =Dec 12 1993; 10:02pm, td =Dec 12 1993; 10:00pm, tv =[Dec 12 1993; 10:00pm, ∞) Class-ref.data (s2) Patient, tx =Dec 12 1993; 10:02pm, td =Dec 12 1993; 10:00pm, tv =[Dec 12 1993; 10:00pm, ∞) Object-status.data (s3) Active, tx =Dec 12 1993; 10:02pm, td =Dec 12 1993; 10:00pm, tv =[Dec 12 1993; 10:00pm, ∞) Patient-Name.data (s4) Dan Cohen, tx =Dec 12 1993; 10:02pm, td =Dec 12 1993; 10:00pm, tv =[Dec 12 1993; 10:00pm, ∞) Social-Security-Number.data (s5) 12345678, tx =Dec 12 1993; 10:02pm, td =Dec 12 1993; 10:00pm, tv =[Dec 12 1993; 10:00pm, ∞) Social-Security-Number.Modify-Control (s6) frozen, tx =Dec 12 1993; 10:02pm, td =Dec 12 1993; 10:00pm, tv =[Dec 12 1993; 10:00pm, ∞) Record-Number.data (s7) 12345678-1, tx =Dec 12 1993; 10:02pm, td =Dec 12 1993; 10:00pm, tv =[Dec 12 1993; 10:00pm, ∞) Record-Number.Modify-Control (s8) frozen tx =Dec 12 1993; 10:02pm, td =Dec 12 1993; 10:00pm, tv =[Dec 12 1993; 10:00pm, ∞) Treatment.data (s9) antibiotic, tx =Dec 12 1993; 10:30pm, td =Dec 12 1993; 10:10pm, tv =[Dec 12 1993; 10:12pm, Dec 19 1993; 8:00pm) Disorder.data (s10) partial treatment, tx =Dec 12 1993; 11:30pm, td =Dec 12 1993; 11:15pm, tv =[Dec 12 1993; 11:15pm, ∞) Disorder.data (s11) brain abscess, tx =Dec 12 1993; 11:30pm, td =Dec 12 1993; 11:15pm, tv =[Dec 12 1993; 11:15pm, ∞) Disorder.data (s12) viral Meningitis, tx =Dec 12 1993; 11:30pm, td =Dec 12 1993; 11:15pm, tv =[Dec 12 1993; 11:15pm, ∞) Social-Security-Number.Void-Se (s13) s5, tx = Dec 12 1993; 11:33pm,td =Dec 12 1993;11:30pm, tv =[Dec 12 1993; 11:30pm, ∞) Social-Security-Number.data (s14) 02345678, tx =Dec 12 1993; 11:33pm, td =Dec 12 1993; 11:30pm, tv =[Dec 12 1993; 11:30pm, ∞) Disorder.data (s15) bacterial Meningitis, tx =Dec 12 1993; 11:35pm, td =Dec 12 1993; 10:05pm, tv =[Dec 12 1993; 10:05pm, ∞) Disorder.data (s16) viral Meningitis, tx =Dec 12 1993; 11:35pm, td =Dec 12 1993; 10:05pm, tv =[Dec 12 1993; 10:05pm, ∞) Disorder.data (s17) spontaneous Subarachnoid Hemorrhage, tx =Dec 12 1993; 11:35pm, td =Dec 12 1993; 10:05pm, tv =[Dec 12 1993; 10:05pm, ∞) Treatment.data (s18) acyclovir, tx =Dec 12 1993; 11:35pm, td =Dec 12 1993; 11:17pm, tv =[Dec 12 1993; 11:19pm, Dec 22 1993; 8:00am] Record-Number.modify-control (s19) changeable, tx =Dec 13 1993; 10:02pm, td =Dec 13 1993; 10:00pm, tv =[Dec 13 1993; 10:00pm, ∞) Object-Status.data (s20) Suspended, tx =Dec 19 1993; 8:02am, td =Dec 19 1993; 8:00am, tv =[Dec 19 1993; 8:00am, ∞) Object-Status.data (s21) Active, tx =Aug 24 1994; 12:03am, td =Aug 24 1994; 12:00am, tv =[Aug 24 1994; 12:00am, ∞) Object-Status.data (s22) Disabled, tx =Aug 25 1994; 8:05am, td =Aug 25 1994; 8:00am, tv =[Aug 25 1994; 8:00am, ∞) Object-Status.modify-control (s23) freeze, tx =Aug 25 1994; 8:15am, td =Aug 25 1994; 8:12am, tv =[Dec 19 1993; 8:00am, ∞)

Fig. 5. An example set of state-elements

A variable has a valid value only when its associated object is valid. The CSE function (Candidate State-Elements) returns the state-elements of a given variable which are valid at chronon t, i.e. the state-elements whose valid-time contains the chronon t. All these state-elements are candidates to be applicable, depending upon the SVS semantics.

76


Definition 41 CSE(var, t) is a function that returns the set of state-elements of the data bucket of the variable var that are possibly valid at a chronon t . A state-element se belongs to this set if it satisfies the following conditions: 1. t ∈ V R(se.oid) /* the object is valid at t */; 2. t ∈ tv (se) /* se is valid at t */; 3. ¬∃se0 | se.se-id = se0 .value ∧ t ∈ tv (se0 ) ∧ se0 ∈ var.void-se ∧ tx (se0 ) > tx (se) /* se is not voided at t. */; For example, CSE(α.Object-Status, Aug 24 1994; 12:00am)={s3, s20, s21}, where α is the object whose state-elements are presented in Figure 5.

Fig. 6. The state transition diagram of the object-status


77

The applicable state-elements among those included in the CSE set are determined according to the SVS semantics. For example: in the all SVS, the whole set is considered to be applicable. In the last value SVS, the applicable stateelement is a state-element whose td is the latest among the CSE set. td may be used when the variable belongs to the application domain. We denote the stateelement chosen by the last value SVS as ASE (Applicable State Element). We assume that each decision is made at a unique chronon, thus ASE is an atom. For example, ASE(α.Object-Status , Aug 24 1994; 12:00am)={s21}, where α is the object whose state-elements are presented in Figure 5. The frozen range of a variable is the range in which the variable is frozen. This is defined by the function FR (var). The function FR returns a collection of valid time chronons in which the applicable state-element is frozen, i.e., it cannot be altered. This function returns the unions of tv of all sate-element in var.modify-control, whose value is “frozen”. 4.2

Retrieval Semantics

The retrieval semantics is determined according to the variable’s SVS, the validity semantics and additional information that may be obtained from the user. The basic retrieval request is: find the value of a variable var at chronon t. By satisfying this retrieval request, many complex queries can be answered. The basic retrieval request has the following interpretation: 1. If the SVS is first value then the state-element with the earliest decision time among those returned by the CSE function is selected. 2. If the SVS is last value then the ASE function returns the value. 3. If the SVS is all then the set of all values in the CSE set is returned. 4. If the SVS is user defined then if a query is referred to at the schema or the variable level, the result of this query is returned, else the user is prompted for a selection query (in this case the SVS is deferred to run-time interpretation). An example of such query is td < t0 , which selects only the set of state-elements decided prior to t0 . This semantics can be implemented on top of various query languages such as TOOSQL [RS91] that also support retrieval from various observation points (an answer to the query as-of to ) that restricts the selection of values to those whose tx < to . The following examples illustrate the retrieval semantics (all of the following queries were issued on December 13, 1993). 1. Query: What is the disorder of Dan Cohen? Answer: The possible Disorders of Dan Cohen are partial treatment, brain abscess, and viral Meningitis. The answer is based on state-elements (s10)-(s12). Since Diagnosis has a last value SVS, the diagnosis with the highest decision time (td ) is selected by the ASE function. The Disorders within a Diagnosis have a user defined SVS, thus the answer is interpreted as possible disorders.

78


2. Query: What was the known Social-Security-Number of Dan Cohen at 10:30pm on December 12, 1993? Answer: The known Social-Security-Number of Dan Cohen on December 12, 1993 at 10:30pm is 12345678. An intelligent query language can point out that the value was erroneous, and was revised to 02345678 on December 12 1993, at 11:33pm. 4.3

Low-level Update Primitives

This section presents the low-level primitives the system use to update the database. These primitives are the building constructs of the update operation types and are not accessible to the user. However, the DBA may use these primitives in handling exceptional situations. The primitives are defined at three different levels: state-element primitives, variable primitives and object primitives. Throughout this section, we use the symbols ⊕ and ⊗. The symbol ⊕ denotes an application of an update operation to a database. The symbol ⊗ is a separator between two successive operations; in case of an abort as part of one of the operations, subsequent operations are not performed. We also use two constants, now designates the chronon at which an operation is being performed, ∞ designates an unlimited known upper bound, for example a state-element having a valid-time interval of [now, ∞] is considered to be valid starting from the time it was inserted, and valid at any later chronon, unless voided or overridden by other value. State-element Level Primitives We introduce the basic primitive of the model: Create-se. Prior to its introduction, we introduce three system functions that are used by it. legal-temporal(tv , td ) is a boolean function that returns “true” if the predetermined temporal constraints are satisfied. These temporal constraints are: 1. tv is a legal temporal element (not empty, contains non intersecting interval); 2. td is a legal chronon (according to the application’s granularity); 3. td ≤ now (now is the current chronon, read from the system’s clock). legal-type(val, p) is a boolean function that returns “true” only if val is in the domain of the property p. associate(se, α.p.β) is a function that associates the state-element with a the bucket β in a variable of the property p of the object α. α denotes the object as identified by its identifier (primary key), this is translated to the OID using a translation function. Create-se: creates a new state-element. Syntax: create-se (oid, p, β, val, τd , τv ). Semantics: DB ⊕ create-se (oid, p, β, val, τd , τv ) ≡ (¬ legal-temporal(τv , τd ) ∨ ¬ legal-type(val, p) )→ abort ⊗


79

DB0 :=DB ∪{se} | se = (se-id, oid, val, τx , τd , τv ) ∧se-id=generate-se-id() ⊗ associate(se, α.p.β) | α.Object-id = oid. This primitive adds a single state-element se to the bucket β of a variable α.p (the instance of the property p in the object α), after checking if certain integrity constraints are satisfied. It consists of two phases: adding the stateelement to the database (each state-element is a separate entity with a unique identity in the database), and associating it with a variable and a bucket. DB0 is the new database state. se-id and τx are generated by the system; se-id is generated according to the object-identifiers’ generation conventions [CK86]; the τx (transaction time) is determined at commit time. For example: The operation create-se(oid=864545, p=Patient-Name, β=data, val=Dan Cohen, τd =Dec 12 1993; 10:00pm, τv =[Dec 12 1993; 10:00pm, ∞)) applied in a transaction that committed on Dec 12 1993; 10:02pm, resulted in the state-element (s4) in Figure 5. Variable Level Update Primitives This section presents the semantics of the variable level primitives. To provide upward compatibility for non-temporal databases and to provide a shortcut for the standard cases and ease the use, omission of the time values is allowed, and thus a default should be provided. 0 We define τd to be: now if τd =nil τd0 := τd otherwise That is, τd0 is assigned a default value of now (the current chronon read from the system’s clock of the transaction start time), only if no value has been provided for τd . This default can be adjusted by the DBA at the application initiation, to be either the start time of the transaction, or to be left as a null value, and be interpreted at retrieval time according to a user-requested interpretation (e.g., tx whose value could not be used before commit time). Set-var assigns a new value to a variable’s data. Syntax: set-var (oid, p, val, τd , τv ) Semantics: set-var (oid, p, val, τd , τv ) ≡ create-se(oid, p, data, val, τd0 , τv0 ) | α.Object-id = oid ∧ [now, ∞) ∩ AR(α) − FR(α.p) if τv =nil τv0 := otherwise τv ∩ AR(α) − FR(α.p) The default value for τv , in this primitive, is [now, ∞). This default has been used by other researchers (e.g., [BZ82]) assuming that the value was not valid from -∞. This default is a natural extension of the update logic in conventional databases, where a new value replaces an older one as of the time it is inserted to the database. The functions FR and AR have been defined in Section 4.1. AR returns the set of chronons in which a given object is active, and FR returns the chronons in which a given variable is frozen. The actual valid time (τv0 ) is derived by intersecting τv with the times in which the variable can be modified AR(α) − F R(α.p) (the modifiable range). The modification of the valid time provided by the user, stems from considering a temporal database as a set

80


of many conventional databases, each of which is valid in a single chronon. Consequently, an update that affects a valid time interval in a temporal database is, in fact, a set of several independent updates, where each update can either succeed or fail in a given valid time chronon. A similar approach, in different contexts, was taken in other works as well (e.g., [Sno87]). For example, the operation set-var (oid=864545, p= Social-Security-Number, val=02345678, τd =nil, τv =nil), applied to the database on Dec 12, 1993; 11:30pm, results in the creation of state-element (s14) in Figure 5. Freeze-var freezes a variable. Syntax: freeze-var (oid, p, τd , τv ) Semantics: freeze-var (oid, p, τd , τv ) ≡ create-se(oid, p, modify-control,“frozen”, τd0 , τv0 ) | α.Object-id = oid ∧ [now, ∞) ∩ AR(α) if τv =nil τv0 := otherwise τv ∩ AR(α) The default value for τv in this primitive is [now, ∞). The actual valid time (τv0 ) is derived by intersecting τv with the activity range of the object. For example, the operation freeze-var (oid=864545, p= Social-SecurityNumber, τd =nil, τv =nil), applied to the database on Dec 12, 1993; 10:00pm, results in the creation of state-element (s6) in Figure 5. Unfreeze-var unfreezes a given variable. Syntax: unfreeze-var (oid, p, τd , τv ) Semantics: unfreeze-var (oid, p, τd , τv ) ≡ create-se(oid, p, modify-control, “changeable”, τd0 , τv0 ) | α.Object-id = oid ∧ [now, ∞) ∩ AR(α) if τv =nil τv0 := otherwise τv ∩ AR(α) τv0 is not calculated with respect to the frozen range of the variable. Thus, an unfreeze-var operation can override an earlier freeze decision. For example, the operation unfreeze-var (oid=864545, p= Record-Number, τd =nil, τv =nil), that was applied to the database on Dec 13 1993; 10:02pm, resulted in the generation of state-element (s19) in Figure 5.


81

Object Level Update Primitives Create-obj: creates a new object that is an instance of a given class. Syntax: oid := create-obj (class) Semantics: oid := create-obj (c) ≡ oid := generate-obj-id() ⊗ create-se-oid (oid) ⊗ create-se-class-ref (c, oid). create-se-oid(oid) ≡ create-se (oid, p=“object-id”, data, oid, τd , τv )| τd =now ∧ τv =[now, ∞) create-se-class-ref (c, oid) ≡ create-se (oid, p=“class-ref”,data, c, τd , τv ) | τd =now ∧ τv =[now, ∞). The create-obj primitive creates two new state-elements. The first stateelement designates an object identity; the object identity is generated by the database and is returned as a result of applying the generate-obj-id builtin function. The object identity is a frozen state-element, the frozen status is protected by a meta-data integrity constraint that prevents the change of its status. The second state-element is a reference to the class c that is given as an argument using the object-id that was created earlier. The values of the time types of both state-elements are generated by the system and represent the systems defaults. They do not represent the object’s validtime activespan, i.e., the time during which the object exists in the modeled reality. The activespan of an object is explicitly controlled by the user, and is associated with the Object-Status variable. For example, the operation create-obj (Patient), that was applied to the database on Dec 12 1993; 10:00pm resulted in the generation of state-elements (s1) and (s2) as presented in Figure 5 and returns the value 864545. Set-obj-status changes the object status in a given valid-time temporal element. Possible values of the object status are Active, Suspended and Disabled. Object-Status is a special variable that cannot be handled by regular variable operations, thus it has its own set of operations that includes Set-obj-status to set the value, and freeze-obj-status and unfreeze-obj-status to freeze and unfreeze this status, respectively. Syntax: set-obj-status (oid, sval, τd , τv ) Semantics: set-obj-status (oid, sval, τd , τv ) ≡ create-se (oid, “object-status”, data, sval, τd0 , τv0 ) | α.Object-id = oid ∧ sval ∈{“active”, “suspended”, “disabled”} ∧ [now, ∞) − FR(α.Object-Status) if τv =nil τv0 = otherwise τv − FR(α.Object-Status) τv0 has a default value of the temporal element [now, ∞). τv0 and τd0 determine the object’s valid-time activespan. For example, the operation set-obj-status (oid=864545, sval=“Active”, τd =nil, τv =nil), applied to the database on Dec 12 1993; 10:00pm, results in the generation of state-element (s3) in Figure 5. Freeze-obj-status freezes the object status in a given interval. Syntax: freeze-obj-status (oid, td , tv )

82


Semantics: freeze-obj-status (oid, τd , τv ) ≡ freeze-var (oid, “Object-Status”, τd0 , τv0 ). τv0 has a default value of the temporal element [now, ∞). τv0 and τd0 are used to determine the object’s valid-time activespan. For example, the operation freeze-obj-status (oid=864545, td =nil, tv = [Dec 12 1993; 10:00pm, ∞), applied to the database on Aug 25 1994; 8:15am, resulted in the generation of state-element (s23) in Figure 5. This operation freezes the object status retroactively during its entire activespan. Unfreeze-obj-status Unfreezes the variable Object-Status. Syntax: unfreeze-obj-status (oid, τd , τv ) Semantics: unfreeze-obj-status (oid, τd , τv ) ≡ unfreeze-var (oid, “Object-Status”, τd , τv ). Disable-Obj changes the object status to Disabled in the interval [ts , ∞), where ts is the start time associated with the valid time, given as a parameter by the user. Only the start time of the interval is used since this status is final in the sense that the object can never be revived again. Consequently, the end chronon is set to ∞. Syntax: disable-obj (oid, τd , τv ) Semantics: disable-obj (oid, τd , τv ) ≡ α.Object-id = oid ∧ [now, ∞) − F R(α.Object-Status) if τv =nil 0 ⊗ τv := [ts , ∞) − F R(α.Object-Status) otherwise τv0 6= [t0s , ∞) → abort ⊗ 0 0 Set-obj-status (oid, “disabled”, τd , τv ) τv0 receives a default value of [now, ∞). The disable-obj operation assumes that the object is disabled as of a certain chronon to infinity. If the object status is frozen at some chronon during the interval of the disable-obj operation, then the object-status cannot be changed in this chronon. Thus, the disable-obj operation cannot be completed and the transaction should be either aborted or treated as an exception. For example, the result of the operation disable-obj (oid=864545, τd =nil, τv =nil), applied to the database on Aug 25 1994; 8:05am, is the same as the freeze-obj operation, as given above. In the general case, the disable-obj operation is not reversible. However, in exceptional cases, an authorized DBA can use the unfreeze-obj-status to reverse the disable-obj operation and “rescue” the object.

4.4

Update Operation Types

The update operation types that have been discussed in Section 2 are defined using the primitives of Section 4.3. These update operation types are the only ones that are accessible to users.


83

Insert : Syntax: insert (c, τdl , τvl , {ν1 , . . . , νn }) | νi =(pi , vali , τdi , τvi ). Semantics: insert (c, τdl , τvl , {ν1 , . . ., νn } | νi =(pi , vali , τdi , τvi ) ≡ (exists-identifier (c, {ν1 , . . ., νn }) → abort ⊗ oid := create-obj (c) ⊗ set-obj-status (oid, “active”, τdl , τvl ) ⊗ set-var (oid, p1 , val1 , τd1 , τv1 ) ⊗ . . . ⊗ set-var (oid, pn , valn τdn , τvn ) exists-identifier is a function, it takes as an argument a class id and the set of input variables, according to the class definition determines the object identifier (primary key) and checks if there exists an instance of the class c with the given identifier. If this function returns true then the transaction should abort. oid is set to be the new object’s id, using the create-obj operation. The insert operation creates the object, using create-obj, sets its status to be active, using set-obj-status and then updates its variables, using set-var. τdl and τvl are the decision and valid times of the object’s valid-time activespan. i.e., the temporal element in which the object is active. The generated oid is returned to the user. Example: A new patient is inserted to the database. The following operation provides the patient’s name. insert (c=Patient, τdl =Dec 12 1993; 10:00pm, τvl =[Dec 12 1993; 10:00pm, ∞) {ν1 =(p1 =Patient-Name, val1 =Dan Cohen, τd1 =nil, τv1 =[Dec 12 1993; 10:00pm, ∞))}) (s1)-(s4) of Figure 5 are the state-elements added to the database as a result of this operation. Modify : Syntax: modify (c, obj, τdl , τvl , {ν1 , . . . , νn }) | νi = (pi , vali , τdi , τvi ). Semantics: modify (c, obj, τdl , τvl , {ν1 , . . ., νn } | νi =(pi , vali , τdi , τvi )) ≡ oid := identify-obj (c, obj) ⊗ (oid = nil) → abort ⊗ (τvl 6= nil) → set-obj-status (oid, “active”, τdl , τvl ) ⊗ set-var (oid, p1 , val1 , τd1 , τv1 ) ⊗ . . . ⊗ set-var (oid, pn , valn , τdn , τvn ) The modify operation retrieves the object identity, based on an identifier given by the user, using identify-obj. If the user assigns a value to the tvl , then it resets the object’s valid-time activespan. Finally, it updates its variables, using set-var. c denotes the class-id of the object. identify-obj is a function that converts object-identifiers (primary keys) to object-identities (surrogates). If the sought object does not exist in the database, then the modify operation cannot be completed and the transaction should be either aborted or treated as an exception. If there is more

84


than one qualifying object with the same object-identifier, then the user is prompted to decide which object is the required one. Example: The operation modify (c=Medical-Record, obj=12345678-1, τvl =nil, τdl =nil, {ν1 =(p1 =Disorder, val1 =partial treatment7 , τd1 =Dec 12 1993; 11:15pm, τv1 =[Dec 12 1993; 11:15pm, ∞))}) changes one of the disorder’s alternatives in the Diagnosis. It generates the state-element (s10) in Figure 5. Suspend : Syntax: suspend (c, obj, τdl , τvl ). Semantics: suspend (c, obj, τdl , τvl ) ≡ oid := identify-obj (c, obj) ⊗ (oid = nil) → abort ⊗ set-obj-status (oid, “suspended”, τdl , τvl ). The suspend operation generates a new state-element of the variable ObjectStatus with the value “suspended,” using set-obj-status. The operation uses the object identity that is given by the identify-obj function. For example, the following operation suspends the patient Dan Cohen as an active patient in the emergency room. As a result, state-element (s20) of Figure 5 is added to the database. suspend (c=Patient, obj=Dan Cohen, τdl =Dec 19 1993; 8:00am, τvl =[Dec 19 1993; 8:00am, ∞)). Resume : Syntax: resume (c, obj, τdl , τvl , {ν1 , . . . , νn }) | νi = (pi , vali , τdi , τvi ). Semantics: resume (c, obj, τdl , τvl , {ν1 , . . . , νn } | νi = (pi , vali , τdi , τvi ) ≡ oid := identify-obj (c, obj) ⊗ (oid = nil) → abort ⊗ set-obj-status (oid, “active”, τdl , τvl ) ⊗ set-var (oid, p1 , val1 , τd1 , τv1 ) ⊗ . . . ⊗ set-var (oid, pn , valn , τdn , τvn ) For example, the following operation resumes the patient Dan Cohen as an active patient when he is admitted again to the emergency room. resume (c=Patient, obj=Dan Cohen, τdl =Aug 24 1994; 12:00am, τvl =[Aug 24 1994; 12:00am, ∞)) As a result, state-element (s21) of Figure 5 is added to the database. Disable : Syntax: disable (c, obj, τd , τv ) Semantics: disable (c, obj, τd , τv ) ≡ oid := identify-obj (c, obj) ⊗ 7

The medical term partial treatment refers to cases in which a treatment has not been completed, for example: a patient has failed to take the entire quantity of antibiotics assigned to him.


85

(oid = nil) → abort ⊗ disable-obj (oid, τd , τv ) In non-temporal databases, when an object is deleted, its information is removed from the database. In temporal databases, historical information is kept and the user can retrieve the contents of each object that was disabled, during its activity range. Moreover, modifications to the state of the object at times before it was disabled are allowed. For example, it is possible to retroactively update a medical record in the period it was open, during the time in which the record is already closed. The semantics of the disable operation is compatible with the “real world semantics,” since it is possible that new information is discovered after an object is no longer in the active domain. Freeze : Syntax: freeze (c, obj, τdl , τvl , {ν1 , . . . , νn }) | νi = (pi , τdi , τvi ). Semantics: freeze (c, obj, τdl , τvl , {ν1 , . . ., νn } | νi =(pi , τdi , τvi ) ≡ oid := identify-obj (c, obj) ⊗ (oid = nil) → abort ⊗ (τvl 6= nil) → freeze-obj-status (oid, τdl , τvl ) ⊗ freeze-var (oid, p1 , τd1 , τv1 ) ⊗ . . . ⊗ freeze-var (oid, pn , τdn , τvn ) A freeze operation can be applied to a single chronon, to an interval or to the entire variable history. This operation can be applied to non-temporal databases as well, such that a freeze operation always refers to the current state. For example, the following operation freezes the Social-Security-Number of Dan Cohen freeze ( c=Patient, obj=Dan Cohen, tdl =nil, tvl =nil, { v1 = ( p1 =SocialSecurity-Number, td1 =Dec 12 1993; 10:00pm, tv1 =[Dec 12 1993; 10:00pm, ∞))}) As a result, state-element (s6) of Figure 5 is added to the database. Unfreeze : Syntax: unfreeze (c, obj, τdl , τvl , {ν1 , . . . , νn }) | νi = (pi , τdi , τvi ). Semantics: unfreeze (c, obj, τdl , τvl , {ν1 , . . ., νn }) | νi =(pi , τdi , τvi ) ≡ oid := identify-obj (c, obj) ⊗ (oid = nil) → abort ⊗ (τvl 6= nil) → unfreeze-obj-status (oid, τdl , τvl ) ⊗ unfreeze-var (oid, p1 , τd1 , τv1 ) ⊗ . . . ⊗ unfreeze-var (oid, pn , τdn , τvn ) An unfreeze operation eliminates the “freeze” constraint (if it exists) for the specified valid time. For example, the following operation unfreezes the Record-Number variable. unfreeze (c=Medical-Record, obj=12345678-1, τdl =nil, τvl =nil, {ν1 =(p1 =Record-Number, τd1 =Dec 13 1993; 10:00pm, τv1 =[Dec 13 1993; 10:00pm, ∞))}) As a result, state-element (s19) of Figure 5 is added to the database.

86


Revise : Syntax: revise (c, obj, τdl , τvl , {γ1 , . . . , γn }) | γi = (νi , sqi ), νi = (pi , vali , τdi , τvi ) Semantics: revise (c, obj, τdl , τvl , {γ1 , . . . , γn }) | γi = (νi , sqi ), νi = (pi , vali , τdi , τvi ) ≡ oid := identify-obj (c, obj) ⊗ (oid = nil) → abort ⊗ (τvl 6= nil) → set-obj-status (oid, “active”, τdl , τvl ) ⊗ val1 6= nil → modify (c, obj, τdl , τvl , {ν1 , . . . , νn })⊗ ∀sei ∈ sq1 ∪ . . . ∪ sqn : create-se(oid, pi , void-SE, sei , τdi , τvi ). The revise operation replaces existing values with new ones, voiding the old values. Each revised value may cause the revision of multiple state-elements, selected by a selection query sqi . A revise operation can affect more than one state-elements in the following cases: 1. The valid time of the correction covers the valid time of several existing state-elements. 2. A change from a multi-valued semantics to a unique value semantics requires to void several state-elements. The revise operation has two parts. The first part adds state-elements with new values if there is at least one value that is not nil. If this part is not activated, then the state-elements are voided without replacing them with new values; the second part uses a selection query sqi for each revised value, to locate the state-elements that should be voided, and voids these stateelements, or any part of their validity time that is specified by the τv variable. For example, the operation revise ( c=Patient, obj=Dan Cohen, { ν1 = ( p1 = Social-Security-Number, val1 =02345678, τd1 =Dec 12 1993; 11:30pm, τv1 =[Dec 12 1993; 11:30pm, ∞), sq1 =select the state-element with value=12345678) applied in a transaction that committed at Dec 12 1993; 11:33pm, resulted in the creation state-elements (s13), (s14) in Figure 5. The revise operation allows the replacement of a frozen value, marking it as an erroneous one. The revise operation is necessary, along with the modify operation, in order to make a semantic distinction between a change in the real world and between a correction of a wrong value that was reported to the database. The default retrieve operations exclude revised values in retrieval operations (this default can be overridden). Additional use of the revise operation is to void state-elements without replacing them. In this case, νi = nil and only the second part of the revise operation is applied. Set-SVS : Syntax: set-SVS (c, obj, τdl , τvl , {ν1 , . . . , νn }) | νi = (pi , svsi , qidi , τdi , τvi ) semantics: set-SVS (c, obj, τdl , τvl , {ν1 , . . . , νn }) | νi = (pi , svsi , qidi , τdi , τvi ) ≡ oid := identify-obj (c, obj) ⊗ (oid = nil) → abort ⊗ (τvl 6= nil) → set-obj-status(oid,“active”,τdl , τvl ) ⊗ create-se (oid, p1 , variable-SVS, (svs1 , qid1 ), τd1 , τv1 ) ⊗, . . . , ⊗ create-se (oid, p1 , variable-SVS, (svs1 , qidn ), τdn , τvn )


87

The set-SVS command sets the SVS interpretation of one or more variables that belong to the same object. The interpretation consists of two parts: the SVS keyword (first, last, all, single, multi) and a query id. A query id is meaningful only when the single or multi keywords are used, otherwise it is ignored. 4.5

Discussion

The update operation types are used as a uniform linguistic abstraction that supports any type of database update, for the data and control parts. The Insert operation type creates a new object, it can also update the data bucket of the variables in the created object. The Modify operation updates the data bucket of the variables in an existing object. Their semantics are an extended version of the semantics of these operation types in regular databases. The extended semantics follow the temporal database’s structure. These operations are implemented using the set-var operation. The Suspend, Resume, and Disable operation are operations that affect the object-status. The Resume operation can also be used to update the data bucket of the variables that belong to the object it resumes. The Freeze and Unfreeze update the modify-control buckets of variables that belong to a given object, they use the freeze-var and unfreezevar operations. The Revise operation updates the data bucket of the revised variable, and marks the revised state-elements in the Void-SE bucket. Note that the Revise semantics does not use set-var, but instead it uses state-elements operations directly. This is done to bypass the frozen constraint, if exists, because it is possible to revise any state-element, even if it’s variable is frozen. The Set-SVS sets SVS interpretation that overrides the static interpretation in the variable’s level. This set of update operation types is a minimal set, but it is not necessarily the set that is appropriate for each application. It is possible to eliminate certain operations (i.e., not allow the Revise operation, in applications that do not support revisions) or to construct new operations using the low level primitives. For example, the combination of Modify and Freeze in a single operation would enable to update values and freeze them using a single linguistic primitive. A formal definition of a new update operation type can be based on the predefined low-level primitives and should consider the following issues: 1. Whether the update operation type is applied with respect to the frozen range of the variable, the changeable range of the variable, or both? 2. What are the appropriate defaults for tv and td ? 3. What are the constraints whose violation lead to a transaction failure?

5

Implementation Issues

Several implementation issues are discussed in this section. Section 5.1 discusses alternatives for implementing the additional functionalities. Section 5.2 discusses

88


the implementation of decision time as a primitive, Section 5.3 discusses the implementation in a temporal relational model, Section 5.4 discusses the mapping of the proposed model to TSQL2, and proposes some changes to TSQL2 in order to facilitate the support for the extended functionality.

5.1

The Implementation Alternatives

The functionality discussed in this paper does not exist in TSQL2 or in any other temporal language, at the primitive level. The implementation alternatives are: • using the proposed primitives as system design tools, using the existing database primitives at the database implementation level; • developing a wrapper based on the temporal infrastructure, whose primitives are compatible with the primitives presented in this paper; • devising a separate implementation model bypassing the temporal database infrastructure, for the use of applications that require the extended functionalities. The first alternative cannot satisfy this study’s objectives; the use of the existing primitives would make writing programs that satisfy these extended functionalities tedious, hard to verify, and ad-hoc. The third alternative of devising a new implementation model is consistent with our objectives and can result in optimized performance. The construction of a standard model that combines the desired object oriented and temporal features is a major task for future research and development in the temporal database community in general, and we intend to base our further implementation on such a model. Our current prototype implementation is based on a relational database, using a subset of TSQL2. In general, we propose to implement our model as a wrapper on top of an TSQL2 implementation.

5.2

The Implementation of the Decision Time Primitive

The following discussion is relevant for applications that require the decision time functionality. We argued that the decision time in some applications is indispensable in determining the correct order of real-world events, and in making decision analysis inferences. The implementation choices are whether to implement decision time as an additional time dimension, or try to achieve this functionality in another way. The decision time has two major impacts on the model’s representation and semantics: • It adds an additional chronon to each state-element; • The function ASE that selects the valid value according to the last value SVS may employ the decision time and not the transaction time to determine the last value (the same may apply for first value SVS).


89

It is possible to emulate the decision time functionality, without using an explicit time type, by adding objects that designate decisions,8 and using the beginning of the tv interval of their variables to denote decision time. Such a solution is proposed in [OS95], and it complies with the desire not to add more primitives. However, we argue that this requirement is general, and important enough to have a direct representation. Using decision-time objects is too cumbersome, even at the logical level. • From space complexity point of view, adding the decision time to the stateelement level requires substantially less space than the creation of a redundant object; • From time complexity point of view, having the decision time available at the state-element level is less expensive than joining the state-element and the decision-related object; • From the development and maintenance point of view, it is clearer to the user since the decision-related object is not a concrete object in the application’s domain. This analysis leads to the conclusion that the support of decision time as a model primitive is cost effective in cases that this functionality is required. If the decision time functionality is not required, we may eliminate the space overhead, by supporting an initialization parameter that eliminates the decision time. In this case, the decision time support is an optional feature selected at the initialization time of the application’s schema. If decision time is not selected, then no space is saved for td at the state-element’s level and the transaction time (tx ) replaces the decision time (td ) in the interpretation of the ASE retrieval function. An existing application can be converted to include decision time, such that the value of tx will be used for any missing value of td . 5.3

Implementation of the Model

The update functionality presented in this paper is “data model independent” in the sense that it can be implemented on various data models. Although a natural implementation is in an object-oriented model, a standard object oriented temporal data model does not exist. We therefore restrict this discussion to the relational model and TSQL2. The structure defined in this paper can be trivially mapped into the nested relational model [RKS88] that has been suggested in [Tan86] to be a basis for temporal database implementation. Mapping the data structure into a “flat” relational model requires the use of normalization rules. The implementation in the temporal model is not unique. A possible implementation can use universal relations as discussed in [N+ 87]. Another possible implementation uses the ENF (Extension Normal Form), which is an extension of the TNF (Time Normal Form) [NA89], as follows. 8

Recall that ‘decision’ is a generic reference to the real-world event that led to the database transaction. In many applications it represents an actual decision.

90


Each relation designates a set of synchronous attributes, which are attributes that have common state-element’s additional information (td , tv , etc.) at any chronon. We extend the definition of TNF to include all the additional information in a state-element, rather then just the tv that represents an atomic combination of property and bucket consists of values and the state-element’s additional information (without the revised-se component). A state-element of a set property is represented by several tuples with the same se-id. Each tuple is identified by both the se-id and its value. The implementation using the ENF blurs the original schema structure. Thus, the relationship among a class and its properties is represented using an additional relation for each bucket. Another relation stores the classification of objects into classes. Each relation represents a single combination of property and bucket, with the state-element’s additional information. Note that in this particular example, all attributes are asynchronous. Object-id-data, Class-ref-data, and Object-status-data are system variables. Treatment-Data is a user defined Property. The creation of a state-element involves the addition of new tuple(s) to the appropriate property-bucket relation. This representation is restricted since the tv can be an interval but not a temporal element. To eliminate this restriction, a separate relation for the tv element should be created, identified by the state-element-id and the interval values. Redundant timestamping exist in tx when multiple state-elements are updated in the same transaction, in tv , when multiple state-elements have the same valid time, and in td , when multiple state-elements have the same decision times. Furthermore, there can be an overlap among all of them, e.g., tx = td = ts (tv ). A possible space optimization feature is the enumeration of chronons and its use instead of the full representation; this, however, requires a conversion table from the enumeration to time-stamps, increasing the retrieval time. 5.4

Supporting The Extended Update Functionality With TSQL2

In this section we present a mapping of the update functionality to TSQL2, and the additional clauses required to augment TSQL2 Mapping to TSQL2 TSQL2 supports a bitemporal database environment, and uses temporal clauses as an extension of SQL-92. It is sufficient to map the create-se operation. The rest of the operations are translated to create-se as shown in Section 3. For the translation we assume that we have an underlying ENF bitemporal relational database with TSQL2 embedded within a host language that controls integrity constraints and aborts the transaction when necessary. create-se(oid, p, β, val, τd , τv , s)≡INSERT INTO p-β VALUES (NEW, val, oid, τd , s) VALID TIMESTAMP τv


91

oid is the object id. val is the set of all values that have a common stateelement’s additional information (e.g., tv , td , etc.) s can be either “changeable” or “frozen.” Since tv is part of the temporal infrastructure schema, it is updated using the TSQL2 feature VALID TIMESTAMP and not as part of the VALUES clause. The retrieval selections CSE and ASE can be easily expressed by TSQL2 queries as well. A Proposal to Augment TSQL2 In order to support that functionality described in this paper in a convenient way, the following features should be supported as a primitive level, this can be done as a shell on top of TSQL2[S+ 94], or as direct extension to the TSQL2 language. 1. A mechanism for handling simultaneous values is required. This mechanism should include new functions and defaults to support the retrieval of simultaneous values. These functions consist of the CSE and ASE functions. 2. A third time type (decision time) that reflects the correct order of occurrences in the modeled reality is needed. 3. A mechanism for freezing object’s values and enforcing freezing constraints should be added. 4. A correction operation, that is semantically distinct from modification, should be introduced. 5. Clauses that represent the functionality of the update operation types would make the update language more powerful. We suggest to include the following new clauses in the extension of TSQL2. SUSPEND p: This clause would have a similar effect as the suspend primitive presented in Section 4. The disable primitive can use the semantics of the DELETE clause of TSQL2. The use of delete as an alias to disable is necessary to guarantee the compatibility of TSQL2 with SQL-92. It should be noted that TSQL2 permits changes to existing tuples even after the transaction commits. This can prevent the ability to restore all past states of the database. For example, a DELETE operation in a bitemporal database changes the tx according to the parameter given in this clause. Since deletions can be proactive and retroactive as well as current, the time of issuing the DELETE operation is not known after the modification. Consequently, queries with a viewpoint earlier than the time of change cannot be answered. RESUME p: This clause would have a similar effect as the resume operation type that was presented in Section 4. The clause: RESUME p VALID TIMESTAMP τv would effect an existing tuple, and change its validity interval. FREEZE: This clause would have a similar effect as the freezing operation type, as presented in Section 4. For example, FREEZE VARIABLES (var1 , . . ., varn ) OF p VALID TIMESTAMP τv

92


The FREEZE clause would freeze a set of a variables in a given valid time interval, but it can be effective only when it is combined with a mechanism that enforces the frozen range of a variable. UNFREEZE: This clause would have a similar effect as the unfreeze operation type that was presented in Section 4. For example, the clause: UNFREEZE VARIABLES (var1 , . . ., varn ) OF p VALID TIMESTAMP τv would unfreeze a set of variables, in a given valid time interval. REVISE...WITH: This clause would have a similar effect as the revise operation type that was presented in Section 4. For example, the clause: REVISE se WITH VALUE (val) would revise the state-element se with the value with the value val. SET-SVS This clause would have a similar effect as the set-svs operation type that was presented in Section 4. For example, the clause: SET-SVS var WITH VALUE (val) USING QUERY (qid) would set the SVS value and associated query of var.

6

Conclusion

This work extends the temporal database functionality to accommodate complex applications. These extensions are a step in the direction of bridging the gap between temporal database capability and the needs of real-life applications. The results presented in this paper support a model that support flexible interpretation of simultaneous values semantics as an integral part of a temporal database. This functionality facilitates the database modeling and manipulation of real-world concepts. The main contribution of this paper is in the construction of a model that supports extended update features in both the schema level and update operation levels. The features include: simultaneous values semantics, modify control and revision control, all of them are required due to the simultaneous values capability of temporal databases. The case study has exemplified the need for such a model in a decision analysis system, however these functionalities can be used for other types of system. For example, it can be used to tailor a data model’s capabilities according to application’s needs, by adjusting the meta-data property class-ref property single or multiple classification of an object and fixed or variable classification of objects. The model presented in this paper includes a third time type called decision time that maintains the correct order of events in the modeled reality. This time type is essential for many types of applications, and is optionally supported as a model primitive. The system designer can choose if this feature is included, during the application’s initialization time.


93

The proposed update functionality is data model independent, and thus it can be designed as a shell on top of existing data models. A mapping of the update primitives to TSQL2 was described, as well as a list of extensions to TSQL2 required for a more complete temporal database functionality. A prototype of this system is currently being developed. This prototype is to be used in a simulation project in a hospital’s training center. Further research will deal with data modeling implementation on top of an object oriented model, the impact of simultaneous values on schema versioning, and investigation of applying research that has been done in the artificial intelligence area about possible world semantics and belief revision to extend this model.

Acknowledgments The case study was established with the help of Gilad Rosenberg M.D. We thank the reviewers for many helpful comments.

References A+ 79.

ABN87.

AKG91. Ari86. Bra78. BZ82. CC87.

CK86. CK94. CT85.

EGS92.

V. De Antonellis et al. Extending the entity-relationship approach to take into account historical aspects of systems. In Proceedings of the International Conference on the E-R Approach to Systems Analysis and Design. North Holland, 1979. T. Abbod, K. Brown, and H. Noble. Providing time-related constraints for conventional database systems. In Proceedings of the 13th International Conference on VLDB, pages 167–175, Brighton, 1987. S. Abiteboul, P. Kanellakis, and G. Grahne. On the representation and querying of sets of possible worlds. Theoretical Computer Science, 78, 1991. G. Ariav. A temporally oriented data model. ACM Transactions on Database Systems, 11(4):499–527, Dec 1986. J. Bradely. Operations in databases. In Proceedings of the Fourth International Conference on VLDB, W. Berlin, 1978. J. Ben-Zvi. The Time Relational Model. PhD thesis, Computer Science Department, UCLA, 1982. J. Clifford and A. Crocker. The historical relational data model (hrdm) and algebra based on lifespans. In Proceedings of the International Conference on Data Engineering, pages 528–537, Feb 1987. G.P. Copeland and S. Khoshafian. Object identity. In Proceedings of Object Oriented Programming Systems, Languages and Applications. ACM, 1986. S. Chakravarthy and S.-K. Kim. Resolution of time concepts in temporal databases. Information Sciences, 80(1-2):43–89, Sept. 1994. J. Clifford and A. U. Tansel. On an algebra for historical relational databases: two views. In Proceedings of the ACM SIGMOD, pages 247– 265, May 1985. O. Etzion, A. Gal, and A. Segev. Temporal support in active databases. In Proceedings of the Workshop on Information Technologies & Systems (WITS), pages 245–254, Dec 1992.

94 EW90. F+ 94. FD71.

Gad88. GE98.

GES94.

HK87. J+ 94. KL83.

Kli93. McK88.

MS91. N+ 87.

NA89. OS95. Pis94. RKS88.

RS91. S+ 94. SA86.

Opher Etzion, Avigdor Gal, and Arie Segev R. Elmasri and G. Wuu. A temporal model and query language for ER database. In Proceedings of the International Conference on Data Engineering, pages 76–83, Feb 1990. R. Fagin et al. Reasoning About Knowledge. MIT Press, Cambridge, MA, 1994. N. Findler and D.Chen. On the problems of time retrieval, temporal relations, causality and coexistence. In Proceedings of the International Conference on Artificial Intelligence. Imperial College, Sep 1971. S.K. Gadia. The role of temporal elements in temporal databases. Data Engineering Bulletin, 7:197–203, 1988. A. Gal and O. Etzion. A multi-agent update process in a database with temporal dependencies and schema versioning. IEEE Transaction on Knowledge and Data Engineering, 10(1), February 1998. A. Gal, O. Etzion, and A. Segev. Representation of highly-complex knowledge in a database. Journal of Intelligent Information Systems, 3(2):185– 203, Mar 1994. R. Hull and R. King. Semantic database modeling: Survey, application and research issues. ACM Computing Surveys, 19(3):201–260, Sep 1987. C.S. Jensen et al. A consensus glossary of temporal database concepts. ACM SIGMOD Record, 23(1):52–63, 1994. M.R. Klopprogge and P.C. Lockmann. Modeling information preserving databases; consequences of the concept of time. In Proceedings of the International Conference of VLDB, Florence, Italy, 1983. N. Kline. An update of the temporal database bibliography. ACM SIGMOD Record, 22(4):66–80, December 1993. E. McKenzie. An Algebraic Language for Query and Update of Temporal Databases. PhD thesis, Computer Science Department, University of North Carolina in Chapel Hill, Sep 1988. E. McKenzie and R. Snodgrass. An evaluation of relational algebras incorporating the time dimension in databases. ACM Computer Surveys, 23(4):501–543, Dec 1991. B.A. Nixon et al. Design of a compiler for a semantic data model. Technical Report CSRI-44, Computer Systems Research Institute, University of Toronto, May 1987. S.B. Navathe and R. Ahmed. A temporal relational model and a query language. Information Sciences, 49:147–175, 1989. G. Ozsoyoglu and R. Snodgrass. Temporal and real-time databases: A survey. IEEE Transaction on Knowledge and Data Engineering, 1995. N. Pissinou. Towards an infrastructure for temporal databases—A workshop report. ACM SIGMOD Record, 23(1):35, 1994. M.A. Roth, H.F. Korth, and A. Silberschatz. Extended algebra and calculus for nested relational databases. ACM Transactions on Database Systems, 13(4):390–417, Dec 1988. E. Rose and A. Segev. Toodm-a temporal, object-oriented data model with temporal constraints. In Proceedings of the International Conference on the Entity-Relationship Approach, pages 205–229, San Mateo, California, 1991. R. Snodgrass et al. TSQL2 language specification. ACM SIGMOD Record, 23(1):65–86, Mar 1994. R. Snodgrass and I. Ahn. Temporal databases. IEEE Computer, 19:35–42, Sep 1986.


95

N.L. Sarda. HSQL: Historical query language. In Temporal Databases, chapter 5, pages 110–140. The Benjamin/Commings Publishing Company, Inc., Redwood City, CA., 1993. SJS95. A. Segev, C.J. Jensen, and R. Snodgrass. Report on the 1995 international workshop on temporal databses. ACM Sigmod Record, 24(4):46–52, Dec 1995. SK86. A. Shoshani and K. Kawagoe. Temporal data management. In Proceedings of the International Conference of VLDB, pages 79–88, Aug 1986. Sno87. R. Snodgrass. The temporal query language TQUEL. ACM Transactions on Database Systems, 12(2):247–298, June 1987. Soo91. M.D. Soo. Bibliography on temporal databases. ACM SIGMOD Record, 20(1):14–24, 1991. SS88. A. Segev and A. Shoshani. The representation of a temporal data model in the relational environment. Technical Report LBL-25461, Lawrence Berkeley Laboratories, Aug 1988. Invited Paper to the 4th International Conference on Statistical and Scientific Database Management. Tan86. A.U. Tansel. Adding time dimension to relational model and extending relational algebra. Information Systems, 11(4):343–355, 1986. TCG+ 93. A.U. Tansel, J. Clifford, S. Gadia, S. Jajodia, A. Segev, and R. Snodgrass. Temporal Databases. The Benjamin/Commings Publishing Company, Inc., Redwood City, CA., 1993. TK96. V.J. Tsotras and A. Kumar. Temporal database bibliography. ACM SIGMOD Record, 25(1):41–51, March 1996. WJL91. G. Wiederhold, S. Jajodia, and W. Litwin. Dealing with granularity of time in temporal databases. In R. Anderson et al., editors, Lecture Notes in Computer Science 498, pages 124–140. Springer-Verlag, 1991. ZP93. E. Zimanyi and A. Pirotte. Imperfect knowledge in databases. In P. Smets and A. Motro, editors, Proceedings of the Workshop on Uncertainty Management in Information Systems: From Needs to Solutions, pages 136–186, Santa Catalins, CA., Apr 1993. Sar93.

On Transaction Management in Temporal Databases Avigdor Gal? Department of Computer Science University of Toronto

Abstract. A transaction model provides a framework for concurrent processing of retrieval and update operations in a database. Considerable research effort has focused on various techniques and protocols to ensure the ACID properties of transactions in conventional databases. However, the adoption of these techniques and protocols to temporal databases is not trivial. In particular, a refined locking mechanism based on temporal characteristics can provide better concurrency among transactions in temporal databases than a conventional locking mechanism. Accordingly, this paper presents a set of modifications and fine tuning of traditional concepts in transaction management, to enable a better performance of temporal databases. We also suggest a scheme for implementing a transaction protocol for temporal databases on top of a relational database. The contribution of the paper is in identifying the unique properties of transaction management in temporal databases and the use of these properties to provide a refined locking mechanism to enhance the concurrency of such databases. In particular, we show that the classic 2PL mechanism cannot ensure serializability in temporal databases. Instead, we suggest an alternative method to ensure serializability and reduce redundant abort operations, which is based on a temporal serializability graph. Keywords: temporal databases, transaction management

1

Introduction

A transaction model provides a framework for concurrent processing of retrieval and update operations in a database. A conventional transaction model ensures the following properties (ACID): Atomicity: Either all the operations of a transaction are properly reflected in the database or none are. Consistency: Execution of a transaction in isolation preserves the consistency of the database. ?

The work was conducted while the author was at the University of Toronto. He is currently at the MSIS Department, Rutgers University, 94 Rockafeller Road, Piscataway, NJ 08854-8054

O. Etzion, S. Jajodia, and S. Sripada (Eds.): Temporal Databases - Research and Practice c Springer–Verlag Berlin Heidelberg 1998 LNCS 1399, pp. 96–114, 1998.


97

Isolation: Each transaction assumes that it is executed alone. Any intermediate transaction results are not available to other concurrently executed transactions. Durability: The values changed by the transaction persists after the transaction was successfully completed. Considerable research was dedicated to various techniques and protocols to ensure the ACID properties of transactions in conventional databases, e.g. the locking mechanism and the 2PL (Two Phase Locking) protocol, using serializability as a correctness criteria. However, adopting these techniques to temporal databases [27], i.e. databases that enable the accumulation of information over time and provide the capability to store different values of the same data element with different time characteristics, is not trivial. When adopting conventional techniques to accommodate the needs of temporal databases, a refined locking mechanism based on temporal characteristics should be designed, to provide better concurrency among transactions in temporal databases. Also, conventional protocols cannot efficiently support transactions in temporal databases. For example, as suggested in [21] and demonstrated in this paper, the classic 2PL mechanism cannot ensure serializability in temporal databases. Therefore, the use of either a strict 2PL or a serial transaction processing is required, when using conventional methods, to prevent a non-serializable transaction management in temporal databases. This paper presents a set of modifications and fine tuning of traditional concepts in transaction management, which are required for a better performance of temporal databases. To exemplify these modifications, we provide a scheme for implementing a temporal transaction protocol on top of a relational database model. The approach of using add-on temporal facilities with an existing conventional database model is considered nowadays the most suitable approach to provide temporal capabilities in databases [28]. The contribution of the paper lies in identifying the unique properties of transaction management in temporal databases and the use of these properties to provide a refined locking mechanism to enhance transactions’ concurrent execution in such databases. In particular, we provide an alternative method to 2PL, based on a temporal serializability graph, to ensure concurrency while reducing the number of redundant abort operations. The issue of transaction modelling for temporal databases was suggested as one of the challenges for further research at the NSF International Workshop on an Infrastructure for Temporal Databases [4] and was first introduced in [21] and [30]. While the former relates to a transaction time temporal database only, the latter uses a simplified temporal data model and therefore results in a much simpler transaction model. In particular, the temporal database in [30] does not support transaction time and is not append-only. Some consideration to the issue of using commit time as a transaction time was given in [8], [19], and [28]. While several previous researches have discussed the refinement of transaction models (e.g. SAGAS [14] and ACTA [6]), none of them relate specifically to the unique properties of temporal databases. Nonetheless, it is worth noting

98

Avigdor Gal

that an extended model like SAGAS can serve as an underlying model for implementing better transaction models for temporal databases by using temporal independence and the refined locking mechanism presented in this paper. Most transaction models deal with time by using histories and time stamps as useful tools for ensuring serializability, and some research was done on querying transaction logs to obtain temporal-oriented information [3]. Yet, these time considerations provide a different dimension than the one we handle in this paper, i.e. providing temporal databases with a coherent transaction model. Time stamping mechanisms for ensuring serializability were discussed in the framework of conventional databases [2] and some research was even dedicated to multiversion systems [16]. While this area of research bares similarity to the research presented in this paper, several major differences exist. First, the time stamping does not provide temporal capabilities on top of a conventional database. Second, a transaction in some temporal database types (e.g. bi-temporal databases) is time stamped at commit time, rather than at the beginning of its execution. Therefore, as we show in this paper, the assumptions that hold for a time stamping mechanism are not valid for transactions in bi-temporal databases. The rest of the paper is organized as follows. Section 2 provides a data model and an execution model of a temporal database that is utilized throughout the paper. A transaction model for temporal databases is introduced in Section 3 followed by a scheme for implementing a temporal transaction protocol on top of a relational database model (section 4). Section 5 concludes the paper.

2

A data model for temporal databases

This section introduces the basic concepts of a data model for temporal databases. The terminology is based on [10], and it uses a semantic data model which is more adequate for representing sets of sets, a common requirements in temporal databases. The generic model can be easily translated into a relational as well as an object-based data model (see [10] for details). An object is defined as an instance of a class or a tuple in a relation and a property is defined as an attribute in the object-based model and a column in the relational model. The term class defines either a class in the object-based model, or a relation in the relational model. Let DBS = {C1 , C2 , ..., Cm } be a database schema that consists of m classes. A class Ci has ni properties P1i , P2i , ..., Pni i , each with a domain Dom(Pji ), where a domain is a set of values. An instance of a property Pji is an element of the set Dom(Pji ), represented as α.Pji , where α is an object identifier instance of the appropriate class, a class name, or a variable. A class domain of a class Ci (CDOM (Ci )) is a subset of the Cartesian product Dom(P1i ) × Dom(P2i ) × . . . × Dom(Pni i ). An object state os of an instance o of a class Ci at time t is an element hp1 , p2 , ..., pni i ∈ CDOM (Ci ). An application state at t is a set {os(o) | o is an instance of Ci (1 ≤ i ≤ m) at t}. Following previous works in the temporal database area, we adopt a discrete model of time [7], isomorphic to the natural numbers. Hence, a temporal domain is a domain T ∼ = N. The discrete model defines a Chronon [17] to be a nondecom-


99

posable unit of time (t ∈ T ), whose granularity is application dependent. A time interval is designated as [ts , te ), the set of all chronons t such that ts ≤ t < te . A temporal element [9] is a finite union of disjoint time intervals. The temporal infrastructure document [26] advocates a bi-temporal database model, in which each data element is associated with two temporal dimensions, called valid time and transaction time. A valid time (v) is a temporal element that designates the collection of chronons at which the data element is considered to be true in the modeled reality. A transaction time (x) is a chronon that designates the time in which the transaction that inserted the data element’s value to the database was committed. Therefore, in a bi-temporal database, a domain Dom(Pji ) of an attribute Pji is the Cartesian product of three domains, one of which is the value domain of the property, while the other two are temporal domains. Information about an object is maintained as a set of variables (instances of the class’ properties), where each variable contains information about the history of the values of the property. Each variable is represented using a set of stateelements, where a state-element se is an element of a domain that consists of a value (se.value) and temporal characteristics (se.v and se.x in the bi-temporal case). The following definition provides some properties of sets of state-elements: Definition 1. Let SE1 and SE2 be two sets of state-elements of a variable α.P : – SE1 and SE2 are identical iff 0 0 ∀1 ≤ i, j ≤ 2(∀se ∈ SEi ∃se ∈ SEj | se.value = se .value ∧ se.v = 0 0 se .v ∧ se.x = se .x). 0 00 0 00 – SE1 and SE2 are similar iff ∀1 ≤ i, j ≤ 2(∀{se1 , se1 } ⊆ SEi ∃{se2 , se2 } ⊆ SEj | 0 0 0 0 1. se1 .value = se2 .value ∧ se1 .v = se2 .v∧ 00 00 00 00 2. se1 .value = se2 .value ∧ se1 .v = se2 .v∧ 0 00 0 00 3. se1 .x ◦ se1 .x −→ se2 .x ◦ se2 .x (◦ ∈ {})) Based on Definition 1, the similarity of two sets of state-elements identifies two sets that consist of the same information, and were committed at the same order, yet in different chronons.1 Various database models accumulate state-elements in different ways. Some models (e.g. TALE [13]) follow the append only approach, according to which new information is added while existing information is left intact. Other models (e.g. [1]) follow the alternative approach, according to which a new state-element of a variable in a valid time τ replaces any other state-element in τ . Many hybrids exist between these two extremes. If the data model supports the append-only approach, previous inserted state-elements can be accessed using an observation time abstraction (see below). Temporal relationships for retrieval and update purposes are specified through the use of participants, variables with valid time binding, of the form hα.P , vi. 1

In [18], value equivalence is suggested, where all temporal characteristics are being stripped off. This is, however, a different notion than similarity.

100

Avigdor Gal

A variable followed by a v defines the state-elements that are retrieved by the operation, or the bounded effect of the operation on the generation of new stateelements. An append-only temporal database is updated by adding state-elements to variables, therefore generating a new application state each time a state-element is added. Each state-element is associated with two temporal values, one specifies its valid time and the other is the transaction time, set upon a successful termination of a transaction, where a transaction is defined using the classical definition (e.g. [29]) and refined in the following section. To ensure durability, the values that are changed by the transaction persist after a commit command is issued. It is worth noting that all the state-elements that were generated by a single transaction share the same transaction time. Information retrieval from a database is done by retrieving state-elements that persist in the database. The following parameters define the set of stateelements which are considered for retrieval: 1. The required variable(s), i.e. a specific object and a list of properties. 2. A temporal element that specifies the required valid time. 3. A chronon that specifies an observation time of the query. An observation time defines a previous state of the database, rather than the current one, to be the retrieved state. A selection of an observation time to be t0 < now results in selecting only state-elements that are known at to , i.e. have persisted in the database no later than to ({se | se.x ≤ to }). It is worth noting that the observation time is restricted to be less than the chronon in which a query was issued. A related type of queries retrieves previously inserted values of a variable α.P in τ . Hence, instead of specifying an observation time, a version number is utilized. For example: “retrieve the value of α.P in τ that was inserted before i versions” (i > 0). We term these queries version queries. Let Q be a query for a variable α.P in τ as of to . Q is formalized as 0 Q = σX=α.P ∧v∩τ 6=∅∧x≤to (Q ), where X is the set of attributes that represents 0 the object identifier, and Q is the query part that is associated with the nontemporal aspects of Q. Q returns the state-elements {se1 , ..., sen } of α.P such that ∀1 ≤ i ≤ n, sei .v ∩ τ 6= ∅ ∧ x ≤ to . It is worth noting that some queries may require the use of the full set of state-elements of a variable. For example, the query “find the chronons in which the price of a share x increases within a day after an increase in patrol prices,” requires the use of the full set of stateelements of the share x and the patrol prices. It is also noteworthy that in order to enable an observation time specification, a participant can be extended to be a triplet hα.P , v, to i where the latter component represents the observation time. It is possible to define a preference criterion to provide a partial order among state-elements. A preference criterion that chooses the value(s) that is (are) valid in an interval τ for which a variable α.P has overlapping values can be based on several preference relations. For example, let sei and sej be two state-elements


101

of a variable α.P that are candidates for retrieval. sej is preferred to sei iff sej .x > sei .x. This preference criteria (denoted “last value semantics”) is the common one in temporal databases and we shall use it as a default criteria. Therefore, a variable for which no observation time is specified (i.e. there is no value specified for to ) is assumed to require the state-element that has a higher x value for each chronon than of all the other candidate state-elements.

3

A transaction model for temporal databases

In this section we provide a transaction model for temporal databases. Section 3.1 provides the modifications of the basic concepts of transaction modelling. Based on these modifications we provide a temporal transaction model in Section 3.2. 3.1

Modification of basic concepts of transaction modelling

A transaction in a temporal database, just like a transaction in a conventional database, is a set of database operations that the database views as a single unit of work. However, all database operations in a temporal database are associated with a temporal element that defines their temporal effect on the database (see the definition of a participant in Section 2). We limit our discussion to database operations only, although a transaction may consist of external routines,2 as we are mainly interested in the transaction’s effect on the database. In this section we provide the required modifications to transaction modelling in temporal databases. Atomicity and recovery This section discusses atomicity and recovery. We present temporal independence as a new form of atomicity, and discuss various recovery mechanisms, including transactions aborts, cascading aborts, aggressive and conservative protocols and a redo mechanism. A transaction in conventional database is atomic, i.e. its database operations can either occur in their entirety or not occur at all, and if they occur, nothing else apparently went on during the time of their occurrence [29]. There are many possible temporal extensions to the atomicity property. The two extremes result in two types of atomic behaviour of a transaction, as follows: Global atomicity: The atomicity as perceived in conventional databases. Temporal independence: The temporal database is conceptually viewed as a set of independent database snapshots, each of which relates to a different chronon. Hence, a transaction in a temporal database is viewed as a collection of transactions applied to different snapshots, and therefore a transaction can commit in one chronon and abort in another. The effect of temporal independence is materialized in a preprocessing phase, during 2

For example, in DB2 a transaction is defined as “a set of interactions between an application and the database.” [5]

102

Avigdor Gal

which a transaction submitted by the user is partitioned into a set of transactions, each relates to a single schema version, that are executed according to a set of algorithms as proposed in [11]. The main discernment for introducing temporal independence is to provide the user with an adequate mechanism to support database operations in a temporal database with schema versioning. A temporal database accommodates schema versioning if it supports modifications to the database schema, as well as database operations that should be interpreted in the context of the appropriate schema version, which is not necessarily the current one [18]. The persistence of all schema versions guarantees correct interpretation of historical data, since each update operation o is considered with respect to the schema(ta) that is (are) correct in the valid time as given in the participants of o. Therefore, by using global atomicity, if o cannot be performed with respect to any of the involved schemata, the transaction aborts. Consequently, redundant aborts may occur due to the user’s ignorance with respect to the metadata modifications. By using temporal independence, on the other hand, a transaction in a temporal database is treated as a syntactic substitution for representing several snapshot transactions, not bounded by global atomicity rules. Temporal independence, therefore, supports the maximal possible changes to snapshots, while maintaining the database consistency. To ensure atomicity, the DBMS should use a recovery scheme. Since each state-element is stamped with a transaction time at commit time, the most natural policy to adopt is the No-steal policy, according to which no state-elements are written to the database at least until the commitment of the modifying transaction. Therefore, we can assume that all the state-elements that are generated by a transaction persist only at commit time, after a time stamp was chosen. Hence, whenever a transaction T aborts, all the state-elements that were generated by T are not added to the database (no-undo policy). It is possible, that due to various reasons (e.g. shortage of main memory) some of the state-elements are written to the database (using the Steal policy), to be replaced at a later time by adding the transaction time. In this case, these state-elements should be erased to ensure a correct recovery process. Since an append-only database simulates the shadowing strategy, by keeping all of its previous states, erasing these state-elements restores the previous database state, and ensures the database consistency.3 The problem of cascading rollbacks exists in temporal databases (and can be prevented by using a strict protocol), yet its scope can be narrowed by refining the conflicting operations notion. This refinement also serves to enable a better concurrency of transactions, as discussed in the sequel. In temporal databases, the occurrence of a deadlock situation is less likely than in conventional databases since temporal databases store and use more information of each property and therefore there is a reduced probability of having two concurrent transactions trying to lock the same item (see section 3 3

A less powerful argument, regarding media failures only, was presented in [20].


103

for the locking mechanism in temporal databases). Based on results in conventional databases, the use of an aggressive protocol is preferable to the use of a conservative one in temporal databases. The redo mechanism of a conventional database is not adequate for temporal databases. In conventional databases we can scan through the log and update each value of a committed transaction (e.g. [22]). In temporal databases, however, this simple mechanism might generate two similar sets of state-elements in case a system failure occurs while updating the database with the updates of a committed transaction. Such a duplication is likely to affect the database’s retrieval results in situations where the number of state-elements is used for view purposes (e.g. averaging the values of a variable at a given chronon). To overcome this problem, we suggest to register the transaction time on the log when a transaction is committed. In the recovery process, the information of a new state-element of a variable α.P will be generated based on the information on the log only if there is no identical state-element in the database for α.P . Using this scheme, the state-elements will be recovered as a whole (including the original transaction time) rather than generating a similar set of state-elements. Temporal locks A common mechanism to ensure serializability of transactions is the locking mechanism. In this section we discuss a refinement of the conventional locking mechanism, to enable a more flexible transaction management, using the unique properties of temporal databases. Definition 2. - A temporal read lock: A transaction T in a temporal database holds a temporal read lock from time tl until time tu on a variable α.P in τ (denoted as trlock hα.P, τ i) iff no transaction can update α.P in τ in the time interval [tl , tu ). Definition 3. - A temporal write lock: A transaction T in a temporal database holds a temporal write lock from time tl until time tu on a variable α.P in τ (denoted as twlock hα.P, τ i) iff T is the only transaction that can update α.P in τ in the time interval [tl , tu ). It is worth noting that there are two different time dimensions in the above definitions. τ is a temporal element that relates to the valid time of a stateelement, while [tl , tu ) defines the time in the real world when other transactions are prohibited from reading/writing α.P in τ . A transaction T can request a trlock hαk .pl , τq i or a twlock hαk .pl , τq i. Both types of locks are released with an unlock hαk .pl , τq i request. As in conventional databases, we assume that each time a twlock is applied to a variable α.P in τ , a unique function associated with that lock produces a new state-element for α.P in τ . That function depends on all the variables which were locked using trlock prior to the unlocking of α.P in τ . Also, we assume that a trlock applied to a variable α.P in τ does not modify α.P in τ . We do not assume, however, that a write lock of a variable implies that it is read.

104

Avigdor Gal

As a final note, we draw attention to the fact that while in conventional databases a write lock of an element A prevents further read locks to A before the write lock is released, there are situations where a write lock does not prevent a read lock. These situations involve the usage of previous application states using an observation time. Since previous application states cannot be modified in an append-only database, any retrieval operation that involves an application state that precedes the starting of the transaction can be retrieved at any time during the transaction processing, without a need for a lock even if the variable is write-locked at that time [21].

Conflicting operations The common model in conventional databases defines conflicts among read and write operations of the same item, and uses locking as a mechanism to prevent a non-serilaizable schedule as a result of such conflicts. Read locks are considered to be shared, i.e. a read lock on an item A prevents any other transaction from writing a new value to A, yet any number of transactions can hold a read lock on A. A write lock, however, is considered to be exclusive in the sense that while a transaction holds a write lock on an item A, no other transaction can read from or write to A. As discussed in this section, a refinement of the notion of a conflict is required when discussing temporal databases. In temporal databases, conflicts may occur among two read or write operations only if they relate to the same variable α.P with an overlapping valid time τ . As discussed in section 3.2, and following similar mechanisms in conventional databases, there can be no RR conflict in temporal databases, yet there exists a WR conflict. However, unlike conventional databases, a WW conflict cannot always be solved by identifying useless transactions4 in append-only temporal databases. For example, if a transaction uses an observation time to retrieve state-elements from the database, “useless transactions” in a conventional database become “useful transactions” as their values might serve in a future read operation. Since transactions are time stamped on commit time (x), their effect on further retrievals in the database depends on the order of the transactions’ commit commands. For example, if two transactions T1 and T2 attempt to write concurrently to a variable α.P values val1 and val2 with valid times τ1 and τ2 , respectively, such that τ1 ∩ τ2 = τ 6= ∅, then both values persist, yet only one value is retrieved using the last value semantics. If T1 commits before T2 , val2 will be the retrieved value of α.P in τ , and vice versa. It is also possible, under such circumstances, to generate a history that would not be serializable. For example, let T1 and T2 be two transactions, and consider the following history:

4

A useless transaction is a transaction which effect on the database is lost due to later values written to the database [25].


105

T1 T2 (1) write hα.P, τ1 i (2) read hα.P, τ1 i (3) write hα.P, τ1 i (4) commit (5) commit Since T2 is committed before T1 , a serialized execution should be T2 −→ T1 , and therefore T2 cannot use the value of α.P in τ as written by T1 . In Section 3.2 we shall show that due to such scenaria, a 2PL protocol cannot guarantee serializability in a temporal database. 3.2

A temporal transaction model

Having defined the required refinements of conventional terminology to support the temporal dimension, this section presents a temporal transaction model using schedules and a temporal serializability test. We use the convention that a serializable schedule of executed operations ensures the consistency and isolation properties, and show that while a 2PL cannot guarantee serializability in bi-temporal databases, a strict 2PL guarantees serializability. We also provide a new protocol, the abort/commit/wait protocol to minimize the number of aborted transactions. In what follows, a transaction is either a transaction as submitted by a user (if using global atomicity) or a transaction as produced by a pre-processing step (if using temporal independence, as defined in Section 2). A schedule S = ha1 , ..., an i for a set of transactions T1 , ..., Tm is an ordered set of operations of T1 , ..., Tm such that ai = Tj : (tr/tw)lock hα.P, τ i or ai = Tj : unlock hα.P, τ i. The following definition defines equivalence of schedules, using the available sets of state-elements. Definition 4. - Equivalence of schedules : Two schedules S1 and S2 are equivalent if: 1. For each variable α.P , S1 and S2 produce similar sets of state-elements. 2. Each temporal read lock of a variable α.P in τ applied by a given transaction occurs in S1 and S2 at times when α.P has similar sets of state-elements in τ. A weaker definition of an equivalence of schedules utilizes the last value semantics as a comparison mechanism, rather than sets similarity. This weaker definition converges to the equivalence definition of schedulers in conventional databases. As explained in Section 3, the granularity of locks in temporal databases involves a temporal element as well as a variable. Therefore, some modifications are required to a precedence graph in order to identify whether a given set of transactions is serializable or not. Definition 5. - A temporal serilizability graph: Let S = ha1 , ..., an i be a schedule for a set of transactions T1 , ..., Tm . A temporal serilizability graph G(V, E) is a polygraph such that:

106

Avigdor Gal

– V = {T1 , ..., Tm } – E is generated as follows: 0 00 generated if: 1. WR conflict: an edge0 hhT , T i, τ i is 0 Write lock: ∃ai = T :twlock hα.P, τ i∧ 00 00 Read lcok: ∃aj = T :trlock hα.P, τ i∧ Write lock precedes Read lock: i < j∧ 0 00 Valid time overlap: τ ∩ τ = τ 6= ∅∧ ∗ No intermediate conflicting lock: ∀i < k < j, (ak 6= T :twlock ∗ ∗ 00 hα.P, τ ∗ i ∨ ak = T :twlockhα.P, τ ∗ i00∧ τ ∩ τ = ∅) 0 2. WW/RW conflict: an edge pair (hhT , T ∗ i, τ i, hhT ∗ , T i, τ i) is generated if: 0 00 0 Existing edge: ∃hhT , T i, τ i ∈ E∧ 0 0 00 Conflicting item: ∃α.P | (∃ai = T : twlock hα.P, τ i∧∃aj = T : trlock 00 0 00 000 hα.P, τ i ∧ i < j ∧ τ ∩ τ = τ 6= ∅∧ 000 ∗ Another write lock: ∃ak = T : twlock hα.P, τ ∗ i∧ τ ∩ τ ∗ = τ 6= ∅). According to Definition 5, an edge (or a pair of edges) of the temporal serializability graph connects two transactions only if the destination of the edge can only be performed after the source of the edge. This can occur in the following two situations: 00

0

1. A transaction T reads a value that was written by a transaction T with 0 an intersecting valid time. Therefore, in a serial schedule T commits before 00 T . 2. A transaction T ∗ writes a value to a variable α.P in a valid time that intersects with a valid time of α.P that is part of a WR conflict between two 0 00 0 transactions T and T . In this case, T ∗ can commit either before T or after 00 T . Definition 5 takes into account the temporal effect, and therefore there should be an overlapping of the locked temporal elements to generate a dependency. It is worth noting that since the retrieval of past application states (using observation times) are not involved in any conflict, they do not require a read lock and therefore do not affect the transactions’ priority. However, the order of writing state-elements of the same variable with an overlapping valid time generates a WW conflict. This conflict prevents an erroneous interpretation of version queries. Definition 6. - A temporal cycle: Let G(V, E) be a temporal serializabiliy 0 graph and let G be a graph that is derived from G by choosing a single edge of 0 each pair. A temporal cycle in G is a sequence n T τ i 6= ∅. hhhT 1 , T 2 i, τ 1 i, hhT 2 , T 3 i, τ 2 i, ..., hhT n , T 1 i, τ n i such that i=1

Theorem 1. Let T1 , T2 , ..., Tm be m transactions with transaction times x1 , x2 , ..., xm , respectively. A schedule S for T1 , T2 , ..., Tm is serializable iff there 0 0 is a derivative of the temporal serializability graph G (V, E ), built using S such that:


107 0

1. For no two transactions Ti and Tj such that xi < xj , hhTj , Ti i, τ i ∈ E . 0 0 2. G (V, E ) has no temporal cycles. Sketch of proof:5 ⇒Assume that S is a serializable schedule, yet for any derivative of the temporal 0 0 serializability graph G (V, E ), built using S, there exist two transactions Ti and 0 Tj such that xi < xj and hhTj , Ti i, τ i ∈ E . Let hhTj , Ti i, τ i be an edge of a derivative of a temporal serializability graph: 1. hhTj , Ti i, τ i was generated due to a WR conflict. =⇒ Ti reads a value that was written by Tj . =⇒ Tj should commit before Ti in any serial schedule equivalent to S. =⇒ xj < xi . contradiction to the assumption. (1) 2. hhTj , Ti i, τ i was generated due to a WW/RW conflict. =⇒: (a) Tj writes a value before Ti and there is some transaction T that reads the value written by Ti . =⇒ Tj should commit before Ti in any serial schedule equivalent to S. =⇒ xj < xi . contradiction to the assumption. (2) (b) Ti writes a value after Tj reads a value written by some transaction T . =⇒ Tj should commit before Ti in any serial schedule equivalent to S. =⇒ xj < xi . contradiction to the assumption. (3) (1), (2), (3) =⇒ no two transactions Ti and Tj exist, such that 0 xi < xj , hhTj , Ti i, τ i ∈ E . The proof of the second part is similar to the classic proof regarding cycles in a serializability graph (see [29] for an example). ⇐Assume conditions 1 and 2 hold, and assume (without loss of generality) that x1 < x2 < ... < xm . Let R = T1 → T2 → ... → Tm be a serial scheduler. Using induction, we can show that Ti reads similar sets of state-elements for each variable it locks, both in the given schedule S and in the serial schedule R. The reason being that if transaction Ti reads a value of an item hα.P, τ i, then in both schedules the same transactions Tj1 , Tj2 , ..., Tjk (1 ≤ j1 , j2 , ..., jk < i) were the last to write α.P in some temporal element τ ∗ such that τ ∗ ∩ τ 6= ∅, or Ti is the first to read hα.P, τ i. Otherwise, a temporal cycle would be generated (contradicting condition 2). Using the induction assumption we can show that the last transaction to write a variable α.P in a chronon t is the same in schedules S and R, and therefore similar sets of state-elements are generated for each variable.2 A temporal variation of 2PL, termed temporal 2PL requires that in any transaction, all (read and write) temporal locks precede all temporal unlocks. A strict temporal 2PL requires all temporal locks to be released after a transaction commits. As mentioned in [21], temporal 2PL cannot guarantee serializability. We 5

In this paper we present partial proofs. We present the part of the proof that is unique to temporal databases, and leave out the parts whose proof is similar to the proofs of classic theorems in transaction theory.

108

Avigdor Gal

use the following example to demonstrate this claim. Let T1 and T2 be two transactions and consider the following schedule S: T1 T2 (1) twlock hα.P, τ i (2) unlock hα.P, τ i (3) trlock hα.P, τ i (4) twlock hα.P, τ i (5) unlock hα.P, τ i 0 Obviously, S obeys the temporal 2PL. Thus, for a serial schedule S to be equivalent to S, T1 should precede T2 . However, if T1 and T2 commit on x1 and 0 x2 , respectively and x1 > x2 , in order for a serial schedule S to be equivalent to S, T2 should precede T1 . Therefore, S is not necessarily serializable. It should be noted that the equivalent schedule in a conventional database (where hα.P, τ i is replaced by α.P ) is serializable, whether T1 commits before T2 or vice versa. Hence, the temporal 2PL is not sufficiently strict to enforce a specific order of commit commands. However, as the following theorem shows, a strict 2PL can enforce a specific order of commit commands and therefore can guarantee serializability. Theorem 2. Let T1 , T2 , ..., Tm be m transactions with transaction times x1 , x2 , ..., xm , respectively, and let S be a schedule for T1 , T2 , ..., Tm . If S obeys strict temporal 2PL, then S is serializable. Sketch of proof: Let S be a schedule that obeys strict temporal 2PL and assume that S is not serializable. Using Theorem 1, for any derivative of the 0 0 temporal serializability graph G (V, E ) built using S, the following two scenaria are possible: 0

0

1. G (V, E ) has a temporal cycle. A contradiction is reached in a similar fashion to classic proofs (see [29] for an example). 0 0 0 00 2. G (V, E ) has no temporal cycles, yet there exist two transactions T and T 0 00 00 0 0 such that x < x and hhT , T i, τ i ∈ E . 00 0 =⇒due to the protocol strictness, T should release all of its locks before T 0 0 can acquire a lock for some participant hα.P, τ i, where τ ∩ τ 6= ∅. Let t be 00 the time T released all of its locks. 00 =⇒due to the protocol strictness, x < t. (1) 0 00 Since T is not completed by the time T released all of its locks (it should 0 still acquire at least one more lock), t < x . (2) 00 0 (1), (2)=⇒ x < x . contradiction. =⇒If S obeys strict temporal 2PL, then S is serializable.2 While strict 2PL ensures serializability, it is not necessarily the best protocol as it reduces concurrent activities. Thus, we present a protocol (commit/abort/wait) in Table 1 to increase concurrency while avoiding redundant aborts. Algorithm 1 provides the relevant activities of transactions during their life cycle. In addition to retrieving and updating the database, transactions lock


109

and unlock variables and update the temporal serializability graph. A transaction that concluded its activities might be forced to wait before committing, due to other transactions that precede it in the temporal serializability graph and did not commit yet. It is worth noting that any transaction would either commit or abort eventually, since the temporal 2PL prevents temporal cycles (although it cannot ensure by itself the order of the committing transactions). Also, a transaction that reaches the end transaction6 bares similarity to the term distributed database systems (e.g. [15]). We refrain from using this term to avoid confusion. phase would eventually commit, as nothing can prevent it from doing so (all activities were successful and there are no temporal cycles). The commit/abort/wait protocol: On start transaction do: 1 generate a new node Ti in the temporal serializability graph 2 execute operations, using temporal 2PL for locking and unlocking and update the temporal serializability graph according to its definition

1 2 3 4 5

On end transaction do: release remaining locks obtained by Ti if exists hT, Ti i ∈ E then: wait else: commit

1 2 3

On commit do: remove Ti and all edges hT, T 0 i s.t. T = Ti or T = T 0 end wait commit transaction

1 2 3 4

On abort do: release remaining locks obtained by Ti remove Ti and all edges hT, T 0 i s.t. T = Ti or T = T 0 end wait abort transaction

1 2 3 4

On end wait do: if exists hT, Ti i ∈ E then: wait else: commit

Table 1. Annotated listing of Algorithm 1—commit/abort/wait protocol

6

transaction

110

4

Avigdor Gal

Implementing a temporal transaction model

Having shown the temporal transaction model, in this section we provide a scheme of a temporal transaction model, based on the relational data model. We define the notion of a shadow relation and utilize it in an algorithm for a strict conservative temporal 2PL. Various methods were suggested to map a temporal data structure into a relational model, using normalization rules. A possible implementation can use universal relations as discussed in [24]. Another possible implementation uses the ENF (Extension Normal Form) [12], which is an extension of the TNF (Time Normal Form) [23], as follows. Each relation designates a set of synchronous attributes, which are attributes that have common state-element’s temporal information (i.e. x and v) at any chronon. Therefore, each relation is augmented with an attribute that represents x and two attributes (vs and ve ) for the boundaries of a v interval. We can assume that if R is a relation and X ⊆ R is the object identifier, then X ∪ {x, vs , ve } serves as a key for R. Using ENF, the update of the temporal database is a tuple-based without redundancies. It is worth noting that the representation is restricted since the v can be an interval but not a temporal element. To eliminate this restriction, a separate relation for the v element should be created, identified by a unique state-element identifier and the interval values. The use of a conventional locking mechanism for a temporal database based on a relational database is impossible. For example, let R be a relation in ENF (where the set {a, x, vs , ve } serves as a key): a b x vs ve a1 b1 t1 t2 t4 a1 b2 t2 t2 t3 a1 b3 t3 t3 t4 Let T1 be a transaction that requires the locking of the latest value(s) of a variable b of R in [t2 ,t4 ). Based on a conventional locking mechanism, the first tuple is locked (being the only one with vs =t2 and ve =t4 ), while the other two tuples can be accessed. However, using the temporal semantics and assuming that t1 , >--. TD satisfaction is characterized by a support and confidence. As TD's may express meaningful trends, mining them is significant. The

428

The Dagstuhl Seminar Researchers

TD mining problem studied is the following task: Given a temporal database, find the TD of a specified form that holds with the highest confidence and with support greater than or equal to a specified minimum threshold.. This pro blem is called TDMINE. Unlike most other work in data mining, we primarily focus on the computational complexity of the TDMINE problem - rather than on the performance of algorithms to solve it. Both the number of tuples (cardinality) and the number of attributes can be taken as the "size" of TDMINE. TDMINE can be solved in quadratic time if the cardinality is taken as the size. If the time requirements are expressed in function of the number of attributes - rather than the cardinality - then the problem turns out NP-complete. We discuss the practical implications of this result.

Dynamic Attributes and Temporal Triggers in Active Databases Ouri Wolfson Dynamic attributes: Existing database management systems (DBMS's) are not well equipped to handle continuously changing data, such as the position of moving objects. The reason for this is that in databases, data is assumed to be constant unless it is explicitly modified. For example, if the salary field is 30K, then this salary is assumed to hold (i.e. 30K is returned in response to queries) until explicitly updated. Thus, in order to represent moving objects (e.g. vehicles) in a database, and answer queries about their position (e.g., How far is the vehicle with license plate RWW860 from the nearest hospital?) the vehicle's position has to be continuously updated. This is unsatisfactory since either the position is updated very frequently (which would impose a serious performance and wireless-bandwidth overhead), or, the answer to queries is outdated. To address this problem, we proposed a data model called Moving Objects Spatio-Temporal (or MOST for short) for databases with dynamic attributes, i.e. attributes that change continuously as a function of time, without being explicitly updated. Temporal Triggers in Active Databases: We are building a rule-processing component that can be incorporated into commercial-off-the-shelfDatabase Management Systems. The component will add monitor and control capabilities to existing DBMS's. The target applications consist of a continuously changing database that represents the status of a real system (e.g. a battlefield). Using the rule-system the user will be able to specify conditions that need to be monitored in real-time over the changing database, and actions to be taken upon occurrence of these conditions. The novel aspect of our rule-processing component is the rule language which, in contrast to existing languages, allows the concise specification of temporal conditions (i.e., conditions on the way the database evolves over time) and temporal actions.

I n d e x of A u t h o r s

Bettini, C. 36, 406 Berger, G. 281 BShlen, M. H. 150, 367 Chamberlain, S. 310 Clifford, J. 367 Dao, S. 310 Darwen, H. 195 Dyreson, C. E. 367, 406 Elmasri, R. 115, 367 Etzion, O. 56 Evans, W. S. 406 Gadia, S. K. 238, 367 Gal, A. 56, 96 Goralwalla, I.A. 1 Grandi, F. 367 Hayes, P. 367 Jajodia, S. 36, 338, 367 Jensen, C. S. 150, 367 K~ifer, W. 367 Kline, N. 367 Lee, J. Y. 115 Lorentzos, N. 367 Mitsopoulos, Y. 367 Montanari, A. 367

Nonen, D. 367 Ozsu, M. T. 1 Patankar, A. K. 257 Peressi, E. 367 Pernici, B. 367 Roddick, J. F. 367 Sarda, N. L. 367 Scalas, M. R. 367 Segev, A. 56, 257, 367 Sistla, A. P. 310 Snodgrass, R. T. 150, 406, 367 Soo, M. D. 367 Steiner, A. 150 Szafron, D. 1 Tansel, A. U. 129, 367 Tiberio, P. 367 Tin, E. 129 Toman, D. 211 Tuzhilin, A. 281 Wang, X. S. 36, 338, 406 Wiederhold, G. 367 Wolfson, O. 10 Wu, Y. 338

Temporal Databases: Research and Practice

Temporal Databases: Research and Practice 1997

Object Databases in Practice

Advances in Spatial and Temporal Databases - SSTD 2011

Hallucinations: Research and Practice

Hallucinations: Research and Practice

Community-Built Databases: Research and Development

Quantifiers and Temporal Ontology

Spatial and Temporal Reasoning

Pancreas - Pathological Practice and Research

Probation: Theories, Practice, and Research

Adolescent Literacy Research and Practice

Forgiveness: Theory, Research, and Practice

Educational Research, Policymaking and Practice

Counterfactuals and Temporal Direction

Text Databases and Document Management: Theory and Practice

Lords Temporal

Bioinformatics: Databases and Systems

Genomes, browsers, and databases

Java and Databases

Living and Studying Abroad: Research and Practice

Industrial and Organizational Psychology: Research and Practice

Bioinformatics: databases and systems

Joe Celko's Data and Databases: Concepts in Practice

Lords Temporal

Identity and Spatio-Temporal Continuity

Strategy as Practice: Research Directions and Resources

Human Ecology: Contemporary Research and Practice

Conflict resolution: theory, research, and practice

Feminist Research in Theory and Practice

Human Ecology: Contemporary Research and Practice

Temporal Databases: Research and Practice