Monday, October 5, 2026

entitas atribut erd

🧑‍⚕️ 🗂️ 🏥

Kuliah Basis Data • Artikel 6 dari 16

Siapa Saja Pemainnya? Mengenal Entitas dan Atribut dalam ERD

Sebelum menggambar ERD, kenali dulu siapa saja yang berperan di pelayanan kesehatan dan data apa yang melekat pada mereka.

#ERD #Entitas #Atribut #RekamMedis

±8 menit

Estimasi baca

Pemula

Level

2026

Tahun

Pernah membayangkan apa yang terjadi kalau dua pasien bernama "Siti Aminah" datang ke loket pendaftaran pada hari yang sama? Tanpa pengenal unik, berkas rekam medis bisa tertukar. Itu bukan sekadar salah ketik, tetapi risiko keselamatan pasien. Di sinilah entitas dan atribut ERD berperan: entitas adalah "pemain" dalam sistem, sedangkan atribut adalah "identitas" yang melekat pada tiap pemain.

Artikel ini adalah Artikel 6 dari 16 seri Kuliah Basis Data untuk kamu mahasiswa D3 RMIK semester 3. Setelah membaca, kamu bisa mengidentifikasi entitas, menentukan atribut dan kuncinya, lalu menghubungkannya pada kasus pelayanan kesehatan sederhana.

Apa Itu Entitas dan Atribut ERD?

Entity Relationship Diagram (ERD) adalah diagram yang menggambarkan data apa saja yang perlu disimpan dan bagaimana data itu saling berhubungan. Model ini pertama kali diusulkan oleh Peter Chen pada 1976 (Chen, 1976). Dua bahan dasarnya adalah entitas dan atribut.

📐 Definisi Inti

Entitas = objek atau konsep di dunia nyata yang datanya perlu kita catat dan bisa dibedakan dari objek lain. Contoh: Pasien, Dokter, Kunjungan.

Atribut = sifat atau keterangan yang menjelaskan sebuah entitas. Contoh: nama pasien, tanggal lahir, nomor rekam medis.

Analogi gampangnya begini. Bayangkan sebuah rumah sakit sebagai panggung drama. Entitas adalah para pemainnya: pasien, dokter, perawat. Atribut adalah kartu identitas tiap pemain: nama, umur, peran. Naskah yang mengatur siapa berinteraksi dengan siapa itulah hubungan (relationship), yang akan kita bahas lebih dalam di artikel berikutnya.

💡 Tips: Uji Kata Benda

Calon entitas hampir selalu berupa kata benda dalam narasi kasus, seperti "pasien", "dokter", "diagnosis". Sebaliknya, kata kerja ("mendaftar", "memeriksa") biasanya jadi calon hubungan, bukan entitas.

Langkah Menemukan Entitas dan Atribut ERD dari Kasus Pelayanan Kesehatan

Banyak mahasiswa bingung harus mulai dari mana. Pakai alur lima langkah ini, dan latihan dengan kasus berikut:

Kasus: Di Poli Umum, pasien mendaftar di loket dengan nomor rekam medis. Dokter memeriksa pasien dalam sebuah kunjungan, menetapkan diagnosis, dan bila perlu melakukan tindakan. Setiap kunjungan dicatat tanggalnya.

Garis bawahi semua kata benda.
Dari kasus: pasien, loket, nomor rekam medis, dokter, kunjungan, diagnosis, tindakan, tanggal, Poli Umum.

Saring: mana yang punya data untuk disimpan?
Pasien, dokter, kunjungan, diagnosis, dan tindakan punya banyak keterangan, jadi calon entitas. "Tanggal" dan "nomor rekam medis" hanya keterangan, jadi calon atribut.

Tempelkan atribut ke entitas yang tepat.
Tanya: "Keterangan ini milik siapa?" Tanggal lahir milik Pasien, sedangkan tanggal kunjungan milik Kunjungan.

Tentukan atribut kunci (primary key).
Pilih atribut yang nilainya unik dan tidak pernah kosong. Untuk Pasien, pilih no_rm, bukan nama.

Cari hubungan antarentitas lewat kata kerja.
"Pasien mendaftar kunjungan", "Dokter memeriksa pasien", "Kunjungan menghasilkan diagnosis dan tindakan".

⚡ Insight Penting

Nama pasien bukan kunci yang baik karena bisa kembar dan bisa berubah. Karena itu rumah sakit memakai nomor rekam medis sebagai identitas tunggal pasien. Ini tanggung jawab inti profesi RMIK. Pasal tentang isi rekam medis dalam Permenkes No. 24 Tahun 2022 pun mengawali dengan identitas pasien (Kemenkes RI, 2022).

Jenis Atribut dalam Entitas dan Atribut ERD: Dari Simpel sampai Turunan

Tidak semua atribut sama. Memahami jenisnya membantu kamu menghindari tabel yang berantakan ketika ERD diterjemahkan ke basis data (Elmasri & Navathe, 2016).

Jenis Atribut	Arti	Contoh di Rekam Medis
Sederhana	Tidak bisa dipecah lagi	jenis_kelamin
Komposit	Bisa dipecah jadi bagian lebih kecil	alamat → jalan, RT/RW, kelurahan, kota
*Kunci (key)*	Nilainya unik, pembeda antarbaris	no_rm, id_kunjungan
Multinilai	Satu entitas punya banyak nilai	no_telepon (pasien punya dua nomor)
Turunan	Bisa dihitung dari atribut lain	umur (dihitung dari tanggal_lahir)

🔥 Fakta Menarik

