Sentuhan Akhir 3NF: Tabel Rapi dengan Primary Key dan Foreign Key

Rapikan tabel kunjungan pasien sampai tidak ada data ganda yang bikin laporan rekam medis berantakan.

Normalisasi 3NF Primary Key Foreign Key RMIK

8 menit

Estimasi baca

Menengah

Level

2026

Tahun

Bayangkan kamu bertugas di unit rekam medis. Dokter kita, dr. Sari, mengganti nama belakangnya setelah menikah. Namanya tercatat di 500 baris tabel kunjungan. Kamu mengubahnya satu per satu, tapi satu baris terlewat. Sekarang satu dokter punya dua nama di laporan. Itu bukan salahmu; tabelnya yang belum rapi. Obatnya adalah normalisasi 3NF.

Di artikel ini kamu menerapkan normalisasi 3NF pada data kunjungan pasien, lalu menentukan primary key dan foreign key. Artikel ini bagian dari seri Kuliah Basis Data (Artikel 11 dari 16), lanjutan dari materi 1NF dan 2NF.

Apa Itu Normalisasi 3NF dan Kenapa Dependensi Transitif Berbahaya?

Bentuk normal ketiga (3NF) adalah tahap lanjutan setelah 2NF. Pada 2NF, kamu sudah menghapus ketergantungan sebagian pada kunci. Pada 3NF, kamu menghapus dependensi transitif, yaitu atribut biasa yang ternyata ditentukan oleh atribut biasa lain, bukan oleh kunci (Elmasri & Navathe, 2016).

Analogi gampangnya begini. Di KTP-mu tercantum kode kelurahan, lalu dari kode itu kamu bisa tahu nama kelurahan. Kalau setiap data warga ikut menyimpan nama kelurahan lengkap, namanya pasti ditulis ribuan kali. Begitu nama kelurahan berubah, ribuan data harus diperbaiki.

📐

Definisi Inti

Tabel memenuhi 3NF jika sudah 2NF dan tidak ada atribut non-kunci yang bergantung pada atribut non-kunci lain.

A → B → C (A kunci, B dan C bukan kunci) = dependensi transitif, harus dipisah

Ambil contoh tabel kunjungan hasil 2NF dari artikel sebelumnya. Perhatikan nama dokter, nama poli, dan nama diagnosis yang diulang-ulang:

id_kunjungan	no_rm	kode_dokter	nama_dokter	kode_poli	nama_poli	kode_icd10	nama_diagnosis
K001	RM0001	D01	dr. Sari, Sp.PD	P01	Penyakit Dalam	I10	Hipertensi esensial
K002	RM0002	D01	dr. Sari, Sp.PD	P01	Penyakit Dalam	E11.9	Diabetes melitus tipe 2
K003	RM0003	D01	dr. Sari, Sp.PD	P01	Penyakit Dalam	I10	Hipertensi esensial

💡 Tips
Cara cepat mendeteksi dependensi transitif: tanya pada setiap kolom non-kunci, "Kalau kolom ini berubah, kolom lain ikut berubah tidak?" Kalau iya, kolom itu kandidat tabel baru.

🔍 Analisis: Apa yang Salah dari Tabel Ini?

Tabel di atas punya tiga rantai dependensi transitif:

id_kunjungan → kode_dokter → nama_dokter
id_kunjungan → kode_poli   → nama_poli
id_kunjungan → kode_icd10  → nama_diagnosis

Anomali ubah: ganti nama dr. Sari berarti mengubah ratusan baris. Anomali hapus: menghapus satu-satunya kunjungan poli baru ikut menghapus informasi poli itu. Anomali sisip: kamu tidak bisa mendaftarkan dokter baru sebelum ia punya kunjungan.

5 Langkah Normalisasi 3NF pada Data Kunjungan Pasien

Ikuti urutan ini setiap kali kamu mengerjakan soal normalisasi 3NF di kelas atau ujian:

