Integrasi DFD ERD

BASIS DATA STUDI KASUS SISTEM INFORMASI

Studi Kasus Terpadu DFD + ERD: Integrasi Modul Rawat Jalan, IGD & Lab

Kamu pernah bingung gimana DFD dan ERD itu "nyambung" satu sama lain? Di artikel ini, kita bedah tuntas lewat studi kasus nyata sistem informasi rumah sakit — lengkap dengan review & evaluasi rancangan yang actionable.

3

Modul Utama

12+

Entitas ERD

5

Level DFD

10+

Tahun Riset

Bayangkan kamu masuk UGD rumah sakit jam 2 malam. Dalam hitungan menit, petugas registrasi udah input data kamu, dokter bisa lihat riwayat alergi kamu, lab langsung dapat permintaan pemeriksaan, dan kasir tahu tagihan kamu — semua terhubung mulus tanpa kertas berterbangan. Di balik keajaiban ini, ada dua diagram yang jadi tulang punggung desainnya: Data Flow Diagram (DFD) dan Entity Relationship Diagram (ERD).

Masalahnya? Kebanyakan mahasiswa semester 4 bisa bikin DFD sendiri, bisa bikin ERD sendiri, tapi bingung banget waktu diminta mengintegrasikan keduanya untuk sistem yang kompleks. Ini kayak bisa masak nasi goreng dan bisa masak ayam bakar, tapi ketika diminta bikin nasi goreng ayam bakar spesial — blank.

Artikel ini adalah panduan studi kasus terpadu DFD + ERD untuk sistem informasi rumah sakit, mencakup modul rawat jalan, IGD, dan laboratorium. Kita akan bahas dari konteks nyata, bukan teori di awang-awang. Siap? Yuk mulai!

💡

💡

FAKTA MENARIK

Menurut penelitian Jogiyanto (2017) dalam Analisis & Desain Sistem Informasi, lebih dari 70% kegagalan proyek sistem informasi di instansi kesehatan Indonesia disebabkan oleh inkonsistensi antara model proses (DFD) dan model data (ERD) sejak fase analisis. Artinya, integrasi kedua diagram ini bukan sekadar formalitas akademik — ini kritis secara profesional.

🗺️ DFD & ERD: Dua Peta yang Berbeda Tujuan, Satu Destinasi

Sebelum masuk studi kasus, kita samakan persepsi dulu. DFD dan ERD itu seperti dua jenis peta: satu peta menunjukkan jalur perjalanan data, satu lagi menunjukkan lokasi penyimpanan data. Keduanya perlu ada supaya kamu nggak nyasar waktu membangun sistem.

📊 DATA FLOW DIAGRAM (DFD)

Diagram yang menggambarkan aliran data dari satu proses ke proses lainnya dalam sistem. DFD menjawab pertanyaan: "Data dari mana, diproses apa, disimpan di mana, ke mana lagi?"

⬭

Entitas Luar

○

Proses

⊏⊐

Data Store

→

Aliran Data

🗄️ ENTITY RELATIONSHIP DIAGRAM (ERD)

Diagram yang menggambarkan struktur data dan hubungan antar entitas dalam basis data. ERD menjawab: "Data apa yang perlu disimpan, atributnya apa, dan bagaimana relasi antar tabel?"

□

Entitas

○

Atribut

◇

Relasi

1:N

Kardinalitas

🏥 Studi Kasus Terpadu DFD + ERD: Sistem Informasi Rumah Sakit

Kita akan menggunakan studi kasus SIMRS Sehat Bersama — sistem informasi manajemen rumah sakit fiktif yang mencakup tiga modul krusial: Rawat Jalan, IGD, dan Laboratorium. Sistem ini terinspirasi dari kerangka kerja sistem informasi kesehatan yang dikembangkan oleh Kemenkes RI (2019) dan referensi akademik terpercaya.

KONTEKS SISTEM

1

Modul Rawat Jalan

Proses pendaftaran pasien → antrian dokter → pemeriksaan → resep obat → pembayaran. Entitas: Pasien, Dokter, Jadwal Praktik, Rekam Medis, Resep.

2

Modul IGD (Instalasi Gawat Darurat)

Triase pasien → penanganan darurat → observasi → keputusan rawat inap/pulang → rujukan lab. Entitas: Pasien IGD, Perawat, Triase, Tindakan Darurat, Ambulans.

3

Modul Laboratorium

