design and implementation of a temporal query language with abstract time

Informarion S~$remr Vol. 15, No. 3. pp. 349-357. 1990 0306-4379/90 53.00 + 0.00 Printed in Great Britain. All rights reserved Copyright C 1990 Perpmon Press plc

DESIGN AND IMPLEMENTATION OF A TEMPORAL QUERY LANGUAGE WITH

ABSTRACT TIME

JINHO KIM, HOWNG Yoo and YOONJOON LEE

Computer Science Department, Korea Advanced Institute of Science and Technology, Cheongryang, P.O. Box 150, Seoul, Republic of Korea

(Received 26 February 1989; in r~f~sed~r~ 29 October 1989; received for publ~c~rjon 3 January 1990)

Abstract-Temporal databases maintain not only current data of an enterprise but also the history of evolution for the current data (i.e. temporal data). In order to access an object from temporal databases, query languages should have facilities of specifying time. A11 users will use not only ubsolute rime (e.g. My 1987) but also ubsrract time (or relative time) (e.g. last summer) for specifying the time that an event occurred.

In this paper, we designed an extended temporal query language (ETQL) which supports both absolute time and abstract time specification. An introduction of the abstract time concept in the temporal query language provides users with friendliness and easiness in specifying time. The ETQL was implemented as front-end system on INGRES DBMS running under the 4.2BSD UNIX system.

1. INTRODU~ION

