Database Normalisation Explained

Updated 2026-08-13

Quick Answer

Database normalisation is the process of organising a relational schema to reduce redundancy and prevent update, insertion, and deletion anomalies. It works through a series of normal forms — 1NF removes repeating groups, 2NF removes partial dependencies, 3NF removes transitive dependencies, and BCNF tightens 3NF — each building on the last so every fact is stored in exactly one place.

Normalisation is the part of database design that most often decides an assignment mark, and it's conceptual rather than mechanical: it's about arranging a schema so that every fact lives in exactly one place. Get it right and the database stays consistent as data changes; get it wrong and the same information ends up duplicated across rows, where it can be updated in one and missed in another. Those failures have names — update, insertion, and deletion anomalies — and normalisation is the systematic process of designing them out.

Why normalise: the anomalies

  • Update anomaly: the same fact is stored in many rows, so changing it means changing every copy — miss one and the data contradicts itself.
  • Insertion anomaly: you can't record one piece of data without also having unrelated data (e.g. can't add a course with no enrolled student).
  • Deletion anomaly: deleting a row for one reason also destroys data you wanted to keep.

Normalisation removes these by splitting data into well-structured tables linked by keys.

The normal forms

First normal form (1NF). Every value is atomic and there are no repeating groups — no comma-separated lists in a cell, no phone1, phone2, phone3 columns.

Second normal form (2NF). In 1NF and every non-key attribute depends on the whole primary key, not just part of a composite key. This removes partial dependencies.

Third normal form (3NF). In 2NF and no non-key attribute depends on another non-key attribute. This removes transitive dependencies — for example, storing a supplier's city because you stored the supplier, when city really belongs in a supplier table.

Boyce–Codd normal form (BCNF). A stricter version of 3NF that handles certain edge cases where a candidate key is involved.

Each form builds on the previous one, so you reach 3NF by passing through 1NF and 2NF.

A quick example

A single Orders table holding customer name, customer address, product name, and product price repeats the customer's address on every order and the product's price on every sale. Splitting it into Customers, Products, and Orders (linked by keys) means each address and each price is stored once — the essence of normalisation.

How far to go

Most designs target 3NF (or BCNF), which removes the common anomalies while keeping queries manageable. Real systems sometimes denormalise deliberately for read performance — a valid trade-off you should be able to justify, not a shortcut.

Related help

For the design skill in full, see Database Assignment Help; for querying your normalised schema, SQL Assignment Help; for the wider discipline, computer science and the database subject page.

Frequently Asked Questions

It's organising your tables so each piece of information is stored once, in the right place. This stops the same fact appearing in multiple rows where it could be updated in one place and not another — the cause of data becoming inconsistent.

First normal form (1NF) requires atomic values and no repeating groups. Second normal form (2NF) removes partial dependencies on part of a composite key. Third normal form (3NF) removes transitive dependencies, where a non-key attribute depends on another non-key attribute.

They're the problems normalisation prevents: an update anomaly is having to change the same fact in many rows; an insertion anomaly is being unable to add data without unrelated data; a deletion anomaly is losing wanted data when you delete a row for another reason.

Most academic and practical designs aim for 3NF (or BCNF), which removes the common anomalies while keeping the schema workable. Over-normalising can hurt read performance, which is why real systems sometimes denormalise deliberately.