Normalization is the systematic process of organizing the tables and columns of a relational database so that each fact is stored in exactly one place. When a design stores the same fact repeatedly — a customer's address repeated on every order row, for example — the database becomes vulnerable to inconsistency: one copy gets updated and the others do not. Normalization attacks this problem at the structural level by examining how attributes depend on keys and splitting tables until each table describes one kind of thing.
In this module you will work through the first three normal forms in detail, so this introductory topic sets up the vocabulary and the motivation you will need. Pay particular attention to the three classic anomalies — insertion, update, and deletion — because they are the practical symptoms that tell you a table is badly designed. Equally important is the idea of a functional dependency: the statement that one set of attributes determines another. Every rule you will learn for 1NF, 2NF, and 3NF is ultimately a statement about which dependencies are allowed to live in a table.
As you watch the videos below, look for three things: concrete examples of redundancy and the trouble it causes, the role of keys in deciding where an attribute belongs, and the reasoning behind each normal form rather than just its definition. The third video deliberately covers denormalization — the deliberate reintroduction of redundancy — so that you understand normalization as a design judgment with trade-offs, not a rule to be applied blindly.
A compact walkthrough of the first three normal forms, presented as a single connected progression from an unnormalized table to a normalized design. Based on its title and description, it frames normalization as both a philosophy and a set of mathematical rules for understanding how data elements relate and connect. Expect worked movement through 1NF, then 2NF, then 3NF, with the reasoning for each step.
At roughly ten minutes it gives you a complete map of the territory this module covers, which is exactly what an introductory topic needs before you study each normal form in depth.
Kevin Feasel focuses on the what and the why of normalization rather than rushing to the mechanics, including why it matters to working data platform professionals. The description also promises his ranking of the normal forms, which implies discussion of several forms and their relative practical value. Likely to cover redundancy, data integrity, and the motivation behind the normal form hierarchy.
This is the strongest fit for the conceptual subtopics here — what normalization is, the redundancy problem, the integrity goal, and the idea of normal forms as a graduated series — and it comes from an experienced data platform presenter speaking to a professional audience.
Decomplexify examines denormalization: what it means to deliberately reverse normalization in a relational database and how to recognize situations where doing so is appropriate. Expect discussion of the costs that normalized designs can impose and the redundancy risks you accept in exchange when you denormalize. The video assumes familiarity with normalized design and reasons about when to depart from it.
Seeing the opposite direction sharpens your understanding of what normalization actually buys you in integrity terms, and Decomplexify is widely regarded for clear, carefully reasoned explanations of relational design.
Together these videos build the conceptual foundation the module's outcomes depend on. The discussion of insertion, update, and deletion anomalies and the redundancy that causes them supports MO1, while the end-to-end progression through 1NF, 2NF, and 3NF previews the transformations required by MO2, MO3, and MO4 — atomicity and primary keys, partial dependencies under composite keys, and transitive dependencies. The emphasis on functional dependencies as the reason behind each rule prepares you to validate a finished schema against all three forms as required by MO5, and the denormalization video ensures you can justify your design decisions rather than apply the rules mechanically.
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.