A deletion anomaly happens when removing one piece of information from a table accidentally destroys other, unrelated information that happened to be stored in the same row. If a single table mixes facts about two different things — say, a course and the instructor who teaches it — then deleting the last row about a course can also erase the only record of that instructor. The data was never intentionally discarded; it simply had nowhere else to live.
This matters in COP4708 because deletion anomalies are one of the three classic symptoms (along with insertion and update anomalies) that signal a table is doing too many jobs at once. Recognizing the symptom is the first step; the cure is normalization, which separates tightly coupled data into tables that each describe a single logical entity, linked by keys. Once the instructor lives in her own table, deleting a course row cannot take her with it.
As you watch the videos below, look for three things: (1) examples where one row holds facts about more than one entity, (2) the moment a presenter shows what is lost when a row is deleted, and (3) how splitting a table and introducing keys and foreign keys makes the loss impossible. Also pay attention to the denormalization video's discussion of trade-offs — it will help you see why anomalies are the price paid when tables are deliberately merged.
This video approaches the subject from the opposite direction: it explains what denormalization is, why engineers sometimes do it deliberately, and what is given up in return. Because denormalization means collapsing data back into wider, more tightly coupled tables, the discussion is likely to cover the redundancy and anomaly risks — including unintended data loss on deletion — that normalization had removed. Expect concrete situations where the trade-off is and is not worth making.
Seeing the reverse operation clarifies exactly why tightly coupled data creates deletion anomalies, and Decomplexify is known for careful, example-driven explanations of relational design.
Kevin Feasel introduces what database normalization is and why data professionals care about it, framing normalization as a practical discipline rather than an academic exercise. The video is likely to motivate normalization by pointing to the problems unnormalized tables cause, including redundancy and the anomalies that follow from it, before ranking and commenting on the normal forms themselves.
It supplies the "why" behind normalization, which is the heart of the subtopic on how normalization prevents deletion anomalies, and it is pitched at a professional audience working with real data platforms.
This is a compact walkthrough of the first three normal forms, moving step by step from an unnormalized table through 1NF, 2NF, and 3NF. Expect to see a sample table decomposed into smaller tables with keys, which is precisely the mechanism that decouples data so that deleting one fact no longer erases another.
At about ten minutes it gives a clear, concrete procedure for the fix, letting you connect the symptom (a deletion anomaly) to the structural remedy (splitting tables by entity).
Together these videos move from problem to cure. The normal forms walkthrough reinforces MO1 and MO5 by showing tables, rows, columns, and keys being reorganized so each table describes one entity. The introduction to normalization supports MO2 and MO4 by explaining why redundancy produces anomalies and how normalization removes them. The denormalization video supports MO3 and MO4 by showing what wide, tightly coupled tables look like and what risks they carry, which trains your eye for warning signs such as mixed entity types and repeating groups. Viewed as a set, they let you name a deletion anomaly, explain its cause, and apply normalization to prevent it.
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.