Objects in the real world are generally perceived to be time-varying. Existing relational databases do not capture temporal aspects of the real world; rather, they only represent a snapshot of the real-world objects at some instant of time. However, there are various applications, such as CAD/CAM, office automation, statistical data processing, software engineering, etc. which require not only the current information of objects but also their past information. For these applications, a database management system (DBMS) must manage all evolution histories of objects in the real world (i.e. temporal data). Databases managed by this kind of DBMS are called historical databases or temporal datubases [ 11.

Temporal query languages have been developed as a user interface for manipulating and querying temporal databases [2-6]. The query language utilizing the time reiational model in f3] has the syntax form based on a subset of SQL [7J, with necessary exten- sions for specifying time aspects. This language was the first which supported more than one kind of time. The temporal query language used in [2J is also an extension to SQL. HTQUEL (Homogeneous Tem- poral QUEL) proposed in [4,5] was designed by extending a query language, Quel of INGRES [8]. HTQUEL has relations in non-first normal form as an underlying data model. TQuel (Temporal Quel) [6] is also an extension to Quel. This language was designed to be a minimal extension of Quei for manipulating time aspects.

All the temporal query languages mentioned above support only absolute time as a time constant, i.e.

specify the reference to a time point or an interval of time only with an absolute time. In general, it is not natural for users to mention only absolute time in specifying the reference to time. We often use ubstract time or relutiue time rather than absolute time when a time about an event is mentioned. (In this paper, we consider that relative time is a kind of abstract time. Thus we will use the term abstract time to represent not only abstract time but also relative time.) For example, we often mention an abstract time, “lunch time”, instead of an absolute time, “12:00-13:OO”. the concept of abstract time was found only in time expert [9], but it was merely to support one sort of user-defined data type, rime, in a conventional DBMS, INGRES.

The goal of this paper is to design and implement an extended temporal query language (ETQL) with an abstract time support, which is an extension to TQuel proposed by [6]. We made an effort to support possible abstract times as much as we can consider, which probably satisfies most users’ desires for dealing with abstract time in temporal queries. We implemented the temporal query language as a front-end system to an existing relational DBMS, INGRES. An introduction of the abstract time concept in the temporal. query language will provide users with friendliness and easiness in specifying time in temporal queries.

In Section 2, we describe the underlying model of our temporal database and the te~inoio~es related to the temporal database. We present in Section 3 design concepts of our extended temporal query language. In Section 4, implementation strategies and procedures are described. We summarize our results and indicate future research issues in Section 5.

349

350 JINHO KIM er al,

2. TEMPORAL DATA MODEL

2.1. Aspects of time

In the real world there are several aspects of time. When an object is changed, we can consider the following three aspects of time [IO]:

(a) time of realization, i.e. when the update of an object is recognized;

(b) time of storage into the database; and (c) time of validity.

Snodgrass [6] included two aspects of time, i.e. (b) and (c), in their model by using the concept of valid time and transaction time. The transaction time represents the time when the change of an object is recorded into the database. The valid time represents the time when the new data value becomes effective in the real world.

In most of business applications, the semantics closely related to reality is more important than update history. That is, valid time is more useful than transaction time in those applications. If two aspects of time are used, the semantics of temporal databases become complicated. Thus it is hard for users to manipulate temporal databases and to produce their queries. Furthermore, the main aim of this paper is not to present the full system of temporal databases but to present advantages of using abstract times in temporal query. By these reasons, we include only valid time in our temporal databases.

2.2. Underlying scheme of a temporal relation

In order to store the history of information, tuple level or attribute level versioning is often used among logical objects. In attribute versioning, each attribute of a tuple is a set of (time, value) pairs, rather than an atomic value. Thus the attribute versioning trangresses the first-normal form rule. In tuple versioning, each tuple is augmented with appropriate time attributes. That is, time is associated with each version of the tuple. The tuple versioning preserves the first-normal form rule, and thus it can immedi- ately use the relational theories of existing relational DBMSs. Also, it is more proper than attribute versioning in using query languages based on relational

tuple calculus. Therefore. we use tuple versioning in underlying temporal relations.

We described above that our temporal database chose a scheme with valid time and tuple versioning. An example of temporal relations is shown in Fig. 1, In this scheme, valid time is represented by two time attributes (Tfrom for valid time start and Tto for valid time end).

In the above figure. the time value. UO~L’ means that the tuple is valid at present, and that the valid time end of the tuple is constantly evolving.

3. DESIGS OF ETQL

3.1. Overview of ETQL

In this section, we propose an extended query language ETQL and present the features of the language briefly. ETQL is an extension to a temporal query language, TQuel[6] with abstract time in order to achieve more naturalness in specifying time in queries. ETQL is also extended to hold time completeness. Here the time completeness means that the temporal predicates we proposed can represent all possible relationships between two time points or two time intervals. The query language ETQL will be illustrated using example queries on the temporal database shown in Fig. I. For the full syntax of ETQL, we refer readers to [l I].

3.1.1. Schema definition. The create statement defines a new relation and provides a scheme for that relation. The scheme of the “Account” relation shown in Fig. 1 is defined by the following statement:

create history Account(No = i2, Kame = c 16,

Amount = i4).

The keyword history indicates that the relation is defined as a temporal relation. Then two attributes for valid time are attached to the attributes specified by the user: Tfrom and Tto for the starting and ending points of a valid time interval.

3.1.2. Retrieval statement. The retrieral statement of Quel consists of two basic components, the target list, which specifies how the attributes of the relation being derived are computed from underlying

(a) Account relation (b) Career relation

Fig. I. An example of temporal relations.

Design and implementation of a temporal query language 351

relations, and the where clause, that specifies which tuples participate in the derivation. A target variable used in this temporal query language is followed by the type specification indicating whether it is integer (INT) type or character (CHAR) type. This specification is used in generating a variable declaration statement of EQuel (Embedded Quel in C program- ming language) [8]. In addition to those components of Quel, ETQL has two more clasues: the valid clause,

which specifies the valid time that a derived relation should have, and the when clause, which restricts the three-dimensional temporal relation along with time dimension. Since ETQL is a superset of Quel, a query in Quel is also allowed in ETQL.

The when clause consists of the keyword followed by temporal predicates on tuple variables or time constants. Here, a tuple variable in the when clause represents the implicit time attributes of the associated relation, while the variable does a tuple of the relation in the where clause.

Example I: List the person who were in MS course during some time in May 1983:

range of c is Career retrieve into MS(Name(CHAR) = c.Name) when overlap(c, “May 1983”)

As shown in above example, the basic terms of temporal predictates have the form of a function call. The function overlap specifies whether two time values are overlapped or not. The temporal predicates can have other functions such as before, after,

meet, samebegin, sameend, equal, during and include.

The semantics of these functions will be described in Subsection 3.3. Meanwhile, an interval can be specified by two time values: a starting time and an ending time. Thus the temporal predicates also use two functions, beginof and endof to specify these two time values of an interval.

The valid clause specifies the values of two time attributes in the derived relation. The valid clause has the form; valid from.. . to.. ., which defines a time interval. We assume that a tuple variable in the valid clause represents the valid time of the corresponding tuple. The valid clause is analogous to the target list of Quel.

Example 2: When did the persons study in MS course?

range of c is Career retrieve into MScourse(Name(CHAR) = c.Name) valid from beginof to endof where c.course = “MS”

3.1.3. Update statements. Update operations are needed in a temporal database to change incorrect information, to add some past information which by mistake may have been omitted, or to delete erroneously existing information.

Three update statements, append, delete and replace in Quel are also extended to apply them to

temporal databases. In contrast to TQuel which has non-deletion and append-only properties. ETQL allows a tuple to be deleted or replaced. The valid and when clauses may be included in the replace statement. The append statement is augmented with the valid clause and the delete statement with the when clause. Example 3 shows an example of using the replace statement.

Example 3: Replace hdyoo’s course which was valid from Mar 1981 with “BA”.

range of c is Career replace c(course = “BA”) valid from beginof to endof where c.Name = “hdyoo” and

c.course = “BS” when equal(beginof(c), “Mar 1981”)

So far, we have shown the query examples based on the syntax of ETQL we designed. Since ETQL supports only valid time as a timestamp. the as-of

clause in TQuel is omitted in ETQL. Also, ETQL has abstract time features. The two points described above are major differences between TQuel and ETQL.

3.2. Time constants in ETQL

3.2.1. Absolute time. As a way of time specification. we may use absolute time which is the specification of calendar time. Meanwhile, we call the least time unit to be used in the specification of time as time granularity (e.g., day, week, month, etc.). When we assume that the granularity of time specification is a day, an absolute time is expressed with the following form in our query language ETQL:

YYYY/MM/DD (e.g. 1986/12/12 or 1986/Dee/12)

3.2.2. Abstract time. When we are talking about time-concerning events, we often mention abstract (or relative) time rather than absolute time. (In this paper, relative time is considered as a kind of abstract time.) As the reflection of the abstract time of the real world, we introduced the concept in ETQL. ETQL supports four kinds of abstract times. First, we introduce application-independent abstract time into the syntax of a time constant in ETQL. ETQL supports the possible combination of the syntax of this kind of time, thus it will provide a more flexible expression for specifying time. Here application-independent means that the abstract time may be com- monly used in any application of the real world. An abstract time is surrounded by two at-signs(@‘s). Let’s see an example:

Example 4: Who is the person whose amount was 100 in last spring?

range of a is Account retrieve into springamount(Name(CHAR) = a.Name) where a.Amount = 100 when overlap (a, @last year spring@)

352 JINHO KIM el ul.

The “last year spring” is an abstract time which indicates a period from March 1988 to May 1988. The following relative times also belong to the application independent time: 3rd version, 5th version, &d before version and so on.

The second kind of abstract times is uppficution- dependent. This kind of abstract time is useful for users to mention the time of an event which has occurred in their working fields (for example “the day of foundation”, “ the day of the entrance examination of our school”, etc.). Of course, users must specify the important events of their application in advance. This kind of abstract time is also useful for user dependent events (for example “my birthday”).

Finally, the combination of the above kinds of abstract times is also supported. It can be also used to represent abstract rime for periodic events, such as “the Christmas of last year” and “this month meeting day”. We present the full syntax of time constants in the Appendix.

3.3. Complereness of ETQL

A given relational algebra is complete if and only if all possible relations reduced from the given base relations can be obtained by relational algebra (121. That is, relational algebra must have the following:

(1)

(2)

(3)

features to obtain new relations from a base relation by restricting along with each dimension, i.e. object dimension and/or attribute dimension; features to express union, cross-product and difference operations between two relations; and features to assign the relation resulting from operations on other relations.

before C--B after

meet

The completeness of a conventional query language can be proved by showing that the query language can be translated to and from relational algebra. This means that the query language is at least as powerful as the relational algebra. Ullman [13] shows that Quel is complete by considering the relational algebra as a benchmark. The proof discussed in [13] can be extended to that of ETQL, since ETQL is a superset of Quel. The requirements needed for proving the completeness of ETQL are to have the following [S]:

(1) features to retrieve the time values when an object has possessed some values; and

(2) features to reduce new relations from a temporal relation by restricting along with the time dimension.

Hence, we can say ETQL is complete if ETQL satisfies the two requirements shown above. The first features are implied in the valid clause of ETQL, i.e. the first requirement is satisfied in ETQL. The second features are considered in the when clause of ETQL. The when clause is used for giving restrictions along with the time dimension. Figure 2 shows the temporal predicates which we can use in the when clause of ETQL.

From Fig. 2, we can see that the temporal predicates are sufficient to represent all possible relationships between two time values. Thus, the second requirement is also met. Therefore, we can say that ETQL is complete.

4. IMPLEMENTATION

4.1. Overview of the implementation

Our temporal database system with the extended temporal query language (ETQL) is implemented as a

‘u; I

overlap

samebegin i :1-,

sameend ’ -4-i

equal

during C--> includes

:‘i

Fig. 2. Temporal predicates and their semantics.

Design and impiementation of’ a temporal query language 353

front-end system to a conventional DBMS, INGRES running under the 4.2BSD UNIX system. The outline of the implementation is shown in Fig. 3. Our system consists of four components: lexical analyzer, parser, transformer and query processor. The lexical analyzer and the parser of our system are constructed by using LEX (lexical analyzer generator) [14] and YACC (yet another compiIer compiler) 1151 running under UNIX environment.

The user’s input query in the extended temporal query language (ETQL) is scanned and divided into tokens by the lexical analyzer (i.e. yylex), then passed to the parser (i.e. yyparse). The parser process syntax analysis and stores the information for translation into appropriate data structures (i.e. parse tree). The transformer scans the data structures and transforms the input query in ETQL to a sequence of commands for the query processor. For the convenience of

*beginof => +endof(a) => *equal@, b) => *overlap(a, b) => *during(a, b) => *before@, b) => l samebegin(a, b) => *sameend(a, b) => *meet& b) => *includes(o, b) => *after(a, b) =>

