TEMPOS : A Temporal Database Model Seamlessly Extending ODMG TEMPOS : Un modele pour Bases de Donnees Temporelles compatible ODMG Marlon Dumas, Marie-Christine Fauvet and Pierre-Claude Scholl LSR-IMAG, University of Grenoble BP 72, 38402 St Martin d'Heres (France) E-mail:
[email protected]
Abstract
This paper presents Tempos, a set of models and languages intended to seamlessly extend the ODMG object database standard with temporal functionalities. The proposed models exploit object-oriented technology to meet some important, yet traditionally neglected design criteria, related to legacy code migration and representation independence. Tempos has been fully formalized both at the syntactical and the semantical level and implemented on top of the O2 DBMS. Its suitability in regard to applications' requirements has been validated through concrete case studies from various contexts. Keywords: temporal databases, temporal data models, temporal query languages, time representation, upward compatibility, object-oriented databases, ODMG
Resume
Ce document presente Tempos : un ensemble de modeles et de langages concus pour etendre le standard pour Bases de Donnees a objets ODMG, par des fonctionnalites temporelles. Les modeles decrits exploitent les possibilites de la technologie objet pour remplir un certain nombre de criteres traditionnellement negliges, lies a la migration d'applications existantes et a l'independance de la representation. Tempos a ete formalise aussi bien au niveau syntaxique que semantique et implante au dessus du SGBD a objet O2 . De plus, son adequation par rapport aux besoins des applications a ete validee sur des etudes de cas tirees de divers contextes. Mots-cles: bases de donnees temporelles, modeles de donnees temporelles, langages de requ^etes temporelles, representation du temps, compatibilite ascendante, bases de donnees a objet, ODMG
1 Introduction Most modern DBMS provide some elementary temporal datatypes to timestamp entities and associations. However, in these systems, a database state represents a snapshot of the modeled world as de ned by the last update. When the need to observe data evolution arises, their history has to be managed at the application level, increasing data and programs complexity. Temporal database systems aim at overcoming these de ciencies [TCG+93, Sno95a, EJS98]. Over the past two decades, research in temporal databases has been very proli c regarding temporal extension proposals to data models and query languages. Whereas in the relational framework these works have led to the consensus temporal query language TSQL2 [Sno95b], as well as two proposals to the ISO and ANSI SQL3 standardization committees [Mel97, SBJS98], equivalent results are signi cantly lacking in the object-oriented framework. Early attempts to de ne temporal extensions of object-oriented data models (see [Sno95a] for a survey) failed to become widely accepted, essentially due to the absence of a standard underlying data model. As the ODMG [CB97] proposal appeared and started to be adopted by the major object DBMS vendors, the idea of temporally extending it arose. Up to now and to our knowledge, three such extensions have been proposed, namely TAU, TOOBIS and T ODMG, respectively reported in [KT96], [TOO96a, TOO96b] and [BFGM98]. However, we argue that these proposals lack at least some of the following four important features:
Migration facilities : ensuring a seamless transition of applications running on top of a non-temporal system to a temporal extension of it. This feature was considered as fundamental during the SQL/Temporal design [SBJS98].
Representation independence : clearly separating the abstract and the representational
views of each new concept or construct during the model and language designs. For instance, most of the existing temporal data models adopt a particular encoding of temporal relations or attribute histories (generally based on interval timestamps) and de ne operators over them on the basis of this representation, leading to some undesirable tensions between query expressions and their intended semantics [Tom98]. The idea here is to de ne such operations independently of any particular representation.
Formal semantics : as pointed out in [Sno95a], \no temporal OO data model or query
language has a formal semantics". More recently, [BFGM98] introduces some formal speci cations at the object model level but does not addresses issues related to the query language. We argue that a formal semantics, both at the model and the language levels, would avoid many ambiguities generated by the richness and complexity of temporal database terminology and could serve as a basis for ecient implementation. 2
Freely-available implementation, enabling researchers and practitioners to experiment over it. Most of the available temporal DBMS implementations concern the relational framework [Boh95].
One of the major goals of the work around Tempos (Temporal Extension Models for Persistent Object Servers) [FCS97, Can97, SFC98, DFS98], is to de ne a temporal database framework integrating these features and to submit it to the temporal database community as a contribution towards a consensus temporal extension of ODMG's object model and languages. With this objective in mind, we propose the Tempos temporal data model and its associated schema de nition and query languages TempODL and TempOQL. This proposal synthesizes the main concepts studied in related works and formalizes them in a functional framework. It also integrates many novel features such as a seamlessly extensible model of time, a comprehensive set of update operators on temporal objects and properties, and a language for describing patterns of histories. The paper is structured as follows. Section 2 focuses on de ning the requirements related to application migration and representation independence, and shows why existing temporal extensions of ODMG fail to ful ll them. Sections 3, 4 and 5, describe the Tempos data model, and the schema de nition and query languages associated to it. In section 6 we present the prototype that has been developed to validate the feasibility of our proposal, and enumerate some applications that have been modeled and implemented in Tempos. Finally, in section 7 we end with a brief overview of the proposal and a discussion on future research directions.
2 Model requirements and related works In this section, we present some of the major requirements that guided the design of Tempos. These requirements may be divided into two categories: those which deal with the migration of data and application programs from a non-temporal to a temporal environment, and those which deal with the abstract modeling and querying of histories.
2.1 Migration requirements It is a well known fact that most of the temporal data models and languages that have been proposed in the literature, are actually extensions of \conventional" ones. A common rationale for this design choice is that the resulting models can be integrated into existing systems, so that applications built on top of these systems may rapidly bene t from the added technology. However, the smooth migration of existing data and application programs to temporal database systems may only be achieved if these latter ful ll some elementary compatibility re3
quirements. Surprisingly, such requirements have traditionally been neglected by the temporal database community: it is until relatively recently that notions such as seamless integration of time [GN93] or upward compatibility [BBJS97, SBJS98], have been seriously considered. Following [BBJS97, SBJS98], we are interested in specifying migration requirements between pairs of data models de ned as follows. De nition 1 (data model). A data model M is as a quadruplet (D, Q, U, [ ] M ) composed of a set of database instances D, a set of legal query statements Q, a set of legal update statements U, and an evaluation function [ ] M . Given an update statement u 2 U, a query statement q 2 Q and a database instance db 2 D, [ u(db)]] M yields a database instance, and [ q(db)]] M yields an instance of some data structure. Hence, a database instance is seen as an abstract entity, to which it is possible to apply updates (statements whose evaluation map a database instance into another one), and queries (statements whose evaluation over a database yield an instance of some data structure). We suppose that the equality is de ned over instances of data structures. We successively introduce two levels of migration requirements: upward compatibility and temporal transitioning support. The de nitions that we provide may be seen as adaptations to the object-oriented framework, of the notions of upward compatibility and temporal upward compatibility introduced in [BBJS97, SBJS98]. De nition 2 (upward compatibility). A data model M' = (D',Q',U',[ ] M 0 ) is upward compatible with another data model M = (D,Q,U,[ ] M ), i : - D D', Q Q' and U U' (syntactical upward compatibility in [BBJS97]) - For any db in D, for any q in Q, for any u1, u2, : : : , un in U and for any instants d1, : : : dn , dn+1 : dn+1(udn ( : : : ud2 (ud1 (db))))] M 0 d2 d1 [ qdn+1(udn 2 1 n n ( : : : u2 ( u1 (db))))] M = [ q Notice that in this latter expression, updates and queries, are parameterized by the instant at which they are issued. This is because, in some temporal data models, operations may depend on the instant at which they are issued as discussed in [CDI+97]. Apart from that, the above de nition may be applied to any other data model extension. In the setting of ODMG, the set of queries Q not only includes those which are submitted to the OQL interpreter, but also, all accesses to class extents and object properties via application programs. Similarly, the update operations include object creations and deletions, as well as updates to object properties. To illustrate upward compatibility, let's consider an ODMG compliant DBMS managing a database about documents and users of a library. Essentially, the database stores information 4
about document loans. Upward compatibility states that if the ODMG DBMS is replaced by a temporal extension of it, or equivalently, if a temporal cartridge is installed, then the data and the application programs accessing these data may be left intact. This implies in particular that the set of database instances recognized by the extension is a super-set of those recognized by the original DBMS, and that the database access and update statements have identical semantics in the original DBMS and in the temporal extension. Notice that at this stage, no notion of temporal support has been considered. Now, suppose that once the legacy applications run on the temporal extension, the database administrator decides that the history of the loans should be kept, but in such a way that legacy application programs may continue to be operational (at worst they should be recompiled). New applications, on the other hand, should perceive the property as being \historical". One way of ful lling this requirement is to o er two di erent views of the database: a \snapshot view" and a \temporal view", letting the applications choose among them. This leads to a notion of bi-accessible data model. De nition 3 (Bi-accessible data model). A bi-accessible data model is a quintuplet (D, Q, U, [ ] 1M , [ ] 2M ) such that (D, Q, U, [ ] 1M ) and (D, Q, U, [ ] 2M ) are data models. A bi-accessible data model (D, Q, U, [ ] SM , [ ] TM ) is said to be temporal, if (D, Q, U, [ ] SM , [ ] TM ) is a snapshot data model and (D, Q, U, [ ] TM ) is a temporal data model, upward compatible with the former. The second migration requirement that we introduce below, is an answer to the problem raised by the above scenario. It aims at ensuring the continuity of legacy code after the migration from a snapshot to a temporal schema. De nition 4 (temporal transitioning support). Given a function T which partially or totally transforms a snapshot database instance into a temporal one (i.e. T attaches temporal support to some classes, attributes and/or relationships in the database's schema), a bi-accessible temporal data model MT = (DT ,QT,UT [ ] SMT , [ ] TMT ) is said to o er temporal transitioning support, if for any db 2 DS , for any q 2 QS , for any u1 , u2 , : : : , un 2 US and for any instants d0 , d1 , : : : dn , dn+1 : d2 d1 dn+1 (udn ( : : : ud2 (ud1(T d0 (db)))))] S [ qdn+1(udn n ( : : : u2 (u1 (db))))] MS = [ q n 2 1 MT While upward compatibility can be achieved by simply adding new concepts and constructs to a model without modifying the existing ones, temporal transitioning support is more dicult to achieve. Indeed, [BBJS97] shows that almost none of the existing temporal extensions to SQL, including TSQL2, satisfy this latter requirement (called temporal upward compatibility by the authors). 5
It can be shown that the same remark holds for existing object-oriented temporal extensions, and in particular for the TAU [KT96] temporal object model. For example, consider a Document class with a property loaned by de ned on it. In the context of TAU, if some temporal support is attached to this property, then any subsequent access to it will retrieve not only the current value of the document's loaned by property (as in the snapshot version of the database), but also its whole history. TOOBIS does not exhibit this latter problem. However, in achieving temporal transitioning support, TOOBIS introduces some burden to temporal applications. Indeed, in TOOBIS TOQL for instance, each reference to a temporal property in a query should be pre xed by either keyword valid, transaction or bitemporal. This leads to rather cumbersome query expressions. Similar remarks apply to TOOBIS C++ binding. This approach is actually equivalent to duplicating the symbols for accessing data when adding temporal support, in such a way that for each temporally enhanced property x, there are actually two properties representing it in the database schema, say x and temporal x. In the example of the library database, this means that when adding temporal support to property loaned by, this temporal property is actually not modi ed and instead, a new temporal property is added (say temporal loaned by). We advocate a di erent approach: when temporal support is added to some component of a database schema S, yielding a new schema S', application programs are divided into two categories: those which view data as if its schema was S, and those which view it with schema S'. Therefore, the problem of temporal transitioning support is seen as a particular case of schema evolution, so that techniques developed in this context apply. The reason for adopting this approach instead of TOOBIS's one, may be stated simply: if a property is modi ed to add temporal support, temporal applications should perceive this property as being temporal.
2.2 Representation independence requirements 2.2.1 Point-based vs. interval-based temporal associations A temporal association is as a piece of data locating a fact in the time-line. Temporal associations may be classi ed into point-based or interval-based, depending on whether they associate facts to instants or to intervals [Cho94]. An interval-based association states that a fact is true during some interval, e.g. \The stock price raised by 50% between 1995 and 1999", without entailing that the fact is true at each instant in the interval, e.g. the above statement does not mean that the stock raised by 50% at each year between 1995 and 1999! On the other hand, a point-based association states that a fact is true at some point in time, observed with some precision (e.g. \The salary of some employee is 5000 at january 1998"). Temporal data models may be classi ed into point-based or interval-based, depending on 6
whether they manage interval or point-based temporal associations [BBJ98]. TSQL2 for instance is point-based: stating that a tuple belongs to a temporal relation during interval [i1,i2), means that this tuple belongs to the relation at each instant between i1 and i2 (i2 excluded). On the other hand, SQL2 enhanced with an ADT for modeling intervals may be considered as interval-based: nothing in the semantics of SQL2 indicates that if a tuple is timestamp with an interval [i1,i2], then the tuple belongs to the relation at each instant between i1 and i2. Some data models are hybrid either because they provide functions for transforming interval-based associations into point-based ones (e.g. IXSQL [Lor93] or SQL/Temporal [SBJS98]) or because they distinguish point-based from interval-based associations (e.g. TOOBIS [TOO96a]). It is worth noting that no temporal data model is actually purely interval-based. This is because point-based associations are prevalent in most temporal database applications [Cho94]. Tempos has been designed as a point-based data model, though we expect to extend it to deal with interval-based associations as well.
2.2.2 Representation of point-based associations In temporal data models, related temporal associations are grouped into temporal relations (in the relational framework) or into object or attribute histories (in the object-oriented and object-relational frameworks). Point-based temporal relations or histories may be represented in several ways. For instance, it is possible to associate an instant timestamp to every tuple in a temporal relation at the logical level [Tom98]. An alternative is to group several value-equivalent tuples into a single one, timestamped either by a temporal element [GN93], or by an interval. This latter is the most common approach in existing point-based data models. Operators on temporal data are then de ned over this interval-timestamped representation, which renders their formalization quite cumbersome: in addition to de ning the result of the operation itself, the semantics must also describe the way this result is to be encoded. The same remark applies to query expressions, which leads to some undesirable tensions between query expressions and their intended semantics [Tom98]. To illustrate this point, let's consider the query retrieve all departments where Ed has been since he rst moved from the accounting department, expressed in TOOBIS's TOQL: select distinct D2 from Employees as E, valid E.department as D1, valid E.department as D2 where E.Name = \Ed" and D1.name = \Accounting" and valid(D1) before valid(D2)
In this example, there is a clear di erence in the level of abstraction between the query expression in natural language and in TOQL: in the natural language formulation, there 7
is no reference to any maximal intervals during which Ed was in the accounting department, whereas valid(D1) and valid(D2) in TOQL's formulation are typical examples of such references. In addition, the notion of \since the rst time", does not appear in TOQL's expression. This mismatch re ects some lack of declarativeness in the language, and more precisely, the need for operators on histories allowing to reason about succession in time. Instead of providing such operators, TOQL, as well as most other temporal query languages, relies on an intervaltimestamped representation of histories, together with operators over intervals, for expressing most kinds of temporal queries. We advocate that exclusively relying on a xed representation of temporal data to de ne the semantics of temporal operators, or for query expression, is an undesirable feature in a temporal data model, and especially in an object-oriented one, since it tends to violate some basic principles of object-orientation such as encapsulation. Instead, speci c representation independent operators on histories should be provided, covering the fundamental temporal reasoning paradigms: succession, simultaneity, granularity change, etc. In this respect, our approach is di erent to those adopted in other works such as [RS93], [Sno95b], [KT96] and [TOO96a], and similar to those adopted in [WD93] and [GO93]. Nevertheless, we do not mean that setting a representation of histories is never useful for query expression. Indeed, some queries naturally involve such representations, e.g. which employees had a constant salary during an interval of at least three years [Sno95b], so that temporal query languages should also provide operators for setting a particular representation of histories based either on instants, intervals or sets of instants. The above considerations also apply to the modeling of temporal values. For instance, in most temporal data models, collections of instants are modeled as sets of disjoint noncontiguous intervals, (usually termed temporal elements ). While this representation is probably adequate in many cases, imposing it at the logical level is useless, and introduces a gap between the modeled concept and the corresponding data model construct. To summarize this discussion, we state a \representation independence" requirement on data models as follows: a temporal data model is said to be representation independent if (i) it de nes all operators on temporal values and associations independently of any representation; (ii) it provides operators accounting for di erent kinds of temporal reasoning, so that it does not exclusively relies on the representation of temporal data for query expression.
3 Temporal datatypes This section introduces the basic concepts for modeling temporal values and associations. These concepts are structured in a hierarchy of abstract datatypes and formalized in a func8
tional framework. We claim that the proposed datatypes are generic enough to be integrated into most existing object-oriented data models, and in particular, to be embedded into ODMG's built-in type hierarchy.
3.1 Time model 3.1.1 Time units We adopt a discrete, linear and bounded time model in which time is structured in a multigranular way [CR87, WJS95] by means of time units. A time unit is a partition of the time line into a set of convex sets: each of the elements of this partition is then seen as an atomic granule and every point of the time-line is approximated by the granule which contains it. Thus a time unit de nes the precision at which time is observed. The granules of a time unit are numbered by natural integers: the order among these integers de nes the notion of succession in time and the distance between them de nes the notion of duration. If a mapping can established between each granule of a time unit u1 and a set of consecutive granules of another unit u2, u2 is said ner than u1 (u1 u2), or conversely, u1 is said coarser than u2. For instance, the time unit month is ner than the unit year but coarser than the unit day, because each year contains an integer amount of months and each month contains an integer amount of days. The ner than relation is a partial order because some pairs of units are not comparable (e.g. units month and week ). We assume that there is a unique nest unit which as usual is called the chronon. For each pair of time units hu1, u2i such that u1 u2, two conversion functions are de ned: one for expanding a granule of the coarser unit (u2) into an interval of granules of the ner one (u1) (noted u2;u1), and the other for approximating a granule of u1 by a granule of u2 (noted u1;u2), as shown in gure 1. Units u1 and u2 (u1 u2) are said to be regular if the intervals of granules generated by u2;u1 have all the same cardinality. αu1,u2(x) Approximation of x
x u2
u1
x Expansion of x ε u2,u1 (x)
Figure 1: unit expansion and approximation A unit system is a a sequence of comparable units in decreasing order according to the ner than relation, e.g. [Year, Month, Day]. As detailed in the next paragraphs, unit systems 9
are used to express temporal values. The nest unit of a unit system de nes the precision at which temporal values are expressed in this system.
3.1.2 Basic temporal types A duration is a number of granules of a time unit measuring an amount of time at the precision de ned by this unit. Hence, values of type duration are pairs made of an integer and a time unit. Durations are signed so as to di erentiate forward from backward motion of time. Instant relative durations (or relative durations in short) are expressed according to a unit system as in \1 month and 10 days". The quali er relative points out the fact that the conversion in the nest unit of the unit system depends on the instant to which the duration is related, unless units are mutually regular as in \1 year and 3 months", in which case they can be mapped into absolute durations. An instant is as an approximation of a connected region of the time line by a granule of an unit, called its observation unit. An instant is a point with respect to its observation unit. However, it may be seen as an interval with respect to a ner one. As durations, instants may be viewed as pairs composed of an integer and a unit, but unlike them, their semantics is de ned with respect to some origin on the time line. Several operators are de ned on instants and durations: predicates related to the chronological order, addition and subtraction of durations, distance function between two instants, addition of instants and durations, and conversion from one unit to another. [CD97, Can97] analyze the cases where these operations may deal with multi-granular arguments. Input and output of instants and durations are managed through an extensible set of formats. Abstractly, a format is de ned as a mapping from a regular language (i.e. a set of words recognized by a regular expression) to a set of temporal values at a given granularity. At the concrete level, a format is composed of a regular expression which describes the syntax of the recognized strings, a unit system which determines the interpretation of the numerical values or other granule references that appear in the string, and a permutation which allows to put these granule references in a canonical order. Indeed, the order of the granule references in the European date format is not the same as in the American one, so that \1/2/1998" means \February the 1st 1998" in Europe and \January the 2nd 1998" in the US. For a more detailed description of the notion of format, the reader may refer to [CD97, Can97].
3.1.3 Temporal sequences At an abstract level, a temporal sequence (TSequence) is de ned as a nite, chronologically ordered sequence of instants observed at some granularity. Since the instants in the sequence are canonically ordered, this notion models a set of instants. Among the various representa10
tions of temporal sequences, we distinguish two : sequences of instants (ISequences), which are in fact extensional representations of temporal sequences, and coalesced sequences of intervals (DSequences). Moreover, we distinguish two particular kinds of temporal sequences, whose characteristics allow to de ne speci c operations over them: periodic sequences of instants (PSequences) and intervals. The latters are in fact particular cases of the formers, since an interval is a periodic sequence of instants with period one. The detailed description of these types and their operations may be found in [CD97, Can97]. Among these operations we can mention the set operations (union, intersection, di erence), the type constructors (adding or taking o an instant to/from a TSequence, setting the period of a PSequence, etc.), and the operators for casting one representation into another. In addition, comparison operators on intervals are de ned on the basis of Allen's interval relations [All83]. All these operators are de ned independently of any particular representation so as to ful ll the representation independence requirement stated in section 2. Figure 2 presents a UML [FS97] class diagram modeling of the types described above and their relationships. finerThan *
*
Unit
{ordered} 1
1
*
intersection(t: Tset): Tset union(t: Tset) : Tset
...
*
Instant
TSequence
UnitSystem 1
Duration
expand(u : Unit) : Interval approx(u : Unit) : Instant add(d : Duration) : Instant subtract(d: Duration): Instant
add(d : Duration): Duration subtract(d: Duration): Duration
...
... PSequence
DSequence
AbsoluteDuration
ISequence
RelativeDuration
*
multiply(i : integer) : Absolute... divide(i: integer) : Absolute... convert(u: Unit) : Duration
...
Interval meets(t: Interval) : boolean before(x: Interval) : boolean
...
Figure 2: Temporal types
3.2 Historical model At an abstract level, a history is de ned as a function from a nite set of instants to a set of values of a given type. The domain and the range of a history are respectively called its temporal and structural domain. 11
In the sequel, we formally describe the types and operators related to histories. This description uses functional notations, since most of the operators on histories are higherorder operators (i.e. functions whose parameters may themselves be functions), and a simple ODMG-like description of them would not be accurate enough. The following notations are used: T1 ! T2 stands for the type of all functions with domain T1 and codomain T2. fTg and [T] respectively denote the type of sets of T and sequences of T. hT1, T2, : : : , Tni designates the the type of tuples whose ith component is of type Ti (1 i n); tuple components may be labeled using the notation hL1 : T1, L2 : T2, : : : , Ln : Tni. T1 denotes an instantiation of the parameterized type T1 with type T2: in particular, History denotes the type of histories with structural values of type T. hv1, v2, : : : , vni denotes a tuple value whose ith component is vi (1 i ni. Finally, if x is an instant or a temporal sequence, then Unit(x) denotes its observation unit. The following speci cation introduces the History ADT and its elementary selectors. type History T = Instant ! T TDomain: History T ! TSequence /* temporal domain */ Unit: History T ! Unit /* Unit(h) = Unit(TDomain(h)) */ SValue: History T , Instant ! T /* SValue(H, I) is the structural value at instant I */ /* precondition: I 2 TDomain(H) */ SDomain: History T ! f T g /* structural domain */
Histories may be represented in several ways, mainly by means of collections of timestamped values, termed chronicles. Among these representations some are useful for query expression, so that speci c operators are de ned on the History ADT allowing to represent a history in any of these forms. Concretely, a history may be represented by at least three kinds of chronicles: - Instant-based representation: chronologically ordered sequence of instant-timestamped values, e.g. [h1, v1i, h2, v1i, h4, v1i, h5, v2i, h6, v2i, h7, v2i, h8, v3i, h9, v1i, h10, v1i]. Such sequences are termed IChronicles. - Interval-based representation: chronologically ordered, coalesced sequence of intervaltimestamped values, e.g. [h[1..2], v1i, h[4..4], v1i, h[5..7], v2i, h[8..8], v3i, h[9..10], v1i]. This kind of sequence is called an XChronicle. - Temporal sequence-based representation: set of distinct values timestamped by disjoint temporal sequences, e.g. f hf1, 2, 4, 9, 10g, v1i, hf5, 6, 7g, v2i, hf 8 g, v3i g, which are termed DChronicles. The following operators are provided to switch from histories to either of these representations and vice-versa. 12
IHistory : [htvalue : Instant, svalue : Ti] ! History /* Precondition: let [IS1, : : : ,ISn ] be the parameter of a call to operator IHistory: 8k 2 [1..n?1] (Unit(ISk.tvalue) = Unit(ISk+1 .tvalue) ^ ISk.tvalue < ISk+1.tvalue) */ XHistory : [htvalue : Interval, svalue : Ti] ! History /* Precondition: let [XS1 , : : : ,XSn ] be the parameter of a call to operator XHistory: 8k 2 [1..n-1] (Unit(XSk .tvalue) = Unit(XSk+1 .tvalue) ^ XSk .tvalue < XSk+1 .tvalue ^ (XSk .tvalue meets XSk+1 .tvalue ) XSk .svalue 6= XSk+1 .svalue)) */ DHistory : f htvalue : TSequence, svalue : Ti g ! History /* Precondition: let SDS be the parameter of a call to DHistory: 8 DS, DS' 2 SDS (DS 6= DS' ) Unit(DS.tvalue) = Unit(DS'.tvalue) ^ DS.tvalue \ DS'.tvalue = ; ^ DS.svalue 6= DS'.svalue) */ IChronicle: History ! [htvalue : Instant, svalue : Ti] /* IHistory(IChronicle(h)) = h */ XChronicle: History ! [htvalue : Interval, svalue : Ti] /* XHistory(XChronicle(h)) = h */ DChronicle: History ! fhtvalue : TSequence, svalue : Tig /* DHistory(DChronicle(h)) = h */
3.3 Algebraic operators on histories Algebraic operators on histories are classi ed into two categories: intra-point and inter-point. An operator is said intra-point if the structural value of the resulting history at a given instant depends exclusively on the structural value of the argument histories at that instant, otherwise it is said to be inter-point (see gure 3). Notice that this classi cation is closed under composition: the composition of two intra-point operators yields an intra-point operator and the same is true of inter-point operators. operators on histories
intra-point
selection
The structural value of the result at a given instant depends on the structural value(s) of the argument(s) at that instant
aggregation
join
inter-point
The structural value of the result at a given instant depends on an arbitrary subset of the argument
grouping
succession in time ...
Γ in
Γ
if
Map
internal
external
sum
avg
...
UGroup
DGroup
AfterFirst
BeforeFirst ...
Figure 3: Taxonomy of algebraic operators on histories The semantics of each operator is formally described below by means of a rst-order calculus-like expression de ning the graph of the resulting history (a set of pairs hinstant, 13
valuei) in terms of that of the argument(s).
3.3.1 Intra-point operators Intra point operators ?if and ?in restrict the temporal domain of a history to those instants at which a given condition is true. ?if : History, (T ! boolean) ! History /* h ?if P = fhI,vi j hI,vi 2 h ^ P(v)g */ ?in : History, TSequence ! History /* h ?in S = fhI,vi j hI,vi 2 h ^ I 2 Sg */
The intra-point operator Map on the other hand, applies a given function to each structural value of a history. Map: History, (T ! T') ! History i2, [i1.. i2] represents the empty interval. - [i j d] is equivalent to [i.. i + d] - [i..] is equivalent to [i.. forever(u)] where u is the observation unit of i. - [..i] is equivalent to [beginning(u).. i] where u is the observation unit of i. - Periodic temporal sequences constructors - psequence(i1..i2 j d) denotes the periodic sequence containing all instants of the form i1 + k d (k 0) and less than or equal to i2 , or the empty sequence if i1 > i2 . - Other temporal sequences constructors - isequence(bi) is the temporal sequence containing all instants in bi. - dsequence(bx) is the DSequence containing all instants lying in at least one of the intervals in bx. Notice that since the result is a DSequence, automatic coalescing of overlaping or contiguous intervals in bx is ensured. Most of the operators on temporal sequences de ned by the time model have their counterpart in TempOQL. In particular, some OQL constructs on collections are overloaded to deal with temporal sequences. In particular, the constructs max and min allow to access the smallest and largest instants in a temporal sequence, and atten transforms a collection of temporal sequences into a single one. For a complete list of TempOQL operators over temporal values the reader may refer to [CD97]. 32
5.2.2 Access mode indicators To illustrate the notion of access mode and its impact on TempOQL, let's consider the following query. select struct(t : b.Trademark, p : b.price) from TheBottles as b
In the temporal mode, this query has type bag and will retrieve for each bottle ever sold, the history of its prices. Conversely, if the upward compatible mode is assumed, the query type is bag and it retrieves the trademarks of all currently sold bottle-types with their corresponding prices. Two constructs are provided in TempOQL to set the access mode of a query or subquery: snapshot and temporal, which respectively correspond to the upward compatible and the temporal modes. Their syntax is de ned by the following rules: ::= ::=
snapshot temporal
The priority of these constructs is smaller than that of all the other TempOQL constructs. The mechanisms used to determine the access mode for sub-queries which are not in the scope of any of these operators are implementation-dependent and will be discussed in section 6.
5.2.3 Querying histories In the following, we describe most of the constructs for handling histories in TempOQL. For each construct, we give its typing rule, its syntax and its semantics, using a notation similar to that of [RS97], which provides a complete formalization of OQL queries. More precisely, the formalization of a construct is made up of four parts: - Preconditions: they describe subtyping constraints on the types appearing in the typing part, as well as some constraints on sub-queries (such as a variable being free in a subquery). Some of the typing preconditions will make reference to subtypes of History and subtypes of Instant, although none of such subtypes are actually de ned by the model. This is to achieve some extensibility, by allowing TempOQL constructs to be applicable to user-de ned subtypes of History and Instant. - Syntax: in a BNF-like notation with terminal symbols typeset in boldface. premise . The notation q::t - Typing: a typing rule for the construct using the notation implication means that the query q has type t, while q[x::t']::t means that query q has type t assuming that variable x has type t'. 33
- Semantics: described in terms of expressions involving operators of the Tempos historical model. The semantics of a query is parametrized by a valuation function which determines the values of free symbols in the query. The notation [x v] denotes the valuation equal to except that it assigns value v to symbol x. The preconditions that apply to the operators de ning the semantics of a construct (in particular those related to the observation units of the argument histories), also apply to the construct itself. Some operators are illustrated through queries on the application presented above. In all these queries, it is assumed that the access mode is temporal.
Selectors The following functions may be applied to queries whose type is a subtype of History: tdomain, sdomain, unit and exists. This latter corresponds to the emptiness test on
histories. These constructs have all a functional syntax and their semantics is straightforwardly de ned in terms of the corresponding selectors on histories. Q.1 : Selectors: structural domain extraction For each client store, give its name and the name of the persons who managed it at least once. /* query type: bag> */ select struct(cname: c.name, mname: sdomain(c.manager)) from TheClients as c
OQL's list accessor construct : : : [ : : : ] is overloaded to deal with histories. It's semantics is de ned in terms of the SValue selector on histories. Preconditions: is a subtype of History; is a subtype of Instant Syntax: ::= '[' ']' 0 q 1 :: ; q2 :: Typing: q1[q2] :: 0 Semantics: [ q1[q2]] = SValue([[ q1] , [ q2] )
Q.2 : Selectors: structural value at a given instant
For each bottle-type, retrieve its trademark and its production on January the 1st 1996.
/* query type: bag> */ select struct (trademark: p.trademark, prod: p.production[@\1/1/1996"]) /* @ introduces an instant litteral; the europ from TheProducts as p
History restriction and pointwise application of a function The during construct restricts a history to those instants lying in a given temporal sequence, as de ned by the ?in operator on histories. 34
Preconditions: 1 is a subtype of History; 2 is a subtype of TSequence or a subtype of Instant Syntax: ::= during q1 :: 1; q2 :: 2 Typing: q during q2 :: History 1 Semantics: [8q1 during q2] = > if 2 subtype of TSequence < [ q1] ?in [ q2] [ q1] ?in if 2 subtype of Instant and > : expand([[ q2] , Unit([[ q1] )) Unit([[ q1] ) Unit([[ q2] )
Q.3 : Restriction on temporal values
For each bottle type, give its trademark and the history of its production during 1997. /* query type : bag */ select struct (T: b.trademark, P: b.production during @\1997") /* Instant @\1997" is automatically expanded into an interval at the granularity of the day */ from TheBottles as b
The when construct on the other hand, is a conterpart of the ?if operator on histories: Preconditions: is a subtype of History; variable x is free in q2 Syntax: ::= as when 0 0 q 1 :: ; q2[x :: ] :: boolean Typing: q as x when q :: History 1 2 Semantics: [ q1 as x when q2] = [ q1] ?if v [ q2] [x v] The when construct is a particular case of the following one. Preconditions: 2 is a subtype of History; variable x is free in q1 and q3 Syntax: ::= map on as when 0 0 0 q 2 :: 2 ; q1[x :: 2 ] :: 1 q3[x :: 2 ] :: boolean Typing: map q on q as x when q :: History 1 2 3 1 Semantics: [ map q1 on q2 as x when q3] = Map([[ q2] ?if v [ q3] [x v], w [ q1] [x w]) More precisely: q1 as x when q2 map x on q1 as x when q2
The map : : : on : : : construct (without when) can be introduced as a macro. 35
map q1 on q2 as x map q1 on q2 as x when true
Despite some similarities between the above construct and the plain OQL's select : : : from : : : where : : : , there are some fundamental di erences between them, both at the semantical and the syntactical levels. At the semantical level, it is important to note that the result of this construct is a history, instead of a collection as for OQL's select : : : from : : : At the syntactical level, there is no notion of projection attribute in the project clause and the \star" shortcut is not allowed. In addition, only one history may appear in the on clause. To relate several histories, this construct should be merged with the join construct presented below.
Operators for merging histories The constructs join and ojoin correspond to the inner and outer temporal joins on histories. Their syntax is similar to that of the struct construct in plain OQL, so as to label the components of the resulting tuple-valued history. Preconditions: 1, : : : 2, : : : n are respectively subtypes of History, History, : : : History; l1, l2, : : : ln are valid labels for structured types. Syntax: ::= join( : f, : g > ) 0 0 0 q 1 :: 1 ; q2 :: 2 ; : : : qn :: n Typing: join(l : q ; l : q ; : : : ; l : q ) :: History 1 1 2 2 n n 1 1 2 2 n n Semantics: [ join(l1: q1, l2: q2, : : : ln : qn)] = [ q1] \ [ q2] , \ : : : \ [ qn] Notice that the above semantic rule does not account for the tuple-component labels that are attached to the structural values of the resulting history. This is because the Tempos data model is formalized in a functional framework, where the existence of tuple types without labels is assumed, whereas such type constructors do not exist in the ODMG's object model. The following query illustrates the use of the inner temporal join. Q.4 : Restriction on structural values and temporal join When were bottles of trademark T1 produced in larger quantity than bottles of trademark T2? /* query type: TSequence (with observation unit = Day) */
atten(select tdomain(join(p1: b1.production, p2: b2.production) as j when (j.p1 > j.p2) ) from TheBottles as b1, TheBottles as b2 where b1.Trademark =\T1" and b2.Trademark = \T2")
The construct ojoin is de ned similarly. To account for the semantics of the outer join, the structural values of the resulting history may contain references to null values. Therefore, if the structural values of the argument histories are of non-nullable literal types 1 and 2 (e.g. integer and real), then the structural values of the result are of type struct (see [CB97] for details on nullable types in ODMG). 36
In the above example query, ojoin could be used to take into account that when T2 has no production, the production of T1 may be considered as being greater than that of T2 : /* query type: TSequence */
atten(select tdomain(ojoin(p1: b1.production, p2: b2.production) as oj when oj.p1 != nil and (oj.p2 = nil or (oj.p1 > oj.p2))) from TheBottles as b1, TheBottles as b2 where b1.Trademark =\T1" and b2.Trademark = \T2")
Finally, the intersect and di erence constructs de ned over collection types in OQL are extended to historical types in TempOQL.
Aggregations and grouping All OQL's aggregation functions on collections are extended
to deal with subtypes of History. The only exception to this is count which is actually renamed to duration when applied to a history, i.e. duration(h) yields the duration of the temporal domain of history h. The semantics of these constructs is obvious from the de nition of the corresponding operators on histories and we therefore omit it. The map .. on ... when construct de ned on histories is extended with a group by and a having clause, accounting for grouping. The grouping criteria may be a temporal unit or a duration. Similar remarks to those formulated for the map ... on ... when construct apply: the when and the having clauses are optional. Preconditions: 2 is a subtype of History; variable x is free in q3; variable partition is free in q1 and q5; is a subtype of Unit; is a subtype of AbsoluteDuration Syntax: ::= map on as when group by having q2 :: 2; q1[partition :: History] :: 1; q3[x :: 20 ] :: boolean q4 :: _ q4 :: ; q5[partition :: History] :: boolean typing: map q1 on q2 as x when q3 group by q4 having q5 :: History Semantics: 8 [ map q1 on q2 as x when q3 group by q4 having q5] = > > Map(UGroup([[ q2] ?if v [ q3] [x v], [ q4] ) if q4 :: > < ?if w [ q5] [partition w], y [ q1] [partition y])
> > Map(DGroup([[ q2] ? v > : ? w [ q5] [partition
if
if
[ q3] [x v], [ q4] ) if q4 :: w] , y [ q1] [partition y])
37
Q.5 : Aggregations and unit-based grouping
For each bottle type, and for each month when this bottle was produced, how many days its production was greater than 100 on that month? /* query type: bag> */ select struct(trademark: b.trademark, production: map duration (partition) /* partition is a history at the granularity of the day. */ on b.production as p when p > 100 group by Month) from TheBottles as b
Q.6 : Aggregations and duration-based grouping
For each bottle type, and for each 10-day period during which the total production of this bottle type is greater than 10000, retrieve its average production on that period. /* query type: bag> */ select struct(trademark: b.trademark, avgprod : /* The result of the following sub-query is a history at the granularity of the day: for a given day, the average production of the 10-day period starting on that day is retrieved, provided that the total production on that period is greater than 10000 */ map avg(partition) on b.production as p group by #\10 days" having sum(partition) > 10000 from TheBottles as b
Operators for setting a representation In addition to providing operators for managing
histories independently of their representation, TempOQL also allows to set a particular representation of histories. By iterating on the resulting collections, it is then possible to express temporal queries by explicitly referencing the timestamps associated to property values as in TSQL2 and TOOBIS{TOQL. Three constructs to cast histories into chronicles are provided: ichronicle, xchronicle and dchronicle. They respectively return an ordered list of instant-timestamped values, an ordered list of interval-timestamped values, and a set of temporal sequence-timestamped values. We describe the semantics of the rst of these constructs. 38
Preconditions: is a subtype of History Syntax: ::= ichronicle() 0 q :: Semantics: [ ichronicle(q)]] = IChronicle([[ q]] ) Notice that as for the join construct, the above semantic rule does not account for the tuple labels which are attached to the result. Q.7 : Setting a representation Who managed store S during an uninterrupted period longer than the longest uninterrupted period during which Ed managed it? [Sno95b] /* query type: set */ select distinct ms2.svalue from TheClients as c, xchronicle(c.manager) as ms1 where c.name = \S" and duration(ms1.tvalue) > max(select duration(ms2.tvalue) from xchronicle(c.manager) ms2 where ms2.svalue = \Ed")
To obtain a history from a bag of timestamped values, the history construct is provided. For instance, if q is a query of type bag, then history(q) is a query of type History. Its semantics is given by the IHistory operator de ned in section 3.2. Construct history may also be applied to bags of interval-timestamped or temporal sequence-timestamped values.
Operators for reasoning about succession in time The after rst before rst, afterlast
and beforelast constructs are straightforward adaptations of the corresponding operators on histories. Their syntax is similar to that of the when construct. Preconditions: is a subtype of History; variable x is free in q2 Syntax: ::= as after rst 0 0 q 1 :: ; q2[x :: ] :: boolean Typing: q as x after rst q :: History 1 2 Semantics: [ q1 as x after rst q2] = AfterFirst([[ q1] , v [ q2] [x v]) To reason about changes in time (e.g. retrieving instants when the value of a history changes), it is useful to reason in terms of the sequence of consecutive pairs of elements in a chronicle. The pairs construct on lists, used in conjunction with an operator for setting a representation, allows to do so. 39
Preconditions: l1 and l2 are valid labels for structured types. Syntax: ::= pairs(, , ) :: list Typing: pairs(l ; l ; q) ::qlist 1 2 8 Semantics: > if count(S) 1 < list() [ pairs(l1, l2, S)] = > list(struct(l1 : S[0], l2 : S[1])) + : [ pairs(l1, l2, S[1:count(S) ? 1])] otherwise
Q.8 : Succession in time
For each price increase of the bottles of trademark T, give the new price, the date when the price raised and the elapsed duration until the next increase. /* query type: bag> */ select struct (newPrice: p.next.svalue, raiseDate: min(p.next.tvalue), /* \min" yields the smallest instant in a temporal sequence */ duration: duration(p.next.tvalue)) from TheBottles as b, pairs(current, next, xchronicle(b.price)) as p where b.trademark = \T"
6 Implementation and applications Tempos has been implemented on top of the object-oriented DBMS O2 . This implementation
[DCFS98] consists of a library of classes corresponding to the ADT hierarchies de ned in the the time and historical models, and of two preprocessors implementing respectively TempOQL and TempODL. A temporal metadata manager accounts for the communication between the schema de nition and the query language preprocessors. An ongoing e ort aims at designing and implementing an API of this module compatible with the meta-object interface de ned by ODMG 2.0. The library of temporal classes has been entirely implemented in the O2's proprietary database programming language O2C, while the preprocessors and the metadata manager have been primarily implemented in C using code generation tools such as Lex and Yacc. Figure 6 illustrates the prototype architecture. The visualization module referenced in the architecture is part of an ongoing work on applying visualization paradigms for the interactive analysis of data resulting from temporal queries. As the preprocessor, this module uses metadata related to the temporal characteristics of classes and properties. Another module referenced in the architecture concerns the retrieval of patterns on histories. This module implements a set of operators for selecting temporal objects based on 40
External programs
End User
Visualization
TempODL pre-processor
TempOQL pre-processor
Temporal library Pattern matching
Reglo
Histories Formats
Temporal metadata manager
Administrator
Temporal types Time units
O2
Figure 6: Prototype architecture complex criteria dealing with the sequenced structure of histories. The de nitions of these operators rely on a pattern-matching language [DFS98] whose constructs are based on regular expressions with time constraints. The implementation of these operators exploits automatabased techniques. In the current interactive TempOQL implementation, access modes for queries that are not in the scope of a access mode indicator (see section 4.5.2), are determined by the value of a global variable that can be interactively set by the user. Our current works on architectural and implementation issues aim at integrating the notions related to temporal transitioning support at the programming-language binding level. The idea here is to design an implementation of the concepts of temporal class, temporal property and access mode on each of the programming language bindings de ned by ODMG (i.e. SmallTalk, C++ and Java bindings). The Tempos prototype has been used to implement applications from several contexts. In particular, we have worked on an application dealing with the management of annotated time series for economical analysis [Can97], and an application concerning the analysis of the resources and space utilization over time, in a ski resort located in the French Alps [FCD+98]. In addition, the Tempos prototype has been demonstrated at several conferences and meetings (e.g. [DCFS98]), and will eventually be available in the public domain.
7 Conclusion and future work The main contribution of this paper is a comprehensive temporal database framework unifying most of the concepts, requirements and functionalities recognized as necessary to temporally extend existing DBMS. This framework is composed of a time model, a history model, and extensions of ODMG's object model, schema de nition language and query language. 41
The time model de nes simple and complex temporal types with respect to an extensible set of time units. Time values are manipulated through a rich collection of functions organized in an ADT hierarchy. These ADT can be straightforwardly integrated into the ODMG's prede ned type hierarchy. The history model provides an ADT dedicated to the notion of history and a wide variety of representation independent operators over it. These operators, together with those de ned on the types of the time model, form the basis for the proposed extension of ODMG's OQL. The temporally extended object model ful lls two important requirements related to legacy code migration: upward compatibility and temporal transitioning support. The former states that a database may be transparently migrated from an ODMG system to a temporal extension of it. The latter allows non-temporal legacy code to remain usable even after a database schema is modi ed to add temporal support to some of its components. Temporal transitioning support is ensured by clearly separating temporal properties from the history of their values: a temporal property may have a historical value in the context of a temporal application and an \snapshot" value in the context of a non-temporal one. In addition, update operators on temporal properties are de ned in such a way that updates done by non-temporal applications are compatible with those performed by temporal ones. All these models and languages have been formalized at the syntactical and the semantical level, and a prototype on top the O2 DBMS has been developed on the basis of this formalization. This prototype has been used to develop several applications from various contexts (GIS, time series, etc.). Currently, we are planning to extend this work in several directions: - User interaction: developing and applying visualization paradigms and tools to ease the interactive analysis and manipulation of data resulting from temporal queries. - Spatio-temporal datatypes: studying design and implementation issues related to the management of interpolated histories of spatial objects such as points or regions. Perhaps, this could be an insightful approach to modeling and querying moving objects [GBE+98]. - Sequence Databases: unifying the concepts and constructs developed in the context of Tempos and other temporal data models, to provide a general framework for managing all kinds of sequenced data: time-series, histories, data ows, videos, etc., following the rst e ort in this direction reported in [SLR96].
Acknowledgments: we wish to thank Jean-Francois Canavaggio for his participation on the
initial design and implementation of Tempos.
42
References [All83] [BBJ98] [BBJS97] [BFGM98] [Boh95] [Can97] [CB97] [CD97] [CDI+97] [CG94] [Cho94] [CR87] [DCFS98] [DFS98]
J.F. Allen. Maintaining knowledge about temporal intervals. Communications of the ACM, 26(11), November 1983. M. Bohlen, R. Busatto, and C.S. Jensen. Point-based versus interval-based temporal data models. In Proc. of the 14th Int. Conference on Data Engineering, pages 192{200, 1998. J. Bair, M. Bohlen, C.S. Jensen, and R.T. Snodgrass. Notions of upward compatibility of temporal query languages. Technical Report TR-6, Time Center, 1997. E. Bertino, E. Ferrari, G. Guerrini, and I. Merlo. Extending the ODMG object model with time. In Proceedings of the European Conference on Object-Oriented Programming (ECOOP), Brussels, Belgium, July 1998. M. Bohlen. Temporal database system implementations. SIGMOD record, 24(4):53{60, December 1995. J.-F. Canavaggio. TEMPOS, un modele d'historiques pour un SGBD temporel. These de doctorat, Universite Joseph Fourier, Grenoble (France), novembre 1997. R.G.G. Cattell and D. Barry, editors. The Object Database Standard: ODMG 2.0. Morgan Kaufmann, 1997. J.-F. Canavaggio and M. Dumas. Manipulation de valeurs temporelles dans un SGBD a objets. In actes du XV congres INFORSID, Toulouse, juin 1997. English version at URL ftp://ftp.imag.fr/pub/STORM/PUBLICATIONS/1997/mtv.ps.gz. J. Cli ord, C. Dyreson, T. Isakowitz, C. Jensen, and R. Snodgrass. On the semantics of \Now" in databases. ACM Transactions on Database Systems, 22(2):171 { 214, June 1997. T. Cheng and S. Gadia. A pattern matching language for spatio-temporal databases. In proc. of the 3rd International Conference on Information and Knowledge Management (CIKM), Gaithersburg, MD (USA), November 1994. J. Chomicki. Temporal Query Languages: A Survey. In proc. of the International Conference on Temporal Logic, Bonn, DE, 1994. J. Cli ord and A. Rao. A simple general structure for temporal domains. In Conference on Temporal Aspects in Information Systems, Sophia-Antipolis, May 1987. AFCET. M. Dumas, J.-F. Canavaggio, M.-C. Fauvet, and P.-C. Scholl. TEMPOS: managing time and histories on top of OO DBMS. In proc. of EDBT'98 demo session, Valencia (Spain), March 1998. M. Dumas, M.-C. Fauvet, and P.-C. Scholl. Handling temporal grouping and pattern-matching queries in a temporal object model. In proc. of the CIKM International Conference, Bethesda, MD (USA), November 1998. 43
[EGS98] [EJS98]
O. Etzion, A. Gal, and A. Segev. Extended update functionality in temporal databases. In Etzion et al. [EJS98]. O. Etzion, S. Jajodia, and S.M. Sripada, editors. Temporal Databases: Research and Practice. Springer Verlag, LNCS 1399, 1998.
[Eme90]
E.A. Emerson. Temporal and modal logic. In J. van Leeuwen, editor, Handbook of Theoretical Computer Science, volume 2. Elsevier Science Publisher, 1990. [FCD+98] M.-C. Fauvet, S. Chardonnel, M. Dumas, P.-C. Scholl, and P. Dumolard. Analyse de donnees geographiques : application des bases de donnees temporelles. Revue Internationale de Geomatique, 8(1-2), November 1998. [FCS97] M.-C. Fauvet, J.-F. Canavaggio, and P.-C. Scholl. Modelling histories in object DBMS. In proc. of the 8th International Conference on Database and Expert Systems Applications (DEXA), Toulouse (France), September 1997. Springer Verlag. LNCS 1308. [FS97] M. Fowler and K. Scott. UML Distilled: Applying the Standard Object Modeling Language. Addison Wesley, 1997. [GBE+98] R. Guting, M. Bohlen, M. Erwig, C. Jensen, Lorentzos N, M. Schneider, and M. Vazirgianis. A foundation for representing and querying moving objects. Technical Report 238, FerUniversitat das Hagen (Germany), 1998. [GN93] S. K. Gadia and S. S. Nair. Temporal databases: a prelude to parametric data. In Tansel et al. [TCG+ 93]. [GO93] I. A. Goralwalla and M. T. Ozsu. Temporal extensions to a uniform behavioral object model. In proc. of the 12th International Conference on the Entity-Relationship Approach - ER'93, LNCS 823. Springer Verlag, 1993. [KT96] I. Kakoudakis and B. Theodoulidis. The TAU Temporal Object Model. Technical Report TR-96-4, TimeLab, University of Manchester (UMIST), 1996. [Lor93] N. A. Lorentzos. The Interval-extended Relational Model and its application to valid-time databases. In Tansel et al. [TCG+93]. [Mel97] J. Melton, editor. SQL/Temporal. ISO/IEC JTC 1/SC 21/WG 3 DBL-LGW-013, 1997. [RS93] E. Rose and A. Segev. TOOSQL - a temporal object-oriented query language. In Springer Verlag, editor, proc. of the 12th International Conference on the EntityRelationship Approach - ER'93, LNCS 823, 1993. [RS97] H. Riedel and M.H. Scholl. A formalization of ODMG queries. In Proc. of the 7th Int. Conference on Data Semantics (DS-7), Leysin, Switzerland, October 1997. Chapman & Hall. [SA85] R. T. Snodgrass and I. Ahn. A taxonomy of time in databases. In proc. of ACM SIGMOD, May 1985. 44
[SBJS98] R.T. Snodgrass, M. Bohlen, C. Jensen, and A. Steiner. Transitioning temporal support in TSQL2 to SQL3. In Etzion et al. [EJS98]. [SFC98] P.-C. Scholl, M.-C. Fauvet, and J.-F. Canavaggio. Un modele d'historique pour un SGBD temporel. TSI, 17(3), mars 1998. Numero thematique \Bases de donnees". [SLR96] P. Seshadri, M. Livny, and R. Ramakrishnan. The design and implementation of a sequence database system. In Proc. of the Int. Conference on Very Large Databases (VLDB), pages 99 { 110, Bombay, India, 1996. [Sno95a] R. T. Snodgrass. Temporal object-oriented databases: a critical comparison. In W. Kim, editor, Modern database systems. The object model, interoperability and beyond, chapter 19. Addison Wesley, 1995. [Sno95b] R. T. Snodgrass, editor. The TSQL2 temporal query language. Kluwer Academic Publishers, 1995. [SS93] A. Segev and A. Shoshani. A temporal data model based on time sequences. In Tansel et al. [TCG+ 93]. [TCG+ 93] A. U. Tansel, J. Cli ord, S. Gadia, S. Jajodia, A. Segev, and R. Snodggrass, editors. Temporal Databases. The Benjamins/Cummings Publishing Company, 1993. [Tom98] D. Toman. Point-based temporal extensions of SQL and their ecient implementation. In Etzion et al. [EJS98]. [TOO96a] TOOBIS ESPRIT Project. TODM, speci cation and design. Deliverable T31TR.1, MATRA CAP SYSTEMES { O2 Technology, December 1996. [TOO96b] TOOBIS ESPRIT Project. TOQL speci cation. Deliverable T33TR.1, University of Athens, National Technical University of Athens, 01-PLIFORIKI S.A., O2 Technology, December 1996. [WD93] G.T.J. Wuu and U. Dayal. A uniform model for temporal and versioned objectoriented databases. In Tansel et al. [TCG+ 93]. [WJS95] X. S. Wang, S. Jajodia, and V. S. Subrahmanian. Temporal modules : an approach toward federated temporal databases. Information Systems, 82, 1995.
A TempODL syntax This section gives a detailed description of TempODL's syntax. A BNF-like notation is used in which terminals are boldfaced except when they correspond to reserved symbols of the BNF notation (such as brackets), in which case they are surrounded by quotes. In some rules, three dots are used to denote that some part of the rule is omitted, in which case, the reader may refer to [CB97] for further details. 45
::= ... | | |
f
g
::= ' ' ' ' ::= ::= ; ; ::= ::= | ::= |
unit
f
g
precedes follows factor function
f
g format
::= ' ' ' ' ::= ::= | ::= ; ; ; ; ::= '[' , ']' ::= ::= '[' ']' ::= ' ' , ' '
instant duration
units regexp permutation alias
f g
f
f
f
f
g
g
f
g g
g
::= ' ' ' ' ::= ::= , ,
f
format system g
::= ... | | ::= | | ::= [ ] ::: ::= [ ] [ ::= [ ] ::= | ::= | | ::=
interval psequence tsequence
class
valid transaction
regular discrete stepwise granularity
46
readonly] ... relationship ...
