Bayangkan kamu sudah capek-capek ngedesain ERD sampai rapi, normalisasi sampai 3NF, terus tiba-tiba dosen bilang: "Sekarang implementasikan ke database fisik-nya ya." Nah, di sinilah banyak mahasiswa tiba-tiba blank. Padahal, integrasi rancangan ke skema fisik ini justru adalah momen paling seru — saat diagram abstrak kamu berubah jadi tabel-tabel nyata yang bisa diisi data pasien rekam medis!
Di artikel ini, kita akan kupas tuntas proses konversi ERD dan hasil normalisasi menjadi skema tabel fisik, cara mendokumentasikan skema database dengan benar, serta langkah review dan verifikasi rancangan supaya database kamu siap pakai. Cocok banget buat kamu mahasiswa D3 RMIK semester 4 yang lagi berjibaku dengan mata kuliah Basis Data. Let's go! ๐
๐️ Apa Itu Skema Fisik dan Kenapa Penting?
Kalau ERD adalah blueprint-nya gedung, maka skema fisik adalah gambar teknik arsitekturnya — lengkap dengan ukuran kolom, tipe data, indeks, constraint, dan semua detail teknis yang dibutuhkan oleh Database Management System (DBMS) untuk benar-benar membangun si database.
Secara formal, skema tabel fisik (physical database schema) adalah representasi implementasi database yang mencakup definisi tabel, tipe data setiap kolom, primary key, foreign key, constraint integritas, dan indeks — sesuai dengan DBMS yang digunakan, misalnya MySQL, PostgreSQL, atau SQL Server (Silberschatz, Korth & Sudarshan, 2020).
Formula Konversi
๐ Langkah-Langkah Konversi ERD ke Skema Tabel Fisik
Proses ini bukan sihir, tapi ada aturan mainnya. Berikut adalah 6 langkah konversi yang sistematis dan bisa kamu ikuti step by step, mengacu pada metodologi Connolly & Begg (2015) serta Elmasri & Navathe (2016):
Konversi Entitas Kuat → Tabel
Setiap entitas kuat (strong entity) dalam ERD dikonversi menjadi satu tabel. Atribut entitas menjadi kolom tabel. Atribut yang menjadi primary key di ERD tetap menjadi PRIMARY KEY di tabel fisik.
CREATE TABLE Pasien (
no_rm VARCHAR(10) NOT NULL,
nama_pasien VARCHAR(100) NOT NULL,
tgl_lahir DATE NOT NULL,
jenis_kelamin ENUM('L','P') NOT NULL,
alamat TEXT,
no_telp VARCHAR(15),
PRIMARY KEY (no_rm)
);
Konversi Entitas Lemah → Tabel dengan FK
Entitas lemah (weak entity) dikonversi menjadi tabel yang menyertakan foreign key yang mereferensi ke tabel entitas kuat pemiliknya. Primary key-nya biasanya gabungan partial key + FK.
CREATE TABLE Detail_Kunjungan (
id_detail INT NOT NULL AUTO_INCREMENT,
no_kunjungan VARCHAR(15) NOT NULL,
diagnosa VARCHAR(200),
tindakan TEXT,
PRIMARY KEY (id_detail),
FOREIGN KEY (no_kunjungan)
REFERENCES Kunjungan(no_kunjungan)
ON DELETE CASCADE
);
Konversi Relasi Many-to-Many → Tabel Asosiatif
Relasi M:N tidak bisa langsung diimplementasikan — harus dibuat tabel baru (junction table / tabel asosiatif) yang berisi FK dari kedua entitas. Ini adalah aturan wajib yang sering dilupakan!
Konversi Relasi 1:N → Foreign Key di Sisi "N"
Untuk relasi satu-ke-banyak, tambahkan foreign key di tabel sisi banyak (N) yang mereferensi primary key tabel sisi satu (1). Analogi: tabel Kunjungan (N) menyimpan FK no_rm dari tabel Pasien (1).
Penentuan Tipe Data dan Constraint
Pilih tipe data yang tepat dan efisien. Jangan pakai VARCHAR(255) untuk semua kolom! Tambahkan constraint NOT NULL, UNIQUE, CHECK, dan DEFAULT sesuai aturan bisnis.
| Data | Tipe Disarankan | Alasan |
|---|---|---|
| No. Rekam Medis | VARCHAR(10) |
Format alfanumerik tetap |
| Tanggal Lahir | DATE |
Hemat storage vs VARCHAR |
| Jenis Kelamin | ENUM('L','P') |
Validasi otomatis DBMS |
| Biaya Periksa | DECIMAL(12,2) |
Presisi desimal keuangan |
| Catatan Dokter | TEXT |
Panjang tidak terprediksi |
Integrasi Hasil Normalisasi
Pastikan setiap tabel yang kamu buat sudah merepresentasikan hasil normalisasi 3NF. Kalau kamu normalisasi tabel ResepObat menjadi tabel Resep + Detail_Resep + Obat — maka tiga tabel itulah yang masuk ke skema fisik, bukan yang aslinya.
Tips Pro
Sebelum nulis CREATE TABLE, buat dulu "kamus data" — dokumen sederhana yang mendaftar setiap kolom beserta tipe data, panjang, constraint, dan deskripsinya. Ini akan menyelamatkanmu saat review dengan dosen dan mempercepat proses debugging nantinya.
๐ Dokumentasi Skema Database: Kenapa Harus dan Bagaimana Caranya?
Ini bagian yang sering di-skip mahasiswa tapi justru bikin nilai naik drastis. Dokumentasi skema bukan sekadar formalitas — ini adalah "peta" yang membantu developer lain (atau kamu sendiri 6 bulan kemudian) memahami database tanpa harus nebak-nebak.
Menurut Date (2004) dalam An Introduction to Database Systems, dokumentasi yang baik adalah komponen wajib dari siklus hidup pengembangan sistem basis data yang profesional.
Komponen Dokumentasi Skema yang Wajib Ada:
Contoh Kamus Data (Data Dictionary) Tabel Pasien:
| Nama Kolom | Tipe Data | Panjang | Constraint | Deskripsi |
|---|---|---|---|---|
no_rm |
VARCHAR | 10 | PK, NOT NULL | Nomor rekam medis unik pasien, format: RM-XXXXXX |
nama_pasien |
VARCHAR | 100 | NOT NULL | Nama lengkap pasien sesuai KTP |
tgl_lahir |
DATE | — | NOT NULL | Tanggal lahir, format YYYY-MM-DD |
jenis_kelamin |
ENUM | ('L','P') | NOT NULL | L = Laki-laki, P = Perempuan |
no_telp |
VARCHAR | 15 | NULLABLE | Nomor telepon aktif, boleh kosong |
Insight Penting
Dalam konteks RMIK, dokumentasi skema database rekam medis punya nilai lebih dari sekadar akademis. Permenkes No. 24 Tahun 2022 tentang Rekam Medis Elektronik mewajibkan sistem informasi kesehatan memiliki dokumentasi teknis yang memadai sebagai bagian dari standar keamanan data pasien. Jadi kemampuan ini bukan cuma buat lulus kuliah, tapi juga tuntutan profesi nyata!
๐ Review dan Verifikasi Rancangan: Quality Gate Sebelum Go Live
Selesai bikin skema fisik bukan berarti langsung selesai. Ada tahap krusial yang namanya review dan verifikasi rancangan. Ini ibarat test drive sebelum beli mobil — kamu harus mastiin semuanya berjalan sesuai harapan sebelum database dipake beneran.
Elmasri & Navathe (2016) menegaskan bahwa tahap verifikasi rancangan melibatkan pengecekan kelengkapan (completeness), konsistensi (consistency), dan kebenaran semantik (semantic correctness) dari skema yang telah dibuat.
✅ Checklist Review Rancangan Database
๐ Verifikasi Struktural
- ◈Setiap tabel memiliki primary key yang didefinisikan dengan jelas
- ◈Semua foreign key mereferensi primary key yang valid
- ◈Tidak ada redundansi data yang melanggar 3NF
- ◈Relasi M:N sudah dikonversi ke tabel asosiatif
๐ฏ Verifikasi Semantik
- ◈Nama tabel dan kolom mencerminkan makna bisnisnya
- ◈Tipe data sesuai dengan jenis data yang disimpan
- ◈Constraint mencerminkan aturan bisnis yang benar
- ◈Skema mampu menyimpan semua data skenario use case
๐ก️ Verifikasi Integritas Data
- ◈Script DDL berhasil dijalankan tanpa error di DBMS target
- ◈Insert data dummy berhasil dan sesuai constraint
- ◈Query JOIN antar tabel menghasilkan data yang benar
- ◈Cascading delete/update bekerja sesuai rencana
Teknik Verifikasi yang Bisa Kamu Gunakan:
Walkthrough Manual
Telusuri setiap skenario transaksi (pendaftaran pasien baru, kunjungan, input resep) dan cek apakah skema dapat menampungnya.
Uji dengan Data Dummy
Insert minimal 5-10 baris data representatif ke setiap tabel. Uji juga kondisi edge case seperti nilai NULL dan data duplikat.
Peer Review
Minta teman kelompok (yang tidak terlibat membuat skema) untuk membaca dokumentasi dan mencoba memahami strukturnya. Kalau mereka bingung, dokumentasimu perlu diperbaiki.
Kesalahan Umum yang Harus Dihindari
- Pakai VARCHAR untuk semua kolom — pilih tipe data yang tepat untuk efisiensi storage
- Lupa ON DELETE/ON UPDATE di foreign key — bisa menyebabkan orphan records
- Nama kolom tidak konsisten — kadang
tgl_lahir, kadangtanggal_lahir, kadangbirthdate. Pilih satu konvensi, konsisten! - Skip dokumentasi karena merasa "nanti aja" — nanti itu tidak pernah datang ๐
๐ฅ Studi Kasus: Sistem Informasi Rawat Jalan Puskesmas
Supaya makin konkret, kita lihat contoh lengkap konversi ERD ke skema fisik dalam konteks yang relevan buat kalian: Sistem Informasi Rawat Jalan Puskesmas. Ini adalah kasus yang sangat dekat dengan bidang RMIK.
๐ Script DDL — Sistem Rawat Jalan
-- =============================================
-- SKEMA FISIK: Sistem Informasi Rawat Jalan
-- Versi: 1.0 | Tanggal: 2025
-- Penulis: Tim Pengembang D3 RMIK
-- =============================================
CREATE TABLE Pasien (
no_rm VARCHAR(10) NOT NULL,
nama_pasien VARCHAR(100) NOT NULL,
tgl_lahir DATE NOT NULL,
jenis_kelamin ENUM('L','P') NOT NULL,
gol_darah ENUM('A','B','AB','O','?') DEFAULT '?',
alamat TEXT,
no_telp VARCHAR(15),
tgl_daftar DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (no_rm)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE Dokter (
id_dokter INT NOT NULL AUTO_INCREMENT,
nip_dokter VARCHAR(18) NOT NULL UNIQUE,
nama_dokter VARCHAR(100) NOT NULL,
spesialisasi VARCHAR(50) NOT NULL,
no_sip VARCHAR(30) NOT NULL,
PRIMARY KEY (id_dokter)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE Kunjungan (
no_kunjungan VARCHAR(15) NOT NULL,
no_rm VARCHAR(10) NOT NULL,
id_dokter INT NOT NULL,
tgl_kunjungan DATETIME NOT NULL,
keluhan TEXT NOT NULL,
diagnosa_icd VARCHAR(10),
status ENUM('menunggu','dalam_proses','selesai')
DEFAULT 'menunggu',
PRIMARY KEY (no_kunjungan),
FOREIGN KEY (no_rm)
REFERENCES Pasien(no_rm) ON DELETE RESTRICT,
FOREIGN KEY (id_dokter)
REFERENCES Dokter(id_dokter) ON DELETE RESTRICT
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- Tabel hasil normalisasi M:N Kunjungan <-> Obat
CREATE TABLE Obat (
id_obat INT NOT NULL AUTO_INCREMENT,
nama_obat VARCHAR(100) NOT NULL,
satuan VARCHAR(20) NOT NULL,
stok INT NOT NULL DEFAULT 0,
PRIMARY KEY (id_obat)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE Resep (
id_resep INT NOT NULL AUTO_INCREMENT,
no_kunjungan VARCHAR(15) NOT NULL,
id_obat INT NOT NULL,
jumlah INT NOT NULL,
aturan_pakai VARCHAR(100) NOT NULL,
PRIMARY KEY (id_resep),
FOREIGN KEY (no_kunjungan)
REFERENCES Kunjungan(no_kunjungan) ON DELETE CASCADE,
FOREIGN KEY (id_obat)
REFERENCES Obat(id_obat) ON DELETE RESTRICT
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
"A database schema is the skeleton of a database. Without it properly defined, even the best application code will eventually break."
— Ramez Elmasri & Shamkant B. Navathe, Fundamentals of Database Systems, 7th Ed. (2016)
๐ Referensi
- Connolly, T. M., & Begg, C. E. (2015). Database Systems: A Practical Approach to Design, Implementation, and Management (6th ed.). Pearson Education.
- Date, C. J. (2004). An Introduction to Database Systems (8th ed.). Addison-Wesley.
- Elmasri, R., & Navathe, S. B. (2016). Fundamentals of Database Systems (7th ed.). Pearson Education.
- Kementerian Kesehatan RI. (2022). Peraturan Menteri Kesehatan Nomor 24 Tahun 2022 tentang Rekam Medis Elektronik. Kemenkes RI.
- Ramakrishnan, R., & Gehrke, J. (2003). Database Management Systems (3rd ed.). McGraw-Hill.
- Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th ed.). McGraw-Hill Education.
๐ฌ
Yuk, Ikut Diskusi!
Pertanyaan, tambahan insight, atau pengalaman kamu saat ngerjain tugas basis data? Tulis di kolom komentar di bawah! Artikel ini ditulis untuk kamu, jadi feedback-mu sangat berharga ๐
No comments:
Post a Comment