📄 Paper 2 · 4.10 Databases
4.10.4 Database Design & Normalisation (1NF–3NF)
AQA 7517 · A-Level Computer Science · ~15 min read

Why Normalise?

Normalisation is the process of organising a database to:

  • Eliminate data redundancy (repeated data)
  • Remove update, insertion, and deletion anomalies
  • Ensure data integrity and efficient storage

It is done through a series of normal forms (NF). AQA 7517 requires knowledge of 1NF, 2NF, and 3NF.

Unnormalised Form (UNF)

Raw data with no normalisation — may have repeating groups, multiple values in cells, and no clear primary key.

Example UNF table:

OrderIDCustomerNameCustomerAddressProducts
101Ali Hassan12 Main StPen, Ruler, Book
102Ali Hassan12 Main StPen

Problems: Products has multiple values; CustomerName and CustomerAddress are repeated.

1st Normal Form (1NF)

1NF Rules
✓ All values are atomic (no repeating groups or multi-valued cells)
✓ Each column contains only one type of data
✓ Each row is unique (has a primary key)
Fix: split "Pen, Ruler, Book" into separate rows. Add ProductName as part of composite key.
OrderIDProductNameCustomerNameCustomerAddress
101PenAli Hassan12 Main St
101RulerAli Hassan12 Main St
101BookAli Hassan12 Main St
102PenAli Hassan12 Main St

PK: OrderID + ProductName (composite). Problem remains: CustomerName and CustomerAddress are repeated for every product in the same order.

2nd Normal Form (2NF)

2NF Rules
✓ Must be in 1NF
✓ No partial dependencies — every non-key attribute must depend on the whole primary key, not just part of it
Fix: CustomerName/CustomerAddress depend only on OrderID, not on ProductName. Split into separate tables.

Result tables in 2NF:

  • Order(OrderID PK, CustomerID FK)
  • Customer(CustomerID PK, CustomerName, CustomerAddress)
  • OrderLine(OrderID FK, ProductName — composite PK)

3rd Normal Form (3NF)

3NF Rules
✓ Must be in 2NF
✓ No transitive dependencies — non-key attributes must depend only on the primary key, not on other non-key attributes
Example: if Order table has CustomerID PK, CustomerName, CustomerPostcode → CustomerName depends on CustomerID ✓, but PostcodeTown depends on CustomerPostcode (not CustomerID) → transitive dependency.

Fix: extract PostcodeTown into a Postcode table. Each non-key attribute must depend directly on the PK only.

Summary of Normal Forms

