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).
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.
Search WWH ::

Custom Search