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!
┌──────────────┬──────────────────┬───────────┐
│ 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 │
└──────────┴─────────────────┴────────────────┘
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.
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.
Sumber atau tujuan data dari luar sistem. Disimbolkan dengan kotak persegi (rectangle). Entitas eksternal TIDAK diproses oleh sistem — mereka hanya memberi atau menerima data.
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).
Tempat data disimpan (sementara atau permanen). Disimbolkan dengan dua garis horizontal sejajar. Di database relasional, setiap data store biasanya merepresentasikan satu tabel.
Jalur perpindahan data antar komponen. Disimbolkan dengan anak panah berarah dengan label nama data yang mengalir. Satu aliran = satu jenis paket data.
| 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 |
- 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.
Sebelum masuk ke penjelasan, kamu perlu tahu dulu apa itu Context Diagram. Context Diagram adalah gambaran paling sederhana dari sebuah sistem — ibarat foto dari jauh yang memperlihatkan siapa saja yang terlibat dalam sistem dan apa yang mereka kirim atau terima. Di diagram ini hanya ada satu proses utama (lingkaran di tengah), yaitu SIMRS, dan beberapa entitas eksternal (kotak-kotak di sekelilingnya) yang berinteraksi dengan sistem tersebut.
Siapa Saja yang Terlibat?
Dalam diagram ini terdapat 5 entitas eksternal, yaitu pihak-pihak di luar sistem yang berinteraksi langsung dengan SIMRS:
- Pasien — orang yang datang berobat ke rumah sakit
- Dokter — tenaga medis yang memeriksa dan merawat pasien
- Petugas Apotek — staf yang mengelola obat-obatan di apotek rumah sakit
- BPJS — badan penyelenggara jaminan sosial kesehatan
- Manajemen RS — pihak pengelola rumah sakit secara keseluruhan
Penjelasan Alur Sistem Secara Lengkap
1. Pasien ↔ SIMRS
Alur pertama dimulai dari Pasien. Ketika seorang pasien datang ke rumah sakit dan ingin berobat, ia menyerahkan data dirinya ke sistem. Data ini disebut Data Registrasi, yang isinya bisa berupa nama, alamat, tanggal lahir, nomor identitas, dan informasi lain yang diperlukan untuk pendaftaran.
Setelah sistem memproses data registrasi tersebut, sistem akan memberikan kembali kepada pasien sebuah Kartu Berobat dan Nomor Antrian. Kartu berobat berfungsi sebagai identitas pasien di rumah sakit, sedangkan nomor antrian digunakan agar pasien bisa dipanggil sesuai urutan.
Singkatnya: Pasien memberi data → Sistem memberi Kartu Berobat & Nomor Antrian
2. Dokter ↔ SIMRS
Alur kedua melibatkan Dokter. Setelah pasien mendapat nomor antrian dan dipanggil untuk diperiksa, dokter yang menangani pasien tersebut membutuhkan informasi riwayat kesehatan pasien. Oleh karena itu, sistem mengirimkan Rekam Medis Pasien kepada dokter — berisi riwayat penyakit, hasil pemeriksaan sebelumnya, alergi obat, dan sebagainya.
Setelah dokter selesai memeriksa pasien, dokter kemudian menginputkan hasil pemeriksaannya ke dalam sistem. Data ini disebut Data Pemeriksaan, yang bisa berisi diagnosis, resep obat, catatan tindakan medis, dan lain-lain.
Singkatnya: Sistem memberi Rekam Medis → Dokter memberi Data Pemeriksaan
3. Petugas Apotek ↔ SIMRS
Alur ketiga melibatkan Petugas Apotek. Setelah dokter membuat resep, pasien akan pergi ke apotek untuk menebus obat. Petugas apotek yang menerima resep tersebut kemudian menginputkan Data Penebusan Resep ke dalam sistem — mencatat obat apa saja yang diambil oleh pasien.
Sebagai timbal baliknya, sistem memberikan kepada petugas apotek sebuah Laporan Stok Obat. Laporan ini sangat penting agar petugas apotek bisa memantau obat mana yang mulai habis dan perlu segera diisi ulang.
Singkatnya: Petugas Apotek memberi Data Penebusan Resep → Sistem memberi Laporan Stok Obat
4. BPJS ↔ SIMRS
Alur keempat melibatkan BPJS. Bagi pasien yang menggunakan layanan BPJS Kesehatan, rumah sakit perlu mengajukan klaim pembayaran ke BPJS. Sistem akan mengirimkan Data Klaim BPJS kepada pihak BPJS — berisi rincian layanan medis yang telah diberikan kepada pasien peserta BPJS beserta biayanya.
Pada diagram ini, alur hanya menunjukkan satu arah yaitu dari sistem ke BPJS, artinya dalam konteks ini SIMRS berperan sebagai pihak yang melaporkan data klaim kepada BPJS.
Singkatnya: Sistem mengirim Data Klaim BPJS ke pihak BPJS
5. Manajemen RS ↔ SIMRS
Alur kelima dan terakhir melibatkan Manajemen RS. Pihak manajemen rumah sakit membutuhkan data untuk pengambilan keputusan dan evaluasi kinerja rumah sakit. Oleh karena itu, sistem mengirimkan Laporan Kunjungan kepada manajemen — berisi informasi tentang jumlah pasien yang datang, tren kunjungan, dan data statistik lainnya yang berguna untuk pengelolaan rumah sakit.
Sama seperti BPJS, alur ini berjalan satu arah dari sistem ke manajemen, menandakan bahwa manajemen adalah penerima laporan dari sistem.
Singkatnya: Sistem mengirim Laporan Kunjungan ke Manajemen RS
Rangkuman Alur dalam Tabel
| Entitas Eksternal | Input ke Sistem | Output dari Sistem |
|---|---|---|
| Pasien | Data Registrasi | Kartu Berobat & Nomor Antrian |
| Dokter | Data Pemeriksaan | Rekam Medis Pasien |
| Petugas Apotek | Data Penebusan Resep | Laporan Stok Obat |
| BPJS | — | Data Klaim BPJS |
| Manajemen RS | — | Laporan Kunjungan |
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).
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 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!
tb_pasien, D2=Rekam Medis → tb_rekam_medis, dst. DFD Level 1 adalah "blueprint" tabel databasemu! (Connolly & Begg, 2015)- Mulai dari DFD Konteks dulu — identifikasi semua external entity
- Lanjut ke Level 0 — pecah jadi proses-proses utama (biasanya 3-7 proses)
- Pilih proses yang paling kompleks untuk di-explode ke Level 1
- Gunakan tools seperti Draw.io, Lucidchart, atau Microsoft Visio untuk menggambar
- 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 |
- 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
- 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
- Connolly, T., & Begg, C. (2015). Database systems: A practical approach to design, implementation, and management (6th ed.). Pearson.
- DeMarco, T. (1979). Structured analysis and system specification. Prentice Hall.
- Gane, C., & Sarson, T. (1979). Structured systems analysis: Tools and techniques. Prentice Hall.
- Jogiyanto, H. M. (2014). Analisis dan desain sistem informasi (5th ed.). Andi Offset.
- PERSI. (2022). Standar minimal sistem informasi manajemen rumah sakit. Perhimpunan Rumah Sakit Seluruh Indonesia.
- Pressman, R. S. (2014). Software engineering: A practitioner's approach (8th ed.). McGraw-Hill Education.
- Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database system concepts (7th ed.). McGraw-Hill.
- Whitten, J. L., & Bentley, L. D. (2007). Systems analysis and design methods (7th ed.). McGraw-Hill/Irwin.
No comments:
Post a Comment