A Visual Query Language For Temporal Databases Vram Kouramajian Michael Gertz Department of Computer Science Institut fuer Informatik Wichita State Un

Transcription

1 Hannover Informatik-Berichte Nr. 02/95 (April 1995) A Visual Query Language for Temporal Databases Vram Kouramajian and Michael Gertz Institut fur Informatik Universitat Hannover Lange Laube 22 D Hannover

2 A Visual Query Language For Temporal Databases Vram Kouramajian Michael Gertz Department of Computer Science Institut fuer Informatik Wichita State University Universitaet Hannover Wichita, Kansas 67260{0083 Lange Laube 22 D Hannover, Germany Abstract This paper addresses the issue of visual query formulation for temporal databases. We introduce a number of visual constructs that allow users to build queries in a modular, bottom{up fashion based on a temporal Extended Entity{Relationship Model. These constructs are: Temporal projection, temporal selection, time links, ltering and set operators, and temporal aggregates. This paper also identies the main challenges posed by visual interface design for temporal databases. It presents guidelines for designing user{friendly, exible visual environment for temporal design editors, temporal query editors, temporal update editors, and temporal display editors. Index Terms { Temporal Extended Entity{Relationship Models, Visual Query Languages, Temporal Databases, Advanced Query Interfaces.

3 1 Introduction Temporal databases preserve the complete history of the Universe of Discourse; that is, they follow the non deletion rule of data [Snod87, GaYe88, NaAh89, RoSe91, WuDa92, ElWK93]. They create a new version for each object modication without destroying or overwriting existing versions of objects. This permits users to query the current state of the database, as well as past states, and even states that are planned for the future. Recent years have witnessed an increase in research on several aspects of temporal databases. A series of bibliographies on temporal databases have been written [Soo91, AlSS93]. Glossaries on well{dened, well{understood, and widely used concepts specic to temporal databases were assembled [JCGS92, JCEG94] 1. During the last 15 years, a corpus nearing 800 papers were published in dierent areas of temporal databases [Snod94]. These papers include research on temporal algebras, calculus{based query languages, valid time and transaction time databases, conceptual and physical temporal database modeling, temporal query languages, temporal active models, and access structures and archiving techniques for temporal data. Unfortunately, not much attention has been paid to the important area of visual interfaces to temporal databases. Most temporal query languages are extension to textual query languages such as SQL [ElNa94] or GORDAS [ElWi81]. They are aimed at users with high degree of sophistication and good knowledge of temporal constructs. What is missing in temporal databases are human{centered user interfaces for database design and manipulation. A human{centered visual environment should include tools for temporal database modeling, query formulation, dierent display metaphors, temporal data insertion and update, and logical error correction of temporal data. In this work, we address the problem of visual query formulation for temporal databases. Several prototypes that provide graphical interfaces for non{temporal databases have been developed [ElLa85, CaSa88, CERE90, AADD92]. Some prototypes use Entity{Relationship (ER) diagrams for data modeling but they oer manipulation facilities close to relational models [CaSa88]. More advanced prototypes 1 This paper adheres to the terms dened in both glossaries. 2

4 provide a consistent view by using the same schema representation for the schema editor and query editor [AADD92]. Successful prototypes are based on the principle of direct manipulation of objects and functions, supporting unconstrained user behavior during schema denition as well as query formulation. In this work, we adopt the same principles for our query editor: WIMP metaphor (Windows, Icons, Menus, Pointing devices), direct manipulation, high degree of exibility in user interaction, and simplicity and minimality (simple conceptual diagrammatic symbols). Our visual query editor provides users with a number of simple, consistent graphical representations for temporal selection, temporal projection, arbitrary and complex temporal operations over a single or multiple database states, and temporal aggregate functions. Our graphical query language is built on top of TEER [ElWK93], a temporal extension to the Extended Entity-Relationship (EER) Model [ElNa94]. A related work by Oberweis and Sanger describes a graphical query language (GTL) for temporal relational models [ObSa94]. GTL introduces a number of new, non-standard patterns for describing temporal queries, which may confuse database users familiar with and accustomed to EER diagrammatic notations. We believe that it is more natural to specify temporal data and queries in a conceptual, entity-oriented data model than in a tuple-oriented relational data model. The TEER model incorporates the concept of lifespan for entities and relationships into the EER model. It also extends the GORDAS ER query language [ElWi81] to handle temporal queries by introducing the concepts of temporal boolean expressions, temporal selection, and temporal projection. The main contributions of this paper are twofold: 1. We rst identify the main challenges posed by visual interface design for temporal databases. We present guidelines for designing user{friendly, exible visual environment for temporal design editors, temporal query editors, temporal update editors, and temporal display editors. 2. We then address the issue of visual query formulation in temporal databases. We introduce a number of visual constructs: Temporal projection, temporal selection, time links, ltering and set operators, and temporal aggregates. These constructs allow users to build queries in a modular, bottom{up fashion. 3

5 The rest of the paper is organized as follows. Section 2 reviews the TEER model. Section 3 discusses the main issues in visual interface design for temporal databases. Section 4 and Section 5 present the basic and advanced constructs of our visual query editor. Finally, Section 6 concludes the paper. 2 Review of the TEER Model The Temporal Extended Entity-Relationship (TEER) model adapts the EER model [ElNa94] to include the temporal dimension. Section 2.1 reviews the representation of time used in this work. Section 2.2 and Section 2.3 present the TEER model and query constructs. 2.1 Representing Time Let T be a countably innite set of totally ordered discrete points in time, or chronons. A chronon is indivisible, or atomic. A time interval [t s ; t e ) is dened to be a set of consecutive chronons; that is, the totally ordered set ft s ; t s+1 ; : : : ; t e?1 g T. We call t s the start time and t e the end time of the time interval. A single discrete chronon t is represented as a closed interval [t; t], or simply [t]. Interval representation has an important shortcoming. Since the set of all intervals in T is not closed under set operations, Gadia and Yeung [GaYe88] suggested the concept of temporal elements. A temporal element, denoted as T E, is a nite union of time intervals, denoted by fi 1 ; I 2 ; : : : ; I n g, where I i is an interval in T. Union, intersection, and dierence operations on temporal elements are easily dened. In addition, set comparison predicates of two temporal elements using =, 6=,,,, and are also easily dened. Time intervals in a temporal element T E are required to be maximal; that is, for each two distinct time intervals I i and I j in T E, I i neither intersects I j nor I i is adjacent to I j. The maximality property is important since it allows an unambiguous specication of ltering operations on temporal elements (see Section 5.2). In temporal databases, it is customary to include a number of dierent time dimensions. Two of the most common ones are the valid time and the transaction time [Snod87]. The valid time represents the actual time in the mini-world that a particular event or change occurred, or the actual time intervals during 4

6 which a particular fact was true. For historical databases, the domain of a valid time attribute is a time interval [0; now), where zero (0) represents the starting time of the database mini{world application, and now is the current time, which is continuously expanding. The transaction time represents the time that facts or events were recorded in the database. Additional time dimensions are also possible and sometimes necessary [Snod87]. Due to space limitations, we will consider only the valid time in this work. 2.2 The TEER Data Model The Temporal EER (TEER) model extends the EER model [ElNa94] to include temporal information on entities, relationships, superclasses/subclasses, and attributes. We will assume that the reader is familiar with the basic concepts of the ER model and ER diagrams [Chen76], and directly specify the concepts of the TEER model Entities and Entity Types An entity type is a set of entities of the same type; that is, entities that share the same basic attributes. Entities represent objects in the mini{world situation that is being modeled. Each entity type E i has a set of basic attributes A i1, A i2,..., A in, and each attribute A ij is associated with a domain of values dom(a ij ). In the TEER model, each entity e of entity type E is associated with a temporal element T E(e) that gives the lifespan of the entity. The lifespan T E(e) could be a continuous time interval, or it could be the union of a number of disjoint time intervals. The temporal value of each attribute A i of e, which we refer to as A i (e), is a partial function A i (e) : T E(e)! dom(a i ). This is also called a temporal assignment [GaYe88]. The subset of T E(e) in which A i (e) is dened is denoted by T E(A i (e)), and is called the temporal element of the temporal assignment. It is assumed that A i has a NULL (or UNKNOW N) value during the intervals T E(e)? T E(A i (e)). In the TEER model, each entity has a system-dened SURROGATE attribute whose value is unique for every entity in the database. The value of this attribute is not visible to users, and does not change throughout the lifespan of the entity. The temporal element of the SURROGATE attribute denes the entity lifespan T E(e). 5

7 2.2.2 Attributes and Keys Several types of attributes exist. Simple, single-valued attributes have at most a single atomic value for each entity at each time instant [t]. Multi-valued attributes can have more than one value for an entity at a given time instant [t]; hence, their domain is the power set P (V ) of some simple domain V. A composite attribute A is a list of several component attributes A = ha 1 ; A 2 ; :::; A n i; hence, its value for each entity at time instant [t] is a concatenation of the values of its components. The temporal element of a temporal assignment of a composite attribute is the union of the temporal elements of the temporal assignments of its components. A key attribute (simple or composite) is an attribute A of an entity type E with the constraint that at any time instant [t], no two entities in E will have the same value for A. The TEER model allows the update of a key attribute since each entity is uniquely identied by its system{dened SURROGATE Relationship Types and Relationship Instances A relationship type R of degree n has n participating entity types E 1 ; E 2 ; :::; E n. Each relationship instance r in R is an n-tuple r = he 1 ; e 2 ; :::; e n i where each e i 2 E i. In the TEER model, each relationship instance r is associated with a temporal element T E(r) which gives the lifespan of the relationship instance. The constraint is that T E(r) must be a subset of the intersection of the temporal elements of the entities e 1 ; e 2 ; :::; e n that participate in r. That is, T E(r) (T E(e 1 ) \ T E(e 2 ) \ ::: \ T E(e n )). This is because for the relationship instance to exist at some point t, all the entities participating in that relationship instance must also exist at t. Relationship attributes are treated similarly to entity attributes; the temporal value A i (r) of each simple attribute A i of r is a partial function (temporal assignment) A i (r) : T E(r)! dom(a i ), and its temporal element T E(A i (r)) T E(r) Classes and Superclass/Subclass Relationships A class is any set of entities; hence, an entity type is also a class. Often we need additional groupings of entities that are subclasses (subsets) of the entities in another class [HaMc81]. Subclasses can be used 6

8 to represent generalization and specialization hierarchies and lattices [SmSm77]. An entity e of superclass E will belong to a predicate-dened subclass C throughout all time intervals when the dening predicate evaluates to true for that entity. For a user dened subclass, the user will specify at specic time points whether the entity is to be made a member of the subclass or removed from the subclass. In either case, the entity will have a temporal element T E(e=C) to specify the time intervals during which it is a member of the subclass C. The constraint is that T E(e=C) T E(e) must hold. Specic attributes of a subclass are treated similarly to other attributes; the temporal elements of their temporal assignments must be subsets of T E(e=C). 2.3 TEER Query Language Constructs To allow for temporal constructs in queries, the TEER model denes the concepts of temporal boolean expressions, temporal selection conditions, and temporal projections as described below: 1. Temporal Boolean Expression: A (temporal) boolean expression is a conditional expression on the attributes and relationships of an entity. The boolean condition when applied to one entity e evaluates to a function from T E(e) to ftrue, FALSE, UNKNOWNg. This function is called a temporal assignment (see Section 2.2.1). 2. True Time: The true time of a boolean expression c, denoted by [c], evaluates to a temporal element for each entity e. The temporal element is the time for which the condition is T RUE for e. 3. Temporal Selection Condition: A (temporal) selection condition compares two true times using the set comparison operators =, 6=,, and. When applied to an entity type (or class), it evaluates to those entities that satisfy the temporal selection condition. 4. Temporal Projection: A temporal projection, when applied to a temporal entity, restricts all temporal assignments (attributes and relationships) for that entity to a specic time period specied by a temporal element. 7

9 Temporal selection conditions are used to select particular entities based on temporal conditions, whereas temporal projections are used to limit the data displayed for the selected entities to specic time periods. Temporal boolean conditions may be used as components in the expressions for both temporal selections and temporal projections. 3 Issues in Visual Interface Design for Temporal Databases During the last decade, powerful visual approaches were experimented for data manipulation [AADD92, BCCL93]. Prototypes for integrated Computer{Aided Software Engineering (CASE) environment whose components cover user interactions during the entire database life cycle were introduced [AADD92]. In this section, we discuss the challenges posed by visual interface design for temporal databases (for an overview of visual query systems, see [BCCL93].) 1. Temporal Design Editors: Temporal design editors should be exible: They must allow multiple ways of specifying temporal constructs. Users may wish to add temporal information to the conceptual model after completing the Entity-Relationship diagrams or may wish to specify the temporal information during the various steps of the conceptual design. Some temporal extensions to the EER model distinguish between conceptual objects and temporal objects as well as between conceptual relationships and temporal relationships [ElKo93]. 2 A temporal design editor should use dierent symbols for representing conceptual and temporal concepts. It must also apply dierent rules for checking user actions, ensuring the desired level of consistency among the actions. 2. Temporal Query Editors: Temporal query editors are much more dicult to design and build than non{temporal query editors. In non-temporal databases, users can only query over the current state of the database whereas in temporal databases users can query over multiple states and time dimensions. In addition, users may apply boolean conditions over some state(s) of the display but they may also display dierent state(s) of the database. Finally, in temporal databases users 2 A conceptual object (or relationship) has a start time but no end time whereas a temporal object (or relationship) has both start time and end time. 8

10 may perform a number of powerful operations such as temporal aggregates, temporal functions, and temporal window operations. A comprehensive temporal query editor must support all these temporal constructs. Otherwise, users may be forced to use two dierent environments: A temporal query editor for simple query formulations and textual query language for powerful temporal constructs. 3. Temporal Update Editors: Temporal update editors should capture the dierences between updates intended to make changes and updates intended to make corrections. In addition, they might support a zero{information{loss model in which the eect of a past transaction, the circumstances surrounding the transaction, and the transaction itself can be determined at any time [GaNa93]. In such an environment, information about the type of operation (update, insert, delete) may be kept, the identity of the user who performed the transaction may be maintained, and a memo eld may be used. A temporal update editor may provide dierent metaphors for entering new information. For instance, it may display all versions of an object linked together. A user may click on a specic object version to perform some error corrections or may append a new object version to the list. A temporal update editor may also display a particular state of the database as rooted graph [ElLa85]. A user may use the rooted graph to perform a new transaction by updating a number of objects displayed and creating a new state of the database. 4. Temporal Display Editors: In general, temporal queries generate huge amount of (temporal) information, which obviously does not lend itself to tabular display. A temporal display editor should provide users with the option of displaying results visually, using two{dimensional or three{ dimensional structures such as graphs or bars. In some cases, an intensional explanation of the temporal query answer may help users in abstracting the large amount of data retrieved. The result of a non{temporal query involves a single state whereas the result of a temporal query may involve multiple states. A temporal display editor may provide a browsing tool that allows users to navigate among the various states of the query result. A simple navigation scheme may allow moving (forward or backward) among the various versions of an object whereas a more 9

11 advanced scheme may allow moving among collections of objects, which belong to a single state or multiple states. 4 Basic Graphical Query Language Constructs For our graphical query language, we do not pre-suppose any particular visual environment but we assume a kernel architecture that provides a basic set of functionality and layouts similar to those available in SUPER [AADD92]. In this section we introduce the basic constructs for our graphical query language. Section 4.1 presents essential non-temporal query operators in visual environment. Sections 4.2 and 4.3 introduce graphical query constructs for temporal projection and temporal selection. 4.1 Essential non-temporal Operators Database users are familiar with EER diagrammatic notations. These notations are popular since they are easy to read and provide a good abstraction tool. In our visual environment, we use the EER diagrammatic model as a starting point for query formulation. In the sequel, we will use the simplied university database schema described in Figure 1 to introduce our various graphical query language constructs. DName DPhone DCollege 1 DEPARTMENT instructors courses-offered 1 DEPT Sno Class Name DEPT INST COURSE STUDENT Grade advisor N N courses offeringdept 1 ADVISES N ENROLL N N dept advices students 1 N INSTRUCTOR TEACHES COURSE courses instructor Salary IName Rank Cno CName Credithours Figure 1: University Database 10

12 4.1.1 The Remove Operator During query formulation, a user may apply the remove operator which drops one or more attributes, entities, and relationships with their attributes from the displayed database schema (and respectively from the query) 3. Deletions are propagated to participating relationships as well as along superclass/subclass hierarchy. If a superclass is deleted, all its participating relationships and subclasses are also deleted. Applying the remove operator iteratively on the database schema results in a working diagram The Restrict Operator After having selected the relevant part of the schema, a user may wish to allow for selection of data that satisfy a certain criteria. The restrict operator is used to impose boolean conditions on attributes of entities and relationships [CERE90, AADD92]. Using restrict operators, users may place boolean conditions directly on attributes. In the case of complex conditions involving attributes of multiple entities, users may place boolean conditions in a condition box linked to the respective attributes. All attributes that are displayed in the query result must be marked explicitly by an asterisk (). Example 4.1: \Retrieve the name, rank, and courses of all instructors of the computer science department who either teach a compiler course or a programming course". DEPARTMENT DName = computer science DEPT INST INSTRUCTOR * * IName Rank TEACHES CName = programming or CName = compiler * COURSE Figure 2: Restrict Operator 3 A keep operator can be dened analogously, which is more convenient if only a small part of the schema is of interest for the query. 11

13 Figure 2 is a graphical representation of the query in Example 4.1. It is built from Figure 1 through a number of operations, including the remove operator and the restrict operator. The attributes DName and CName are used in restrict operators: (DName = 'computer science') and (CName = 'programming' or CName = 'compiler'). The current values of attributes IName, Rank, and CName are displayed since they are marked by an asterisk (). Figure 2 does not include any temporal constructs. In the context of an underlying temporal data model, both restrictions and display operators are applied at the time instant now Bottom{up Construction of Queries During the query formulation process, a user is allowed to specify the dierent components of a query independently in a working diagram and to modify them separately at a later time. These sub{queries may be part of more than one query. This allows reuse and a modular way of building complex queries in a bottom{up fashion. In order to formulate queries that involve multiple and distinct references to the same entity set, a user applies the duplicate operator which copies respective entities within a working diagram. This operation allows users to specify the dierent components of a query (i.e., sub{queries) independently and to combine them into expressions of arbitrary complexity. In our graphical query language, the query result link operator combines a query with sub{queries. A user uses a query result link to pass the result of a sub{query to another query. A query result link restricts the selection of entities in a query based on a boolean condition whose evaluation depends on the result of another sub{query. We illustrate this concept with the next example. Example 4.2: \Retrieve the salary and rank of all instructors of the computer science department who earn more than the instructor John Smith". 12

14 DEPARTMENT DName = computer science DEPT INST INSTRUCTOR * * IName Rank * Salary > x x x := Salary INSTRUCTOR IName = John Smith Figure 3: Query Result Link The right part of the Figure 3 represents a sub{query determining the salary of instructor John Smith (this part is obtained by applying the duplicate operator). The result of the query is bounded to the variable x. The left part of the diagram represents the root query, which is related to the sub{query via a query result link. The evaluation of the boolean condition on the attribute Salary in the root query depends on the evaluation of John Smith's salary (as indicated by the directed edge). A query result link is bounded to a typed variable. This variable may correspond to a tuple or to a set of tuples; that is, a query result link may pass either a single tuple or a set of tuples to a root query. This implies that users must choose carefully the predicate used in the link condition. For example, in Figure 3, if the sub{query evaluates to a set of salaries (i.e., x is a set instead of single value), the condition \Salary > x" must be replaced with the predicate \Salary >all x". An important feature of graphical query language interfaces, in particular when several sub{queries are used to formulate a query, is a compose operator that allows replacing a specied sub{query by a named (smaller) \placeholder". Links related to a replaced sub{query remain in a working diagram. The compose operator reduces the complexity of the displayed query structure and hence the working diagram becomes more simple and easy to read. At the end of the query formulation process, a display operator is applied to the completed working diagram. This operator transforms the specied query into operations that are executed on the underlying database management system. This of course requires that all sub{queries formulated in the working diagram are related to a root query via query result links or via time links which we will discuss 13

15 in Section 5. However, it might be also possible to apply another type of display operator to a single sub{query in the working diagram in order to verify the correctness of that sub{query. Due to space limitations, we will not discuss the functionality of the display operator or formatting procedures on query results in this paper. 4.2 Temporal Projection In temporal databases, a temporal projection is used to limit the data displayed for selected entities to a specic temporal element. In our graphical query language, the temporal projection operator is applied to a completed schema diagram by surrounding the diagram with a dashed box and providing a temporal element at the end of an edge labeled with one of the following qualication predicates: before, after, equal, adjacent before, adjacent after, overlap before, overlap after, during, include, start, and end [Alle83]. 4 Example 4.3: \Retrieve the name, salary, and rank of each current computer science instructor during the time period 1985 to 1988 ". DEPARTMENT DEPT INST DName = computer science during [1/1/85, 12/31/88] INSTRUCTOR * * * Salary Rank IName Figure 4: Temporal Projection Operator In Figure 4, the (non{temporal) restrict operator (DName = 'computer Science') is applied, which selects (the history) of all instructors currently in computer science department. Afterwards, the temporal projection operator [1/1/85, 12/31/88] is applied, which displays the name, salary, and rank of selected 4 Although qualication predicates should be represented graphically in a query (e.g., using icons), we use textual notations in the sequel. 14

16 instructors during the time period 1985 to If a user wishes to retrieve the complete history of computer science instructors, the temporal element [0,now) has to be specied at the end of the edge labeled with during. If a user wishes to retrieve the history of computer science instructors before (after) 1/1/86, the temporal element 1/1/86 (shorthand for [1/1/86, 1/1/86]) has to be specied at the end of the edge labeled with before (after). As part of temporal projection, we do not allow the assignment of a time element to a sub{part of a schema (i.e., sub{query) since this operation has no semantic meaning. A diagrammatic schema augmented with selection condition is used to retrieve entities. It makes sense to apply a temporal projection operator after only selecting the entities (i.e., on the entire schema) instead of applying it before selecting entities (only on some part of the schema). In our visual environment, a temporal element used in temporal projection may itself be derived from the database as the result of another query formulated separately in the working diagram. Instead of assigning a temporal element to a diagram explicitly (e.g., by means of a date), users may specify a time restriction using true times. A true time can be computed from a boolean condition correlated to the attributes of the diagram. The boolean condition used in the computation of a true time is represented graphically in a double box, linked to an edge associated with the diagram. Example 4.4: \Retrieve the history of each computer science instructor during the time period s/he was an assistant or associate professor". DEPARTMENT DEPT INST DName = computer science during Rank = associate professor or Rank = assistant professor INSTRUCTOR * * * Salary Rank IName Figure 5: Condition Based Temporal Projection 15

17 In Figure 5, a dierent temporal projection is applied to each selected entity based on the time that entity was assistant or associate professor. The time restriction is correlated to each individual entity ([Rank = 'associate professor' or Rank = 'assistant professor']), yielding a dierent temporal element for dierent instructors Temporal Selection A temporal selection is used to retrieve entities based on temporal conditions over attributes. These conditions involve the comparison of two temporal elements using the set{comparison operators =, 6=,, and. In our visual environment, the temporal selection operator is linked directly to a sub{part of a working diagram. (This is in contrast to temporal projection which is attached to the entire working diagram.) This operator is visually displayed as an association between two temporal elements: the true time of a boolean condition and a temporal element which can be either a constant time or the result of another query. The association is labeled with one of the set{comparison operators =, 6=,, or. The true time is represented as a double box that contains the boolean condition. Example 4.5: \Retrieve the current name and rank of all instructors of the computer science department who were assistant professor during the time period 1987 to 1990". DEPARTMENT DEPT INST DName = computer science INSTRUCTOR * * IName Rank Rank = assistant professor [1/1/87, 12/31/90] Figure 6: Temporal Selection 5 If a projection condition yields more than one time interval, qualication predicates like before or after are ambiguous. In such cases, users must be notied and they have to select a single time interval for the projection. 16

18 Figure 6 is a visual representation of the query in Example 4.5. It has two selection conditions: A temporal selection over the attribute Rank and a non{temporal selection over the attribute DName. For each faculty currently in the computer science department, the temporal selection condition is applied as follows: First the true time [c (Rank = 'assistant professor')] is computed and then [c] [1=1=87; 12=31=90] is evaluated. If the evaluation of the temporal selection condition returns TRUE, the current name and rank of the faculty is displayed since no temporal projection is specied. Example 4.6: \Retrieve for the period of 1987 to 1990, the name and rank of all instructors of the computer science department who were assistant professor during the time period 1987 to 1990". DEPARTMENT DName = computer science during [1/1/87, 12/31/90] DEPT INST [1/1/87, 12/31/90] INSTRUCTOR * * IName Rank Rank = assistant professor Figure 7: Temporal Projection on Temporal Selection Figure 7 can be built in an iterative, bottom{up fashion. First, a user may specify the temporal and non{temporal selection conditions as indicated in Figure 6. Afterwards, s/he may add the temporal projection condition on the entire working schema diagram by surrounding the diagram with a dashed box and providing a temporal element [1=1=87; 12=31=90] at the end of an edge labeled with during. The above example nicely illustrates how temporal projection and temporal selection operators can be easily combined. It also demonstrates how visual graphical queries can be constructed in a bottom{up, stepwise fashion by gluing together various temporal operators. These temporal operators can be easily modied, thus providing the exibility to examine dierent formulations and conditions for selections and projections in a query diagram. 17

19 5 Advanced Graphical Query Language Constructs In this section, we introduce a number of advanced feature of our graphical query language. Section 5.1 presents the time link operator which is similar to a pipe operation. The input to the time link operator is a temporal element and the output is either directly displayed or used as part of a query. Section 5.2 introduces the concepts of ltering and set operators on time links, which allow users to choose one or more time intervals from a temporal element. Finally, Section 5.3 describes how users specify temporal aggregate functions in our visual environment. 5.1 The Time Link Operator Temporal elements used during query formulation may either be assigned constant values by users or be computed from sub{query results. In order to formalize the concept of temporal elements derived from sub{queries, we introduce the time link operator which retrieves the temporal elements of entities selected as a result of query computation. The time link operator is similar to a pipe operation, which takes input from one function (in this case a temporal element), and either sends the input to another function (in this case the root query) or directly displays the temporal elements. The time link operator is a one{directional association labeled on one side with the mandatory get time words and the other side with either a temporal comparison operator [Alle83] or an empty label. In the next two examples, we illustrate the two variations of the time link operator. Example 5.1: \Retrieve the time period(s) when John Smith taught a compiler course". COURSE CName get time TEACHES INSTRUCTOR IName = John Smith during CName = compiler Figure 8: Time Link with Empty Label 18

20 Figure 8 shows how a time link operator with an empty label is used. The entire schema is enclosed in a dashed box, which is associated with a time link operator. Inside the rst dashed box, a non{temporal selection condition is applied to the Name attribute (IName = 'John Smith'). Inside the second dashed box, a temporal projection operation is applied to limit the teaching history of John Smith to compiler course. At the end, a time link operator is applied to display the time period(s) that John Smith taught a compiler course. Example 5.2: \Retrieve the name and rank of all instructors with their courses when John Smith taught a compiler course". COURSE TEACHES CName CName = compiler during get time during COURSE * CName TEACHES INSTRUCTOR IName = John Smith INSTRUCTOR * * IName Rank Figure 9: Time Link with Comparison Operator The time link operator used in Figure 9 shows how the pipe operation works: Instead of displaying the input of the time link operator, the user sends it to another query. The get time words indicate that the schema diagram on the left is used to compute temporal elements. These temporal elements are used in the temporal projection operator applied to the schema diagram on the right. The time link operator is very exible: (1) Any of its subparts can be modied, thus allowing users to experiment with dierent queries and (2) any of its subparts can be tested separately, thus allowing users to localize errors easily. In addition, the label of the time link operator can be replaced with another temporal comparison predicate without modifying the associated sub{queries. For instance, in Figure 9 a user may wish to replace the during label with before label to retrieve the name and rank of all instructors before John Smith taught a compiler course. 19

21 5.2 Temporal Functions Filtering Operators In general the time link operator may yield a temporal element that contains more than one time interval. However, during query formulation a certain time interval of a temporal element may be needed (e.g., the time interval with the maximum duration). For this purpose, we introduce a set F of unary ltering operators on time links that select time intervals and chronons from temporal elements based on certain conditions. The input as well as the output type of the ltering operator f 2 F is a time element; i.e., f : T E! T E. Below, we describe a number of ltering operators used in our visual environment. (For space limitations, we do not introduce the entire set of ltering operators.) rst (rst interval): T E! I. For a temporal element T E, rst returns the time interval I = [t s ; t e ] in T E such that there exists no other time interval I 0 = [t 0 s; t 0 e] in T E with t 0 s < t s. last (last interval): T E! I. Similar to rst except that the condition is replaced with t 0 s > t s. min duration (minimal duration): T E! I. For a temporal element T E, min duration returns the time interval I = [t s ; t e ] in T E such that there exists no other time interval I 0 = [t 0 s; t 0 e] in T E with (t 0 e? t0 s) < (t e? t s ). max duration (maximal duration): T E! I. Similar to min duration except that the condition is replaced with (t 0 e? t0 s) > (t e? t s ). Note that in the case of min duration and max duration, there may be more than one time interval that satises the condition. In that case, the result will be a set of time intervals all with the same length (min duration: T E! T E 0 ; max duration: T E! T E 0 ). In a working diagram, a ltering operator on a time link is represented as a triangle with the operator name inside. For instance, a user may wish to modify Example 5.2 to retrieve the name and rank of instructors with their courses during the rst time period John Smith taught the compiler course. In that case, the time link operator of Figure 9 is replaced with that of Figure

22 ... get time during first... Figure 10: Filtering Operator Set-Operators on Time Links In our visual environment, we allow temporal elements (computed from sub{queries and time links) to be combined through set-oriented operators (see also [GaNa93]). These set operators are: 1. An n{ary set operator [ : T E 1 : : :T E n! T E. This operator returns the union of the temporal elements T E 1, T E 2,..., T E n. 2. An n{ary set operator \ : T E 1 : : : T E n! T E. This operator returns the intersection of the temporal elements T E 1, T E 2,..., T E n. 3. A binary operator? : T E 1 T E 2. This operator returns the dierence of T E 1 and T E 2... Figure 11: Set Operators on Time Links These three set operators are shown visually in Figure 11. Both operators, [ and \, have two or more incoming edges and exactly one outgoing edge. The incoming edges represent the input temporal elements and the outgoing edge represents the resulting temporal element. In the case of the dierence operator {, the temporal element marked with a \" is subtracted from the other incoming temporal element 6. 6 The idea of applying set operators to query results can as well be adopted to the query result links presented in Section 4. Thus, the union, intersect, and minus operators from SQL2 can be integrated in our graphical query language. 21

23 The combination of set operators allows users to specify complex temporal queries graphically in an intuitive way. For example, it is possible to lter all time intervals from a time element except the rst (or last) interval as shown in the following example. Example 5.3: \Retrieve the name, rank, and courses of instructors during the time when John Smith taught the compiler course, but except the rst time period". get time... during first... Figure 12: Combining Filtering and Set Operators Figure 12 is similar to Figure 9, except that the time link operator combines ltering and set operators. The rst time interval is ltered by applying the operator rst, and it is combined with the set dierence operator { to get all time intervals except the rst time period. 5.3 Temporal and Non-Temporal Aggregation In non-temporal databases, aggregate functions such as count, sum, avg, min, and max are applied either to sets of entities or to attribute values of sets of entities. In a temporal database, whenever an aggregate function is applied to a set of temporal entities, it is conceptually applied for each time granularity separately. Thus, the result of an aggregate function is a temporal assignment from a temporal element to a range of non{temporal aggregate functions. In our graphical query language, we allow temporal aggregate operators to be applied directly to a schema diagram (inside dashed boxes used for temporal projections if any temporal projection is specied). We also allow temporal selections on temporal attributes together with temporal aggregates 7. In a temporal aggregation, a user marks an attribute as the grouping attribute by associating it with an oval labeled with G. All other non-restricted attributes are linked with aggregate functions by 7 The aggregate operators presented in this section correspond to a preliminary proposal and we plan to extend them in a number of ways. 22

24 associating them with ovals labeled with function names. Useful aggregate functions are: L (count), (sum), = (avg),? (min), and > (max). Example 5.4: \For each rank of instructors in the computer science department, retrieve the total number of students they advised before 1/1/88 ". DEPARTMENT DName = computer science DEPT INST Rank G Sno * * INSTRUCTOR ADVISES STUDENT before [1/1/88] Figure 13: Temporal Aggregation In Figure 13, the attribute Rank is marked as the grouping attribute and the attribute Sno is associated with the function L (count). In this example, the query returns the number of students advised for each granularity. However, if a user wishes to modify the granularity of the temporal aggregate function, he may rene the grouping operator to a coarser granularity. For instance, if in Figure 13 the oval containing the label G is replaced with G month, the total number of students advised per month is computed. 6 Conclusions In this paper, we addressed the issue of visual query formulation for temporal databases. We introduced a number of visual temporal constructs that allow users to build queries in a modular, bottom{up fashion. These constructs are: Temporal projection, temporal selection, time links, ltering and set operators, and temporal aggregates. We also discussed a general framework for designing a visual environment for temporal databases and identied the dierent components of such a framework: Design editor, query editor, update editor, and display editor. 23

25 This work can be extended in a number of ways: 1. Our visual query editor supports only valid time. We plan to extend our query editor to provide support for transaction time and belief time. 2. We plan to incorporate the TIME-SLICE and MOVING WINDOW operators [NaAh89] in our visual query editor so that users will be able to ask queries over time periods as well as moving time intervals. 3. We intend to extend our work and provide a visual environment for the entire life cycle of temporal database development. Possible extensions include a design editor, an update editor, and a display editor. 4. We plan to provide formal mapping algorithms of our temporal graphical queries to temporal GORDAS queries [ElWK93]. 5. We plan to implement a generic kernel for a temporal visual framework on top of existing database management systems. References [AADD92] A. Auddino, E. Amiel, Y. Dennebouy, Y. Dupont, E. Fontana, S. Spaccapietra, Z. Tari: SUPER { Visual Interaction with an Object-based ER Model. In G. Pernul, A.M. Tjoa (Eds.), Eleventh International Conference on the Entity-Relationship Approach, LNCS 645, Springer-Verlag, Berlin, 1992, pp [Alle83] J. F. Allen: Maintaining Knowledge about Temporal Intervals. Communications of the ACM 26:11 (1983), 832{843. [AlSS93] K. K. Al-Taha, R. T. Snodgrass, M. D. Soo: Bibliography on Spatiotemporal Databases. SIGMOD Record 22:1 (1993), 59{67. [BCCL93] C. Batini, T. Catarci, M. F. Costabile, S. Levialdi: On Visual Representations for Database Query Systems In Proceedings of the Interface to Real and Virtual Worlds Conference, Montpellier, France, 1993, pp [CERE90] B. Czejdo, R. Elmasri, M. Rusinkiewicz, D. W. Embley: A Graphical Data Manipulation Language for an Extended Entity-Relationship Model. IEEE Computer 23:3 (1990), 26{36. [Chen76] [CaSa89] P. P. Chen: The Entity-Relationship Model { Towards a Unied View of Data. ACM Transactions on Database Systems 1:1 (1976), 9{36. T. Catarci, G. Santucci: Query by Diagram: A Graphic Query System. In F. Lochovsky (ed.), Eight International Conference on the Entity-Relationship Approach, North-Holland, Amsterdam, 1989, 291{

26 [ElKo93] R. Elmasri, V. Kouramajian: A Temporal Query Language for a Conceptual Model. In N. R. Adam, B. K. Bhargava (eds.), Advanced Database Systems, LNCS 759, Springer-Verlag, Berlin, 1993, 175{190. [ElLa85] R. Elmasri, J. Larson: A Graphical Query facility for ER Databases. In J. Liu (ed.), Proc. 4th International Conference on the Entity-Relationship Approach, 1985, 236{245. [ElNa94] [ElWi81] R. Elmasri, S. B. Navathe: Fundamentals of Database Systems (Second Edition). Addison-Wesley, Amsterdam, R. Elmasri, G. Wiederhold: GORDAS: A Formal High-Level Query Language for the ER Model. In P. Chen (ed.), Entity-Relationship Approach to Information Modeling and Analysis, Elsevier Science, [ElWK93] R. Elmasri, G. T. Wuu, V. Kouramajian: A Temporal Model and Query Language for EER Databases. In A. Tansel, J. Cliord, S. Gadia, S. Jajodia, A. Segev, R. Snodgrass (eds.), Temporal Databases: Theory, Design, and Implementation, Database Systems and Applications Series, Benjamin/Cummings, Redwood City, CA, 1993, 212{229. [GaNa93] S. Gadia, S. Nair: Temporal Databases: A Prelude to Parametric Data. In A. Tansel, J. Cliord, S. Gadia, S. Jajodia, A. Segev, R. Snodgrass (eds.), Temporal Databases: Theory, Design, and Implementation, Database Systems and Applications Series, Benjamin/Cummings, Redwood City, CA, 1993, 28{66. [GaYe88] S. K. Gadia, C.-S. Yeung: A Generalized Model for a Relational Temporal Database. In H. Boral, P.- A. Larson (eds.), Proc. ACM SIGMOD Int. Conf. on Management of Data 1988, Chicago, SIGMOD Record, ACM Press, New York, 1988, 251{259. [HaMc81] M. M. Hammer, D. J. McLeod: Database Description with SDM: A Semantic Database Model. ACM Transactions on Database Systems 6:3 (1981), 351{386. [JCEG94] C. Jensen, J. Cliord, R. Elmasri, S. Gadia, P. Hayes, S. Jajodia: A Consensus Glossary of Temporal Database Concepts. SIGMOD Record 23:1 (1994), 52{63. [JCGS92] C. Jensen, J. Cliord, S. Gadia, A. Segev, R. T. Snodgrass: A Glossary of Temporal Database Concepts. SIGMOD Record 21:3 (1992), 35{43. [NaAh89] S. B. Navathe, R. Ahmed: A Temporal Relational Model and a Query Language. Information Sciences 49:2 (1989), 147{175. [ObSa94] A. Oberweis, V. Sanger: GTL { A Graphical Language for Temporal Data. In H. Hinterberger, J. French (eds.), Procedings of the Seventh International Working Conference on Scientic and Statistical Database Management, IEEE Computer Press, [RoSe91] E. Rose, A. Segev: TOODM { A Temporal Object-Oriented Data Model with Temporal Constraints. In T. Teorey (ed.), Entity-Relationship Approach: The Core of Conceptual Modelling, Elsevier Science, Amsterdam, 1991, 205{229. [Snod87] R. Snodgrass: The Temporal Query Language TQuel. ACM Transactions on Database Systems 12:2 (1987), 247{298. [Snod94] R. Snodgrass: Overview of the Special Section on Temporal Database Infrastructure. SIGMOD Record 23:1 (1994), 34{34. [Soo91] M. D. Soo: Bibliography on Temporal Databases. SIGMOD Record 20:1 (1991), 14{23. [SmSm77] J. M. Smith, D. C. P. Smith: Database Abstractions: Aggregation and Geberalization. Communications of the ACM 20:6 (1977), 405{413. [WuDa92] G. Wuu, U. Dayal: A Uniform Model for Temporal Object-Oriented Databases. In F. Golshani (ed.), Eighth International Conference on Data Engineering, IEEE Computer Society Press, 1992, 584{