create Account(No = i2, Name = ~16,

Amount = i4, Tfrom = i4, Tto = i4

Here, we can see that the keyword history is deleted and two time attributes are added.

4.2.2. Other statements. The calid clause can be found in the append, retrieve and replace statements. If the valid clause is specified in a ETQL statement, we set the values of two time attributes (i.e. Tfrom and Tto) to the values specified in the valid clause. Then we add two time attributes to the target fists of the corresponding Quel statement. The other dause extended, when clause is used in retrieve, replace and delete statements. Several temporal predicates in the when clause are to be changed into the appropriate forms which are legal in Quel, and appended to predicates of the where clause. The translation rules of temporal predicates are the following:

a.Tfrom a.Tto a.Tfrom = b.Tfrom and a.Tto = b.Tto aTfrom < b.Tto and b.Tfrom < a.Tto a.Tfrom > b.Tfrom and a.Tto < b.Tto a.Tto < b.Tfrom a.Tfrom = b.Tfrom a.Tto = b.Tto a.Tto = b.Tfrom a.Tfrom -Z b.Tfrom and a.Tto > b.Tto b.Tto < a.Tfrom

implementation, we use the ail legal EQuei (Em- where a and b are tuple variables of temporal re- bedded SQL) statements as the commands for the lations. Also, set operations on time, tintersect and query processor. That is, the transformer translates t&on are calculated with two functions “max” and the input query into an EQueI program. Then the “min” as follows:

*tintersect(u, b) = > [max(a.Tfrom, b.Tfrom) 15 min(u.Tto, b.Tto)] *tunion(a, b) = > [min(a.Tfrom, b.Tfrom) w max(u.Tto, b.Tto)]

query processor executes the EQuel program and returns the result of the execution to the users. The query processor will access stored relations through the conventional DBMS, INGRES. In Subsection 4.2, we describe the rules of translating ETQL statements into EQuel statements.

4.2. Trunslution rules

4.2.1. Create statement. We can distinguish whether the relation to be created is temporal or conventional through the scanning of the create statement. If the keyword history is found in the scanning, the given create statement is the definition of the temporal relation scheme, and the information is stored in a data structure. In the case of a temporal relation, two time attributes (i.e. Tfrom and Tto) which indicate calid time start and vulid time end are defined in the integer type with the length of 4 bytes, and attached to the scheme declared by users. The create statement shown in Subsection 3.1.1 is translated as follows:

where

min(x,y) = {x, if x <y (y, otherwise

max(x, y) = (x, if x > y {y, otherwise

However, “min(a, b),, and “max(a, b).’ cannot be supported directly in Quel, and thus a translation is needed once more. When one of two arguments of temporal predicates has the max or min function, the following rules are needed for the translation:

*x > max(y, 2) = >(x >y and x > z) *x c max(y, 2) = > (x < y or x < 2) *x = max(y, z) = >((y > z and x =y)

or (z >y and x = z)) *x > min(y, 2) = >(x>yorx>t) l x < minfy, z) = >(x<yandxcz) *x = min(y, z) = >((y < z and x = y)

or (z c y and x = z))

354 JINHO KIM et al.

Lexical rules of ETQL

Grammar of ETQL + Semantic Actions

+ Time Support

Input Query

output

Q&

I I d+ CL

YACC

< -ssor

3 yylex

<

PZZ-,’

Fig. 3. Overview of the system implementation.

The valid clause and the when clause can be used optionally. If both of them are omitted, the given query has no translation. Two time attributes having integer values are converted to user-readable forms of time through the reconverting routine provided.

4.3. Time conversion

The external representation form of time, here, is converted to an internal form of integer for easy manipulation of time and less storage space. Thus, the operations between times are changed to the operations between the integer values which are converted from the given times. The currently evolving time, now, is converted to 99999 which is a value out of the legal integer range. The integer value of time is computed through the routine for time conversion, which gets the relative value to a time “Jan 1, 1960” of integer value 1. This reference point in time (i.e. Jan I, 1960) can be changed with some modification of the routine for time conversion. We also provide a routine for reconverting from the given integer value to the user-readable form of time. This routine is used for letting the user identify the explicit time corresponding to the given integer form of time.

4.4. Abstract time support

In this implementation, we support abstract time in four ways. First, the application-independent abstract time is included in the syntax of the time constant. The words used in this time representation are dealt with as individual tokens. Second, users can record the important events in advance which have occurred in their working fields. This kind of abstract time is preserved in a data structure. It is logically a timetable with three fields which are the name, the start time and the end time of an event. The tokens of an event name are compressed by removing all leading and including blanks. The abstract times are sorted in alphabetic order. The corresponding time is

converted to an integer value and then stored in the timetable. If an abstract time is the name of an event not lasting any interval of time, the ending time is automatically the same as the starting time. Then, when users refer the predefined abstract time in their query, the name is searched in the timetable by the binary search method and the abstract time is replaced with the corresponding absolute time. Third, the event name and its absolute time are stored in an appropriate storage structure in an interactive manner. This feature is supported the same way as the second explained above. The fourth feature is implemented by way of the combination of implementation methods of the above features, and used for the name of periodic events.

All abstract time which is relative to current time is converted to the corresponding absolute time by referring to the current time. Since the current time is changed day by day, a mechanism is necessary to manage the ever-changing current time. Therefore, we adopt a system clock as a supplier of the current time.

4.5. An example of translation result

Through the translation rules described so far, we can get the final legal EQuel program from the input query written in the extended temporal query language ETQL. The resulting EQuel program is compiled, then executed on temporal databases by the query processor of our system. Here, we show an example of translating a temporal query into an EQuel program (see Fig. 4). The reconvert( ) is a subroutine for reconverting the given integer value of time to the corresponding user-readable form of time.

5. CONCLUSION

We designed and implemented an extended temporal query language ETQL with abstract time

Design and implementation of a temporal query language 355

An Example Input Query:

List the persons who have amount of more than 100 in spring of 1982.

=> range of a is account retrieve (number(INT)=ano,irm(CHAR)=a.name) valid from beginof to endof where aamount > 100 when overlap(a,@ 1982 year spring@)

Output EQUEL Program Corresponding to the given Input Query:

#include CStdiO.h> maW) { ## int number; ## char irm[20]; ## int fromtime; ## int totime;

printf(” ____________c___________ ____________________________-_______\n”); printf(“number\t”); printf(“irm\t”); p~~~‘fromtime\t”); printf(” totime\t”); printf(“\n”); printf(” ________--_--__--_ -__________________________ ___ _______ ____\n”);

## ingres temporaldb ## range of a is account ##I retrieve (number=a.no,irm=a.name,fromtime=a.Tfrom,totime=a.Tto) ## where aamount > 100 and ## aTfrom -C 8187 and ## 8096 c a.Tto W

printf(“%d\t”, number); printf~‘%s\t“, irm); if~f~rn~e == 99999) p~~~‘now\t”); else reconvert(fromtime); if(totime == 99999) printf(kow\t”); else reconvert(totime); p~n~~\n”);

