Normalisasi: Konsep dan Implementasi Sederhana
Memahami 1NF, 2NF, 3NF, dan BCNF melalui studi kasus sistem rekam medis rumah sakit
Pendahuluan
Dalam perancangan basis data, salah satu masalah paling umum yang muncul ketika seluruh data dipaksa masuk ke dalam satu tabel besar adalah anomali data: kegagalan menyimpan data baru (insertion anomaly), inkonsistensi saat memperbarui data (update anomaly), dan hilangnya data penting saat satu baris dihapus (deletion anomaly). Akar masalah ini hampir selalu sama: redundansi, yaitu data yang sama disimpan berulang-ulang di banyak baris.
Normalisasi adalah proses sistematis untuk memecah (dekomposisi) sebuah tabel menjadi beberapa tabel yang lebih kecil, dengan aturan tertentu, sehingga redundansi berkurang dan anomali data dapat dihindari, tanpa kehilangan informasi apa pun dari data aslinya.
Artikel ini membahas empat tingkatan normalisasi yang paling umum dipelajari, yaitu 1NF, 2NF, 3NF, dan BCNF, menggunakan studi kasus yang berkelanjutan: sistem rekam medis rumah sakit.
Studi Kasus: Tabel Awal yang Bermasalah
Bayangkan sebuah rumah sakit awalnya mencatat semua kunjungan pasien dalam satu tabel mentah, di mana tindakan medis yang diambil seorang pasien dicatat sebagai daftar dalam satu sel:
Tabel RAWAT_PASIEN (belum ternormalisasi)
Tabel ini jelas bermasalah: kolom tindakan_diambil menyimpan lebih dari satu nilai dalam satu sel (multivalued attribute). Kalau kita ingin mencari “pasien mana saja yang mengambil TN01”, kita harus memecah string itu secara manual, yang sangat tidak efisien untuk diquery.
1. First Normal Form (1NF)
Syarat: setiap nilai atribut harus bersifat atomic (satu sel = satu nilai), dan tidak boleh ada kelompok nilai berulang dalam satu sel.
Solusi: pecah setiap nilai dalam tindakan_diambil menjadi barisnya sendiri-sendiri.
Tabel rekam_medis_anomali (sudah 1NF)
Primary key-nya adalah kombinasi (no_rm, kode_tindakan), karena satu pasien bisa mengambil banyak tindakan, dan satu tindakan bisa diambil banyak pasien.
Catatan penting:
1NF tidak otomatis menghilangkan redundansi. Perhatikan nama_pasien, nama_tindakan, dan nama_dokter masih berulang di banyak baris — inilah yang nanti dibereskan di tahap 2NF dan 3NF.
2. Second Normal Form (2NF)
Syarat:
• Sudah memenuhi 1NF.
• Tidak ada Partial Dependency — atribut non-kunci harus bergantung penuh pada seluruh kombinasi primary key, bukan hanya sebagian.
Masalah 2NF hanya muncul jika primary key berupa composite key. Karena PK kita adalah (no_rm, kode_tindakan), kita perlu cek ini.
Analisis Ketergantungan Fungsional (FD)
• nama_pasien dan tgl_lahir cukup ditentukan oleh no_rm saja, tidak butuh kode_tindakan.
• nama_tindakan, biaya, dan data dokter cukup ditentukan oleh kode_tindakan saja, tidak butuh no_rm.
• Hanya status_bayar yang benar-benar butuh kombinasi keduanya (status pembayaran spesifik untuk tindakan tertentu dari pasien tertentu).
Solusi: dekomposisi menjadi 3 tabel.
Tabel PASIEN (PK: no_rm)
Tabel TINDAKAN_MEDIS (PK: kode_tindakan)
Tabel REKAM_MEDIS (junction table, PK: no_rm, kode_tindakan)
3. Third Normal Form (3NF)
Syarat:
• Sudah memenuhi 2NF.
Get Shihab ali Mumtaz’s stories in your inbox
Join Medium for free to get updates from this writer.
• Tidak ada Transitive Dependency — atribut non-kunci tidak boleh bergantung pada atribut non-kunci lainnya; harus langsung bergantung ke primary key.
Lihat lagi tabel TINDAKAN_MEDIS hasil 2NF di atas. Ada masalah tersembunyi:
Karena kode_tindakan menentukan kode_dokter, dan kode_dokter menentukan nama_dokter, maka secara tidak langsung nama_dokter bergantung pada kode_tindakan melalui kode_dokter. Inilah yang disebut Transitive Dependency.
Dampaknya jika dibiarkan:
Sama persis dengan anomali yang sudah dibuktikan di praktikum sebelumnya — kalau gelar dr. Wowok berubah, kita harus update di setiap baris TINDAKAN_MEDIS yang memakai DK01, dan rawan terlewat (persis kasus Update Anomaly sebelumnya).
Solusi: pisahkan data dokter ke tabel sendiri.
Tabel DOKTER (PK: kode_dokter)
Tabel TINDAKAN_MEDIS (disesuaikan)
Sekarang nama dokter cukup diubah satu kali saja di tabel DOKTER, dan otomatis berlaku untuk seluruh tindakan yang terkait.
4. Boyce-Codd Normal Form (BCNF)
Syarat:
• Sudah memenuhi 3NF.
• Untuk setiap ketergantungan fungsional X -> Y, X harus berupa Super Key / Candidate Key, tanpa pengecualian.
Bedanya dengan 3NF: 3NF masih “toleran” kalau Y adalah prime attribute (bagian dari candidate key lain). BCNF tidak memberi toleransi itu sama sekali.
Sekarang masukkan aturan bisnis rumah sakit yang lebih spesifik ke tabel REKAM_MEDIS:
• Satu dokter (kode_dokter) hanya menangani satu jenis tindakan tertentu (sesuai spesialisasinya).
• Satu jenis tindakan bisa ditangani oleh beberapa dokter berbeda (tergantung shift/jadwal).
Perhatikan data real kita: DK01 selalu menangani TN01, DK02 selalu TN02, DK03 selalu TN03, konsisten di setiap baris. Kalau kita tambahkan kode_dokter ke tabel REKAM_MEDIS untuk mencatat siapa yang menangani kunjungan itu:
Tabel REKAM_MEDIS (PK: no_rm, kode_tindakan)
Muncul FD baru: kode_dokter -> kode_tindakan. Tapi kode_dokter bukan candidate key dari tabel ini (PK-nya no_rm + kode_tindakan), padahal dia menentukan sebagian dari primary key (kode_tindakan). Ini melanggar BCNF.
Dampaknya jika dibiarkan:
Informasi “DK01 menangani TN01” ditulis berulang setiap ada pasien baru. Dokter baru yang ditugaskan menangani tindakan baru tidak bisa dicatat sebelum ada pasien yang mengambil tindakan tersebut (Insertion Anomaly). Kalau semua pasien yang ditangani DK01 dihapus, catatan “DK01 menangani TN01” ikut hilang total (Deletion Anomaly).
Solusi: pisahkan FD kode_dokter -> kode_tindakan ke tabel tersendiri.
Tabel DOKTER_TINDAKAN (PK: kode_dokter)
Tabel REKAM_MEDIS (disesuaikan — kode_tindakan dihapus)
Skema Akhir (Hasil 1NF -> BCNF)
Setelah melalui seluruh rangkaian normalisasi, kita memperoleh 5 tabel yang efisien dan bebas anomali:
PASIEN (no_rm PK, nama_pasien, tgl_lahir)
DOKTER (kode_dokter PK, nama_dokter)
TINDAKAN_MEDIS (kode_tindakan PK, nama_tindakan, biaya, kode_dokter FK)
DOKTER_TINDAKAN (kode_dokter PK FK, kode_tindakan FK)
REKAM_MEDIS (no_rm PK FK, kode_dokter PK FK, status_bayar)
Relasinya: PASIEN (1 — N) REKAM_MEDIS (N — 1) DOKTER_TINDAKAN (1–1) DOKTER, dan DOKTER_TINDAKAN (N — 1) TINDAKAN_MEDIS.
Ringkasan Perbedaan Tiap Tahap
Kesimpulan
Normalisasi bukan sekadar aturan akademis, melainkan metode sistematis untuk mendeteksi di mana redundansi bersembunyi dalam sebuah tabel, lalu membereskannya satu per satu: dari nilai yang tidak atomic (1NF), ketergantungan parsial pada kunci gabungan (2NF), ketergantungan tidak langsung antar kolom biasa (3NF), hingga pelanggaran paling ketat di mana determinan bukan candidate key (BCNF). Studi kasus rumah sakit ini membuktikan bahwa tabel rekam_medis_anomali yang sebelumnya rawan Insertion, Update, dan Deletion Anomaly, kini sepenuhnya aman setelah melalui keempat tahap normalisasi ini.
