Why normalise?

Imagine storing every club booking in one table, with the coach repeated on every row: each booking of the Chess club would carry "Mr Ng" again and again.

That repetition causes problems. If Mr Ng leaves, you must update many rows; miss one and the data becomes inconsistent. Normalisation organises tables to remove this kind of redundancy.

The normal forms

You normalise in steps:

• 1NF — every cell holds a single value (no lists or repeating groups), and the table has a primary key.
• 2NF — already 1NF, and no non-key column depends on only part of a composite key.
• 3NF — already 2NF, and no non-key column depends on another non-key column (no transitive dependency).

In the one-table version, coach depends on the club, not on the booking — a transitive dependency, so it is not in 3NF.

The normalised design

We split the data into two tables (the ones loaded here):

• club(club_id, name, coach) — each club and its coach, stored once.
• booking(booking_id, student, club_id) — each booking, linked by the foreign key club_id.

Now a coach is stored once. A JOIN puts the information back together whenever you need it — write that join below.

Common mistakes

• Split repeating groups into their own table instead of many similar columns.
• Each table should describe one kind of thing.