Normalisation · Normalisasi
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.
Mengapa normalisasi?
Bayangkan menyimpan setiap pemesanan klub dalam satu tabel, dengan nama pelatih berulang di setiap baris: setiap pemesanan Chess club akan membawa "Mr Ng" berulang-ulang.
Pengulangan itu menyebabkan masalah. Jika Mr Ng keluar, Anda harus memperbarui banyak baris; jika melewatkan satu, data menjadi tidak konsisten. Normalisasi mengatur tabel untuk menghilangkan redundansi semacam itu.
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.
Bentuk-bentuk normal
Anda menormalisasi secara bertahap:
- 1NF — setiap sel berisi satu nilai (tidak ada daftar atau kelompok berulang), dan tabel memiliki primary key.
- 2NF — sudah 1NF, dan tidak ada kolom non-kunci yang bergantung hanya pada sebagian dari composite key (kunci gabungan).
- 3NF — sudah 2NF, dan tidak ada kolom non-kunci yang bergantung pada kolom non-kunci lainnya (tidak ada transitive dependency / ketergantungan transitif).
Pada versi tabel tunggal, coach bergantung pada club, bukan pada pemesanan — sebuah transitive dependency, sehingga tidak memenuhi 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 keyclub_id.
Now a coach is stored once. A JOIN puts the information back together whenever you need it — write that join below.
Desain yang ternormalisasi
Kami memecah data menjadi dua tabel (yang dimuat di sini):
club(club_id, name, coach)— setiap klub dan pelatihnya, disimpan sekali.booking(booking_id, student, club_id)— setiap pemesanan, dihubungkan melalui foreign keyclub_id.
Sekarang sebuah pelatih disimpan sekali. A JOIN menyusun kembali informasi tersebut setiap kali Anda membutuhkannya — tuliskan penggabungan itu di bawah ini.
Common mistakes
- Split repeating groups into their own table instead of many similar columns.
- Each table should describe one kind of thing.
Kesalahan Umum
- Pisahkan kelompok berulang ke dalam tabel tersendiri alih-alih banyak kolom yang mirip.
- Setiap tabel harus menggambarkan satu jenis hal.
Reassemble the data: list each booking's student next to their club's coach, by joining booking to club on club_id, ordered by booking.booking_id. · Reassemble data: daftarkan setiap booking's student di samping club's coach, dengan joining booking ke club pada club_id, diurutkan oleh booking.booking_id.
Click Run to see the output here. · Klik Jalankan untuk melihat output di sini.
The split tables still answer questions together. Count how many bookings each club has: join booking to club, show club.name and COUNT(*) AS bookings, group by the club, and order by club.name. · Tabel split masih menjawab pertanyaan bersama. Hitung berapa banyak booking setiap club memiliki: join booking ke club, tampilkan club.name dan COUNT(*) AS bookings, group by club, dan order by club.name.
Click Run to see the output here. · Klik Jalankan untuk melihat output di sini.