Normalisasi 3NF Basis Data

📚 Basis Data — D3 RMIK Semester 4

Normalisasi 3NF & Penerapannya:
Bye-bye Ketergantungan Transitif!

Eliminasi ketergantungan transitif, studi kasus data kunjungan pasien dengan kode ICD-10, sampai cara validasi hasil normalisasi — dikupas tuntas dengan analogi nyata dan contoh yang langsung bisa kamu praktekin di lab.

3NF

Target Normal Form

ICD-10

Studi Kasus

~12 mnt

Baca Artikel

5

Tabel Hasil Akhir

#Normalisasi3NF #BasisData #ICD10 #KunjunganPasien #RMIK #TransitiveDependency

Kamu sudah lolos dari 1NF dan 2NF — selamat! Tapi cerita belum selesai. Ada satu musuh tersembunyi yang masih bisa merusak database kamu tanpa terlihat jelas: ketergantungan transitif. Ibarat grup chat yang sudah rapi anggotanya, tapi ternyata ada satu orang yang selalu forward info dari orang lain — redundansi tetap terjadi!

Normalisasi 3NF (Third Normal Form) hadir untuk membereskan persoalan itu. Di artikel ini kita akan bongkar tuntas konsep 3NF — mulai dari definisi formal, studi kasus nyata menggunakan data kunjungan pasien dengan kode ICD-10, hingga cara memvalidasi bahwa normalisasi kamu sudah benar. Ini bukan sekadar teori — ini skill yang kamu butuhkan untuk merancang sistem rekam medis elektronik (RME) yang solid. ^[1]

💡

Fakta Menarik

ICD-10 (International Classification of Diseases, 10th Revision) adalah standar WHO yang berisi lebih dari 14.400 kode diagnosa. Di Indonesia, penggunaannya diwajibkan oleh BPJS Kesehatan sejak 2014. Salah desain tabel ICD-10 di database-mu? Siap-siap update ribuan baris data! ^[2]

Kilasan Balik: Dari 2NF Menuju 3NF

Sebelum masuk ke 3NF, kita perlu paham posisi kita. Ingat perjalanan normalisasi seperti naik tangga: kamu tidak bisa loncat ke lantai 3 tanpa lewati lantai 2.

🪜 Tangga Normalisasi Basis Data

UNF — Unnormalized Form Nilai berulang, tidak atomik

1NF Nilai atomik, no repeating groups

2NF No partial dependency

3NF ← Kita di sini! 🎯 No transitive dependency

Untuk sebagian besar sistem informasi kesehatan, normalisasi hingga 3NF sudah sangat cukup dan direkomendasikan. ^[3]

Apa Itu 3NF? Definisi & Syarat Formal

Menurut Elmasri & Navathe dalam Fundamentals of Database Systems ^[3], sebuah relasi berada dalam Third Normal Form (3NF) jika:

📐 Definisi Formal 3NF

1️⃣

Sudah 2NF

+

🚫

Tidak Ada Ketergantungan Transitif terhadap Primary Key

=

✅

3NF

Definisi lebih presisi: Untuk setiap functional dependency X → Y dalam relasi R, minimal salah satu kondisi ini harus terpenuhi: (a) X adalah superkey dari R, atau (b) Y adalah atribut prima (bagian dari candidate key). ^[3]

Apa Itu Ketergantungan Transitif?

Ketergantungan transitif terjadi ketika atribut non-key bergantung pada atribut non-key lain — bukan langsung ke primary key. Pola ini:

🔍 Pola Ketergantungan Transitif

PK → A Primary Key menentukan A (ini bagus ✓)

A → B A menentukan B — A & B sama-sama non-key!

PK → A → B ← INI MASALAHNYA! B bergantung transitif ke PK via A ❌

🎭 Analogi Kehidupan Nyata

Bayangkan kamu tahu NIM seseorang (PK) → kamu bisa tahu nama prodinya (A). Dan dari nama prodi (A) → kamu bisa tahu nama dekannya (B).

Jadi NIM → Prodi → Dekan. Nama Dekan bergantung transitif ke NIM lewat Prodi. Seharusnya data Dekan disimpan di tabel Prodi, bukan di tabel Mahasiswa! Kalau dekan ganti, kamu update ratusan baris mahasiswa? Nggak masuk akal, kan?

Studi Kasus Nyata: Data Kunjungan Pasien & Kode ICD-10

Ini bagian paling seru — kita akan pakai konteks yang langsung relevan dengan pekerjaan kamu sebagai tenaga RMIK! Perhatikan tabel berikut yang sudah melewati 2NF tapi belum 3NF:

