Unnormalized Data - The Problem

basic

Single table with everything causes update anomalies

-- ORDERS_BAD (Unnormalized):

order_id | customer_name | customer_email | product1 | price1

1 | John Smith | john@example.com | Laptop | 999.99

2 | John Smith | john@example.com | Keyboard | 79.99

-- PROBLEMS:

-- Update Anomaly: John changes email → update 2 rows

-- Delete Anomaly: Delete orders → lose customer

-- Storage Waste: Email stored twice

Problems with unnormalized data:

❌ Update Anomaly: Change email in multiple rows

❌ Insert Anomaly: Can't add customer without order

❌ Delete Anomaly: Delete orders loses customer

❌ Storage Waste: Redundant data

Unnormalized data causes inconsistencies, wasted storage, inflexible schema. Normalization solves these problems.

All

First Normal Form (1NF)

basic

Eliminate repeating groups, atomic values only

-- VIOLATES 1NF (repeating groups):

order_id | products

1 | Laptop, Mouse, Keyboard

-- ACHIEVES 1NF (atomic values):

order_id | customer_email | product_name | price

1 | john@example.com | Laptop | 999.99

1 | john@example.com | Mouse | 29.99

2 | john@example.com | Keyboard | 79.99

1NF Result:

✓ Each cell contains single value

✓ No arrays or comma-separated lists

✓ Can query individual products

⚠️ Still has redundancy (email repeated)

1NF eliminates repeating groups. Each row represents one order item. Still has redundancy - next step is 2NF.

All

Second Normal Form (2NF)

intermediate

Eliminate partial dependencies on composite keys

-- VIOLATES 2NF (customer_email depends only on order_id):