Entity Relationship Diagram ERD

Basis Data · Semester 4

Basis Data Relasional & ERD:
Panduan Lengkap dari Nol

Dari entitas, atribut, relasi, hingga kardinalitas — semua yang kamu butuhkan untuk nguasain ERD sebelum UTS menyerang.

3

Tipe Kardinalitas

2

Notasi ERD

1

Studi Kasus Rekam Medis

#ERD #BasisData #RelasiKardinalitas #NotasiChen #SistemInformasi

Bayangkan kamu diminta membangun sebuah sistem informasi rumah sakit — ada data pasien, dokter, obat, jadwal periksa, rekam medis, tagihan... tanpa peta, kamu pasti nyasar sebelum nulis baris kode pertama. Nah, di sinilah Entity-Relationship Diagram (ERD) hadir sebagai "peta bumi"-nya basis data. Satu diagram yang menyelamatkan ratusan jam debugging.

Kalau kamu lagi duduk di semester 4 jurusan Sistem Informasi, Ilmu Komputer, atau sejenisnya — artikel ini ditulis khusus untukmu. Kita akan bahas ERD dari akarnya: entitas, atribut, relasi, kardinalitas (1:1, 1:N, M:N), notasi Chen vs Crow's Foot, sampai implementasi nyata di studi kasus rekam medis. Pakai bahasa yang manusiawi, bukan kalimat buku teks yang bikin ngantuk.

Siap? Grab kopi dulu, terus kita mulai. ☕

📋 Daftar Isi

1. Pengertian ERD (Entity-Relationship Diagram)
2. Manfaat ERD dalam Perancangan Basis Data
3. Komponen Utama ERD: Entitas, Atribut, Relasi
4. Kardinalitas: 1:1, 1:N, M:N
5. Notasi Chen vs Crow's Foot
6. Studi Kasus: ERD Rekam Medis
7. Kesimpulan

Pengertian ERD (Entity-Relationship Diagram)

Entity-Relationship Diagram (ERD) adalah representasi visual dari struktur data dalam suatu sistem, yang menggambarkan entitas-entitas, atribut-atributnya, serta hubungan (relasi) antar entitas tersebut. Konsep ini pertama kali diperkenalkan oleh Peter Pin-Shan Chen pada tahun 1976 dalam makalahnya berjudul "The Entity-Relationship Model — Toward a Unified View of Data" yang dipublikasikan di ACM Transactions on Database Systems (Chen, 1976).

Kalau mau analogi sederhananya: ERD itu seperti denah rumah sebelum kamu membangunnya. Kamu nggak akan mungkin menyuruh tukang langsung pasang bata tanpa tahu di mana kamar tidur, kamar mandi, atau dapur — kan? ERD adalah "denah" database kamu, dan tanpanya, developer bisa salah bangun struktur tabel dari awal.

📖 Definisi Formal

"ERD adalah model konseptual yang merepresentasikan struktur logis dari sebuah basis data menggunakan entitas, atribut, dan relasi beserta batasan-batasannya."

— Elmasri & Navathe, Fundamentals of Database Systems, 7th ed. (2016)

💡

Fakta Menarik

Makalah Peter Chen (1976) tentang Entity-Relationship Model adalah salah satu makalah ilmu komputer yang paling banyak dikutip sepanjang masa — lebih dari 15.000 sitasi di Google Scholar. Artinya, konsep yang kamu pelajari hari ini sudah terbukti relevan selama hampir 50 tahun!

Manfaat ERD dalam Perancangan Basis Data

Menurut Ramakrishnan & Gehrke (2003) dalam Database Management Systems, ERD memberikan fondasi yang kuat untuk proses desain basis data karena mampu mengabstraksikan kompleksitas dunia nyata ke dalam representasi yang terstruktur. Berikut manfaat utamanya:

1

Komunikasi Antar Tim

ERD menjadi "bahasa universal" antara analis bisnis, DBA, dan developer. Satu diagram bisa mewakili ribuan baris dokumen spesifikasi.

2

Deteksi Kesalahan Desain Lebih Awal

Memperbaiki ERD jauh lebih murah daripada memperbaiki struktur database yang sudah jalan — ibarat lebih mudah hapus goresan pensil di denah daripada membongkar tembok yang sudah dibangun.

3

Dasar Normalisasi Database