W ## exit ]

Fig. 4. An example output.

features and several temporal predicates. It is implemented as a front-end system to INGRES DBMS running under the 4.2BSD UNIX system. The introduction of abstract time features in ETQL provides users with friendliness and naturalness in specifying time in queries on temporal databases. We made an effort to incfude abstract times as much as possible. This effort can cover most users’ desires for dealing with abstract time in temporal queries. The temporal predicates extended here can represent all possible relationships between two points in time or intervals of time. The front-end implementation makes the

conventional DBMS, INGRES support temporal databases, and gives more flexibility of implementation. Also, this implementation can be used as a benchmark for evaluating temporal DBMSs to appear later.

in terms of the actual running of the implemented temporal database system, impatient users may- suffer from performance degradation. This is due to dis- advantages of the front-end implementation ap preach. Performance degradation mainly stemmed from the usage of storage structure and the accessing scheme of pure INGRES. If we use specia1 storage

356 JINHO KIM et al.

structures for a temporal relation, users’ requests to <mh> temporal databases can be executed efficiently. Thus we are designing and implementing the special storage structures and the index structures which are fit for temporal databases. For further study, we also need to develop the techniques of query processing and optimization and the mechanisms of concurrency control.

:: J ,Jat! / Feb

I!4Iar

l-9 { Ma}