Atribut umur sebaiknya tidak disimpan. Umur pasien berubah tiap tahun, sedangkan tanggal lahir tetap. Simpan tanggal lahir, lalu hitung umur saat dibutuhkan. Hasilnya, data tidak basi dan tidak perlu diperbarui manual.

🔍 Analisis: Entitas atau Atribut?

Jadikan ENTITAS jika:

Punya atribut sendiri lebih dari satu
Perlu dicatat berulang-ulang
Contoh: Diagnosis (kode ICD-10, nama diagnosis, jenis)

Jadikan ATRIBUT jika:

Hanya keterangan satu nilai
Tidak punya data pendukung sendiri
Contoh: golongan_darah milik Pasien

Contoh Penerapan Entitas dan Atribut ERD pada Pelayanan Rawat Jalan

Dari kasus Poli Umum tadi, kita susun empat entitas utama. Inilah sketsa ERD berbentuk teks (notasi sederhana: PK = primary key, FK = foreign key, 1 = satu, N = banyak):

🧩 erd-rawat-jalan.txt

+-------------------+          +----------------------+
|      PASIEN       | 1      N |      KUNJUNGAN       |
+-------------------+----------+----------------------+
| PK no_rm          | mendaftar| PK id_kunjungan      |
|    nama_pasien    |          |    tgl_kunjungan     |
|    tgl_lahir      |          |    keluhan           |
|    jenis_kelamin  |          | FK no_rm             |
|    alamat         |          | FK id_dokter         |
|    no_telepon     |          +----------+-----------+
+-------------------+                     | N
                                          | memeriksa
                                          | 1
                               +----------+-----------+
                               |        DOKTER        |
                               +----------------------+
                               | PK id_dokter         |
                               |    nama_dokter       |
                               |    spesialisasi      |
                               +----------------------+

+----------------------+  N   M  +----------------------+
|      KUNJUNGAN       +---------+      DIAGNOSIS       |
|                      | memiliki| PK kode_icd10        |
+----------------------+         |    nama_diagnosis    |
                                 +----------------------+

Perhatikan bahwa no_rm muncul lagi di Kunjungan sebagai FK. Itulah "benang merah" yang menyambungkan satu pasien ke seluruh riwayat kunjungannya. Kalau nanti ERD ini kamu ubah menjadi tabel, hasilnya kira-kira seperti kode berikut:

🗄️ pasien-kunjungan.sql

CREATE TABLE pasien (
  no_rm          VARCHAR(10)  PRIMARY KEY,
  nama_pasien    VARCHAR(100) NOT NULL,
  tgl_lahir      DATE         NOT NULL,
  jenis_kelamin  CHAR(1),
  alamat         VARCHAR(200)
);

CREATE TABLE kunjungan (
  id_kunjungan   INT          PRIMARY KEY,
  tgl_kunjungan  DATE         NOT NULL,
  keluhan        VARCHAR(255),
  no_rm          VARCHAR(10)  NOT NULL,
  FOREIGN KEY (no_rm) REFERENCES pasien(no_rm)
);

⚠️ Perhatian: Jebakan Klasik

Jangan menaruh nama_dokter langsung di entitas Kunjungan. Kalau dokter berganti nama atau salah ketik, kamu harus memperbaiki ratusan baris. Simpan sekali di entitas Dokter, lalu rujuk lewat id_dokter. Ini fondasi untuk normalisasi di artikel-artikel berikutnya.

💡 Tips Latihan Mandiri

Ambil formulir pendaftaran pasien di puskesmas atau rumah sakit terdekat, lalu tandai tiap kolomnya: ini atribut milik entitas yang mana? Latihan lima menit ini melatih mata rancangmu lebih cepat daripada membaca teori satu jam.

Menentukan Hubungan: Pelengkap Entitas dan Atribut ERD

Entitas dan atribut baru separuh cerita. Pemain panggung perlu tahu siapa berinteraksi dengan siapa, dan seberapa banyak. Itulah fungsi kardinalitas, yaitu jumlah baris di satu entitas yang boleh berpasangan dengan baris di entitas lain (Elmasri & Navathe, 2016). Ada tiga jenis yang perlu kamu hafal:

Kardinalitas	Artinya	Contoh Pelayanan Kesehatan
1 : 1	Satu pasangan saja di kedua sisi	Satu kunjungan rawat inap menempati satu surat persetujuan umum (general consent)
1 : N	Satu baris berpasangan dengan banyak baris	Satu pasien memiliki banyak kunjungan
M : N	Banyak berpasangan dengan banyak	Satu kunjungan bisa punya banyak diagnosis, dan satu diagnosis muncul di banyak kunjungan

Hubungan M:N paling sering bikin mahasiswa tersandung. Basis data relasional tidak bisa menyimpannya secara langsung. Solusinya, kamu membuat entitas penghubung di tengah. Misalnya, hubungan Kunjungan dan Diagnosis menjadi entitas DIAGNOSIS_KUNJUNGAN dengan atribut id_kunjungan, kode_icd10, dan jenis_diagnosis (utama atau sekunder). Perhatikan bahwa atribut jenis_diagnosis tidak milik Kunjungan maupun Diagnosis. Ia milik pasangan keduanya, dan itu bukti entitas penghubung memang punya atribut sendiri.

⚡ Cara Cepat Menentukan Kardinalitas

Baca hubungan dari dua arah. Tanya: "Satu pasien boleh punya berapa kunjungan?" (banyak). Lalu balik: "Satu kunjungan boleh milik berapa pasien?" (satu). Hasilnya 1:N. Kalau kedua arah jawabannya "banyak", kamu butuh entitas penghubung.

