Study guide
Section 3.3: Normalization
DAMA Certified Data Management Professional CDMP
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & DMBoK Framework
1.1 CDMP Exam Details & Strategy 1.2 The DMBoK Framework 1.3 Data Management Organization & Roles
2 Chapter 2: Data Governance (Part A)
2.1 Data Governance Principles & Drivers 2.2 Operating Models & Structures 2.3 Policies, Standards, and Procedures
3 Chapter 2: Data Governance (Part B)
2.4 Data Stewardship 2.5 Governance Metrics & Implementation
4 Chapter 3: Data Modeling and Design (Part A)
Section 3.1: Conceptual, Logical, and Physical Models Section 3.2: ERD Notations & Relational Modeling Section 3.3: Normalization
5 Chapter 3: Data Modeling and Design (Part B)
3.4 Dimensional Modeling 3.5 Naming Standards & Modeling Best Practices
6 Chapter 4: Data Quality (Part A)
Section 4.1: Data Quality Dimensions Section 4.2: Data Quality Policy & Rules Section 4.3: DMAIC & DQ Improvement Lifecycle
7 Chapter 4: Data Quality (Part B)
4.4 Root-Cause Analysis & Remediation 4.5 DQ Metrics, Tools, and Reporting
8 Chapter 5: Metadata Management (Part A)
5.1 Business, Technical, and Operational Metadata 5.2 Metadata Lineage & Impact Analysis 5.3 Repository Architectures
9 Chapter 5: Metadata Management (Part B)
5.4 Standards and Semantics 5.5 Metadata Governance & Integration
10 Chapter 6: Master and Reference Data Management
6.1 Master vs Reference Data 6.2 MDM Repository Architectures 6.3 Match-Merge & Identity Resolution 6.4 Reference Data Governance & Standards
11 Chapter 7: Data Warehousing and Business Intelligence
7.1 DW Architectures: Inmon vs Kimball 7.2 Data Warehousing Storage & Load Patterns 7.3 BI Delivery & OLAP 7.4 Data Marts & Enterprise Data Warehouses
12 Chapter 8: Data Architecture
8.1 Enterprise Data Architecture & Zachman Framework 8.2 Data Flow Diagrams & Value Chains 8.3 Architecture Frameworks & Standards
13 Chapter 9: Document and Content Management
9.1 Records Management & ECM 9.2 Retention, Disposal, and E-Discovery 9.3 ARMA GARP Principles & Taxonomies
14 Chapter 10: Data Integration and Interoperability
Section 10.1: Integration Patterns & Technologies Section 10.2: Replication & Virtualization Section 10.3: Canonical Models & Integration Standards
15 Chapter 11: Data Security
Section 11.1: Security Principles: CIA Triad & Privacy Section 11.2: Access Control & Encryption Section 11.3: Security Regulations & Standards
16 Chapter 12: Data Storage and Operations
Section 12.1: Database Technologies & DBA Roles Section 12.2: Backup, Recovery, and High Availability Section 12.3: Performance Tuning & Operations
17 Chapter 13: Big Data and Data Science
13.1 Big Data V's & Technologies
18 Chapter 14: Data Ethics
14.1 DMBoK Data Ethics Framework
19 Chapter 15: Data Management Process and Maturity
15.1 Maturity Assessment Frameworks
Section 3.3: Normalization
Key Takeaways Explain This Topic AI
Normalization is a mathematical process designed to minimize data redundancy and prevent insertion, update, and deletion anomalies.
First Normal Form (1NF) requires atomicity and no repeating groups; Second Normal Form (2NF) removes partial dependencies on composite keys; Third Normal Form (3NF) removes transitive dependencies where non-keys depend on other non-keys.
Boyce-Codd Normal Form (BCNF) is a stricter version of 3NF requiring that every determinant in a functional dependency must be a superkey.
Denormalization is a deliberate physical design choice to improve query performance at the cost of redundancy, transferring the responsibility of maintaining data integrity to the application layer.
Last updated: July 2026
Relational Database Normalization
Normalization is a systematic, mathematical process used in relational database design to organize tables in a manner that minimizes data redundancy and eliminates structural update anomalies . Developed by Edgar F. Codd, the pioneer of the relational model, normalization breaks down large, complex tables into smaller, well-structured tables that represent distinct business concepts. Relationships between these tables are then established using foreign keys.
Data Anomalies: The Consequence of Poor Design
Without normalization, data tables often suffer from redundancy, which leads to three primary types of data anomalies:
Insertion Anomaly : Occurs when a user cannot insert a record because some required data is not yet known or does not exist.
Example : If a single table combines Course and Instructor details, you cannot add a new course if no instructor has been assigned yet (assuming Instructor ID is part of a composite primary key or mandatory).
Update (or Modification) Anomaly : Occurs when data is duplicated across multiple rows. If that data changes, every duplicate row must be updated. If any row is missed, the database is left in an inconsistent state.
Example : If an instructor's phone number is stored in every row representing a class they teach, updating their phone number requires updating dozens of rows.
Deletion Anomaly : Occurs when deleting a record unintentionally destroys other unrelated business data that exists only in that record.
Example : If deleting a student's enrollment record also deletes the only copy of the course's description because student and course details are combined in one table.
The Progressive Normal Forms
Normalization is applied progressively, with each higher normal form building on the rules of the previous ones. For the CDMP exam, you must master the definitions and mechanics of First, Second, Third, and Boyce-Codd Normal Forms.
Normal Form Rule Summary Anomalies / Issues Resolved
First Normal Form (1NF) Eliminate repeating groups; ensure all column values are atomic; define a primary key. Multi-valued columns, unstructured records
Second Normal Form (2NF) Must be in 1NF; eliminate partial dependencies (non-key attributes must depend on the entire primary key). Anomalies caused by multi-attribute primary keys
Third Normal Form (3NF) Must be in 2NF; eliminate transitive dependencies (non-key attributes cannot depend on other non-key attributes). Anomalies caused by relationships between non-key fields
Boyce-Codd Normal Form (BCNF) Stricter version of 3NF; every determinant must be a candidate key. Multi-valued anomalies in tables with overlapping keys
First Normal Form (1NF)
A table is in First Normal Form (1NF) if:
All attributes contain only atomic (indivisible) values. There are no multi-valued attributes or comma-separated lists of values within a single cell.
There are no repeating groups (e.g., having columns like Phone1 , Phone2 , Phone3 ).
Each row is uniquely identifiable by a primary key.
Worked Example : A Customer table contains a column Phone Numbers with the value "555-0199, 555-0143" . To achieve 1NF, you must split these into separate rows or, ideally, move phone numbers to a separate Customer Phone table where each row contains a single phone number.
Second Normal Form (2NF)
A table is in Second Normal Form (2NF) if:
It is already in 1NF.
It has no partial dependencies . This means that if the primary key is a composite key (made up of multiple columns), every non-key column must depend on the entire key, not just a part of it.
Note : If a table has a single-column primary key, it is automatically in 2NF if it is in 1NF, because partial dependency is mathematically impossible.
Worked Example : In an Order Line table with a composite key of {Order ID, Product ID} , we have attributes Quantity and Product Description . Quantity depends on both the order and the product (valid 2NF). However, Product Description depends only on Product ID (part of the key). To resolve this partial dependency, Product Description must be moved to a separate Product table.
Third Normal Form (3NF)
A table is in Third Normal Form (3NF) if:
It is already in 2NF.
It contains no transitive dependencies . A transitive dependency occurs when a non-key attribute determines another non-key attribute (e.g., Customer ID determines Zip Code, which determines State). In other words, non-key columns must depend only on the primary key.
A common mnemonic used by data modelers is that every non-key attribute must depend on "the key, the whole key, and nothing but the key, so help me Codd."
Worked Example : In an Employee table with Employee ID as the primary key, we have the columns Department ID and Department Name . The Department Name depends on the Department ID (a non-key attribute), which in turn depends on the Employee ID . This is a transitive dependency. To achieve 3NF, the Department Name must be moved to a separate Department table.
Boyce-Codd Normal Form (BCNF)
A table is in Boyce-Codd Normal Form (BCNF) if:
It is in 3NF.
For every functional dependency X -> Y, the determinant X must be a superkey (a candidate key or a primary key).
BCNF is a stronger variation of 3NF. It resolves edge cases where a table has multiple, overlapping composite candidate keys. For example, if a table has candidate keys {A, B} and {A, C}, and there is a dependency where C -> B, the table is in 3NF but violates BCNF because C is not a superkey.
Pragmatic Denormalization and Read Optimization
While normalization is the standard for transactional systems ( Online Transaction Processing - OLTP ) where data integrity and write performance are paramount, it can create performance bottlenecks in analytics and reporting databases ( Online Analytical Processing - OLAP ). Because normalized databases distribute data across dozens of tables, retrieving complete data requires executing resource-intensive table joins.
To optimize query speeds, database architects selectively perform denormalization .
Reasons for Denormalization:
Query Performance : Minimizes the number of joins needed for complex reports.
Pre-computed Aggregations : Storing calculated columns (e.g., Order Total or Year-to-Date Sales ) instead of calculating them on the fly.
Data Archiving : Freezing historical data so that it remains static, even if master records change.
The Cost of Denormalization:
Denormalization is not a shortcut; it is a calculated risk. It introduces data redundancy, meaning the application layer or database triggers must now manage data synchronization to prevent update anomalies. If a denormalized attribute is updated in one table, the database must write update logic to ensure all duplicate locations are updated, increasing write latency.