ERD yang baik mempermudah proses normalisasi (1NF, 2NF, 3NF) karena relasi dan dependensi antar atribut sudah tergambar jelas sejak awal.

4

Dokumentasi Sistem

ERD adalah dokumentasi hidup yang mempermudah onboarding developer baru dan maintenance jangka panjang. Database tanpa ERD = kode tanpa komentar.

Komponen Utama ERD: Entitas, Atribut, Relasi

ERD dibangun dari tiga komponen fundamental. Memahami ketiganya secara mendalam adalah kunci sebelum kamu bisa menggambar ERD yang benar (Connolly & Begg, 2015).

🗂️

Entitas

Objek/benda nyata yang memiliki keberadaan mandiri dan perlu disimpan datanya. Digambarkan sebagai persegi panjang dalam notasi Chen.

Contoh:

PASIEN, DOKTER, OBAT, RUANGAN

🏷️

Atribut

Properti/karakteristik yang mendeskripsikan entitas. Digambarkan sebagai elips/oval dalam notasi Chen. Atribut kunci (Primary Key) digaris bawahi.

Contoh:

no_pasien, nama, tanggal_lahir, alamat

🔗

Relasi

Hubungan/asosiasi antar entitas. Digambarkan sebagai belah ketupat (diamond) dalam notasi Chen. Relasi bisa punya atribut sendiri.

Contoh:

PASIEN — MENJALANI — PEMERIKSAAN

Tipe-Tipe Atribut dalam ERD

Tidak semua atribut itu sama. Silberschatz, Korth & Sudarshan (2020) dalam Database System Concepts mengklasifikasikan atribut menjadi beberapa tipe:

Tipe Atribut	Deskripsi	Contoh	Notasi Chen
Simple	Nilai tunggal, tak bisa dibagi lagi	umur, jenis_kelamin	Oval biasa
Composite	Terdiri dari beberapa sub-atribut	nama_lengkap (depan + belakang), alamat	Oval dengan oval anak
Multivalued	Dapat memiliki lebih dari satu nilai	no_telepon, email	Oval ganda (double oval)
Derived	Nilai dihitung dari atribut lain	usia (dari tgl_lahir)	Oval putus-putus
Key	Pengidentifikasi unik setiap instance entitas	no_pasien, nik	Oval + teks digaris bawahi

Kardinalitas ERD: 1:1, 1:N, dan M:N

Kardinalitas mendefinisikan jumlah instance dari satu entitas yang bisa berelasi dengan instance dari entitas lain. Ini adalah salah satu konsep paling penting dan paling sering muncul di ujian! (Date, 2019). Ada tiga tipe utama:

1:1 One-to-One

Satu instance entitas A berelasi dengan tepat satu instance entitas B, dan sebaliknya. Analogi: satu orang punya satu NIK, satu NIK dimiliki satu orang.

PEGAWAI

1

─────── memiliki ───────

1

LOKER

📌 Contoh riil: PASIEN ↔ REKAM_MEDIS_UTAMA (satu pasien, satu nomor rekam medis)

1:N One-to-Many

Satu instance entitas A berelasi dengan banyak instance entitas B, namun satu instance B hanya berelasi dengan satu instance A. Relasi paling umum ditemukan dalam database!

DOKTER

1

─────── menangani ───────

N

PASIEN

📌 Contoh riil: Satu DOKTER menangani banyak PASIEN, tapi satu PASIEN ditangani satu dokter spesialis utama

M:N Many-to-Many

Banyak instance entitas A berelasi dengan banyak instance entitas B. Dalam implementasi fisik, relasi M:N selalu dipecah dengan tabel penghubung (junction table / associative entity).

PASIEN

M

─────── mendapat ───────

N

OBAT

📌 Contoh riil: Satu PASIEN bisa mendapat banyak OBAT; satu OBAT bisa diberikan ke banyak PASIEN. Diselesaikan dengan tabel RESEP.

🎯

Tips Krusial untuk Ujian

Relasi M:N tidak bisa langsung diimplementasikan ke tabel SQL! Kamu harus memecahnya menjadi dua relasi 1:N dengan tabel asosiatif di tengah. Ini adalah kesalahan yang paling sering dilakukan mahasiswa semester 4. Pastikan kamu paham ini sebelum praktikum!

Notasi ERD: Chen vs Crow's Foot