Latihan kecil untuk kamu: bagaimana dengan Kunjungan dan Tindakan medis, misalnya pemasangan infus atau penjahitan luka? Satu kunjungan bisa mencakup beberapa tindakan, dan satu jenis tindakan bisa dilakukan di banyak kunjungan. Ya, itu M:N. Coba tentukan atribut entitas penghubungnya, seperti jumlah tindakan dan waktu pelaksanaan. Tulis jawabanmu di komentar, nanti kita bahas bersama.

Cek Ulang: Daftar Periksa Sebelum Menggambar ERD

Sebelum melangkah ke gambar ERD lengkap, pastikan hasil identifikasimu lolos lima pertanyaan ini:

Apakah setiap entitas punya atribut kunci yang unik?
Apakah tiap atribut menempel pada satu entitas yang paling tepat?
Apakah atribut turunan (seperti umur) sudah dikeluarkan?
Apakah atribut komposit (seperti alamat) sudah kamu putuskan perlu dipecah atau tidak?
Apakah setiap hubungan punya kata kerja yang jelas dan keterangan 1 atau N?

Kenapa semua ketelitian ini penting buat calon perekam medis? Karena rancangan data adalah fondasi mutu informasi. Kalau satu pasien tercatat dengan dua nomor rekam medis, riwayatnya terbelah dan dokter melihat gambaran yang tidak utuh. Kalau diagnosis disimpan sebagai teks bebas, laporan morbiditas jadi sulit dihitung. Sebaliknya, ketika entitas, atribut, dan kuncinya dirancang rapi sejak awal, pencarian riwayat, pelaporan, dan penelusuran berkas berjalan jauh lebih mulus. Jadi, anggap latihan ERD ini sebagai latihan menjaga kualitas data pasien, bukan sekadar tugas menggambar kotak dan garis.

🏁

Kesimpulan

Memahami entitas dan atribut ERD adalah langkah pertama merancang basis data yang rapi. Entitas adalah objek yang datanya kita catat, seperti Pasien, Dokter, Kunjungan, dan Diagnosis. Atribut adalah keterangan yang melekat padanya. Kunci unik seperti no_rm memastikan setiap pasien tidak tertukar. Hubungan antarentitas biasanya terbaca dari kata kerja dalam kasus.

Di artikel berikutnya, kamu akan menggambar semuanya menjadi ERD utuh. Sampai ketemu di sana!

Sudah bisa membedakan entitas dan atribut? Tulis contohmu di kolom komentar, dan bagikan artikel ini ke teman sekelasmu!

💬 Tulis Komentar 📤 Bagikan Artikel

🏷️ Topik:

#BasisData #Database #RMIK #ERD #Entitas #Atribut

Label: Entitas dan Atribut ERD Artikel 6 dari 16

📚 Daftar Referensi

Chen, P. P. S. (1976). The entity-relationship model: Toward a unified view of data. ACM Transactions on Database Systems, 1(1), 9–36.
Connolly, T., & Begg, C. (2015). Database systems: A practical approach to design, implementation, and management (6th ed.). Pearson.
Elmasri, R., & Navathe, S. B. (2016). Fundamentals of database systems (7th ed.). Pearson.
Kementerian Kesehatan Republik Indonesia. (2022). Peraturan Menteri Kesehatan Nomor 24 Tahun 2022 tentang Rekam Medis.
Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database system concepts (7th ed.). McGraw-Hill.

Artikel Utama Seri Ini

📖 Daftar Isi

Daftar Isi Kuliah Basis Data

Lihat seluruh 16 artikel seri Basis Data untuk mahasiswa RMIK →

← Artikel Sebelumnya

Ikuti Alur Datanya! Membaca Pelayanan Kesehatan lewat DFD

Artikel Selanjutnya →

Gambar Dulu Baru Bangun: Merancang ERD Pelayanan Kesehatan

dfd alur data pelayanan kesehatan

📚 Kuliah Basis Data · Artikel 5 dari 16

🏥➡️🗂️

Ikuti Alur Datanya! Membaca Pelayanan Kesehatan lewat DFD

Dari meja pendaftaran sampai laporan bulanan, lihat ke mana saja data pasien berjalan sebelum kamu merancang satu tabel pun.

DFD Analisis Kebutuhan Data Alur Data Rawat Jalan Rekam Medis

⏳

±9 menit

Estimasi baca

🎯

Pemula

Level

📅

2026

Tahun

Bayangkan kamu petugas pendaftaran di puskesmas. Seorang bapak datang dengan keluhan batuk tiga minggu. Dalam hitungan menit, namanya masuk register, berkasnya pindah ke poli umum, dokter menulis diagnosis, lalu data yang sama muncul lagi di laporan bulanan. Pertanyaannya: sebenarnya data itu berjalan ke mana saja?

Di sinilah DFD data flow diagram berperan. Diagram sederhana ini membantu kamu "melihat" perjalanan data dari satu titik ke titik lain, sebelum menyentuh satu baris SQL pun. Ini Artikel 5 dari 16 dalam seri Kuliah Basis Data untuk mahasiswa D3 RMIK semester 3. Setelah membaca, kamu bisa mengidentifikasi aliran data pelayanan kesehatan dan mengubahnya menjadi daftar kebutuhan data. Siap ikut alurnya?

Apa Itu DFD Data Flow Diagram? Peta Perjalanan Data

Kalau ERD adalah denah gudang yang menunjukkan apa saja yang disimpan dan di rak mana, maka DFD data flow diagram adalah rute kurirnya: menunjukkan bagaimana paket data bergerak dari pengirim, singgah di mana, lalu sampai ke penerima. Keduanya penting, tapi urutannya jelas. Kamu harus tahu rutenya dulu sebelum bisa merancang gudang yang pas.

