Temporls datu bzes sistmas veidoana

22

The scope of the TSQL language[footnoteRef:2] [2: Richard Snodgrass. TSQL: A Design Approach, 1992.]

1. TSQL is to be a relational query language.Given that SQL is intergalactic dataspeak (Mike Stonebrakers term), TSQL should whenever possible be consistent with standard SQL, specically, SQL89. It simply doesnt make sense to base TSQL on competing (and arguably better) query languages such as Quel, Datalog, or Daplex. (Given that my language design work is based on Quel, I nd it particularly painful that SQL has dominated over that superior language.) While I strongly agree that interesting research is possible and even desirable in extending the other languages to include temporal support, such extensions are necessarily outside of the scope of TSQL.2. TSQL need not be consistent with existing standards.In general, TSQL need not be consistent with SQL2, which is in the nal standardization process, nor SQL3, which is currently being designed. SQL2 contains severe aws in its (minimal) handling of time-stamps, and SQL3 is a moving target which, in its present state, is regarded by many as a baroque design with a bewildering array of features. Consistency with the non-temporal aspects of existing standards for SQL, including SQL89, SQL2, and SQL3, is desirable if such consistency does not conict with other goals.3. TSQL will not be another standard.While the goal is a fully elaborated language design, there is no expectation that this design will be made into a standard. Of course, one hopes that our results would be acceptable to the standards bodies; at a minimum, our design should be communicated to these bodies. However, it is important to keep in focus the objective of the TSQL design: to provide a basis for future research in temporal databases. It also must be emphasized that TSQL should in no way limit or constrain future research in temporal databases, which should be free to adopt or propose whatever linguistic constructs are appropriate.4. TSQL will not be an object-oriented query language.While temporal object-oriented query languages are being actively investigated, it would be distracting and counter-productive at this stage to attempt to merge the rather disparate approaches of object-oriented and relational languages while also addressing the temporal processing needs. Those involved in object-oriented language design are encouraged to produce, in parallel with this eort, a temporal object-oriented extension to SQL. At a later date, the two extensions could be merged.5. TSQL should be comprehensive.TSQL should have constructs, extended in a natural fashion, that support all of the functionality of SQL, including update, aggregates, and schema specication and evolution. Consistent with the modier temporal, TSQL should support both valid and transaction time.6. The language design should include a formal semantics.Fortunately, there is a tradition of rigor in the temporal database community. The recent publication in TODS of a straightforward semantics of SQL will also help here.7. The language will have an associated algebra.Such an algebra would demonstrate the existence of an executable equivalent to the declarative constructs in the language, and would suggest implementation strategies.8. TSQL will be a language design.The TSQL design should not attempt to dene storage structures, indexing structures, access methods, fourth-generation interfaces, support for distributed systems or heterogeneous databases, or optimization techniques. Such aspects, while important, are more properly the target of the research eorts that will utilize TSQL as a common substrate.9. TSQL should reect areas of convergence.The design of TSQL should avoid active areas of research where new results are generated frequently. Such areas include historical indeterminacy and temporal database design.

Temporls vaicjumu valodas pamatkoncepcijas

1. Darbam ar temporlm datu bzm ir jizstrd vaicjumu valoda, kas btu:

1) balstta uz SQL valodu;

2) ktu par SQL valodas paplainjumu.

2. Temporlm vaicjumu valodm jpaplaina visas trs datu modea komponentes:

1) datu struktru;

2) datu apstrdes darbbas;

3) ierobeojumus.

3. Jebkurai korektai konstrukcijai vaicjumu valod SQL ir jbt korektai ar jaunaj valod. Ir jsaglab ar o vaicjumu semantika (rezulttiem ir jbt tdiem paiem k SQL valodas vaicjumiem).

SQL and temporal SQL queries

SQL query Relational algebra actions . . .

SELECT ...

FROM ...

WHERE ...

...

Temporal SQL query Tempral algebra actions . . .

SELECT ...

FROM ...

WHILE ...

VALID(A) ...

...

Temporal query languages

Peuquet (1994) mentions that the development of temporal query languages is a relatively new area, that has not received much attention from research and development until recently. Nevertheless over 20 query languages have been proposed.