FormRequirement
UNFRaw data — no structure
1NFAtomic values, unique rows (PK), no repeating groups
2NF1NF + no partial dependencies (all non-key attrs depend on whole PK)
3NF2NF + no transitive dependencies (non-key attrs depend only on PK, not on other non-key attrs)
Exam tip: AQA 7517 normalisation questions often give you a table in UNF or 1NF and ask you to normalise to 3NF. Remember: 2NF removes partial dependencies (only relevant if composite PK). 3NF removes transitive dependencies (A → B → C, where C doesn't directly depend on A). Normalisation to 3NF = no redundancy, no anomalies. You may need to draw resulting tables with PKs and FKs marked.
Click through the slides at your own pace. Use arrow keys or click to advance.
Click slide or press arrow keys to navigate

Worksheet — 4.10.4 Normalisation

8 questions · instantly marked · AQA 7517 standard

Q1Explain what normalisation is and state two benefits of normalising a database to 3NF.[2]
✅ Mark scheme
Mark scheme
Normalisation: process of structuring a relational database to remove redundancy and improve data integrity [1]; done through a series of normal forms (1NF → 2NF → 3NF) [1]. Benefits (any 2): eliminates data redundancy — same data not stored multiple times [1]; removes update/insertion/deletion anomalies [1]; easier to maintain and update — change in one place [1]; improves query efficiency [1].
Q2State the three requirements for a table to be in First Normal Form (1NF).[2]
✅ Mark scheme
Mark scheme
All values are atomic (no repeating groups or multi-valued cells — one value per cell) [1]; all values in a column are the same data type [1]; each row is unique, identified by a primary key [1].
Q3Explain what a partial dependency is. Why is 2NF only relevant when a composite key exists?[2]
✅ Mark scheme
Mark scheme
Partial dependency: a non-key attribute depends on only part of a composite primary key, not the whole key [1]. Example: in OrderLine(OrderID, ProductID, CustomerName), CustomerName depends only on OrderID — not on ProductID [1]. 2NF only applies with composite keys because: with a single-column PK, a non-key attribute either depends on the whole PK (the only option) or is independent — there is no 'part' to partially depend on [1]; therefore a table in 1NF with a single-column PK is automatically in 2NF [1].
Q4Explain what a transitive dependency is and give an example. How is it resolved?[3]
✅ Mark scheme
Mark scheme
Transitive dependency: a non-key attribute depends on another non-key attribute (not directly on the PK) [1]. Example: in Employee(EmpID PK, EmpName, DeptID, DeptName) — DeptName depends on DeptID, not EmpID [1]; this is a transitive dependency: EmpID → DeptID → DeptName [1]. Resolution: extract DeptID and DeptName into a separate Department table; Employee keeps DeptID as a FK [1].
Q5A table has: OrderID, CustomerID, CustomerName, CustomerEmail, ProductID, Quantity. The PK is OrderID + ProductID. Identify any partial dependencies.[3]
✅ Mark scheme
Mark scheme
Partial dependencies: CustomerID, CustomerName, and CustomerEmail all depend only on OrderID — not on ProductID [1]; they are partially dependent on the composite PK [1]. Quantity depends on the whole composite PK (OrderID + ProductID — how much of a product was ordered) [1]; fix: move CustomerID, CustomerName, CustomerEmail to a separate Order/Customer table; keep OrderLine(OrderID, ProductID, Quantity) [1].
Q6Describe the difference between 2NF and 3NF in terms of which dependencies each removes.[3]
✅ Mark scheme
Mark scheme
2NF removes partial dependencies: non-key attributes depending on only part of a composite PK [1]; ensures every non-key attribute depends on the whole PK [1]. 3NF removes transitive dependencies: non-key attributes depending on other non-key attributes rather than the PK directly [1]; ensures every non-key attribute depends only on the PK — not on any other non-key column [1].
Q7What is meant by an unnormalised form (UNF) table? Give two characteristics.[2]
✅ Mark scheme
Mark scheme
UNF: raw, unstructured data with no normalisation applied [1]. Characteristics (any 2): cells may contain multiple values (e.g. a comma-separated list) [1]; repeating groups of data [1]; may have no clear primary key [1]; significant data redundancy [1].
Q8Normalise the following to 3NF. Table: Booking(BookingID PK, StudentID, StudentName, CourseID, CourseName, TeacherID, TeacherName). State the resulting tables.[3]
✅ Mark scheme
Mark scheme
1NF: already atomic with single PK [1]. 2NF: no composite PK so no partial dependencies — already in 2NF [1]. 3NF: identify transitive dependencies. StudentName → depends on StudentID (not BookingID directly) [1]; CourseName → depends on CourseID [1]; TeacherName → depends on TeacherID [1]. Result tables: Booking(BookingID PK, StudentID FK, CourseID FK) [1]; Student(StudentID PK, StudentName); Course(CourseID PK, CourseName, TeacherID FK); Teacher(TeacherID PK, TeacherName) [1].
Normalisation Quiz
Question 1 of 15
You scored
out of 15
Card 1 of 8
Click to reveal definition
🎉
All cards reviewed!
TermDefinition
🎯

Mini Test — Normalisation

10 questions · 10 minutes

← 4.10.3 SQL
66 of 70 · AQA 7517
4.10.5 Transactions →