Belajar Gratis Sistem Informasi & Informatika: Integrasi berbagai REA: membuat model REA skala enterprise

Proses pemodelan REA yang dijelaskan pada bagian sebelumnya menghasilkan model REA individual pada siklus pendapatan (revenue cycle) di Apex Supply. Bagian ini menjelaskan bagaimana berbagai diagram REA, yang masing-masing dibuat secara terpisah dalam proses pemodelannya, diintegrasikan menjadi satu model tunggal yang berskala enterprise. Bagian ini selanjutnya menjelaskan bagaimana model enterprise diimplementasikan kedalam database relasional dan view dari pengguna yang sudah dibuat. Proses integrasi ini meliputi tiga langkah dasar:

1.    Menyatukan model-model individual
2.    Mendefinisikan primary key, foreign key, dan atribut-atribut.
3.    Membuat database fisik dan membuat pandangan pengguna

Langkah 1. Menggabungkan model-model individual

Karena Apex adalah perusahaan grosir yang tidak memiliki berbagai fasilitas produksi, konsolidasi modelnya akan terdiri dari model siklus revenue (pendapatan) yang telah dibuat sebelumnya (gambar 10-8) dan model siklus expenditure (pengeluaran) untuk pembelian/pembayaran dan payroll seperti yang digambarkan pada gambar 10-10 dan gambar 10-11 secara berurutan. Penjelasan singkat mengenai resources, events, agents, dan kardinalitas untuk dua model siklus expenditure diberikan selanjutnya.

Prosedur pembelian dan pembayaran uang/cash

Gambar 10-10 menunjukkan tiga entitas event pada sistem pembelian dan pembayaran uang di Apex. Yang pertama, entitas Order Product/Memesan Barang, adalah support event yang tidak secara langsung meningkatkan entitas inventori/persediaan (resource). Setelah mengetahui adanya kebutuhan untuk inventory/persediaan, yang habis terjual ke pelanggan (siklus revenue), karyawan bagian pembelian (agent internal) memilih supplier (agent eksternal) dan membuat pesanan. Tindakan ini bukan merupakan suatu economic event, tetapi merupakan sebuah komitmen untuk membeli. Link dari entitas event ke entitas Inventory/Persediaan menunjukkan bahwa catatan akan disesuaikan untuk menunjukkan bahwa item-item yang ditanyakan sedang dipesan.

Namun demikian, jumlah kuantitas yang tersedia tidak akan meningkat untuk saat ini. Informasi ‘sedang-di-pesan’ akan mencegah item-item supaya secara tak sengaja dipesan lagi dan akan membantu karyawan customer service dalam menyarankan para pelanggan mengenai status inventory/persediaan dan tanggal jatuh tempo untuk item-item yang kehabisan stock. Asosiasi 1:M antara Supplier dan Order Product/Memesan Barang menunjukkan bahwa setiap pesanan hanya berlanjut ke satu supplier dan bahwa supplier tertentu mungkin telah menerima pesanan sebanyak nol (zero) atau banyak (many) kali selama periode tersebut.

Entitas event kedua adalah Receive Product/Menerima Barang, yang merupakan economic event yang menyebabkan perubahan pada resource. Ini adalah bagian parohan ‘menerima’ dari pertukaran/transaksi dan menambah jumlah inventori/persediaan. Barang-barang diterima dari supplier dan karyawan bagian penerimaan memprosesnya. Aktivitas ini meliputi menghitung, menginspeksi, memindahkan barang ke gudang, dan mengupdate catatan inventory/persediaan. Kardinalitas 0,1 pada asosiasi antara entitas Order Product/Memesan Barang dan entitas Receive Product/Menerima Barang menyiratkan bahwa kapanpun sebuah pesanan bisa ada (kejadian Order Product/Memesan Barang) yang belum diterima (tidak ada kejadian Menerima Barang).

