Databases Reference
In-Depth Information
The term
business key
usually refers to a set of one or more
columns of data which can be used as unique identifiers
for the objects they represent, and which contain business-
meaningful data only, and no surrogate-valued columns. Some-
times business keys are used as primary keys. But sometimes,
surrogate-valued columns are used as primary keys instead of
business keys.
Asserted Versioning uses the term “business key” to refer to
the one or more columns of an asserted version table which
are the primary key of the corresponding entity in the logical
data model, or of the corresponding conventional table which
has been converted to an asserted version table. Sometimes
these columns contain business-meaningful data, but some-
times they do not. The role of business keys in asserted version
tables is to identify the object represented by each row in the
same way that object would be identified, or was identified, in
a conventional table.
Most of the time, business keys are reliable. In other words,
most of the time, each business key value is a unique identifier
for one and only one object. So in a non-temporal table, it would
be possible to define a unique index on the business key,
whether or not it is used as the primary key.
Unfortunately, it is sometimes necessary to manage tables
whose business keys are not reliable. If the business keys for a
table are not completely reliable, we cannot be sure that each
business key value represents one and only one object. We may
sometimes have to manage transactions, and rows in tables, that
have missing or incomplete business keys.
In Chapter 5, we discussed how business keys are used when
matching transactions to non-temporal tables, and how they are
used when matching transactions to asserted version tables. But
throughout that discussion, we assumed that the business keys
for those tables were reliable. When they are not, it is more diffi-
cult to match transactions to a target table, especially when that
target table is bi-temporal. In the next chapter, we will discuss
the match logic that must be used when temporal inserts,
updates and deletes are applied both to asserted version tables
with reliable business keys, and also to asserted version tables
with unreliable business keys.
Temporal Foreign Key Metadata
The temporal foreign key metadata table contains one entry
for every temporal foreign key. Recall that temporal foreign keys,
like conventional foreign keys, express an existence dependency,
one in which the existence of the child object represented by the
