Databases Reference
In-Depth Information
The standard implementation of event time, as we mentioned
earlier, is the data mart and the fact/dimension, star or snow-
flake structures that it uses.
State Temporal Data
Event data, as we have seen, is not the best way of tracking
changes to non-metric relationships. It is also not ideal for man-
aging changes to non-metric properties of persistent objects,
such as customer names or bill of material hierarchies. Who
ever heard of a data mart with customers or bill of material
hierarchies as the
fact
tables? For such relationships and such
objects, state-based history is the preferred option. One reason
is that, for persistent objects, we are usually more interested in
what state they are in at a given point in time than in what
changes they have undergone. If we want to know about
changes to the status of an insurance policy, for example, we
can always reconstruct a history of those changes from the
series of states of the policy. With balances, and their rapidly
changing metrics, on the other hand, we generally are at least
as interested in how they changed over time as we are in what
statetheyarecurrentlyin.
So we conclude that, except for keeping track of metric pro-
perties of relationships, the best queryable method of managing
temporal data about persistent objects is to keep track of the
succession of states through which the objects pass. When man-
aging time using state data, what we record are not transactions,
but rather the
results
of transactions, the rows resulting from
inserts and (logical) deletes, and the rows representing both a
before- and an after-image of every update.
State data describes those things that can have states,
which means those things that can change over time. An
event, like a withdrawal from a bank account, as we have
already pointed out, can't change. Events don't do that. But
the customer who owns that account can change. The branch
the account is with can change. Balances can also change over
time, but as we have just pointed out, it is usually more effi-
cient to keep track of balances by means of periodic snapshots
of beginning balances, and then an accumulation of all the
transactions from that point forward.
But from a logical point of view, event data and state data are
interchangeable. No temporal information is preserved with one
method that cannot be preserved with the other. We have these
two methods simply because an event data approach is prefera-
ble for describing metric-based relationships, while a state data
