Databases Reference
In-Depth Information
already in use, the AVF rejects the transaction. And if it
does not find a match, but the
oid
on the transaction does
match an
oid
already in use, the AVF rejects the transac-
tion. The reason behind all this logic is that when both
an
oid
and a reliable business key are present, any conflict
makes the transaction invalid; and when a temporal
update has an
oid
and business key that do agree, but that
do not match anything on the target table, the temporal
update fails the match, and is rejected.
(viii) Oid present, business key present, business key is not reli-
able. In this case, the AVF attempts to match on the
oid
.Ifit
does, it accepts the transaction, and otherwise rejects it.
Note that if the business key is a new one, then when the
transaction is applied, it assigns a new business key to an
object, in clock ticks already occupied by that object.
The Temporal Update Transaction: Semantics
In a conventional table, if an object is represented and the user
wishes to modify the row doing the representing, she issues an
update transaction which overwrites the data to be changed with
the data that changes it. The update transaction expresses not
only her intentions, but also her beliefs and assumptions. It
expresses her intention to update a representation of an object,
but it also expresses her belief that such a representation already
exists. If she is mistaken in her belief, her transaction is rejected,
which is precisely what she would expect and want to happen.
In an asserted version table, the question is not whether or not
the object is already represented, but rather whether or not the
object is already represented, in current assertion time, within
the effective-time target span indicated on the transaction. If the
user submits a temporal update transaction, she also expresses
both intention and belief. Her intention is to modify a currently
asserted representation of an object in every clock tick within
the target effective timespan. Her belief is that such a representa-
tion already exists in at least one clock tick within that target span.
If she is mistaken in her belief, her transaction is rejected, which
is precisely what she would expect and want to happen.
The Temporal Update Transaction: Mechanics
Here are some examples that will illustrate how this interpre-
tation of the target timespans on temporal update transactions
works. Consider a temporal update with a [Nov 2011 - 12/31/
9999]
target
timespan. This update affects all versions in