Event ketiga yang disajikan pada diagram tersebut adalah Disburse Cash/Membayar Uang. Ini adalah economic event yang termasuk bagian sisi ‘memberi’ dari suatu pertukaran/transaksi ekonomi. Dalam kasus ini berarti akan menyebabkan resource Cash/Uang berkurang. Asosiasi 1:M dengan entitas Supplier menyiratkan bahwa setiap pembayaran hanya dibuat untuk satu supplier, setiap supplier mungkin menerima pembayaran sebanyak nol (zero) atau banyak (many) kali selama periode tersebut. Asosiasi 1:M antara Disburse Cash/Membayar Uang dan Receive Product/Menerima Barang menyiratkan bahwa setiap penerimaan barang dibayar secara penuh (bukan pembayaran parsial/bertahap), tetapi banyak pembayaran bisa saja dikombinasikan dan dibayarkan kedalam satu pembayaran tunggal untuk mengurangi proses menuliskan check.

Perhatikan bahwa asosiasi M:M terjadi antara entitas Order Product/Memesan Barang dan entitas Inventory/Persediaan dan antara entitas Receive Product/Menerima Barang dan entitas Inventory/Persediaan. Ini berarti bahwa pesanan yang dibuat ke supplier dan barang yang diterima dari mereka bisa berisi satu atau banyak item. Dari sisi yang sebaliknya, asosiasi-asosiasi ini menandakan bahwa setiap item inventory/persediaan mungkin dipesan dan diterima sebanyak nol (zero) atau banyak (many) kali pada periode tersebut. Seperti yang telah dibahas sebelumnya, setiap asosiasi M:M perlu diselesaikan dengan menambahkan entitas penghubung. Tabel-tabel yang berfungsi sebagai entitas-entitas penghubung nantinya akan dibuat di database, tetapi entitas-entitas tersebut tidak akan dimasukkan pada diagram REA. Harap diingat juga bahwa agent internal disajikan pada diagram REA adalah entitas-entitas yang terpisah. Ini dilakukan untuk menjelaskan peranan mereka masing-masing secara lebih jelas. Dalam kenyataannya, agent-agent ini adalah instance/objek dari entitas Employee/Karyawan dan akan disatukan kedalam satu tabel Employee/Karyawan pada database akhir nanti.

Prosedur Payroll

Diagram REA pada gambar 10-11 menggambarkan model data untuk prosedur payroll di Apex Supply. Model ini hanya terdiri dari dua economic events. Get Time/Mendapatkan Waktu dan Disburse Cash/Membayar Uang. Event Get Time/Mendapatkan Waktu adalah bagian sisi menerima dari pertukaran/transaksi ekonomi. Ini melibatkan pekerja (agent internal) yang memberikan waktunya, yang disajikan oleh resource Jasa Karyawan. Supervisor (agent eksternal) mengasumsikan pengendalian resource. Berbeda dengan resource ekonomi yang tangible seperti uang dan inventori/persediaan, waktu tidak memiliki element aliran barang dan tidak bisa disimpan. Event Get Time/Mendapatkan Waktu menambah jumlah waktu, dan berbagai event kinerja pekerjaan secara bersamaan mengurangi jumlah waktu. Di bagian depan bab ini, resource Jasa Karyawan telah didiskusikan sebagai resource yang memungkinkan untuk dimodelkan pada database Apex Supply. Pada situasi dimana jasa karyawan dilacak secara langsung ke barang yang dihasilkan atau jasa yang diberikan ke klien (seperti, konsultasi, jasa hukum, atau akuntansi publik), adalah masuk akal untuk memodelkan resource semacam ini. Karena Apex tidak melacak waktu karyawan untuk aktivitas-aktivitas seperti pelanggan individu yang dilayani atau pesanan-pesanan yang ditangani, memindahkan entitas ini ke tabel database fisik tidak ada gunanya. Namun demikian, untuk menjaga konsistensi dengan konvensi pemodelan REA bahwa setiap event harus terhubung ke satu resource, Jasa Karyawan (Employee Services) dimasukkan pada gambar 10-11 sebagai resource yang diarsir (garis titik-titik). Ini tidak akan dimodelkan pada diagram REA skala enterprise.

