Normalization Jokes and the Normal Forms They Make Fun Of

An old DBA joke says the more normal the database, the less normal its DBA. Normalization jokes like this one land because every DBA has lived them, so let me use a few of them to explain the first three normal forms in plain English.

Why Normalization Jokes Work

Normalization is the habit of storing each fact once, in the table where it belongs. People do not live this way. My kitchen drawer holds batteries, rubber bands, soy sauce packets and a key to an apartment I moved out of years ago.

Normalization jokes are really short lessons. The rules sound fussy, you ignore them, and then one day the same customer has three different addresses and nobody knows which one is true.

First Normal Form: One Value per Box

The joke: I stored all my phone numbers in one column, separated by commas, and now I have one problem, repeated. First normal form says each column holds one value, and a table has no repeating groups.

-- Not 1NF: several phone numbers squeezed into one column
CREATE TABLE dbo.CustomerBad
(
    CustomerId int PRIMARY KEY,
    Phones varchar(200)
);

-- 1NF: one row per phone number
CREATE TABLE dbo.CustomerPhone
(
    CustomerId int NOT NULL,
    Phone varchar(20) NOT NULL,
    PRIMARY KEY (CustomerId, Phone)
);

Try finding every customer with a certain area code in the first table. You end up writing string surgery. In the second table it is a simple WHERE clause.

Second Normal Form: The Whole Key

The joke: a table walks into a bar, and the bartender asks for its whole key before serving it. Second normal form matters when the key has more than one column. Every other column must depend on the whole key, not just part of it.

Picture an order line table keyed by OrderId and ProductId, with a ProductName column. ProductName depends only on ProductId. Rename a product and you have to update it on every order line that ever sold it. Move ProductName to a Product table and the problem is gone.

Third Normal Form: Nothing but the Key

DBAs have an old oath for this one: every column depends on the key, the whole key, and nothing but the key. Third normal form removes columns that depend on another non-key column.

A customer table with ZipCode and City is the classic case. City depends on ZipCode, not on the customer. Store it on every customer row, and sooner or later two customers with the same zip code live in two different cities.

When to Stop Telling Normalization Jokes

Reporting databases break these rules on purpose. A data warehouse copies product names into a wide table so reports stay fast and simple. That is fine when it is a decision you made, written down, with a clear source of truth.

So keep your normalization jokes for the office party, and keep the rules for any table that takes new data every day.

Related reading on this blog: Rules of Third Normal Form and Normalization Advantage: 3NF and Effect of Normalization on Index and Performance.

Store each fact once, and the database stays sane even when the DBA does not.

Normalization is not a fussy rule, it’s how one fact avoids having three versions of the truth.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.