---
title: "Normalisation to Third Normal Form"
description: "Splitting tables until every field depends on the key, the whole key, and nothing but the key. Each step removes a way the data could contradict itself after an update."
canonical: https://lightmysky.com/learn/computing/normalisation-to-third-normal-form-mt_cbRXVW6KxX
source: https://lightmysky.com/learn/computing/normalisation-to-third-normal-form-mt_cbRXVW6KxX.md
retrieved: 2026-09-12
---

> **Agent view.** This is the Markdown twin of the page, for tools and assistants.
> When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md
> API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md
> Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt
> Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json
> Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`.

# Normalisation to Third Normal Form

Splitting tables until every field depends on the key, the whole key, and nothing but the key. Each step removes a way the data could contradict itself after an update.

Subject: Computing · Area: Computer Systems · Ages 17 to 18
Page: https://lightmysky.com/learn/computing/normalisation-to-third-normal-form-mt_cbRXVW6KxX

## Ready when they can

- Take an unnormalised table through first, second and third normal form
- Name the update, insert or delete problem that each step removes
- Say when a designer might accept a repeated field on purpose

## Lesson: Split the tables until nothing can disagree

Normalisation is the discipline of splitting tables until every field depends on the key, the whole key, and nothing but the key. Each split kills a way the data could contradict itself after an update. Good design starts by asking what the things are and how they relate.

**Example.** An orders table repeats the customer address on every order. One day an address changes and the update misses a row, so two rows disagree and nobody knows which is right. Move the address into a Customers table and leave only the customer key on each order. That split just killed the update anomaly.

First normal form needs one value per cell, with no repeating groups, so split lists into their own rows. Second normal form needs every non-key field to depend on the whole key, not just part of it. Third normal form needs every field to depend on the key alone, never on another non-key field.

**Tip.** Name the victim of every split: the update problem, the insert problem, or the delete problem. Without a split you cannot add a new product unless you invent a fake order to hang it on, and deleting the last order can wipe out a product entirely. A designer may still repeat a field on purpose for speed, but only knowingly, while guarding it.

**Recap.** Split until every field answers to the key alone, and name the anomaly each split destroys.

## Practice

8 questions on this page, each with its working shown.

## Needs first

- [Relational Databases: Tables, Keys and Relationships](https://lightmysky.com/learn/computing/relational-databases-tables-keys-and-relationships-mt_i7pZV6H902)

## Opens up

- [SQL: Selecting, Filtering and Ordering Rows](https://lightmysky.com/learn/computing/sql-selecting-filtering-and-ordering-rows-mt_lDVVG2AKzs)
- [Functional Dependencies and Boyce-Codd Normal Form](https://lightmysky.com/learn/computing/functional-dependencies-and-boyce-codd-normal-form-mt_PfWLq1aEQz)