Normalisasi — 1NF, 2NF, 3NF, BCNF
Kenapa tabel "satu untuk semua" bermasalah, functional dependency, dan langkah normalisasi dengan contoh KRS.
SlideNormalizationNORMALIZATION Advanced
Normalisasi adalah proses memecah tabel supaya setiap fakta disimpan di satu tempat saja. Tujuannya menghilangkan redundansi dan anomali saat data diubah.
Masalahnya: satu tabel besar
Misalkan semua data KRS disimpan di satu tabel:
| nim | nama | dosen_wali | kode_mk | nama_mk | sks | nilai |
|---|---|---|---|---|---|---|
| 001 | Ayu | Pak Budi | MK302 | Struktur Data | 4 | A |
| 001 | Ayu | Pak Budi | MK303 | Basis Data | 4 | AB |
| 002 | Bima | Bu Sari | MK302 | Struktur Data | 4 | B |
Tiga jenis anomali muncul:
- Update anomaly: nama matkul “Struktur Data” tersimpan berkali-kali. Ganti di satu baris, lupa yang lain, data jadi tidak konsisten.
- Insert anomaly: matkul baru tidak bisa dicatat sebelum ada mahasiswa yang mengambilnya (kolom kunci
nimkosong). - Delete anomaly: kalau Bima satu-satunya mahasiswa Bu Sari dan barisnya dihapus, info bahwa Bu Sari dosen wali ikut hilang.
Functional dependency (FD)
dibaca “X menentukan Y”: jika dua baris punya nilai X sama, nilai Y pasti sama. Dari tabel di atas:
nim → nama, dosen_walikode_mk → nama_mk, sks{nim, kode_mk} → nilai
Candidate key tabel ini adalah {nim, kode_mk}, himpunan atribut minimal yang menentukan semua atribut lain.
Bentuk normal
1NF: setiap sel berisi satu nilai atomik; tidak ada kolom berulang atau list dalam sel (misalnya
matkul = "MK302, MK303").
2NF: sudah 1NF, dan tidak ada partial dependency: atribut non-kunci harus bergantung pada seluruh
candidate key, bukan sebagian. nama hanya bergantung pada nim (sebagian dari kunci), jadi harus dipisah.
3NF: sudah 2NF, dan tidak ada transitive dependency: atribut non-kunci tidak boleh bergantung pada atribut
non-kunci lain. Contoh: jika dosen_wali → no_hp_dosen, maka nim → dosen_wali → no_hp_dosen adalah transitif.
BCNF: untuk setiap FD non-trivial , harus superkey. Lebih ketat dari 3NF; bedanya baru terasa jika ada beberapa candidate key yang saling tumpang tindih.
Hasil dekomposisi
Dekomposisi yang baik harus lossless (tabel asli bisa direkonstruksi persis lewat JOIN) dan sebaiknya dependency preserving (semua FD masih bisa dicek tanpa JOIN). Coba lakukan JOIN-nya di catatan SQL dasar.
Telusuri satu pemisahan tabel
Bayangkan tabel KRS dengan kunci (NIM, kodeMK) dan atribut namaMK. Setiap kodeMK memiliki tepat satu namaMK.
Latihan UTS & UAS
- UTS 2025 · No. 3Periksa dependensi dan bedakan bentuk normal.