Understanding Database

Normalization: 1NF, 2NF, and 3NF

Explained
Database normalization is a systematic approach to organizing data in relational
databases to minimize redundancy and dependency. This lecture explores the
fundamental concepts of First Normal Form (1NF), Second Normal Form (2NF), and Third
Normal Form (3NF), providing practical examples and step-by-step guidance for applying
these principles to real-world database design challenges.
Why Normalize? The Purpose of Database Normalization
Core Objectives How It Works
Database normalization serves as the foundation for creating efficient, Normalization achieves these goals by organizing data into logical,
maintainable database systems. By systematically organizing data into related tables that maintain integrity and efficiency. The process relies
well-structured tables, normalization addresses critical data management heavily on the strategic use of various types of keys:
challenges that plague poorly designed databases.
Primary keys uniquely identify each record in a table
The primary goals include: Foreign keys create relationships between tables

Eliminating data redundancy - storing the same information Composite keys combine multiple columns to form unique
multiple times wastes space and creates maintenance nightmares identifiers

Preventing data inconsistencies - when duplicate data exists, These keys serve as the connective tissue linking tables together,
updates in one location may not reflect in others ensuring referential integrity while allowing data to be stored in its most
Avoiding anomalies - insertion, update, and deletion operations can logical location without unnecessary duplication.
produce unexpected or corrupted results in unnormalized databases
First Normal Form (1NF): Atomicity & Unique Rows
First Normal Form establishes the fundamental requirements for organizing data in a relational database. It's the essential first step in the normalization
process and sets the groundwork for all subsequent normal forms.

Atomic Values Only Unique Row Identification No Repeating Groups

Each table cell must contain only one Every row in the table must be unique and The table cannot contain repeating groups
atomic value4no multi-valued attributes, identifiable by a primary key. No two rows or arrays within columns. Each column
no composite attributes, and no nested should be completely identical, and there should represent a single type of data, not a
structures. This means you cannot store must be a way to distinguish each record collection of similar values that should
lists, arrays, or multiple pieces of from all others in the table. instead be represented as separate rows.
information in a single field.

Common 1NF Violation Example

Consider a student enrollment system where a designer attempts to store all courses for
each student in a single field. This creates a multi-valued attribute that violates 1NF
principles:

"A student table where courses are listed in a single cell (e.g., 'Math, English, Science')
violates 1NF because the Courses column contains multiple atomic values."

The solution: Split the data into multiple rows, with one course per row, ensuring each
cell contains only a single, indivisible value.
Example: Violating 1NF vs. 1NF Compliant Table
Let's examine a concrete example that demonstrates the transformation from a non-normalized table to one that satisfies First Normal Form
requirements. This side-by-side comparison illustrates the fundamental principle of atomicity.

o Before 1NF: Violation ' After 1NF: Compliant

This table violates 1NF because the Courses column contains multiple The normalized table ensures each cell contains exactly one atomic
values separated by commas. This design makes it impossible to value. Course information is separated into individual rows, making the
efficiently query, update, or maintain course information. data easily queryable and maintainable.

StudentID Name Courses StudentID Name Course

101 Amy Math, English 101 Amy Math

102 Bob Science 101 Amy English

102 Bob Science

Problems with this design:

Cannot easily search for students taking a specific course Benefits of this design:
Difficult to add or remove individual courses
Each course is a separate, atomic value
Cannot enforce referential integrity with a Courses table
Easy to query students enrolled in specific courses
Wastes space and creates inconsistent formatting
Simple to add or remove course enrollments
Enables proper relationships with other tables

