Databases Reference
In-Depth Information
We emphasize that the following history is not a history in any
strict sense. It is more like our reflections on changes in methods
of managing data which we have observed, as IT consultants, over
the last quarter-century. It is our attempt to look back on those
changes, and impose some order and structure on them. It does
not fall short of history, in a strict sense, in attempting to impose
order and structure. All historical narrative does that, no matter
how purely descriptive it claims to be. Rather, it falls short in its
reliance solely on personal reminiscence.
Excluding Time from Databases:
A Ubiquitous Paradigm
In one sense, temporal data has been accorded only second-
class status since the advent of computers and their use in man-
aging business data. Neither database management systems
(DBMSs) and the tables they manage, nor access methods and
the files they manage, provide explicit mechanisms and
structures to distinguish data about the past, present or future
of the things we keep track of. Instead, unless developer-designed
data structures and developer-written code is deployed, every
object is represented by one and only one row in a table. If the
row is there, the corresponding object is represented in our
databases; otherwise it is not. If something about a represented
object changes, the row is retrieved, updated and rewritten to
reflect that change.
This focus on current data is reflected in a basic paradigm
that has been used since we began managing data with com-
puters. The paradigm is that of one data structure to represent
a type of object or event, containing multiple other data
structures, each representing an instance of an object or event
of that type. Contained within the latter data structures are addi-
tional structures, each representing a property of the instance in
question, or a relationship it has to another instance of the same
type or (more usually) a different type.
This paradigm has manifested itself in such terminologies as
(i) files, records, fields and pointers; (ii) tables, rows, columns
and foreign keys; and (iii) classes, objects, slots and links. For
the remainder of this topic, we will use the table, row, column
and foreign key terminology, although the concepts of uni-
temporal and bi-temporal data management apply equally well
to data managed by directly invoking access methods, to data
managed with proprietary software, and to data managed with
object-oriented structures and transformations.
