Skip to main content

FDs and BCNF (Formal)

  • Chapter
  • First Online:
Database Design and Relational Theory
  • 1674 Accesses

Abstract

Now I want to step back, take a deep breath as it were, and consider FDs and BCNF all over again—but this time I want to do it properly (with apologies for the small amount of repetition involved). As you’ll quickly see, the treatment in this chapter is rather more abstract than that in the previous one; it shouldn’t be too difficult to follow, if you’re fully comfortable with the material of that previous chapter, but it’ll certainly be more formal. For that reason, I don’t want you to look at this chapter at all until you’ve absorbed everything in the previous one. (Of course, that shouldn’t be hard to do, since most of what was in that chapter was surely familiar to you anyway.)

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 39.99
Price excludes VAT (USA)
  • Available as EPUB and PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 54.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Notes

  1. 1.

    In particular because it ignores attribute types. In fact I’m going to ignore attribute types throughout the rest of this chapter (except in the definition of join), and indeed throughout most of the rest of this book.

  2. 2.

    Refer to the section “Equality Dependencies” in Chapter 3 for an explanation of the shorthand notation I’m using here.

  3. 3.

    Well ... it is an FD, but one that holds in the join of two relvars (viz., SNC and CT), rather than in an individual relvar as such. Note, however, that enforcing the key constraints on those two relvars will enforce that multirelvar constraint “automatically”; that is, the multirelvar constraint in question is implied by—equivalently, is a logical consequence of—certain explicitly declared constraints (actually key constraints, in the case at hand).

  4. 4.

    See the remarks on lossy joins in footnote 5 in Chapter 3 (in the section “Normalization Serves Two Purposes”); see also the answer to Exercise 3.2 in that same chapter.

  5. 5.

    In his paper “Unacceptable File Operations in a Relational Database,” Proc. 1971 ACM SIGFIDET Workshop on Data Description, Access, and Control, San Diego, Calif. (November 11th-12th, 1971).

  6. 6.

    Or, as we would “more naturally” tend to write them, interchanging the two sets of attributes and specifying the individual attributes in a “more natural” order, on {SNO,SNAME,CITY} and {CITY,STATUS}.

  7. 7.

    Here I’m adopting once again the convenient fiction that relvars S, SNC, and CT all coexist (living alongside one another, as it were).

  8. 8.

    Subsidiary exercise: What are the predicates for these relvars?

Author information

Authors and Affiliations

Authors

Rights and permissions

Reprints and permissions

Copyright information

© 2019 C. J. Date

About this chapter

Check for updates. Verify currency and authenticity via CrossMark

Cite this chapter

Date, C.J. (2019). FDs and BCNF (Formal). In: Database Design and Relational Theory. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-5540-7_5

Download citation

Publish with us

Policies and ethics