📋 Tabel KUNJUNGAN (Sudah 2NF, Belum 3NF)

🔑 ID_Kunjungan	ID_Pasien	Tgl_Kunjungan	ID_Dokter	Kode_ICD10 ⚠️	Nama_Diagnosa ⚠️	Kategori_ICD ⚠️	Bab_ICD ⚠️
KNJ-001	P-01	2025-01-10	DR-01	J06.9	ISPA	Infeksi Saluran Nafas	Bab X - Pernafasan
KNJ-002	P-02	2025-01-11	DR-02	A09	Diare	Infeksi Pencernaan	Bab I - Infeksi
KNJ-003	P-01	2025-02-03	DR-01	J06.9	ISPA	Infeksi Saluran Nafas	Bab X - Pernafasan
KNJ-004	P-03	2025-02-05	DR-03	E11	Diabetes Mellitus Tipe 2	Ggn. Endokrin & Metabolik	Bab IV - Endokrin

⚠️ Sel merah & kuning = ketergantungan transitif. Nama_Diagnosa, Kategori_ICD, dan Bab_ICD semuanya bergantung ke Kode_ICD10, bukan ke ID_Kunjungan!

Identifikasi Ketergantungan Transitif

🔍 Analisis Functional Dependency — Tabel KUNJUNGAN

ID_Kunjungan → ID_Pasien, Tgl_Kunjungan, ID_Dokter, Kode_ICD10 ✅ Langsung ke PK — ini normal & benar

Kode_ICD10 → Nama_Diagnosa, Kategori_ICD, Bab_ICD ❌ Kode_ICD10 adalah non-key! Ini ketergantungan transitif.

ID_Kunjungan → Kode_ICD10 → Nama_Diagnosa, Kategori_ICD, Bab_ICD ❌ Transitif chain — inilah yang harus dihilangkan di 3NF!

Kesimpulan: Nama_Diagnosa, Kategori_ICD, dan Bab_ICD seharusnya disimpan di tabel ICD-10 tersendiri, bukan di tabel KUNJUNGAN. Data ICD-10 adalah entitas mandiri!

🧠

Insight Penting — Kenapa ICD-10 Harus Tabel Sendiri?

WHO merilis pembaruan ICD-10 secara berkala. Kalau nama diagnosa atau kategorisasi berubah, dan data ICD-10 tersebar di tabel kunjungan — kamu harus update ribuan baris sekaligus. Ini update anomaly yang bisa merusak integritas data rekam medis elektronik yang sudah tersertifikasi! ^[2]

Dengan tabel ICD-10 terpisah, cukup update satu baris di satu tempat — dan seluruh sistem langsung konsisten. Itulah kekuatan 3NF!

Solusi 3NF: Pisahkan ke Tabel ICD-10

Langkah solusinya jelas: pindahkan semua atribut yang bergantung pada Kode_ICD10 ke tabel baru, lalu hubungkan via foreign key.

🔧 Langkah Dekomposisi ke 3NF

1

Identifikasi ketergantungan transitif

Temukan semua X → Y di mana X bukan superkey. Di sini: Kode_ICD10 → Nama_Diagnosa, Kategori_ICD, Bab_ICD.

2

Buat tabel baru untuk determinan

Jadikan Kode_ICD10 sebagai primary key di tabel baru: MASTER_ICD10.

3

Pindahkan atribut yang bergantung

Nama_Diagnosa, Kategori_ICD, dan Bab_ICD dipindah ke tabel MASTER_ICD10.

4

Sisakan foreign key di tabel asal

Tabel KUNJUNGAN tetap menyimpan Kode_ICD10 sebagai FK yang mereferensi MASTER_ICD10.

✅ Tabel KUNJUNGAN (3NF) PK: ID_Kunjungan | FK: ID_Pasien, ID_Dokter, Kode_ICD10

🔑 ID_Kunjungan	ID_Pasien	Tgl_Kunjungan	ID_Dokter	🔗 Kode_ICD10 (FK)
KNJ-001	P-01	2025-01-10	DR-01	J06.9
KNJ-002	P-02	2025-01-11	DR-02	A09
KNJ-003	P-01	2025-02-03	DR-01	J06.9
KNJ-004	P-03	2025-02-05	DR-03	E11

✅ Bersih! Semua atribut bergantung langsung ke ID_Kunjungan. Kode_ICD10 hanya sebagai FK penghubung.

✅ Tabel MASTER_ICD10 (Tabel Baru — Hasil 3NF) PK: Kode_ICD10

