Boyce–Codd normal form

From Wikipedia, the free encyclopedia

Boyce–Codd normal form (or BCNF or 3.5NF) is a normal form used in

database normalization. It is a slightly stronger version of the third normal form
(3NF). BCNF was developed in 1974 by Raymond F. Boyce and Edgar F. Codd to
address certain types of anomalies not dealt with by 3NF as originally defined. [1]

If a relational schema is in BCNF then all redundancy based on functional

dependency has been removed, although other types of redundancy may still exist.
A relational schema R is in Boyce–Codd normal form if and only if for every one of
its dependencies X → Y, at least one of the following conditions hold:[2]

X → Y is a trivial functional dependency (Y ⊆ X)

X is a super key for schema R

Chris Date has pointed out that a definition of what we now know as BCNF
appeared in a paper by Ian Heath in 1971.[3] Date writes:

"Since that definition predated Boyce and Codd's own definition by some
three years, it seems to me that BCNF ought by rights to be called
Heath normal form. But it isn't."[4]

Edgar F. Codd released his original paper 'A Relational Model of Data for Large
Shared Databanks' in June 1970. This was the first time the notion of a relational
database was published. All work after this, including the Boyce-Codd normal
form method was based on this relational model.

3NF table not meeting BCNF (Boyce–Codd

normal form)
Only in rare cases does a 3NF table not meet the requirements of BCNF. A 3NF
table that does not have multiple overlapping candidate keys is guaranteed to be
in BCNF.[5] Depending on what its functional dependencies are, a 3NF table with
two or more overlapping candidate keys may or may not be in BCNF.

An example of a 3NF table that does not meet BCNF is:

 Today's Court Bookings
Court Start Time End Time Rate Type
1 09:30 10:30 SAVER
1 11:00 12:00 SAVER
1 14:00 15:30 STANDARD
2 10:00 11:30 PREMIUM-B
2 11:30 13:30 PREMIUM-B
2 15:00 16:30 PREMIUM-A

Each row in the table represents a court booking at a tennis club that has one
hard court (Court 1) and one grass court (Court 2)
A booking is defined by its Court and the period for which the Court is
reserved
Additionally, each booking has a Rate Type associated with it. There are four
distinct rate types:
SAVER, for Court 1 bookings made by members
STANDARD, for Court 1 bookings made by non-members
PREMIUM-A, for Court 2 bookings made by members
PREMIUM-B, for Court 2 bookings made by non-members

The table's superkeys are:

S1 = {Court, Start Time}

S2 = {Court, End Time}
S3 = {Rate Type, Start Time}
S4 = {Rate Type, End Time}
S5 = {Court, Start Time, End Time}
S6 = {Rate Type, Start Time, End Time}
S7 = {Court, Rate Type, Start Time}
S8 = {Court, Rate Type, End Time}
ST = {Court, Rate Type, Start Time, End Time}, the trivial superkey

Note that even though in the above table Start Time and End Time attributes have
no duplicate values for each of them, we still have to admit that in some other
days two different bookings on court 1 and court 2 could start at the same time or
end at the same time. This is the reason why {Start Time} and {End Time} cannot
be considered as the table's superkeys.

However, only S1, S2, S3 and S4 are candidate keys (that is, minimal superkeys for
that relation) because e.g. S1 ⊂ S5, so S5 cannot be a candidate key.

Recall that 2NF prohibits partial functional dependencies of non-prime attributes

(i.e. an attribute that does not occur in ANY candidate key) on candidate keys, and
that 3NF prohibits transitive functional dependencies of non-prime attributes on
candidate keys.

In Today's Court Bookings table, there are no non-prime attributes: that is, all
attributes belong to some candidate key. Therefore the table adheres to both 2NF
and 3NF.

The table does not adhere to BCNF. This is because of the dependency Rate Type
→ Court in which the determining attribute Rate Type on which Court depends is
neither a candidate key nor a superset of a candidate key.

Dependency Rate Type → Court is respected since a Rate Type should only ever
apply to a single Court.

The design can be amended so that it meets BCNF:

Rate Types
Rate Type Court Member Flag
SAVER 1 Yes
STANDARD 1 No
PREMIUM-A 2 Yes
PREMIUM-B 2 No

