Fourth Normal Form (4NF)
Press Next → or use ← → arrow keys
The Story — The Club-Fair Spreadsheet
This table can already be in BCNF — no functional dependency is broken. Yet it's riddled with redundancy and anomalies. The culprit is a different species entirely: a multi-valued dependency.
Two Very Different "Dependencies"
A functional dependency maps one X to exactly one Y. A multi-valued dependency X →→ Y maps one X to a set of Y values — independent of everything else. Every FD is just an MVD whose set has size one.
BCNF's Blind Spot
3NF and BCNF are defined entirely in terms of functional dependencies — "every determinant is a superkey." They remove single-valued repetition completely.
They are completely blind to a different redundancy: when a single key independently determines two or more sets of values. Since no functional dependency describes that situation, no FD-based rule can remove it.
A table can be flawless in BCNF and still drown in multiplied rows. That's not a functional problem — it's a multi-valued one, and 4NF is the form built to catch it.
The Multi-Valued Explosion, In Data
| Student | Course | Club |
|---|---|---|
| Reena | DBMS | Music |
| Reena | DBMS | Drama |
| Reena | DBMS | Robotics |
| Reena | OS | Music |
| Reena | OS | Drama |
| Reena | OS | Robotics |
Two independent MVDs share one table: Student →→ Course and Student →→ Club. The table multiplies them together, inventing pairings like "OS + Robotics" that carry no real meaning.
The Explosion's Three Anomalies
No functional dependency is violated here, yet the table is full of redundancy and anomalies. The damage comes purely from cramming two independent multi-valued facts into one relation.
The Multi-Valued Dependency, Defined
X →→ Y reads "X multi-determines Y": one X value fixes a whole set of Y values, independent of the other attributes. It only causes trouble when a third attribute Z is also multi-valued on X and independent of Y.
If rows (x, y1, z1) and (x, y2, z2) both exist, then (x, y1, z2) and (x, y2, z1) must also exist. The values combine freely — that free combination is the fingerprint of an MVD.
Every functional dependency is also a multi-valued dependency — one whose "set" happens to have size one. So MVDs are the bigger, more general tool.
Trivial vs Non-Trivial MVDs
4NF only cares about non-trivial MVDs. A table whose only MVDs are trivial is already fine — which is exactly why the two split tables at the end will both satisfy 4NF.
Fourth Normal Form — The Definition
A relation is in 4NF if it is in BCNF and, for every non-trivial multi-valued dependency X →→ Y, X is a superkey.
"One table, one multi-valued fact." If a single key fans out into two unrelated sets, those sets belong in two separate tables.
Convert to 4NF — Split by the MVD
| Student | Course |
|---|---|
| Reena | DBMS |
| Reena | OS |
| Student | Club |
|---|---|
| Reena | Music |
| Reena | Drama |
| Reena | Robotics |
The 6 redundant rows collapse to 2 + 3 = 5 honest rows. Adding a course now adds one row — not a whole club-set. Each table holds only a trivial MVD, so both are in 4NF.
The Safety Check — Lossless, Not Spurious
Ronald Fagin proved that a relation can be decomposed losslessly into two of its projections precisely when a multi-valued dependency holds between them. The very condition that signals an MVD is the one that guarantees a clean, reversible split.
Join STUDENT_COURSE and STUDENT_CLUB back on Student and you reproduce the original exactly — no rows lost, and crucially no fake rows invented (no "spurious tuples").
Split a table along the wrong boundary and the rejoin invents rows that were never there. Splitting along a real MVD is the only way to stay lossless and spurious-free.
BCNF vs 4NF — Side by Side
| Aspect | BCNF | 4NF |
|---|---|---|
| Dependency handled | Functional X → Y | Multi-valued X →→ Y |
| Core rule | Every determinant is a superkey | Every non-trivial MVD's left side is a superkey |
| Redundancy removed | Single-valued repetition | Independent multi-valued explosion |
| Min. attributes to fail | 2 (overlapping keys) | 3 (two independent multi-valued) |
| Prerequisite | Must be in 3NF | Must be in BCNF |
| Generality | Subset of the picture | FDs are a special case of MVDs |
BCNF cleans up "one value determines one value." 4NF cleans up "one key fans out into two unrelated sets."
Academic vs Industry Lenses
Many systems land in 4NF without naming it — because good modelling separates association tables. Analytics layers may denormalize the wide multiplied shape deliberately for read speed: a profiled trade-off, never an accident.
When 4NF Matters — and When It's Overkill
If redundancy lingers because a table can only be rebuilt by joining three or more projections, that's a join dependency — the realm of 5NF (Project–Join Normal Form).
Golden Rules of 4NF
One Table, One Multi-Valued Fact
4NF catches the one thing BCNF is blind to: a single key independently determining two unrelated sets, multiplying them into a Cartesian explosion. Split each multi-valued fact into its own table and the explosion collapses — losslessly and without spurious rows, exactly as Fagin's theorem promises.
If one key fans out into two unrelated sets, they belong in two tables — that's 4NF. When repetition needs three-way joins to explain, you've reached 5NF.
💥 End of tutorial · Press ← to review, or click Restart