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.