Temporls datu bzes sistmas veidoana

1

Temporls datu bzes pirmskumi

Richard Snodgrass proposed in 1992 that temporal extensions to SQL be developed by the temporal database community. In response to this proposal, a committee was formed to design extensions to the 1992 edition of the SQL standard (ANSI X3.135.-1992 and ISO/IEC 9075:1992)

Those extensions, known as TSQL2, were developed during 1993 by this committee.

In late 1993, Snodgrass presented this work to the group responsible for the American National Standard for Database Language SQL, ANSI Technical Committee X3H2 (now known as NCITS H2). The preliminary language specification appeared in the March 1994 ACM SIGMOD Record.

Based on responses to that specification, changes were made to the language, and the definitive version of the TSQL2 Language Specification was published in September, 1994.

An attempt was made to incorporate parts of TSQL2 into the new SQL standard SQL:1999, called SQL3.

Parts of TSQL2 were included in a new substandard of SQL3, ISO/IEC 9075-7, called SQL/Temporal. The TSQL2 approach was heavily criticized by Chris Date and Hugh Darwen. The ISO project responsible for temporal support was canceled near the end of 2001.

As of December 2011, ISO/IEC 9075, Database Language SQL:2011 Part 2: SQL/Foundation included clauses in table definitions to define:

1) "application-time period tables" (valid time tables);

2) "system-versioned tables" (transaction time tables);

3) "system-versioned application-time period tables" (bitemporal tables). A substantive difference between the TSQL2 proposal and what was adopted in SQL:2011 is that there are no hidden columns in the SQL:2011 treatment, nor does it have a new data type for intervals; instead two date or timestamp columns can be bound together using a PERIOD FOR declaration. Another difference is replacement of the controversial (prefix) statement modifiers from TSQL2 with a set of temporal predicates.

Richard Thomas Snodgrass temporls datu bzes "tvs"

Richard Thomas Snodgrass (1955) is an American computer scientist and writer, currently employed as a professor at the University of Arizona. He is best known for his work on temporal databases, query language design, query optimization and evaluation, storage structures, database design and ergalics (the science of computing).

Snodgrass and his doctoral student originated the concept of valid time and transaction time. As of December 2011, ISO/IEC 9075, Database Language SQL:2011 Part 2: SQL/Foundation included clauses in table definitions to define "application-time period tables" (valid-time tables) and "system-versioned tables" (transaction-time tables).

TSQL2, a temporal extension to the SQL-92 language standard, was designed by the TSQL2 committee, which was formed in July, 1993. Snodgrass chaired the TSQL2 language design committee.[12] The committee produced a preliminary language specification the following January, which appeared in the March 1994 ACM SIGMOD Record.

Various members of the temporal database research community have worked to transfer some of the constructs and insights of TSQL2 into SQL3, termed SQL/Temporal. Snodgrass initiated SQL/Temporal part of the SQL3 draft standard. SQL/Temporal has been partially implemented in Oracle, Teradata version 14, and IBM DB2 10.

Snodgrass along with Christian Jensen co-chairs TimeCenter, an international center for the support of temporal database applications on traditional and emerging DBMS technologies. The center has published more than 90 articles since 1997, many of which have been accepted in leading computer science journals.

The scope of the TSQL (temporal SQL) language[footnoteRef:1] [1: Richard Snodgrass. TSQL: A Design Approach, 1992.]

1. TSQL is to be a relational query language.TSQL ir jbt relciju vaicjumu valodai.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.TSQL valodai ir jbut atbilstoai eksistjoiem SQL standartiem.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.TSQL valodai nedrkst bt specils standarts. 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. TSQL nebs objektorientta vaicjumu valoda.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 ir jbt viegli izprotamai un lietojamai. 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. Valod var tikt izmantotas formlas semantikas.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. Valodai ir jbt atbilstoai algebrai.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. TSQL ir jbt valodas projektam (ne fizisks realizcijas projektam).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 reflex 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 un temporl SQL datu izganas vaicjumu realizana

SQL vaicjums Relciju algebras darbbu secba . . .

SELECT ...

FROM ...

WHERE ...

...

Temporls SQL vaicjums Temporls algebras darbbu secba . . .

