Contoh Desain Struktur Database Aplikasi Realisasi Fisik dan Keangan serta Arus Kas

Membangun aplikasi sistem informasi keuangan, baik untuk skala perusahaan swasta maupun instansi pemerintahan (seperti aplikasi pengelolaan Dana Desa atau Anggaran Daerah), memiliki tantangan tersendiri. Kesalahan terbesar yang sering dilakukan oleh programmer pemula adalah tidak merancang arsitektur database (basis data) secara matang sejak awal.

Jika struktur tabel berantakan, proses penarikan laporan (query data) untuk melihat realisasi keuangan dan realisasi fisik akan menjadi sangat berat dan membebani kinerja server.

Artikel ini akan membedah contoh desain struktur database MySQL yang efisien untuk aplikasi pengelolaan anggaran dan arus kas (cash flow). Skema ini sangat cocok diterapkan jika Anda sedang mengembangkan sistem berbasis dokumen pelaksanaan anggaran (DPA).

Konsep Dasar Relasi Data Anggaran

Dalam sistem pengelolaan anggaran, alur logika datanya tidak bisa hanya mencatat “uang masuk” dan “uang keluar”. Kita harus mematuhi hierarki kode rekening (mata anggaran) dan pagu anggaran yang sudah ditetapkan di awal tahun.

Secara garis besar, kita membutuhkan setidaknya tiga tabel utama agar sistem bisa melacak realisasi dengan akurat:

1. Tabel Master Rekening: Menyimpan daftar nomenklatur atau kode akun keuangan standar.
2. Tabel Anggaran (DPA): Menyimpan besaran pagu/jatah anggaran untuk masing-masing kode rekening pada periode tertentu.
3. Tabel Arus Kas: Menyimpan histori transaksi riil (pengeluaran/pemasukan) harian yang mengikat pada kode rekening anggaran tersebut.

Mari kita bahas satu per satu struktur tabelnya beserta perintah SQL-nya.

1. Tabel master_rekening

Tabel ini adalah pondasi utama. Di pemerintahan atau instansi resmi, setiap pengeluaran pasti memiliki “Kode Rekening”. Tabel ini bersifat statis (jarang diubah kecuali ada aturan nomenklatur baru).

SQL

<code>CREATE TABLE `master_rekening` (
  `id_rekening` int(11) NOT NULL AUTO_INCREMENT,
  `kode_rekening` varchar(50) NOT NULL,
  `nama_rekening` varchar(255) NOT NULL,
  `kategori` enum('Pendapatan','Belanja','Pembiayaan') NOT NULL,
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id_rekening`),
  UNIQUE KEY `kode_rekening` (`kode_rekening`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
</code>

Penjelasan:

• kode_rekening: Di-set sebagai Unique Key agar tidak ada kode akun yang ganda (misal: 5.1.02.01.01 untuk Belanja Alat Tulis Kantor).
• kategori: Menggunakan ENUM untuk membatasi input agar lebih terstruktur dan mempercepat indeksasi database.

2. Tabel anggaran_dpa

Tabel ini menyimpan Dokumen Pelaksanaan Anggaran (DPA). Di sinilah pagu (jatah) uang di-setel pada awal tahun.

SQL

<code>CREATE TABLE `anggaran_dpa` (
  `id_dpa` int(11) NOT NULL AUTO_INCREMENT,
  `id_rekening` int(11) NOT NULL,
  `tahun_anggaran` year(4) NOT NULL,
  `pagu_anggaran` decimal(15,2) NOT NULL DEFAULT '0.00',
  `target_fisik` decimal(5,2) NOT NULL DEFAULT '100.00' COMMENT 'Persentase target fisik',
  `keterangan` text,
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id_dpa`),
  KEY `id_rekening` (`id_rekening`),
  CONSTRAINT `fk_dpa_rekening` FOREIGN KEY (`id_rekening`) REFERENCES `master_rekening` (`id_rekening`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
</code>

Penjelasan:

• Menggunakan relasi Foreign Key (fk_dpa_rekening) ke tabel master_rekening. Ini memastikan bahwa kita tidak bisa memasukkan pagu anggaran untuk rekening yang tidak ada di data master.
• Tipe data decimal(15,2) sangat penting untuk pagu_anggaran. Jangan gunakan tipe FLOAT atau INT untuk menyimpan nilai uang berskala besar, karena rawan mengalami pembulatan otomatis yang membuat laporan keuangan tidak balance.
• target_fisik: Digunakan untuk melacak target persentase pengerjaan di lapangan (sangat berguna untuk proyek fisik instansi).

3. Tabel arus_kas

Tabel ini adalah jantung dari aplikasi Anda. Setiap kali ada pengajuan pencairan dana (SPP/SPM) atau pengeluaran kas rill, datanya masuk ke sini.

SQL

<code>CREATE TABLE `arus_kas` (
  `id_transaksi` bigint(20) NOT NULL AUTO_INCREMENT,
  `id_dpa` int(11) NOT NULL,
  `tanggal_transaksi` date NOT NULL,
  `nomor_bukti` varchar(100) NOT NULL,
  `jenis_transaksi` enum('Pemasukan','Pengeluaran') NOT NULL,
  `nilai_keuangan` decimal(15,2) NOT NULL DEFAULT '0.00',
  `realisasi_fisik` decimal(5,2) NOT NULL DEFAULT '0.00' COMMENT 'Persentase fisik yang dicapai',
  `uraian` text NOT NULL,
  `created_at` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id_transaksi`),
  KEY `id_dpa` (`id_dpa`),
  KEY `tanggal_transaksi` (`tanggal_transaksi`),
  CONSTRAINT `fk_arus_kas_dpa` FOREIGN KEY (`id_dpa`) REFERENCES `anggaran_dpa` (`id_dpa`) ON DELETE RESTRICT
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
</code>

Penjelasan:

• id_transaksi: Menggunakan BIGINT untuk mengantisipasi jutaan baris transaksi di masa depan.
• Relasinya diikat ke id_dpa, bukan ke id_rekening. Kenapa? Karena pengeluaran harus memotong pagu anggaran di tahun spesifik (anggaran_dpa), bukan sekadar memotong kode akun master.
• tanggal_transaksi diberi Index (KEY). Ini adalah rahasia agar aplikasi tidak “ngelag” saat Anda men- generate laporan bulanan atau rentang tanggal tertentu.

Keuntungan Menggunakan Desain Database Ini

1. Integritas Data Terjamin: Berkat Foreign Key constraints, aplikasi tidak akan mengizinkan penghapusan data master rekening jika masih ada jejak transaksi di arus kas. Ini mencegah error relasi data.
2. Perhitungan Sisa Anggaran Mudah: Untuk mencari “Sisa Anggaran” sebuah program, query-nya sangat sederhana. Cukup kurangi pagu_anggaran di tabel anggaran_dpa dengan total SUM(nilai_keuangan) dari tabel arus_kas.
3. Tracking Ganda: Struktur ini tidak hanya memantau uang keluar (realisasi keuangan), tetapi juga mencatat progres pekerjaan di lapangan (realisasi fisik) setiap kali dana dicairkan.

Kesimpulan

Merancang database untuk aplikasi keuangan menuntut ketelitian dalam memilih tipe data (wajib gunakan Decimal) dan penentuan Index pada kolom yang sering dicari. Jika Anda mengimplementasikan skema di atas menggunakan framework seperti Laravel atau CodeIgniter, struktur ini sangat mudah diintegrasikan dengan fitur ORM (Object-Relational Mapping) bawaan mereka.

Semoga arsitektur database ini bisa menjadi referensi yang solid untuk proyek development Anda selanjutnya!