📌 DEFINISI INTI

DFD (Data Flow Diagram) = diagram yang menggambarkan bagaimana data masuk ke sistem, diproses, disimpan, dan keluar, tanpa membahas teknis pemrogramannya.

Rujukan konsep: Kendall & Kendall (2019), Systems Analysis and Design.

Kenapa ini penting untuk RMIK? Satu kunjungan pasien melibatkan loket pendaftaran, poli, dokter, ruang rekam medis, sampai bagian pelaporan. Tanpa peta, data mudah "tersangkut": nomor rekam medis ganda, diagnosis tidak terdokumentasi, atau laporan yang tidak cocok dengan register. DFD membuat semua masalah itu kelihatan sebelum kamu merancang tabel.

Dalam Sub-CPMK T2 mata kuliah ini, DFD adalah pintu masuk. Dari alur data, kamu menurunkan kebutuhan data, lalu merepresentasikannya sebagai ERD di artikel-artikel berikutnya.

🔥 Fakta Menarik

Notasi DFD populer lewat dua buku klasik. DeMarco (1978) memakai lingkaran untuk proses, sedangkan Gane & Sarson (1979) memakai persegi bersudut membulat. Artikel ini mengikuti gaya Gane & Sarson karena lebih mudah digambar di kertas maupun di teks.

Empat Simbol DFD Data Flow Diagram yang Wajib Kamu Kenal

Seluruh DFD hanya tersusun dari empat komponen. Anggap saja empat jenis balok lego: sedikit, tapi bisa membentuk sistem serumit apa pun.

Komponen	Simbol (Gane & Sarson)	Fungsi	Contoh di RMIK
Entitas Eksternal	Persegi ▭	Pihak di luar sistem yang mengirim atau menerima data	Pasien, Dokter, Kepala RMIK
Proses	Persegi bersudut membulat ▢	Mengubah data masuk menjadi data keluar	Mendaftarkan Pasien, Mencatat Diagnosis
Aliran Data	Panah berlabel →	Menunjukkan arah dan isi data yang bergerak	"data identitas pasien", "hasil diagnosis"
Penyimpanan Data	Dua garis sejajar ═	Tempat data "beristirahat" sampai dibutuhkan lagi	D1 Data Pasien, D3 Rekam Medis

⚡ Insight Penting: Tiga Aturan Emas

1. Setiap proses wajib punya minimal satu aliran masuk dan satu aliran keluar. Proses tanpa input disebut "ajaib", proses tanpa output disebut "lubang hitam".
2. Data tidak boleh mengalir langsung antar entitas eksternal atau antar penyimpanan data. Selalu lewat proses.
3. Beri nama aliran dengan kata benda yang spesifik, misalnya "data identitas pasien", bukan sekadar "data".

💡 Tips Penamaan

Tulis proses dengan kata kerja (Mendaftarkan Pasien), sedangkan data store dan aliran data dengan kata benda (Data Kunjungan). Bingung membedakan? Tanyakan: "Apakah ia melakukan sesuatu pada data, atau hanya menyimpannya?" Yang pertama proses, yang kedua data store.

Langkah Membuat DFD Data Flow Diagram Pelayanan Kesehatan

Kamu tidak perlu aplikasi khusus. Kertas, pensil, dan satu kasus nyata sudah cukup. Ikuti enam langkah berikut, dengan contoh pelayanan rawat jalan poli umum.

Tentukan batas sistem.
Tulis satu kalimat: "Sistem ini mencakup alur data pasien rawat jalan poli umum, dari pendaftaran sampai laporan kunjungan." Tanpa batas, diagrammu akan melebar ke farmasi, laboratorium, bahkan keuangan.

Daftar entitas eksternal.
Siapa yang mengirim atau menerima data di luar sistem? Pada contoh ini: Pasien, Dokter, dan Kepala RMIK.

Gambar diagram konteks (Level 0).
Seluruh sistem dianggap satu proses besar bernomor 0. Gambar entitas di sekelilingnya dan beri label setiap panah.

Pecah menjadi Level 1.
Bongkar proses 0 menjadi tiga sampai lima proses utama, misalnya 1.0 Mendaftarkan Pasien, 2.0 Memeriksa Pasien, 3.0 Menyusun Resume dan Laporan.

Tambahkan data store dan label aliran.
Tentukan di mana data "menginap": D1 Data Pasien, D2 Data Kunjungan, D3 Rekam Medis. Pastikan setiap panah punya nama.

Uji dengan satu pasien imajiner.
Telusuri satu orang dari datang sampai pulang. Kalau ada langkah yang datanya "muncul begitu saja" atau "hilang entah ke mana", diagrammu perlu diperbaiki.

Hasil langkah 3 untuk kasus kita bisa dituliskan seperti ini:

📄 diagram-konteks-level-0.txt

                 identitas, keluhan
   ┌─────────┐ ───────────────────▶ ╭───────────────╮ ◀─────────────────── ┌─────────┐
   │ PASIEN  │                      │ 0. Sistem     │     diagnosis,       │ DOKTER  │
   └─────────┘ ◀─────────────────── │ Rawat Jalan   │     tindakan         └─────────┘
                 kartu berobat      ╰───────────────╯
                                            │  laporan kunjungan
                                            ▼
                                    ┌──────────────┐
                                    │ KEPALA RMIK  │
                                    └──────────────┘

Membaca DFD Data Flow Diagram Level 1: Satu Pasien, Satu Perjalanan Data

