Databases Reference
In-Depth Information
targettablemustbemadeonthebasisofabusiness key for the
object in question. If no match is found, a new surrogate key
value is generated, and is used for the new row the transaction
is about to create. If a match is found, then a row for the object
is already in the target table, and the insert transaction is
rejected.
In some implementations, surrogate keys are circulated out
of the target database back into the databases that are the
sources of the transactions. In that case, update and delete
transactions may already have a surrogate key when they show
up to be processed. If they do arrive with a surrogate key in
hand, then the search for a match is made with that surrogate
key, and is conducted with a business key only in the case of
an insert transaction. Otherwise, update and delete transactions
are matched to their target rows on the basis of business keys,
and are rejected if matching rows are not present.
Surrogate keys can be assigned in either a pre-processing step
or as part of the same process which submits transactions to the
DBMS. Surrogate keys may or may not be supplied on update
and delete transactions. But in terms of the semantics that have
to be carried out, these distinctions don't matter. Regardless of
how we design the process of assigning surrogate keys, the
important point is that it is not just a matter of requesting a
unique key value for an insert transaction.
Surrogate Keys, Business Keys and Asserted
Version Tables
We can now return to the question of where the P861 surrogate
key value on a temporal insert transaction, such as the one shown
in the next chapter, came from. Our brief review of surrogate key
match logic tells us that there must have been a match process
that used a business key. But because we are now considering a
temporal table and a temporal transaction, the match process is
not identical to the process we just described.
When the target table is a temporal table, in this case an
asserted version table, the question is not whether or not that
object is already represented in the table. The question is
whether or not the object is already represented in the table in
the time period specified on the transaction. For example, an
insert of policy P861, effective for all of 2010, will not be rejected
because the Policy table already shows that policy effective for
all of 2009. However, the actual use of surrogate keys with tem-
poral transactions is more complicated than this. It will be
discussed in detail in Chapter 9.
