Database

Design &
Normalizatio
n
Master the fundamental principles of relational database design through
systematic normalization techniques. This comprehensive guide explores
functional dependencies, normal forms, and advanced decomposition
methods that ensure data integrity, eliminate redundancy, and optimize
database performance for real-world applications.
Functional Dependencies: The Foundation of
Database Design
Definition & Concept Practical Example Types of Dependencies
A functional dependency X → Y means In a Student table, StudentID → Name • Trivial dependencies (X → X)
that if two tuples have the same value means each student ID uniquely • Non-trivial dependencies
for attribute set X, they must have determines exactly one student
• Partial dependencies
the same value for attribute set Y. name. This dependency ensures data
• Transitive dependencies
This mathematical relationship forms consistency and prevents anomalies.
the backbone of normalization theory.

Understanding functional dependencies is crucial because they reveal the inherent structure of your data and guide the
normalization process. They help identify which attributes logically depend on others, forming the basis for creating well-designed
database schemas.
Normal Forms: Systematic Database Organization
The Normalization Hierarchy

Normal forms represent increasingly strict rules for organizing database tables. Each higher
normal form builds upon the requirements of lower forms, creating a systematic approach to
eliminating data redundancy and insertion, update, and deletion anomalies.

01

First Normal Form (1NF)

Eliminates repeating groups

02

Second Normal Form (2NF)

Removes partial dependencies

03

Third Normal Form (3NF)

Eliminates transitive dependencies

04

Boyce-Codd Normal Form

Handles all functional dependencies

First, Second & Third Normal Forms
First Normal Form (1NF)
Rule: Each table cell contains only atomic (indivisible) values, and each record is unique.

Example: Instead of storing "Math, Science, History" in a single Subjects field, create separate rows for each subject or a separate
Subjects table.

Benefits: Eliminates repeating groups and ensures data can be properly queried and indexed.

Second Normal Form (2NF)

Rule: Must be in 1NF and all non-key attributes are fully functionally dependent on the primary key.

Example: In a CourseEnrollment table with composite key (StudentID, CourseID), StudentName depends only on StudentID, violating 2NF.

Solution: Move StudentName to a separate Students table to eliminate partial dependency.

Third Normal Form (3NF)

Rule: Must be in 2NF with no transitive dependencies (non-key attributes depending on other non-key attributes).

Example: If StudentID → DepartmentID and DepartmentID → DepartmentName, then DepartmentName transitively depends on StudentID.

Solution: Create separate Department table to eliminate transitive dependency.

Boyce-Codd Normal Form (BCNF)
Beyond Third Normal Form

BCNF is a stricter version of 3NF that handles anomalies that 3NF might miss. A relation is in BCNF if for every functional
dependency X → Y, X must be a superkey. This means that only candidate keys can determine other attributes.

"BCNF ensures that every determinant is a candidate key, eliminating all possible anomalies caused by functional dependencies."

Key Differences from 3NF

• More restrictive than 3NF

• Handles overlapping candidate keys
• May require more table decompositions
• Guarantees elimination of all FD-based anomalies

BCNF Example

Consider a table with attributes (Student, Course, Instructor) where:

• Student, Course → Instructor

• Instructor → Course

The second dependency violates BCNF because Instructor is not a superkey. Solution:
decompose into separate tables for student-instructor and instructor-course
Inclusion Dependencies
Core Concept Practical Applications Design Implications
An inclusion dependency states that Inclusion dependencies ensure Inclusion dependencies affect
values in one column must be a referential integrity between related database design by:
subset of values in another column, tables: • Constraining decomposition options
typically across different tables. This • Foreign key constraints • Influencing join strategies
concept formalizes the foreign key
• Subtype-supertype relationships •
constraint mechanism. Determining data insertion order
• Cross-table value validation • Impacting query optimization
Notation: R[A] ⊆ S[B] means every
• Data consistency enforcement
value in column A of relation R must
also appear in column B of relation S.

Understanding inclusion dependencies is essential for maintaining data integrity across normalized tables. They complement
functional dependencies by ensuring that relationships between separate tables remain consistent and valid throughout database
operations.
 Lossless Join Decompositions