Diagram konteks memberi gambaran besar, tapi detailnya ada di Level 1. Di bawah ini versi teksnya. Setiap proses ditulis lengkap dengan data yang masuk, dibaca, ditulis, dan keluar, sehingga mudah kamu salin ke catatan kuliah.

📄 dfd-level-1-rawat-jalan.txt

PROSES 1.0  Mendaftarkan Pasien
  Masuk : Pasien  → data identitas, keluhan
  Baca  : D1 Data Pasien (cek apakah pasien lama)
  Tulis : D1 Data Pasien (pasien baru), D2 Data Kunjungan
  Keluar: Pasien  ← kartu berobat, nomor antrean

PROSES 2.0  Memeriksa Pasien
  Masuk : Dokter  → hasil anamnesis, diagnosis, tindakan
  Baca  : D1 Data Pasien, D3 Rekam Medis (riwayat)
  Tulis : D3 Rekam Medis
  Keluar: Dokter  ← riwayat penyakit terdahulu

PROSES 3.0  Menyusun Resume dan Laporan
  Baca  : D2 Data Kunjungan, D3 Rekam Medis
  Keluar: Kepala RMIK ← laporan kunjungan

Sekarang saatnya membaca, bukan sekadar menggambar. Perhatikan pola yang muncul:

🔍 Analisis: Apa yang Terbongkar dari Diagram Ini?

D1 dibaca dua proses.
Data pasien jadi data induk. Artinya harus tunggal dan konsisten, karena nomor rekam medis ganda akan merusak dua proses sekaligus.

D3 hanya ditulis proses 2.0.
Isi rekam medis berasal dari pemeriksaan dokter. Ini petunjuk awal untuk hak akses: siapa boleh mengisi, siapa hanya boleh membaca.

D2 menjadi sumber laporan.
Kalau data kunjungan tidak lengkap, laporan proses 3.0 ikut bermasalah. Kualitas di hulu menentukan kualitas di hilir.

⚠️ Perhatian: Ini Data Sensitif

Aliran yang menuju D3 Rekam Medis membawa informasi kesehatan pribadi. Permenkes No. 24 Tahun 2022 mengatur penyelenggaraan rekam medis, termasuk kewajiban fasilitas pelayanan kesehatan menyelenggarakan rekam medis elektronik, dan UU No. 27 Tahun 2022 mengatur pelindungan data pribadi. Sejak tahap DFD, biasakan bertanya: siapa yang boleh melihat aliran ini?

Dari Alur Data ke Kebutuhan Data: Jembatan Menuju ERD

Inilah alasan DFD masuk kuliah Basis Data. Setiap data store adalah calon entitas, dan setiap label aliran data adalah calon atribut. Dengan begitu, daftar kebutuhan datamu tidak berasal dari tebakan, melainkan dari alur nyata.

Data Store (DFD)	Calon Entitas (ERD)	Calon Atribut dari Label Aliran
D1 Data Pasien	PASIEN	no_rm, nama, tanggal_lahir, alamat
D2 Data Kunjungan	KUNJUNGAN	tanggal_kunjungan, keluhan, nomor_antrean
D3 Rekam Medis	DIAGNOSIS, TINDAKAN	kode_icd10, nama_diagnosis, nama_tindakan

Sebagai gambaran, dua data store pertama bisa langsung diterjemahkan ke SQL. Jangan khawatir soal kunci dan relasinya; itu bahan artikel ERD berikutnya.

🗄️ pratinjau-tabel.sql

-- Dari D1 Data Pasien
CREATE TABLE pasien (
  no_rm         VARCHAR(10),
  nama          VARCHAR(100),
  tanggal_lahir DATE,
  alamat        VARCHAR(200)
);

-- Dari D2 Data Kunjungan
CREATE TABLE kunjungan (
  tanggal_kunjungan DATE,
  keluhan           VARCHAR(255),
  nomor_antrean     INT
);

💡 Latihan Mini 15 Menit

Pilih satu alur di tempat praktikmu, misalnya pendaftaran pasien baru atau permintaan berkas rekam medis oleh dokter. Gambar diagram konteksnya, daftarkan data store yang terlibat, lalu tulis tiga calon atribut untuk tiap data store. Bawa hasilnya ke kelas, dan jadikan bahan diskusi.

Kesimpulan: DFD Data Flow Diagram sebagai Peta Sebelum Merancang Data

Kamu sudah melihat bahwa pelayanan kesehatan adalah rangkaian aliran data yang saling bersambung. Poin yang perlu kamu bawa pulang:

▸ DFD hanya punya empat komponen: entitas eksternal, proses, aliran data, dan penyimpanan data.

▸ Buat dari konteks (Level 0) dulu, baru pecah ke Level 1, lalu uji dengan satu pasien imajiner.

▸ Data store menjadi calon entitas, label aliran menjadi calon atribut.

▸ Sejak tahap awal, perhatikan sensitivitas data rekam medis.

Dengan kebiasaan membaca DFD data flow diagram, kamu akan merancang basis data yang berangkat dari kebutuhan nyata, bukan dari asumsi. Nah, bagian paling seru ada di kamu: menurutmu, proses mana di fasilitas kesehatan yang alur datanya paling rumit? Tulis di kolom komentar, lalu bagikan artikel ini ke teman sekelasmu.

💬 Tulis Komentar 📤 Bagikan Artikel

📖 Referensi

DeMarco, T. (1978). Structured Analysis and System Specification. New York: Yourdon Press.

Gane, C. & Sarson, T. (1979). Structured Systems Analysis: Tools and Techniques. Englewood Cliffs, NJ: Prentice-Hall.

Kendall, K. E. & Kendall, J. E. (2019). Systems Analysis and Design (11th ed.). New York: Pearson.