Event Get Time/Mendapatkan Waktu menangkap instance/objek karyawan yang memberikan waktu hariannya melalui mekanisme pencatatan waktu seperti time-clock elektronik. Bagi karawayan yang bergaji tetap, proses pencatatan waktu mungkin bisa secara sederhana melibatkan alur waktu. Kardinalitas nol (zero) pada asosiasi antara entitas Get Time/Mendapatkan Waktu dan entitas Pekerja dan entitas Supervisor mencerminkan kemungkinan bahwa beberapa karyawan mungkin tidak mengontribusikan waktunya selama periode tersebut. Ini terjadi contohnya adalah karyawan baru atau karyawan yang cuti karena sakit.

Event Disburse Cash/Membayar Uang adalah bagian sisi memberi dalam pertukaran/transaksi ekonomi. Aktivitas ini meliputi membagikan uang/cash ke karyawan (saat ini menjadi agent eksternal) atas jasa yang diberikannya. Karyawan bagian payroll (agent internal) terlibat dalam event ini, yang mengurangi resource uang/cash. Aosiasi antara event Disburse Cash/Membayar Uang dan event Get Time/Mendapatkan Waktu mencerminkan selisih waktu antara waktu yang diberikan karyawan dan pembayaran yang diterimanya, karena mereka pada umumnya tidak dibayar harian. Pada umumnya, karyawan bekerja selama seminggu, dua minggu, atau bahkan sebulan sebelum dibayar. Karena itu, kardinalitas 1,M pada sisi Get Time/Mendapatkan Waktu dari asosiasi tersebut menyiratkan bahwa setidaknya satu atau mungkin banyak instance Get Time/Mendapatkan Waktu akan terjadi untuk setiap instance Disburse Cash/Membayar Uang. Kardinalitas 0,1 pada sisi Disburse Cash/Membayar Uang dari asosiasi tersebut menyiratkan bahwa pada waktu tertentu (pertengahan minggu), instance Get Time/MendapatkanWaktu akan ada yang belum dibayar. Namun, setiap instance Get Time/Mendapatkan Waktu hanya dibayar sekali.

Menggabungkan diagram-diagram REA individual

Dengan diagram-diagram REA individu yang telah dibuat dan dijelaskan, saat ini kita siap menyatukan semua diagram menjadi satu diagram tunggal berskala enterprise (lihat gambar 10-12). Dengan membalikkan diagram-diagram siklus expenditure/pengeluaran seperti dipantulkan dalam cermin, resource umum inventory/persediaan dan Uang/Cash berpusat di tengah. Keduanya diapit oleh dua konstelasi event, yang menambahkan dan menguranginya. Para agent membentuk konstelasi pada pinggiran diagram.

Untuk menyederhanakan diagram, entitas-entitas event, agent, dan resource yang redundant disatukan menjadi satu entitas tunggal bila memungkinkan. Contohnya, event Disburse Cash / Membayar Uang, yang merupakan elemen penting pada prosedur Payroll dan Pembayaran Pembelian/Cash untuk Apex Supply disajikan hanya sekali di dalam model yang telah disatukan. Selain itu, entitas-entitas Uang/Cash dan Inventory/Persediaan hanya disajikan sekali saja pada diagram yang telah disatukan. Untuk mempertahankan perspektif peranan-peranan yang dimainkan oleh para agent internal, mereka disajikan sebagai entitas-entitas individu daripada disajikan secara kolektif sebagai karyawan. Terakhir, untuk menghindari garis-garis yang menyilang pada asosiasi antar entitas, agent Supplier dan Pelanggan dimunculkan lebih dari satu kali pada diagram tersebut.

Langkah 2. Mendefinisikan Primary Key, Foreign Key, dan Atribut

Dengan model data yang sudah dibuat, kita sekarang siap untuk mendesain tabel-tabel database relasional. Ini antara lain dengan menetukan primary key, menugaskan foreign key, dan mendefiniskan atribut-atribut tabel. Satu tabel akan dibuat untuk setiap entitas yang valid pada diagram REA yang sudah terintegrasi pada gambar 10-12. Ini akan memerlukan 18 tabel yang dijelaskan dibawah:

