Databases Reference
In-Depth Information
(ii) No
oid
, no business key, business key is not reliable.In
this case, the AVF rejects the update, for the same reason
as for case (i).
(iii) No
oid
, business key present, business key is reliable.In
this case, the AVF looks for a match on the business key.
If it finds one, it assigns the
oid
of the matching row to
the transaction. Otherwise, it rejects the transaction. The
reason is that reliable business keys are unique identifiers
of objects, and that, because all temporal insert trans-
actions to tables with reliable business keys must have a
business key on the transaction, all existing rows for the
same object will contain that reliable business key. This
means that a temporal update with a non-matching reli-
able business key is just like a conventional update which
cannot match a primary key. It is a mistaken update.
(iv) No
oid
, business key present, business key is not reliable.
In this case, the AVF rejects the update. The reason is that if
the business key isn't reliable, it doesn't matter if it's there or
not, and so the AVF proceeds as though the business key
were not there. Note that if we did attempt a match on
the business key, and were successful, we might or might
not have the right
oid
to assign to the transaction. We can't
be sure because the AVF can't guarantee that an unreliable
business key value is not being used by two or more
oid
s.
If we use a match on a business key that may be associated
with several different objects, then unless we have an
oid
supplied by the transaction itself, we have no way of know-
ing which
oid
is the correct target of the transaction.
(v)
Oid
present, no business key, business key is reliable.In
this case, the AVF looks for a match on the
oid
. If it finds
one, it accepts the transaction. Otherwise, it rejects it.
The reason is obvious. Note that, unlike inserts, updates
to tables with reliable business keys are not required to
have the business key on the transaction.
(vi)
Oid
present, no business key, business key is not reliable.
In this case, the AVF looks for a match on the
oid
. If it finds
one, it accepts the transaction. Otherwise, it rejects it.
(vii)
Oid
present, business key present, business key is reli-
able. In this case, the AVF looks for a match on the busi-
ness key. If it finds a match, and the
oid
of the matching
row matches the
oid
on the transaction, the AVF accepts
the transaction. If it finds a match, but the
oid
of the
matching row does not match the
oid
on the transaction,
the AVF rejects the transaction. If it does not find a match,
and the
oid
on the transaction does not match any
oid
