normalisasi redundansi data pasien | java php laravel linux mysql sql bootstrap html css query java php laravel linux mysql sql bootstrap html css query: normalisasi redundansi data pasien

Monday, October 5, 2026

normalisasi redundansi data pasien

๐Ÿ—‚️๐Ÿงน
Kuliah Basis Data · Artikel 9 dari 16

Kenapa Data Pasien Bisa Dobel? Mengurai Redundansi lewat Normalisasi

Dari tabel kunjungan yang gemuk dan berantakan menuju struktur data yang rapi, konsisten, dan aman untuk rekam medis.

Normalisasi Redundansi Anomali Data Rekam Medis
8 menit
Estimasi baca
Pemula
Level
2026
Tahun

Bayangkan kamu bertugas di loket pendaftaran puskesmas. Pak Budi datang untuk kontrol, lalu layar menampilkan tiga catatan: "Budi Santoso", "Budi Santosa", dan "B. Santoso", masing-masing dengan alamat berbeda. Mana yang benar?

Inilah masalah klasik yang diselesaikan oleh normalisasi basis data. Data yang sama tersimpan berulang kali, lalu lama-lama saling bertentangan. Kalau kamu mahasiswa RMIK yang kelak mengelola data pasien, artikel ini memang untukmu. Kita akan membongkar apa itu redundansi, kenapa berbahaya, dan bagaimana normalisasi menjadi jawabannya. Artikel ini adalah Artikel 9 dari 16 dalam seri Kuliah Basis Data.

Apa Itu Normalisasi Basis Data dan Kenapa Kamu Perlu Peduli?

Mulai dari analogi ruang rekam medis. Bayangkan setiap kali pasien berobat, petugas menyalin biodata lengkap (nama, alamat, tanggal lahir) ke lembar baru, lalu menumpuknya di map. Pasien itu berobat 50 kali, jadi ada 50 salinan biodata. Saat ia pindah rumah, kamu harus mencari dan mengoreksi 50 lembar. Kalau satu lembar terlewat, map itu menyimpan dua alamat yang saling bertentangan.

Cara yang lebih waras: simpan biodata di satu map, dan setiap lembar kunjungan cukup mencatat nomor rekam medis sebagai penunjuk. Itulah ide inti normalisasi basis data.

๐Ÿ“˜ Definisi Kunci
Normalisasi adalah proses menyusun ulang atribut ke dalam beberapa tabel agar redundansi berkurang dan anomali data tercegah, tanpa kehilangan informasi saat tabel digabungkan kembali.
Rumus pikir: 1 fakta = 1 tempat penyimpanan.

Secara teori, normalisasi bertumpu pada model relasional yang diperkenalkan Codd (1970) dan dijabarkan dalam buku teks basis data seperti Elmasri dan Navathe (2016). Prosesnya bertahap lewat normal form: 1NF, 2NF, 3NF. Di pertemuan ini kamu cukup memahami konsep, tujuan, dan masalah redundansi yang melatarbelakanginya. Teknik 1NF dan 2NF kita praktikkan di artikel berikutnya.

⚡ Insight Penting
Normalisasi bukan soal "membuat tabel lebih banyak". Normalisasi adalah soal memastikan setiap atribut ditaruh di tabel milik pemiliknya. Alamat milik pasien, bukan milik kunjungan. Nama dokter milik dokter, bukan milik diagnosis.

Redundansi Data Pasien: Masalah Utama yang Diselesaikan Normalisasi Basis Data

Redundansi berarti data yang sama tersimpan berulang di banyak tempat tanpa kebutuhan yang jelas. Lihat contoh tabel kunjungan "serba ada" yang sering dibuat pemula: semua kolom dijejalkan ke satu tabel.

Tabel 1. Tabel kunjungan_flat (belum dinormalisasi)
No RMNamaAlamatTgl KunjunganDokterPoliICD-10Diagnosis
RM-000123Siti AminahJl. Mawar 1214-09-2026dr. Rina Wulandari, Sp.PDPenyakit DalamI10Hipertensi esensial
RM-000123Siti AminahJl. Mawar 1221-09-2026dr. Rina Wulandari, Sp.PDPenyakit DalamI10Hipertensi esensial
RM-000123Siti AminahJl. Mawar 1228-09-2026dr. Rina Wulandari, Sp.PDPenyakit DalamE11.9Diabetes melitus tipe 2 tanpa komplikasi
RM-000124Budi SantosoJl. Kenanga 728-09-2026dr. Bayu PratamaUmumJ00Nasofaringitis akut

Baris berlatar kuning menunjukkan biodata Siti dan identitas dokternya tertulis tiga kali untuk tiga kunjungan. Itu baru empat baris. Di fasilitas kesehatan dengan ratusan kunjungan per hari, pengulangan ini membengkak cepat.

Berikut kode SQL untuk membuat tabel tersebut. Coba jalankan di praktikum:

