Determinants and identiﬁers
 ,QWURGXFWLRQ
This chapter introduces a simple formal rule which a table must obey if it is to be free of
redundancy. To apply the rule it is ﬁrst necessary to understand what is meant by the
terms determinant and identiﬁer.
 'HWHUPLQDQWV
Consider the attributes within a table type. If the enterprise rules are such that duplicate
values of attribute A are always associated with the same value of attribute B (within
any given occurrence of the table), then attribute A is a determinant of attribute B. In
the special case where duplicate values of A are not allowed within a table occurrence,
A is necessarily a determinant of B.
If A is a determinant of B, we will say that A determines B and B is determined by (or
is dependent on) A. The value of attribute B may be duplicated elsewhere in the table,
it may be a null, and it may be updated (if so, a new table occurrence is created in which
duplicate values of A must still be associated with a single, though now updated, value
of B). If a
1
and a
2
are non-duplicate values of A, they may be associated with the same,
or different values of B.
Less rigorously, we may say that A is a determinant of B if each value of A has
precisely one (possibly null) associated value of B. Although ambiguous (why?),
statements in this form will be used for the sake of conciseness in what follows.
Figure 6.1 shows some sample data for the table type:
Stock (partNo, partDescription, quantityInStock)
If we are told that each possible partNo value has precisely one associated
partDescription value (e.g. partNo P2 has just one description, nut), then we can say
that partNo is a determinant of partDescription. Similarly, if each possible partNo
Fig. 6.1 Stock table occurrence

Get Data Analysis for Database Design, 3rd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.