BCNF, or Boyce-Codd Normal Form, is a stronger version of Third Normal Form. A relation is in BCNF when, for every non-trivial functional dependency X → Y, X is a superkey. The important difference is that 3NF sometimes allows a dependency whose determinant is not a superkey when the right-side attribute is prime, but BCNF does not allow that exception. This chapter explains the rule, 3NF vs BCNF, candidate keys, prime attributes, decomposition, lossless join, dependency preservation and solved examples in very simple language.
What Is BCNF in DBMS?
A relation is in BCNF if, for every non-trivial functional dependency X → Y, X is a superkey. In simple words, every attribute set that determines something new must be powerful enough to identify the complete row.
BCNF memory line
Every non-trivial determinant must be a superkeyIf functional dependency, attribute closure or candidate keys are still confusing, revise Functional Dependency in DBMS first. For 1NF, 2NF and 3NF, revise Normalization in DBMS: 1NF, 2NF & 3NF.
Determinant, Superkey and Prime Attribute
Formal Rule of 3NF
For every non-trivial functional dependency:
X → Aa relation is in 3NF if at least one of these is true:
Condition 1
X is a superkey.
Condition 2
A is a prime attribute, meaning A belongs to at least one candidate key.
The second condition is the important exception that makes 3NF slightly weaker than BCNF.
Formal Rule of BCNF
For every non-trivial functional dependency:
X → YBCNF requires:
X must be a superkeyThere is no “right side is prime” exception.
Why BCNF is stricter
3NF can accept some dependencies because the right side is prime. BCNF asks only one question: is the determinant a superkey?
3NF vs BCNF: Main Differences
| Point | 3NF | BCNF |
|---|---|---|
| Basic rule | For X → A, X is a superkey or A is prime. | For X → Y, X must be a superkey. |
| Strictness | Less strict. | Stricter than 3NF. |
| Prime-attribute exception | Allowed. | Not allowed. |
| Redundancy | Can still allow some redundancy caused by certain dependencies. | Removes a wider class of dependency-based redundancy. |
| Dependency preservation | 3NF synthesis can preserve dependencies. | BCNF decomposition may sometimes lose dependency preservation. |
| Relationship | A 3NF relation may not be in BCNF. | Every BCNF relation is also in 3NF. |
Simple Example of a Relation in BCNF
Consider:
STUDENT(Student_ID, Student_Name, Email)
Functional Dependencies:
Student_ID → Student_Name, Email
Email → Student_ID, Student_NameAssume both Student_ID and Email are unique candidate keys.
Check each non-trivial determinant:
| FD | Determinant | Superkey? | BCNF? |
|---|---|---|---|
| Student_ID → Student_Name, Email | Student_ID | Yes | Pass |
| Email → Student_ID, Student_Name | Yes | Pass |
Since every determinant is a superkey, the relation is in BCNF.
Example That Is in 3NF but Not in BCNF
Consider the relation:
R(Student, Course, Instructor)Assume the following rules:
(Student, Course) → Instructor
Instructor → CourseInterpretation:
Find candidate keys
(Student, Course) is a candidate key because it determines Instructor.
(Student, Instructor) is also a candidate key because Instructor determines Course.
Therefore all three attributes—Student, Course and Instructor—are prime attributes because each appears in at least one candidate key.
Why This Relation Satisfies 3NF
Check:
Instructor → CourseInstructor is not a superkey, but Course is a prime attribute because Course belongs to candidate key (Student, Course).
So the FD passes the formal 3NF rule using the prime-attribute exception.
3NF verdict
Determinant not superkey + RHS prime → 3NF can still allow itWhy the Same Relation Violates BCNF
BCNF does not care that Course is prime. It asks only:
Is Instructor a superkey?No. Instructor alone does not determine Student. Therefore:
Instructor → Courseviolates BCNF.
BCNF verdict
Instructor is not a superkey → BCNF failsCheck 3NF and BCNF Yourself
Use the same relation R(Student, Course, Instructor). Click a functional dependency to see the verdict.
FD: (Student, Course) → Instructor
Verdict
How to Decompose the Relation Into BCNF
The violating dependency is:
Instructor → CourseUse it to decompose:
Original relation
R(Student, Course, Instructor)
BCNF relations
R1(Instructor, Course)
R2(Student, Instructor)
R1(Instructor, Course)
In R1:
Instructor → CourseInstructor is a key of R1, so R1 is in BCNF.
R2(Student, Instructor)
There is no non-trivial dependency in R2 with a non-superkey determinant under our given FD set, so R2 is in BCNF.
Is the BCNF Decomposition Lossless?
Yes, this decomposition is lossless. The common attribute between R1 and R2 is Instructor, and Instructor functionally determines all attributes of R1.
R1 ∩ R2 = {Instructor}
Instructor → Course
Therefore Instructor → R1This is the standard lossless-join idea for binary decomposition: the common attributes should functionally determine all attributes of at least one decomposed relation.
Lossless memory line
Split tables → join back without wrong extra informationDoes BCNF Always Preserve All Functional Dependencies?
No. BCNF decomposition is designed to be lossless, but it may fail to preserve every original functional dependency directly in the smaller tables.
In our example, the original dependency:
(Student, Course) → Instructoris not contained completely inside R1(Instructor, Course) or R2(Student, Instructor). Enforcing it may require considering data across the decomposed relations.
BCNF strength
Stronger redundancy control because every non-trivial determinant must be a superkey.
Possible trade-off
Some BCNF decompositions are not dependency-preserving.
This is one reason 3NF is still important in practical relational design: a dependency-preserving 3NF decomposition can sometimes be preferred when preserving constraints locally matters.
How to Check Whether a Relation Is in BCNF
How Attribute Closure Helps in BCNF
For relation:
R(Student, Course, Instructor)
FDs:
(Student, Course) → Instructor
Instructor → CourseClosure of (Student, Course)
{Student, Course}+
= {Student, Course, Instructor}So (Student, Course) is a superkey.
Closure of Instructor
{Instructor}+
= {Instructor, Course}Student is missing, so Instructor is not a superkey. That is exactly why Instructor → Course violates BCNF.
Is Every BCNF Relation in 3NF?
Yes. Every relation in BCNF is also in 3NF, but every 3NF relation is not necessarily in BCNF.
Why? BCNF already satisfies the stronger condition that every non-trivial determinant is a superkey. If the determinant is a superkey, the 3NF rule is automatically satisfied.
Remember
BCNF ⊂ 3NF in strictness terms: BCNF is stronger2NF vs 3NF vs BCNF in One View
| Normal Form | Main Problem | Main Rule |
|---|---|---|
| 2NF | Partial dependency | Every non-prime attribute depends on the whole candidate key. |
| 3NF | Problematic transitive dependency | For X → A, X is a superkey or A is prime. |
| BCNF | Any remaining non-superkey determinant | For every non-trivial X → Y, X is a superkey. |
BCNF Mistakes to Avoid
Solved BCNF Question Step by Step
Given:
R(A, B, C)
FDs:
AB → C
C → BStep 1: Find candidate keys
AB+ gives A, B and C, so AB is a candidate key.
AC+ starts with A and C. From C → B, add B. So AC+ also gives A, B and C. Therefore AC is another candidate key.
All three attributes A, B and C are prime because each appears in at least one candidate key.
Step 2: Check 3NF
For:
C → BC is not a superkey, but B is prime. So 3NF allows the dependency.
Step 3: Check BCNF
C is not a superkey. Therefore C → B violates BCNF.
Step 4: Decompose
R1(C, B)
R2(A, C)In R1, C is a key because C → B. In R2, no given non-trivial dependency has a non-superkey determinant. The resulting relations satisfy BCNF under the projected dependencies.
How to Write BCNF in Semester Exams
Definition
Write: a relation is in BCNF if every non-trivial determinant is a superkey.
Rule + 3NF difference
Explain the superkey rule and mention that 3NF allows a prime-attribute exception but BCNF does not.
Solved decomposition
Find candidate keys, test every FD, identify the violating dependency, decompose and explain lossless join.
For answer presentation, revise How to Write High-Scoring Answers in University Semester Exams. For topic prioritization, use the previous-year-paper method.
Practice Questions With Answers
1. What is BCNF in DBMS?
BCNF is a normal form in which every determinant of a non-trivial functional dependency is a superkey.
2. What is the main difference between 3NF and BCNF?
3NF allows a non-superkey determinant when the right-side attribute is prime. BCNF requires every non-trivial determinant to be a superkey.
3. Is BCNF stronger than 3NF?
Yes. BCNF is stricter because it removes the prime-attribute exception allowed by 3NF.
4. Is every BCNF relation also in 3NF?
Yes. Every BCNF relation satisfies 3NF, but a 3NF relation may still violate BCNF.
5. How do you test BCNF?
For every non-trivial functional dependency X → Y, check whether X is a superkey. If every determinant passes, the relation is in BCNF.
6. Why can a relation be in 3NF but not BCNF?
Because 3NF may accept a dependency with a non-superkey determinant when the dependent attribute is prime, while BCNF does not accept that case.
7. What is BCNF decomposition?
It is the process of splitting a relation that violates BCNF into smaller relations so that the violating determinant becomes a key in an appropriate relation.
8. Is BCNF decomposition always lossless?
The standard BCNF decomposition algorithm is designed to produce a lossless decomposition.
9. Does BCNF always preserve functional dependencies?
No. A lossless BCNF decomposition may fail to preserve every original functional dependency directly in the decomposed relations.
10. What should I study after BCNF?
Study multivalued dependency, Fourth Normal Form, join dependency and Fifth Normal Form.
BCNF One-Minute Revision Sheet
Ultimate memory line
3NF asks “superkey OR prime RHS?” · BCNF asks only “superkey?”Frequently Asked Questions
What is BCNF in DBMS in simple words?
BCNF is a stricter normal form where any attribute set that determines another new attribute must be a superkey.
What is the difference between 3NF and BCNF?
3NF allows a dependency when the determinant is a superkey or the right-side attribute is prime. BCNF requires the determinant itself to be a superkey for every non-trivial dependency.
Can a relation be in 3NF but not BCNF?
Yes. This happens when a non-superkey determinant determines a prime attribute. 3NF may allow it, but BCNF rejects it.
How do you find a BCNF violation?
Check every non-trivial functional dependency and compute whether the determinant is a superkey. Any non-superkey determinant creates a BCNF violation.
Is BCNF decomposition always dependency-preserving?
No. BCNF decomposition can be lossless while still failing to preserve every original functional dependency directly.
What should I learn after BCNF?
Continue with multivalued dependency, 4NF, join dependency and 5NF.
What Should You Learn Next?
Next: Multivalued Dependency & Fourth Normal Form (4NF)
BCNF handles functional-dependency problems. The next level is understanding situations where one key independently determines multiple sets of values. That leads to multivalued dependency and 4NF.
For video revision after reading, use the DBMS YouTube study guide only as a secondary resource.
