TVQL - Temporal Versioned Query Language - Springer Link

TVQL - Temporal Versioned Query Language Mirella Moura Moro1 , Nina Edelweiss1, Aglaê Pereira Zaupa1, 2 , and Clesio Saraiva dos Santos1 1

Instituto de Informática - Universidade Federal do Rio Grande do Sul Av. Bento Gonçalves, 9500 - Porto Alegre, RS, Brazil - CxP. 15064. CEP 91501-970 2 Faculdade de Informática - Universidade do Oeste Paulista R. José Bongiovani, 700 - Presidente Prudente, RS, Brazil. CEP 19050-260 1 2 {mirella, nina, clesio}@inf.ufrgs.br, [email protected]

Abstract. The Temporal Versions Model (TVM) is an Object Oriented Data Model developed to store the object versions and, for each version, the history of its dynamic attributes and relationships values. In this work, we propose a query language for this model. The language, called Temporal Versioned Query Language - TVQL, is based on SQL, adding new features to recover temporal information and versions. An alternative to its implementation on top of a commercial database is also presented.

1

Introduction

Information stored in a database evolves with time and, very often, it is necessary to keep track of such evolution. This fact led to researches concerning temporal database systems [2, 4, 5, 9, 10], which keep the evolution of data by associating timestamps to them. On the other hand, non-conventional applications, as CAD and CASE tools, often demand the support of many design alternatives. To fulfill such requirement, many works have focused on the question of versions support [1, 3, 6, 8, 11]. In [7], Moro et al. present a temporal object-oriented versions model (Temporal Versions Model - TVM), which brings together features of a version model and a temporal model. The Model allows the storage of all versions of an object and the history of dynamic attributes and relationships values. An approach to implement the TVM model on top of a commercial database is also presented in that work. TVM is part of a project that aims implementing an integrated environment for class specification, object versioning, versions management, query, and visualization. There is an interface for temporal versioned class specification that allows the creation of tables in the database according to this specification. Now, this work presents a query language for TVM (Temporal Versioned Query Language – TVQL). The language adds new features to SQL for recovering temporal information and versions. An alternative to its implementation is also presented. The paper is structured as follows. Section 2 illustrates the example to be used in the paper. Section 3 briefly exposes the Temporal Versions Model. Section 4 presents the query language TVQL. An alternative to its implementation on top of a commercial database is proposed in Section 5. Section 6 cites some related works. Section 7 summarizes the main ideas of this paper and presents future works. R. Cicchetti et al. (Eds.): DEXA 2002, LNCS 2453, pp. 618–627, 2002. c Springer-Verlag Berlin Heidelberg 2002

TVQL - Temporal Versioned Query Language

2

619

Example

In order to illustrate different TVQL queries, TVM is used to model a simple application: a website design company, as presented in [7]. Beyond its clients’ sites, the company keeps the professional pages of its employees. In order to simplify and make the concepts clearer, only the nucleus of the model is presented. Each website is composed by one or more pages, one of them being the initial or main page. Each page is associated to a page pattern, which defines the background color and image, a banner, and the default font specification. The pattern is used as a standard for the employees’ page layout. This pattern may vary according to the seasons of the year and commemorative dates, for instance. The class diagram corresponding to this example is presented in Fig. 1. associatedWith 1..1

0..n

WebSite

PagePattern patternName backgrdColor backgrdImage banner

0..1 initial Page 1..1 1..n

URL online

0..n

default

Font

1..1

WebPage pageTitle pageText

fontType fontSize fontColor fontEffect

Fig. 1. Class Diagram of the example

3

Temporal Versions Model

The Temporal Versions Model (TVM) is proposed as an object-oriented (OO) data model that extends a version model by adding the temporal dimension to the instance versioning level [7]. Indeed, the user may model the database considering the design alternatives as well as the data evolution. It is important to notice that TVM does not require all classes to be temporal and versionable, allowing the integration with existing applications. TVM allows the storage of different designed versions together with all updates in values of those attributes and relationships defined as temporal. Therefore, different versions coexist, representing branched time order that is not usual in other models, in which the time order is almost always linear. Within a version, the updates of temporal attributes and relationships vary in linear order. Consider a Travel Agency as a client of the Website Company. The Agency has special tourism packages for international holydays with advertisements in the banner attribute. As illustrated in Fig. 2, a temporal versioned class may have instances with no versions and versioned objects. The instance Fall has no versions, while the instance Summer has three versions – the basic summer version S, a version to be used advertising the American July 4th, and a version for the French national date, July 14th. This figure also clarifies the evolving behavior of the temporal property banner whose value changes from US-J4 to FR-J14. The temporal labels mean that a value is stored in the database and denotes the real world value on 06/28/2002; and another value is stored on 07/01/2002 but is valid only on 07/05/2002.