/zl

t Aw ISeP

IGct

February

March

April

June

July

AugtlJt

September

October 1 Nov November

IDec ~Decelnber

REFERENCES

[t] R. Snodgrass and I. Ahn. A taxonomy of time in databases. Proc. ACM SIGMOD Int. ConJ on Management oJ Data, pp. 236-246 (1985).

[2] G. Ariav. Preserving the time dimension in information systems. Ph.D. Dissertation, The Wharton School, University of Pennsylvania (1983).

131 J. Ben-Zvi. The time relational model. Ph.D. Disser- * * tation, Department of Computer Science, University of

California, Los Angeles (1982). [4] S. K. Gadia and J. H. Vaishnav. A query language for

a homogeneous temporal database. Proc. 4th ACM S~GACT-SrGMUD Symp. on Principles of Databuse Systems, pp. 5 t-56 (1985).

<dy> (time2)

(abstract time)

::= 1121 . ..I31

:: = /* empty */ 1 ‘-’ (timel)

:: = (application independent time) 1 (application independent duration

time) 1 <application dependent time)

1 (periodic time)

<application independent time) ::= (ymd spec) IS] S. K. Gadia. A homogeneous relational modet and query languages for temporal databases. ACM Trans. Database Systems I3(4). 418448 (1988).

[6] R. Snodgrass. The temporal query language TQuel. ACM Trans. Database Systems 12(2). 247-298 (1987).

