Normalization is usually introduced as a set of rules: identify functional dependencies, remove partial and transitive dependencies, and work your way up through 1NF, 2NF, 3NF, and BCNF. In practice, you rarely start with a messy table and normalize it in isolation. You start with requirements, draw an entity-relationship model, and then produce a relational schema whose tables are already close to normalized because the entities and relationships were identified well in the first place. This topic connects those two views: the theory you can apply as a check, and the design process that produces well-structured schemas in the first place.
Real-world data complicates things. Business rules change, source data arrives denormalized from spreadsheets or legacy systems, some dependencies are ambiguous until you talk to a domain expert, and splitting tables for correctness can mean more joins at query time. Design is therefore iterative: you sketch a model, test it against sample data and expected queries, discover a dependency you missed, and revise. This module's later topics on denormalization build directly on this foundation — you cannot make a sound trade-off decision unless you know what the normalized baseline looks like.
As you watch the videos below, pay attention to how each presenter moves from a business description to entities, attributes, keys, and relationships. Ask yourself where a functional dependency is being implicitly resolved when an attribute is placed in one table rather than another, how many-to-many relationships become junction tables, and where the presenter makes a judgment call rather than following a mechanical rule. Those judgment calls are exactly what this topic is about.
A walkthrough of the overall database design process, from understanding what the system needs to store through to producing a workable table structure. Based on its title and channel, it should cover the stages of design — gathering requirements, identifying entities and attributes, defining relationships and keys — and is likely to touch on normalization as one step within that larger process.
Database Star is a well-known, practitioner-oriented channel focused specifically on relational design and SQL, and this video frames normalization as part of an end-to-end, iterative design workflow rather than an isolated exercise.
A focused, shorter video on the specific step of turning written requirements into a concrete database schema. Expect it to demonstrate reading a requirements statement, extracting the nouns and rules that become tables, columns, and relationships, and producing the resulting schema; the description also links to practice exercises on the same skill.
It targets the translation step directly — requirements to normalized schema — which is the hardest part of applying normalization theory in production, and the linked exercises let you practice rather than just watch.
An introductory tutorial on building an entity-relationship diagram from scratch, covering entities, attributes, and cardinality according to its description. It should establish the vocabulary and notation you need to read and produce ER diagrams before converting them into tables.
Produced by Lucid Software (makers of Lucidchart), it is a clear, widely viewed primer that gives you the ER foundation assumed by the schema-translation subtopic, including the cardinality distinctions that determine how relationships map to keys and junction tables.
Together these videos support MO2 most directly: the ERD tutorial gives you the modeling notation and cardinality concepts, while the two Database Star videos show the path from requirements to entities to a concrete table structure that avoids redundancy. They also reinforce MO1 indirectly, since deciding which attributes belong with which key during design is the same reasoning used to spot functional dependency violations when classifying an existing table. Because the design walkthroughs treat schema design as an iterative process with explicit trade-offs, they also set up the baseline you will need for MO3, MO4, and MO5 — you must be able to produce and defend a normalized schema before you can argue for selectively denormalizing it against a specific workload.
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.