620

M. Moura Moro et al.

Instance without versions

PagePattern

Fall

Summer Instance with versions Versions

S

Fr-Jul14

US-Jul4

06/28/2002 07/05/2002

US-J4

Fr-J14

06/28/2002 07/01/2001

(a)

Valid Time Transaction Time

(b)

Fig. 2. a. An instance with no versions (Fall), and a versioned object (Summer) with three versions (S, US-Jul4, and Fr-Jul14). b. The evolving behavior of the temporal property banner with temporal labels.

4

Temporal Versioned Query Language

After this brief outline of TVM, this section shows its query language, Temporal Versioned Query Language (TVQL). The general form of a TVQL query is: query ::=

SELECT [ EVER ] [ DISTINCT ] targetC { , targetC } FROM identificC { , identificC } [ WHERE [ EVER ] searchC ] [ GROUP BY groupC { , groupC } [ HAVING logicalExpr ] ] [ ORDER BY orderC { , orderC } [ setOp query ] ; targetC ::= ( * | propertyName | aggregationFunctions | preDefInterval | preDefInstant ) [ AS identifier ] identificC ::= className [ .VERSIONS ] [ aliasName ] searchC ::= logicalExpr | tempExpr groupC ::= propertyName | preDefInterval | preDefInstant logicalExpr ::= AnyLogicalExpression tempExpr ::= logicalExpr | PRESENT ( logicalExpr ) orderC ::= groupC [ ASC | DESC ] setOp ::= UNION | INTERSECTION | DIFFERENCE preDefInterval ::= [ propertyName. ] ( tInterval | vInterval ) preDefInstant ::= [ propertyName. ] ( tiInstant | tfInstant | viInstant | vfInstant ) | [ className. ] ( iLifeTime | fLifeTime )

Where brackets [ ] indicate optional segment, braces { } indicate optional repetitive segment (zero or more times), parentheses indicate set of options, | indicates “or”, emphasized (bold) words are keywords. TVQL is based on SQL and keeps its following features: base structure with selectfrom-where, alias for attributes (select) and classes (from), keyword distinct to eliminate duplicate values, operators for comparison, range and pattern matching (, =, =, , in, between..and, like), arithmetic operators (+, -, *, / ), logical operators (or, and, not), set operations (union, intersection, difference), aggregation functions (count, sum, avg, min, max), and other clauses (group by, having, order by). By default, a TVQL statement retrieves current data stored in the current database state. Considering the temporal features of TVM, TVQL offers properties for predefined instants and intervals with a set of operators. Several combinations of current and historic values may be declared in a query, depending on the use of the special keywords ever and present. Ever may be used after select and where to take into account not only the current values, but also the whole attributes and relationships histories. When ever is used in the select clause, the


621

query retrieves the whole history of the chosen temporal properties. The use of ever in the where clause makes all values in a property history to be considered by the search condition. Another possibility is to retrieve historic values according to a current condition. This is done using ever in the select clause, and present in the where clause, which thus receives the current condition. In order to retrieve and consider the temporal labels, TVQL specifies pre-defined temporal properties: tInterval (transaction time interval), vInterval (valid time interval), tiInstant (initial transaction time), tfInstant (final transaction time), viInstant (initial valid time), and vfInstant (final valid time). These properties are related to those attributes and relationships defined as temporal. Since there may be more than one temporal attribute in the same query, the user must specify to which attribute these properties are related. Otherwise, the query considers the temporal labels of all temporal attributes and relationships cited in the statement. There are also two pre-defined properties related to the object lifetime: iLifetime (initial lifetime of the object), and fLifeTime (final lifetime of the object). All these pre-defined properties are defined to hide storage details from the user. Moreover, this feature allows greater implementation flexibility, as classes and attributes that store this information are not specified in TVQL. TVQL proposes operators and behaviors for the existing operations to be included in the logical expressions of the where clause. There are operators for sequence of instants and intervals (before, into, after). The operators for temporal intervals are: • intersect – returns true if the intervals have at least one common point. • overlap – returns true if the second interval is within the first one. • equal – returns true if both intervals start and finish in the same instants. The user defines in the from clause which classes will be considered by a query. In TVQL, objects and versioned objects (current versions) are specified by the class name. The analysis of all versions is specified by adding the keyword versions to the class name. Consider the following queries: 1. Select banner from PagePattern; 2. Select banner from PagePattern.versions; Query 1 takes into account Fall and the current version of Summer, while query 2 considers Fall together with all versions of Summer (S, US-Jul4 and Fr-Jul14). TVQL has three sets of functions to get specific information about versions and versioned objects. First, state functions evaluate the state of versions and return a boolean value – isWorking, isWorkingAt (if the version is in state “working” at a given time). Navigating functions evaluate the position of versions in the derivation sequence and return a boolean value – isCurrent, isUserCurrent (if the user defined it as the current one), isFirst, isLast, isPredecessorOf, isSuccessorOf. Finally, control functions retrieve information from the versioned object control – firstVersion, lastVersion, versionCount, currentVersion, nextVersionNumber, among others.

5

Implementing TVQL

The use of a powerful temporal data model does not require a specific database management system to support it. Existing commercial DBMSs may be used for this purpose as long as a proper mapping from the temporal data model to the data model underlying the adopted DBMS is provided. In order to show the feasibility of this approach, TVM was mapped to a commercial database in [7]. Now, this work

622


presents the mapping from TVQL to SQL based on a mapping from TVM to a relational database. Instead of mapping TVM to an object-oriented database, this approach was chosen due to the widespread use and stability of relational databases. Basically, the mapping process joins the two parts of TVM mapping (representing the class model’s hierarchy, and implementing the application classes) with a third one: the mapping of the TVQL functions and properties to SQL-92. 5.1

Mapping TVM to a Relational Database

In summary, the mapping from TVM classes to relational tables considers these steps: 1. If the class is standard, it is mapped to a table (main table) with the same name of the class, its attributes are mapped to columns, and the primary key is tvoid. 2. If the class is temporal versioned, it is also mapped to a main table with the same name of the class, with the following additional characteristics: 3. The inherited attributes alive, configuration, status are mapped to columns in the main table. 4. The inherited attributes ascendant, descendant, predecessor and successor are mapped to two special tables (AscDesc and PredSucc), which store the pairs and temporal labels (as these attributes are temporal). 5. There is also a reference (refVOC, foreign key) to the tvoid of the respective versioned object control (which is mapped to the table VOC to store the information of all version controls, more details in reference [7]). 6. Each temporal attribute and relationship is stored in a separated table (auxiliary table), which stores its history. These tables present the following columns: tvoid (foreign key related to the main table), value (with the same type of the attribute), and itTime, ftTime, ivTime, fvTime (temporal labels for initial and final transaction times, initial and final valid times). The primary key is composed by tvoid, itTime and ivTime. Main tables store current data, and auxiliary tables store history values. The current values are also stored in the auxiliary tables in order to keep the temporal labels. This kind of implementation facilitates the query about current data, because only the main tables are considered. Similarly, queries about history consider only the auxiliary tables. Triggers and stored procedures are defined in order to manage current and historic data. For example, class PagePattern is mapped as shown in Fig. 3. PagePattern patternName backgrdColor backgrdImage t banner

PagePattern tvoid alive configuration status refVoc patternName backgrdColor backgrdImage banner default

PagePattern_Banner tvoid value itTime ftTime ivTime fvTIme

...

Fig. 3. A temporal versioned class (PagePattern) is mapped to a main table (PagePattern) and auxiliary tables in a relational database. The mapping is summarized with only one auxiliary table (PagePattern_Banner) graphically presented. Inherited attributes are presented in gray.


5.2

623

Mapping TVQL to SQL

The mapping from TVQL to SQL starts with the representation of the from clause, followed by the select and where clauses, and is divided in two parts: (i) mapping of classes, attributes and associations; and (ii) mapping of data restrictions. There is no special rule for mapping the general TVQL to SQL (keyword distinct; aggregation functions - count, sum, avg, min, max; and grouping clauses - group by, having, order by). Classes and properties involved in these cases are mapped to the respective tables implemented. In order to illustrate this procedure, some examples of TVQL queries with their mapping to SQL are presented in this section. Mapping Classes, Attributes and Associations. The first step is to define in which tables of the database the classes and properties are stored. In from clause, classes are mapped to the main tables, and receive an alias (t1, t2, and so on). In select clause, attributes are mapped to the respective columns in the tables defined in from. In case of usual classes, the mapping is direct, as query 1. Current data. Queries 1 and 2 consider only the current values stored in the main tables. The TVQL query is on the left side, and the respective SQL query is on the right. Query 1) List all font types and sizes. SQL TVQL SELECT fontType, fontSize SELECT t1.fontType, t1.fontSize FROM Font t1; FROM Font; In case of temporal versioned classes, if the keyword versions is not specified, the query must consider only the objects and current versions. Then, the table VOC is included in the from clause, and a special condition in the where clause, as the next query shows. Query 2) List all current banners. The special condition means that either there is no reference to the versioned object control (the object has no versions) or there is a reference and the version is the current one. With keyword versions, this special condition is not used. SQL TVQL SELECT t1.banner SELECT banner FROM PagePattern t1, VOC t2 FROM PagePattern; WHERE (t1.refVOC = null) or (t1.refVOC = t2.tvoid and t1.tvoid = t2.currentVersion); Data history. If the keyword ever is used after select, the auxiliary tables are also considered. As there is no temporal data restriction, queries 3 and 4 consider the current database state, which has final transaction time with value null or ‘12/31/9999’. Query 3) List all banners in the history of all versions. SQL TVQL SELECT t1.value SELECT EVER banner FROM PagePattern.versions; FROM PagePattern_Banner t1 WHERE t1.ftTime = ‘12/31/9999’;