Elmasri, R. & Navathe, S. B. (2016). Fundamentals of Database Systems (7th ed.). Boston: Pearson.

Kementerian Kesehatan Republik Indonesia. (2022). Peraturan Menteri Kesehatan Nomor 24 Tahun 2022 tentang Rekam Medis.

Republik Indonesia. (2022). Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi.

#BasisData #Database #RMIK #DFD #DataFlowDiagram #AnalisisKebutuhanData

🏷️ DFD Data Flow Diagram 🏷️ Alur Data Pelayanan Kesehatan 🏷️ Kuliah Basis Data 5/16

ARTIKEL UTAMA SERI

📚 Daftar Isi Kuliah Basis Data

Artikel ini bagian dari seri Kuliah Basis Data (Artikel 5 dari 16). Lihat seluruh materi dan urutan belajarnya di halaman utama.

Buka Daftar Isi →

← ARTIKEL SEBELUMNYA

Ketika Pasien, Dokter, dan Poli Saling Terhubung: Relasi pada Pelayanan Kesehatan

ARTIKEL SELANJUTNYA →

Siapa Saja Pemainnya? Mengenal Entitas dan Atribut dalam ERD

relasi pelayanan kesehatan

🧑‍⚕️🔗🏥

Kuliah Basis Data · Artikel 4 dari 16

Ketika Pasien, Dokter, dan Poli Saling Terhubung: Relasi pada Pelayanan Kesehatan

Cara menghubungkan tabel lewat primary key dan foreign key supaya data kunjungan pasien tidak berjalan sendiri-sendiri.

Basis Data Relasi Tabel Foreign Key Rekam Medis

⏱ 9 menit

Estimasi baca

📈 Dasar

Level

📅 2026

Tahun

Bayangkan kamu bertugas di loket pendaftaran sebuah puskesmas. Seorang bapak datang dengan keluhan batuk. Kamu mencatat namanya di tabel pasien, lalu mencatat dokter jaga di tabel dokter. Tapi di mana kamu menulis bahwa bapak ini diperiksa dokter itu, di poli umum, pada hari ini? Tanpa penghubung, tabel-tabelmu hanya tumpukan data yang saling cuek.

Di sinilah relasi basis data pelayanan kesehatan berperan. Artikel ini adalah bagian dari seri Kuliah Basis Data (Artikel 4 dari 16). Setelah memahami anatomi tabel, atribut, dan record di artikel sebelumnya, sekarang kamu belajar menghubungkan entitas pasien, dokter, poli, dan kunjungan menjadi satu alur data yang utuh.

🎯 Capaian pembelajaran (Sub-CPMK T1)

Setelah membaca, kamu mampu menerapkan konsep relasional pada kasus kesehatan dan menghubungkan entitas serta data pada kasus pelayanan kesehatan.

Mengapa Relasi Basis Data Pelayanan Kesehatan Itu Penting?

Coba bayangkan kartu pasien di lemari arsip. Satu map berisi identitas, riwayat kunjungan, nama dokter, dan hasil diagnosis. Di basis data relasional, semua itu tidak ditumpuk dalam satu tabel raksasa. Datanya dipecah ke beberapa tabel kecil yang rapi, lalu dihubungkan lewat kunci. Edgar F. Codd memperkenalkan gagasan ini pada tahun 1970 (Codd, 1970).

Kenapa dipecah? Karena kalau identitas pasien kamu tulis ulang di setiap kunjungan, masalah muncul cepat. Pasien pindah alamat, dan kamu harus mengubahnya di puluhan baris. Satu baris terlewat, dan datanya tidak konsisten. Dengan relasi, identitas pasien cukup tersimpan sekali, lalu kunjungan hanya "menunjuk" ke pasien tersebut.

📐 Konsep Utama

Primary Key (PK) = atribut yang mengidentifikasi satu record secara unik di dalam tabelnya.

Foreign Key (FK) = atribut di satu tabel yang nilainya merujuk ke PK di tabel lain.

Relasi = FK (tabel anak) ➜ PK (tabel induk)

💡 Tips

Pakai analogi nomor KTP. Nomor itu unik per orang (PK), dan formulir apa pun yang menyebut nomor KTP-mu sedang "menunjuk" ke dirimu (FK). Di rekam medis, nomor rekam medis (No. RM) memainkan peran yang sama.

Tiga Jenis Relasi dalam Basis Data Pelayanan Kesehatan

Relasi punya "kardinalitas", yaitu aturan berapa record di satu tabel yang boleh terhubung dengan record di tabel lain (Elmasri & Navathe, 2016). Ada tiga jenis yang wajib kamu kuasai, dan semuanya muncul di puskesmas atau rumah sakit.

Jenis Relasi	Artinya	Contoh Kasus Kesehatan
One-to-One (1:1)	Satu record terhubung ke tepat satu record lain	Satu pasien memiliki satu data kepesertaan jaminan kesehatan aktif
One-to-Many (1:N)	Satu record induk punya banyak record anak	Satu pasien memiliki banyak kunjungan; satu poli menerima banyak kunjungan
Many-to-Many (M:N)	Banyak record bisa terhubung ke banyak record lain, perlu tabel penghubung	Satu dokter praktik di banyak poli, satu poli diisi banyak dokter

Relasi paling sering kamu temui adalah one-to-many. Pasien yang sama bisa datang berkali-kali, tetapi setiap kunjungan hanya milik satu pasien. Relasi many-to-many butuh perhatian ekstra karena tidak bisa dipasang langsung. Kamu membuat tabel perantara, misalnya jadwal_praktik, yang menyimpan pasangan dokter dan poli.

