DBMS Topics
Dependency Preservation
Last Updated : 21 May, 2026
A decomposition of R into R1, R2, ..., Rn is dependency-preserving if the union of the functional dependencies that can be derived from each Ri restricted to the attribut
Definition
A decomposition of R into R1, R2, ..., Rn is dependency-preserving if the union of the functional dependencies that can be derived from each Ri (restricted to the attributes of Ri) logically implies all the original FDs in F.
Let Fi = the set of FDs in F+ that involve only attributes in Ri.
The decomposition is dependency-preserving if:
(F1 ∪ F2 ∪ ... ∪ Fn)+ = F+
In other words: every original FD can be verified using one of the decomposed tables — without needing to perform a join.
Why Dependency Preservation Matters
If a decomposition is NOT dependency-preserving, enforcing the lost FD requires:
- Joining the decomposed tables back together
- Then checking the constraint
This is expensive and impractical at scale.
Example — Dependency-Preserving Decomposition
| F = { A | B, B → C, A → C } |
| Decompose into | R1(A, B), R2(B, C) |
| F1 (FDs on R1): A | B (from F, restricted to {A,B}) |
| F2 (FDs on R2): B | C (from F, restricted to {B,C}) |
| Check | (F1 ∪ F2)+ should equal F+ |
| From F1 ∪ F2 = {A | B, B→C}: |
| A | B (direct) |
| B | C (direct) |
| A | C (by transitivity: A→B, B→C) |
Example — NOT Dependency-Preserving
| F = { (Student, Course) | Teacher, Teacher → Course } |
| Candidate Keys | (Student, Course), (Student, Teacher) |
| BCNF decomposition (violating FD: Teacher | Course): |
| R1(Teacher, Course) Teacher | Course |
| R2(Student, Teacher) (Student, Teacher) | Student (trivial) |
| F1 (on R1): Teacher | Course ✓ preserved |
| F2 (on R2) | No non-trivial FDs |
| Can we check (Student, Course) | Teacher from F1 ∪ F2? |
| F1 ∪ F2 = { Teacher | Course } |
| Start | {Student, Course} |
| (Student, Course) | Teacher is NOT derivable from F1 ∪ F2 ✗ |
Testing Dependency Preservation
Algorithm
| For each FD X | Y in F: |
| IF Y ⊆ result | FD X→Y is preserved ✓ |
| ELSE | FD X→Y is NOT preserved ✗ |
| If all FDs in F are preserved | decomposition is dependency-preserving. |
3NF Guarantee
The 3NF synthesis algorithm always produces a decomposition that is:
- Lossless ✓
- Dependency-preserving ✓
3NF Synthesis Algorithm:
1. Compute canonical cover Fc of F
2. For each FD X → Y in Fc:
Create relation Ri(X ∪ Y)
3. If no Ri contains a candidate key of R:
Add a relation containing a candidate key of R
4. Remove any Ri that is a subset of another Rj
BCNF vs 3NF Trade-off
| Property | 3NF | BCNF |
|---|---|---|
| Lossless join | ✓ | ✓ |
| Dependency pres. | ✓ | Not always ✗ |
| Redundancy elim. | Partial | Complete ✓ |
Summary
Dependency Preservation
─────────────────────────
All original FDs can be verified in individual decomposed tables
without requiring a JOIN operation.
Importance
─────────────────────────
Lost FDs → Cannot enforce constraints efficiently
→ Possible constraint violations go undetected
→ Application-level enforcement needed (complex, error-prone)
Guarantee
─────────────────────────
3NF decomposition → always lossless + dependency-preserving
BCNF decomposition → always lossless, but may lose some FDs
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Dependency Preservation.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this DBMS topic.
Search Terms
dbms, database management system, database notes, sql, unit, dependency, preservation, dependency preservation
Related DBMS Topics