Ada dua notasi utama yang dipakai untuk menggambar ERD. Keduanya valid — perbedaannya hanya pada cara visual merepresentasikan entitas dan kardinalitas (Teorey et al., 2011).

Chen

Akademik / Konseptual

• Entitas = Persegi Panjang
• Relasi = Belah Ketupat (Diamond)
• Atribut = Oval/Elips
• Atribut Key = Oval + Garis Bawah
• Atribut Multivalued = Double Oval
• Atribut Derived = Oval Putus-putus
• Weak Entity = Double Rectangle

✅ Lebih ekspresif — cocok untuk desain konseptual dan tugas kuliah

Crow's Foot

Industri / Tools

• Entitas = Tabel/Kotak
• Relasi = Garis penghubung langsung
• One (1) = Garis tegak lurus ( | )
• Many (N) = "Kaki gagak" (tiga garis)
• Zero or One = Lingkaran + garis tegak
• One and Only One = Dua garis tegak lurus
• Zero or Many = Lingkaran + kaki gagak

✅ Lebih compact — default di MySQL Workbench, Lucidchart, draw.io

🔍

Insight Penting

Di dunia industri, notasi Crow's Foot lebih populer karena didukung langsung oleh tools seperti MySQL Workbench, dbdiagram.io, ERDPlus, dan Lucidchart. Namun di lingkungan akademik, dosen umumnya masih menggunakan Notasi Chen karena lebih eksplisit dalam menggambarkan atribut. Kuasai keduanya!

Studi Kasus: ERD Rekam Medis Rumah Sakit

Sekarang saatnya kita terapkan semua konsep di atas ke dalam kasus nyata. Sistem rekam medis adalah contoh klasik yang sering dipakai dalam pembelajaran basis data karena melibatkan berbagai tipe relasi sekaligus (Hoffer, Ramesh & Topi, 2016).

Identifikasi Entitas & Atribut

📦 PASIEN

no_rm, nama_pasien, tanggal_lahir, jenis_kelamin, alamat, no_telepon (mv), golongan_darah, usia*

📦 DOKTER

id_dokter, nama_dokter, spesialisasi, no_sip, jadwal_praktik (mv), no_telepon

📦 PEMERIKSAAN

id_pemeriksaan, tanggal_periksa, keluhan, diagnosa, tekanan_darah, suhu, catatan

📦 OBAT

id_obat, nama_obat, jenis_obat, satuan, dosis_standar, stok

📦 RESEP (Tabel Asosiatif M:N)

id_resep, id_pemeriksaan (FK), id_obat (FK), jumlah, aturan_pakai

📦 RUANG_RAWAT

id_ruang, nama_ruang, kelas, kapasitas, lantai

Ket: (mv) = multivalued; * = derived attribute; (FK) = Foreign Key

Relasi & Kardinalitas dalam Sistem Rekam Medis

Entitas A	Relasi	Entitas B	Kardinalitas	Keterangan
PASIEN	MENJALANI	PEMERIKSAAN	1 : N	Satu pasien bisa beberapa kali periksa
DOKTER	MELAKUKAN	PEMERIKSAAN	1 : N	Satu dokter melakukan banyak pemeriksaan
PEMERIKSAAN	MENGHASILKAN	RESEP	1 : N	Satu pemeriksaan bisa punya banyak resep
RESEP	MEMUAT	OBAT	M : N	Diselesaikan dengan tabel RESEP_DETAIL
PASIEN	MENEMPATI	RUANG_RAWAT	M : N	Pasien bisa pindah ruang; ruang dipakai bergantian

Visualisasi ERD Rekam Medis (Notasi Chen — Disederhanakan)

ERD Rekam Medis Disederhanakan — Notasi Chen (visualisasi tidak mencakup semua atribut)

🔬 Analisis ERD Rekam Medis

⚡ Titik Kritis M:N

Relasi PEMERIKSAAN-OBAT adalah M:N yang wajib dipecah menjadi tabel RESEP sebagai entitas asosiatif dengan atribut tambahan (jumlah, aturan_pakai).

🏗️ Weak Entity Kandidat

PEMERIKSAAN bisa dikategorikan sebagai weak entity dari PASIEN — keberadaannya bergantung pada adanya pasien, dan id_pemeriksaan hanya unik dalam konteks satu pasien.

🛠️

Rekomendasi Tools Gratis untuk Buat ERD