624


Time and versions. Query 4) List the first version of all objects over history in class PagePattern, and the interval in which they are valid. TVQL SQL SELECT EVER firstVersion, SELECT t3.value, t3.ivTime || “..” || t3.fvTime vInterval FROM PagePattern t1, VOC t2, VOC_FirstVersion t1 FROM PagePattern.versions; WHERE t1.refVOC = t2.tvoid and t2.tvoid = t3.tvoid and t1.ftTime = ‘12/31/9999’; This query shows that getting the first version of a class is easy, while mapping to SQL is more complex. The possibility of querying the versioned object control directly by keywords, which are translated to its attributes, makes all query process involved in the implemented database transparent. Mapping Data Restrictions. The second step is to map the data restrictions. In case of usual classes, the mapping is equal to SQL. In case of temporal versioned classes, a lot of possibilities must be considered, as presented in the next queries. Temporal conditions. Query 5) Retrieve the current banner from versions of page patterns that have banner name beginning with letter A in its history. SQL TVQL SELECT banner SELECT t1.banner FROM PagePattern.versions FROM PagePattern t1, PagePattern_Banner t2 WHERE EVER WHERE t1.tvoid = t2.tvoid and banner LIKE ‘A%’; t2.ftTime = ‘12/31/9999’ and t2.value like ‘A%’; Query 6) Retrieve the current banner from versions of page patterns that have banner beginning with letter A as the database state on last December 31. SQL TVQL SELECT t1.banner SELECT banner FROM PagePattern.versions FROM PagePattern t1, PagePattern_Banner t2 WHERE t1.tvoid = t2.tvoid WHERE EVER and t2.value like ‘A%’ banner LIKE ‘A%’ and and t2.itTime = ‘12/31/2001’; Queries 5 and 6 are very similar. The former considers the current database state, while the latter considers the database state as 12/31/2001. Another possibility for this query is to retrieve the history of banners based on current data, as query 7. Query 7) Retrieve the history of banners that currently begin with letter A. SQL TVQL SELECT t2.value SELECT EVER banner FROM PagePattern.versions FROM PagePattern t1, PagePattern_Banner t2 WHERE t1.tvoid = t2.tvoid WHERE PRESENT and t2.ftTime = ‘12/31/9999’ (banner LIKE ‘A%’); and t1.banner like ‘A%’; Version features. Query 8) Retrieve pattern name and banner of stable versions in class PagePattern, with identification of their successors.


