Subject: Temporal-database concepts and terms

From: "Christian S. Jensen" <[email-masked]>
Date: Sat, 24 Oct 92 19:14:20 +0100

******************************************************************
  **  Call for proposals of temporal-database concepts and terms  **
  ******************************************************************

Dear colleague,
 
During the preparation of a forthcoming book on temporal databases, a
glossary on temporal database concepts and terms was developed. We are
now initiating the process of developing a next generation of the
glossary and invite you to contribute with proposed concepts and
terms.

As you may be aware, the first workshop on temporal databases, with
the title "International Workshop on an Infrastructure for Temporal
Databases," is scheduled to be held in Arlington, TX, June 14-16, 1993.

The objective of this workshop is to define and establish a common
infrastructure of temporal databases and to develop a consensus base
document that will provide a foundation for implementation and
standardization as well as for further research.

Independently, the first book on temporal databases (Temporal
Databases: Theory, Design, and Implementation, edited by A. Tansel, J.
Clifford, S. Gadia, S. Jajodia, A. Segev, and R. Snodgrass,
Benjamin/Cummings Publishers, Database Systems and Applications
Series) is expected to be available in early 1993.

A glossary on temporal-database concepts is included as part of this
book, and each contributor to the book has used the terms defined in
the glossary. The glossary also appears in the September 1992 issue of
the SIGMOD Record.

Maintaining a precise, well-defined, and intuitive technical language
is important to the scientific community. The glossary meets a need
for creating a higher degree of consensus on the definition and naming
of central concepts from within the field. The use of inconsistent
terminology adversely affects the accessibility of the literature and
hinders progress.

The glossary consists of a list of entries as illustrated next.

\subsection{<the chosen name of the concept>}

\entry{Definition}         
		 <the definition of the concept>

\entry{Alternative Names}   
		<names that were considered and subsequently rejected
		 in favor of the chosen name> 

\entry{Discussion}
		<reasons for the particular choice of name (and
		 concept) and reasons for not selecting considered
		 names (and concepts)> 

We encourage you to propose glossary entries. Proposals should be
submitted to the mailing list [email-masked], and we request the
submission of complete glossary entries only.

The current version of the glossary is available by anonymous ftp from
cs.arizona.edu, in the "tsql" directory, in the file "glossary.tex".
In addition, DVI and Postscript versions are available. Documents
indicating the current status may also be found in the "tsql"
directory.

Feel free to direct questions to "[email-masked]".

Best regards,

Christian S. Jensen
Aalborg University

---

From: [email-masked] (John Roddick)
Date: 31 Oct 1992 09:36:46 +0930

The following two entries are prompted by an apparent confusion in the
literature regarding the two terms Schema Evolution and Schema Versioning. 
In many papers they are used interchangeably which I believe is wrong as
the definitions demonstrate.

\subsection{Schema Evolution}

\entry{Definition}         
A database supporting schema evolution permits the modification of the
database schema without loss of extant data.

\entry{Alternative Names}   
Schema Versioning is a separate but allied concept which allow user
definition of schema changes - see definition.  

Some thought was also given to using the terms 'data evolution' and 'schema
evolution' but these were rejected due to the latter's usage in the
literature.

\entry{Discussion}
i.   In it's simplest sense, schema evolution does not imply full
historical support for the schema; only the ability to change the schema
definition without loss of data.  In practice, retention of past
definitions will probably be appropriate.  In contrast, Schema Versioning,
even in its simplest form, requires that a history of changes be maintained
to enable the retention of past schema definitions.

ii.  The significant difference between evolution and versioning is the
ability for users to identify quiet points in the definition and 'label'
the definition in force at that time for later reference.  Schema Evolution
does not require the ability to version data except in so far as each
changed schema can be considered a new version.

iii. Schema changes will not necessarily result in a new version. 
Typically schema changes will be of a finer grain than the definable
versions.

iv.  Versions will tend to be labelled by some user-defined method whereas
schema evolution changes are referred to more often by the (transaction)
time of change.

\subsection{Schema Versioning}

\entry{Definition}         
Schema Versioning is accommodated when a database system allows the viewing
of all data, both retrospectively and prospectively, through user definable
version interfaces.

\entry{Alternative Names}   
Schema Evolution is an allied concept.

\entry{Discussion}
See discussion under Schema Evolution
John.
-------------------------------------------+--------------------------
John Roddick                               | Ph.  (08) 302 3643
School of Computer and Information Science | Int. +61 8 302 3463
University of South Australia              | Fax  (08) 302 3381
The Levels                                 | Int. +61 8 302 3381
SOUTH AUSTRALIA     5095                   | Net. [email-masked]