SELECT ...

FROM ...

WHILE ...

VALID(A) ...

...

Temporls vaicjumu valodas (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:2] called SQL3/temporal. [2: 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 and nonsequenced queries. Finally, the standard supports "system-versioned application-time period tables" (a mouthful, essentially bitemporal tables) and supporting temporal queries and modifications of combinations of the valid-time and transaction-time variants just listed for uni-temporal tables.

Implementation in Oracle

Oracle 9i, released in 2001, included support for transaction time. Its flashback queries allow the application to access prior transaction-time states of their database; they are transaction timeslice queries. Database modifications and conventional queries are temporally upward compatible.

Oracle 10g, released in 2006, extended flashback queries to retrieve all the versions of a row between two transaction times (a key-transaction-time-range query) and allowed tables and databases to be rolled back to a previous transaction time, discarding all changes after that time. The Oracle 10g Workspace Manager includes the period data type, valid-time support, transaction-time support, support for bitemporal tables, and support for sequenced primary keys, sequenced uniqueness, sequenced referential integrity, and sequenced selection and projection, in a manner quite similar to that proposed in SQL/Temporal.

These facilities permit tracing of actions on data as well as the ability to perform database forensics, as elaborated in the book "Oracle Forensics: Oracle Security Best Practices", by Paul M. Wright.

Oracle 11g, released in 2007, does not rely on transient storage like the undo segments. Rather, it records changes in the Flashback Recovery Area. Validtime queries were also enhanced; see Workspace Manager Valid Time Support. [Oracle documentation]

Oracle 12c, released in 2013, continues to support transaction time via the Workspace Manager, implemented as a PL/SQL package, while also supporting the (multi-)temporal features introduced in SQL:2011. (It seems that the valid-time support of prior versions of Workspace Manager has been removed, in favor of the SQL:2011 approach, though the enable_at_valid_time() procedure can specifiy various options for the visibility of table data.) The valid-time aspect (termed "temporal validity") of Oracle 12c is illustrated in an article and a tutorial. A blog post touches on transaction time implemented with the Flashback Data Archive, valid time implemented with temporal validity, and a third dimension called "decision time" also implemented with temporal validity. That blog post cautions that "The support for temporal data management in Oracle 12c is based on sound concepts, but the implementation is currently incomplete. I miss mainly a temporal DML API, temporal integrity constraints, temporal joins and temporal aggregations."

Implementation in Teradata

Teradata Database 13.10, released October 2010, introduced the period data type, valid-time support, transaction-time support, timeslices, temporal upward compatibility, sequenced primary key and temporal referential integrity constraints, nonsequenced queries, and sequenced projection and selection, in a manner almost identical to that proposed in SQL/Temporal.

Teradata Database 14, released February 29, 2012, adds capabilities to create a global picture of an organization's business at any point in time.

Implementation in IBM DB2

IBM DB2 10 for z/OS, released in October 2010 for z/OS and in April 2012 for Linux, Unix, and Windows, includes the period data type, valid-time support (termed business time), transaction-time support (termed system time), timeslices, temporal upward compatibility, sequenced primary keys, and sequenced projection and selection, in a manner identical to that in SQL:2011. Here is a tutorial on temporal tables in DB2.

Implementation in Microsoft SQLServer

Microsoft SQLServer 2016 provides support for a transaction-time backing table recording the history of a designated table, termed a "system-versioned temporal table".

Implementation in SAP HANA

SAP HANA runs on SAP In-Memory Computing Engine, which provides support for History Tables. Such tables provide support for session level and statement level time travel, effectively a transaction-time slice.

Implementation in MarkLogic Server

MarkLogic's MarkLogic Server product stores XML documents as a transaction-time database and supports transaction timeslice queries in XQuery (termed "point-in-time queries"), almost identically to that proposed in SQL/Temporal and applied to XQuery in XQuery.

Other Products Providing Temporal Support

Stratio released in August 2015 a new version of their open source Lucene index plugin for Apache Cassandra. "One of its features is to index bitemporal data using the 4-R index approach (Bliujute, R. et al.) over four Lucene's date range prefix trees. Each Cassandra node indexes its own local data, allowing to efficiently manage large amounts of bitemporal data spread over hundreds of nodes. It can also be combined with MapReduce frameworks such as Spark and Hadoop to perform massive computations." This brings valid time and transaction time as well as valid-time+transaction-time slices into Big Data.

Tom Johnston and Randy Weis have written a book entitled "Managing Time in Relational Databases" (Morgan Kaufmann) in which they present a novel approach called asserted versioning (also described on the book's web page). In this approach, bitemporal requirements are expressed separately and declaratively, in metadata tables.

Tom Johnston has written a book entitled "Bitemporal Data: Theory and Practice" (Morgan Kaufmann) proposing three temporal dimensions: state time (i.e., valid time), inscription time (i.e., transaction time), and speech act time (originally called assertion time in his previous book).

Asserted Versioning, LLC has developed a set of macros in ERWin that provide support for asserted versioning, included deferred assertions. These macros also provide full temporal upward compatibility and encapsulate the temporal complexity of primary key and foreign keys and of modifications (those not having complex predicates involving other temporal tables) over bitemporal tables (valid and transaction time). One-table updates (without a where clause) are allowed, with sequenced primary key and referential integrity constraints maintained across such updates. Non-sequenced queries are supported by making the begin and end dates explicit. One-table sequenced updates are also supported. Sequenced queries are not yet supported, nor are sequenced updates that reference other tables; those have to be mapped by the user into non-sequenced statements.

IBM's DataPropagator can use data replication of a DB2 log to create both before and after images of every row modification to create a transaction-time database that can be later queried.

LogExplorer from Lumigent provides an analysis tool for Microsoft SQLServer logs, to allow one to view how rows change over time (a nonsequenced transaction-time query) and then to selectively back out and replay changes, on both relational data and the schema (it effectively treats the schema as a transaction-versioned schema).

TimeDB is a Java API and uses JDBC to run as a frontend for Oracle. Temporal statements (queries, updates, and assertions) are compiled into (sequences of) SQL-92 statements which are executed by the backend. TmeDB provides upward compatibility, temporal upward compatibility, and bitemporal support (valid time and transaction time).

aTempo's Time Navigator is a data replication tool for DB2, Oracle, Microsoft SQL Server and Sybase that extracts information from a database to build a slice repository, thereby enabling image-based restoration of a past slice; these are transaction time-slice queries.

The PolarLake Data Management Platform supports bitemporal data in financial applications, as announced on June 9, 2011. Commenting on the release Warren Buckley, founder and CTO of PolarLake said, The Investment Banking and Asset Management communities are facing new levels of transparency requirements from Regulators when it comes to Financial Data. Regulators will be keen to know what you knew and when you knew it about particular Data Entities. They will also want to know when your view of that Data Entity changed over time, with detailed history of the changes.

Temporl vaicjumu valoda TSQL

SELECT ...

FROM ...

WHERE ...

WHEN {BEFORE | AFTER | DURING (laik) | EQUIVALENT | ADJACENT (blakus) | OVERLAP (daji sakrt) | FOLLOWS (seko) | PRECEDES (ir priek) }

Temporl vaicjumu valoda TempSQL

SELECT ...

WHILE (laika izteiksme, noteikums)

FROM ...

WHERE ...

GROUP BY ...

HAVING ...

DURING (laika izteiksme, noteikums)

SELECT a.Uzvards, b.Laika_intervals

WHILE A.Uzvards = B.Uzvards

FROM Darbinieki A, Projekti B

WHERE B.Proj_nos = '1. projekts';

Temporlie dati un SQL3 standarts

SQL3 adds the PERIOD( ) constructor. An SQL data type constructor specifies a new type constructed out of a specified type. Examples are SQL sets, multisets (i.e., with duplicates), and lists (i.e., with ordering). In the case of the period type constructor, you can specify period data types of the SQL datetime data types as well as of exact numerics with a scale of 0 (i.e., integers).

Hence, the following period data types are available:

PERIOD(DATE)

PERIOD(TIME) and PERIOD(TIME WITH TIME ZONE)

PERIOD(TIMESTAMP) and PERIOD(TIMESTAMP WITH TIME ZONE)

PERIOD(INT) and PERIOD(INTEGER)

PERIOD(SMALLINT)

PERIOD(NUMERIC)

PERIOD(DECIMAL)

Predicates:

p equals q p = q

p before q p PRECEDES q

p before1 q p SUCCEEDS q

p meets q END(p) = BEGIN(q)

p meets1 q END(q) = BEGIN(p)

p overlaps q BEGIN(p) < BEGIN(q) AND BEGIN(q) < END(p)

p overlaps1 q BEGIN(q) < BEGIN(p) AND BEGIN(p) < END(q)

p during q BEGIN(q) < BEGIN(p) AND END(p) < END(q)

p during1 q BEGIN(p) < BEGIN(q) AND END(q) < END(p)

p starts q BEGIN(p) = BEGIN(q) AND END(p) < END(q)

p starts1 q2 BEGIN(p) = BEGIN(q) AND END(q) < END(p)

p nishes q BEGIN(q) < BEGIN(p) AND END(p) = END(q)

p nishes1 q BEGIN(p) < BEGIN(q) AND END(p) = END(q)

p OVERLAPS q p OVERLAPS q

p IS NULL p IS NULL

Datetime Constructors:

beginning(p) BEGIN(p)

previous(p) PRIOR(BEGIN(p))

last(p) LAST(p)

ending(p) END(p)

Interval Constructors:

duration(p) INTERVAL(p), INTERVAL(p AS qual )

extract time zone(p) CAST(EXTRACT(TIMEZONE HOUR

FROM BEGIN(p)) AS HOUR) +

CAST(EXTRACT(TIMEZONE MINUTE

FROM BEGIN(p)) AS MINUTE)

Period Constructors:

p + i PERIOD[BEGIN(p) + i, END(p) + i)

i + p PERIOD[BEGIN(p) + i, END(p) + i)

p - i PERIOD[BEGIN(p) - i, END(p) - i)

p extend q not possible

p \ q p P INTERSECT q

p - q p P EXCEPT q

p [ q p P UNION q

p AT TIME ZONE i PERIOD[BEGIN(p) AT TIME ZONE i,

END(p) AT TIME ZONE i)

p AT LOCAL PERIOD[BEGIN(p) AT LOCAL, END(p) AT LOCAL)

Other Operators:

CAST(a AS PERIOD) PERIOD[a, a]

CAST(p AS CHAR) CAST(p AS CHAR)

Temporls vaicjumu valodas (temporls SQL valodas)

1. TSQL2 ir paplainjums standartam SQL-92 valodai, kas tika izveidots 1993. gad. Neskatoties uz to, ka kop valodas izveidoanas jau ir pagjis vairk par 15 gadiem, msdiens TSQL2 valoda ldz pat m brdim ir populra.

Valoda satur vairkas funkcijas darbam ar laiku un datumiem, tomr izstrdtji cents minimizt datu modeli un implementt to t, lai t saturtu tikai paas vienkrkas (pamata) opercijas.

3. TOSQL.

4. HSQL.

5. IXSQL.

6. CHRONOSQL.

8. ATSQL.

9. TOLAP ir SQL valodas paplainjums, kas pievieno temporlu datu bu atbalstu vairku dimensiju analtiskiem vaicjumiem OLAP.

10. TQuel ir paplainjums Quel valodai. T atbalsta gan relo, gan ar transakciju laiku. Atbalsta ar agregcijas, datu evolcijas shmas un rela laika nenoteiktbas jdzienu, kad droi nav zinms, kds laiks bija kda noteikta notikuma laik.

11. T4SQL atbalsta vairkas opercijas, kas tika defintas k nepiecieamks temporlo vaicjumu valod. Valoda atbalsta vairkas temporlas datu dimensijas, neskaitot rela laika un transakciju laiku, valoda atbalsta ar divus papildus jdzienus pieejambas laiku un notikumu laiku.

12. TXQuery ir paplainjums XQuery valodai, kura ir balstta uz XML valodu. SQL-2006 standart tika izstrdti mehnismi, kuri va izpildt XQuery valodas vaicjumus SQL vaicjumos.

http://www.inf.unibz.it/dis/teaching/TSDB/ln/tsdb05_temporal-SQL.pdf