๐Ÿ“„ kunjungan_flat.sql
CREATE TABLE kunjungan_flat (
  no_rm            VARCHAR(10),
  nama_pasien      VARCHAR(100),
  alamat           VARCHAR(150),
  tgl_kunjungan    DATE,
  nama_dokter      VARCHAR(100),
  poli             VARCHAR(50),
  kode_icd10       VARCHAR(10),
  nama_diagnosis   VARCHAR(150)
);

INSERT INTO kunjungan_flat VALUES
('RM-000123','Siti Aminah','Jl. Mawar 12','2026-09-14','dr. Rina Wulandari, Sp.PD','Penyakit Dalam','I10','Hipertensi esensial'),
('RM-000123','Siti Aminah','Jl. Mawar 12','2026-09-21','dr. Rina Wulandari, Sp.PD','Penyakit Dalam','I10','Hipertensi esensial'),
('RM-000123','Siti Aminah','Jl. Mawar 12','2026-09-28','dr. Rina Wulandari, Sp.PD','Penyakit Dalam','E11.9','Diabetes melitus tipe 2 tanpa komplikasi'),
('RM-000124','Budi Santoso','Jl. Kenanga 7','2026-09-28','dr. Bayu Pratama','Umum','J00','Nasofaringitis akut');
๐Ÿ” Analisis: Berapa Harga Sebuah Redundansi?

Misalkan satu pasien kronis berkunjung 50 kali dalam setahun. Dengan tabel flat:

Tanpa normalisasi
Alamat tersimpan 50 kali. Pindah rumah berarti mengubah 50 baris. Risiko salah ketik muncul 50 kali.
Dengan normalisasi
Alamat tersimpan 1 kali di tabel pasien. Pindah rumah berarti mengubah 1 baris. Konsistensi terjaga otomatis.

Selain boros ruang simpan, redundansi memperbesar peluang data saling bertentangan. Padahal Permenkes No. 24 Tahun 2022 tentang Rekam Medis mengatur penyelenggaraan rekam medis, termasuk yang elektronik. Data yang konsisten adalah fondasi dokumen yang layak dipercaya.

Tiga Anomali Data: Harga yang Dibayar Tanpa Normalisasi Basis Data

Redundansi yang dibiarkan melahirkan anomali, yaitu kondisi saat operasi tambah, ubah, atau hapus data menghasilkan efek samping yang tidak diinginkan (Elmasri & Navathe, 2016; Silberschatz dkk., 2019). Ada tiga jenis:

Tabel 2. Tiga anomali pada tabel kunjungan_flat
AnomaliContoh di Tabel 1Akibat
Update (ubah)Alamat Siti diubah hanya di 1 dari 3 barisSatu pasien punya dua alamat
Insert (tambah)Dokter baru ingin dicatat, tapi belum ada kunjunganData dokter tidak bisa disimpan, atau memaksa isi kolom pasien dengan NULL
Delete (hapus)Baris Budi dihapus karena salah inputData dr. Bayu dan diagnosis J00 ikut lenyap

Anomali update paling mudah dibuktikan. Perhatikan: petugas hanya memperbarui kunjungan terbaru Siti.

๐Ÿ“„ demo_anomali_update.sql
-- Petugas memperbarui alamat, tapi hanya satu baris
UPDATE kunjungan_flat
SET    alamat = 'Jl. Melati 5'
WHERE  no_rm = 'RM-000123'
  AND  tgl_kunjungan = '2026-09-28';

-- Deteksi: pasien dengan lebih dari satu versi alamat
SELECT no_rm,
       COUNT(DISTINCT alamat) AS jumlah_versi_alamat
FROM   kunjungan_flat
GROUP  BY no_rm
HAVING COUNT(DISTINCT alamat) > 1;

Query kedua akan mengembalikan RM-000123 dengan dua versi alamat. Itulah bukti bahwa tabel flat tidak bisa menjaga dirinya sendiri tetap konsisten.

⚠️ Perhatian
Jangan langsung menghapus data "dobel" tanpa memeriksanya. Dalam rekam medis, dua catatan mirip bisa saja dua pasien berbeda yang kebetulan senama. Pastikan identitasnya lewat nomor RM dan data pendukung sebelum menggabungkan atau menghapus.
๐Ÿ”ฅ Fakta Menarik
Model relasional yang menjadi dasar normalisasi dipublikasikan Edgar F. Codd pada 1970 (Codd, 1970). Artinya, masalah data dobel yang kamu pelajari hari ini sudah dipikirkan solusinya lebih dari lima dekade lalu, dan masih relevan di sistem informasi rumah sakit modern.

Tujuan Normalisasi Basis Data: Dari Tabel Gemuk ke Tabel Ramping

Dari tiga anomali tadi, tujuan normalisasi basis data bisa kita rangkum menjadi empat hal:

  • Mengurangi redundansi sehingga ruang simpan lebih efisien.
  • Mencegah anomali saat menambah, mengubah, dan menghapus data.
  • Menjaga konsistensi data pasien di seluruh sistem.
  • Mempermudah pemeliharaan struktur data saat kebutuhan layanan berubah.

Gambaran hasilnya seperti ini. Satu tabel gemuk dipecah menjadi tabel-tabel yang masing-masing mengurus satu hal, lalu dihubungkan lewat primary key dan foreign key:

SEBELUM
+--------------------------------------------------+
| kunjungan_flat                                   |
| no_rm, nama, alamat, tgl, dokter, poli, icd, dx  |
+--------------------------------------------------+

SESUDAH
+---------+      +--------------+      +--------+
| pasien  |1----N| kunjungan    |N----1| dokter |
| no_rm PK|      | id_kunjungan |      | id_dr  |
| nama    |      | no_rm FK     |      | nama   |
| alamat  |      | id_dr FK     |      | poli   |
+---------+      | kode_icd FK  |      +--------+
                 +------+-------+
                        |N
                        |1
                 +------+-------+
                 | diagnosis    |
                 | kode_icd PK  |
                 | nama_dx      |
                 +--------------+

Lalu bagaimana cara mulai menilai tabel yang ada? Ikuti langkah berikut untuk setiap tabel yang kamu temui:

1
Tanyakan "ini milik siapa?" pada setiap kolom.
Alamat milik pasien. Nama dokter milik dokter. Nama diagnosis milik kode ICD-10. Kolom yang "salah rumah" adalah kandidat untuk dipindah.
2
Cari nilai yang berulang di banyak baris.
Tandai kolom yang isinya sama setiap kali satu pasien, dokter, atau kode muncul lagi.
3
Jalankan query deteksi.
Pakai GROUP BY ... HAVING COUNT(DISTINCT ...) > 1 seperti contoh tadi untuk menemukan data yang sudah terlanjur bertentangan.
4
Uji tiga anomali secara mental.
Tanyakan: "Kalau data ini kutambah, kuubah, atau kuhapus, apa efek sampingnya?" Kalau ada efek samping, tabelmu belum rapi.
5
Catat hubungan antaratribut.
Tuliskan atribut mana yang menentukan atribut lain, misalnya no_rm → nama, alamat. Catatan ini jadi bahan utama saat kita masuk ke 1NF dan 2NF.
๐Ÿ’ก Tips
Saat praktikum, jangan langsung membuka aplikasi DBMS. Gambar dulu tabel dan panah hubungannya di kertas. Cara ini membuat kamu menemukan atribut yang "salah rumah" jauh lebih cepat daripada menebak lewat kode. Rancangan ERD dari artikel sebelumnya adalah bahan latihan yang pas.

Satu catatan penting: normalisasi punya batas wajar. Beberapa data memang sengaja disimpan sebagai snapshot pada saat kejadian (misalnya tarif atau tindakan saat pelayanan), dan itu bukan redundansi yang salah. Kita bahas pertimbangan ini lebih jauh di artikel-artikel berikutnya (Date, 2003).

๐Ÿ Kesimpulan: Normalisasi Basis Data Bukan Sekadar Teori

Data pasien bisa dobel karena banyak fakta dijejalkan ke satu tabel. Akibatnya, informasi yang sama tersimpan berulang dan memicu anomali update, insert, dan delete. Normalisasi basis data menjawabnya dengan satu prinsip: satu fakta, satu tempat.

  • Redundansi = data sama tersimpan berulang tanpa kebutuhan jelas.
  • Anomali = efek samping saat menambah, mengubah, atau menghapus data.
  • Tujuan normalisasi = kurangi redundansi, cegah anomali, jaga konsistensi.

Setelah paham masalahnya, kamu siap membereskan tabel secara bertahap di artikel berikutnya.

Pernah menemukan data pasien dobel di lapangan? Ceritakan pengalamanmu di kolom komentar, dan bagikan artikel ini ke temanmu yang masih bingung soal normalisasi!

๐Ÿ’ฌ Tulis Komentar ๐Ÿ“ค Bagikan Artikel

๐Ÿ“š Daftar Referensi

  1. Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377–387.
  2. Date, C. J. (2003). An Introduction to Database Systems (8th ed.). Addison-Wesley.
  3. Elmasri, R., & Navathe, S. B. (2016). Fundamentals of Database Systems (7th ed.). Pearson.
  4. Kent, W. (1983). A simple guide to five normal forms in relational database theory. Communications of the ACM, 26(2), 120–125.
  5. Kementerian Kesehatan Republik Indonesia. (2022). Peraturan Menteri Kesehatan Nomor 24 Tahun 2022 tentang Rekam Medis.
  6. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2019). Database System Concepts (7th ed.). McGraw-Hill.
#BasisData #Database #RMIK #Normalisasi #Redundansi #AnomaliData
Label: Normalisasi Basis Data Redundansi Data Pasien
๐Ÿ“š
Artikel Utama Seri
Daftar Isi Kuliah Basis Data

Artikel ini bagian dari seri Kuliah Basis Data (Artikel 9 dari 16). Lihat seluruh rangkaian materinya di sini.

Buka Daftar Isi →

No comments:

Post a Comment

saifiahmada.com adalah blog belajar programming Indonesia, membahas lengkap materi bahasa pemrograman: code HTML, CSS, Bootstrap, Desain, PHP, MySQL, coding Java, Query, SQL, dan dunia linux