Course Database Design

Normalisation

Modelling & Normalisation Preview

Why normalise

A normalised database stores each fact once. That kills a whole class of bugs: wrong prices, orphaned records, inconsistent data.

The rules (simplified)

FormRule
1NFOne value per cell, a primary key
2NF1NF + no partial dependency (non-key depends on part of the key)
3NF2NF + no transitive dependency (non-key depends on another non-key)

A bad design

ORDER_ROW\n├─ order_id\n├─ customer_name\n├─ customer_city\n├─ product_name\n├─ product_price\n├─ qty\n├─ product_discount

The problems

  • customer_city repeated on every order (update anomaly)
  • Deleting the order deletes the customer info
  • product_price can change per order row inconsistently

The normalised version

CUSTOMER (id, name, city)\nPRODUCT  (id, name, price)\nDISCOUNT (product_id, discount_pct)\nORDER    (id, customer_id, created_at)\nORDER_ITEM (order_id, product_id, qty)

Test your tables

1. Every column holds one value?   → 1NF\n2. Every column depends on the whole PK? → 2NF\n3. Columns depend only on the PK?   → 3NF
Tip: If a column is the same for many rows and driven by another column, move it to its own table. Normalisation is mostly that.

This is a free preview lesson

Enroll in the Database Design to unlock every lesson, lesson PDF guides, quizzes and your certificate - and start creating your own pieces today.


Discussion

Free preview lesson