Dalam topik sebelumnya, kita telah menunjukkan proses pemodelan pandangan (tampilan), dimana database designer mengidentifikasi dan memodelkan sekumpulan data yang diperlukan oleh masing-masing pengguna untuk mengambil keputusan atau melakukan tugasnya. Hasil dari proses ini adalah diagram ER yang menggambarkan model data pengguna. Pendekatan REA menggunakan pemodelan semantik untuk membuat diagram REA, yang dalam bebarapa hal mirip dengan diagram ER, tetapi dalam beberapa hal lain sangat berbeda. Sebelum kita membahas pemodelan REA, kita perlu mempelajari perbedaan-perbedaan ini.
Perbedaan antara diagram ER dan REA
Diagram ER dan REA sevara visual berbeda sangat signifikan. Entitas-entitas pada diagram ER hanya terdiri dari satu klas saja (tidak ada penggolongan), dan kedekatan antar entitas ditentukan oleh kardinalitasnya dan oleh apa yang secara visual diagramnya mudah dibaca. Namun dalam diagram REA, entitas-entitas dibagi kedalam tiga klas (resources, events, agents) dan konstelasi dalam diagram tersebut diatur oleh klas. Pengaturan ini seperti yang digambarkan dalam gambar 10-4. Harap diingat bahwa selama integrasi pandangan/tampilan (yang akan dipelajari nanti), konstelasi entitas mungkin perlu diubah. Namun demikian, sebagai piranti untuk desain dalam fase pemodelan pandangan, kesepakatan untuk penyusunan konstelasi tetap diikuti seperti biasa.
Perbedaan kedua dari diagram ER dan REA adalah tentang urutan events (aktivitas/transaksi). Diagram ER menyajikan gambaran statis terhadap fenomena bisnis yang mendasari. Hubungan antar data ditunjukkan melalui kardinalitas dan asosiasi, tetapi urutan aktivitas yang menentukan kardinalitas dan asosiasi tidak disajikan secara jelas. Namun demikian, diagram REA secara khas diatur dari atas ke bawah dalam konstelasi yang berfokus pada urutan aktivitas. Keuntungannya adalah bahwa selama pengembangan sistem, manajemen dan pengguna lain yang nonteknis lebih bagus dalam memahami diagram REA.
Perbedaan ketiga diagram ER dan REA berkenaan dengan kesepakatan penamaan entitas. Dalam diagram ER, nama-nama entitas selalu disajikan dalam bentuk kata benda tunggal. Pemodelan REA menerapkan aturan ini ketika memberi nama untuk entitas-entitas resource dan agent. Namun, untuk entitas-entitas event diberikan nama-nama berupa kata kerja seperti Menjual Barang, Mengambil Pesanan, atau Menerima Uang. Karena itu pembaca harus cermat supaya tidak bingung antara entitas event dengan suatu proses. Entitas-entitas event pada diagram REA menyajikan dan menggambarkan tabel-tabel database yang akan menyimpan data suatu proses, tetapi entitas-entitas tersebut tidak sedang menyajikan atau menjelaskan proses-proses itu sendiri.
Pemodelan pandangan: membuat satu diagram REA individual
Bagian ini menyajikan proses pemodelan pandangan untuk membuat diagram REA. Prosesnya meliputi langkah-langkah berikut ini:
1. Identifikasi entitas-entitas event
2. Identifikasi entitas-entitas resource
3. Identifikasi entitas-entitas agent
4. Menentukan asosiasi dan kardinalitas antar entitas
Prosedur tersebut dilakukan pada setiap fungsi organisasi yang sedang dimodelkan. Hasilnya adalah kumpulan dari diagram REA individu. Proses pemodelan kemudian selesai setelah fase integrasi pandangan (dijelaskan nanti) dimana semua model individu disatukan ke dalam satu model global tunggal. Untuk mengilustrasikan pemodelan pandangan REA, kita akan menggunakan deskripsi sederhana dari proses siklus revenue. Berikut adalah fitur-fitur kuncinya:
Apex Supply Company adalah grosir barang-barang listrik di pusat kota Philadelphia yang menjual ke para pengecer listrik. Dia memiliki inventori sekitar 10.000 item. Pelanggan memesan melalui phone dan membeli secara kredit melalui konektivitas line-of-credit yang sudah di set sebelumnya dengan Apex. Transaksi secara umum melibatkan pelanggan yang mengontak department customer services terlebih dahulu untuk memverifikasi ketersediaan dan mengecek harga item yang dicari. Bila pelanggan memutuskan untuk membeli, dia kemudian dihubungkan ke agent/karyawan penjualan yang menangani pemesanan tersebut. Karyawan bagian pengiriman kemudian mengirimkan barang ke pelanggan melalui jasa pengantaran umum (common carrier). Karyawan bagian penagihan mencatat penjualan di jurnal penjualan, menyiapkan invoice, dan mengirimkannya ke pelanggan yang diberu waktu selama 30 hari untuk membayar. Karyawan bagian piutang (AR) juga menerima copy invoice tersebut dan mencatat di ledger piutang (AR ledger). Berikutnya (dalam 30 hari) pelanggan mengirimkan check dan remittance advice ke Apex. Karyawan bagian penerimaan uang menerima check, mencatatnya ke dalam jurnal penerimaan uang, dan mengupdate akun kas/uang. Remittance advice kemudian diteruskan ke karyawan bagian piutang (AR), yang mengupdate (mengurangi) piutang pelanggan
Langkah 1. Identifikasi entitas-entitas event
Langkah pertama dalam mengembangkan model REA adalah melakukan identifikasi entitas-entitas event pada fungsi yang sedang dimodelkan. Events pada contoh siklus revenue tersebut bisa diidentifikasi melalui tindakan/aktivitas yang memiliki nilai tambah (added-value) yang diambil oleh para karyawan Apex. Entitas-entitas ini adalah Memverifikasi Ketersediaan (Verify Availability), Menangani Pesanan (Take Order), Mengirim Barang (Ship Product), dan Menerima Uang (Receive Cash). Suatu model REA setidaknya harus meliputi dua economic events yang terdiri dari aktivitas give dan receive yang mengurangi dan menambah economic resources dalam pertukaran/transaksi. Selain itu, mungkin saja melibatkan support events, yang tidak mengubah reources secara langsung. Berikutnya kita akan meneliti setiap event yang diidentifikasi di atas untuk menentukan apakah diklasifikasikan sebagai economic event atau support event.
Verify Avalilability / Memverifikasi Ketersediaan. Event Verify Availability / Memverifikasi Ketersediaan adalah support event karena tidak secara langsung menambah atau mengurangi resource. Keputusan untuk menambahkan entitas ini ke dalam model akan tergantung pada kebutuhan manager akan informasi yang berkaitan dengan pertanyaan pelanggan. Informasi seperti ini bisa membantu untuk menentukan item-item inventory mana saja yang paling sering diinginkan oleh pelanggan. Mungkin saja hal itu berbeda dengan apa yang dijual Apex ke pelanggannya. Contohnya, analisa terhadap berbagai pertanyaan yang tidak menghasilkan pemesanan mungkin menunjukkan bahwa pelanggan hanya sedang ingin tahu saja, dan mendapatkan harga yang lebih baik dari para pesaing Apex. Karena itu kita akan asumsikan bahwa Verify Availability / Memverifikasi Ketersediaan adalah aktivitas yang memiliki nilai tambah (added-value) yang harus dimodelkan pada diagram REA.
Take Order / Menangani Pesanan. Tergantung dengan keadaan, Take Order / Menangani Pesanan bisa merupakan economic event atau bisa juga support event. Menangani suatu pesanan pada umumnya hanya melibatkan komitmen pada bagian penjual untuk menjual barang ke pelanggan. Hal ini mungkin saja bahkan melibatkan penyesuaian (pengurangan) inventori yang tersedia untuk penjualan untuk mencegah barang tersebut dijual atau yang telah dijanjikan ke pelanggan yang lain. Namun, komitmen ini tidak menyebabkan pengurangan inventori secara riil dan bukan merupakan pertukaran/transaksi ekonomi. Terlebih lagi, bila kemudian klien membatalkan pesanan sebelum barang dikirim, maka tidak ada pertukaran/transaksi ekonomi yang terjadi. Sebaliknya, bila menangani suatu pesanan menyebabkan pembeli mengeluarkan resource untuk mendapatkan atau membuat produk atas permintaan pelanggan, maka economic event telang berlangsung. Untuk keperluan maksud dalam contoh ini, kita akan mengasumsikan bahwa tidak ada efek-efek ekonomi yang diturunkan dari event Take Order / Menangani Pesanan dan karena itu ini adalah support event.
Ship Product / Mengirimkan Barang. Ship Product / Mengirimkan Barang adalah economic event. ini adalah bagian give dari pertukaran/transaksi ekonomi dan mengurangi inventory resource secara langsung.
Receive Cash / Menerima Uang. Serupa dengan di atas, Receive Cash / Menerima Uang adalah economic event. Ini adalah bagian receive daro pertukaran/transaksi uang menambah resource uang.
Jenis-jenis entitas yang tidak valid. Pemodelan REA berfokus pada value chain events (aktivitas-aktivitas rantai nilai). Ini adalah berbagai aktivitas yang menggunakan uang/cash untuk mendapatkan resources seperti peralatan, bahan baku, pekerja dan kemudian menggunakan resources tersebut untuk mendapatkan revenue baru. Pekerjaan-pekerjaan pembukuan seperti mencatat penjualan ke dalam jurnal dan menetapkan piutang (AR) bukan merupakan aktivitas-aktivitas rantai nilai. Hal-hal tersebut adalah jenis-jenis entitas yang invalid dan seharusnya tidak dimasukkan dalam diagram REA.
Aturan dasar dalam REA adalah penolakan terhadap berbagai artifak akuntansi, seperti jurnal, ledger, dan double-entry bookkeeping. Menangkap berbagai data transaksi secara cukup detil akan membantu proses akuntansi tradisional. Contohnya, piutang adalah selisih antara penjualan ke pelanggan dan uang yang diterima dalam pembayaran. Karena itu, menganalisa data yang berkaitan dengan event Ship Product / Mengirimkan Barang (penjualan) dan Receive Cash / Menerima Uang bisa melegakan kebutuhan informasi yang terkait dengan fungsi-fungsi piutang dan penagihan yang digambarkan dalam kasus Apex di atas.
Setelah entitas-entitas event yang valid diidentifikasi dan diklasifikasikan baik economic event maupun support event, entitas-entitas tersebut diletakkan pada diagram REA. Kesepakatan REA adalah mengatur entitas-entitas tersebit sesuai urutan kejadian dari atas ke bawah. Gambar 10-5 menyajikan empat event di atas secara urut kejadian.
Langkah 2. Identifikasi entitas-entiras resource
Langkah berikutnya dalam membuat diagram REA adalah mengidentifikasi resources yang terkait dengan events yang sudah dipilih untuk dimodelkan. Setiap economic event dalam satu model REA harus dihubungkan minimal dengan satu antitas resource yang nilai ekonominya akan berkurang atau bertambah akibat event tersebut. Support events juga terkait dengan resources tetapi tidak menimbulkan perubahan nilai resource.
Ada orang yang mungkin berargumen secara teori bahwa semua tindakan karyawan, termasuk support events seperti Verify Availability / Memverifikasi Ketersediaan atau Take Order / Menangani Pesanan, menggunakan resource yang disebut Jasa Karyawan. Dalam kanyataannya, resource ini naik ketika karyawan memberikan layanannya ke organisasi dan secara bersamaan menurun ketika layanan tersebut diterapkan dalam kinerja pekerjaan. Dalam situasi dimana Jasa Karyawan dilacak hingga ke project atau produk khusus, entitas ini akan memberikan data yang bermanfaat dan seharusnya dimasukkan ke dalam model REA. Karena kita menganggap bahwa ini bukan kasus untuk Apex Supply, Jasa Karyawan tidak akan dimodelkan disini.
Dalam siklus pendapatan (revenue cycle) Apex, economic events hanya mengubah dua resources. Event Ship Product / Mengirim Barang mengurangi resource inventory dan event Receive Cash / Menerima Uang menambah resource uang/cash. Support events Verify Availability / Memverifikasi Ketersediaan dan Take Order / Menangani Pesanan juga terasosiasi dengan inventory, tetapi tidak mengubahnya. Resource dan entitas-entitas event yang terkait disajikan dalam Gambar 10-6.
Langkah 3. Identifikasi entitas-entitas agent
Setiap entitas economic events pada diagram REA terasosiasi minimal dengan dua entitas agent. Satu agent internal dan yang lain adalah agent eksternal. Agent eksternal yang terkait dengan semua empat event pada kasus Apex adalah Pelanggan. Selain itu, empat agent internal yang terkait dengan empat event tersebut:
1. karyawan customer service, yang terlibat dalam event Verify Availability / Memverifikasi Ketersediaan.
2. karyawan sales represtative (penjualan), yang terlibat dalam event Take Order / Menangani Pesanan.
3. karyawan pengiriman (shipping clerk), yang terlibat dalam event Ship Product / Mengirim Barang.
4. karyawan penerima uasng/cash, yang terlibat dalam event Receive Cash / Menerima Uang.
Harap diingat bahwa setiap agent internal ini pada kenyataannya adalah instance/objek dari jenis entitas Employee / Karyawan. Untuk keperluan ilustrasi pada diagram REA, kita mengidentifikasikan instance dari Employee / Karyawan (contohnya, Sales Representative atau Karyawan Pengiriman) sebagai entitas terpisah. Namun demikian, database yang muncul dari model ini pada akhirnya akan menerapkan tabel tunggal Employee / Karyawan, dan setiap instance yang ditunjukkan dalam model tersebut akan menjadi baris/record dalam tabel tersebut. Gambar 10-6 mengilustrasikan hubungan antara events dan agent-agent eksternal dan internal dalam kasus Apex.
Langkah 4. Menetukan asosiasi dan kardinalitas antar entitas.
Pada bab 9 kita mempelajari secara detil topik mengenai asosiasi dan kardinalitas entitas. Bagian ini mengandaikan bahwa kita sudah paham dengan topik tersebut yang hanya akan direview secara singkat.
Asosiasi adalah sifat dasar dari hubungan antar entitas, seperti yang disajikan oleh garis yang diberi label yang menghubungkan antar entitas tersebut. Kardinalitas (derajat aosiasi antar entitas) menjelaskan banyaknya kejadian yang mungkin terjadi dalam satu entitas yang terkait dengan satu kejadian tunggal dalam entitas yang berhubungan tersebut. Empat bentuk dasar kardinalitas yang mungkin ada: zero or one (0,1), one and only one (1,1), zero or many (0,M), and one or many (1,M).
Gambar 10-7 menyajikan tiga metode alternatif untuk menyajikan kardinalitas pada diagram REA. Alternatif 1 menyajikan metode notasi cakar ayam seperti yang telah dipelajari dalam bab 9. Contoh tersebut menjelaskan bahwa satu kejadian (record) tunggal pada entitas A terasosiasi dengan kejadian zero atau many pada entitas B. Jadi kardinalitas minimum yang mungkin terjadi adalah zero dan yang tertinggi adalah many. Dengan melihat arah yang lain, notasinya menyatakan bahwa satu kejadian tunggal pada entitas B terasosiasi dengan satu dan hanya satu kejadian pada entitas A. Terkadang kardinalitas bawah dan atas secara eksplisit ditulis diatas garis asosiasi antar entitas asperti yang ditunjukkan pada alternatif 2 pada gambar tersebut. Versi pendek tentang kardinalitas ditunjukkan sebagai alternatif 3, yang hanya menunjukkan kardinalitas atas dan menganggap kardinalitas bawah adalah zero. Kardinalitas atas untuk setiap entitas mendefinisikan keseluruhan asosiasi. Contohnya, entitas-entitas pada gambar 10-7 dikatakan memiliki asosiasi 1:M. asosiasi lain yang mungkin adalah 1:1 dan M:M.
Gambar 10-8 menyajikan model data untuk Apex yang telah direvisi. Perhatikan bahwa gambar itu sudah disederhanakan supaya lebih enak dibaca dengan menghilangkan instance yang redundant dari entitas-entitas Employee / Karyawan dan Inventory yang digambarkan pada gambar 10-6. Selain itu, gambar 10-8 menunjukkan aosiasi dan kardinalitas antar entitas dengan menggunakan metode notasi cakar ayam. Kardinalitas mencerminkan business rules (aturan bisnis) yang berlaku untuk organisasi tertentu. Terkadang aturan tersebut sangat jelas dan sama bagi semua organisasi. Contohnya, kardinalitas normal antara entitas Customer / Pelanggan dan Take Order / Menerima Pesanan adalah 1,1 dan 0,M. Ini berarti bahwa pelanggan tertentu bisa saja membuat pesanan sebanyak nol (zero) atau banyak (many) selama periode penjualan dan bahwa setiap pemesanan hanya untuk satu pelanggan. Asosiasi antar entitas ini adalah 1:M dan tidak pernah jadi 1:1 karena ini akan berarti bahwa organisasi membatasi setiap pelanggan hanya boleh membuat satu pesanan saja, yang berarti tidak logis. Asosiasi antar entitas event dan agents internal mengikuti pola yang sama. Organisasi menghendaki karyawan-karyawannya terlibat dalam banyak events, tidak hanya satu saja. Kebanyakan kardinalitas pada gambar 10-8 mencerminkan aturan yang cukup jelas. Beberapa hal yang memerlukan penjelasan lebih lanjut akan disajikan berikutnya.
Kardinalitas antara entitas-entitas Verify Availability / Menverifikasi Ketersediaan dan Take Order / Menangani Pesanan. Setiap kejadian dari entitas Verify Availability / Memverifikasi Ketersediaan adalah hasil dari pertanyaan yang diajukan oleh pelanggan. Namun, kita ketahui dari deskripsi kasus tersebut bahwa tidak semua pertanyaan berlanjut menjadi pesanan pelanggan. Sebaliknya, kita akan menyederhanakan asumsi ini bahwa setiap kejadian Take Order / Menangani Pesanan adalah hasil dari suatu pertanyaan. Karena itu kardinalitas pada sisi Take Order / Menangani Pesanan dari hubungan tersebut adalah 0,1. Sedangkan pada sisi Verify Availability / Memverifikasi Ketersediaan adalah 1,1.
Kardinalitas antara entitas-entitas Take Order / Menangani Pesanan dan Ship Product / Mengirimkan Barang. Kardinalitas 0,1 pada sisi Ship Product / Mengirimkan Barang dari relasi ini mencerminkan adanya selisih waktu antara pesanan ketika ditangani dengan dikrimkan. Ketika penjualan tidak diproses dengan cepat, kita mengasumsikan bahwa ada pesanan (kejadian Take Order / Menangani Pesanan) yang belum dikirimkan (tidak ada kejadian Ship Product / Mengirimkan Barang). Selanjutnya, pesanan yang dibatalkan sebelum dikirimkan tidak akan menyebabkan pencatatan Ship Product / Mengirimkan Barang.
Kardinalitas antara entitas-entitas Ship Product / Mengirimkan Barang dan Receive Cash / Menerima Uang. Istilah bisnis untuk perdagangan dan kebijakan pembayaran sangatlah beragam. Banyak perusahaan yang melakukan penjualan secara kredit kepada pelanggan seringkali menerima pembayaran parsial (sebagian-sebagian) selama beberapa waktu. Hal ini akan menyebabkan banyak kejadian untuk penerimaan uang/cash untuk satu kejadian pengiriman. Sebaliknya, banyak perusahaan yang pelanggannya adalah organisasi bisnis biasanya menghendaki pembayaran penuh ketika jatuh tempo. Namun demikian, para pelanggan bisnis bisa saja menyatukan banyak invoice pada satu pembayaran uang/cash untuk mengurangi menuliskan check. Karena perusahaan Apex ini adalah grosir yang melayani para pelanggan bisnis, kita akan mengasumsikan bahwa piutang dibayarkan secara penuh (bukan pembayaran secara parsial) dan bahwa para pelanggan Apex bisa saja membayar untuk banyak pengiriman dengan satu kali penerimaan uang/cash saja. Kardinalitas dalam gambar 10-8 mencerminkan aturan bisnis ini.
Kardinalitas antara entitas-entitas Cash / Uang dan Receive Cash / Menerima Uang. Resource uang/cash dari organisasi terdiri dari beberapa akun yang berbeda, seperti akun general operating, payroll imprest account, petty cash (uang kecil), dan seterusnya. Semua itu disatukan ke dalam satu akun tunggal untuk pelaporan keuangan, tetapi digunakan dan dilacak secara terpisah. Kardinalitas yang digambarkan dalam hubungan ini menunjukkan bahwa uang/cash diterima dari banyak pelanggan dan didepositokan menjadi satu akun.
Asosiasi many-to-many. Model pada gambar 10-8 menggambarkan tiga contoh asosiasi M:M. Yang pertama adalah antara antitas-entitas Verify Availability / Memverifikasi Ketersediaan dan Inventory / Persediaan. Kardinalitas 1,M ada pada sisi Inventory (Persediaan) dan kardinalitas 0,M terletak sisi Verify Availability / Memverifikasi Ketersediaan. Hal ini menunjukkan bahwa permintaan pelanggan tertentu melibatkan satu atau banyak item inventory (persediaan), dan setiap item mungkin telah ditanyakan sebanyak nol (zero) atau banyak kali pada periode tersebut. Asosiasi M:M yang kedua ada antara entitas-entitas Take Order / Menangani Pesanan dan Inventory (Persediaan). Kardinalitas 1,M ada pada sisi Inventory (Persediaan) dan kardinalitas 0,M pada sisi Take Order / Menangani Pesanan. Ini berarti bahwa pesanan tertentu bisa berisi satu atau banyak item inventory (persediaan) yang berbeda dan bahwa suatu item tertentu bisa saja tidak pernah dipesan sama sekali (barangkali produk baru) atau mungkin telah dipesan banyak kali selama periode tersebut. Situasi yang mirip ada antara entitas-entitas Ship Product / Mengirimkan Barang dan Inventory / Persediaan. Pada masing-masing kasus ini kardinalitas atas dari M menciptakan asosiasi M:M, yang kita ketahui dari bab 9 bahwa hal ini harus mengalami penyesuaian. Situasi ini adalah hasil dari data yang berulang yang perlu dinormalkan sebelum mengimplementasikan model tersebut ke database relasional. Solusinya adalah dengan membuat tiga tabel penghubung yang berisi primary key dari tabel-tabel yang terasosiasi. Tabel-tabel penghubung ini juga akan berisi detil-detil yang berkaitan dengan item-item yang ditanyakan, pesanan-pesanan yang ditangani, dan barang-barang yang dikirim.
Ketika memodelkan diagram-diagram ER tradisional, seringkali dirasa nyaman untuk menyertakan tabel-tabel penghubung ke dalam model (seperti pada bab 9) sehinggan secara erat mencerminkan database yang sebenarnya. Namun demikian, dengan penyertaan tabel-tabel penghubung pada diagram REA menyebabkan konflik dengan aturan bahwa entitas event harus terhubung dengan setidaknya satu resource dan setidaknya dua entitas agent. Gambar 10-9 menunjukkan bagaimana sebagian diagram REA Apex akan muncul ketika tabel-tabel penghubung dimasukkan. Meskipun tabel-tabel penghubung adalah persyaratan teknis untuk menerapkan asosiasi M:M pada database relasional, tabel-tabel penghubung tersebut bukanlah persyaratan teknis untuk memodelkan database. Dengan memasukkan tabel penghubung ke dalam diagram REA akan mengganggu integritas visualnya dan hanya menambahkan sedikit saja pemahaman seseorang terhadap model konseptual. Akhirnya, pada proses implementasi, desainer database akan membuat tabel-tabel penghubung. Memang, database tidak akan berfungsi tanpa adanya tabel-tabel penghubung tersebut. Namun demikian, untuk maksud proses penggambaran diagram REA, tabel-tabel penghubung hanya perlu ditunjukkan melalui asosiasi M:M.
Comments
Post a Comment