Video summary

1st, 2nd and 3rd Normal Form (Database Normalisation)

Main summary

Key takeaways

Educational

Main ideas / lessons: Database Normalisation (1NF, 2NF, 3NF)

The video presents a beginner guide to database normalisation, explaining how to structure tables to remove redundancy and prevent update anomalies by applying:

  • First Normal Form (1NF)
  • Second Normal Form (2NF)
  • Third Normal Form (3NF)

Methodology / step-by-step rules

First Normal Form (1NF)

A table is in 1NF if:

  • Uniqueness of rows

    • Each row must be unique
    • There must be no duplicate rows (no two rows contain identical data across all columns)
    • Fix when needed by adding an identifier (e.g., Order ID) so rows become distinguishable

  • Single (atomic) values per cell

    • Each cell must contain only one value
    • No lists / multiple items in one cell
    • Fix when needed by moving repeating/multi-item fields into a separate table (e.g., one row per order item)

  • Atomic (non-divisible) values

    • Each value must be atomic / non-divisible
    • Avoid composite values inside a single column (example: “Bob Jones” should be split into First Name and Last Name)

Examples used:

  • Takeaway orders table

    • Problem: duplicate-looking rows because the same customer and the same items appear
    • Fix: add an Order ID

  • Orders table

    • Problem: a single cell contains multiple items (e.g., burger, fries, coke)
    • Fix: create an order items table with one item per row, linked by Order ID

  • Customer table

    • Problem: “Customer name” is composite
    • Fix: split into first name and last name

Second Normal Form (2NF)

A table is in 2NF if:

  • It is already in 1NF (2NF assumes you’ve satisfied 1NF first)
  • No partial dependencies
    • For a table with a composite candidate key (e.g., Student ID + Course ID):
      • Every non-prime attribute must depend on the whole candidate key
      • Non-prime attributes must not depend on only part of the composite key

Example used:

  • Students/Courses enrolment
    • Composite key: (Student ID, Course ID)
    • Problem: Course fee depends only on Course ID, not on Student ID
    • Result: partial dependency (course fee is determined by only part of the composite key)
    • Fix:
      • Split the schema into two tables:
        • CourseFees: Course ID → Course Fee
        • StudentCourses: Student ID + Course ID (without course fee)

Third Normal Form (3NF)

A table is in 3NF if:

  • It is already in 2NF (therefore also in 1NF)
  • No transitive dependencies
    • All fields must be determinable only from the primary/composite key
    • You cannot determine a non-key field using another non-key attribute/key
    • In other words: non-key columns shouldn’t depend on other non-key columns indirectly

Example used:

  • Tournament data (from Wikipedia)
    • Fields include: tournament name, year, winner, winner’s date of birth
    • Problem (transitive dependency):
      • Winner’s date of birth can be found from Winner name
      • Therefore, it’s not determined solely by (tournament name, year)
    • Fix:
      • Split into separate tables:
        • TournamentWinners: (Tournament Name, Year) → Winner
        • Winners: Winner → Winner Date of Birth
    • Why this works:
      • Winner depends on tournament name + year
      • Date of birth depends on winner identity

Conclusion (as conveyed)

  • 1NF removes:

    • duplicate rows
    • multi-value cells
    • non-atomic values

  • 2NF removes:

    • partial dependencies in composite-key tables

  • 3NF removes:

    • transitive dependencies by ensuring non-key attributes depend only on the key

Speakers / sources featured

  • Speaker: Not explicitly named (the presenter guiding through the concepts)
  • Source referenced: Wikipedia (used for the tournament/winner example)

Original video