Databases Reference
In-Depth Information
As shown in
Figure 12.6
, the Policy table now contains only
three deferred assertions that have not been overridden. One is
P861(r6), whose withdrawal has been deferred until January
2090. The other two are P861(r9 & r10). They constitute a single
deferred assertion group
, that group being defined by the future
assertion date that they share.
A deferred assertion group is another managed object
introduced by Asserted Versioning but not supported by rela-
tional theory, relational technology, other temporal models, or
ongoing research in the field. It is a designated collection of
one or more rows which consist of assertions in the same future
assertion period of time, and, transitively, any earlier non-past
assertions that are locked because of them. These deferred asser-
tion groups can contain assertions for different episodes of the
same object, and for different objects in the same or in different
tables.
Besides its own currently asserted production data, a pro-
duction table may contain any number of deferred assertion
groups. These deferred assertion groups are the
internalization
of inflow pipeline datasets. They are the internalization of
collections of transactions which are not currently production
data.
Usually, these collections are called batch transaction datasets.
Typically, there may be any number of batch transaction datasets
in which
pending
transactions are accumulated as they are
acquired or created. One by one, on a scheduled or as-needed
basis, these batch datasets are processed against their target
databases, and production tables are updated. But with asserted
version tables as the target production tables, these batch datasets
aren't necessary. Transactions scheduled to be processed on a
later date can be submitted immediately, with that later date as
the assertion begin date.
Let us assume that the business has now reviewed the
deferred assertion group and approved the assertions in it to
become current as soon as possible. It is now March 2013, and
so the next opportunity to update the database is April 2013.
The AVF moves deferred assertions backwards in time with a
special temporal update transaction. This transaction takes
deferred assertions in the far future and moves them into the
near future.
But before we move P861(r9 & r10) backwards in assert-
ion time, consider P861(r6). P861(r9 & r10) were created as
assertion-time contiguous
with P861(r8), which itself was created
as assertion-time contiguous with P861(r6). The idea was that,
on January 2090, when P861(r6) ceased being asserted, it would