Pastikan tabel sudah 2NF. Semua atribut atomik, dan tidak ada ketergantungan sebagian pada kunci. Kalau belum, balik dulu ke artikel 1NF dan 2NF.

Tulis semua ketergantungan fungsional. Contoh: kode_dokter → nama_dokter, spesialisasi. Tulis dengan tanda panah supaya rantai transitifnya terlihat.

Cari dependensi transitif. Cari pola kunci → atribut biasa → atribut biasa lain. Atribut tengah (kode_dokter, kode_poli, kode_icd10) adalah calon primary key tabel baru.

Pisahkan menjadi tabel baru. Pindahkan atribut yang bergantung ke tabel baru, lalu jadikan penentunya sebagai primary key. Hasilnya: tabel dokter, poli, dan diagnosis.

Tinggalkan penghubungnya. Kode penentu tetap ada di tabel asal sebagai foreign key. Tanpa langkah ini, kamu kehilangan hubungan antardata.

⚡ Insight Penting
Normalisasi bukan soal memecah tabel sebanyak mungkin. Tujuannya satu: setiap fakta disimpan di satu tempat saja. Kent (1983) merangkumnya dengan kalimat terkenal: setiap atribut harus bergantung pada kunci, seluruh kunci, dan tidak ada yang lain selain kunci.

Primary Key dan Foreign Key: Hasil Akhir Normalisasi 3NF

Primary key adalah "nomor KTP" sebuah baris: unik dan tidak boleh kosong. Foreign key adalah "tautan" yang menunjuk ke primary key tabel lain, mirip nomor rekam medis yang kamu tulis di formulir lab supaya hasilnya sampai ke pasien yang benar. Berikut peta hasil normalisasi 3NF-nya:

  pasien (PK no_rm)         dokter (PK kode_dokter)
        │                          │
        └────────┐      ┌──────────┘
                 ▼      ▼
         kunjungan (PK id_kunjungan)
          FK: no_rm, kode_dokter,
              kode_poli, kode_icd10
                 ▲      ▲
        ┌────────┘      └──────────┐
        │                          │
  poli (PK kode_poli)    diagnosis (PK kode_icd10)

💻 skema_3nf_rekam_medis.sql

CREATE TABLE pasien (
  no_rm        VARCHAR(10)  PRIMARY KEY,
  nama_pasien  VARCHAR(100) NOT NULL,
  tgl_lahir    DATE         NOT NULL
);

CREATE TABLE dokter (
  kode_dokter  VARCHAR(8)   PRIMARY KEY,
  nama_dokter  VARCHAR(100) NOT NULL,
  spesialisasi VARCHAR(50)
);

CREATE TABLE poli (
  kode_poli    CHAR(3)      PRIMARY KEY,
  nama_poli    VARCHAR(50)  NOT NULL
);

CREATE TABLE diagnosis (
  kode_icd10     VARCHAR(7)   PRIMARY KEY,
  nama_diagnosis VARCHAR(150) NOT NULL
);

CREATE TABLE kunjungan (
  id_kunjungan  VARCHAR(10) PRIMARY KEY,
  no_rm         VARCHAR(10) NOT NULL,
  tgl_kunjungan DATE        NOT NULL,
  kode_dokter   VARCHAR(8)  NOT NULL,
  kode_poli     CHAR(3)     NOT NULL,
  kode_icd10    VARCHAR(7),
  FOREIGN KEY (no_rm)       REFERENCES pasien (no_rm),
  FOREIGN KEY (kode_dokter) REFERENCES dokter (kode_dokter),
  FOREIGN KEY (kode_poli)   REFERENCES poli (kode_poli),
  FOREIGN KEY (kode_icd10)  REFERENCES diagnosis (kode_icd10)
);

Kamu bisa menggabungkan kembali data dengan JOIN kapan pun butuh laporan lengkap:

💻 laporan_kunjungan.sql

SELECT k.id_kunjungan, p.nama_pasien, d.nama_dokter,
       po.nama_poli, dg.nama_diagnosis