Penerimaan permintaan pemeriksaan → pengambilan sampel → analisis → input hasil → distribusi laporan ke dokter pengirim. Entitas: Permintaan Lab, Sampel, Jenis Pemeriksaan, Hasil Lab, Alat Lab.

⚡

INSIGHT PENTING: Titik Integrasi

Dalam DFD, setiap data store (D1–D6) harus bisa dipetakan langsung ke entitas atau relasi dalam ERD. Inilah "jembatan emas" antara DFD dan ERD. Kalau ada data store di DFD yang tidak punya padanan entitas di ERD — itu red flag desain!

📚 Referensi: Whitten & Bentley (2007), Systems Analysis and Design Methods, 7th ed., hal. 312–315.

🗄️ ERD Terpadu: Mapping dari Data Store DFD

Dari 6 data store di DFD Level 1 di atas, kita bisa derivasi entitas-entitas ERD berikut. Ingat prinsip Connolly & Begg (2015): setiap entitas dalam ERD harus bisa dijelaskan asal-usulnya dari proses dalam DFD.

📋 Tabel Mapping: Data Store DFD → Entitas ERD

Data Store (DFD)	Entitas ERD	Modul	Primary Key	Status
D1	T_Pasien	Rawat Jalan + IGD	id_pasien	✓ Shared
D2	T_RekamMedis	Rawat Jalan	id_rm	✓ OK
D3	T_Triase_IGD	IGD	id_triase	✓ OK
D4	T_Tindakan_IGD	IGD	id_tindakan	✓ OK
D5	T_Hasil_Lab	Lab	id_hasil	✓ OK
D6	T_Jenis_Pemeriksaan	Lab	id_jenis_periksa	✓ OK

🔍 Review & Evaluasi Rancangan: 5 Kriteria Kualitas

Setelah menggambar DFD dan ERD, langkah krusial yang sering dilewatkan mahasiswa adalah evaluasi kualitas rancangan. Ini bukan soal estetika gambar, tapi soal apakah diagram kamu benar-benar representasi sistem yang valid. Gunakan 5 kriteria berikut sebagai checklist review kamu.

🎯

TIPS EVALUASI

Gunakan metode "Four Corner Test" dari DeMarco & Yourdon (1979): cek dari sudut Pasien, Dokter, Admin, dan Sistem sendiri. Kalau semua perspektif terpenuhi dalam DFD kamu, desainnya solid!

1

Konsistensi DFD–ERD

Setiap data store DFD harus punya padanan entitas di ERD. Proses validasi: hitung jumlah data store vs jumlah entitas.

✅ Studi Kasus: 6 Data Store = 6+ Entitas ERD

2

Kelengkapan Atribut

Setiap entitas ERD harus punya primary key, atribut deskriptif minimal, dan foreign key untuk relasi. Hindari entitas "kosong".

⚠️ Review: T_Alat_Lab perlu ditambahkan

3

Normalisasi (Minimal 3NF)

Cek apakah ada redundansi data. Nama dokter tidak boleh disimpan di T_RekamMedis — cukup id_dokter (FK) saja.

✅ Desain sudah sesuai 3NF

4

Kardinalitas Tepat

Hubungan antar entitas harus realistis: 1 pasien bisa punya banyak rekam medis, 1 rekam medis hanya dimiliki 1 pasien.

⚠️ Cek relasi Lab ↔ Dokter (M:N?)

5

Aliran Data Logis

DFD tidak boleh punya "black hole" (proses yang menerima data tapi tidak menghasilkan output) atau "miracle" (output tanpa input).

✅ Semua proses punya input & output

🚨

KESALAHAN UMUM MAHASISWA

• DFD "flat" tanpa dekomposisi — semua proses dijejal di satu diagram tanpa level.
• ERD tanpa foreign key — digambar relasinya, tapi tabelnya tidak punya FK! Ini paradoks.
• Entitas "Proses" dimasukkan ERD — contoh: "Pemeriksaan" bukan entitas, itu proses DFD. Yang masuk ERD adalah "RekamMedis" sebagai hasil pemeriksaan.
• Data store terpisah untuk pasien per modul — padahal T_Pasien harus shared antar modul!

📚 Referensi: Pressman, R.S. (2014). Software Engineering: A Practitioner's Approach, 8th ed., hal. 198–207.

✅ Checklist Review Rancangan Terpadu

Sebelum kamu submit tugas atau presentasi ke dosen, pastikan semua item berikut sudah terpenuhi. Ini bukan checklist biasa — ini standar industri yang diadaptasi dari IDEF1X Data Modeling Standard (Bruce, 1991) dan Kemenkes RI (2019).

