Normalization, Gently

One fact, one place

Normalization is the practice of structuring tables so each fact is stored exactly once. That is the principle behind everything in this unit, and it has a simple test: if a fact changed, how many rows would you have to edit? The answer should be one.

Here is a library table that fails the test:

Ana's email is stored twice, once per loan. Update it on one row and forget the other, and the table now contradicts itself: two different emails for one person, and no way to know which is right. This is called an update anomaly. The next block commits that exact crime so you can see the damage.

The normalized fix

Split by thing: members are one thing, loans are another.

• members(id, name, email): each person once.
• loans(member_id, book): each loan points at a member (one-to-many, lesson 5-1).

Now Ana's email lives in exactly one row. Updating it once fixes it everywhere, because every loan points at the same member row instead of carrying its own copy. The cost is that reading requires a JOIN, and that is the trade: normalized data is a little more work to read and much safer to write.

You do not need the formal jargon yet (first normal form, second, third). For a working engineer the instinct is: repeating the same value down a column that describes some other entity is a smell. Split the table.