Databases Reference

In-Depth Information

Chapter 10

J D s a n d 5 N F

( F o r m a l )

After great pain, a formal feeling comes

─Emily Dickinson

Just as Chapter 5 consisted of a more formal treatment of material introduced in Chapter 4, so this chapter consists

of a more formal treatment of material introduced in Chapter 9. But there's rather more to cover in this chapter than

there was in Chapter 5, as you'll soon see. Let me just say up front that, just as Chapter 5 had little to say about 2NF

or 3NF, so this chapter has little to say about 4NF, either; like 2NF and 3NF, in fact, 4NF is─from some points of

view, at least─mainly of historical interest. However, I'll have more to say about it in a later chapter (Chapter 12).

JOIN DEPENDENCIES

I begin with a precise and accurate definition of what a JD is, followed by some explanatory text that deliberately

parallels the corresponding text in Chapter 5. (Similar remarks apply to the next section also.)

Definition:
Let
H
be a heading; then a
join dependency
(JD)
with respect to
H
is an expression of the form

{
X1
,...,
Xn
}, where
X1
, ...,
Xn
(the
components
of the JD) are subsets of
H
whose union is equal to
H
.

Note:
The phrase
JD with respect to H
can be abbreviated to just
JD
, if
H
is understood.

Here are some examples:

{ { SNO , SNAME , CITY } , { CITY , STATUS } }

{ { CITY , SNO } , { CITY , STATUS , SNAME } }

{ { SNO , SNAME } , { SNO , STATUS } , { SNAME , CITY } }

{ { SNO , CITY } , { CITY , STATUS } }

Note carefully that JDs (like FDs) are defined with respect to some heading, not with respect to some relation

or some relvar. Of the JDs just shown, for example, the first three are defined with respect to the heading

{SNO,SNAME,STATUS,CITY} and the fourth is defined with respect to the heading {SNO,STATUS,CITY}.

Note too that from a formal point of view (again like FDs), JDs are just expressions: expressions that, when

interpreted with respect to some specific relation, become propositions that, by definition, evaluate to either TRUE

or FALSE. For example, if the first two JDs shown above are interpreted with respect to the relation that's the

current value of relvar S (Fig. 1.1), then the first evaluates to TRUE and the second to FALSE. Of course, it's

common informally to define
{
X1
,...,
Xn
} to be a JD, in some specific context, only if it evaluates to TRUE in that

context. However, such a definition leaves no way of saying a given relation fails to satisfy, or violates, some JD—

because, by that informal definition, a JD that isn't satisfied wouldn't be a JD in the first place. For example, we

wouldn't be able to say the relation that's the current value of relvar S violates the second of the JDs shown above.