FROM kunjungan k
JOIN pasien    p  ON k.no_rm       = p.no_rm
JOIN dokter    d  ON k.kode_dokter = d.kode_dokter
JOIN poli      po ON k.kode_poli   = po.kode_poli
LEFT JOIN diagnosis dg ON k.kode_icd10 = dg.kode_icd10;

🔥 Fakta Menarik
Kode ICD-10 seperti I10 dan E11.9 yang kamu pakai di tabel diagnosis berasal dari klasifikasi penyakit WHO. Karena sudah baku, kode ini cocok jadi primary key alami. Kamu tidak perlu membuat nomor urut sendiri.

Tabel	Primary Key	Foreign Key
pasien	no_rm	-
dokter	kode_dokter	-
poli	kode_poli	-
diagnosis	kode_icd10	-
kunjungan	id_kunjungan	no_rm, kode_dokter, kode_poli, kode_icd10

⚠️ Perhatian
Contoh di atas menyederhanakan satu diagnosis per kunjungan. Di fasilitas kesehatan nyata, satu kunjungan bisa punya banyak diagnosis dan tindakan, sehingga butuh tabel penghubung tersendiri. Soal itu kita bahas lebih lanjut di seri berikutnya. Ingat juga, rekam medis tergolong data pribadi kesehatan; atur akses tabel pasien dengan ketat (Permenkes No. 24 Tahun 2022).

Cek Ulang Hasil Normalisasi 3NF: Dua Pertanyaan Sakti

Setelah memecah tabel, uji hasilnya dengan dua pertanyaan. Pertama: kalau nama dr. Sari berubah, berapa baris yang harus kuubah? Jawaban yang benar: satu baris di tabel dokter. Kedua: apakah ada atribut non-kunci yang menentukan atribut non-kunci lain? Jawaban yang benar: tidak ada. Kalau keduanya terpenuhi, normalisasi 3NF-mu sudah beres.

DBMS seperti MySQL dan PostgreSQL membantu menjaga hubungan ini lewat foreign key constraint. Kamu tidak bisa menyimpan kunjungan dengan kode_dokter yang tidak terdaftar (lihat dokumentasi resmi MySQL dan PostgreSQL pada daftar referensi).

Bentuk Normal	Masalah yang Dihapus	Contoh di Kasus Ini
1NF	Nilai majemuk dan kelompok berulang	Satu sel berisi beberapa diagnosis
2NF	Ketergantungan sebagian pada kunci	Data pasien tercampur di tabel kunjungan
3NF	Dependensi transitif	Nama dokter, poli, dan diagnosis ikut terulang

🎯

Kesimpulan

Normalisasi 3NF menghapus dependensi transitif dengan memisahkan atribut yang bergantung pada atribut non-kunci ke tabel sendiri. Penentunya menjadi primary key di tabel baru dan tetap hadir sebagai foreign key di tabel asal.

Dengan normalisasi 3NF, data dokter, poli, dan diagnosis cukup disimpan sekali. Laporan rekam medis jadi konsisten, dan perubahan data tidak lagi menyiksa.

Sudah coba? Ceritakan kasus tabel yang paling bikin kamu pusing di kolom komentar, lalu bagikan artikel ini ke temanmu.

💬 Tulis Komentar 📤 Bagikan Artikel

📚 Daftar Referensi

Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377–387.
Elmasri, R., & Navathe, S. B. (2016). Fundamentals of Database Systems (7th ed.). Pearson.
Kent, W. (1983). A simple guide to five normal forms in relational database theory. Communications of the ACM, 26(2), 120–125.
Silberschatz, A., Korth, H. F., & Sudarshan, S. (2019). Database System Concepts (7th ed.). McGraw-Hill.
Peraturan Menteri Kesehatan Republik Indonesia Nomor 24 Tahun 2022 tentang Rekam Medis.
MySQL Reference Manual: FOREIGN KEY Constraints. Oracle. dev.mysql.com.
PostgreSQL Documentation: Constraints (bab Data Definition). postgresql.org.