ER DIagram Purchasing

Perancangan Aplikasi dan atau sistem menghendaki adanya perancanga basis data atau lebih dikenal sebagai database. Dan menurut saya, perancangan database, adalah perancangan yang paling dasar dan harus benar. Mengapa? Banyak aplikasi susah untuk di maintenance terkait dengan data-data yang sedang dismpan. Oleh karena itu, perancangan basis data yang baik setidaknya dapat mengurangi bug maupun integritas data. Tabel-tabel dibuat senormal mungkin agar data tidak terjadi duplikasi maupun anomali. Benteng-benteng pertahanan aplikasi atau sistem pun sebaiknya dibuat pada level ini. Banyak sekali pembuat program hanya membentengi data tidak valid pada level user interface, ini sangat tidak bagus jika ada seseorang yang berhasil masuk ke level DBMS yang menyimpan data.

Berikut adalah Gambar ER(Entity Relationship) diagram dari aplikasi ataupun sistem informasi pembelian yang saya buat untuk memenuhi tugas besar SIA.

Untuk melihat lebih jelas, klik pada gambar (ER-Diagram)

ER di atas bercerita bahwa pembelian yang dilakukan oleh perusahaan yang saya ambil untuk studi kasus adalah pembelian atau pengakuan pembelian terjadi saat ada atau datang faktur pembelian (invoice). Faktur muncul diakibatkan oleh dua hal yakni pemesanan(order) atau penerimaan barang (receive). Oleh karena itu, referensi pembuatan faktur dapat berasal dari dua hal di atas. Namun, ada pula kemunculan faktur tanpa dua hal di atas, yakni pembelian langsung, tetapi barang belum diterima. Hal ini mengakibatkan nomor order ataupun nomor receive kosong d tabel invoice (faktur).

Untuk masalah receive, sama halnya dengan faktur, proses ini mengambil referensi nomor order sebagai dasar pembuatan receive (penerimaan). Bisa saja, penerimaan tanpa adanya pemesanan terlebih dahulu dapat terjadi. Ini tidak membuat masalah, karena kolom nomor order dalam tabel receive dapat kosong yang menandakan penerimaan tanpa pemesanan.

Masalah terakhir yakni retur pembelian. Retur menjadi hal yang sering terjadi dalam praktik dunia bisnis, terutama dagang. Retur mengambil referensi dari nomor faktur. Barang dagangan pun tidak harus sama seperti  saat pembelian. Semisal dalam faktur tertulis pembelian barag A, bisa jadi dalam praktik sesungguhnya, bukan barag A yang diretur, melainkan barang B. Ini menjadi konsekuensi untuk pembuatan basis data dengan model ER seperti di atas.