🔹 draw.io / diagrams.net — free, support notasi Chen & Crow's Foot, bisa simpan ke Google Drive
🔹 dbdiagram.io — code-based ERD dengan output visual Crow's Foot yang cantik
🔹 ERDPlus — khusus ERD akademik, mirip notasi Chen, cocok untuk tugas
🔹 MySQL Workbench — reverse-engineer database ke ERD otomatis, standar industri

📚 Referensi & Daftar Pustaka

1. Chen, P. P. S. (1976). The Entity-Relationship Model — Toward a Unified View of Data. ACM Transactions on Database Systems, 1(1), 9–36. https://doi.org/10.1145/320434.320440
2. Connolly, T., & Begg, C. (2015). Database Systems: A Practical Approach to Design, Implementation, and Management (6th ed.). Pearson Education.
3. Date, C. J. (2019). Database Design and Relational Theory: Normal Forms and All That Jazz (2nd ed.). Apress.
4. Elmasri, R., & Navathe, S. B. (2016). Fundamentals of Database Systems (7th ed.). Pearson Education.
5. Hoffer, J. A., Ramesh, V., & Topi, H. (2016). Modern Database Management (12th ed.). Pearson Education.
6. Ramakrishnan, R., & Gehrke, J. (2003). Database Management Systems (3rd ed.). McGraw-Hill.
7. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill Education.
8. Teorey, T. J., Lightstone, S., Nadeau, T., & Jagadish, H. V. (2011). Database Modeling and Design: Logical Design (5th ed.). Morgan Kaufmann.

✅ Kesimpulan

ERD adalah Fondasi, Bukan Formalitas

Setelah membaca artikel ini, kamu sudah punya pemahaman komprehensif tentang Entity-Relationship Diagram (ERD) — mulai dari komponen dasarnya (entitas, atribut, relasi), tiga tipe kardinalitas (1:1, 1:N, M:N), perbedaan notasi Chen dan Crow's Foot, hingga implementasinya dalam sistem rekam medis nyata.

Poin-poin kunci yang wajib kamu ingat:

• Relasi M:N selalu dipecah dengan tabel asosiatif saat implementasi fisik
• Primary Key digaris bawahi dalam notasi Chen
• Notasi Chen lebih cocok untuk desain konseptual; Crow's Foot untuk tools industri
• ERD bukan tugas dosen semata — ini adalah dokumen hidup yang menyelamatkan proyekmu

💬

Yuk, Diskusi Bareng!

Masih ada yang bingung soal ERD, kardinalitas, atau cara menggambar studi kasus tertentu? Drop pertanyaanmu di kolom komentar — kita bahas bareng! Atau kalau artikel ini bermanfaat, share ke teman sekelas supaya makin banyak yang paham sebelum praktikum. 🚀

✍️ Tulis Komentar 🔔 Subscribe Blog Ini 📤 Share Artikel

#BasisData #ERD #EntityRelationship #Kardinalitas #NotasiChen #CrowsFootNotation #RekamMedis #SistemInformasi #DatabaseDesign #Semester4

Data Flow Diagram DFD

BASIS DATA SIMRS DFD D3 RMIK

Basis Data Relasional — DFD: Konsep, Komponen & Studi Kasus SIMRS

Pernah nggak kamu merasa bingung gimana data pasien bisa mengalir dari loket pendaftaran ke dokter, lalu ke apotek — semuanya nyambung? Jawabannya ada di DFD dan konsep relasional. Yuk kita bedah tuntas!

3

Level DFD

4

Simbol Utama

1

Studi Kasus SIMRS

10+

Tahun Pengalaman

Bayangin kamu kerja di rumah sakit. Setiap hari, ratusan pasien masuk — mendaftar, diperiksa dokter, dapat resep, tebus obat di apotek. Semua data itu harus mengalir dengan benar, nyambung satu sama lain, dan nggak boleh ada yang hilang. Nah, inilah dunia nyata dari basis data relasional dan Data Flow Diagram (DFD).

Di semester 4 ini, kamu mulai ketemu konsep yang agak serius tapi super penting buat karir RMIK kamu: gimana cara memodelkan aliran data sebelum diimplementasikan ke sistem nyata. DFD adalah "peta jalan" itu — dan kalau kamu bisa baca DFD, kamu bisa baca otak si perancang sistem.