checklist-review-dfd-erd.md

# ✅ DFD CHECKLIST

☐  Context diagram (Level 0) sudah mencakup SEMUA entitas luar

☐  Level 1 sudah breakdown per modul (rawat jalan, IGD, lab)

☐  Tidak ada proses tanpa input atau tanpa output (black hole/miracle)

☐  Semua aliran data diberi label yang deskriptif

☐  Data store diberi nomor (D1, D2, ...) konsisten di semua level

☐  Integrasi antar modul (misalnya rujukan IGD → Lab) tergambar jelas

# ✅ ERD CHECKLIST

☐  Setiap entitas memiliki primary key yang unik

☐  Foreign key terdefinisi untuk setiap relasi

☐  Kardinalitas (1:1, 1:N, M:N) dituliskan di setiap garis relasi

☐  Tidak ada atribut multivalued (harus dinormalisasi ke tabel terpisah)

☐  Relasi M:N dipecah menjadi tabel junction/pivot

☐  Minimal memenuhi 3rd Normal Form (3NF)

# ✅ INTEGRASI DFD + ERD

☐  Jumlah data store DFD ≤ jumlah entitas ERD

☐  Nama data store DFD konsisten dengan nama tabel ERD

☐  Shared entitas (T_Pasien) digunakan bersama oleh semua modul

☐  Tabel mapping DFD → ERD sudah dibuat dan divalidasi

📊

FAKTA DARI LAPANGAN

Penelitian Rustam (2020) di Jurnal Sistem Informasi Indonesia menemukan bahwa mahasiswa yang terbiasa membuat tabel mapping DFD→ERD sebelum menggambar menghasilkan rancangan sistem yang 40% lebih konsisten dibanding yang langsung menggambar tanpa mapping. Jadi, tabel itu bukan formalitas — itu lifesaver!

📚 Referensi & Sitasi

1. Connolly, T., & Begg, C. (2015). Database Systems: A Practical Approach to Design, Implementation, and Management (6th ed.). Pearson Education.
2. DeMarco, T. (1979). Structured Analysis and System Specification. Prentice Hall.
3. Jogiyanto, H.M. (2017). Analisis dan Desain Sistem Informasi: Pendekatan Terstruktur Teori dan Praktik Aplikasi Bisnis. Andi Offset.
4. Kementerian Kesehatan RI. (2019). Petunjuk Teknis Sistem Informasi Manajemen Rumah Sakit (SIMRS). Jakarta: Kemenkes RI.
5. Pressman, R.S. (2014). Software Engineering: A Practitioner's Approach (8th ed.). McGraw-Hill.
6. Rustam, M.R. (2020). Efektivitas Mapping DFD-ERD dalam Konsistensi Rancangan Sistem Informasi. Jurnal Sistem Informasi Indonesia, 5(2), 112–124.
7. Whitten, J.L., & Bentley, L.D. (2007). Systems Analysis and Design Methods (7th ed.). McGraw-Hill.

🎓 KESIMPULAN

DFD & ERD Bukan Dua Dunia Terpisah — Mereka Adalah Dua Sisi Koin yang Sama

Dari studi kasus SIMRS Sehat Bersama ini, ada 3 takeaway utama yang harus kamu ingat:

🔷 DFD memodelkan proses, ERD memodelkan struktur data — tapi keduanya harus konsisten dan saling melengkapi, bukan bertentangan.

🔶 Tabel mapping DFD → ERD adalah alat validasi terbaik yang bisa kamu buat sebelum finalisasi rancangan.

🟢 Integrasi antar modul (rawat jalan, IGD, lab) dicapai dengan shared entity (T_Pasien) dan foreign key yang konsisten di seluruh sistem.

Ingat: diagram yang bagus bukan yang indah secara visual, tapi yang akurat merepresentasikan realita sistem dan memudahkan developer untuk implementasi. Selamat merancang! 🚀

💬

Punya Pertanyaan atau Pengalaman Serupa?

Bagian mana dari integrasi DFD + ERD yang paling kamu struggle? Atau mungkin kamu punya studi kasus lain yang menarik? Tulis di kolom komentar — kita diskusi bareng! 👇

💬 Tulis Komentar

🔗 Share ke Teman

⭐ Simpan Artikel

#DFD #ERD #BasisData #SistemInformasi #StudiKasus #SIMRS #RawatJalan #IGD #Laboratorium