Databases Reference
In-Depth Information
A foreign key is a column in a relational table whose job is to
relate rows to other rows.
5
If the foreign key column is declared to
the DBMS to be nullable, then any row in that table may or may
not contain a value in its instance of that column. But if it does con-
tain a value, that valuemust match the value of the primary key of a
row in the table declared as the target table for that foreign key. For
non-nullable foreign keys, of course,
every
row in the source table
must contain a valid value in its foreign key column.
In addition, once the FK relationship is declared to the
DBMS, the DBMS is able to guarantee that the two managed
objects—the child row and the parent row—accurately reflect
the existence dependency between the objects they represent.
It does so by enforcing the constraint expressed in the declara-
tion, the constraint that if the child row's FK points to a parent
row, that parent row must have existed in its table at the time
the child row was added to its table, and must continue to exist
in the parent table for as long as the child row exists in its table
and continues to point to that same parent.
This is a somewhat elaborate way of describing something
that most of us already understand quite well, and that few of
us may think is worth describing quite so carefully—that foreign
keys relate child rows to parent rows and that, in doing so, they
reflect a relationship that exists in the real world. We have gone
to this length in order to be very clear about both the semantics
and the mechanics of foreign keys—semantics described in our
talk about objects, and mechanics in our talk about managed
objects—and to place the descriptions at a level of generality
where the semantics and mechanics of TFKs can be seen as
analogous to those of the more familiar FKs. So if we use an
“X/Y” notation in which the “X” term is part of the referential
integrity description and the “Y” term is part of the temporal ref-
erential integrity description, we have a description which makes
it clear that temporal referential integrity really is temporalized
referential integrity, that TRI is RI as it applies to temporal data.
That description is given in the following paragraph.
Once the FK/TFK relationship is declared to the DBMS/AVF,
the DBMS/AVF is able to guarantee that the two managed
objects—the child row/version and the parent row/episode—
accurately reflect the existence dependency between the objects
they represent. Each does so by enforcing the constraint
expressed in the declaration, the constraint that if the FK/TFK in
the child row/version points to a parent row/episode, that parent
5
We will assume that all primary and foreign keys consist of single columns, since the
complications that arise with multi-column keys are irrelevant to this discussion.
