Abstract
As noted in the previous chapter, Boyce/Codd normal form (BCNF for short) is defined in terms of functional dependencies (FDs); indeed, it’s really the normal form with respect to functional dependencies, just as—to get ahead of ourselves for a moment—5NF is really the normal form with respect to join dependencies (JDs). The overall purpose of the present chapter is to explain BCNF and FDs in detail; as the chapter title indicates, however, the various explanations and associated definitions are all intentionally a little informal at this stage. (Informal, but not inaccurate; I won’t tell any deliberate lies.) A more formal treatment of the material appears in the next chapter.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
One reviewer accused me of rewriting history with this definition. Guilty as charged, perhaps, but I do have my reasons; to be specific, earlier “definitions” of the concept were all, in my opinion, either too vague to be useful or flat out wrong. See SQL and Relational Theory for further discussion, also Exercise 4.16 at the end of the chapter.
- 2.
This sentence is 100% correct as stated. However, I don’t want to mislead you; the fact is, there are some exceptions—exceptions, that is, to the statement that relational attributes can be of any type whatsoever—but those exceptions have nothing to do with 1NF as such. (The exceptions in question were given in the answer to Exercise 2.2 in Chapter 2, but I repeat them here for convenience. First, if relation r is of type T, then no attribute of r can itself be of type T (think about it!). Second, no relation in the database can have an attribute of any pointer type.)
- 3.
Or relvars, rather (see my second “small point” in just a moment).
- 4.
And, perhaps more to the point, newer ones like XML (see Exercise 4.12).
- 5.
I note in passing that SQL does support something a little bit like RVAs, in the form of columns whose type is RT MULTISET, where RT is some specified “row type.”
- 6.
As we’ve seen, the relational world in general very unfortunately uses the term relation to mean sometimes a relation value and sometimes a relation variable. In exactly the same kind of way, SQL in particular uses the term table to mean sometimes a table value and sometimes a table variable. Be aware, therefore, that in this section I use the term table to mean a table variable specifically, not a table value.
- 7.
Though I note I passing that Requirement 2 in particular effectively means that SQL tables are never normalized—except, possibly, in the case of such a table with just one column (see footnote 14 in Chapter 1). However, the disciplines recommended in SQL and Relational Theory allow us among other things to treat such tables as if they were normalized after all (most of the time but, sadly, not all of the time).
- 8.
E. F. Codd: “A Relational Model of Data for Large Shared Data Banks,” Communications of the ACM 13, No. 6 (June 1970).
- 9.
Except as noted in footnote 2.
- 10.
“Agree on,” in contexts like the one at hand, is standard shorthand for “have the same value for.”
- 11.
In connection with the last of these examples in particular, see Exercise 4.10 at the end of the chapter.
- 12.
Do note, however, that there’s no suggestion that relvars have just one key. Au contraire, in fact: A relvar can have any number of distinct keys, subject only to a limit that’s a logical consequence of the degree of the relvar in question (see Exercise 4.9 at the end of the chapter).
- 13.
As a historical note, I remark that key and nonkey attributes were called prime and nonprime attributes, respectively, in Codd’s original normalization papers (see Appendix D).
- 14.
That’s why I didn’t show any double underlining when I showed the sample tuples—there are two candidate keys, and there doesn’t seem to be any good reason to make either of them primary and thus somehow “more equal than the other.”
- 15.
E. F. Codd: “Recent Investigations into Relational Data Base Systems,” Proc. IFIP Congress, Stockholm, Sweden (1974).
- 16.
Actually, when Raymond Boyce first came up with what became BCNF, he did call it fourth! The paper in which he first described the concept, IBM Technical Disclosure Bulletin 16, No. 1 (June 1973), had as its title “Fourth Normal Form and its Associated Decomposition Algorithm.” Since that paper predated Fagin’s paper on 4NF by several years (see Appendix D), Boyce’s original name could perfectly well have been used at the time. It was Codd who insisted on calling the new normal form “third”—describing Boyce’s definition as merely an improved version of one that already existed—and who thereby gave rise to a confusion (admittedly minor, but all logical differences are big differences) that continues to this day.
- 17.
Yes, I do mean three.
- 18.
You might think this is the wrong way round, but it isn’t. What I’ve shown is that not 2NF by Definition 1 implies not 2NF by Definition 2. Given that “p implies q” is equivalent to “(not p) or q,” therefore, it follows that what I’ve shown is that 2NF by Definition 2 implies 2NF by Definition 1, or (loosely) Definition 2 implies Definition 1 as stated. Apologies if you find this confusing!
- 19.
In our book Database Explorations: Essays on The Third Manifesto and Related Topics (Trafford, 2010) and elsewhere.
- 20.
Actually there’s no need for the projection in the example—CONSTRAINT SNP KEY {SNO} KEY {SNAME} would suffice.
- 21.
The symbol r! is pronounced “r factorial” (sometimes “r bang”) and denotes the product r × (r-1) × … × 2 × 1.
- 22.
Well, that’s not quite the situation as far as this book is concerned, because in this book I almost never declare primary keys as such (in fact Tutorial D provides no way of doing so)—but I think you see what I mean.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2019 C. J. Date
About this chapter
Cite this chapter
Date, C.J. (2019). FDs and BCNF (Informal). In: Database Design and Relational Theory. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-5540-7_4
Download citation
DOI: https://doi.org/10.1007/978-1-4842-5540-7_4
Published:
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-5539-1
Online ISBN: 978-1-4842-5540-7
eBook Packages: Professional and Applied ComputingProfessional and Applied Computing (R0)Apress Access Books