Pendekatan REA pada Pemodelan Database (Ch 10)

Bab ini mempelajari tentang model REA (resources, events, agents) sebagai sarana untuk menentukan dan mendesain
sistem informasi akuntansi yang melayani kebutuhan semua pengguna dalam suatu organisasi. Bab ini terdiri dari tiga
bagian utama. Bagian pertama akan memperkenalkan tentang pendekatan REA dan berbagai pendapat yang terkait dengan
permasalahan umum di seputar akuntansi tradisional yang bisa dipecahkan dengan pendekatan REA.
Model dasar REA terdiri dari tiga jenis entitas (resources, events, dan agents) dan sekumpulan asosiasi yang
menghubungkan entitas-entitas tersebut. Resources adalah segala hal (barang) yang memiliki nilai ekonomi dan
merupakan objek dari pertukaran/transaksi (secara ekonomi) dengan para rekan bisnis/dagang. Events dalam REA terdiri
dari dua kelompok umum: economic events atau aktivitas ekonomi dan support events atau aktivitas pendukung. Yang
dimaksud dengan economic events adalah yang mempunyai efek terhadap perubahan resources (entah
peningkatan/penambahan atau penurunan/pengurangan). Sedangkan support events adalah yang terkait dengan
pengendalian (kontrol), perencanaan, dan berbagai aktivitas manajerial yang terkait dengan economic events namun tidak
secara langsung berefek pada perubahan resources. Agents adalah orang-orang atau organisasi baik di dalam maupun di
luar organisasi yang berpartisipasi dalam suatu economic event. Satu fitur kunci dalam REA adalah adanya konsep dualitas
ekonomi. Setiap economic event atau aktivitas ekonomi selalu dicerminkan oleh satu event yang lain dalam arah yang
berlawanan. Kedua aktivitas tersebut adalah aktivitas memberi dan aktivitas menerima dalam suatu aktivitas pertukaran
ekonomi.
Bagian kedua menyajikan berbagai tahapan proses dalam membuat model REA. Fokus dalam pembahasan disini adalah
memodelkan satu pandangan (tampilan) dari keseluruhan database. Tahapan-tahapan ini mencakup: (1) mengidentifikasi
berbagai entitas events/aktivitas yang akan dimodelkan, (2) mengidentifikasi berbagai entitas resources yang mengalami
perubahan yang diakibatkan oleh events, (3) mengidentifikasi berbagai entitas agents yang terlibat dalam events, dan (4)
menentukan asosiasi dan kardinalitas di antara entitas-entitas tersebut.
Bagian ketiga dan terakhir adalah menyajikan proses integrasi berbagai pandangan (tampilan) dari semua bagian dalam
organisasi, dimana beberapa diagram REA yang dibuat secara mandiri dan per-bagian disatukan ke dalam model REA
tunggal yang mencakup satu perusahaan. Langkah-langkah untuk melakukan integrasi berbagai pandangan (tampilan) dari
tiap-tiap bagian ini adalah: (1) mengkonsolidasikan semua model individual/parsial; (2) mendefinisikan primary key, foreign
key, dan berbagai atribut; dan (3) mengkonstruksi database fisik dan membuat pandangan/tampilan pengguna. Bagian ini
menyimpulkan dengan suatu diskusi mengenai keuntungan REA dalam mencapai keunggulan kompetitif.
Pendekatan REA
Inti dari philosofi database adalah adanya pemahaman bahwa data perusahaan harus menunjang kebutuhan informasi
semua pengguna dalam organisasi tersebut. Karena itu satu aspek penting dalam pemodelan data adalah membuat suatu
model yang diyakini mencerminkan realitas organisasi. Hal ini bukanlah hal yang mudah dicapai ketika berbagai macam
orang dalam organisasi melihat dan menggunakan data yang sama dengan cara yang berbeda.

Dari bab 9 kita ingat bahwa pandangan (tampilan) pengguna adalah sekumpulan data yang dibutuhkan oleh pengguna
tertentu untuk mencapai pekerjaan-pekerjaan yang ditugaskan
kepadanya. Contohnya, pandangan (tampilan) bagi karyawan bagian general ledger akan memerlukan chart of accounts
(daftar kode akun transaksi) organisasi, namun tidak memerlukan
data transaksi detilnya. Pandangan (tampilan) untuk manajer penjualan mungkin memerlukan data penjualan pelanggan
secara detil yang sudah dikelompokkan berdasarkan produk, area penjualan, dan tenaga/karyawan penjualnya. pandangan
(tampilan) untuk manajer produksi mungkin akan memerlukan inventori barang jadi yang tersedia, kapasitas proses
manufaktur yang tersedia, dan lead time dari vendor.
Masalah muncul dalam menyatukan berbagai kebutuhan yang beragam ini ketika satu pandangan (tampilan) yang tidak pas
untuk berbagai maksud dan tujuan yang luas mendominasi proses pengumpulan, peringkasan, penyimpanan dan pelaporan
transaksi dan berbagai data sumber daya. Profesi akuntansi sudah lama dikritik karena hanya berfokus pada peran yang
terlalu sempit dalam informasi akuntansi. Saat ini banyak peneliti yang mendorong profesi akuntansi untuk mengalihkan
fokus dari masalah debit, kredit, double-entry accounting, dan GAAP untuk lebih maju dengan memberikan informasi yang
bermanfaat dalam proses pengambilan keputusan dan membantu organisasi untukmengidentifikasi dan mengendalikan
risiko bisnis.
Para manajer modern memerlukan baik informasi financial maupun nonfinancial dalam format dan tingkat-tingkat yang

terpadu dimana hal ini pada umumnya tidak bisa diberikan oleh sistem akuntansi tradisional yang bebrbasis GAAP.
Jawaban dari berbagai organisasi terhadap dominansi informasi akuntansi yang berpandangan (tampilan) tunggal adalah
dengan membuat berbagai sistem informasi yang terpisah untuk menunjang tiap-tiap pandangan (tampilan) pengguna. Hal
ini menyebabkan organisasi memiliki banyak sistem informasi yang secara fungsional tidak saling terkoneksi. Seringkali data
yang telah dimasukkan ke suatu sistem dimasukkan lagi ke sistem-sistem yang lain. Dengan begitu banyaknya duplikasi
data, persoalan mengenai akurasi dan kekinian data memunculkan masalah yang serius.
Kekhawatiran semacam itu telah menyebabkan sejumlah peneliti database untuk mengembangkan model semantik atau
framework untuk mendesain sistem informasi akuntansi yang mendukung penerapan berbagai sudut pandang pengguna.
Model sematik akan menangkap makna operasional dari data pengguna dan memberikan deskripsi yang singkat mengenai
hal tersebut. Satu contoh semacam itu, yang sangat penting bagi akuntansi, adalah model REA. Pada tahun 1982, REA pada
awalnya diusulkan sebagai kerangka teoritis untuk akuntansi. Namun, sejak saat itu, REA mendapatkan perhatian yang
besar sebagai alternatif praktis terhadap sistem akuntansi tradisional.

Membuat model REA (Ch. 10)

Dalam bab 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 masingmasing 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.