Sekilas tentang konsep database di dunia nyata

Sering melihat struk/nota pembayaran mini market seperti Alfamart/Indomaret? coba perhatikan gambar dibawah ini:

2136344_20120908083821
gambar 1
Struk Indomaret (diambil dari cdn kaskus).

Seorang System Analyst, Programmer, atau pekerajaan yang terbiasa bergelut dengan database pasti memikirkan hal-hal seperti ini. Table Master, table transaksi, relasi Primary Key, One to many, Many to many dsb.

Untuk menghasilkan Output struk diatas, nyatanya tidak lah mudah. Ini disisi pembuatan database, belum dilevel teknis programming apalagi implementasi disisi Hardware & Jaringannya. Karena yang akan saya bahas kali ini adalah konsep database nya; jadi skup/ ruang lingkup tidak akan membahas diluar konsep.

Karena saya sudah lupa ERD, DFD, Normalisasi 😀 saya berikan pola pikir dari pengalaman saya. Lihat saja pada gambar struk diatas. Ada, nama perusahaan, tanggal, kode barang, nama barang, nama petugas, harga, kuantitas, dll.

Saya mulai dengan table ‘setup header’ terlebih dahulu. Isinya sederhana saja; cuma nama, alamat, no telpon, no npwp. Selanjutnya, disitu ada nama pegawai. Untuk menghasilkan keterangan itu saja, bisa melibatkan 3 tables dan beberapa fields-records.

 

konsep db
gambar 2
Hanya contoh saja.

Lihat gambar 2 diatas, itu saja baru sekitar 10~20% pengerjaan untuk membuat suatu sistem yang salah satunya menghasilkan output struk seperti gambar 1. Sudah pasti ini melibatkan juga konsep FIFO, karena kebanyakan barang-barang yang dijual ada masa kadaluarsa-nya. Untuk itu perlu dibuatkan juga system batch-order; agar barang kadarluasa bisa dikontrol, misalnya di beri diskon agar cepat laku, atau proses retur. Misalkan ketika barang datang secara bersamaan, catat transaksi pada sebuah table. Yang nantinya table ini bisa dijadikan suatu acuan untuk mengambil keputusan.

Saya jelaskan secara singkat untuk proses ‘pemberian nama’ petugas pada struk gambar 1. Pada table master pegawai, sudah pasti ada id_pegawai yang menjadi acuan untuk proses login pada aplikasi nantinya. Karena setiap transaksi membutuhkan nama petugas, dibuatlah table [pegawai_login_log] yang berisikan sesi pegawai yang bertugas. Didalam table tsb, terdapat field [id_pegawai_log] yang value nya akan di isi di table [transaksi].[id_login_log]. Hal ini dibuat; agar proses penelusuran pada module opname pada sisi programming/queries akan jauh lebih mudah.

Perhatikan table [transaksi] ada field [id_pembayaran], yang akan terisi dari table [transaksi_jenis]. Didalamnya, bisa diletakkan metode bayar, yakni CASH/TUNAI ataupun memakai kartu debit/kredit. Jika perlu; tambahkan opsi-opsi lain. Misalnya, jika transaksi dengan memakai debit ada diskon; kartu kredit dikenakan charge tambahan.

Bagaimana dengan perancangan table stock-opname, payroll, akunting, dll? Nah untuk itu, seorang yang akan mendesain database, seharusnya paham benar, alur bisnis; dari hulu sampai hilir. Dari Pembelian, inventori, Pajak, Akunting, Payroll, Stock, dll. Untuk itu dibutuhkan pengalaman yang biasanya dimulai oleh programmer. Karena programmer terbiasa membuat aplikasi interface ke database; dimana proses input, storing data, dan output pada sebuah sistem — lama kelamaan, programmer bisa menjadi System Analyst pemula.

Perkuat analisa pembuatan database, supaya nantinya pada proses implementasi tidak tambal sulam; yang membuat banyak bug pada interface & backend aplikasi. Sekian dulu pengantar pengalaman hidup yang berkaitan dengan basis data kali ini.

 

Post By Tommy Wiranto (68 Posts)

Rasa ingin tahunya, terkadang 101% -- petualang yang tertahan. Terkadang sombong, tetapi pada tempatnya.

Website: →

Connect