TVQL SELECT p1.patternName, p1.banner, p2.tvoid FROM PagePattern.versions p1, PagePattern.versions p2 WHERE p1.isStable and p1.isPredecessorOf (p2);

625

SQL SELECT t1.patternName, t1.banner, t2.tvoid FROM PagePattern t1, PagePattern t2, PredSucc t3 WHERE t1.status = ‘S’ and t3.predecessor = t1.tvoid and t3.successor = t2.tvoid and t3.ftTime = ‘12/31/9999’;

Two or more Temporal Attributes. Query 9) Retrieve the url of online pages over the history. This query considers two temporal attributes in the same statement. The operation intersect appears in this query to assure that the result is not a Cartesian product between the histories of attributes url and online. Furthermore, it assures history consistency as the query retrieves only the urls that are valid when the pages are online. SQL TVQL SELECT EVER url SELECT t1.value FROM WebPage.versions FROM WebSite_URL t1, WebSite_Online t2 WHERE online = true and WHERE t1.tvoid = t2.tvoid and t2.value = true and url.vInterval INTERSECT t1.ftTime = ‘12/31/9999’ and t2.ftTime = ‘12/31/9999’ online.vInterval; and t1.ivTime= t2.ivTime;

6

Related Works

Temporal concepts and versions modeling are mostly treated individually in literature. Reference [7] cites at least eight works about temporal databases and seven about versions modeling, and just two models with time and versions, which are presented in this section. Other temporal query languages and version manipulation languages are also presented with their main particularities. Finally, we cite some similar and different features of these languages compared to TVQL. The first model with time and versions is an extension for the OODAPLEX model, as a uniform model for temporal and versioned object-oriented databases, proposed by Wuu and Dayal [11]. The second one is a formal definition of a temporal versioned Object-Oriented data model (TVOO), proposed by Rodriguez, Ogata and Yano [8]. However, it has no query language specified. In the OODAPLEX extension, queries are operations (functions) that map object (perhaps complex objects) to objects. Instead of select, the query structure uses for each, for the, for all, and for some. They uniformly combine retrieval on individual objects and aggregates of objects, associative retrieval and navigation retrieval. No special operators are necessary for temporal queries. However, while the retrieval of temporal and non-temporal information is uniformly expressed, the concept of version is not explicitly defined. Some temporal query languages and version manipulation languages are presented as follows. VOHQL [3] is a visual query language for versions. The model represents the database as a graph of nodes and links. Expressing a VOHQL query consists of selecting links and performing operations from nodes of the graph. The language allows querying versions independent of others and versions organized into forests or