[7] M. M. Astrahan and D. D. Chamberlin. Implemen- tation of a structured English query language. Commun. ACM 18(10), 580-587 (1985).

[S] M. Stonebreaker, E. Wong, P. Kreps and G. Held. The ::= (urn WC> <d SF>

:: = < yearspec) (monthspec) I ( yearspec>

::= this year lb ye= 1 (counts> year ago

1 <counts) year

::= Iunuber

:: = this month 1 last month

I {counts) month ago

:: = I* empty */ 1 <dayspec>

::= today 1 yesterday

Ibefore (counts> day

:: = (monthspee) <d spec)

:: = < yeanpec) <seasons>

:: = spring

I

summer

autumn

1 winter

:: = ( yearspec) (mh) :: = (weekspec) (dd spec)

::= this week /last week

/<counts> week ago

:: = [* empty ‘j 1 <dw WC>

< ymd WC)

<P spec>

< yearsi=)

design and implementation of INGRES. ACM Trans. Database Svstems l(3). 189-222 (1976).

[9] M. Stonebreaker and R. Gvermyer. Im~Iem~tation of a time expert in a database system. ACM S~GMOD Record U(3), 51-59 (1982).

[IO] P. Klahotd et at. A general model for version management in databases. Proc, 12th Znt. Conf off Very Large Databases, pp. 319-327 (1986).

