So far in this module you have studied BCNF, 4NF, and 5NF as definitions. This topic shifts the focus from definitions to practice: how do you take a messy, real-world schema with many attributes, overlapping candidate keys, and poorly documented business rules, and systematically work it into a higher normal form? The process usually starts with an audit — listing attributes, inferring the functional dependencies that actually hold in the data, identifying candidate keys, and only then testing each dependency against the BCNF condition that every determinant must be a superkey.
From there, normalization becomes a sequence of decisions rather than a single step. You decompose for BCNF, then check whether independent multi-valued facts have been forced into the same relation (a 4NF violation), then consider whether any remaining relation can be reconstructed from three or more projections (a 5NF join dependency). Each step must preserve the lossless-join property, and some steps cost you dependency preservation — a trade-off you have to justify, not ignore.
As you watch the videos below, pay attention to two things. First, the mechanics: how a determinant that is not a superkey is pulled out into its own relation, and how the original relation is rewritten. Second, the judgment calls: when a designer chooses to stop at 3NF, when denormalization is defensible, and how the overall design process (requirements, entities, keys, refinement) frames the normalization work you do on paper.
This lecture works through normalization examples aimed at a specific and frequently misunderstood point: BCNF decomposition is always lossless, but it does not always preserve all functional dependencies. Expect worked relations with their FD sets, identification of candidate keys, a check of whether each determinant is a superkey, and a demonstration of how a dependency can be lost after the relation is split.
It targets the BCNF-versus-3NF trade-off directly with concrete examples, which is exactly the judgment students need when auditing a schema and deciding how far to decompose; Gate Smashers is a widely used DBMS channel with an example-driven, exam-oriented style.
Database Star walks through the overall process of designing a database, from gathering requirements and identifying entities and attributes to choosing keys and refining the resulting tables. The video places normalization inside the larger design workflow rather than treating it as an isolated exercise, and the channel links to sample database design guides for further practice.
It supplies the context for the auditing and end-to-end walkthrough subtopics, showing how you arrive at a schema worth normalizing and how design decisions and trade-offs are weighed in practice by an experienced database educator.
The Gate Smashers lecture supports MO1 and MO4 most directly: it drills the superkey test for identifying BCNF violations and makes the dependency-preservation cost of BCNF decomposition explicit against 3NF, while its worked decompositions reinforce the lossless-join requirement in MO2. The Database Star video supports MO5 and the auditing stage of this topic by situating decomposition within a complete design process, so students can see how a multi-relation schema is built, inspected, and refined. Neither video substitutes for the module readings on multivalued and join dependencies (MO3 and the 4NF/5NF portions of MO2 and MO5), so use the course materials and practice schemas to complete those steps after watching.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.