Database Normalization
Database normalization organizes relational tables to reduce data redundancy and prevent update anomalies. It applies a series of normal forms that determine how attributes are grouped into tables so that each fact is stored once and dependencies are explicit.
itDatabases and data storage | OpenSkills.info
Intro
Database Normalization
Database normalization is a way to design relational tables around facts and their dependencies. You separate facts that describe different things. You then connect those tables with keys.
The goal is not to create as many tables as possible. The goal is to give each fact one clear home. That structure reduces repeated data and makes changes less likely to produce contradictions.
Imagine one table that records orders, customers, and products:
| order_id | customer_id | customer_name | product_id | product_name | quantity |
|---|---|---|---|---|---|
| 501 | C7 | Amara Chen | P4 | Desk Lamp | 2 |
| 502 | C7 | Amara Chen | P9 | Cable Tray | 1 |
The customer name repeats for every order line. The product name repeats whenever someone orders that product. A spelling correction must reach every copy. Missing one copy leaves the database with conflicting versions of the same fact.
A normalized design gives each fact a home:
customersstores facts about a customer.productsstores facts about a product.ordersstores facts about an order.order_linesrecords which products belong to an order and in what quantity.
The order line still contains identifiers. Those identifiers are not unwanted repetition. They are keys that connect related facts.
The problem normalization solves
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://research.ibm.com/publications/a-relational-model-of-data-for-large-shared-data-banks
Supports
- Codd's relational model introduces relations and a normal form while addressing redundancy and consistency
- Logical representation can remain independent from internal storage representation
- https://research.ibm.com/publications/normalized-data-base-structure-a-brief-tutorial
Supports
- Normalization removes repeating groups and simplifies database relations
- A simple tabular relational view replaces hierarchical, network, and cross-referencing structures
- https://research.ibm.com/publications/a-note-on-lossless-database-decompositions
Supports
- A lossless database decomposition corresponds to a lossless join
- Functional dependencies and keys provide a characterization of lossless joins
- https://research.ibm.com/publications/multivalued-dependencies-and-a-new-normal-form-for-relational-databases
Supports
- Fourth normal form is based on multivalued dependencies
- Fourth normal form is stronger than Boyce-Codd normal form
- Relations can be decomposed into fourth normal form without loss of information
- https://mariadb.com/docs/general-resources/database-theory/database-normalization/database-normalization-overview
Supports
- Normalization aims to reduce redundancy and data-change anomalies
- Normalization can make referential integrity easier to enforce
- Normalization progresses through staged normal forms
- https://mariadb.com/docs/general-resources/database-theory/database-normalization/database-normalization-1st-normal-form
Supports
- First normal form removes repeating groups
- Each row-column intersection contains one value
- Keys are established before progressing through later normal forms
- https://mariadb.com/docs/general-resources/database-theory/database-normalization/database-normalization-2nd-normal-form
Supports
- Second normal form requires first normal form and no partial dependencies
- Partial dependency requires a composite key and dependence on only part of it
- A first-normal-form table with a single-field key is automatically in second normal form
- https://mariadb.com/docs/general-resources/database-theory/database-normalization/database-normalization-3rd-normal-form
Supports
- Third normal form requires second normal form and no transitive dependencies
- A transitive dependency passes from the primary key through another non-key attribute
- Third normal form addresses common data anomalies for many tables
- https://mariadb.com/docs/general-resources/database-theory/database-normalization/database-normalization-boyce-codd-normal-form
Supports
- Boyce-Codd normal form is distinct from fourth normal form
- Boyce-Codd normal form requires each determinant to be a candidate key
- A determinant determines another attribute, while a candidate key can uniquely identify a row
- https://mariadb.com/docs/general-resources/database-theory/database-normalization/database-normalization-4th-normal-form
Supports
- Fourth normal form addresses multiple independent multivalued dependencies
- Separating independent many-valued facts removes their repeated combinations
- https://mariadb.com/docs/general-resources/database-theory/database-normalization/database-normalization-5th-normal-form-and-beyond
Supports
- Fifth normal form addresses decompositions governed by join dependencies
- A valid decomposition can reconstruct the original facts through joins without losing information
- https://mariadb.com/docs/general-resources/database-theory/relational-databases-table-keys
Supports
- A candidate key is a field or field combination that uniquely identifies a record
- A primary key is the candidate key designated to identify records
- Candidate keys can include multiple fields, and unchosen candidates are alternate keys
- https://mariadb.com/docs/general-resources/database-theory/relational-databases-foreign-keys
Supports
- Foreign keys connect related tables through key values
- Foreign keys support referential integrity by requiring references to existing records
- https://mariadb.com/docs/general-resources/database-theory/database-normalization/understanding-denormalization
Supports
- Denormalization reverses normalization transformations for performance reasons
- Denormalization trades data-integrity advantages for potential query-performance benefits
- A normalized design should remain when its measured performance is acceptable
- https://www.ibm.com/docs/en/tpfdf/1.1.3?topic=database-normalization
Supports
- Normalization refines table structure through first, second, and third normal forms
- A primary key uniquely identifies a row and may contain more than one attribute
- Direct and transitive dependencies describe how attributes depend on a key
- https://learn.microsoft.com/en-us/previous-versions/troubleshoot/microsoft-365/microsoft-365-apps/access/database-normalization-description
Supports
- Normalization organizes tables and relationships to reduce redundancy and inconsistent dependencies
- First normal form eliminates repeating groups
- Worked examples show second- and third-normal-form decompositions
- https://www.postgresql.org/docs/current/ddl-constraints.html
Supports
- Primary keys require unique and non-null values and can span columns
- Unique constraints can enforce alternate candidate keys
- Foreign keys require referencing values to match eligible values in a related table