[11] H. Yoo. A design and implementation of temporal query language with abstract time support. MS Thesis, Computer Science Department, KAIST (1987).

[12] E. F. Codd. Relational completeness of data base sublanguages. Data Base Systems, Vol. 6 of Courant Computer Symposium Series, pp. 65-98 Prentice Halt, Englewood Cliffs, New Jersey (1972).

[13] J. D. Ullman. Principles of Databuse Systems. Com- puter Science Press, Maryland (1982).

(141 M. E, Lesk. LEX: a texicai analyzer generator. Tech- nical Report No. 39, Bell Laboratories, Murray Hill, New Jersey (1975).

[t 51 S. C. Johnson. YACC: yet another compiler compiler. Unix Programmers’ Mand f 1978).

(counts)

(monthspec)

<d spec>

<dam=>

<md v=> <YS WC>

(seasons)

APPENDIX

Time Constants of ETQL in BNF notations

(Time Constants) ::= (absolute time) 1 (abstract time)

<absolute time) :: = (time1 ><time2>

(timel) :: = <yr> ‘/’ <mh> ‘j’ (dy)

(yr> ::= l~~l961~...~2~

g2~) (weekspec)

<dd SF=>

Design and implementation of a temporal query language

(dw WC) :: = Sun 1 Sunday

1 Mon 1 Monday

/ Tue ) Tuesday

( wed 1 Wedlwsdny

1 Thu 1 Thursday

1 Fri 1 Friday

1 Sat / Saturday

<application independent duration time) :: =

between (interval time)

357

(interval time) ::= {counts) yean ) (counts) months 1 (counts) weeks

I(counts> days

(application dependent time) :: = (application dependent time) (time component) (time component)

(time component) :: = identifier

(periodic time} :: = ( yearspec) (application dependent time)

IS II 3-F

design and implementation of a temporal query language with abstract time

Documents