Databases Reference
In-Depth Information
for assertion time, and the other the granularity for effective
time. Granularity, of course, is the size of the clock tick.
As we have said, the clock ticks being used in examples in this
book are one-month clock ticks, for both assertion time and effec-
tive time. But in our consulting experience, companies often use
one granularity for versioning, and a different granularity to record
row creation dates. Versioning, of course, is the best practice
approximation to Asserted Versioning's effective time, and row
creation dates are an approximation to Asserted Versioning's
assertion time. And in our own prior implementations of bi-
temporal data management, we have used dates for effective
time and microsecond timestamps for assertion time.
By using the same granularity for all assertion times in the
same database, and the same granularity for all effective times,
it is easy to determine the Allen relationship between any two
time periods. So suppose that the same granularity is
not
used,
and that there are two time periods which start at the same time,
one of which is delimited by dates and the other by timestamps.
The values, each of which designate the same point in time, are
not identical. But if the same granularity is used, the EQUALS
operator will tell us whether or not those time periods begin at
the same time.
Of particular importance is whether or not two time periods
have a gap in time between them or not. By using the same gran-
ularity for all asserted version tables in the same database, it is
easy to spot two versions of the same object that are contiguous
in either assertion or in effective time. Because of the closed-
open convention, two time periods [meet] (are contiguous) if
and only if the end point in time of one has the same value as
the begin point in time of the other. This is a very important
temporal relationship because two versions of the same object
that effective-time [meet] belong to the same episode, whereas
two versions that do not [meet] belong to different episodes.
We note that no granularity mismatch issues should arise
when assertion time and effective time are based on different
granularities. This is because there seem to be no semantically
meaningful queries that would compare an assertion time
period or point in time to an effective time period or point in
time.
One final point. We recommend that assertion time granular-
ity be set to the level of the
atomic
clock tick for the DBMS, i.e.
the smallest clock tick that could occur between two successive
modifications to the database. The reason is that if a non-atomic
clock tick is used for assertion time, then it would be physically
possible to place two or more asserted version rows, for the same
