Talk:Temporal database

From Wikipedia, the free encyclopedia

The first sentence of the article entitled "Temporal database" starts like this:

"A temporal database is a database management system…"

This is nonsense. A database is what a database management system (DBMS) manages, not the DBMS itself.

But the whole article is really woeful, imo.

Why does a database, in order to be temporal, have to be managed using "a temporal version of structured query language [sic]", specifically? Is the author assuming that every database is accessed using SQL? Perish the thought!

Besides, where in the current technology do temporal versions of SQL exist? Nowhere at all, to the best of my belief. There was a brief attempt, in the mid-1990s, to add an extension to the SQL standard to support temporal data, but the attempt was abandoned partly because of a raging controversy that arose over the USA proposal based on TSQL2 and in any case because the SQL vendors were diverted by the pressing requirement at the time for "object/relational" support (the eventual take-up for which by the users appears to have been negligible!). Then, when O/R support was finally published in SQL:1999, the new presing requirement for XML support got in the way of any attempt to revive temporal support.

A similar comment applies to "the temporal aspects usually include". How can "usually" be justified, given the actual nonexistence of temporal databases, for lack of any technology to support them?

Now, the lack of technology is in stark contrast to the amount of research into the topic that has taken place in the academic world over the past quarter of a century or more. The article makes no mention of that research or its results. It doesn't even mention the severe problems that arise when one requires to record the changes in the truth of certain propositions over time, let alone the various solutions that researchers have proposed to those problems.

For example, the idea of simply adding "from" and "to" attributes to relations to represent "valid time" intervals has been pretty well universally rejected in favour of recording intervals as atomic values, such that a single interval-typed attribute replaces the naive from/to duo suggested in the article, and the justification for interval types is overwhelming when you really think about it. For a start, consider how many times you would have to write a constraint to the effect that no "from" value must be greater than the "to" value with which it is paired; with interval types, the constraint is built into the type definitions, there being no such thing as an interval that ends before it begins. Next, what about the interpretation of the interval bounds? Are the time points they represent in the interval or just out of it? With interval types the question can be finessed using the conventional notation whereby a square bracket denotes a cloised bound, an parenthesis an open one, such that [2:4], (1:4], [2:5) and (1:5) all denote the same interval (of integers).

And what about the importance of quantisation, recognised by most authorities in the temporal database field? For example, how is the duration of an interval represented by a from/to pair to be determined, unless the relevant unit of measure (scale) is known? Even if the so-called discrete (versus continuous) model of time for temporal database purposes is still controversial, surely it and some of the reasons for it should be mentioned, considering that most people intuitively think of time as being continuous?

As for "the Valid-To is filled with infinity (∞)", since when has infinity been a time? What is the duration of an interval that runs from the 1st of January, 2006, to infinity? What is the effect of infinity on all the other operators that can be invoked on time values? The author has dismissed perhaps one of the most difficult aspects of temporal databases--concerning "the moving point, now" at a single, cavalier-like stroke! It might be beyond the scope of the article to describe all the various approaches to that problem that have been advanced, but at the very least the fact shoud be mentioned that it is a big problem, surrounded by a certain amount of controversy.

I hesitate to attempt a replacement for this article myself, because I am a coauthor of a fairly recent book on the subject that advances one particular approach--what might be called the "pure relational" approach--that is much derided by some of those who do not hold the tenets of the relational model of data in such high regard as I do myself (including in particular advocates of the TSQL2 approach). Thus, my attempt might be seen as one-sided and possibly self-serving.

AndrewWarden 18:37, 22 February 2006 (UTC)

Please do replace the article, Mr Darwen. This is the principle on which Wikipedia works: if something's broken, fix it first and discuss it later. If no one complains, great. If someone improves your article, great. If someone reverts your replacement, he will have to explain himself. If you can't agree, refer it to a third party.
It might be that after all is done and said people can't still agree; one could always create an alternative article called 'Temporal relational databases' or something the like.
--
Leandro GFC Dutra 13:47, 7 April 2006 (UTC)


Actually, the article is more wrong than that. The model is completely wrong.

The entity classes should be:

PERSON - this describes the person throughout time. The only attribute in this example would be "Name" CITY (or simply GEOGRAPHIC AREA) - the place where a PERSON may live at any particular time. PERSON PLACEMENT this describes the fact that a person lived in a particular city. Attributes are "From date" and "To date". There is a many to one relationship asserting that each PERSON PLACEMENT must be of one PERSON in one CITY. That is, each PERSON may be located via one or more PERSON PLACEMENTS in a CITY, and each CITY may be the object of one or more PERSON PLACEMENTS of a PERSON.

Thus, PERSON and CITY represent what are (for purposes of this example) eternal things, and PERSON PLACEMENT describes the state of a PERSON's being in a CITY at a particular time.

Problem solved.

DaveHay 14:45(CST) 23 March, 2006

Please fix!
--
Leandro GFC Dutra 15:04, 19 April 2006 (UTC)


[edit] External links

This page is linked to by Fabian Pascal in http://www.dbdebunk.com/index.html in the section TO LAUGH OR CRY: 04/07/06 Wikipedia Talk: Temporal Database. --elwikipedista 01:52, 12 April 2006 (UTC)

[edit] Remarks section moved to this talk page

There was a small section titled "Remarks/Issues" which clearly belong on the talk page instead. The contents of that section (which I removed) were

* The temporal example could do with rewording for clarity.

-Dmeranda 18:23, 18 July 2006 (UTC)

The article has been significantly improved since I wrote that long criticism in February, 2006. That criticism should now be regarded as totally irrelevant but I'm not sure what should properly be done about it.

AndrewWarden 13:43, 27 May 2007 (UTC)