Normalisasi 1NF, 2NF, 3NF: Contoh Soal dari Tabel KRS sampai 3NF

Normalisasi database 1NF, 2NF, dan 3NF dikerjakan dengan tiga langkah berurutan: pecah sel yang berisi banyak nilai (1NF), pisahkan atribut yang hanya bergantung pada sebagian kunci komposit (2NF), lalu pisahkan atribut yang bergantung pada atribut bukan kunci (3NF). Kuncinya ada di daftar dependensi fungsional. Kalau daftar itu benar, pemecahan tabelnya hampir mekanis. Contoh soal di bawah memakai satu tabel KRS dan nilai mahasiswa yang dibawa sampai 3NF, dengan isi tabel ditulis di setiap tahap.

#Tabel KRS mentah yang akan dinormalisasi

Bagian akademik sebuah kampus mencatat KRS dan nilai satu semester di satu lembar seperti ini:

Aturan bisnis yang berlaku: satu mata kuliah diampu satu dosen, satu mahasiswa punya satu prodi, dan nilai dicatat per mahasiswa per mata kuliah. Aturan ini penting, karena dependensi fungsional diturunkan dari aturan bisnis, bukan dari data contoh yang kebetulan ada.

#Bagaimana mengubah tabel ke 1NF?

Tabel memenuhi 1NF kalau setiap sel berisi satu nilai (atomik), tidak ada kelompok kolom yang berulang, dan setiap baris bisa dibedakan dengan kunci. Kolom "Mata kuliah yang diambil" melanggar aturan pertama karena satu sel memuat dua mata kuliah sekaligus.

Perbaikannya: satu baris untuk satu mata kuliah yang diambil satu mahasiswa, dan setiap informasi mata kuliah diberi kolom sendiri.

Tiga baris mentah menjadi lima baris. Data memang jadi lebih berulang (nama Rina tertulis dua kali), dan itu wajar. 1NF baru membereskan bentuk sel. Pengulangan dibereskan di 2NF dan 3NF.

#Cara menulis dependensi fungsional dan menentukan kunci

Dependensi fungsional A → B berarti satu nilai A selalu menentukan tepat satu nilai B. Dari aturan bisnis di atas, daftarnya:

1. NIM → NamaMhs, KodeProdi (satu mahasiswa, satu nama, satu prodi)
2. KodeProdi → NamaProdi
3. KodeMK → NamaMK, SKS, KodeDosen (satu mata kuliah, satu dosen pengampu)
4. KodeDosen → NamaDosen
5. NIM, KodeMK → Nilai

Untuk mencari kunci, hitung penutup (closure) dari calon kunci, yaitu semua atribut yang bisa dicapai lewat dependensi di atas.

• Penutup {NIM} = NIM, NamaMhs, KodeProdi, lalu lewat dependensi 2 dapat NamaProdi. KodeMK tidak tercapai, jadi NIM saja bukan kunci.
• Penutup {KodeMK} = KodeMK, NamaMK, SKS, KodeDosen, lalu NamaDosen. NIM tidak tercapai, jadi bukan kunci juga.
• Penutup {NIM, KodeMK} = gabungan keduanya ditambah Nilai lewat dependensi 5. Kesepuluh kolom tercapai.

Kunci primer tabel 1NF adalah kunci komposit (NIM, KodeMK). Kunci ini minimal, karena membuang salah satu kolomnya membuat beberapa atribut tidak tercapai.

#Langkah ke 2NF: memisahkan dependensi parsial

Tabel memenuhi 2NF kalau sudah 1NF dan tidak ada atribut bukan kunci yang bergantung hanya pada sebagian kunci komposit. Kunci kita (NIM, KodeMK), jadi periksa setiap atribut bukan kunci:

Hanya Nilai yang butuh seluruh kunci. Atribut yang bergantung parsial dipindah ke tabel baru bersama penentunya, dan penentu itu tetap tinggal di tabel asal sebagai foreign key.

MAHASISWA (NIM, NamaMhs, KodeProdi, NamaProdi)

MATAKULIAH (KodeMK, NamaMK, SKS, KodeDosen, NamaDosen)

KRS (NIM, KodeMK, Nilai)

Lima baris KRS tetap lima, tetapi Basis Data sekarang hanya tertulis sekali. Tabel MAHASISWA dan MATAKULIAH punya kunci satu kolom, jadi keduanya otomatis lolos 2NF. Pertanyaannya tinggal apakah mereka lolos 3NF.

#Langkah ke 3NF: memisahkan dependensi transitif

Tabel memenuhi 3NF kalau sudah 2NF dan tidak ada dependensi transitif, yaitu atribut bukan kunci yang ditentukan oleh atribut bukan kunci lain. Di hasil 2NF ada dua:

• Di MAHASISWA: NIM → KodeProdi dan KodeProdi → NamaProdi. NamaProdi bergantung ke NIM hanya lewat KodeProdi. Buktinya terlihat di data: "Sistem Informasi" tertulis dua kali.
• Di MATAKULIAH: KodeMK → KodeDosen dan KodeDosen → NamaDosen.

Pisahkan rantai kedua: NamaProdi pindah ke tabel PRODI, NamaDosen pindah ke tabel DOSEN. KodeProdi dan KodeDosen tetap tinggal sebagai foreign key. Hasil akhirnya lima tabel:

Kalau dosenmu meminta DDL, tabel KRS ditulis seperti ini. Bagian REFERENCES adalah yang paling sering lupa:

CREATE TABLE krs (
  nim      CHAR(7)    NOT NULL REFERENCES mahasiswa(nim),
  kode_mk  VARCHAR(6) NOT NULL REFERENCES matakuliah(kode_mk),
  nilai    CHAR(2),
  PRIMARY KEY (nim, kode_mk)
);

Cara cepat memeriksa hasilnya: gabungkan kembali kelima tabel dengan JOIN. Kalau hasilnya persis lima baris tabel 1NF, tanpa baris tambahan dan tanpa yang hilang, pemecahanmu tidak kehilangan informasi. Cara menulis query gabungannya ada di contoh soal SQL JOIN.

#Anomali apa yang hilang setelah normalisasi?

Alasan semua langkah di atas adalah tiga anomali yang ada di tabel 1NF. Ketiganya bisa ditunjukkan dengan data yang sama.

1. Anomali update. SKS Basis Data tertulis di dua baris (Rina dan Andi). Kalau kurikulum mengubahnya menjadi 4 SKS dan hanya satu baris yang diganti, tabel mengatakan Basis Data 3 SKS sekaligus 4 SKS. Di 3NF, SKS hanya ada di satu baris MATAKULIAH.
2. Anomali insert. Prodi menambah mata kuliah IF301 Jaringan Komputer yang belum diambil siapa pun. Di tabel 1NF mata kuliah itu tidak bisa dicatat, karena kunci primernya (NIM, KodeMK) dan NIM tidak boleh kosong. Di 3NF cukup tambahkan satu baris ke MATAKULIAH.
3. Anomali delete. Kalkulus I hanya diambil Andi. Kalau Andi membatalkan Kalkulus I dan barisnya dihapus, ikut hilang juga informasi bahwa MA101 bernilai 3 SKS dan diampu Hadi Prasetyo. Di 3NF yang terhapus hanya satu baris KRS.

Anomali yang sama menimpa Dewi. Kalau satu-satunya baris miliknya dihapus, data bahwa Dewi mahasiswa Sistem Informasi ikut lenyap.

#Kesalahan yang sering terjadi di soal normalisasi

• Mencari dependensi parsial di tabel berkunci tunggal. Dependensi parsial hanya mungkin ada kalau kuncinya komposit. Tabel 1NF yang semua kunci kandidatnya satu kolom otomatis sudah 2NF, jadi jangan memecah MAHASISWA "demi 2NF".
• Memindahkan atribut tanpa meninggalkan penentunya. Kalau NamaProdi dipindah ke PRODI tetapi KodeProdi ikut dihapus dari MAHASISWA, kamu tidak bisa lagi tahu Rina kuliah di prodi apa.
• Lupa menandai foreign key. Di jawaban UTS, garis bawah untuk kunci primer saja tidak cukup. Tandai juga kolom mana merujuk ke tabel mana.
• Menurunkan dependensi dari data contoh. Di data contoh tidak ada dua mahasiswa bernama sama, tetapi itu tidak berarti NamaMhs → NIM. Dependensi berasal dari aturan bisnis.
• Memakai nama sebagai kunci. Dua mahasiswa bisa bernama Dewi Lestari. Pakai NIM atau kode.
• Menulis 3NF dulu sebelum 2NF. Hasil akhirnya mungkin benar, tetapi soal biasanya menilai tabel di setiap tahap.

Normalisasi biasanya berangkat dari tabel mentah. Kalau soalmu berangkat dari diagram, langkahnya berbeda dan dibahas di mengubah ERD ke tabel.

#FAQ

#Apakah tabel 3NF di contoh ini juga sudah BCNF?

Ya. BCNF meminta setiap penentu dalam dependensi fungsional adalah kunci kandidat. Di kelima tabel akhir, penentunya hanya kunci primer masing-masing, jadi syarat itu terpenuhi.

#Bagaimana kalau mahasiswa mengulang mata kuliah yang sama?

Kunci (NIM, KodeMK) tidak cukup lagi, karena Andi bisa punya dua nilai Kalkulus I dari semester berbeda. Tambahkan kolom tahun akademik atau semester ke kunci KRS, misalnya (NIM, KodeMK, TahunAkademik).

#Bagaimana kalau satu mata kuliah diampu lebih dari satu dosen?

Dependensi KodeMK → KodeDosen tidak berlaku lagi, jadi KodeDosen tidak boleh tinggal di MATAKULIAH. Buat tabel penghubung PENGAMPU (KodeMK, KodeDosen) dengan kunci komposit kedua kolom.

#Apakah IPK perlu disimpan sebagai kolom di tabel MAHASISWA?

Di desain 3NF tidak, karena IPK bisa dihitung dari KRS dan SKS di MATAKULIAH. Menyimpannya membuat anomali update baru setiap ada nilai yang berubah. Untuk mengecek hitungan manualnya, pakai kalkulator IPK.

#Apakah semua tabel harus dinormalisasi sampai 3NF?

Untuk tugas kuliah dan sistem transaksi, 3NF adalah target yang umum. Sistem laporan dan gudang data kadang sengaja menyimpan data berulang supaya query lebih cepat, tetapi keputusan itu diambil setelah desain 3NF-nya dipahami, bukan sebagai pengganti.