Artikel ini akan membahas konsep relasional sebagai fondasi, lalu kita bedah komponen & simbol DFD, terus naik level dari DFD Konteks → Level 0 → Level 1, dan semuanya kita landing di studi kasus SIMRS (Sistem Informasi Manajemen Rumah Sakit) yang relevan banget buat jurusanmu. Siap? Gas! 🚀

Apa Itu Basis Data Relasional? Fondasi yang Wajib Kamu Paham

Basis data relasional (relational database) adalah model penyimpanan data yang mengorganisasikan informasi ke dalam tabel-tabel (relasi) yang saling terhubung melalui kunci (key). Konsep ini pertama kali diperkenalkan oleh E.F. Codd dari IBM pada tahun 1970 dalam makalah monumentalnya "A Relational Model of Data for Large Shared Data Banks" (Codd, 1970).

Analogi paling gampang: bayangin spreadsheet Excel yang kamu buat. Satu sheet = satu tabel. Kalau kamu punya sheet "Pasien" dan sheet "Kunjungan", dan keduanya terhubung lewat kolom ID_Pasien — itulah inti dari model relasional!

🗂️

Relasi (Tabel)

Kumpulan baris dan kolom yang merepresentasikan satu entitas data (misal: tabel Pasien).

🔑

Primary Key

Atribut unik pengidentifikasi setiap baris. Tidak boleh null dan tidak boleh duplikat.

🔗

Foreign Key

Kolom yang merujuk ke primary key tabel lain — inilah yang membuat tabel "berelasi".

📐

Integritas Referensial

Aturan yang menjamin foreign key selalu menunjuk ke data yang valid di tabel induk.

📊 Contoh Tabel Relasional — SIMRS

TABEL: tb_pasien
┌──────────────┬──────────────────┬───────────┐
│ id_pasien (PK) │ nama_pasien │ tgl_lahir │
├──────────────┼──────────────────┼───────────┤
│ P001 │ Budi Santoso │ 1990-05-12│
│ P002 │ Siti Rahayu │ 1985-11-23│
└──────────────┴──────────────────┴───────────┘

TABEL: tb_kunjungan
┌──────────┬─────────────────┬────────────────┐
│ id_kunjungan │ id_pasien (FK) │ tgl_kunjungan │
├──────────┬─────────────────┬────────────────┤
│ K001 │ P001 │ 2024-03-15 │
└──────────┴─────────────────┴────────────────┘

id_pasien di tb_kunjungan adalah Foreign Key yang menghubungkan ke tb_pasien → itulah relasi!

💡

FAKTA MENARIK

Lebih dari 70% DBMS yang digunakan di industri kesehatan Indonesia (termasuk SIMRS) berbasis relasional — MySQL, PostgreSQL, atau SQL Server. Jadi memahami konsep relasional bukan cuma teori; itu skill yang langsung kepake di dunia kerja! (PERSI, 2022)

Menurut Silberschatz et al. (2020) dalam bukunya Database System Concepts, model relasional unggul karena kemampuannya menjaga konsistensi data melalui constraints dan kemudahan query menggunakan SQL. Hal ini menjadikan model relasional sebagai pilihan utama untuk sistem informasi kompleks seperti SIMRS.

DFD (Data Flow Diagram): Peta Aliran Data Sistem Kamu

DFD (Data Flow Diagram) adalah alat pemodelan sistem yang menggambarkan bagaimana data bergerak melalui sebuah sistem informasi — dari mana datangnya, diproses apa, disimpan di mana, dan kemana hasilnya dikirim. Diperkenalkan oleh DeMarco & Yourdon (1979) dan kemudian dipopulerkan oleh Gane & Sarson (1979), DFD menjadi standar de facto dalam analisis sistem.

Kalau basis data relasional adalah "struktur gudang data", maka DFD adalah "denah jalan keluar-masuk barang di gudang itu". Keduanya saling melengkapi dalam perancangan sistem informasi.

🎯 Mengapa Analis Sistem Butuh DFD?

✅ Komunikasi Tim

DFD bisa dipahami analis, programmer, dan klien (non-teknis) — bahasa visual universal.

✅ Identifikasi Kebutuhan

Memperlihatkan input/output yang dibutuhkan sebelum coding dimulai — hemat waktu dan biaya.

✅ Dokumentasi Sistem

Menjadi dokumen resmi yang wajib ada dalam skripsi/TA dan proposal proyek IT.

