Databases Reference
In-Depth Information
takes effect either in the past or in the future, basic temporal
updates to asserted version tables also take place in the present.
Just as an update to a conventional table remains in effect until
further notice, rather than for a predetermined length of time, a
basic temporal update to an asserted version table will be to a
current episode that is open, i.e. whose latest version has an
effective end date of 12/31/9999, and it will always leave that
episode open after the transaction is complete.
Basic temporal transactions are the Asserted Versioning equiva-
lent of conventional transactions. No bi-temporal parameters are
specified on them, and so their content is identical to that of their
corresponding conventional transactions. They contain exactly the
same information that is present on conventional transactions—
nothing more and nothing less. Butiftemporaltransactionsareto
take effect some time in the future, or some time in the past, then
those non-current effective time periods must be explicitly specified
on those transactions. And if we wish to update the database with
deferred assertions, the assertion begin date must also be specified.
In these cases, the temporal transactions are no longer basic; they
explicitly state the bi-temporal parameters they want.
Corresponding to each appearance of a managed object in a
conventional table, i.e. to each period of time starting when a
row for an object is inserted and ending if and when it is deleted,
there would be an episode of that object if that table were instead
an asserted version table. It follows that there can be any number
of episodes of the same object present at the same time in an
asserted version table, although no more than one of them, of
course, can be current. Each episode is a managed object,
representing an object as it exists over a continuous period of
time. Each version of that episode is also a managed object,
representing an object as it exists over one continuous period of
time that is included within the episode's period of time.
In
Figure 7.1
, eight versions, grouped into three episodes, are
shown along a timeline. The first two episodes are closed, as all
but the latest episode of an object must be. The last one is open.
All are managed objects representing one object, policy P861.
Episode A
Episode B
Episode C
1
2
3
7
8
4
5
6
Jan
2010
Jan
2011
Jan
2012
Jan
2013
Jan
2014
Figure 7.1 Eight Versions and Three Episodes of Policy P861.