🔑 Kode_ICD10	Nama_Diagnosa	Kategori_ICD	Bab_ICD
A09	Diare	Infeksi Pencernaan	Bab I - Infeksi
E11	Diabetes Mellitus Tipe 2	Ggn. Endokrin & Metabolik	Bab IV - Endokrin
J06.9	ISPA	Infeksi Saluran Nafas	Bab X - Pernafasan

✅ Data ICD-10 kini mandiri. Update nama diagnosa atau kategori? Cukup satu baris, satu tempat!

🎯

Tips Praktis Mengidentifikasi Ketergantungan Transitif

Cara cepat: tanya diri sendiri — "Apakah atribut ini masih masuk akal jika Primary Key-nya berbeda, tapi nilai atribut 'penengah' ini sama?"

Contoh: Kode_ICD10 = J06.9 selalu punya Nama_Diagnosa = ISPA, terlepas dari kunjungan mana pun. Artinya Nama_Diagnosa bergantung ke Kode_ICD10, bukan ke ID_Kunjungan. Pisahkan! 🔪

Skema Database Lengkap Hasil 3NF: Sistem Kunjungan Pasien

Oke, sekarang kita lihat gambar besar. Dari satu tabel kunjungan yang berantakan, kita mendapat 5 tabel yang bersih dan terstruktur. Inilah skema final sistem kunjungan pasien yang sudah 3NF:

🗄️ Skema Database — 3NF Final

📋 PASIEN

🔑 ID_Pasien (PK)

Nama_Pasien

Tgl_Lahir

Alamat

No_BPJS

👨‍⚕️ DOKTER

🔑 ID_Dokter (PK)

Nama_Dokter

SIP_Dokter

ID_Spesialisasi (FK)

🏥 SPESIALISASI

🔑 ID_Spesialisasi (PK)

Nama_Spesialisasi

🩺 MASTER_ICD10

🔑 Kode_ICD10 (PK)

Nama_Diagnosa

Kategori_ICD

Bab_ICD

🔗 KUNJUNGAN (Central)

🔑 ID_Kunjungan (PK)

🔗 ID_Pasien (FK)

Tgl_Kunjungan

🔗 ID_Dokter (FK)

🔗 Kode_ICD10 (FK)

💡 5 tabel bersih, semua terhubung via FK. Tidak ada ketergantungan transitif yang tersisa. Sistem siap digunakan untuk rekam medis elektronik! ✅

Validasi Hasil Normalisasi 3NF: Sudah Bener Belum?

Nah, ini bagian yang sering dilewati tapi krusial. Setelah normalisasi selesai, kamu perlu memvalidasi hasilnya secara sistematis. Ada dua aspek yang perlu dicek: correctness (benar secara logika) dan completeness (tidak ada data yang hilang). ^[4]

✅ Checklist Validasi Normalisasi 3NF

Kriteria Validasi Status Cara Cek

Setiap tabel punya Primary Key ✅ Cek definisi CREATE TABLE

Tidak ada nilai multi-value dalam satu sel ✅ Review data sampel

Semua non-key atribut bergantung penuh ke PK ✅ Buat daftar FD per tabel

Tidak ada X → Y di mana X bukan superkey ✅ Analisis FD dengan Armstrong's Axioms

Hasil JOIN mengembalikan data asli (lossless) ✅ Jalankan query JOIN & verifikasi

Semua FD awal masih terpresentasi (dependency preservation) ✅ Bandingkan FD sebelum & sesudah

Tidak ada data yang hilang setelah dekomposisi ✅ Row count sebelum vs sesudah JOIN

Validasi dengan Query SQL JOIN

Salah satu cara paling ampuh memvalidasi normalisasi adalah dengan lossless join test: JOIN semua tabel hasil dekomposisi dan pastikan hasilnya identik dengan data awal ^[4]:

💻 SQL — Lossless Join Validation

SELECT
  k.ID_Kunjungan,
  p.Nama_Pasien,
  k.Tgl_Kunjungan,
  d.Nama_Dokter,
  s.Nama_Spesialisasi,
  i.Kode_ICD10,
  i.Nama_Diagnosa,
  i.Kategori_ICD,
  i.Bab_ICD
FROM KUNJUNGAN k
INNER JOIN PASIEN p      ON k.ID_Pasien   = p.ID_Pasien
INNER JOIN DOKTER d       ON k.ID_Dokter   = d.ID_Dokter
INNER JOIN SPESIALISASI s ON d.ID_Spesialisasi = s.ID_Spesialisasi
INNER JOIN MASTER_ICD10 i ON k.Kode_ICD10  = i.Kode_ICD10
ORDER BY k.Tgl_Kunjungan;

Jika hasil query ini identik dengan data awal (sebelum normalisasi), berarti dekomposisimu lossless — tidak ada data yang hilang. Normalisasi berhasil! ✅

