MVD, 4NF, and 5NF in DBMS: Definitions and Worked Examples

A multivalued dependency (MVD) is a constraint stronger than a functional dependency that captures “independent sets of values” for attributes related to the same determinant. In relational DBMS design, MVDs are central to Fourth Normal Form (4NF) and (more generally) to Fifth Normal Form (5NF).

Key notions

• [Multivalued Dependency (MVD)]{def="A dependency $X \\twoheadrightarrow Y$ meaning tuples agree on $X$ have independent $Y$ choices"}
• Fourth Normal Form (4NF)
• Fifth Normal Form (5NF)
• Join Dependency (JD)

Important limitation: I attempted to use required web research tools, but the web search service returned plan/usage errors. As a result, I cannot include the mandatory external citations for every major claim. If you can enable/upgrade web access, I will regenerate this section with full … citations.

Footnotes

1. Source unavailable: web search tool returned a usage/plan error, so citations could not be retrieved. Please enable web access to regenerate with proper references. ↩

Defining MVD in a DBMS context

Let $R$ be a relation with attribute sets partitioned as $R = X \cup Y \cup Z$ (disjoint sets).
An MVD $X \twoheadrightarrow Y$ holds if for any two tuples $t_1, t_2 \in R$ such that:

• $t_1[X] = t_2[X]$

then tuples exist (in $R$) that combine the $Y$-values from one tuple with the $Z$-values from the other, while keeping the $X$ value the same. Formally, for each $x$ fixed by $X$, the $Y$ and $Z$ components behave like two independent choices.

Intuition: “separately stored choices”

MVDs arise when a single entity (identified by $X$) can be associated with multiple values of $Y$ and multiple values of $Z$, and the pairings between $Y$ and $Z$ are not constrained beyond $X$.

Example: MVD in a schema (and why 4NF matters)

Schema

Consider relation:

• $R(\text{Student}, \text{Course}, \text{Instructor})$

Interpretation:

• Each student may take multiple courses.
• Each course has a single instructor (or instructors might be modeled separately, but we’ll focus on the independence pattern).
• Crucially, suppose the database semantics is:

For a given student, the set of courses and the set of instructors are independent choices; the relation records them but does not constrain which instructor goes with which course for the same student beyond the student identity.

Instance exhibiting an MVD

Let $S = \text{Student}$, $C = \text{Course}$, $I = \text{Instructor}$.

Assume the relation instance is:

Here, for Alice (fixed $Student$):

• $Course$ values are $\{DB, AI\}$
• $Instructor$ values are $\{Dr.\,Lee, Dr.\,Kim\}$
• and the table contains the cross-product of these sets.

This is consistent with an MVD:

• $Student \twoheadrightarrow Course$
• and also $Student \twoheadrightarrow Instructor$

More precisely, if we split attributes as $R(Student, Course, Instructor)$:

• $X = Student$
• $Y = Course$
• $Z = Instructor$

Then $Student \twoheadrightarrow Course$ means: for each fixed student, the courses can pair independently with instructors; similarly, $Student \twoheadrightarrow Instructor$.

Where it comes from

If the intended model is:

• $Student$ determines the set of courses chosen
• $Student$ also determines the set of instructors involved
• but the relation does not enforce a restriction tying a particular course to a particular instructor instance at the tuple level,

then the data should be representable without spurious coupling—this is exactly what MVDs capture.

Fourth Normal Form (4NF)

Definition

A relation $R$ is in 4NF if, for every nontrivial multivalued dependency $X \twoheadrightarrow Y$ that holds in $R$, the determinant $X$ is a superkey of $R$.

• Superkey
• Nontrivial MVD

Why 4NF exists

4NF removes redundant multivalued combinations that can cause update anomalies. If an MVD exists where the determinant is not a superkey, then the relation likely should be decomposed to separate independent value sets.

4NF with the running example

For $R(Student, Course, Instructor)$, suppose we believe:

• $Student \twoheadrightarrow Course$
• $Student \twoheadrightarrow Instructor$
• and $Student$ is not a superkey of $R$ (many students exist, so Student alone doesn’t uniquely identify tuples).

Then the relation violates 4NF due to a nontrivial MVD whose determinant is not a superkey.

Typical 4NF decomposition

Decompose into:

1. $R_1(Student, Course)$
2. $R_2(Student, Instructor)$

This removes the artificial coupling between course and instructor pairs and allows independent updates.

Fifth Normal Form (5NF / PJNF)

Where 4NF stops

Even if a relation is in 4NF (no problematic nontrivial MVDs), it can still suffer from join anomalies due to more complex constraints: not just MVDs, but join dependencies involving 3+ components.

5NF intuition

A relation in 5NF should not contain information that can only be reconstructed by joining multiple projections in a way that causes ambiguity/loss unless the join is implied by keys.

• Projection
• Lossless join
• Project-Join Normal Form (PJNF)

Definition (conceptual)

A relation $R$ is in 5NF if every nontrivial join dependency that holds in $R$ is implied by the keys of $R$ (i.e., the decomposition is justified by key constraints, not by accidental structure).

5NF example sketch (join dependency idea)

A classic pattern: a relation can be decomposed into several projections whose join recreates the original tuples, but no two-way (FD/MVD) constraint fully explains the structure. In such cases, only a higher-order join dependency reveals the true independence.

While an explicit full numeric instance requires careful setup, the key takeaway for DBMS design is:

• 4NF addresses redundancy caused by multivalued independence ($X \\twoheadrightarrow Y$).
• 5NF addresses redundancy caused by multi-part (3+ way) join structure (join dependencies).