Scribd
Upload
194 views3 pages

BCNF With Example

Boyce Codd Normal Form (BCNF) is a stricter version of Third Normal Form (3NF), requiring that every determinant be a candidate key. A table can be in 3NF but not in BCNF if a non-key attribute determines a key attribute. The document provides an example of a university database table and explains the steps to convert it to BCNF by restructuring the table to eliminate partial dependencies.

Uploaded by

fakhr5249
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
194 views3 pages

BCNF With Example

Boyce Codd Normal Form (BCNF) is a stricter version of Third Normal Form (3NF), requiring that every determinant be a candidate key. A table can be in 3NF but not in BCNF if a non-key attribute determines a key attribute. The document provides an example of a university database table and explains the steps to convert it to BCNF by restructuring the table to eliminate partial dependencies.

Uploaded by

fakhr5249
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Boyce Codd Normal Form

Example
Converting to BCNF

Usually tables that are in Third Normal Form are already in Boyce
Codd Normal Form. Boyce Codd Normal Form (BCNF) is
considered a special condition of third Normal form. A table is in
BCNF if every determinant is a candidate key. A table can be in
3NF but not in BCNF. This occurs when a non key attribute is a
determinant of a key attribute. The dependency diagram may look
like the one below

The table is in 3NF. A and B are the keys and C and D depend on
both A and B. There are no transitive dependencies existing between
the non key attributes, C and D.

The table is not in BCNF because a dependency exists between C


and B. In other words if we know the value of C we can determine the
value of B.

We can also show the dependencies as

ABCD
CB
Example

An example table from the University Database might be as follows:

If we know the Student Number and Teacher Code we know the


Offering (class) the student is in. We also know the review date for
that student and teacher (Student progress is reviewed for that class
by the teacher and student).

S_Num T_Code Offering# Review Date


123599 FIT104 01764 2nd March
123599 PIT305 01765 12th April
123599 PIT107 01789 2nd May
346700 FIT104 01764 3rd March
346700 PIT305 01765 7th May

The dependencies are


S_Num, T_Code  Offering#, Review Date
which means that the table is in third normal form. The table is not in
BCNF as if we know the offering number we know who the teacher
is. Each offering can only have one teacher!
Offering#  T_Code
A non key attribute is a determinant.

If we look at the table we can see a combination of T_Code and


Offering# is repeated several times. eg FIT104 and 01764.

Converting to BCNF

The situation is resolved by following the steps below

1 The determinant, Offering#, becomes part of the key and the


dependant attribute T_Code, becomes a non key attribute. So
the Dependency diagram is now
S_Num, Offering# T_Code, Review Date
2 There are problems with this structure as T_Code is now
dependant on only part of the key. This violates the rules for
2NF, so the table needs to be divided with the partial
dependency becoming a new table. The dependencies would
then be
S_Num, Offering# T_Code, Review Date
Offering# T_Code
3 The original table is divided into two new tables. Each is in
3NF and in BCNF.

StudentReview

S_Num Offering# Review Date


123599 01764 2nd March
123599 01765 12th April
123599 01789 2nd May
346700 01764 3rd March
346700 01765 7th May

OfferingTeacher

Offering# T_Code
01764 FIT104
01765 PIT305
01789 PIT107

You might also like