⚡

Insight Penting — 3NF vs BCNF

Ada level normalisasi yang lebih ketat di atas 3NF: BCNF (Boyce-Codd Normal Form). Perbedaannya: 3NF masih mentolerir satu pengecualian (atribut Y adalah bagian dari candidate key), sedangkan BCNF tidak — setiap determinan harus superkey. ^[3]

Untuk sistem rekam medis skala kecil-menengah, 3NF sudah optimal. BCNF baru dibutuhkan ketika ada multiple overlapping candidate keys — kasus yang lebih jarang di RMIK.

🎓

Tips Jitu Soal Normalisasi 3NF di Ujian

1. Tulis semua FD terlebih dahulu — ini modal utama analisis normalisasi.
2. Cek apakah semua tabel sudah 1NF dan 2NF — 3NF mensyaratkan keduanya terpenuhi.
3. Cari FD di mana determinan bukan superkey — itu kandidat ketergantungan transitif.
4. Buat tabel baru untuk setiap determinan non-key yang kamu temukan.
5. Uji lossless join dengan memastikan semua FK terhubung dengan benar.

Tabel Perbandingan Lengkap: 1NF, 2NF, dan 3NF

Aspek	1NF	2NF	3NF
Masalah diselesaikan	Nilai tidak atomik	Partial dependency	Transitive dependency
Prasyarat	—	Sudah 1NF	Sudah 2NF
Berlaku saat	Selalu	Composite PK	Ada non-key → non-key FD
Cara penanganan	Pecah nilai jamak ke baris	Pisah tabel per partial FD	Pisah tabel per transitive FD
Contoh kasus RMIK	Multi diagnosa 1 sel	Nama dokter ikut di tabel tindakan	Data ICD-10 ikut di tabel kunjungan

📚 Referensi

1. Kemenkes RI. (2022). Petunjuk Teknis Implementasi Sistem Rekam Medis Elektronik. Kementerian Kesehatan Republik Indonesia. Permenkes No. 24 Tahun 2022.
2. World Health Organization. (2019). ICD-10: International Statistical Classification of Diseases and Related Health Problems (10th Rev., Vol. 1). WHO Press. who.int/classifications/icd
3. Elmasri, R., & Navathe, S. B. (2016). Fundamentals of Database Systems (7th ed.). Pearson. ISBN: 978-0133970777
4. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2019). Database System Concepts (7th ed., pp. 345–382). McGraw-Hill Education. ISBN: 978-0078022159

📝 Kesimpulan

3NF: Bukan Sekadar Teori, Tapi Investasi Kualitas Data

Normalisasi 3NF adalah finishing touch dari proses normalisasi yang paling sering digunakan di dunia nyata. Dengan menghilangkan ketergantungan transitif, kamu memastikan bahwa setiap atribut "berbicara langsung" ke primary key — tidak ada perantara yang tidak perlu.

Dalam konteks RMIK, ini bukan perkara akademis semata. Database rekam medis yang sudah 3NF artinya: pembaruan data ICD-10 cukup di satu tempat, tidak ada risiko data dokter atau diagnosa yang inkonsisten, dan sistem siap berkembang tanpa perlu rombakan besar-besaran.

Dan ingat — validasi itu wajib! Lossless join test dan dependency preservation adalah dua kunci untuk memastikan normalisasimu tidak hanya benar secara teori, tapi juga aman secara data.

Perjalanan Normalisasimu

1NF ✓ 2NF ✓ 3NF ✓ BCNF 4NF+

💬 Yuk, Diskusi di Kolom Komentar!

Setelah baca artikel ini, coba tantang diri kamu sendiri: ambil satu tabel dari tugas praktikum atau data dummy rekam medis, lalu identifikasi — apakah sudah 3NF? Temukan satu ketergantungan transitif yang sembunyi di sana!

Tulis hasilnya di komentar — apakah tabelmu sudah bersih atau ada yang perlu dinormalisasi lagi? Atau kalau ada yang masih bingung soal 3NF, tanya saja di bawah, kita bahas bareng! 👇

📢 Share artikel ini ke teman satu angkatanmu — apalagi yang lagi struggle sama materi normalisasi. Dan jangan lupa follow blog ini karena artikel berikutnya akan bahas tentang ERD (Entity-Relationship Diagram) dari awal sampai implementasi SQL!

Meta Description (155 karakter): Pelajari normalisasi 3NF: eliminasi ketergantungan transitif, studi kasus data kunjungan pasien + ICD-10, dan validasi hasil normalisasi. Panduan D3 RMIK.