Databases Reference
In-Depth Information
7
THE BASIC SCENARIO
CONTENTS
The Representation of Objects in Time Periods
Occupied and Represented
144
Basic Temporal Transactions: The Mental Model
144
Maintaining Asserted Version Tables: The Basic Scenario
A Temporal Insert Transaction
145
A Temporal Update Transaction
147
A Second Temporal Update Transaction
A Temporal Delete Transaction
Glossary References
When representing an object in a non-temporal table, the
most basic things we can do are to insert a row representing
the object, update the row as changes happen to the object,
and delete the row if and when the object ceases to exist, or
ceases to be of interest to us. Almost always, we don't know in
advance if or when any of these things will happen: if or when
a row will be inserted; if or when the next update will occur; if
or when the row will be deleted.
These rows represent objects of interest to us. They are not
the objects themselves. A row in a Policy table is not a policy;
it is data which represents the policy in our database. Through
the DBMS, for the most part mediated by application software,
we manage these rows. We insert them, update them and some-
times delete them. We put them in result sets in response to
queries. We put them on reports. By managing them, we are able
to manage the policies which they represent. For this reason, we
will call these rows
managed objects
.
Sometimes it is harmless enough to finesse this distinction, and
speak of the DBMS, for example, updating policies. But what the
DBMS updates, of course, are rows representing policies.
It updates managed objects, not the objects they represent.
As we enter into a series of chapters whichwill describe our method
of temporal data management in great detail, we will sometimes