-    10 agent internal yang disajikan pada gambar 10-12 akan disatukan menjadi satu tabel Employee/Karyawan.
-    Dua agent eksternal (Pelanggan dan Supplier) masing-masing akan memerlukan table tersendiri.
-    Dua resource Inventory/Persediaan dan Uang/Cash masing-masing akan menjadi satu tabel.
-    Delapan event masing-masing akan memerlukan tabel sendiri.
-    Lima relasi M:M yang disajikan pada diagram masing-masing akan memerlukan tabel penghubung.

Aturan untuk primary key dan atribut. Tabel 10-1 menyajikan 18 tabel pada database Apex disertai dengan primary key, foreign key, dan atribut. Penentuan primary key dan atribut berasal dari pemahaman terhadap tujuan tabel yang dihasilkan dari analisa rinci dari kebutuhan pengguna. Desainer database harus memilih primary key yang secara logic dan unique mendefinisikan atribut-atribut nonkey pada tabel. Dalam beberapa hal, hal ini dicapai dengan kode sekuensial sederhana seperti Nomor Invoice, Nomor Check, atau Nomor Purchase Order. Pada beberapa situasi yang lain, block codes, group codes, alphabetic codes, dan mnemonic codes adalah lebih baik. Kita telah mempelajari keunggulan dan kelemahan berbagai teknik pengkodean secara detil pada bab 8.

Beberapa jenis atribut tabel adalah umum bagi semua organisasi dan bisa diturunkan dari pengertian umum. Beberapa jenis atribut lain adalah bersifat unique terhadap aplikasi tertentu dan bisa diturunkan dari analisa rinci dan menyeluruh terhadap pandangan pengguna. Namun, setiap atribut yang diberikan ke suatu tabel harus muncul baik secara langsung atau tidak langsung (nilai yang sudah diperhitungkan) pada satu atau lebih pandangan pengguna. Bila ada data yang disimpan pada suatu tabel tidak digunakan dalam suatu dokumen, report, atau penghitungan yang digunakan untuk laporan, maka tidak ada gunanya dan tidak perlu menjadi bagian dari database.

Aturan untuk foreign key. Derajat asosiasi antar tabel (yaitu, 1:1, 1:M, atau M:M) menentukan bagaimana foreign key diberikan. Kita telah mempelajari aturan-aturan untuk pemberian key untuk menghubungkan tabel pada bab 9, yang secara singkat di-review pada bagian ini.

Key pada asosiasi 1:1. Dalam asosiasi 1:1, salah satu sisi dari asosiasi tersebut pada umumnya akan memiliki kardinalitas minimum nol (zero). Ketika hal ini terjadi, primary key dari tabel yang kardinalitasnya 1,1 sebaiknya ditanamkan sebagai foreign key pada tabel yang kardinalitasnya 0,1. Bila aturan ini dibalik akan menghasilkan struktur tabel dimana tabel yang kardinalitasnya 1,1 berisi instance foreign key yang nilainya null (blank). Meskipun penghubung semacam ini akan tetap berhasil, namun tabel seperti ini adalah desain tabel yang buruk yang bisa menyebabkan inefisiensi dan berpotensi menyebabkan error. Namun demikian, dengan menaati aturan tadi semua nilai foreign key pada tabel yang kardinalitasnya 0,1 (dari asosiasi tersebut) tidak akan null. Contohnya, kita bisa lihat dari tabel 10-1 bahwa primary key untuk tabel Verify Availability/Memverifikasi Ketersediaan (Nomor Permintaan) ditetapkan sebagai foreign key ke tabel Take Order/Menangani Pesanan.

Key pada asosiasi 1:M. Dimana ada asosiasi 1:M dianatara tabel-tabel tersebut, primary key pada sisi 1 ditanamkan pada tabel yang M. contohnya, primary key tabel Employee (Employee Number) ditetapkan sebagai foreign key ke tabel-tabel Verify Availability, Take Order, dan Ship Product.

