Normalisasi Database — 1NF, 2NF, 3NF dalam Satu Kalimat

Normalisasi database bisa diringkas dalam satu kalimat: "Simpan fakta yang sama di satu tempat saja." Cara sistematis untuk melakukannya adalah 1NF → 2NF → 3NF.

Kenapa ini penting? — Kalau informasi yang sama tersebar di banyak baris, begitu Anda mengubah satu saja dan lupa mengubah yang lain, data langsung jadi saling bertentangan. Ini disebut anomali pembaruan. Coba rasakan sendiri di bawah ini.

Kalau laboratorium Prof.A berubah, pada tabel yang belum ternormalisasi Anda harus mengubah 2 baris secara manual. Kalau satu saja terlewat, akan muncul kontradiksi seperti "Prof.A ada di Room 301 sekaligus Room 502". Pada tabel 3NF, cukup ubah 1 baris saja dan selesai.

Itulah inti normalisasi — sisanya hanyalah aturan untuk menentukan "kolom mana harus diletakkan di mana agar hanya disimpan di satu tempat".

Dependensi fungsional — dasar penilaian normalisasi

Normalisasi melihat "kolom ini bergantung pada apa". Ini disebut dependensi fungsional.

Misalnya, student_id → student_name berarti "kalau kita tahu ID mahasiswa, maka namanya bisa ditentukan".

Pada diagram di bawah, perhatikan warna panahnya:

• Hijau = bergantung pada seluruh key (benar)
• Kuning = hanya bergantung pada sebagian key (dependensi parsial → melanggar 2NF)
• Merah putus-putus = bergantung lewat kolom non-key lain (dependensi transitif → melanggar 3NF)

Menghilangkan panah kuning dan merah = memecah tabel = melakukan normalisasi.

Melihat 1NF → 2NF → 3NF sekaligus

Di bawah ini, klik langsung untuk melihat bagaimana tabel dipecah langkah demi langkah. Sel berwarna merah menandakan "kolom ini tidak seharusnya ada di sini".

1NF: satu nilai per sel

Kalau satu sel berisi banyak nilai seperti MATH101, CS102, pencarian jadi sulit dan JOIN juga tidak bisa dilakukan dengan baik.

Aturan: setiap sel harus bersifat atomik (satu nilai saja).

Kolom seperti phone1, phone2, phone3 juga punya masalah yang sama — nilainya hanya disembunyikan di dalam nama kolom.

2NF: hilangkan dependensi parsial

Pada tabel dengan composite key (student_id, course_id), student_name hanya bergantung pada student_id. Artinya, ia tidak bergantung pada seluruh key, melainkan hanya pada sebagian — inilah yang disebut dependensi fungsional parsial.

Aturan: semua kolom non-key harus bergantung pada seluruh key.

Kalau ada dependensi parsial, pindahkan kolom tersebut ke tabel terpisah.

Kalau key-nya hanya satu kolom? Dependensi parsial tidak mungkin terjadi, jadi kalau sudah 1NF maka otomatis juga 2NF.

3NF: hilangkan dependensi transitif

Pada tabel Courses, instructor_office tidak bergantung langsung pada course_id (key). Ia bergantung melalui jalur course_id → instructor_id → instructor_office — artinya kolom non-key bergantung pada kolom non-key lain. Inilah yang disebut dependensi transitif.

Aturan: kolom non-key harus bergantung hanya melalui key. Tidak boleh lewat kolom non-key lain.

Solusi: pisahkan instructor_office ke tabel Instructors.

Bukan hafalan, cukup satu pertanyaan

"Semua atribut non-key harus bergantung pada key, seluruh key, dan hanya key."

Kalimat ini sudah mencakup semuanya:

• key = 1NF (fakta harus bisa diidentifikasi oleh key)
• seluruh key = 2NF (bergantung pada key secara utuh, bukan sebagian)
• hanya key = 3NF (bergantung langsung pada key, bukan lewat kolom non-key)

Kalau di ujian muncul soal normalisasi, cukup ajukan pertanyaan ini: "Kolom ini bergantung pada siapa? Pada seluruh key, sebagian key, atau kolom non-key?"

Kesalahan yang sering terjadi

"Kalau sudah sampai 3NF berarti selesai" — 3NF adalah titik awal yang bagus, bukan akhir. Kadang diperlukan BCNF yang lebih ketat, dan di sisi lain kadang kita sengaja melakukan denormalisasi demi performa.

"Semakin banyak tabel dipecah, semakin bagus" — tujuan normalisasi bukan menambah jumlah tabel, melainkan memastikan "setiap tabel hanya bertanggung jawab pada satu jenis fakta". Kalau dipecah tanpa alasan yang jelas (tanpa hubungan dependensi), JOIN justru jadi makin rumit.

"Kalau pakai NoSQL, normalisasi tidak perlu" — normalisasi memang istilah khusus di DB relasional, tetapi masalah "menjaga konsistensi data yang duplikat" ada di jenis DB apa pun. Bahkan saat melakukan denormalisasi pun, Anda harus tahu "apa yang sedang dikorbankan".

Coba periksa sendiri

Pilih satu tabel dari proyek Anda, lalu:

1. Tulis apa key-nya.
2. Periksa apakah setiap kolom non-key bergantung pada seluruh key, atau hanya pada sebagian. → Kalau hanya sebagian, berarti melanggar 2NF.
3. Periksa apakah ada kolom non-key yang bergantung pada kolom non-key lain. → Kalau ada, berarti melanggar 3NF.

Dengan 3 langkah ini saja, Anda sudah bisa menangkap sebagian besar masalah normalisasi.