Today's Bookings
Member Flag Court Start Time End Time
Yes 1 09:30 10:30
Yes 1 11:00 12:00
No 1 14:00 15:30
No 2 10:00 11:30
No 2 11:30 13:30
Yes 2 15:00 16:30

The candidate keys for the Rate Types table are {Rate Type} and {Court, Member
Flag}; the candidate keys for the Today's Bookings table are {Court, Start Time}
and {Court, End Time}. Both tables are in BCNF. When {Rate Type} is a key in
the Rate Types table, having one Rate Type associated with two different Courts is
impossible, so by using {Rate Type} as a key in the Rate Types table, the anomaly
affecting the original table has been eliminated.
Achievability of BCNF
In some cases, a non-BCNF table cannot be decomposed into tables that satisfy
BCNF and preserve the dependencies that held in the original table. Beeri and
Bernstein showed in 1979 that, for example, a set of functional dependencies {AB
→ C, C → B} cannot be represented by a BCNF schema.[6] Thus, unlike the first
three normal forms, BCNF is not always achievable.

Consider the following non-BCNF table whose functional dependencies follow the
{AB → C, C → B} pattern:

Nearest Shops
Person Shop Type Nearest Shop
Davidson Optician Eagle Eye
Davidson Hairdresser Snippets
Wright Bookshop Merlin Books
Fuller Bakery Doughy's
Fuller Hairdresser Sweeney Todd's
Fuller Optician Eagle Eye

For each Person / Shop Type combination, the table tells us which shop of this
type is geographically nearest to the person's home. We assume for simplicity that
a single shop cannot be of more than one type.

The candidate keys of the table are:

{Person, Shop Type}

{Person, Nearest Shop}

Because all three attributes are prime attributes (i.e. belong to candidate keys),
the table is in 3NF. The table is not in BCNF, however, as the Shop Type attribute
is functionally dependent on a non-superkey: Nearest Shop.

The violation of BCNF means that the table is subject to anomalies. For example,
Eagle Eye might have its Shop Type changed to "Optometrist" on its "Fuller"
record while retaining the Shop Type "Optician" on its "Davidson" record. This
would imply contradictory answers to the question: "What is Eagle Eye's Shop
Type?" Holding each shop's Shop Type only once would seem preferable, as doing
so would prevent such anomalies from occurring:

In this revised design, the "Shop Near Person" table has a candidate key of
{Person, Shop}, and the "Shop" table has a candidate key of {Shop}.
Unfortunately, although this design adheres to BCNF, it is unacceptable on
different grounds: it allows us to record multiple shops of the same type against
 the same person. In other
Shop Near Person Shop words, its candidate keys
Person Shop Shop Shop Type do not guarantee that the
Davidson Eagle Eye Eagle Eye Optician functional dependency
{Person, Shop Type} →
Davidson Snippets Snippets Hairdresser {Shop} will be respected.
Wright Merlin Books Merlin Books Bookshop
A design that eliminates
Fuller Doughy's Doughy's Bakery all of these anomalies
Fuller Sweeney Todd's Sweeney Todd's Hairdresser (but does not conform to
Fuller Eagle Eye BCNF) is possible. This
design introduces a new
normal form, known as Elementary Key Normal
Form.[7] This design consists of the original "Nearest Shops" table supplemented
by the "Shop" table described above. The table structure generated by Bernstein's
schema generation algorithm[8] is actually EKNF, although that enhancement to
3NF had not been recognized at the time the algorithm was designed:

Nearest Shops Shop

Person Shop Type Nearest Shop Shop Shop Type
Davidson Optician Eagle Eye Eagle Eye Optician
Davidson Hairdresser Snippets Snippets Hairdresser
Wright Bookshop Merlin Books Merlin Books Bookshop
Fuller Bakery Doughy's Doughy's Bakery
Fuller Hairdresser Sweeney Todd's Sweeney Todd's Hairdresser
Fuller Optician Eagle Eye

If a referential integrity constraint is defined to the effect that {Shop Type,

Nearest Shop} from the first table must refer to a {Shop Type, Shop} from the
second table, then the data anomalies described previously are prevented.