Key pada asosiasi M:M. tabel-tabel pada asosiasi M:M tidak bisa menerima foreign key yang ditanamkan dari tabel yang ter-relasi. Sebaliknya, desainer database harus membuat tabel baru yang berfungsi sebagai penghubung yang berisi dari kedua tabel foreign key. Dengan membuat satu tabel penghubung diantara tabel-tabel asli, asosiasi M:M diubah menjadi dua buah asosiasi yang 1:M (lihat gambar 10-9). Tabel penghubung sekarang bisa menerima primary key dari tabel-tabel tersebut pada sisi 1 dari dua asosiasi baru tersebut. Proses ini menghasilkan key komposit (key gabungan/kombinasi) yang bertindak sebagai primary key untuk mendefinisikan atribut-atribut (bila ada) pada tabel penghubung. Masing-masing komponen dari key komposit juga bertindak sebagai foreign key untuk menempatkan record-record yang terkait pada tabel-tabel yang terelasi. Lima tabel penghubung disajikan pada tabel 10-1: Inventori-Verify Link, Inventory-Order Link, Inventory-Ship Link, Ord-Prod-Inven Link, dan Rec-Prod-Inven Link.

Normalisasi Tabel. Penempatan primary key dan atribut-atribut pada tabel-tabel relasional harus selalu mengikuti aturan normalisasi yang telah dibahas pada bab 9. Harap diingat bahwa tabel-tabel yang dinormalisasi dengan tidak baik akan mengalami gejala-gejala operasional buruk yang biasa disebut sebagai anomali, termasuk anomali untuk update, anomali untuk insert dan anomali delete. Satu atau lebih dari anomali-anomali ini akan ada pada tabel-tabel yang tidak dinormalisasi hingga yang sudah dinormalisasi sampai level 3 (3NF). Anomali-anomali ini disebabkan oleh problem-problem struktural di dalam tabel yang disebut sevagai repeating groups (bagian yang berulang), partial dependencies (ketergantungan sebagian), dan transitive dependencies (ketergantungan transitif). Normalisasi melibatkan proses mengidentifikasi dan memindahkan secara sistematis berbagai macam ketergantungan ini dari tabel-tabel yang sedang di-review. Tabel-tabel pada 3NF akan bebas anomali dan akan memenuhi dua kondisi berikut:

1. Semua atribut nonkey akan secara sepenuhnya dan secara unique bergantung pada (yang telah didefiniskan oleh) primary key.
2. Tidak ada satupun atribut-atribut yang nonkey akan bergantung pada (yang telah didefinisikan oleh) atribut-atribut nonkey lainnya.

Tabel-tabel database pada tabel 10-1 adalah 3NF, tetapi hanya berisi atribut-atribut minimal. Harap diingat bahwa database tidaklah statis. Ketika kebutuhan pengguna berubah dan berbagai pandangan pengguna tambahan diperlukan, atribut-atribut tambahan dan barangkali tabel-tabel tambahan mungkin perlu dimasukkan ke database. Penambahan-penambahan ini harus mengikuti aturan-aturan normalisasi untuk menjaga integritas struktural tabel-tabel dan menghindari berbagai anomali. Untuk pelajaran mengenai anomali, dependency, dan normalisasi yang lebih lengkap, silahkan me-review bagian-bagian pada bab 9 dan appendixnya.

Langkah 3. Membuat Database Fisik dan Membuat Pandangan Pengguna

Pada titik ini, desainer database sudah siap membuat tabel-tabel relasional fisik berdasarkan deskripsi pada tabel 10-1. setelah tabel-tabel dibuat, beberapa diantaranya harus diisi dengan data. Tabel-tabel resource dan agent harus diinisialiasi dengan nilai-nilai data tertentu seperti kuantitas inventory yang tersedia, nama dan alamat pelanggan, dan data karyawan. System yang baru akan mulai berjalan dengan nilai-nilai awal ini untuk atribut-atribut dari tabel-tabel tersebut. Sebaliknya, tabel-tabel events dimulai dengan data yang kosong dan akan diisi melalui berbagai aktivitas proses transaksi aktual.