✅ Panduan Database Design

Data store di DFD menjadi acuan tabel di database — koneksi langsung ke basis data relasional!

Komponen & Simbol DFD: 4 Elemen yang Wajib Kamu Hafal

DFD menggunakan 4 komponen utama. Ada dua notasi yang sering dipakai: Yourdon-DeMarco dan Gane-Sarson. Di Indonesia, kebanyakan buku teks dan soal ujian menggunakan Yourdon-DeMarco, jadi kita fokus ke situ ya.

1

External Entity (Entitas Eksternal) Persegi Panjang

Sumber atau tujuan data dari luar sistem. Disimbolkan dengan kotak persegi (rectangle). Entitas eksternal TIDAK diproses oleh sistem — mereka hanya memberi atau menerima data.

Contoh SIMRS: Pasien, Dokter, BPJS, Dinas Kesehatan

2

Process (Proses) Lingkaran / Bubble

Transformasi atau manipulasi data dalam sistem. Disimbolkan dengan lingkaran (circle) di notasi Yourdon, atau persegi rounded di notasi Gane-Sarson. Diberi nomor dan nama aktif (kata kerja).

Contoh SIMRS: 1.0 Pendaftaran Pasien, 2.0 Pemeriksaan, 3.0 Penebusan Resep

3

Data Store (Penyimpanan Data) Dua garis sejajar

Tempat data disimpan (sementara atau permanen). Disimbolkan dengan dua garis horizontal sejajar. Di database relasional, setiap data store biasanya merepresentasikan satu tabel.

Contoh SIMRS: D1 Data Pasien, D2 Data Dokter, D3 Rekam Medis, D4 Obat

4

Data Flow (Aliran Data) Anak Panah Berlabel

Jalur perpindahan data antar komponen. Disimbolkan dengan anak panah berarah dengan label nama data yang mengalir. Satu aliran = satu jenis paket data.

Contoh SIMRS: Data Identitas Pasien, Nomor Antrian, Resep Dokter, Laporan Kunjungan

Komponen	Yourdon-DeMarco	Gane-Sarson	Keterangan
External Entity	Kotak/Rectangle	Kotak/Rectangle	Sama di kedua notasi
Proses	Lingkaran (circle)	Persegi rounded	Beda di sini!
Data Store	Dua garis sejajar terbuka	Kotak dengan bagian kiri diarsir	Beda bentuk, sama fungsi
Data Flow	Anak panah berlabel	Anak panah berlabel	Sama di kedua notasi

⚡

TIPS PENTING — ATURAN EMAS DFD

• Proses tidak boleh langsung terhubung ke proses lain tanpa aliran data
• Data store tidak boleh langsung terhubung ke external entity — harus lewat proses
• Setiap proses minimal memiliki satu input dan satu output
• Nama aliran data harus berupa kata benda, bukan kata kerja
• Nomor proses menunjukkan urutan decomposisi, bukan urutan eksekusi

DFD Konteks (Level 0): "Foto dari Satelit" Sistem Kamu

DFD Konteks (Context Diagram) adalah tingkatan tertinggi DFD — paling abstrak dan paling sederhana. Seluruh sistem digambarkan sebagai SATU PROSES TUNGGAL (biasanya diberi nomor 0), dikelilingi oleh entitas-entitas eksternal yang berinteraksi dengannya.

Bayangkan kamu lagi lihat peta kota dari Google Maps dengan zoom paling jauh — kamu bisa lihat kota mana yang ada, tapi tidak bisa lihat jalan kecilnya. Itulah DFD Konteks: gambaran besar, scope jelas, tanpa detail internal.

🗺️ DFD KONTEKS — SIMRS (Notasi Deskriptif)

[PASIEN] ──── Data Registrasi ────► [DOKTER] ──── Data Pemeriksaan ───► ┌────────────────────┐ [PETUGAS APOTEK] ──── Data Penebusan ────► │ │ │ 0. SIMRS (Sistem │ ◄──── Kartu Berobat ──── [PASIEN] │ Informasi Manajemen│ ◄──── Rekam Medis ────── [DOKTER] │ Rumah Sakit) │ ◄──── Laporan Stok ───── [PETUGAS APOTEK] │ │ ◄──── Lap. Kunjungan ─── [MANAJEMEN RS] └────────────────────┘ ◄──── Data Klaim ─────── [BPJS]