Problem Identification 1
When decomposing tables during normalization, we risk losing information if the decomposition cannot perfectly reconstruct the
original table through joins.
2 Lossless Property
A decomposition R = {R₁, R₂, ..., Rₙ} is lossless if the natural join of all decomposed relations equals the original relation: R₁ ⋈ R₂
⋈ ... ⋈ Rₙ = R.
Testing Methods 3
Use the chase algorithm or check if common attributes form a superkey in one of the decomposed relations to verify lossless property.

4 Practical Implementation
Always ensure decompositions preserve the ability to reconstruct original data through proper join conditions and shared key attributes.

Binary Decomposition Test

For a binary decomposition R = {R₁, R₂}, the decomposition is lossless if and only if:

• R₁ ∩ R₂ → R₁ - R₂, or
• R₁ ∩ R₂ → R₂ - R₁

This means the common attributes must functionally determine the remaining attributes in at least one of the decomposed relations.
Normalization Using Functional Dependencies
01 02

Identify Functional Dependencies Find Minimal Cover

Analyze the data requirements and business rules to discover all Reduce the set of functional dependencies to a minimal cover by
functional dependencies. Document dependencies like StudentID → removing redundant dependencies and splitting dependencies with
Name, CourseID → Title, InstructorID → Department. multiple attributes on the right side.

03 04

Apply Normalization Algorithm Verify Decomposition Properties

Use algorithms like 3NF synthesis or BCNF decomposition to Ensure the resulting decomposition is both lossless and dependency-
systematically create normalized tables based on the functional preserving. Check that all original FDs can be enforced in the
dependencies. decomposed schema.

3NF Synthesis Algorithm BCNF Decomposition Algorithm

1. Compute minimal cover of FDs 1. If relation is in BCNF, stop

2. Create relation for each FD in minimal cover 2. Find BCNF violation X → Y
3. If no relation contains a candidate key, add one 3. Decompose into (X ∪ Y) and (R - Y)
4. Eliminate redundant relations 4. Recursively apply to each sub-relation
Multi-valued Dependencies (MVD) and Join Dependencies (J

Multi-valued Dependencies Fourth Normal Form (4NF) Join Dependencies

MVDs occur when one attribute determines a A relation is in 4NF if it's in BCNF and contains JDs generalize MVDs and specify that a relation
set of values for another attribute, independent no non-trivial multi-valued dependencies. This can be reconstructed by joining its projections
of other attributes. Notation: X →→ Y means X eliminates redundancy caused by independent on specified attribute sets. They lead to Fifth
multi-determines Y. multi-valued attributes. Normal Form (5NF).

Example: If a student can have multiple Solution: Decompose into separate tables for Application: Rare in practice but important for
hobbies and multiple courses independently, student-hobbies and student-courses. theoretical completeness and handling complex
then StudentID →→ Hobby and StudentID →→ multi-way relationships.
Course.

Key Insight: While functional dependencies handle one-to-one and many-to-one relationships, multi-valued dependencies address many-to-many
relationships where multiple independent sets of values are associated with a single key.

Practical MVD Example

Consider a Company table storing employees, projects, and skills. If an employee can work on multiple projects and have multiple skills independently, storing
this in one table creates excessive redundancy. The MVD Employee →→ Project | Skill suggests decomposition into separate Employee-Project and Employee-
Skill tables.
Alternative Approaches to Database Design

Entity-Relationship Modeling Dimensional Modeling

Start with conceptual ER diagrams that focus on entities, attributes, and Primarily used for data warehousing and analytics, this approach intentionally
relationships rather than normalization rules. This top-down approach helps denormalizes data into fact and dimension tables optimized for query
capture business requirements naturally before converting to relational performance rather than update efficiency.
schema.

Object-Oriented Design Agile Database Design

Map object-oriented application models directly to database structures, Embrace evolutionary database design with continuous refactoring, automated
potentially using object-relational features or NoSQL databases that better testing, and version control. Start simple and refactor as requirements emerge
support complex data types and inheritance. rather than trying to perfect the design upfront.

When to Use Alternatives Hybrid Approaches

ER Modeling: Complex domains requiring clear conceptual understanding Modern database design often combines multiple approaches: start with ER

Dimensional: Analytics and reporting systems modeling for conceptual clarity, apply normalization for OLTP systems, and
create dimensional models for analytics. The key is choosing the right
OO Design: Applications with complex object hierarchies
technique for each specific use case and performance requirement.
Agile: Rapidly evolving requirements