Database yang dihasilkan seharusnya cukup kaya dalam membantu kebutuhan informasi semua pengguna system yang sedang dimodelkan. Hal ini termasuk kebutuhan para akuntan, para personel operasi, dan manajemen. Reports, layar komputer, dan berbagai dokumen yang meliputi berbagai pandangan/tampulan diturunkan dari berbagai perintah SQL (structured query language) yang mengakses ke berbagai tabel yang telah dinormalisasi pada database. Pada bagian ini, kami menyajikan berbagai contoh reports yang dihasilkan dari berbagai tabel event.

Menghasilkan laporan keuangan dan berbagai laporan akuntansi yang lain. Pada system tradisional, laporan keuangan biasanya disiapkan dari akun-akun general ledger yang nilainya diturunkan dari jurnal voucher. Namun, berbagai artifak akunting seperti jurnal, ledgers, dan doublen-entry accounting, bukanlah entitas pada model REA. Sebaliknya, mekanisme akuntansi tradisional tersebut direproduksi dari berbagai tabel event. Untuk mengilustrasikan, gambar 10-3 menyajikan struktur untuk beberapa tabel relasional pada database Apex. Struktur tabel tersebut berkaitan dengan tabel-tabel yang ada pada tabel 10-1, tetapi beberapa atribut tidak dipakai untuk menyederhanakan gambar tersebut.

Gambar tersebut menunjukkan bagaimana angka-angka akuntansi laporan keuangan bisa dikonstruksi dari data event yang mendasari. Perhitungannya adalah seperti berikut:

    Total Sales = jumlah dari atribut Invoice Amount pada tabel Ship Product untuk semua item yang sudah dikirim pada atau sebelum tanggal penutupan akhir tahun.
    Accounnts Receivable = Total Sales dikurangi jumlah dari atribut Amount pada tabel Receive Cash untuk semua remittance yang diterima pada atau sebelum tanggal penutupan akhir tahun.
    Cost of Goods Sold = jumlah dari Quantity yang terjual pada tabel penghubung Inventory-Ship yang dikalikan dengan atribut Unit Cost pada tabel Inventory.
    Inventory = atribut Quantity On Hand yang dikalikan dengan atribut Unit Cost pada tabel Inventory.

Angka-angka akuntansi yang diekstrak dengan cara ini dari tabel-tabel REA bisa digunakan untuk menyiapkan laporan keuangan, balance sheets, dan bahkan journal entrys seperti diilustrasikan dengan laoran jirnal voucher pada gambar 10-14.

Menghasilkan laporan manajemen dari tabel-tabel REA. Tujuan kunci REA adalah menciptakan database yang memiliki kemampuan untuk menunjang berbagai pandangan pengguna. Bagian ini mengilustrasikan berbagai contoh laporan untuk pengguna non-akuntansi yang bisa dihasilkan Apex Supply dari database mereka. Gambar 10-15 menggambarkan laporan status inventory yang akan digunakan oleh karyawan pembelian mereka. Laporan ini mengidentifikasi item-item yang harus dipesan dan suppliernya masing-masing. Data untuk laporan ini berasal dari tabel Inventory dan tabel Supplier pada tabel 10-1. gambar 10-16 adalah laporan aktivitas penjualan yang diatur berdasarkan pelanggan dan produk, yang akan digunakan oleh manajer penjualan. Laporan tersebut dikontruksi dari data pada tabel Customer, tabel Ship Product, tabel penghubung Inventory-Ship, dan tabel Iventory.gambar 10-17 adalah laporan atas pertanyaan yang diajukan oleh pelanggan. Maksud dari laporan ini adalah melacak pertanyaan-pertanyaan yang diajukan oleh pelanggan untuk dibandingkan dengan penjualan aktualnya. Laporan ini menunjukkan berapa banyak waktu diluangkan untuk setiap pertanyaan oleh pelanggan dan apakah itu menyebabkan penjualan atau tidak. Tabel-tabel Customer, Verify Availability, Inventory-Verify Link, Inventory, dan Take Order menyediakan data untuk laporan tersebut.