626


trees. It has specific function for versions graph (forest, unforest, tree, untree), past and current links (past, current). ATSQL [2] extends SQL using temporal modifiers or flags that may precede query statements (upward compatibility - UC, temporal upward compatibility - TUC, sequenced - SEQ, and non-sequenced queries - NONSEQ) in transaction and valid dimensions. It also allows coalescing and interval preservation. TF-ORM [4] is a model with temporal functionality in objects with roles. Its language has special clauses when and as on, predicates (is_valid_at, active_class ...), operators (always past, since...) and temporal functions (value, class_end_time ...). TSQL2 [9] supports time periods, multiple granularity, calendars, indeterminacy, selection operators (extractors, constructors and comparison). SQL3 [10] adds object oriented features, the keywords validtime, transactiontime and nonsequenced, and temporal semantic to SQL. TVQL is an SQL-based query language that allows usual SQL statements and retrieves data from the current and the past database states with time and versions information. Similarly to VOHQL, TVQL allows queries about independent versions as well as versions organized in the derivation graph. Instead of new clauses and modifiers (as presented in TF-ORM, TSQL2, SQL3), TVQL retrieves historic data values using pre-defined temporal properties in the search clause, and the keyword ever to retrieve all history. It also allows to rollback the database to previous states using these same properties, ensuring an homogeneous behavior for valid and transaction times. Finally, TVQL can query current and historic values in the same statement by combining ever and present keywords. Finally, as most temporal languages, TVQL has temporal operators for handling instants and intervals (before, into, overlap…). It also presents predicates for instance versions order, stored in the versioned object control (first, last, next, and current).

7

