Letter from the Chief Editor
IEEE Data Engineering Bulletin
This special issue concerns databases that capture the evolution over time of the enterprise being modelled. In a very real sense, the first databases, those hieroglyphics describing the pharoali's inventory of grain scrawled with great effort on pyramid wails, already integrated time. In current terminology, these were tuple-timestamped, rollback databases (a common phrase describing the transaction time of rollback databases, "the past information is unalterable, as if written in stone,"
... inly applies here). The first historical database, Homer's Odyssey, was infinitely more malleable, changing in subtle ways with each retelling. While the three-dimensional view of an historical relation was introduced somewhat more recently (by Fred Brooks in his Harvard doctoral dissertation, 1956), temporal databases were not studied until the early 1970's, when Wiederhold and others included time support in their medical information systems. By the end of that decade, both the research and business communities were becoming comfortable with database theory and practice, respectively (!), and a plethora of extensions soon emerged: engineering DB's (CAD/CAM/CASE/CAE), geographic DB's, image DB's, knowledge DB's, object-oriented DB's, radiology and hospital DB's, spatial DB's, statistical DB's, and, as popularized in the scientific press by the significant Clifford and Warren 1983 TODS paper, historical DB's (to be fair, other, earlier articles set the stage for the ensuing surge of interest in time in databases). Mindful of the precedent set by the definition, formalization, then implementation of the relational model in the early 70's, and cognizant of the daunting philosophical, linguistic, and even physical difficulties with defining time, researchers focussed on formalizing, as carefully as possible, extensions or replacements for the relational model, algebra, and calculus. Healthy controversy developed almost immediately. Should the model incorporate objects? The standard relational model does not, but an argument can be made that object identity is crucial when time is modelled. Should the algebra be entirely "syn tactic", or should it require various integrity and normal form constraints, and hence be considered "semantic"? What aspect(s) of time should be modelled? llsoo Ahn and I have argued that both valid and transaction time should be supported by any database calling itself temporal. Should first normal form be considered a prerequisite, as in the standard model, or are non-first-normal-form proposes superior? Both approaches are evident in the papers in this special issue. Should tuples or attributes be time-stamped? These difficult, fundamental questions are debated in the literature, in the hallways at conferences, and even in referee reports. Attempts to address these questions have re sulted in, at last count, 11 algebras, 8 calculus-based query languages, and many data models. Over the last several years, the focus has started shifting towards implementation, with several prototype DBMS's in place, and movement, but not yet products, by several computer companies. This shift signals a maturing of the discipline; the bibliography in this issue provides another data point. The seven articles gathered in this special issue represent the current thinking of some of the most active participants in the area. Many of these papers reflect ideas in evolution. Consult the conference proceedings in 1989 and the journals in 1990 (and 1991 and ...) to see the approaches and concepts these papers engender. I expect that the debate will remain lively for quite some time,-with controversy yielding to consensus, and then replaced by nascent controversy concerning different issues. All that we know about conventional databases, which is substantial, must be reexamined when time is introduced. The learning curve is steeper this second go-around, but there is still much to do before we catch up. I would like to thank each of the authors for their contribution, and for meeting tight time and space constraints.