Difference between revisions of "Database normalization"
Karl Jones (Talk | contribs) (Created page with "'''Database normalization''' (or '''normalisation''') is the process of organizing the columns (attributes) and tables (relations) of a relational database to minimize d...") |
Karl Jones (Talk | contribs) (→See also) |
||
| Line 40: | Line 40: | ||
* [[Database]] | * [[Database]] | ||
* [[Data redundancy]] | * [[Data redundancy]] | ||
| − | * [[ | + | * [[E. F. Codd]] |
* [[Relational database]] | * [[Relational database]] | ||
* [[Relational model]] | * [[Relational model]] | ||
Revision as of 11:47, 18 February 2016
Database normalization (or normalisation) is the process of organizing the columns (attributes) and tables (relations) of a relational database to minimize data redundancy.
Description
Normalization involves decomposing a table into less redundant (and smaller) tables without losing information; defining foreign keys in the old table referencing the primary keys of the new ones.
The objective is to isolate data so that additions, deletions, and modifications of an attribute can be made in just one table and then propagated through the rest of the database using the defined foreign keys.
Origin
Edgar F. Codd, the inventor of the relational model (RM), introduced the concept of normalization and what we now know as the First normal form (1NF) in 1970.
Codd went on to define the Second normal form (2NF) and Third normal form (3NF) in 1971, and Codd and Raymond F. Boyce defined the Boyce-Codd Normal Form (BCNF) in 1974.
Third normal form
Informally, a relational database table is often described as "normalized" if it meets Third Normal Form.
Most 3NF tables are free of insertion, update, and deletion anomalies.
The relational model separates the logical design from the physical design:
- DBMS performance is a matter of physical design using:
- *ndexes
- View materialization
- Big buffers, etc.
- Not a matter of changing the logical design
Example
A typical example of normalization is that an entity's unique ID is stored everywhere in the system but its name is held in only one table.
The name can be updated more easily in one row of one table.
A typical update in such an example would be the RIM company changing its name to BlackBerry.
That update would be done in one place and immediately the correct "BlackBerry" name would be displayed throughout the system.
See also
External links
- Database normalization @ Wikipedia
