Definition

A relation is in BCNF if, for every non-trivial and decomposed functional dependency , the LHS (X) is a superkey of .

Note

  • βœ… All RHS attributes must depend only on superkeys
  • ❌ If RHS depends on non-superkey β‡’ LHS can repeat β‡’ Redundancy arises

BCNF Checking Algorithm (Conceptual)

  1. List all non-trivial and decomposed FDs.
  2. Check if each FD has a superkey on its LHS.
  3. If all FDs pass this test, then the relation is in BCNF.

Shortcut: β€œMore but not all” condition

If any closure of a subset X yields more than X but not all attributes of R, then: β€’ X is not a superkey β€’ Hence, violates BCNF

This condition helps you avoid checking all FDs manually.

Pros and Cons

BCNF Pros

  1. Eliminates update, insertion, and deletion anomalies
  2. Reduces redundancy
  3. Lossless join: Original table can be reconstructed from decomposed tables

BCNF Cons

  1. FDs may not be preserved after decomposition. Enforcing original constraints may no longer be possible directly.

BCNF Decomposition Algorithm

Goal: Remove BCNF violations recursively

Step-by-step:

  1. Find such that satisfies β€œmore but not all” condition
  2. Decompose R into:
  3. Repeat this process on R₁ and Rβ‚‚ recursively, using projected FDs

Note

Each decomposition removes at least one BCNF violation.

  • Final result is not unique – depends on order of choices
  • If a relation has only 2 attributes, it is always in BCNF

Example

Given:

  • Relation:
  • Functional Dependencies (FDs):

Step 1: Find violating FD β†’ More than A, but not all β†’ violates BCNF

Step 2: Decompose R

  • (attributes in )
  • ( + rest)

Step 3: Check BCNF

  • : No violating FD β†’ βœ…
  • : , but is not a superkey β†’ ❌

Step 4: Decompose R1

  • B+ = {B, C} β†’ violates BCNF

Decompose:

  • R3(B, C)
  • R4(A, B)

βœ… Final BCNF Tables:

  • R2(A, D)
  • R3(B, C)
  • R4(A, B)

Closure Projection for Decomposition

When decomposing into and :

  • To find the FDs for , use the original FDs but ignore attributes not in
  • Do the same for

Lossless Join Property

To verify that decomposition is lossless:

  1. Compute common attributes of the decomposed tables
  2. Check if the closure of those attributes contains all attributes of one of the relations

Note

  • If yes β†’ lossless join is guaranteed
  • Also can test: does natural join of all decompositions yield the original relation?

Dependency Preservation

Let:

  • = original set of FDs
  • = FDs preserved across all decomposed tables

To check if dependency is preserved, confirm β€²,

  • For every FD in , can it be derived from β€²?
  • For every FD in β€², can it be derived from ?

Trick

If a decomposed relation contains all attributes of and , then is preserved in that relation.

Dependency Preservation Algorithm

  1. For each decomposed relation , compute closure of all subsets of attributes
  2. Find all implied FDs in
  3. Combine them to form β€²
  4. Check if and β€² are equivalent