How a Database Stops One Fact Becoming Many
Imagine a customer’s address appears on every order they have ever placed. If the customer moves, someone must update every copy. Miss one, and the database now tells two different stories about where the same person lives.
Normalization tackles this by separating facts according to what they describe. Customer details go in a customer table; orders go in an order table. Each customer receives a unique identifier, and an order stores that identifier instead of repeating the customer’s name and address. The identifier is a key: a value that lets the database connect related records.
Fewer Copies, Fewer Update Traps
The design helps prevent three common problems. An update anomaly occurs when a change must be repeated in several places. An insertion anomaly occurs when a fact cannot be added without inventing an unrelated record. A deletion anomaly occurs when removing one record accidentally erases the only copy of some other useful fact.
With customer details stored once, changing an address means editing one customer record. Orders still point to that customer, so the relationship remains intact without copying the address into each order.
The Tradeoff: Rebuilding the View
The information has not disappeared; it has been divided into linked pieces. To display an order alongside the customer’s current address, the database joins the order and customer tables—matching their identifiers to assemble a combined result.
That extra linking can make queries more involved, and highly normalized designs may require more joins. Designers therefore balance consistency against the practical needs of an application. The key benefit is that a correction has one authoritative place to land: instead of chasing conflicting copies, the system updates the fact and lets related records refer back to it.