⚡ Insight Penting

Tabel kunjungan adalah "jantung" basis data pelayanan. Ia menyimpan tiga foreign key sekaligus: pasien, dokter, dan poli. Satu baris kunjungan menjawab pertanyaan siapa, diperiksa siapa, di mana, dan kapan.

Berikut gambaran hubungan antartabel dalam bentuk diagram teks. Panah menunjukkan arah rujukan dari foreign key ke primary key.

 ┌──────────┐ 1      N ┌─────────────┐ N      1 ┌──────────┐
 │  PASIEN  │──────────│  KUNJUNGAN  │──────────│   POLI   │
 │ PK no_rm │          │ PK id_kunj  │          │ PK id_poli│
 └──────────┘          │ FK no_rm    │          └─────┬────┘
                       │ FK id_dokter│                │ 1
 ┌──────────┐ 1      N │ FK id_poli  │                │
 │  DOKTER  │──────────│ tgl, keluhan│          ┌─────┴──────────┐
 │PK id_dokt│          └─────────────┘          │ JADWAL_PRAKTIK │
 └────┬─────┘ 1                              N  │ FK id_dokter   │
      └──────────────────────────────────────────│ FK id_poli     │
                                                 └────────────────┘

Langkah Membangun Relasi Basis Data Pelayanan Kesehatan

Kamu tidak perlu langsung menulis kode. Ikuti lima langkah berikut, urut dari kertas dulu baru ke SQL.

Daftar entitasnya. Dari kasus puskesmas, tuliskan benda yang datanya perlu disimpan: pasien, dokter, poli, kunjungan, diagnosis.

Tentukan primary key tiap tabel. Pilih atribut yang pasti unik dan tidak berubah, misalnya No. RM untuk pasien.

Tentukan jenis relasi. Tanyakan dua arah: "satu pasien boleh punya berapa kunjungan?" lalu "satu kunjungan boleh milik berapa pasien?"

Pasang foreign key di sisi "banyak". Pada relasi 1:N, FK selalu ditaruh di tabel anak. Untuk M:N, buat tabel penghubung.

Tulis dan uji dengan SQL. Buat tabel, isi data contoh, lalu coba masukkan data yang "salah" untuk melihat apakah relasi menolaknya.

Berikut implementasinya dalam SQL. Urutan pembuatan penting: tabel induk dulu, baru tabel anak.

📄 pelayanan_kesehatan.sql

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

CREATE TABLE dokter (
  id_dokter      INT PRIMARY KEY,
  nama_dokter    VARCHAR(100) NOT NULL
);

CREATE TABLE poli (
  id_poli        INT PRIMARY KEY,
  nama_poli      VARCHAR(50) NOT NULL
);

CREATE TABLE kunjungan (
  id_kunjungan   INT PRIMARY KEY,
  no_rm          VARCHAR(10) NOT NULL,
  id_dokter      INT NOT NULL,
  id_poli        INT NOT NULL,
  tgl_kunjungan  DATE NOT NULL,
  keluhan        VARCHAR(200),
  FOREIGN KEY (no_rm)     REFERENCES pasien(no_rm),
  FOREIGN KEY (id_dokter) REFERENCES dokter(id_dokter),
  FOREIGN KEY (id_poli)   REFERENCES poli(id_poli)
);

⚠️ Perhatian

Hati-hati memakai ON DELETE CASCADE pada data klinis. Menghapus satu pasien bisa ikut menghapus seluruh riwayat kunjungannya. Rekam medis punya aturan penyimpanan dan kerahasiaan, jadi baca Permenkes No. 24 Tahun 2022 tentang Rekam Medis sebelum menentukan perilaku hapus.

Membaca Relasi Basis Data Pelayanan Kesehatan dengan JOIN

Data yang sudah terhubung baru terasa gunanya saat kamu menggabungkannya kembali. Perintah JOIN mengikuti "benang" foreign key untuk menyatukan tabel. Tanpa JOIN, tabel kunjungan hanya berisi deretan angka kode yang sulit dibaca manusia.

📄 laporan_kunjungan.sql

SELECT k.tgl_kunjungan,
       p.nama_pasien,
       d.nama_dokter,
       po.nama_poli,
       k.keluhan
FROM kunjungan k
JOIN pasien p  ON k.no_rm     = p.no_rm
JOIN dokter d  ON k.id_dokter = d.id_dokter
JOIN poli  po  ON k.id_poli   = po.id_poli
WHERE k.tgl_kunjungan = '2026-10-05';

Query ini menghasilkan daftar kunjungan hari itu lengkap dengan nama pasien, dokter, dan poli. Ini mirip laporan harian yang mungkin kamu buat di unit rekam medis. Perhatikan pola ON k.no_rm = p.no_rm: kondisi JOIN hampir selalu berupa pasangan foreign key dan primary key.

🔥 Fakta Menarik

Gagasan model relasional berasal dari makalah Codd tahun 1970 yang ditulis di IBM. Lebih dari lima dekade kemudian, prinsip yang sama masih menjadi dasar sistem informasi rumah sakit yang kamu temui sekarang.

Mengembangkan Relasi: Diagnosis dan Tindakan

Kunjungan jarang berhenti pada keluhan saja. Dokter menegakkan diagnosis, lalu kadang melakukan tindakan. Dalam rekam medis, satu kunjungan bisa punya lebih dari satu diagnosis, misalnya hipertensi dan diabetes sekaligus. Itu berarti relasinya satu kunjungan ke banyak diagnosis (1:N). Kamu cukup membuat tabel diagnosis_kunjungan yang berisi id_kunjungan sebagai foreign key dan kode penyakit dari ICD-10.

