SQL Playground
TutorialsPlayground
SQL FormatterSQL MinifierSyntax ValidatorJSON to SQLCSV to SQLSQL to JSONER Diagram Generator
Daily ChallengeInterviewsCheat SheetBlog

© 2026 SQL Playground. Built for developers.

PrivacyTermsAboutRSS Feed
SQL Playground
TutorialsPlayground
SQL FormatterSQL MinifierSyntax ValidatorJSON to SQLCSV to SQLSQL to JSONER Diagram Generator
Daily ChallengeInterviewsCheat SheetBlog
Back to Blog
2025-12-07
5 min read

Database Normalization Explained: 1NF, 2NF, 3NF

database-designnormalizationsql-basicsschema

Let's be honest: "Database Normalization" sounds like something a robot would say before taking over the world. 🤖

But in reality? It's just a fancy word for organizing your stuff so it doesn't become a dumpster fire.

Imagine you have a messy music playlist. You've got songs, artists, albums, and genres all jumbled together. If you want to change an artist's name, you have to find every single song they ever wrote and update it. Nightmare, right?

That's an un-normalized database.

Today, we're going to fix a messy "Music Library" database using the three magical steps of normalization: 1NF, 2NF, and 3NF.

The Messy Starting Point (Un-normalized)

Here is our disaster of a table. We're storing everything in one giant bucket called playlist_messy.

SongArtistGenresAlbumAlbum Year
"Bohemian Rhapsody"QueenRock, OperaA Night at the Opera1975
"Bad Guy"Billie EilishPop, ElectronicWhen We All Fall Asleep2019

See the problem? The Genres column has multiple values ("Rock, Opera"). This is a big no-no.

Step 1: First Normal Form (1NF) - The "One Thing Per Cell" Rule

The Rule: Every cell must hold a single value. No lists, no arrays, no comma-separated chaos.

To fix our playlist, we need to break those multiple genres into separate rows.

Interactive SQL
Loading...

Status: We are in 1NF. But wait... we are repeating a LOT of data. "Queen", "A Night at the Opera", and "1975" are written twice just because the song has two genres.

Step 2: Second Normal Form (2NF) - The "Whole Key" Rule

The Rule: Non-key columns must depend on the entire Primary Key, not just part of it.

In our 1NF table, the Primary Key is effectively (Song + Genre).

  • Does Artist depend on the specific Genre? No, it depends on the Song.
  • Does Album depend on the Genre? No, it depends on the Song.

These are called Partial Dependencies. We need to move them to their own table.

Let's split this into two tables: songs and song_genres.

Interactive SQL
Loading...

Status: We are in 2NF. Much better! But look at the songs_2nf table. We have album and album_year. If we have 10 songs from the same album, we repeat the album_year 10 times.

Step 3: Third Normal Form (3NF) - The "Nothing but the Key" Rule

The Rule: Columns should depend only on the Primary Key, not on other non-key columns.

In songs_2nf:

  • song_id -> album (Makes sense, a song belongs to an album)
  • album -> album_year (Wait, the year belongs to the album, not directly to the song!)

This is a Transitive Dependency. The year depends on the album, which depends on the song.

To reach 3NF, we need to move Album details to their own table.

Interactive SQL
Loading...

Summary: The Normalization Cheat Sheet

  1. 1NF (The "Atomic" Rule): One value per cell. No lists.
  2. 2NF (The "Whole Key" Rule): Move data that doesn't depend on the whole key to a new table.
  3. 3NF (The "Direct" Rule): Move data that depends on other non-key columns to a new table.

Normalization isn't just about following rules; it's about making your data logical and easy to maintain. Now go forth and organize your data like a pro! 🧹✨

Share this article:

Comments

© 2026 SQL Playground. Built for developers.

PrivacyTermsAboutRSS Feed