Catatan: Pada DFD Konteks, semua proses internal SIMRS terwakili oleh satu proses "0" saja. Detail proses akan dijabarkan di level berikutnya.

Karakteristik DFD Konteks menurut Pressman (2014) dalam Software Engineering: A Practitioner's Approach:

• Hanya ada satu proses yang merepresentasikan keseluruhan sistem
• Menampilkan semua external entity yang berinteraksi dengan sistem
• Menampilkan semua aliran data di batas sistem (system boundary)
• Tidak menampilkan data store (penyimpanan internal)
• Digunakan untuk kesepakatan scope dengan klien/stakeholder

DFD Level 0 & Level 1 Studi Kasus SIMRS: Zoom In Sampai Detail

Proses "0" di DFD Konteks sekarang kita pecah (decompose) menjadi beberapa proses lebih kecil. Inilah yang disebut DFD Level 0 atau sering juga disebut Overview Diagram. Lanjut lagi dipecah → DFD Level 1 (dan seterusnya sampai proses cukup primitif untuk diimplementasikan).

🗺️ Analogi Zoom Maps

🛰️

DFD Konteks

Zoom 1x — Lihat kota dari luar angkasa

✈️

DFD Level 0

Zoom 5x — Lihat kecamatan dan jalan utama

🚗

DFD Level 1

Zoom 20x — Lihat gang dan nomor rumah

DFD Level 0 — SIMRS

DFD Level 0 menampilkan proses-proses utama dalam SIMRS beserta interaksinya satu sama lain, dengan entitas eksternal, dan dengan data store. Untuk SIMRS, kita bisa identifikasi 4 proses utama:

📊 DFD LEVEL 0 — SIMRS (Ringkasan Proses Utama)

[PASIEN] ──Data Registrasi──► (1.0 Pendaftaran) ──► D1 Data Pasien │ Nomor RM ◄──┘ │ [DOKTER] ──────────────────► (2.0 Pemeriksaan) ──► D2 Rekam Medis ◄──────Rekam Medis────── │ Resep│ ▼ [PETUGAS APT] ◄────────────── (3.0 Penebusan Resep) ──► D3 Data Obat │ Lap. Kunjungan│ ▼ [MANAJEMEN] ◄────────────── (4.0 Pelaporan) ◄── D4 Data Kunjungan [BPJS] ◄──────Data Klaim──────

DFD Level 1 — Explode Proses 1.0 (Pendaftaran Pasien)

Sekarang kita explode (pecah lebih detail) proses 1.0 Pendaftaran. Di level 1, proses ini dipecah menjadi sub-proses yang lebih spesifik. Inilah yang persis akan kamu kerjakan dalam TA/Skripsi nanti!

🔍 DFD LEVEL 1 — EXPLODE PROSES 1.0 PENDAFTARAN

[PASIEN] │ │──Data Pribadi──────► (1.1 Verifikasi Data Pasien) │ │ │ Valid? │ Tidak Valid │ │──────────────► Notifikasi Error ──► [PASIEN] │ │ Valid │ ▼ │ (1.2 Generate Nomor RM) │ │ │ Nomor RM Baru │ │ │ ▼ │ (1.3 Simpan Data Pasien) ──► D1 Data Pasien │ │ │ Kartu Berobat │ ▼ └──────────────────── [PASIEN] (terima Kartu Berobat) │ Nomor Antrian│ ▼ (1.4 Pengelolaan Antrian) ──► D5 Data Antrian │ No. Antrian Aktif ▼ [PASIEN]

🔥

INSIGHT PENTING — HUBUNGAN DFD & DATABASE

Setiap Data Store (D) di DFD Level 1 akan menjadi tabel di database relasional. Jadi D1=Data Pasien → tb_pasien, D2=Rekam Medis → tb_rekam_medis, dst. DFD Level 1 adalah "blueprint" tabel databasemu! (Connolly & Begg, 2015)

🛠️

TIPS — CARA MEMBUAT DFD YANG BENAR

1. Mulai dari DFD Konteks dulu — identifikasi semua external entity
2. Lanjut ke Level 0 — pecah jadi proses-proses utama (biasanya 3-7 proses)
3. Pilih proses yang paling kompleks untuk di-explode ke Level 1
4. Gunakan tools seperti Draw.io, Lucidchart, atau Microsoft Visio untuk menggambar
5. Cek ulang: apakah semua aliran data di Level 0 tetap konsisten di Level 1? (ini namanya leveling DFD)