Pola yang sama berlaku untuk tindakan medis. Setiap kali kebutuhan data baru muncul, tanyakan dua hal: data ini milik siapa, dan berapa banyak yang boleh dimiliki? Jawabannya langsung menunjukkan di tabel mana foreign key harus dipasang. Latihan sederhana ini membuat kamu terbiasa membaca kasus pelayanan kesehatan sebagai jaringan entitas, bukan sekadar daftar kolom. Cobalah menggambar relasinya di kertas dulu sebelum membuka aplikasi DBMS, karena kesalahan rancangan jauh lebih murah diperbaiki di atas kertas daripada setelah ribuan data pasien masuk.

🔍 Analisis: Tanpa Relasi vs Dengan Relasi

❌ Satu tabel besar

Nama pasien ditulis berulang di tiap kunjungan
Ganti nama dokter harus ubah banyak baris
Typo membuat satu orang tercatat sebagai dua pasien

✅ Tabel berelasi

Identitas pasien tersimpan sekali
Perubahan cukup di satu tempat
Foreign key menolak kunjungan untuk pasien yang tidak ada

Poin terakhir itulah yang disebut integritas referensial: basis data sendiri yang menjaga agar setiap rujukan menunjuk ke data yang benar-benar ada (Silberschatz, Korth, & Sudarshan, 2019).

💡 Tips Praktik

Setelah tabel jadi, langsung uji dengan sengaja. Coba INSERT kunjungan dengan No. RM yang belum terdaftar. Kalau relasimu benar, DBMS akan menolak. Di praktikum, kebiasaan menguji data "nakal" seperti ini akan menyelamatkanmu dari banyak galat.

🏁 Kesimpulan

Relasi mengubah tabel-tabel yang berdiri sendiri menjadi satu gambaran utuh pelayanan kesehatan. Ingat empat hal ini:

Primary key mengidentifikasi record, foreign key menghubungkannya ke tabel lain.
Ada tiga jenis relasi: 1:1, 1:N, dan M:N (dengan tabel penghubung).
Tabel kunjungan menyatukan pasien, dokter, dan poli lewat tiga foreign key.
JOIN membaca ulang data yang sudah terhubung menjadi laporan yang mudah dipahami.

Itulah inti relasi basis data pelayanan kesehatan: data tidak diulang, tetap konsisten, dan bisa ditelusuri dari pasien sampai tenaga kesehatan yang menanganinya.

Menurutmu, relasi mana yang paling membingungkan: 1:N atau M:N? Ceritakan di kolom komentar, lalu bagikan artikel ini ke temanmu yang sedang belajar basis data!

💬 Tulis Komentar 🔗 Bagikan Artikel

#BasisData #Database #RMIK #RelasiTabel #PrimaryKey #ForeignKey

🏷 Relasi Basis Data Pelayanan Kesehatan 🏷 Pasien–Dokter–Poli

📚 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.
Silberschatz, A., Korth, H. F., & Sudarshan, S. (2019). Database System Concepts (7th ed.). McGraw-Hill.
Kementerian Kesehatan Republik Indonesia. (2022). Peraturan Menteri Kesehatan Nomor 24 Tahun 2022 tentang Rekam Medis.

📚 Artikel Utama Seri

Daftar Isi Kuliah Basis Data

Artikel ini bagian dari seri Kuliah Basis Data (Artikel 4 dari 16). Lihat seluruh materi di halaman daftar isi.

Buka Daftar Isi ➜

⬅️ Artikel Sebelumnya

Tabel, Atribut, Record: Anatomi Basis Data Relasional

Artikel Selanjutnya ➡️

Ikuti Alur Datanya! Membaca Pelayanan Kesehatan lewat DFD

entitas atribut erd

Siapa Saja Pemainnya? Mengenal Entitas dan Atribut dalam ERD

Apa Itu Entitas dan Atribut ERD?

Langkah Menemukan Entitas dan Atribut ERD dari Kasus Pelayanan Kesehatan

Jenis Atribut dalam Entitas dan Atribut ERD: Dari Simpel sampai Turunan

Contoh Penerapan Entitas dan Atribut ERD pada Pelayanan Rawat Jalan

Menentukan Hubungan: Pelengkap Entitas dan Atribut ERD

Cek Ulang: Daftar Periksa Sebelum Menggambar ERD

Kesimpulan

dfd alur data pelayanan kesehatan

Apa Itu DFD Data Flow Diagram? Peta Perjalanan Data

Empat Simbol DFD Data Flow Diagram yang Wajib Kamu Kenal

Langkah Membuat DFD Data Flow Diagram Pelayanan Kesehatan

Membaca DFD Data Flow Diagram Level 1: Satu Pasien, Satu Perjalanan Data

Dari Alur Data ke Kebutuhan Data: Jembatan Menuju ERD

Kesimpulan: DFD Data Flow Diagram sebagai Peta Sebelum Merancang Data

relasi pelayanan kesehatan

Ketika Pasien, Dokter, dan Poli Saling Terhubung: Relasi pada Pelayanan Kesehatan

Mengapa Relasi Basis Data Pelayanan Kesehatan Itu Penting?

Tiga Jenis Relasi dalam Basis Data Pelayanan Kesehatan

Langkah Membangun Relasi Basis Data Pelayanan Kesehatan

Membaca Relasi Basis Data Pelayanan Kesehatan dengan JOIN

Mengembangkan Relasi: Diagnosis dan Tindakan

🏁 Kesimpulan

Daftar Isi Kuliah Basis Data

java php laravel linux mysql sql bootstrap html css query