Summary and Concluding Remarks

This paper presented a query language (TVQL) for time-evolving systems with versions support that may be modeled using TVM. Although TVM is an objectoriented model, the query language is based on SQL, as part of an environment for temporal versions management under development on top of a relational database. The mapping from TVQL to SQL is also presented. TVQL allows usual SQL statements. It also retrieves instances with time and versions associated to. Many examples of TVQL statements are presented with their mapping to SQL, covering the most important features of the language. Instead of changing the base SQL structure (select-from-where), TVQL adds new properties to SQL clauses. These properties may retrieve past, current, and future data values, as well as current and past database states. Furthermore, the same query statement may consider current and historic values, by combining keywords ever and present. All these pre-defined properties are defined to hide storage details from the user. Therefore, this feature allows greater implementation flexibility, as the classes and attributes that store this information are not specified in TVQL. A complete grammar was developed to formalize the structure and syntax of TVQL. Only a summary of the TVQL BNF is presented here, due to space limitation.


627

Among the language features are: retrieval of objects and versions independently and according to the derivation graph, querying over versions from one or more entities, homogeneous behavior for valid and transaction times, branched time information manipulation, querying over logically deleted instances, transparency of TVM specific features, and addition of few keywords to SQL. Considering the intended integrated environment, the phase of TVM implementation is almost complete. There is an interface for temporal versioned class specification that allows creating tables in the database according to this specification. TVQL is mapped to SQL to run on top of the mapped tables. Finally, the complete data manipulation language (with create, insert, update and delete statements) is also under development. Furthermore, the same project is extending TVM for supporting schema versioning and evolution, with a concrete plan already proposed. Other features must be added to TVQL when this part is complete.

References 1. Andonoff, E., Hubert, G., Le Part, A.: A Database Interface Integrating a Querying Language for Versions. In Procs. of Advances in Databases and Information Systems ADBIS. Lecture Notes in Computer Science, Vol. 1475. Springer-Verlag, Berlin (1998) 200-211 2. Böhlen, M. H., Jensen, C. S., Snodgrass, R. T.: Temporal statement modifiers. ACM Transactions on Database Systems, ACM Press, Vol. 25, No. 4 (December 2000) 407-456 3. Conradi, R., Westfechtel, B.: Version Models for Software Configuration Management. ACM Computing Surveys, Vol. 30, No. 2 (June 1998) 232-282 4. Edelweiss, N., Hübler, P., Moro, M.M., Demartini, G.: A Temporal Database Management System Implemented on Top of a Conventional Database. In Procs. of Intl. Conf. of the Chilean Computer Science Society (2000) 58-67 5. Etzion, O., Jajodia, S., Sripada, E. (eds.): Temporal Databases: Research and Practice. Lecture Notes in Computer Science, Vol. 1300. Springer-Verlag, Berlin (1998) 6. Golendziner, L.G., dos Santos, C.S.: Versions and configurations in object-oriented database systems: a uniform treatment. In Procs. of Intl. Conf. Manag. of Data (1995) 18-37 7. Moro, M.M., Saggiorato, S.M., Edelweiss, N., Santos, C.S. dos.: Adding Time to an ObjectOriented Versions Model. In Procs. of Intl. Conf. on Database and Expert Systems Applications - DEXA. Lecture Notes in Computer Science, Vol. 2113. Springer-Verlag, Berlin (2001) 805-814 8. Rodríguez, L., Ogata, H., Yano, Y.: TVOO: A Temporal Versioned Object-Oriented data model. In Information Sciences, Elsevier Science, Vol. 114 (1999) 281-300 9. Snodgrass, R.: The TSQL2 Temporal Query Language. Kluwer Publishers (1995) 10. Snodgrass, R., Böhlen, M., Jensen, C., Steiner, A.: Transitioning Temporal Support in TSQL2 to SQL3. In: O. Etzion et al (eds.): Temporal Databases Research and Practice. Lecture Notes in Computer Science, Vol. 1300. Springer-Verlag, Berlin (1998) 150-194 11. Wuu, G. T. J., Dayal, U.A.: A Uniform Model for Temporal and Versioned Object-Oriented Databases. In: A. Tansel et al (eds.): Temporal Databases: Theory, Design, and Implementation. Benjamin/Cumming (1993) 230-247