Most developments are a result of extending existing query languages such as SQL (Structured Query Language) or Quel, a query language for the INGRES relational DBMS, to the spatio-temporal domain. Tansel etal. (1993) gives a survey of much of the work performed.

TOSQL developed by Ariav (1986) is an extension of SQL. It allows access to both current data and their previous versions, but does not include update semantics.

Snodgrass (1987) extended Quel to TQuel with language constructs to retrieve facts that have been time stamped with a validity interval.

HTQUEL (Homogeneous Temporal Quel) proposed by Gadia (1988) is based on the same query language as TQuel. Time is considered as discrete equidistant time intervals.

Kim etal. (1990) developed ETQL as a front-end system to INGRES. ETQL supports abstract time (including relative time, e.g., last spring) to achieve easier specification of time in queries.

In 1994 the specification of TSQL2 was published (Snodgrass etal., 1994), which later resulted in proposals for an extension to SQL3[footnoteRef:3] called SQL3/temporal. [3: http://www.objs.com/x3h7/sql3.htm]

Standard SQL does not include time support except for user-defined time. Neither transaction time nor valid time is available. Date and time support in SQL-92 are similar to that in DB2 (Melton and Simon, 1993). The design for SQL3 only corrected some of the inconsistencies, but contains no additional temporal support over SQL-92 (Pissinou etal., 1994). However, until 1994 the SQL3 proposals included several constructs that can be useful for temporal extensions (e.g., interval data type). Since then several change proposals were submitted to the ANSI and ISO SQL3 standards committees for adding a new part termed SQL/Temporal (Snodgrass, 1997; Snodgrass etal., 1996b,a).

None of these temporal query languages are built for complex spatial queries.

Oracle recently announced their support for the HHCODE standard for spatial attributes. Such efforts could induce further developments in the research of temporal query languages including spatial aspects.

Commercial database systems often support transaction time mechanism based on tuple time-stamping.

Valid time is not supported as a built-in functionality.

TSQL2 and SQL3 Interactions

Various members of the temporal database research community have worked to transfer some of the constructs and insights of TSQL2 into SQL3.

The first step was to propose a new part to SQL3, termed SQL/Temporal. This new part was accepted at the Ottawa meeting in January, 1995 as Part 7 of the SQL3 specification. A modification of TSQL2's PERIOD data type is included in that part.

Discussions then commenced on adding valid-time and transaction-time support to SQL/Temporal. Two change proposals, ANSI-96-501 and ANSI-96-502, were unanimously accepted by ANSI and forwarded to ISO in early 1997, as MAD-146r2 (pdf) and MAD-147r2 (pdf), prepared for the ISO meeting in Madrid. A discussion of these proposals may be found in "Transitioning Temporal Support in TSQL2 to SQL3," by R. T. Snodgrass, M. H. Bohlen, C. S. Jensen, and A. Steiner, in Temporal Databases: Research and Practice, O. Etzion, S. Jajodia, and S. Sripada (eds.), Springer, pp. 150-194, 1998 (pdf).

An etensive comparison between standard SQL and the proposed temporal support may be found in chapter 12 of Developing Time-Oriented Database Applications in SQL, Richard T. Snodgrass, Morgan Kaufmann Publishers, Inc., 1999 (pdf). Due to disagreements within the ISO committee, the project responsible for temporal support was canceled in 2001. However, concepts and constructs from SQL/Temporal were subsequently included in the SQL:2011 standard and have been implemented (via various syntaxes and semantics) in IBM DB2, MarkLogic Server, Microsoft SQLServer, Oracle, SAP HANA, and Teradata Database (see below); other products have included temporal support (see the list below for details). These ideas have also made their way into design patterns for things that change with time.

Temporal Facilities in the SQL Standard

ISO/IEC 9075, Database Language SQL:2011 Part 2: SQL/Foundation, published December 15, 2011 (and weighing in at 1434 pages), includes clauses in table definitions to define "application-time period tables" (essentially valid-time tables), with sequenced primary and foreign keys, This standard also includes single-table valid-time sequenced insertions, deletions, and updates. Nonsequenced valid-time queries are supported. The standard includes clauses for defining "system-versioned tables" (essentially transaction-time tables) with transaction-time current primary and foreign keys and supporting transaction-time current insertions, deletions, and updates as well as transaction-time current