Ringkasan Studi Kasus SIMRS: Semua Nyambung!

Mari kita satukan semua konsep. SIMRS adalah contoh ideal karena melibatkan banyak entitas, proses kompleks, dan kebutuhan database yang kuat. Berikut mapping lengkap dari konsep ke implementasi:

Tingkatan DFD	Isi Utama	Contoh SIMRS	Relasi ke Database
Konteks	1 proses, semua external entity	Pasien, Dokter, BPJS, Manajemen	Belum ada mapping
Level 0	Proses utama + data store utama	Pendaftaran, Pemeriksaan, Resep, Laporan	Data store = calon tabel utama
Level 1	Sub-proses detail + semua data store	Verifikasi, Generate No RM, Simpan, Antrian	Setiap data store → satu tabel relasional

⚠️

KESALAHAN PALING UMUM MAHASISWA (Jangan Sampai Kamu Ikutan!)

• Menghubungkan External Entity langsung ke Data Store (harus lewat Proses!)
• Lupa memberi label pada anak panah aliran data
• DFD Level 0 tidak konsisten dengan DFD Konteks (aliran data berbeda)
• Menggunakan kata kerja sebagai nama aliran data (misal: "kirim data" → harusnya "data pasien")
• Data store hanya dibaca tapi tidak pernah ditulis, atau sebaliknya — cek arah panah!

📚 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. https://doi.org/10.1145/362384.362685
2. Connolly, T., & Begg, C. (2015). Database systems: A practical approach to design, implementation, and management (6th ed.). Pearson.
3. DeMarco, T. (1979). Structured analysis and system specification. Prentice Hall.
4. Gane, C., & Sarson, T. (1979). Structured systems analysis: Tools and techniques. Prentice Hall.
5. Jogiyanto, H. M. (2014). Analisis dan desain sistem informasi (5th ed.). Andi Offset.
6. PERSI. (2022). Standar minimal sistem informasi manajemen rumah sakit. Perhimpunan Rumah Sakit Seluruh Indonesia.
7. Pressman, R. S. (2014). Software engineering: A practitioner's approach (8th ed.). McGraw-Hill Education.
8. Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database system concepts (7th ed.). McGraw-Hill.
9. Whitten, J. L., & Bentley, L. D. (2007). Systems analysis and design methods (7th ed.). McGraw-Hill/Irwin.

✅ KESIMPULAN

Dari Konsep ke Praktik: Kamu Sekarang Punya Bekalnya!

Di artikel ini, kamu sudah mempelajari bahwa basis data relasional adalah fondasi penyimpanan data modern — dengan tabel, primary key, dan foreign key sebagai pilarnya. Di atasnya, kita menggunakan DFD sebagai alat untuk memodelkan aliran data sebelum mengimplementasikan database.

Perjalanan DFD dimulai dari Konteks (gambaran besar sistem vs dunia luar), turun ke Level 0 (proses-proses utama), dan semakin detail di Level 1 (sub-proses operasional). Studi kasus SIMRS membuktikan bahwa semua konsep ini bukan teori kosong — ini adalah blueprint nyata sistem yang kamu akan gunakan kelak di rumah sakit.

Ingat: DFD bukan soal gambar yang bagus — tapi soal logika yang benar. Dan sekarang kamu sudah punya kuncinya! 🗝️

💬 Diskusi & Engagement

Punya pertanyaan tentang DFD untuk TA kamu? Atau mau share studi kasus SIMRS di rumah sakit tempat PKL kamu? Tulis di kolom komentar di bawah — dosen dan teman-teman siap diskusi!

👉 Kalau artikel ini membantu, share ke teman sekelas kamu — siapa tahu mereka lagi bingung hal yang sama! Dan jangan lupa subscribe blog ini untuk materi basis data, RMIK, dan sistem informasi kesehatan berikutnya.

Artikel selanjutnya: Entity Relationship Diagram (ERD) untuk SIMRS — dari DFD ke desain tabel yang sesungguhnya. Stay tuned! 🚀

Tags

#BasisData #DFD #SIMRS #DataFlowDiagram #RMIK #SistemInformasi #ModelRelasional #AnalisisiSistem #MahasiswaD3