Chapter 10. JDs and 5NF (Formal)

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 (Figure 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.

Here’s another example of a JD that happens to be satisfied by the current value of relvar S (and in fact by all legitimate values of that relvar):

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

This JD corresponds to a nonloss decomposition in which one of the projections isn’t needed in the reconstruction process. In fact, it’s clearly equivalent to the first of the four shown previously[100]

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

—implying that one of the two identical components can be dropped without significant loss. For such reasons, I’ll feel free to refer to the components of any given JD as constituting a set, even though the commalist of components in the written form of that JD might contain repetitions (duplicates), which sets per se never do. (That’s why that commalist is enclosed in braces, of course.)

To continue with the definitions:

  • Definition: Let relation r have heading H and let {X1,...,Xn} be a JD, J say, with respect to H. If r is equal to the join of its projections on X1, ..., Xn, then r satisfies J; otherwise r violates J.

Observe that it’s relations, not relvars, that satisfy or violate some given JD. For example, the relation that’s the current value of relvar S satisfies both of these JDs—

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

—and violates this one:

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

Note that the question of that relation satisfying or violating the JD {{SNO,CITY},{CITY,STATUS}}—the last of our original set of four sample JDs—doesn’t arise, because that JD isn’t defined with respect to the heading of that relation.

  • Definition: Let relvar R have heading H and let {X1,...,Xn} be a JD, J say, with respect to H. Then the JD J holds in relvar R (equivalently, relvar R is subject to the JD J) if and only if every relation that can ever be assigned to relvar R satisfies J. The JDs that hold in relvar R are the JDs of R.

Please note the terminological distinction I’m drawing here—JDs are satisfied (or are violated) by relations, but hold (or don’t hold) in relvars. I’ll adhere to this distinction throughout what follows. By way of example, the following JD holds in relvar S—

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

—and these ones don’t:

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

(Contrast the examples following the previous definition.) So now, at last, we know precisely what it means for a given relvar to be subject to a given JD—and it’s immediate that relvar R can be nonloss decomposed into its projections on X1, ..., Xn if and only if it’s subject to the JD {X1,...,Xn}.



[100] In general, two JDs are equivalent if and only if every relation that satisfies either one also satisfies the other. I’ll have more to say on this topic (equivalence of JDs) in the next chapter.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.138.61.208