Search
4 results for “normalization”
Search results
Database Normalization
What 1NF, 2NF, and 3NF actually require, why normalization removes update anomalies, and when denormalizing on purpose is the right call.
What problem does normalization solve?
Normalization removes redundant data by splitting it across related tables, which prevents update anomalies: without it, the same fact (say, a customer address) can be duplicated across many rows, so an update has to touch every copy or the data silently goes inconsistent. Normalization also prevents insertion anomalies (needing unrelated data to exist before you can insert a new fact) and deletion anomalies (losing unrelated data as a side effect of deleting one row).
What is the practical difference between 2NF and 3NF?
2NF removes partial dependencies: every non-key column must depend on the whole primary key, not just part of a composite key. 3NF goes further and removes transitive dependencies: a non-key column cannot depend on another non-key column. A classic 3NF violation is storing both zip_code and city on an orders table, where city is really determined by zip_code, not by the order itself, city belongs in its own lookup table.
When is denormalizing a good idea?
When read performance matters more than write simplicity and the redundancy is deliberately managed, for example, caching a computed total on an orders row instead of summing line items on every read, or duplicating a display name to avoid a join on a hot path. The key is that it is a conscious trade-off with a plan for keeping the duplicate data consistent (triggers, application logic, or accepting eventual consistency), not an accident.