Important Note: While this table is now in 1NF, it still contains redundancy (Amy's name appears twice). This redundancy will be addressed as
we progress to higher normal forms, particularly when we separate student information from enrollment information into distinct tables.
Second Normal Form (2NF): Eliminate Partial Dependency
Second Normal Form builds upon 1NF by addressing a specific type of redundancy that occurs with composite primary keys. Understanding 2NF
requires grasping the concept of functional dependency and recognizing when non-key attributes depend on only part of a composite key rather than
the entire key.

01 02 03

Must Already Be in 1NF Identify Composite Keys Eliminate Partial Dependencies

Before applying 2NF rules, the table must satisfy Second Normal Form primarily applies to tables All non-key attributes must depend on the entire
all First Normal Form requirements: atomic with composite primary keys4keys made up of primary key, not just part of it. If an attribute
values, unique rows identified by a primary key, two or more columns. Single-column primary depends on only one column of a composite key,
and no repeating groups. keys automatically satisfy 2NF. it creates a partial dependency that violates 2NF.

The Problem 2NF Solves

Partial dependencies create unnecessary redundancy and potential anomalies.
Consider a course-textbook relationship table with a composite key of (Course,
Textbook).

If attributes like Lecturer and Department depend only on Course (not on the
Textbook part of the key), they will be duplicated for every textbook associated
with that course.

This creates:

Update anomalies - changing a lecturer requires updates to multiple rows

Insertion anomalies - can't add a course without a textbook
Deletion anomalies - removing the last textbook deletes course information
Example: Normalizing to 2NF
This example demonstrates how to identify and resolve partial dependencies in a table with a composite primary key. We'll transform a 1NF table into
2NF by decomposing it into multiple tables where all non-key attributes fully depend on the entire primary key.

o Original Table (1NF but not 2NF)

The following table uses (Course, Textbook) as a composite primary key, but Lecturer and Department depend only on Course:

Course Textbook Lecturer Department

Relational DB Database Systems Jeremy Brown Computer Science

Relational DB Intro to Databases Jeremy Brown Computer Science

Identified Problem: Notice how Jeremy Brown and Computer Science are repeated for each textbook. These attributes depend on Course
alone, not on the combination of Course and Textbook. This partial dependency violates 2NF and creates unnecessary redundancy.

' After 2NF: Split Into Two Tables

To achieve 2NF, we decompose the original table into two tables where each non-key attribute depends on the entire primary key:

Table 1: Courses Table 2: CourseTextbooks

Primary Key: Course Primary Key: (Course, Textbook)

Course Lecturer Department Course Textbook

Relational DB Jeremy Brown Computer Relational DB Database Systems

Science
Relational DB Intro to Databases

This table stores course-specific information. Lecturer and Department

now appear only once per course, eliminating redundancy. This table stores the many-to-many relationship between courses and
textbooks, with Course serving as a foreign key linking to the Courses
table.

Result: Both tables are now in 2NF. All non-key attributes depend on the entire primary key of their respective tables. We've eliminated partial
dependencies while maintaining all the original information through table relationships.
Third Normal Form (3NF): Remove Transitive Dependency
Third Normal Form represents the final step in basic normalization, addressing a subtle but important type of dependency that can still exist even in 2NF
tables. While 2NF eliminates partial dependencies on composite keys, 3NF targets transitive dependencies4situations where non-key attributes
depend on other non-key attributes rather than directly on the primary key.

Must Be in 2NF No Transitive Dependency Direct Dependency Only

The table must already satisfy both 1NF and Non-key attributes cannot depend on other Each non-key attribute must depend only on
2NF requirements before addressing 3NF non-key attributes. Every piece of data must the primary key, not on any intermediary
concerns. depend directly on the primary key. attributes.

Understanding Transitive Dependency

A transitive dependency occurs when we have a chain of dependencies: A ³B
³ C. In database terms, if the primary key determines attribute B, and attribute B
determines attribute C, then C is transitively dependent on the primary key.

Classic Example:

In a Courses table with primary key Course:

Course ³ Lecturer (direct dependency)

Lecturer ³ Department (another dependency)
Therefore: Course ³ Lecturer ³ Department (transitive!)

This means Department depends on Course only indirectly through Lecturer. If

the same lecturer teaches multiple courses, the department information will be
redundantly stored, creating potential anomalies.

The 3NF Solution: Separate tables so that Lecturer information lives in its own table, with Department stored alongside Lecturer. The
Courses table then references Lecturer through a foreign key, eliminating the transitive dependency while maintaining all necessary
relationships.
Example: Achieving 3NF
Let's walk through a concrete example of identifying and resolving a transitive dependency. This transformation from 2NF to 3NF demonstrates how to
ensure every non-key attribute depends directly and solely on the primary key.

o Before 3NF: The Transitive Dependency Problem

Consider this Courses table that is in 2NF but violates 3NF due to a transitive dependency:

Course (PK) Lecturer Department

Relational DB Jeremy Brown Computer Science

Data Structures Jeremy Brown Computer Science

Organic Chemistry Sarah Johnson Chemistry

Biochemistry Sarah Johnson Chemistry

Why This Violates 3NF Problems Created

The problem is clear: Department depends on Lecturer, not directly on Redundancy: Computer Science and Chemistry repeat for each
Course (the primary key). course by that lecturer
Update anomaly: If Jeremy moves to a different department,
Dependency chain:
multiple rows need updates
Course ³ Lecturer 7 Insertion anomaly: Can't record a new lecturer's department
Lecturer ³ Department 7 without assigning them a course
Course ³ Department (indirect/transitive) Deletion anomaly: Removing all of Sarah's courses loses her
department information

' After 3NF: Separated Tables with Direct Dependencies

We resolve the transitive dependency by creating two tables where all non-key attributes depend directly on their respective primary keys:

Table 1: Courses Table 2: Lecturers

Primary Key: Course Primary Key: Lecturer

Course Lecturer (FK) Lecturer Department

Relational DB Jeremy Brown Jeremy Brown Computer Science

Data Structures Jeremy Brown Sarah Johnson Chemistry

Organic Chemistry Sarah Johnson

Department now depends directly on Lecturer (the primary key), with
each lecturer appearing only once. No redundancy, no transitive
Biochemistry Sarah Johnson
dependencies.

Each course is directly linked to its lecturer. Department information is no

longer stored here, eliminating the transitive dependency.

Achievement: Both tables are now in 3NF. Every non-key attribute depends directly on the primary key, nothing else. Department information is stored
once per lecturer, courses are stored once with their lecturer reference, and all relationships are maintained through proper foreign key constraints.
Summary: Normalization Progression & Benefits
Database normalization is a systematic journey through increasingly rigorous standards of data organization. Each normal form builds upon the previous
one, progressively eliminating different types of redundancy and dependency. Let's review the complete progression and understand the cumulative
benefits.

Third Normal Form (3NF)

Second Normal Form (2NF)
Requirement: No transitive dependencies4
First Normal Form (1NF)
Requirement: All attributes must depend all non-key attributes depend directly on the
Requirement: Atomic values in all cells, on the entire primary key (no partial primary key
unique rows identifiable by primary key dependencies)
Eliminates: Indirect dependencies where
Eliminates: Repeating groups, multi-valued Eliminates: Partial dependencies where attributes depend on other non-key
attributes, and arrays within columns non-key attributes depend on only part of a attributes
Result: Each piece of data exists as a single, composite key
Result: Complete elimination of
indivisible value in its own cell Result: Redundancy associated with redundancy, with each fact stored in exactly
composite keys is removed through table one place
decomposition

Cumulative Benefits of Full Normalization

Reduced Redundancy Improved Data Integrity

Each piece of information is stored in exactly one location, With single points of truth for each fact, updates automatically
dramatically reducing database size and eliminating inconsistencies. propagate correctly throughout the database via relationships.

Easier Maintenance Prevention of Anomalies

Changes to data structure or content are simpler and less error-prone Insertion, update, and deletion operations work predictably without
when data is properly organized and non-redundant. unexpected side effects or data loss.
Final Thoughts & Best Practices
Core Principles to Remember
Database normalization is not just a theoretical exercise4it's an essential
discipline for building scalable, maintainable database systems that serve as
reliable foundations for applications. Whether you're designing a small project
database or an enterprise-scale data warehouse, these normalization principles
remain fundamental.

1 Follow the Sequential Process

Always start with 1NF and progress methodically through 2NF to 3NF.
Each form builds on the previous one, and skipping steps can lead to
missed dependencies and lingering anomalies.

2 Leverage Keys Strategically

Primary keys, foreign keys, and composite keys are your tools for
maintaining relationships between tables. Design them thoughtfully to
ensure referential integrity across your entire database schema.

3 Balance Normalization with Performance

While normalization reduces redundancy and improves integrity,

sometimes strategic denormalization is practical for performance
optimization4especially in read-heavy systems or data warehouses
where query speed outweighs storage concerns.

Practice Makes Perfect Document Your Decisions

The best way to master normalization is through hands-on practice As you normalize databases, document why you made specific
with real-world examples. Take existing poorly-designed databases decomposition choices. Understanding the reasoning behind your
and work through the normalization process. Identify dependencies, table structures helps future maintainers and serves as a valuable
decompose tables, and verify that your final design eliminates reference for your own learning journey.
redundancy while maintaining all necessary relationships.

Questions?
Database normalization is a deep topic with nuances that become clearer
through discussion and practice. Feel free to explore edge cases, discuss
trade-offs, or work through additional examples to solidify your
understanding of these fundamental database design principles.