Pendekatan REA untuk Pemodelan Database

Bab ini membahas sumber daya, peristiwa, dan agen (REA) model sebagai sarana menentukan
dan merancang sistem informasi akuntansi yang melayani kebutuhan semua pengguna dalam
suatu organisasi. Bab ini terdiri dari tiga bagian utama. Yang pertama memperkenalkan
Pendekatan REA dan komentar tentang masalah umum juga? Ciated dengan praktik akuntansi
tradisional yang dapat diselesaikan melalui pendekatan REA. Bagian ini menyajikan Model REA
dan menggambarkan struktur diagram REA. Model REA dasar terdiri dari tiga jenis entitas
(sumber daya, acara, dan agen) dan satu set asosiasi menghubungkan ??? di dalamnya. Sumber
daya adalah hal-hal yang bernilai ekonomi bagi organisasi dan merupakan objek pertukaran
ekonomi dengan mitra dagang. Peristiwa REA dibagi menjadi dua kelompok umum: peristiwa
ekonomi dan acara dukungan. Peristiwa ekonomi fenomena yang mempengaruhi perubahan
(bertambah atau berkurang) di sumber daya. Acara-acara pendukung termasuk kegiatan
pengendalian, perencanaan, dan manuver yang terkait dengan peristiwa ekonomi tetapi dilakukan
tidak secara langsung mempengaruhi perubahan sumber daya. Agen adalah individu? Als dalam
dan di luar organisasi yang berpartisipasi dalam suatu peristiwa ekonomi. Fitur utama dari REA
adalah konsep dualitas eko-nomis. Setiap peristiwa ekonomi dicerminkan oleh yang lain acara
dalam arah yang berlawanan. Peristiwa ganda ini merupakan acara memberi dan menerima acara
pertukaran ekonomi.Bagian kedua menyajikan proses multistep lihat pemodelan untuk membuat
model REA. Fokusnya di sini adalah pada pemodelan satu tampilan seluruh database. Langkah-
langkahnya yang terlibat adalah: (1) mengidentifikasi entitas peristiwa yang akan
dimodelkan, (2)mengidentifikasi entitas sumber daya yang diubah oleh peristiwa,
(3) iden ???tifikasi entitas agen yang berpartisipasi dalam acara, dan (4)
menghalangi asosiasi tambang dan kardinalitas antar entitas. Bagian ketiga dan
terakhir menyajikan tugas melihat inte ??? gration, di mana beberapa diagram REA
individu dimasukkan ke dalam model perusahaan tunggal. Langkah-langkahnya
terlibat dalam integrasi pandangan adalah: (1) mengkonsolidasikan model ual
individual; (2) menentukan kunci primer, kunci asing, dan atribut; dan (3)
membangun basis data fisik dan menghasilkan pandangan pengguna. Bagian ini
diakhiri dengan diskusi tentang keuntungan dari REA dalam mencapai keunggulan
kompetitif. Pusat ke filosofi database adalah pengakuan bahwa data perusahaan
harus mendukung informasi kebutuhan semua pengguna di organisasi. Suatu aspek penting
dari pemodelan data, oleh karena itu, adalah menciptakan suatu model yang dengan setia
mencerminkan realitas fisik organisasi. Ini tidak mudah dilakukan ketika berbeda orang-orang
dalam organisasi melihat dan menggunakan data yang sama secara berbeda. Anda akan ingat dari
Bab 9 bahwa pandangan pengguna adalah kumpulan data yang perlu dicapai oleh pengguna
tertentu tugasnya yang ditugaskan. Misalnya, tampilan pengguna kasir buku besar akan
menyertakan organisasi bagan akun, tetapi tidak detail data transaksi. Tampilan manajer
penjualan dapat mencakup data penjualan yang terperinci berdasarkan produk, wilayah, dan
penjual. Tampilan manajer produksi mungkin termasuk persediaan barang jadi di tangan,
kapasitas produksi yang tersedia, dan waktu tunggu vendor. Masalah muncul dalam memenuhi
beragam kebutuhan ini ketika satu tampilan yang tidak sesuai untuk tujuan entitas yang luas
mendominasi pengumpulan, peringkasan, penyimpanan, dan pelaporan transaksi dan
data sumber daya. Profesi akuntansi telah lama dikritik karena terlalu berfokus pada peran
informasi akuntan. Banyak peneliti hari ini mendorong profesi untuk mengalihkan penekanannya
dari debet, kredit, akuntansi double-entry, dan GAAP dan bergerak ke arah menyediakan
informasi yang berguna untuk pengambilan keputusan dan membantu organisasi
mengidentifikasi dan mengendalikan risiko bisnis. Manajer modern memerlukan informasi
keuangan dan nonkeuangan dalam format dan pada tingkat agregasi bahwa sistem akuntansi
tradisional berbasis GAAP umumnya gagal menyediakan. Tanggapan dalam banyak organisasi
untuk pandangan tunggal yang dominan dari informasi akuntansi telah menciptakan sistem
informasi terpisah untuk mendukung pandangan setiap pengguna. Ini telah menghasilkan
organisasi dengan banyak informasi sistem yang terputus secara fungsional. Seringkali, data
yang dimasukkan dalam satu sistem perlu dimasukkan kembali ke dalam yang lain. Dengan
duplikasi data yang meluas, akurasi dan masalah mata uang data menimbulkan masalah serius.

Keprihatinan tersebut telah menyebabkan sejumlah peneliti database untuk mengembangkan

model semantik atau kerangka kerja untuk merancang sistem informasi akuntansi yang
mendukung beberapa pandangan pengguna. Tutup model semantik memunculkan makna
operasional dari data pengguna dan memberikan deskripsi singkat tentangnya. Salah satu contoh
seperti itu, sangat penting untuk akuntansi, adalah model REA. Pada tahun 1982, REA awalnya
diusulkan sebagai kerangka teoritis untuk akuntansi.1 Sejak saat itu, bagaimanapun, telah
mendapat perhatian yang cukup sebagai alternatif praktis untuk sistem akuntansi tradisional.

MODEL REA

Model REA adalah kerangka kerja akuntansi untuk pemodelan sumber daya penting organisasi,
peristiwa, dan agen serta hubungan di antara mereka. Tidak seperti beberapa sistem akuntansi
tradisional, sistem REA mengizinkan baik data akuntansi dan nonaccounting untuk diidentifikasi,
ditangkap, dan disimpan secara terpusat. database. Dari repositori ini, pandangan pengguna dapat
dibangun yang memenuhi kebutuhan semua pengguna di orga ??? nization. Model REA dapat
diimplementasikan baik dalam arsitektur relasional atau object-oriented architec ??? tures. Untuk
keperluan diskusi dalam bab ini, kita akan mengasumsikan database relasional karena ini lebih
banyak arsitektur umum untuk aplikasi bisnis.Gambar 10-1 mengilustrasikan model REA dasar,
yang merupakan versi unik dari hubungan entitas (ER)
diagram yang terdiri dari tiga jenis entitas (sumber daya, peristiwa, dan agen) dan satu set
asosiasi yang terhubung mereka. Dari titik ini, kita akan mengacu pada teknik dokumentasi ini
sebagai diagram REA. Pertemuan untuk menggambarkan asosiasi, menugaskan kardinalitas, dan
menormalisasi tabel seperti yang dibahas dalam Bab 9 untuk diagram ER tradisional juga
berlaku untuk diagram REA.
Elemen dari Model REA
SUMBER DAYA. Sumber daya ekonomi adalah hal-hal yang bernilai ekonomi bagi organisasi.
Mereka didefinisikan sebagai objek yang langka dan di bawah kendali perusahaan. Sumber daya
digunakan dalam ekonomi pertukaran dengan mitra dagang dan ditingkatkan atau dikurangi
dengan pertukaran
[11/4 17.21] Desy Khofifah: Hal.461 bagan dulu
ACARA. Pemodelan REA mencakup dua kelas acara: peristiwa ekonomi dan acara dukungan.
Peristiwa ramah lingkungan adalah fenomena yang mempengaruhi perubahan (meningkat atau
menurun) dalam sumber daya yang diwakili oleh
hubungan aliran stok pada Gambar 10-1. Mereka hasil dari kegiatan seperti penjualan produk ke
pelanggan, penerimaan uang tunai dari pelanggan, dan pembelian bahan baku dari vendor.
Peristiwa ekonomi adalah elemen informasi penting dari sistem akuntansi dan harus ditangkap
sebagai terpilah (sangat tinggi rinci) bentuk mungkin untuk menyediakan database yang kaya.
Acara pendukung (tidak ditunjukkan pada Gambar 10-1) termasuk kontrol, perencanaan, dan
aktivitas manajemen itu terkait dengan peristiwa ekonomi, tetapi tidak secara langsung
mempengaruhi perubahan sumber daya. Contoh dukungan Peristiwa meliputi (1) menentukan
ketersediaan persediaan untuk pelanggan sebelum melakukan penjualan, (2) memverifikasi
informasi pendukung (melakukan pertandingan tiga arah) sebelum menyalurkan uang tunai
kepada vendor, dan (3) memeriksa kredit pelanggan sebelum memproses penjualan. AGEN.
Agen ekonomi adalah individu dan departemen yang berpartisipasi dalam ekonomi dan
dukungan acara. Mereka adalah pihak-pihak di dalam dan di luar organisasi dengan wewenang
discretionary untuk menggunakan atau tidak berpose sumber daya ekonomi. Setiap peristiwa
ekonomi dikaitkan dengan setidaknya satu agen internal dan satu agen eksternal yang
berpartisipasi dalam pertukaran. Peran masing-masing agen internal dan eksternal di transaksi
dengan pihak luar biasanya terlihat jelas. Misalnya, dalam transaksi penjualan, agen internal
berbagai karyawan perusahaan dan agen eksternal adalah pelanggan. Namun, untuk transaksi
internal murni, peran agen internal dan eksternal mungkin tidak begitu jelas. Konvensi di REA
pemodelan adalah untuk memperlakukan transaksi seperti jika mereka adalah penjualan.
Misalnya, dalam transfer produk dari work-in-process untuk persediaan barang jadi, petugas
pekerjaan-dalam-proses dipandang sebagai menjual produk petugas barang jadi. Oleh karena itu,
petugas menyerahkan kontrol dan mengurangi sumber daya (kerja-dalam-proses Petugas) adalah
agen internal dan petugas yang memegang kendali dan meningkatkan sumber daya (petugas
barang jadi) adalah agen eksternal. Agen internal dan eksternal juga terlibat dalam acara
dukungan, tetapi pertukaran melibatkan informasi bukan sumber daya ekonomi. Misalnya,
pelanggan (agen eksternal) yang memeriksa harga produk menerima informasi dari petugas
penjualan (agen internal), yang menyerahkan informasi. Menautkan internal agen untuk acara
dengan cara ini mempromosikan kontrol dan memungkinkan organisasi untuk menilai tindakan
yang diambil oleh karyawan mereka. KUALITAS. Fitur semantik REA berasal dari elemen
transaksi ekonomi. Dasar pemikirannya di balik transaksi ekonomi adalah bahwa dua agen
masing-masing memberikan yang lain sumber daya sebagai ganti yang lain sumber. Pada
kenyataannya, pertukaran adalah sepasang peristiwa ekonomi, yang diekspresikan melalui
dualitas seperti juga ditunjukkan pada Gambar 10-1. Dengan kata lain, setiap peristiwa ekonomi
dicerminkan oleh ekonomi yang terkait acara dalam arah yang berlawanan. Gambar 10-2
memperluas model REA dasar untuk mengilustrasikan koneksi antara peristiwa ganda ini: acara
memberi dan menerima acara. Dari perspektif organisasi
[11/4 17.25] Desy Khofifah: Hal.462 Bagan di bawah

fungsi yang dimodelkan, yang memberikan setengah dari pertukaran menurunkan sumber daya
ekonomi, seperti yang diwakili oleh asosiasi aliran keluar. Setengah menerima pertukaran
meningkatkan sumber daya ekonomi diwakili oleh asosiasi inflow. Gambar 10-3 menyajikan
beberapa contoh acara memberi dan menerima sebagaimana adanya berhubungan dengan
pendapatan, pengeluaran, dan siklus konversi. Perhatikan bahwa pertukaran ekonomi tidak
memerlukan peristiwa dualitas terjadi secara bersamaan. Sebagai contoh, inventaris langsung
dikurangi dengan penjualan ke pelanggan, tetapi uang tunai tidak dapat ditingkatkan oleh
pengiriman khusus ??? er selama beberapa minggu. Model REA mengakomodasi transaksi
berbasis kredit dan waktu yang dibutuhkan, tetapi tidak menggunakan mekanisme tradisional
seperti buku besar AR atau AP dalam akuntansi untuk acara-acara ini. Bahkan, REA menolak
kebutuhan untuk artefak akuntansi, termasuk jurnal, buku besar, dan pembukuan entri ganda.
Seperti yang disebutkan sebelumnya, fenomena ekonomi harus ditangkap dalam bentuk terpisah
yang konsisten dengan kebutuhan banyak pengguna. Untuk mencerminkan semua aspek
ekonomi yang relevan peristiwa, oleh karena itu, data bisnis tidak boleh diformat atau dibatasi
secara artifisial. Jurnal, buku besar, dan pembukuan double-entry adalah mekanisme tradisional
untuk memformat dan mentransmisikan data akuntansi, tetapi mereka bukan elemen penting dari
database akuntansi. Sistem REA menangkap esensi dari apa akun akuntan dengan memodelkan
fenomena ekonomi yang mendasari secara langsung. Organisasi yang menggunakan REA dapat
menghasilkan laporan keuangan, jurnal, buku besar, dan laporan akuntansi double-entry
langsung dari tabel database acara melalui tampilan pengguna. Kami mendemonstrasikan
bagaimana hal ini dilakukan nanti di bab ini. Mengembangkan Model REA Pada bab
sebelumnya kami menggambarkan proses pemodelan pandangan, di mana perancang basis data
mengidentifikasi dan memodelkan kumpulan data yang dibutuhkan pengguna individual untuk
membuat keputusan atau melakukan tugas. Hasil dari proses ini adalah diagram ER yang
menggambarkan model data pengguna. Pendekatan REA menggunakan semantic mod ??? eling
untuk membangun diagram REA, yang dalam beberapa hal mirip dengan diagram ER, tetapi
dalam hal lain sangat berbeda. Sebelum kita menjelaskan pemodelan pandangan REA, kita perlu
memeriksa perbedaan-perbedaan ini.
[11/4 17.26] Desy Khofifah: Hal. 463 Bagan di bawah

PERBEDAAN ANTARA DIAGRAM ER DAN REA

Diagram ER dan REA berbeda secara visual dengan cara yang signifikan. Entitas dalam diagram
ER adalah satu kelas, dan kedekatan mereka dengan entitas lain ditentukan oleh kardinalitas
mereka dan oleh apa yang secara visual menyenangkan untuk dijaga diagram yang bisa dibaca.
Entitas dalam diagram REA, bagaimanapun, dibagi menjadi tiga kelas (sumber daya,
acara, dan agen) dan diatur dalam rasi bintang oleh kelas pada diagram. Pengaturan ini
diilustrasikan pada Gambar 10-4. Perhatikan bahwa selama integrasi tampilan (dibahas nanti),
ketika beberapa diagram REA individu digabungkan untuk membentuk model global tunggal,
rasi bintang entitas mungkin perlu diubah. Sebagai alat desain selama fase pemodelan tampilan,
namun konvensi konstelasi biasanya diikuti. Perbedaan kedua antara diagram ER dan REA
melibatkan urutan peristiwa. Diagram ER menyajikan gambaran statis dari fenomena bisnis yang
mendasarinya. Hubungan antar data ditunjukkan melalui kardinalitas dan asosiasi, tetapi urutan
kegiatan yang menentukan kardinalitas dan asso ??? ciations tidak jelas diwakili. Diagram REA,
bagaimanapun, biasanya disusun dari atas ke bawah dalam rasi bintang untuk fokus pada urutan
kejadian. Keuntungan dari ini adalah bahwa selama system pengembangan, manajemen dan
pengguna nonteknis lebih baik memahami diagram REA.Perbedaan ketiga antara diagram ER
dan REA berkaitan dengan konvensi penamaan untuk entitas. Di Diagram ER, nama entitas
selalu direpresentasikan dalam bentuk kata benda tunggal. Pemodelan REA menerapkan ini
aturan saat menugaskan nama ke entitas sumber daya dan agen. Entitas acara, bagaimanapun,
diberikan kata kerja (action) nama-nama seperti Jual Persediaan, Ambil Pesanan, atau Terima
Uang Tunai. Oleh karena itu, pembaca harus berhati-hati tidak membingungkan entitas acara
dengan suatu proses. Entitas event pada diagram REA mewakili dan menggambarkan data ???
tabel dasar yang akan menyimpan data tentang proses, tetapi mereka tidak mewakili atau
menggambarkan proses diri.

LIHAT PEMODELAN: MENCIPTAKAN DIAGRAM REAKSI INDIVIDU

Bagian ini menjelaskan proses pemodelan pandangan sebagaimana diterapkan untuk membuat
diagram REA. Proses
melibatkan langkah-langkah berikut:

1. Identifikasi entitas acara.

2. Identifikasi entitas sumber daya.
[11/4 17.27] Desy Khofifah: Hal.465 bagan di bawah
3. Identify the agent entities.

4. Determine associations and cardinalities between entities.

These procedures are performed for each organizational function being modeled. The result is
several

individual REA diagrams. The modeling process is completed during the view integrating phase

(described later) where the individual models are consolidated into a single global model. To
illustrate

REA view modeling, we will use a simplified description of a revenue cycle process. Following
are its

key features:

Apex Supply Company is a downtown Philadelphia wholesaler of electrical products that sells to
electrical retailers. It carries an inventory of approximately 10,000 items. Customers place orders
by phone

and buy on credit through a line-of-credit arrangement with Apex. A typical transaction involves
the
customer first contacting the customer services department to verify availability and check the
price of

the item or items being sought. If the customer decides to buy, he or she is transferred to a sales
agent,

who takes the order. The shipping clerk sends the products to the customer by a common carrier.
The

billing clerk records the sale in the sales journal, prepares an invoice, and sends it to the
customer,

who is given 30 days to make payment. The AR clerk also receives a copy of the invoice and
records it

in the AR ledger. Subsequently (within 30 days) the customer sends a check and the remittance
advice

to Apex. The cash receipts clerk receives the check, records it in the cash receipts journal, and
updates

the cash account. The remittance advice goes to the AR clerk, who updates (reduces) the
customer’s

account receivable.
[11/4 17.28] Desy Khofifah: 3. Identifikasi entitas agen.

4. Tentukan asosiasi dan kardinalitas antar entitas.

Prosedur ini dilakukan untuk setiap fungsi organisasi yang dimodelkan. Hasilnya beberapa

diagram REA individu. Proses pemodelan selesai selama fase integrasi tampilan

(dijelaskan kemudian) di mana model individu dikonsolidasikan ke dalam model global tunggal.
Menggambarkan

Pemodelan REA view, kami akan menggunakan deskripsi yang disederhanakan dari proses siklus
pendapatan. Berikut ini adalah miliknya

fitur utama:

Apex Supply Company adalah pusat kota Philadelphia grosir produk listrik yang menjual ke
pengecer elektronik. Ini membawa inventaris sekitar 10.000 item. Pelanggan memesan melalui
telepon

dan membeli secara kredit melalui pengaturan line-of-kredit dengan Apex. Transaksi tipikal
melibatkan

pelanggan pertama menghubungi departemen layanan pelanggan untuk memverifikasi

ketersediaan dan memeriksa harga

barang atau barang yang dicari. Jika pelanggan memutuskan untuk membeli, dia ditransfer ke
agen penjualan,
siapa yang mengambil pesanan. Petugas pengiriman mengirimkan produk ke pelanggan oleh
operator umum. Itu

Petugas penagihan mencatat penjualan dalam jurnal penjualan, menyiapkan faktur, dan
mengirimkannya ke pelanggan,

yang diberi 30 hari untuk melakukan pembayaran. Petugas AR juga menerima salinan faktur dan
mencatatnya

dalam buku besar AR. Selanjutnya (dalam 30 hari) pelanggan mengirimkan cek dan saran
pengiriman uang

ke Apex. Petugas penerimaan kas menerima cek, mencatatnya dalam jurnal penerimaan kas, dan
pembaruan

akun kas. Saran pengiriman uang pergi ke petugas AR, yang memperbarui (mengurangi)
pelanggan

piutang dagang.
[11/4 17.29] Desy Khofifah: Step 1. Identify the Event Entities

The first step in developing an REA model is to identify the event entities in the function being
modeled.

The events in this revenue cycle example can be identified as the value-added actions that Apex
employees take. These entities include Verify Availability, Take Order, Ship Product, and
Receive Cash. An

REA model must, at a minimum, include the two economic events that constitute the give and
receive

activities that reduce and increase economic resources in the exchange. In addition, it may
include support events, which do not change resources directly. We will next examine each
identified event above to

determine whether it should be classified an economic event or a support event.

VERIFY AVAILABILITY. The Verify Availability event is a support event because it does not
directly

increase or decrease a resource. The decision to add this entity to the model will depend on
management’s

need for information regarding customer inquiries. Such information could help them determine
which inventory items customers most frequently demand. This may be different from what
Apex is actually selling

to customers. For example, an analysis of inquiries that do not lead to placed orders may indicate
that customers are shopping around for, and getting, better deals from Apex competitors. We will
assume, therefore, that Verify Availability is a value-added activity that should be modeled in the
REA diagram.

TAKE ORDER. Depending on the circumstances, Take Order could be either an economic or
support
event. Taking an order typically involves only a commitment on the part of the seller to sell
goods to the

customer. It may even involve adjusting (decreasing) the inventory available for sale to prevent it
from

being sold or promised to other customers. This commitment, however, does not cause a real
decrease in

inventory and is not an economic exchange. Furthermore, if the client subsequently cancels the
order

before it is shipped, no economic exchange will occur. On the other hand, if taking an order
causes the

buyer to expend resources to obtain or manufacture the product on behalf of the customer, then
an economic event will have occurred. For the purposes of this example, we will assume that no
economic consequences derive directly from the Take Order event and it is, therefore, a support
event.

SHIP PRODUCT. Ship Product is an economic event. This is the give half of an economic
exchange

and reduces the inventory resource directly.

RECEIVE CASH. Similarly, the Receive Cash event is an economic event. This is the receive
half of

the exchange that increases the cash resource.

INVALID ENTITY TYPES. REA modeling focuses on value chain events. These are the
activities that

use cash to obtain resources including equipment, materials, and labor and then employ those
resources

to earn new revenues. Bookkeeping tasks such as recording a sale in the journal and setting up an
account

receivable are not value chain activities. These are invalid entity types and should not be
included in an

REA diagram.

A fundamental precept of REA is the rejection of accounting artifacts, including journals,

ledgers, and

double-entry bookkeeping. Capturing transaction data in sufficient detail adequately serves

traditional

accounting requirements. For example, an account receivable is the difference between a sale to
a customer and cash received in payment of the sale. Therefore, analyzing data pertaining to the
Ship Product
(sales) and Receive Cash events can satisfy the information needs related to the accounts
receivable and

billing functions described in the Apex case previously presented.

Once the valid event entities are identified and classified as either economic or support events,
they

are placed on the REA diagram. REA convention is to arrange these entities in their sequence of
occurrence from top to bottom on the diagram. Figure 10-5 presents the four events previously
described in

sequence of occurrence.

Step 2. Identify the Resource Entities

The next step in creating the REA diagram is to identify the resources that are impacted by the
events

selected to be modeled. Each economic event in an REA model must be linked to at least one
resource
[11/4 17.29] Desy Khofifah: Langkah 1. Identifikasi Entitas Acara

Langkah pertama dalam mengembangkan model REA adalah mengidentifikasi entitas peristiwa
dalam fungsi yang dimodelkan.

Peristiwa dalam contoh siklus pendapatan ini dapat diidentifikasi sebagai tindakan nilai tambah
yang digunakan oleh Apex. Entitas ini termasuk Verifikasi Ketersediaan, Ambil Pesanan, Kirim
Produk, dan Terima Uang Tunai. Sebuah

Model REA harus, paling tidak, memasukkan dua peristiwa ekonomi yang merupakan pemberian
dan penerimaan

kegiatan yang mengurangi dan meningkatkan sumber daya ekonomi di bursa. Selain itu,
mungkin termasuk sup ??? peristiwa port, yang tidak mengubah sumber daya secara langsung.
Kami selanjutnya akan memeriksa setiap peristiwa yang diidentifikasi di atas

menentukan apakah itu harus diklasifikasikan sebagai peristiwa ekonomi atau acara dukungan.

KETERSEDIAAN VERIFIKASI. Acara Verifikasi Ketersediaan adalah acara dukungan karena

tidak secara langsung

menambah atau mengurangi sumber daya. Keputusan untuk menambahkan entitas ini ke model
akan bergantung pada manajemen perlu informasi mengenai pertanyaan pelanggan. Informasi
semacam itu dapat membantu mereka menentukan item pelanggan mana yang paling sering
diminta pelanggan. Ini mungkin berbeda dari apa yang sebenarnya dijual Apex
kepada pelanggan. Misalnya, analisis pertanyaan yang tidak mengarah pada pesanan yang
ditempatkan dapat menunjukkan bahwa pelanggan berbelanja di sekitar, dan mendapatkan,
penawaran yang lebih baik dari pesaing Apex. Kami akan menganggap, ada kedepan, bahwa
Verifikasi Ketersediaan adalah kegiatan nilai tambah yang harus dimodelkan dalam diagram
REA.

TAKE ORDER. Tergantung pada keadaan, Take Order bisa menjadi ekonomi atau dukungan
peristiwa. Mengambil pesanan biasanya hanya melibatkan komitmen pada bagian penjual untuk
menjual barang ke pelanggan. Bahkan mungkin melibatkan penyesuaian (penurunan) persediaan
tersedia untuk dijual untuk mencegahnya dijual atau dijanjikan kepada pelanggan lain.
Komitmen ini, bagaimanapun, tidak menyebabkan penurunan nyata inventaris dan bukan
pertukaran ekonomi. Selanjutnya, jika klien selanjutnya membatalkan pesanan sebelum dikirim,
tidak ada pertukaran ekonomi yang akan terjadi. Di sisi lain, jika mengambil pesanan
menyebabkan pembeli menghabiskan sumber daya untuk mendapatkan atau memproduksi
produk atas nama pelanggan, maka peristiwa eko-nomik akan terjadi.
Untuk keperluan contoh ini, kita akan berasumsi bahwa tidak ada urutan kon fl ik ekonomi yang
berasal langsung dari peristiwa Take Order dan oleh karena itu, merupakan suatu acara
dukungan.

PRODUK KAPAL. Produk Kapal adalah peristiwa ekonomi. Ini adalah memberi setengah dari
pertukaran ekonomi

dan mengurangi sumber daya inventaris secara langsung.

MENERIMA TUNAI. Demikian pula, acara Penerimaan Uang Tunai adalah peristiwa ekonomi.
Ini adalah menerima setengah dari

pertukaran yang meningkatkan sumber daya kas.

JENIS ENTITAS INVALID. Pemodelan REA berfokus pada peristiwa rantai nilai. Ini adalah
kegiatan-kegiatan itu

menggunakan uang tunai untuk mendapatkan sumber daya termasuk peralatan, bahan, dan
tenaga kerja dan kemudian menggunakan sumber daya tersebut

untuk mendapatkan pemasukan baru. Tugas pembukuan seperti merekam penjualan dalam jurnal
dan membuat akun

piutang adalah bukan aktivitas rantai nilai. Ini adalah jenis entitas yang tidak valid dan tidak
boleh dimasukkan ke dalam

Diagram REA.

Ajaran mendasar REA adalah penolakan artefak akuntansi, termasuk jurnal, buku besar, dan

pembukuan entri ganda. Menangkap data transaksi dengan cukup detail secara memadai
melayani tradisional

persyaratan akuntansi. Misalnya, piutang adalah perbedaan antara penjualan ke pelanggan dan
uang tunai yang diterima dalam pembayaran penjualan. Oleh karena itu, analisis data yang
berkaitan dengan Produk Kapal

(penjualan) dan Menerima acara Kas dapat memenuhi kebutuhan informasi terkait dengan
piutang dan

fungsi penagihan yang dijelaskan dalam kasus Apex yang sebelumnya disajikan.

Setelah entitas peristiwa yang valid diidentifikasi dan diklasifikasikan sebagai peristiwa ekonomi
atau dukungan, mereka
ditempatkan pada diagram REA. Konvensi REA adalah mengatur entitas-entitas ini dalam urutan
mereka terjadi dari bawah ke atas pada diagram. Gambar 10-5 menyajikan empat peristiwa yang
sebelumnya dijelaskan dalam

urutan kejadian.

Langkah 2. Identifikasi Entitas Sumber Daya

Langkah selanjutnya dalam menciptakan diagram REA adalah mengidentifikasi sumber daya
yang dipengaruhi oleh peristiwa

dipilih untuk dimodelkan. Setiap peristiwa ekonomi dalam model REA harus dikaitkan dengan
setidaknya satu sumber daya
[11/4 17.30] Desy Khofifah: Hal.466 Ada bagan di bawah

entity whose economic value will be either reduced or increased by the event. Support events are
also

related to resources but do not effect a change in the resource value.

One could make the theoretical argument that all employee actions, including support events
such as

Verify Availability or Take Order, consume a resource called Employee Service. In fact, this
resource is

increased as employees render their services to the organization and is simultaneously decreased
as those

services are employed in the performance of a task. In situations in which employee services are
tracked

to specific projects or products, this entity would provide meaningful data and should be
included in the

REA model. Because we can presume that this is not the case for Apex Supply, Employee
Services will

not be modeled.

In the Apex revenue cycle, economic events change only two resources. The Ship Product event

reduces the inventory resource and the Receive Cash event increases the cash resource. The
Verify Availability and the Take Order support events are also associated with inventory, but they
do not change it.

The resource and associated event entities are presented in Figure 10-6.

Step 3. Identify the Agent Entities

Each economic event entity in an REA diagram is associated with at least two agent entities. One
of these
is an internal agent and the other is an external agent. The external agent associated with all four
events in

the Apex case is Customer. In addition, four internal agents are associated with the four events:

1. The customer services clerk, who participates in the Verify Availability event.

2. The sales representative, who participates in the Take Order event.

[11/4 17.31] Desy Khofifah: entitas yang nilai ekonominya akan dikurangi atau ditingkatkan oleh
acara tersebut. Acara dukungan juga

terkait dengan sumber daya tetapi tidak mempengaruhi perubahan nilai sumber daya.

Seseorang dapat membuat argumen teoretis bahwa semua tindakan karyawan, termasuk peristiwa
pendukung seperti

Verifikasi Ketersediaan atau Ambil Pesanan, konsumsi sumber daya yang disebut Layanan
Karyawan. Sebenarnya, sumber daya ini

meningkat saat karyawan memberikan layanan mereka kepada organisasi dan secara bersamaan
menurun seperti itu

layanan digunakan dalam pelaksanaan tugas. Dalam situasi di mana layanan karyawan dilacak

untuk proyek atau produk tertentu, entitas ini akan memberikan data yang bermakna dan harus
dimasukkan ke dalam

Model REA. Karena kita dapat menganggap bahwa ini bukan kasus untuk Pasokan Apex,
Layanan Karyawan akan

tidak dimodelkan.

Dalam siklus pendapatan Apex, peristiwa ekonomi hanya mengubah dua sumber daya. Acara
Produk Kapal

mengurangi sumber daya persediaan dan acara Penerimaan Kas meningkatkan sumber daya kas.
Kemampuan Verify Avail ??? dan peristiwa dukungan Take Order juga terkait dengan inventaris,
tetapi tidak mengubahnya.

Sumber daya dan entitas kejadian terkait disajikan pada Gambar 10-6.

Langkah 3. Identifikasi Entitas Agen

Setiap entitas peristiwa ekonomi dalam diagram REA dikaitkan dengan setidaknya dua entitas
agen. Salah satu dari ini

adalah agen internal dan yang lainnya adalah agen eksternal. Agen eksternal yang terkait dengan
semua empat peristiwa di

Kasus Apex adalah Pelanggan. Selain itu, empat agen internal terkait dengan empat peristiwa:

1. Petugas layanan pelanggan, yang berpartisipasi dalam acara Verify Availability.

2. Perwakilan penjualan, yang berpartisipasi dalam acara Take Order.

[11/4 17.31] Desy Khofifah: Hal.467 di bawah ada bagan

3. The shipping clerk, who participates in the Ship Product event.

4. The cash receipts clerk, who participates in the Receive Cash event.

Note that each of these internal agents is in fact an instance of the Employee entity type. For
illustration

purposes on the REA diagram, we identify each instance of Employee (for example, Sales
Representative

or Shipping Clerk) as a separate entity. The database that ultimately emerges from this model,
however,

will employ a single Employee table, and each instance shown in the model will be a row in that
table.

Figure 10-6 illustrates the relationship between the events and associated external and internal
agents in

the Apex case.

Step 4. Determine Associations and Cardinalities between Entities

We discussed in detail in Chapter 9 the topics of entity association and cardinality. This section
assumes

familiarity with these topics, which are only briefly reviewed.

Association is the nature of the relationship between two entities, as the labeled line connecting
them

represents. Cardinality (the degree of association between the entities) describes the number of
possible

occurrences in one entity that are associated with a single occurrence in a related entity. Four
basic forms

of cardinality are possible: zero or one (0,1), one and only one (1,1), zero or many (0,M), and
one or

many (1,M).
[11/4 17.32] Desy Khofifah: 3. Petugas pengiriman, yang berpartisipasi dalam acara Produk
Kapal.

4. Petugas penerimaan kas, yang berpartisipasi dalam acara Terima Kas.

Perhatikan bahwa masing-masing agen internal ini sebenarnya merupakan instance dari tipe
entitas Karyawan. Untuk ilustrasi

tujuan pada diagram REA, kami mengidentifikasi setiap contoh Karyawan (misalnya, Perwakilan
Penjualan
atau Petugas Pengiriman) sebagai entitas terpisah. Database yang pada akhirnya muncul dari
model ini, bagaimanapun,

akan menggunakan tabel Karyawan tunggal, dan setiap contoh yang ditampilkan dalam model
akan menjadi baris dalam tabel itu.

Gambar 10-6 mengilustrasikan hubungan antara kejadian dan agen eksternal dan internal yang
terkait di

kasus Apex.

Langkah 4. Tentukan Asosiasi dan Kardinalitas antar Entitas

Kami membahas secara rinci dalam Bab 9 topik asosiasi entitas dan kardinalitas. Bagian ini
mengasumsikan

keakraban dengan topik-topik ini, yang hanya sebentar ditinjau.

Asosiasi adalah sifat hubungan antara dua entitas, sebagai garis berlabel yang menghubungkan
mereka mewakili. Kardinalitas (tingkat hubungan antar entitas) menjelaskan jumlah
kemungkinan kejadian dalam satu entitas yang terkait dengan satu kejadian dalam entitas terkait.
Empat bentuk dasar kardinalitas mungkin: nol atau satu (0,1), satu dan hanya satu (1,1), nol atau
banyak (0, M), dan satu atau banyak (1, M).

[11/4 17.55] Desy Khofifah: gambar 10-7 menyajikan tiga metode alternatif untuk menyajikan
kardinalitas dalam rea diagram. mengubah asli 1 menyajikan Gagak kaki notasi metode dibahas
dalam Bab 9. contoh menggambarkan bahwa satu kejadian (catatan) di entitas yang berhubungan
dengan nol atau banyak kejadian di entitas B. dengan demikian, terendah kardinalitas adalah nol
dan tertinggi adalah banyak. melihat di arah lain, notasi menyatakan bahwa satu kejadian di
entitas B dikaitkan dengan satu dan hanya satu kejadian di entitas A. kadang-kadang lebih rendah
dan atas kardinalitas yang secara eksplisit tertulis pada Asosiasi garis antara entitas, seperti yang
ditunjukkan di alternatif 2 dalam gambar. sebuah istilah versi ini disajikan sebagai alternatif 3,
yang menunjukkan hanya atas kardinalitas dan menganggap rendah kardinalitas menjadi nol. atas
kardinalitas untuk setiap entitas menentukan secara keseluruhan Asosiasi. sebagai contoh, entitas
pada gambar 10-7 dikatakan memiliki 1: M Asosiasi. lain mungkin Asosiasi 1: 1 dan M: M.
gambar 10-8 menyajikan direvisi model data untuk APEX. perhatikan bahwa itu telah
disederhanakan untuk membaca baik kemampuan dengan menghilangkan berlebihan contoh dari
pelanggan dan persediaan entitas yang digambarkan pada gambar 10-6. Selain itu, gambar 10-8
menunjukkan Asosiasi dan kardinalitas antara entitas menggunakan Gagak kaki notasi metode.
kardinalitas mencerminkan aturan bisnis yang bermain untuk tertentu orga nization. kadang-
kadang aturannya jelas dan yang sama untuk semua organisasi. sebagai contoh, atau mal
kardinalitas antara pelanggan dan mengambil pesanan entitas 1,1 dan 0, M. ini berarti bahwa
tertentu pelanggan mungkin harus ditempatkan nol atau banyak pesanan selama penjualan
periode dan bahwa setiap order untuk hanya satu pelanggan. Asosiasi antara entitas adalah 1: M
dan tidak akan pernah menjadi 1: 1 karena hal ini berarti bahwa organisasi membatasi setiap
pelanggan ke batas hanya satu urutan, yang tidak masuk akal. Asosiasi antara internal agen dan
acara entitas berikut ini pola yang sama. sebuah orga nization harapkan karyawannya untuk
berpartisipasi dalam banyak peristiwa dari waktu ke waktu, bukan hanya satu. sebagian besar
kardinalitas pada gambar 10-8 mencerminkan aturan yang cukup jelas. beberapa poin yang perlu
lebih lanjut expla bangsa disajikan berikutnya. kardinalitas antara memeriksa ketersediaan dan
mengambil pesanan entitas. masing-masing terjadinya verifikasi ketersediaan entitas adalah hasil
dari seorang pelanggan kirim. kita tahu dari kasus deskripsi, Bagaimanapun, bahwa tidak semua
pertanyaan menghasilkan pesanan pelanggan. di sisi lain, kita akan membuat menyederhanakan
asumsi bahwa masing-masing mengambil pesanan terjadinya adalah hasil dari penyelidikan.
yang Cardi nality pada mengambil pesanan sisi hubungan, oleh karena itu, adalah 0,1. pada
memverifikasi ketersediaan sisi, itu adalah 1,1
[11/4 17.56] Desy Khofifah: 479
CARDINALITY BETWEEN THE TAKE ORDER AND SHIP PRODUCT ENTITIES. The 0,1

cardinality on the Ship Product side of the relation reflects the timing difference between orders
taken

and shipped. Because sales are not processed instantly, we can assume that an order will exist
(occurrence

of Take Order) that has not yet been shipped (no occurrence of Ship Product). Furthermore, an
order that

is canceled before being shipped would also result in no Ship Product record being created.

CARDINALITY BETWEEN THE SHIP PRODUCT AND RECEIVE CASH ENTITIES.

Business

terms of trade and payment policies vary greatly. Companies that make credit sales to consumers
often

accept partial payments over time. This would result in many cash receipts occurrences for a
single shipment occurrence. On the other hand, companies whose customers are other businesses
typically expect

payment in full when due. Business customers, however, may consolidate several invoices on a
single

cash payment to reduce check writing. Because the Apex company is a wholesaler that serves
business

customers, we will assume that debts are paid in full (no multiple partial payments) and that
Apex customers may pay for multiple shipments with a single cash receipt. The cardinality in
Figure 10-8 reflects

this business rule.

CARDINALITY BETWEEN THE CASH AND RECEIVE CASH ENTITIES. The cash
resource of

an organization is composed of several different accounts, such as the general operating account,
payroll
[11/4 17.56] Desy Khofifah: kardinalitas antara mengambil pesanan dan kapal produk entitas.
para 0,1 kardinalitas pada kapal produk sisi hubungan mencerminkan waktu perbedaan antara
pesanan diambil dan dikirimkan. karena penjualan tidak diproses langsung, kita bisa berasumsi
bahwa perintah akan ada (terjadinya mengambil pesanan) yang belum dikirim (tidak ada
terjadinya kapal produk). Selain itu, perintah yang dibatalkan sebelum dikirim juga akan
mengakibatkan tidak ada kapal produk catatan diciptakan. kardinalitas antara kapal produk dan
menerima uang tunai entitas. bisnis hal perdagangan dan pembayaran kebijakan sangat
bervariasi. perusahaan yang membuat penjualan kredit kepada konsumen sering menerima
sebagian pembayaran dari waktu ke waktu. ini akan mengakibatkan banyak penerimaan kas
kemunculan untuk satu kapal ment terjadinya. di sisi lain, perusahaan yang pelanggan bisnis lain
biasanya mengharapkan pembayaran penuh saat jatuh TEMPO. pelanggan bisnis, Namun,
mungkin mengkonsolidasikan beberapa faktur pada satu pembayaran tunai untuk mengurangi
periksa menulis. karena APEX perusahaan grosir yang melayani pelanggan bisnis, kami akan
berasumsi bahwa utang dibayar penuh (tidak ada beberapa parsial pembayaran) dan yang APEX
cus tomers mungkin membayar untuk beberapa pengiriman dengan satu penerimaan kas. yang
kardinalitas pada gambar 10-8 mencerminkan bisnis ini aturan. kardinalitas antara kas dan
menerima uang tunai entitas. kas sumber daya dari sebuah organisasi terdiri dari beberapa
account yang berbeda, seperti operasi Umum akun, penggajian
[11/4 17.57] Desy Khofifah: imprest account, petty cash, and so on. These are consolidated for
financial reporting into a single

account, but are used and tracked separately. The cardinality depicted in this relationship implies
that cash

is received from many customers and is deposited into one account.

MANY-TO-MANY ASSOCIATIONS. The model in Figure 10-8 depicts three examples of M:M

associations. The first of these is between the Verify Availability and Inventory entities. A 1,M
cardinality exists at the Inventory end of the association and a 0,M cardinality lies at the Verify
Availability

end. This suggests that a particular customer query could involve one or many items of
inventory, and

each item may have been queried zero or many times in the period. The second M:M association
exists

between the Take Order and Inventory entities. A 1,M cardinality exists at the Inventory end of
the

association and a 0,M cardinality is at the Take Order end. This means that a particular order may
contain one or many different items of inventory and that a particular item may have never been
ordered

(perhaps a new product) or may have been ordered many times during the period. A similar
situation

exists between the Ship Goods and Inventory entities. In each of these cases the upper
cardinalities of

M creates an M:M association, which we know from Chapter 9 must be reconciled. These
situations

are the result of repeating group data that need to be normalized before implementing the model
in a

relational database.2 The solution is to create three link tables that contain the primary keys of
the associated tables. The link tables will also contain details pertaining to items queried, the
orders taken, and

the products shipped.

When modeling traditional ER diagrams, it is often convenient to include the link tables in the
model
(as in Chapter 9) so that it reflects closely the actual database. The inclusion of link tables in an
REA diagram, however, creates a conflict with the rule that an event entity should be connected
to at least one

resource and at least two agent entities. Figure 10-9 shows how a portion of the Apex REA
diagram

would appear when link tables are inserted. Although link tables are a technical requirement for
implementing an M:M association in a relational database, they are not a technical requirement
for modeling

the database. Including the link table in an REA diagram disrupts its visual integrity and adds
little to

one’s understanding of the conceptual model. Ultimately, during implementation, the database
designer

will create the link tables. Indeed, the database cannot function without them. For REA
diagramming purposes, however, the link tables need only be implied via the M:M associations.

View Integration: Creating an Enterprise-Wide

REA Model

The view modeling process described in the previous section produced an individual REA model
of the

revenue cycle for Apex Supply. This section explains how multiple REA diagrams, each created
in its

own view modeling process, are integrated into a single global or enterprise model. The section
then

explains how the enterprise model is implemented into a relational database and user views
constructed.

The view integration process involves three basic steps:

1. Consolidate the individual models.

2. Define the primary keys, foreign keys, and attributes.

3. Construct the physical database and produce user views.

STEP 1. CONSOLIDATE THE INDIVIDUAL MODELS

Because Apex is a wholesale supply company with no production facilities, model consolidation
for them

will include the previously developed revenue cycle model (Figure 10-8) and the expenditure
cycle
models for purchases/cash disbursements and payroll illustrated in Figures 10-10 and 10-11,
respectively.
[11/4 17.58] Desy Khofifah: uang muka akun, kas kecil, dan sebagainya. ini adalah laporan
laporan keuangan menjadi satu akun, tetapi digunakan dan dilacak secara terpisah. yang
kardinalitas digambarkan dalam hubungan ini menyiratkan bahwa uang tunai yang diterima dari
banyak pelanggan dan disimpan ke dalam satu akun. banyak-to-banyak Asosiasi. model pada
gambar 10-8 menggambarkan tiga contoh M: M Asosiasi. pertama ini adalah antara memeriksa
ketersediaan dan persediaan entitas. 1, M Cardi nality ada di persediaan akhir Asosiasi dan 0, M
kardinalitas terletak di memverifikasi ketersediaan akhir. ini menunjukkan bahwa tertentu
pelanggan query bisa melibatkan satu atau banyak item persediaan, dan setiap item mungkin
telah dipertanyakan nol atau berkali-kali pada periode. kedua M: M Asosiasi ada antara
mengambil pesanan dan persediaan entitas. 1, M kardinalitas ada di persediaan akhir Asosiasi
dan 0, M kardinalitas adalah di mengambil pesanan akhir. ini berarti bahwa urutan tertentu
mungkin Con Tain satu atau banyak item yang berbeda dari persediaan dan bahwa tertentu item
mungkin belum pernah memerintahkan (mungkin produk baru) atau mungkin telah
memerintahkan berkali-kali selama periode. situasi yang sama ada antara kapal barang dan
persediaan Badan. di masing-masing kasus atas kardinalitas dari M menciptakan M: M Asosiasi,
yang kita tahu dari Bab 9 harus didamaikan. situasi seperti ini adalah hasil dari mengulangi
kelompok data yang perlu dinormalisasi sebelum menerapkan model relasional database.2 solusi
adalah untuk membuat tiga link tabel yang berisi kunci Primer dari Asso ciated tabel. link tabel
juga akan berisi rincian berkaitan dengan item dipertanyakan, perintah diambil, dan produk yang
dikirim. ketika pemodelan tradisional er diagram, hal ini sering nyaman untuk menyertakan link
tabel dalam model (seperti dalam Bab 9) sehingga mencerminkan erat database sebenarnya.
dimasukkannya link tabel dalam rea dia gram, Bagaimanapun, menciptakan konflik dengan
aturan bahwa acara entitas harus terhubung dengan setidaknya satu sumber daya dan setidaknya
dua agen entitas. gambar 10-9 menunjukkan bagaimana sebagian dari puncak rea diagram akan
muncul ketika link tabel dimasukkan. Meskipun link tabel adalah persyaratan teknis untuk imple
menting sebuah M: M Asosiasi di database relasional, mereka tidak teknis persyaratan untuk
pemodelan database. termasuk link tabel dalam rea diagram mengganggu dengan visual
integritas dan menambahkan sedikit atau seseorang pemahaman tentang model konseptual.
akhirnya, selama pelaksanaan, database desainer akan membuat link tabel. memang, database tdk
bisa berfungsi tanpa mereka. untuk rea diagram pur pose, Namun, link tabel hanya perlu akan
tersirat melalui M: M Asosiasi. lihat integrasi: menciptakan suatu perusahaan di seluruh rea
model pandangan pemodelan proses yang Dijelaskan dalam bagian sebelumnya menghasilkan
individu rea model dari siklus pendapatan untuk APEX pasokan. bagian ini menjelaskan
bagaimana beberapa rea diagram, masing-masing dibuat dalam sendiri lihat pemodelan proses,
diintegrasikan ke dalam satu global atau model perusahaan. bagian kemudian menjelaskan
bagaimana model perusahaan diimplementasikan ke database relasional dan user views
dibangun. pandangan integrasi proses melibatkan tiga langkah dasar: 1. mengkonsolidasikan
individu model. 2. menentukan kunci Primer, kunci asing, dan atribut. 3. membangun fisik
database dan menghasilkan pengguna tampilan. langkah 1. mengkonsolidasikan individu model
karena APEX adalah grosir pasokan perusahaan dengan tidak ada fasilitas produksi, model
konsolidasi untuk mereka akan mencakup sebelumnya dikembangkan siklus pendapatan model
(gambar 10-8) dan pengeluaran siklus model untuk pembelian / pengeluaran kas dan penggajian
diilustrasikan dalam angka 10-10 dan 10-11, masing-masing.
[11/4 17.58] Desy Khofifah: 475.

A brief explanation of the resources, events, agents, and cardinalities for two expenditure cycle
models is

provided next.

Purchases and Cash Disbursement Procedures

Figure 10-10 shows three event entities in Apex’s purchases and cash disbursement system. The
first of

these, the Order Product entity, is a support event that does not directly increase the Inventory
(resource)

entity. Upon recognizing the need for inventory, which sales to customers (revenue cycle)
depleted, the

purchasing clerk (internal agent) selects a supplier (external agent) and places the order. This act
does not

constitute an economic event, but is a commitment to buy. The link from the event entity to the
Inventory

entity indicates that the records will be adjusted to show that the items in question are on order.
The quantity on hand, however, will not be increased at this time. The on-order information will
prevent items

from being accidentally reordered and will assist customer service clerks in advising customers
as to the

status of inventory and expected due dates for out-of-stock items. The 1:M association between
Supplier

and Order Product indicates that each order goes to only one supplier and that a particular
supplier may

have received zero or many orders during the period.

The second event entity is Receive Product, which is an economic event that causes a change in
an

economic resource. This is the receive half of the exchange and increases inventory. Goods are
received

from the supplier and the receiving clerk processes them. This involves counting, inspecting,
transporting

the products into the warehouse, transferring title to Apex, and updating the inventory records.
The 0,1

cardinality in the association between the Order Product and Receive Product entities implies
that at any

point in time, an order may exist (occurrence of Order Product) that has not yet been received
(no occurrence of Receive Product).
[11/4 17.59] Desy Khofifah: penjelasan singkat dari sumber daya, acara, agen, dan kardinalitas
selama dua pengeluaran siklus model disediakan berikutnya. pembelian dan kas pencairan
prosedur gambar 10-10 menunjukkan tiga acara entitas di APEX pembelian dan kas pencairan
sistem. pertama ini, urutan produk entitas, adalah mendukung acara yang tidak langsung
meningkatkan persediaan (sumber) entitas. setelah menyadari kebutuhan untuk persediaan, yang
penjualan kepada pelanggan (siklus pendapatan) habis, beli petugas (internal agen) memilih
pemasok (External agen) dan tempat urutan. Undang-Undang ini tidak merupakan ekonomi
acara, tetapi adalah komitmen untuk membeli. link dari acara entitas untuk persediaan entitas
menunjukkan bahwa catatan akan disesuaikan untuk menunjukkan bahwa item tersebut berada di
urutan. Quan tity di tangan, Bagaimanapun, tidak akan meningkat saat ini. on-informasi
pemesanan akan mencegah item agar tidak sengaja mengatur kembali dan akan membantu
layanan pelanggan pegawai di menasihati pelanggan untuk status persediaan dan diharapkan
tanggal jatuh TEMPO untuk out-of-persediaan item ada. 1: M hubungan antara pemasok dan
memesan produk menunjukkan bahwa setiap pesanan pergi untuk hanya satu pemasok dan
bahwa tertentu pemasok mungkin telah menerima nol atau banyak pesanan selama periode. acara
kedua entitas menerima produk, yang merupakan ekonomi acara yang menyebabkan perubahan
ekonomi sumber daya. ini adalah menerima setengah dari pertukaran dan meningkatkan
persediaan. barang diterima dari pemasok dan penerima petugas proses mereka. ini melibatkan
menghitung, memeriksa, pengiriman produk ke gudang, mentransfer judul untuk APEX, dan
memperbarui persediaan catatan. para 0,1 kardinalitas dalam hubungan antara pesanan produk
dan menerima produk entitas menyiratkan bahwa setiap titik pada waktunya, perintah mungkin
ada (terjadinya agar produk) yang belum diterima (tidak ada terjadi rence dari menerima
produk).
[11/4 18.00] Desy Khofifah: ketiga acara diwakili dalam diagram menyalurkan kas. ini adalah
ekonomi acara yang merupakan memberikan setengah dari ekonomi Exchange. dalam hal ini,
menyebabkan kas sumber daya yang akan menurun. 1: M Asosiasi dengan pemasok entitas
menyiratkan bahwa setiap pembayaran dilakukan untuk hanya satu pemasok, tapi setiap pemasok
mungkin menerima nol atau banyak pengeluaran selama periode. 1: M hubungan antara dis burse
kas dan menerima produk menyiratkan bahwa setiap produk penerimaan dibayar penuh (tidak
ada beberapa parsial membayar ments), tetapi banyak penerimaan dapat dikombinasikan dan
dibayar dengan satu pencairan untuk mengurangi periksa menulis. melihat bahwa M: M Asosiasi
ada antara agar produk dan persediaan entitas dan antara menerima produk dan persediaan
entitas. ini menggambarkan bahwa perintah diletakkan dengan pemasok dan diterima dari
mereka mungkin berisi satu atau banyak item. dari sisi berlawanan, ini Asosiasi menandakan
bahwa setiap item persediaan mungkin telah memerintahkan dan menerima nol atau berkali-kali
pada periode. seperti yang Dijelaskan sebelumnya, masing-masing M: M Asosiasi perlu
diselesaikan dengan menambahkan menghubungkan entitas. tabel untuk menghubungkan entitas
pada akhirnya akan dibuat dalam database, tapi entitas tidak akan termasuk dalam rea dia gram.
ingat juga bahwa internal agen diwakili dalam rea diagram sebagai entitas yang terpisah. hal ini
dilakukan untuk menggambarkan lebih jelas masing-masing peran. pada kenyataannya, agen ini
adalah contoh dari karyawan entitas dan akan jatuh ke dalam satu karyawan tabel di akhir
database. penggajian prosedur rea diagram pada gambar 10-11 menjelaskan model data untuk
APEX supply penggajian prosedur. model terdiri dari hanya dua peristiwa ekonomi:
mendapatkan waktu dan menyalurkan kas. Get waktu acara adalah menerima setengah dari
ekonomi Exchange. ini melibatkan pekerja (internal agen) menyerah waktunya, yang diwakili
oleh karyawan layanan sumber daya. Supervisor (eksternal agen) mengasumsikan kontrol
sumber daya. tidak seperti nyata sumber daya ekonomi kas dan persediaan, waktu tidak memiliki
saham aliran elemen dan tdk bisa disimpan. Get waktu acara meningkatkan waktu, dan berbagai
tugas kinerja peristiwa sekaligus mengurangi waktu. di awal Bab, karyawan layanan sumber
daya dibahas sebagai kemungkinan sumber daya untuk menjadi model di APEX pasokan
database. dalam situasi di mana karyawan layanan langsung dilacak untuk produk yang
diproduksi atau jasa yang diberikan untuk bisnis (yaitu, konsultasi, pelayanan hukum, atau
akuntan publik), masuk akal untuk model ini sumber daya. karena APEX tidak melacak
karyawan waktu untuk kegiatan tersebut sebagai nasabah individu disajikan atau perintah
diambil, mengubah entitas ini menjadi fisik basis data tabel melayani tidak ada tujuan. untuk
menjaga konsistensi dengan rea pemodelan konvensi bahwa setiap acara harus dikaitkan dengan
sumber daya, Bagaimanapun, karyawan layanan termasuk dalam gambar 10-11 sebagai
bayangan sumber daya (garis putus-putus) saja. itu tidak akan tidak dimodelkan di akhir
perusahaan di seluruh rea diagram. Get waktu acara menangkap sehari-hari waktu memberikan
contoh karyawan melalui ketepatan waktu mekanisme seperti elektronik waktu jam. untuk gaji
karyawan, waktu-menangkap proses mungkin SIM ply melibatkan berlalunya waktu. nol
kardinalitas dalam Asosiasi antara mendapatkan waktu dan pekerja dan Supervisor entitas
mencerminkan kemungkinan bahwa beberapa karyawan mungkin tidak memiliki kontribusi
waktu selama periode. ini akan mencakup, misalnya, karyawan baru atau karyawan pada cuti
sakit. yang menyalurkan kas acara adalah memberikan setengah dari ekonomi Exchange. ini
melibatkan mendistribusikan kas untuk seorang karyawan (sekarang eksternal agen) untuk
layanan yang diberikan. penggajian petugas (internal agen) berpartisipasi dalam acara ini, yang
mengurangi kas sumber daya. Asosiasi antara menyalurkan kas dan mendapatkan waktu
peristiwa mencerminkan beda waktu antara karyawan menyerah waktu mereka dan menerima
pembayaran untuk itu, karena mereka biasanya tidak dibayar setiap hari. biasanya, karyawan
bekerja selama seminggu, dua Minggu, atau Bahkan sebulan sebelum dibayar. oleh karena itu, 1,
M kardinalitas pada mendapatkan waktu sisi Asosiasi menyiratkan bahwa setidaknya satu dan
mungkin banyak contoh mendapatkan waktu akan ada untuk setiap contoh menyalurkan kas.
para 0,1 kardinalitas pada menyalurkan kas sisi Asosiasi menyiratkan bahwa pada suatu titik
waktu (pertengahan Minggu), Get waktu contoh akan ada yang belum dibayar. masing-masing
mendapatkan waktu contoh, Namun, dibayar hanya sekali. menggabungkan individu rea diagram
dengan individu rea diagram dibuat dan menjelaskan, kita sekarang siap untuk mengkonsolidasi
mereka ke dalam satu perusahaan di seluruh diagram (lihat gambar 10-12). dengan membalik
pengeluaran siklus diagram untuk membuat cermin efek, Umum sumber daya persediaan dan
uang tunai yang berpusat di diagram. ini adalah diapit oleh dua rasi bintang dari peristiwa, yang
meningkatkan dan penurunan mereka. agen bentuk pinggiran konstelasi dalam diagram.
[11/4 18.01] Desy Khofifah: To simplify the diagram, redundant event, agent, and resource
entities have been collapsed into a single entity where possible. For example, the Disburse Cash
event, which is an element of both the Payroll

and Purchase/Cash Disbursement procedures for Apex Supply is represented only once in the
consolidated model. Also, the Cash and Inventory entities are present only once on the
consolidated diagram. To

maintain perspective as to the roles played by internal agents, they are depicted as individual
entities

rather than collectively as Employee. Finally, to avoid crossing association lines between
entities, the

Supplier and Customer agents appear more than once in the diagram.

STEP 2. DEFINE PRIMARY KEYS, FOREIGN KEYS, AND ATTRIBUTES

With the data model constructed, we are now ready to design the relational database tables. This
involves

determining primary keys, assigning foreign keys, and defining the attributes of the tables. A
separate table will be constructed for each valid entity in the REA integrated diagram in Figure
10-12. This will

require 18 tables, which are explained in the following paragraphs:

The ten internal agents represented in Figure 10-12 will be collapsed into a single Employee
table.

The two external agents (Customer and Supplier) will each require a separate table.

The two resources Inventory and Cash will each be a table.

The eight events will require a table each.

The five M:M relations represented in the diagram will each require a linking table.

RULES FOR PRIMARY KEYS AND ATTRIBUTES. Table 10-1 presents the 18 tables in
Apex’s

database along with their primary keys, foreign keys, and attributes. The determination of
primary keys

and attributes comes from an understanding of each table’s purpose, which results from a
detailed analysis of user needs. The database designer should select a primary key that logically
and uniquely defines

the nonkey attributes in the table. In some cases, this is accomplished with a simple sequential
code such

as an Invoice Number, Check Number, or Purchase Order number. In other situations, block
codes, group

codes, alphabetic codes, and mnemonic codes are better choices. We discussed the advantages
and disadvantages of various coding techniques in detail in Chapter 2.

Some table attributes are common to all organizations and can be derived from common sense
and adherence to best practices. Other attributes are unique to specific applications and can be
derived only from

thorough and detailed analyses of individual user views. Each attribute assigned to a table
should, however, appear directly or indirectly (a calculated value) in one or more user views. If
data stored in a table

are not used in a document, report, or a calculation that is reported in some way, then it serves no
purpose

and should not be part of the database.

RULES FOR FOREIGN KEYS. The degree of association between tables (that is, 1:1, 1:M, or
M:M)

determines how foreign keys are assigned. We discussed the key-assignment rules for linking
tables in

Chapter 9, and they are briefly reviewed in this section.

KEYS IN 1:1 ASSOCIATIONS. In 1:1 associations, one side of the association will typically
have a

minimum cardinality of zero. When this is the case, the primary key of the table with the 1,1
cardinality

should be embedded as a foreign key in the table with the 0,1 cardinality. Reversing this rule will
create a
table structure in which the 1,1 cardinality table contains instances of foreign keys with a null
(blank)

value. Although such a link will work, it is a poor table design that can lead to inefficiencies and
possible

processing errors. By following the rule, however, all foreign key values in the table on the 0,1
cardinality

side of the association will be non-null. For example, we can see from Table 10-1 that the
primary key

for the Verify Availability table (Inquiry Number) is assigned as a foreign key to the Take Order
table.

KEYS IN 1:M ASSOCIATIONS. Where a 1:M association exists between tables, the primary
key of

the 1 side is embedded in the table of the M side. For example, the primary key of the Employee
table

(Employee Number) has been assigned as a foreign key to the Verify Availability, Take Order,
and Ship

Product tables.

CHA
[11/4 18.03] Desy Khofifah: untuk menyederhanakan diagram, berlebihan acara, agen, dan
sumber daya entitas telah runtuh ke dalam dosa Gle entitas jika mungkin. sebagai contoh,
menyalurkan kas acara, yang merupakan unsur kedua penggajian dan pembelian / kas pencairan
prosedur untuk APEX pasokan diwakili hanya sekali dalam consoli tanggal model. Selain itu,
kas dan persediaan entitas yang hadir hanya sekali pada laporan diagram. untuk mempertahankan
perspektif untuk peran yang dimainkan oleh internal agen, mereka digambarkan sebagai individu
entitas dan bukan secara kolektif sebagai karyawan. akhirnya, untuk menghindari crossing
Asosiasi garis antara entitas, pemasok dan pelanggan agen muncul lebih dari sekali dalam
diagram. langkah 2. menentukan kunci Primer, kunci asing, dan atribut dengan model data
dibangun, kita sekarang siap desain database relasional tabel. ini melibatkan menentukan kunci
Primer, menetapkan kunci asing, dan mendefinisikan atribut dari tabel. terpisah TA Ble akan
dibangun untuk setiap hari entitas dalam rea terintegrasi diagram pada gambar 10-12. ini akan
memerlukan 18 tabel, yang Dijelaskan dalam paragraf berikut: sepuluh internal agen diwakili
dalam gambar 10-12 akan runtuh ke satu karyawan tabel. dua agen eksternal (pelanggan dan
pemasok) masing-masing akan memerlukan tabel terpisah. dua sumber daya persediaan dan kas
masing-masing akan menjadi tabel. delapan acara akan memerlukan tabel masing-masing. lima
M: M hubungan diwakili dalam diagram masing-masing akan memerlukan menghubungkan
tabel. aturan untuk kunci Primer dan atribut. tabel 10-1 menyajikan 18 tabel di APEX database
beserta kunci Primer, kunci asing, dan atribut. penentuan kunci Primer dan atribut berasal dari
pemahaman tentang setiap tabel tujuan yang disebabkan rinci analy SIS dari kebutuhan
pengguna. database desainer harus pilih kunci Primer yang logis dan unik mendefinisikan
nonkey atribut di meja. dalam beberapa kasus, hal ini dicapai dengan sederhana berurutan kode
seperti nomor faktur, periksa nomor, atau nomor pesanan pembelian. dalam situasi lain, Blok
kode, kelompok kode, alfabetis kode, dan mnemonic kode adalah pilihan yang lebih baik. kita
Bahas keuntungan dan disad vantages berbagai coding teknik secara rinci dalam Bab 2. beberapa
tabel atribut Umum untuk semua organisasi dan dapat berasal dari akal sehat dan iklan herence
untuk praktik terbaik. atribut lainnya yang unik untuk aplikasi spesifik dan dapat berasal hanya
dari menyeluruh dan rinci analisis pengguna individu tampilan. setiap atribut ditugaskan ke meja
harus, bagaimana pernah, muncul secara langsung maupun tidak langsung (dihitung nilai) dalam
satu atau lebih user tampilan. jika data yang tersimpan dalam tabel tidak digunakan dalam
dokumen, laporan, atau perhitungan yang dilaporkan dalam beberapa cara, maka menjabat tidak
ada tujuan dan tidak harus menjadi bagian dari database. aturan untuk kunci asing. tingkat
hubungan antara tabel (yaitu, 1: 1, 1: M, atau M: M) menentukan bagaimana kunci asing
ditugaskan. kita Bahas kunci-tugas aturan untuk menghubungkan tabel di Bab 9, dan mereka
secara singkat diulas di bagian ini. kunci 1: 1 Asosiasi. di 1: 1 Asosiasi, satu sisi dari Asosiasi
biasanya akan memiliki minimal kardinalitas nol. ketika hal ini terjadi, kunci Primer dari meja
dengan 1,1 kardinalitas harus dimasukkan sebagai kunci asing di meja dengan 0,1 kardinalitas.
membalikkan aturan ini akan membuat struktur tabel di mana 1,1 kardinalitas tabel berisi contoh
kunci asing dengan nol (kosong) nilai. Meskipun demikian link akan bekerja, ini adalah miskin
tabel desain yang dapat menyebabkan inefisiensi dan mungkin pengolahan kesalahan. dengan
mengikuti aturan, Namun, semua asing nilai kunci di meja di 0,1 kardinalitas sisi Asosiasi akan
non-null. sebagai contoh, kita dapat melihat dari tabel 10-1 bahwa kunci utama untuk memeriksa
ketersediaan tabel (kirim jumlah) ditugaskan sebagai kunci asing untuk mengambil pesanan
tabel. kunci 1: M Asosiasi. mana 1: M Asosiasi ada antara tabel, kunci Primer dari 1 sisi tertanam
dalam tabel dari M sisi. sebagai contoh, kunci utama dari karyawan tabel (karyawan jumlah)
telah ditetapkan sebagai kunci asing untuk verifikasi ketersediaan, mengambil pesanan, dan
kapal produk tabel.
kunci di M: M Asosiasi. tabel dalam M: M Asosiasi tdk bisa menerima tertanam kunci asing dari
terkait tabel. sebaliknya, database desainer harus membuat terpisah link tabel mengandung kunci
asing. dengan memasukkan link tabel antara asli tabel, yang M: M Asosiasi berubah menjadi dua
1: M Asosiasi (lihat gambar 10-9). link tabel sekarang dapat menerima kunci Primer dari tabel
pada 1 sisi kedua baru Asosiasi. proses ini menghasilkan gabungan (komposit) kunci yang
berfungsi sebagai kunci utama untuk mendefinisikan atribut (jika ada) pada link di meja. masing-
masing komponen komposit kunci juga berfungsi sebagai kunci asing untuk menemukan terkait
catatan di terkait tabel. lima link tabel dinyatakan dalam tabel 10-1: persediaan memverifikasi
link, inventaris-order link, persediaan-kapal link, ord-Prod-inven link, dan RE-Prod-inven link.
dinormalisasi tabel. penugasan kunci Primer dan atribut untuk relasional tabel harus selalu
mematuhi aturan Normalisasi dibahas dalam Bab 9. ingat bahwa tidak benar dinormalisasi tabel
menunjukkan negatif operasional gejala disebut anomali, termasuk pembaruan anomali, yang
inser tion anomali, dan penghapusan anomali. satu atau lebih dari ini anomali akan ada di meja
yang tidak normal untuk ketiga bentuk normal (3nf) tingkat. ini anomali yang disebabkan oleh
masalah struktural dalam tabel dikenal sebagai mengulangi grup besar, sebagian dependensi, dan
transitif dependensi. normaliza tion melibatkan sistematis mengidentifikasi dan menghapus ini
dependensi dari tabel (S) di bawah ulasan. tabel di 3nf akan bebas dari anomali dan akan
bertemu dua kondisi: 1. semua nonkey atribut akan sepenuhnya dan unik tergantung pada
(didefinisikan oleh) kunci Primer. 2. tak satu pun dari nonkey atribut akan tergantung pada
(didefinisikan oleh) lainnya nonkey atribut. tabel database pada tabel 10-1 berada di 3nf, tetapi
hanya berisi minimal atribut. perlu diingat bahwa basis data tidak statis. sebagai kebutuhan
pengguna mengubah dan pengguna tambahan pandangan dikembangkan, atribut tambahan dan
mungkin tambahan tabel mungkin perlu dimasukkan ke dalam database. penambahan ini harus
mematuhi Normalisasi aturan untuk mempertahankan integritas struktural dari tabel dan
menghindari anomali. untuk lengkap dis cussion dari anomali, dependensi, dan Normalisasi
teknik, harap Tinjau yang sesuai bagian dari Bab 9 dan lampiran. langkah 3. membangun fisik
database dan menghasilkan pengguna tampilan pada titik ini, database desainer siap untuk
membuat fisik relasional tabel berdasarkan deskripsi pada tabel 10-1. setelah tabel telah
dibangun, beberapa dari mereka harus diisi dengan data. sumber daya dan agen tabel harus
diinisialisasi dengan nilai-nilai data seperti persediaan jumlah di tangan, cus tomer nama dan
alamat, dan karyawan data. sistem baru akan mulai operasi dengan awal Val ues untuk atribut
dari tabel ini. sebaliknya, acara meja memulai kosong dan akan diisi melalui sebenarnya
transaksi kegiatan pengolahan.
[11/4 18.04] Desy Khofifah: 479
[11/4 18.05] Desy Khofifah: The resulting database should be rich enough to support the
information needs of all users of the system being modeled. This includes the needs of
accountants, operations personnel, and management. The

reports, computer screens, and documents that constitute these views are derived from structured
query

language commands and computer programs that access the normalized tables in the database
and navigate between them using the foreign keys as links. In this section, we present some
examples of the

reports that can be produced from rich event tables.

PRODUCING FINANCIAL STATEMENTS AND OTHER ACCOUNTING REPORTS. In a

traditional system, financial statements are typically prepared from general ledger accounts,
whose values

are derived from journal voucher postings. Accounting artifacts, including journals, ledgers, and
doubleentry accounting, however, are not entities in an REA model. Instead, these traditional
accounting mechanisms are reproduced from the event tables. To illustrate, Figure 10-13 presents
the structures for several

relational tables in the Apex database. These table structures correspond to the tables listed in
Table 10-1,

but some of the attributes have been omitted to simplify the figure. The figure demonstrates how
financial

statement accounting figures can be constructed from underlying event data. The calculations
are:

Total Sales = The sum of the Invoice Amount attribute in the Ship Product table for all items
shipped

on or before the year-end closing date.

Accounts Receivable = Total Sales minus the sum of the Receive Cash table’s Amount attribute
for

all remittances received on or before the year-end closing date.

Cost of Goods Sold = Sum of Quantity sold in the Inventory-Ship Link table multiplied by the
Unit

Cost attribute in the Inventory table.

Inventory = Quantity On Hand attribute multiplied by Unit Cost attribute in the Inventory table.

Accounting figures extracted in this way from REA tables can be used to prepare income
statements,

balance sheets, and even journal entries as illustrated with the journal voucher report in Figure
10-14.
PRODUCING MANAGEMENT REPORTS FROM REA TABLES. A key objective of REA is
to

create a database capable of supporting multiple user views. This section illustrates examples of
nonaccounting user reports that Apex Supply could produce from their database. Figure 10-15
depicts an inventory status report that their purchasing agent would use. This report identifies
items to be ordered and the
[11/4 18.06] Desy Khofifah: yang dihasilkan database harus cukup kaya untuk mendukung
kebutuhan informasi semua pengguna Sys tem yang dimodelkan. ini termasuk kebutuhan
akuntan, operasi personil, dan manajemen. laporan, layar komputer, dan dokumen yang
merupakan pandangan-pandangan ini berasal dari terstruktur bahasa query perintah dan program
komputer yang mengakses dinormalisasi tabel dalam database dan Navi gerbang di antara
mereka menggunakan kunci asing sebagai link. dalam bagian ini, kami hadir beberapa contoh
laporan yang dapat dihasilkan dari kaya acara meja. memproduksi laporan keuangan dan
akuntansi laporan. dalam Tra ditional sistem, laporan keuangan biasanya dibuat dari buku besar
account, yang nilai-nilai yang berasal dari jurnal voucher posting. akuntansi artefak, termasuk
jurnal, ledgers, dan pembukuan rangkap akuntansi, Bagaimanapun, tidak entitas dalam rea
model. sebaliknya, ini tradisional akuntansi Mecha nisms direproduksi dari acara meja. untuk
menggambarkan, gambar 10-13 menyajikan struktur selama beberapa relasional tabel di APEX
database. ini tabel struktur sesuai dengan tabel terdaftar di tabel 10-1, tetapi beberapa atribut
telah dihilangkan untuk menyederhanakan gambar. angka menunjukkan bagaimana laporan
keuangan akuntansi angka dapat dibangun dari mendasari data acara. perhitungan adalah: total
penjualan = jumlah faktur jumlah atribut di kapal produk tabel untuk semuanya dikirimkan pada
atau sebelum akhir tahun tanggal penutupan. piutang = total penjualan minus jumlah menerima
uang tunai tabel jumlah atribut untuk semua pengiriman uang yang diterima pada atau sebelum
akhir tahun tanggal penutupan. beban pokok penjualan = jumlah kuantitas dijual dalam
persediaan-kapal link tabel dikalikan dengan biaya unit atribut dalam persediaan tabel.
persediaan = kuantitas di tangan atribut dikalikan dengan biaya unit atribut dalam persediaan
tabel. akuntansi angka diekstraksi dengan cara ini dari rea tabel dapat digunakan untuk
mempersiapkan pendapatan konsolidasi, neraca, dan Bahkan entri jurnal sebagai diilustrasikan
dengan jurnal voucher laporan pada gambar 10-14. memproduksi manajemen laporan dari rea
tabel. sebuah tujuan utama dari rea adalah untuk membuat database mampu mendukung
beberapa pengguna tampilan. bagian ini menggambarkan contoh nonac menghitung laporan
pengguna yang APEX pasokan bisa menghasilkan dari database mereka. gambar 10-15
menggambarkan sebuah inven Tory laporan status bahwa agen pembelian akan menggunakan.
laporan ini mengidentifikasi item yang akan memerintahkan dan
[11/4 18.06] Desy Khofifah: 481

respective suppliers. The data for this report come from the Inventory and Supplier tables in
Table 10-1.

Figure 10-16 is a sales activity report organized by customer and product, which the sales
manager would

use. The report is constructed from data in the Customer, Ship Product, Inventory-Ship link, and
Inventory tables. Figure 10-17 is a customer inquiry report. The purpose of this report is to track
customer

inquires against actual sales. The report indicates how much time is spent on each customer
inquiry and

whether it led to a sale. The Customer, Verify Availability, Inventory-Verify Link, Inventory, and
Take
Order tables provide the data for the report.

REA AND VALUE CHAIN ANALYSIS

The competitive advantages to organizations that adopt the REA approach are most clearly seen
from the

perspective of the value chain. These are the activities that add value or usefulness to an
organization’s

products and services. To remain competitive, organizations must differentiate between their
various business activities, prioritizing them on the basis of their value in achieving
organizational objectives. This

means being adaptable and responsive to changes in the environment, including their
relationships with

suppliers, customers, and other external entities that influence performance. Modern decision
makers need

information systems that help them look beyond their internal operations to those of their trading
partners.

One approach adopted for this purpose is known as value chain analysis. This analysis
distinguishes between primary activities and support activities: primary activities create value;
support activities assist in the achievement of the primary activities. By applying value chain
analysis, an

organization can look beyond itself and maximize its ability to create value, for example, by
incorporating the needs of its customers in its products or accommodating the flexibility of its
suppliers in

scheduling its production.

Traditional information systems are not well suited to supporting value chain activities.
Organizations that have applied value chain analysis have generally done so outside the
traditional accounting

information system by providing such information separately to the decision makers. Frequently,
this

involved the creation of separate information systems, which results in data redundancy, data
concurrency, and system integration problems. As a single information system framework
capable of capturing generic and fine-grained data, REA can overcome these problems and is
capable of providing the

following advantages.

1. The REA approach to modeling business processes helps managers focus on the key elements
of

economic events and identify the nonvalue-added activities that can be eliminated from
operations.
[11/4 18.07] Desy Khofifah: masing-masing pemasok. data untuk laporan ini berasal dari
persediaan dan pemasok tabel dalam tabel 10-1. gambar 10-16 adalah penjualan laporan kegiatan
diselenggarakan oleh pelanggan dan produk yang manajer penjualan akan menggunakan. laporan
dibangun dari data pelanggan, kapal produk, persediaan-kapal link, dan inven Tory tabel. gambar
10-17 adalah seorang pelanggan kirim laporan. tujuan laporan ini adalah untuk melacak
pelanggan bertanya terhadap penjualan aktual. laporan menunjukkan berapa banyak waktu
dihabiskan pada setiap pelanggan kirim dan apakah itu dipimpin untuk penjualan. pelanggan,
memverifikasi ketersediaan, persediaan memverifikasi link, persediaan, dan mengambil pesanan
tabel menyediakan data untuk laporan. rea dan analisis rantai nilai keunggulan kompetitif untuk
organisasi yang mengadopsi rea pendekatan yang paling jelas dilihat dari perspektif rantai nilai.
ini adalah kegiatan yang memberikan nilai tambah atau kegunaan untuk organisasi produk dan
jasa. tetap kompetitif, organisasi harus membedakan antara mereka berbagai busi Ness kegiatan
prioritas mereka berdasarkan nilai mereka dalam mencapai organisasi tujuan. ini berarti
beradaptasi dan responsif terhadap perubahan lingkungan, termasuk hubungan mereka dengan
pemasok, pelanggan, dan eksternal lainnya entitas yang mempengaruhi kinerja. modern
pengambil keputusan membutuhkan sistem informasi yang membantu mereka terlihat luar
mereka operasi internal untuk orang-orang dari mereka mitra dagang. satu pendekatan diadopsi
untuk tujuan ini dikenal sebagai analisis rantai nilai. analisis ini Distin guishes antara utama
kegiatan dan mendukung aktivitas: utama kegiatan menciptakan nilai; mendukung kegiatan ities
membantu dalam pencapaian utama kegiatan. dengan menggunakan analisis rantai nilai, sebuah
organisasi dapat melihat di luar itu sendiri dan memaksimalkan kemampuan untuk membuat
nilai, misalnya, dengan incorpo peringkat kebutuhan pelanggan dalam produk atau akomodatif
fleksibilitas pemasoknya di penjadwalan produksi. tradisional sistem informasi tidak cocok
untuk mendukung rantai nilai kegiatan. organiza tions yang telah diterapkan analisis rantai nilai
umumnya melakukannya di luar tradisional sistem informasi akuntansi dengan menyediakan
informasi tersebut secara terpisah ke pengambil keputusan. sering, ini terlibat penciptaan terpisah
sistem informasi, yang menghasilkan data redundansi, data setuju rency, dan integrasi sistem
masalah. sebagai satu sistem informasi kerangka mampu captur Ing generik dan halus data, rea
dapat mengatasi masalah ini dan mampu memberikan keuntungan sebagai berikut. 1. rea
pendekatan untuk pemodelan proses bisnis membantu manajer fokus pada elemen kunci dari
peristiwa ekonomi dan mengidentifikasi nonvalue tambah kegiatan yang dapat dihilangkan dari
operasi.
[11/4 18.08] Desy Khofifah: 482

Improving the operational efficiency of individual departments thus generates excess capacity
that

can be redirected to increase the overall productivity of the firm.

2. The storage of both financial and nonfinancial data in a common database reduces the need for
multiple data collection, storage, and maintenance procedures.

3. Storing financial and nonfinancial data about business events in detailed form permits a wider
range

of management decisions by supporting multiple user views.

4. The REA model provides managers with more relevant, timely, and accurate information. This

will translate into better customer service, higher-quality products, and flexible production

processes.

REA COMPROMISES IN PRACTICE

The advantages to operational efficiency, systems integration, and value chain analysis have
drawn

great attention to REA as a theoretical model for system and database design. As a practical
matter,

however, larger organizations often compromise the REA model for financial statement reporting
purposes. Although it is possible to extract traditional financial information from event data (as
illustrated

in Figure 10-13), doing so from millions of individual event records can be problematic. Instead,
most

companies implementing an REA model create an event database for operations, planning, and
control

purposes and maintain a traditional general ledger system separately in the background for
financial

reporting. Enterprise resource planning systems, which are discussed in the next chapter,
exemplify the

successful integration of event-based and traditional database designs within a single system.

Summary

This chapter examined the REA model as a means of specifying and designing accounting
information systems that serve

the needs of all users in an organization. It began by defining

the key elements of REA. The basic model employs a unique

form of an ER diagram called an REA diagram, which consists

of three entity types (resources, events, and agents) and a

set of associations linking them. The rules for developing an

REA diagram were then explained and illustrated in detail.

Each event in an REA diagram is linked to at least one

resource and to at least two agents. An important aspect of the

model is the concept of economic duality, which specifies that

each economic event must be mirrored by an associated economic event in the opposite
direction. These dual events constitute the give and receive activities in an economic exchange.

The chapter went on to illustrate the development of an

REA database for a hypothetical firm following a multistep

process called view modeling. The steps involved are: (1) identify the event to be modeled, (2)
identify the resource changed

by events, (3) identify the agents participating in events, and

(4) determine associations and cardinalities between entities.

The result of this process is an REA diagram for a single organizational function. This next
section in the chapter explained

how multiple REA diagrams (revenue cycle, purchases, cash

disbursements, and payroll) are integrated into a global or

enterprise-wide model. The enterprise model was then implemented into a relational database
structure and user views

were constructed. The view integration process involved

three steps: (1) consolidate the individual models; (2) define

primary keys, foreign keys, and attributes; and (3) construct

the physical database and produce the user views.

The chapter concluded with a discussion of how REA

modeling can improve competitive advantage by allowing management to focus on the value-
added activities of their operations. For financial statement reporting purposes, however,

many companies compromise the pure REA model by maintaining a traditional general ledger
system.

Key Terms

agents (459)

association (467)

cardinality (467)

duality (461)

economic events (461)

external agent (461)

give event (461)

internal agent (461)

[11/4 18.08] Desy Khofifah: meningkatkan efisiensi operasional individu Departemen dengan
demikian menghasilkan kelebihan kapasitas yang dapat diarahkan untuk meningkatkan
keseluruhan produktivitas perusahaan. 2. penyimpanan kedua keuangan dan nonfinansial data
Umum database mengurangi kebutuhan untuk multi PLE pengumpulan data, penyimpanan, dan
prosedur perawatan. 3. menyimpan keuangan dan nonfinansial data tentang acara bisnis di rinci
bentuk izin yang lebih luas berbagai keputusan manajemen oleh mendukung beberapa pengguna
tampilan. 4. rea model memberikan manajer dengan lebih relevan, tepat waktu, dan informasi
yang akurat. ini akan terjemahkan ke pelanggan yang lebih baik layanan, berkualitas tinggi
produk, dan fleksibel proses produksi. rea kompromi dalam prakteknya keuntungan untuk
efisiensi operasional, integrasi sistem, dan analisis rantai nilai telah ditarik perhatian besar untuk
rea seperti model teoritis untuk sistem dan desain database. sebagai praktis peduli,
Bagaimanapun, organisasi yang lebih besar sering membahayakan rea model untuk laporan
keuangan pelaporan pur pose. Meskipun hal ini dimungkinkan untuk ekstrak tradisional
informasi keuangan dari data acara (sebagai diilustrasikan pada gambar 10-13), melakukannya
dari jutaan individu acara catatan dapat bermasalah. sebaliknya, sebagian besar perusahaan
menerapkan rea model membuat acara database untuk operasi, perencanaan, dan kontrol tujuan
dan mempertahankan tradisional buku besar sistem secara terpisah di latar belakang laporan
keuangan. perencanaan sumber daya perusahaan sistem, yang dibahas dalam Bab berikutnya,
memberikan contoh keberhasilan integrasi acara berbasis dan tradisional database desain dalam
sistem tunggal. ringkasan Bab ini meneliti rea model sebagai sarana menentukan Ing dan
perancangan sistem informasi akuntansi yang melayani kebutuhan semua pengguna dalam
organisasi. mulai dengan mendefinisikan elemen kunci dari rea. model dasar mempekerjakan
bentuk unik dari er diagram disebut rea diagram, yang terdiri dari tiga entitas jenis (sumber daya,
acara, dan agen) dan satu set Asosiasi menghubungkan mereka. aturan untuk mengembangkan
rea diagram kemudian menjelaskan dan digambarkan secara rinci. setiap acara dalam rea
diagram terkait dengan setidaknya satu sumber daya dan setidaknya dua agen. aspek penting dari
model konsep ekonomi dualitas, yang menentukan bahwa setiap ekonomi acara harus
dicerminkan oleh Asosiasi Eco eko- kegiatan di arah yang berlawanan. ini dual peristiwa Con
stitute yang memberi dan menerima kegiatan ekonomi Exchange. Bab melanjutkan untuk
menggambarkan pengembangan sebuah rea database untuk hipotetis perusahaan mengikuti
bertingkat proses yang disebut lihat pemodelan. langkah-langkah yang terlibat adalah: (1) Iden
tify acara menjadi model, (2) mengidentifikasi sumber daya berubah oleh peristiwa, (3)
mengidentifikasi agen yang berpartisipasi dalam acara, dan (4) menentukan Asosiasi dan
kardinalitas antara entitas. hasil dari proses ini adalah rea diagram untuk satu orga nizational
fungsi. ini bagian berikut dalam Bab ini menjelaskan bagaimana beberapa rea diagram (siklus
pendapatan, pembelian, pengeluaran kas, dan penggajian) diintegrasikan ke dalam global atau
perusahaan di seluruh model. perusahaan model kemudian imple mented menjadi struktur
database relasional dan user pandangan yang dibangun. pandangan integrasi proses melibatkan
tiga langkah: (1) mengkonsolidasikan individu model; (2) mendefinisikan kunci Primer, kunci
asing, dan atribut; dan (3) membangun fisik database dan menghasilkan pengguna tampilan. Bab
menyimpulkan dengan diskusi tentang bagaimana rea pemodelan dapat meningkatkan
keunggulan kompetitif dengan memungkinkan orang pengelolaan untuk fokus pada nilai tambah
kegiatan mereka Opera tions. untuk laporan keuangan tujuan pelaporan, Namun, banyak
perusahaan kompromi murni rea model oleh utama taining tradisional buku besar sistem. istilah
kunci agen (459) Asosiasi (467) kardinalitas (467) dualitas (461) peristiwa ekonomi (461) luar
agen (461) memberikan acara (461) internal agen (461)
[11/4 18.09] Desy Khofifah: REA diagram (460)

REA model (460)

receive event (461)

resources (460)

semantic models (460)

stock flow (461)

support events (461)

third normal form (3NF) (477)

user view (460)

value chain (465)

value chain analysis (481)

view integration (470)

view modeling (462)

Review Questions

1. What is a user view?

2. What is a semantic data model?

3. What is an REA diagram?

4. What are economic resources?

5. What are economic events?

6. What are support events?

7. What are economic agents?

8. Define duality.

9. What is view modeling?

10. What is represented by the labeled lines connecting entities in an REA diagram?

11. Why are journals and ledgers not modeled in an

REA diagram?

12. Define association.

13. Define cardinality.

14. Name the four basic forms of cardinality.

15. What is view integration?

16. List the steps involved in view integration.

17. What is the rule for assigning foreign keys in a 1:1

association?
18. What is the rule for assigning foreign keys in a 1:M

association?

19. What is the rule for assigning foreign keys in an

M:M association?

20. Define the value chain.

Discussion Questions

1. From the perspective of an organization, explain

duality as it relates to the give and receive events

of an economic exchange.

2. Explain the relationship between cardinality and

association.

3. Discuss the rules for assigning primary keys to

database tables.

4. Discuss the rules for linking events to resources

and agents in an REA diagram.

5. How are external and internal agents modeled in

REA diagrams for transactions that involve purely

internal exchanges, such as raw material moving

into production?

6. Explain how REA databases are able to support financial statement reporting when they do not

employ journals and ledgers.

7. Distinguish between economic events and support

events and provide examples of each.

8. Describe the minimum number and types of

events that an REA diagram must include.

9. Why are traditional accounting events such as recording a transaction in a journal or posting to

ledgers not modeled in REA diagrams?

10. ER diagrams usually include the link tables in

the model to resolve M:M associations. REA

diagrams typically do not show link tables.

Explain.

11. Employee time is a resource that is always used

but is not always modeled in an REA diagram.

Explain and give examples.

12. When are data in 3NF

[11/4 18.10] Desy Khofifah: rea diagram (460) rea model (460) menerima acara (461) sumber
daya (460) semantik model (460) saham aliran (461) mendukung acara (461) ketiga bentuk
normal (3nf) (477) pengguna lihat (460) rantai nilai (465) analisis rantai nilai (481) tampilkan
integrasi (470) tampilkan pemodelan (462) ulasan pertanyaan 1. apakah yang dimaksud dengan
pengguna lihat? 2. apakah yang dimaksud dengan semantik model data? 3. adalah rea diagram?
4. adalah sumber daya ekonomi? 5. apa yang peristiwa ekonomi? 6. apa yang mendukung acara?
7. apa yang agen-agen ekonomi? 8. mendefinisikan dualitas. 9. apakah lihat pemodelan? 10. apa
yang diwakili oleh berlabel jalur tersambung Ing entitas dalam rea diagram? 11
yang selalu digunakan tetapi tidak selalu dimodelkan dalam rea diagram. menjelaskan dan
memberikan contoh. 12. kapan data di 3nf

pilihan ganda pertanyaan

1. konsep dualitas berarti bahwa rea diagram harus terdiri atas.
a. dua peristiwa-salah satunya ekonomi dan pendukung lainnya.
2. setiap ekonomi event di sebuah rea diagram selalu.
a. terkait dengan setidaknya dua sumber daya entitas. .
b. terkait dengan lain ekonomi acara.
c. terkait dengan dukungan acara.
3. yang dari berikut ini adalah karakteristik Eco eko- agen
a. mereka berpartisipasi dalam peristiwa ekonomi, tapi jangan berasumsi kontrol
sumber daya.
b. mereka berpartisipasi dalam peristiwa ekonomi, tetapi tidak mendukung acara.
4. yang dari berikut ini benar? sebuah. rea diagram entitas disusun constella tions oleh
entitas kelas. B. er diagram hadir statis gambar yang mendasari bisnis fenomena. c.
entitas nama di er diagram selalu dalam kata benda bentuk. D. peristiwa entitas nama di
rea diagram berada di kata kerja bentuk. e. semua di atas adalah benar konsolidasi.
5. yang dari peristiwa berikut akan paling mungkin dimodelkan dalam rea diagram A.
pertanyaan pelanggan B. penjualan untuk pelanggan c. hutang D. kas e. semua peristiwa
ini akan dimodelkan
6. yang dari berikut Asosiasi akan kemungkinan besar menggambarkan hubungan antara
internal agen dan ekonomi acara A. 1: M B. 1: 1 c. M: M D. 0: M e. Tidak ada di atas
7. yang dari tabel berikut ini akan kemungkinan besar memiliki komposit kunci A.
Mengambil pesanan B. Kapal barang c. Persediaan-kapal link D. Kas e. Tidak ada di atas
8. yang dari berikut Asosiasi membutuhkan Sep arate tabel dalam database A. 1: 1 B. 1: M
c. M: M D. Semua di atas
9. ketika menetapkan kunci asing dalam 1: 1 Asosiasi A. Kunci Primer dari setiap tabel
harus menanamkan ded sebagai kunci asing di terkait tabel. B. Kunci Primer pada 0,1 sisi
hubungan harus dimasukkan sebagai kunci asing pada 1,1 sisi. C. Kunci Primer pada 1,1
 sisi hubungan harus dimasukkan sebagai kunci asing pada 0,1 samping. D. Link tabel
harus diciptakan untuk menerima untuk eign kunci dari kedua tabel. E. Tidak ada di atas
adalah benar.
10. ketika menetapkan kunci asing dalam 1: M Asosiasi A. Kunci Primer dari setiap tabel
harus dimasukkan sebaagai kunci asing di terkait tabel. B. Kunci Primer di 0, M sisi
hubungan harus dimasukkan sebagai kunci asing pada 1,1 sisi. C. Kunci Primer pada 1,1
sisi hubungan harus dimasukkan sebagai kunci asing pada 0, M samping. D. Link tabel
harus diciptakan untuk menerima untuk eign kunci dari kedua tabel. E. Tidak ada di atas
adalah benar.

[11/4 18.13] Desy Khofifah: Hal 485

Problems

1. REA DIAGRAMS

Describe three differences between REA diagrams and

ER diagrams.

2. REA ASSOCIATIONS

Bentley Restorations Company restores and sells topend classic and antique automobiles. Most
of its customers are private collectors, but some are investors

who buy multiple cars and hold them for resale. Bentley

extends no credit terms. All sales are for cash.

Required

Which of the relationships in the diagram for Problem 2

properly models the entity associations for Bentley

Restorations? Explain your answer.

3. REA ASSOCIATIONS
Based on the data in Problem 2, which of the following

relationships in the diagram for Problem 3 properly

models the entity associations for ey Restorations?

Explain your answer.

4. REA ASSOCIATIONS

Based on the data in Problem 2, which of the relationships in the diagram for Problem 4 properly
models

the entity associations for this situation? Explain your

answer.

5. REA MODEL EXTRACT

Prepare an REA model depicting the issuance of raw

materials into the manufacturing process. Identify the

[11/4 18.13] Desy Khofifah: Hal. 485
[11/4 18.13] Desy Khofifah: masalah 1. rea diagram menjelaskan tiga perbedaan antara rea
diagram dan er diagram. 2. rea Asosiasi Bentley restorasi perusahaan mengembalikan dan
menjual akhir atas klasik dan antik mobil. sebagian besar yang cus tomers pribadi kolektor, tetapi
beberapa investor yang membeli beberapa mobil dan menahan mereka untuk dijual kembali.
Bentley meluas tidak ada persyaratan kredit. semua penjualan untuk uang tunai. diperlukan yang
dari hubungan dalam diagram untuk masalah 2 benar model entitas Asosiasi untuk Bentley
restorasi? menjelaskan jawaban Anda. 3. rea Asosiasi berdasarkan data dalam masalah 2, yang
dari berikut hubungan dalam diagram untuk masalah 3 benar model entitas Asosiasi untuk
Bentley restorasi? menjelaskan jawaban Anda. 4. rea Asosiasi berdasarkan data dalam masalah 2,
yang dari hubungan kapal dalam diagram untuk masalah 4 benar model entitas Asosiasi untuk
situasi ini? menjelaskan jawaban Anda. 5. rea model ekstrak menyiapkan rea model yang
menggambarkan penerbitan bahan baku ke dalam proses produksi. mengidentifikasi
[11/4 18.14] Desy Khofifah: resource, event, and agent entities. Show the cardinalities in the
associations between entities.

6. REA MODEL—HORIZON BOOKS

Horizon Books is a bookstore in downtown Philadelphia. It carries an inventory of

approximately 5,000

books. Customers come in and browse the shelves,

select their books, and take them to the cashier. At the

cashier’s desk, they can also discover whether a particular book is in stock, place orders for
books not currently

available in the bookstore, and collect and pay for

books previously ordered. There are no credit sales.

[11/4 18.14] Desy Khofifah: sumber daya, acara, dan agen entitas. menampilkan Kardinal ities
dalam Asosiasi antara entitas. 6. rea model-Horizon buku Horizon buku adalah toko buku di
Pusat Kota philadel phia. itu melakukan inventarisasi dari sekitar 5,000 buku. pelanggan datang
dan isi rak-rak, pilih buku mereka, dan membawa mereka ke kasir. di kasir meja tulis, mereka
juga dapat menemukan apakah particu Lar buku dalam persediaan, memesan untuk buku saat ini
tidak tersedia di toko buku, dan mengumpulkan dan membayar untuk buku sebelumnya
memerintahkan. ada tidak ada penjualan kredit.
[11/4 18.15] Desy Khofifah: Hal. 486
[11/4 18.16] Desy Khofifah: semua pelanggan membayar untuk pembelian mereka pada saat
pembelian. diperlukan menyiapkan rea model untuk Horizon database. tampilkan semua
kardinalitas dalam Asosiasi. 7. rea model-feinman komputer feinman komputer menjual
komputer desktop sistem yang memproduksi dari bagian dan perangkat lunak yang vendor pihak
ketiga menyediakan. pelanggan baik swasta Con sumers dan usaha kecil. konsumen membayar
tunai atau dengan kartu kredit, tapi bisnis pelanggan membeli kredit. sebuah pemeriksaan kredit
adalah terbuat dari semua bisnis baru pelanggan sebelum menyetujui garis kredit. penjualan yang
dibuat online atau dengan keras copy rangka dokumen yang pelanggan Mail atau faks kepada
perusahaan. ketika kredit agar diterima, penjualan petugas Veri fies persediaan ketersediaan,
menyiapkan order penjualan dan mengirimkan saham rilis copy ke Willy, gudang EM ployee
yang mengambil barang dan mengatur pengiriman. Willy kemudian mempersiapkan tagihan dari
lading dan pengiriman pemberitahuan. barb di penagihan Departemen menerima pengiriman
pemberitahuan dari Willy dan update persediaan anak perusahaan buku besar untuk mencapai
pengurangan inven Tory. barb file saham rilis, mempersiapkan faktur, dan Mail salinan ke
pelanggan. barb kemudian update penjualan jurnal dan kemudian mengirimkan faktur, order
penjualan, saham rilis, dan pengiriman melihat ke AR Departemen. Adam di AR Departemen file
dokumen yang barb mengirimnya dan update AR anak perusahaan buku besar. Mickey dalam
ekspedisi menerima pengiriman uang nasihat dan pelanggan cek dikirim dalam pembayaran
rekening. ia mengirimkan pengiriman uang saran untuk Adam untuk posting ke AR buku besar
dan mengirimkan cek untuk Carol, yang penerimaan kas petugas. pada akhir hari, ia menyiapkan
de menempatkan slip dan deposit cek ke perusahaan rekening Bank, file Bank penerimaan, dan
update penerimaan kas jurnal. penjualan tunai untuk konsumen pelanggan ditangani dengan cara
yang sama dengan proses yang Dijelaskan di sini kecuali bahwa pemeriksaan atau kartu kredit
nomor rekening yang disampaikan dengan yang asli rangka. pada akhir setiap Minggu, John,
seorang petugas akuntansi, mendamaikan semua transaksi dan posting mereka ke buku besar.
diperlukan. mempersiapkan rea model penjualan / proses pengumpulan. B. lihat tarif dan
kardinalitas untuk semua Asosiasi. c. daftar tabel, kunci, dan atribut yang dibutuhkan untuk
menerapkan model ini di database relasional. 8. rea model-k meriam, Inc. k meriam, Inc, adalah
produsen dari portabel CD bermain ers. perusahaan pembelian bahan baku seperti Plas tics dan
chip komputer untuk konversi siklus. berikut menggambarkan k meriam pembelian dan
membayar ments prosedur. John, beli Departemen petugas, monitor bahan baku tingkat
persediaan dan mempersiapkan pembelian req uisition saat pembelian diperlukan. ini adalah
dikirim ke agen pembelian, yang mempersiapkan enam salinan yang pur Chase rangka. dua
pesanan pembelian dikirim langsung ke vendor. satu ditempatkan di terbuka pesanan pembelian
file di Departemen pembelian, dan satu digunakan untuk Post untuk pembelian jurnal. semua
penawaran wisata beli berangkat ment petugas mempersiapkan sebuah jurnal voucher dari pur
mengejar jurnal dan mengirimkannya ke General Ledger Departemen untuk posting. yang ap dan
penerima Departemen juga setiap menerima salinan pesanan pembelian, yang mereka file
Sementara. setelah menerima bahan baku, penerima Departemen petugas menciptakan lima
salinan dari penerima laporan. satu salinan dikirim ke bahan baku gudang dan satu salinan
dikirim ke ap Departemen. dua salinan yang dikirim ke Departemen pembelian, di mana satu
diajukan dan satu digunakan untuk informasi persediaan catatan. akhir copy diajukan dalam
menerima Departemen dengan pesanan pembelian dan slip kemasan. vendor menyekolahkan
[11/4 18.16] Desy Khofifah: All customers pay for their purchases at the time of

purchase.
Required

Prepare an REA model for Horizon’s database. Show

all cardinalities in the associations.

7. REA MODEL—FEINMAN

COMPUTERS

Feinman Computers sells desktop computer systems

that it manufactures from parts and software that thirdparty vendors provide. Customers are both
private consumers and small businesses. Consumers pay cash or

by credit card, but business customers buy on credit.

A credit check is made of all new business customers

before approving a line of credit. Sales are made online

or by a hard-copy order document that customers mail

or fax to the company.

When a credit order is received, the sales clerk verifies inventory availability, prepares a sales
order and

sends the stock release copy to Willy, a warehouse employee who picks the goods and arranges
shipment.

Willy then prepares the bills of lading and shipping

notices. Barb in the billing department receives the

shipping notice from Willy and updates the inventory

subsidiary ledger to account for the reduction in inventory. Barb files the stock release, prepares
the invoice,

and mails a copy of it to the customer. Barb then

updates the sales journal and then sends the invoice,

sales order, stock release, and shipping notice to the AR

department.

Adam in the AR department files the documents that

Barb sent him and updates the AR subsidiary ledger.

Mickey in the mail room receives remittance advices

and customer checks sent in payment of accounts. He

sends the remittance advice to Adam for posting to the

AR ledger and sends the checks to Carol, the cash

receipts clerk. At the end of the day, she prepares a deposit slip and deposits the checks into the
company’s

bank account, files the bank receipt, and updates the

cash receipts journal.

Cash sales to consumer customers are handled in a

manner similar to the process described here except that

checks or credit card account numbers are submitted

with the original order.

At the end of each week, John, an accounting clerk,

reconciles all transactions and posts them to the general

ledger.

Required

a. Prepare the REA model of the sales/collection

process.

b. Show the cardinalities for all associations.

c. List the tables, keys, and attributes needed to

implement this model in a relational database.

8. REA MODEL—K CANNON, INC.

K Cannon, Inc., is a manufacturer of portable CD players. The company purchases raw materials
such as plastics and computer chips for its conversion cycle. The

following describes K Cannon’s purchases and payments procedures.

John, the purchasing department clerk, monitors raw

materials inventory levels and prepares a purchase requisition when purchases are necessary.
These are sent to

the purchasing agent, who prepares six copies of a purchase order. Two purchase orders are sent
directly to
the vendor. One is placed in an open purchase order file

in the purchasing department, and one is used to post to

the purchases journal. Each week the purchasing department clerk prepares a journal voucher
from the purchases journal and sends it to the general ledger

department for posting. The AP and the receiving

departments also each receive a copy of the purchase

order, which they file temporarily.

Upon receiving the raw materials, the receiving

department clerk creates five copies of the receiving

report. One copy is sent to the raw materials warehouse

and one copy is sent to the AP department. Two copies

are sent to the purchasing department, where one is filed

and one is used to update the inventory records. The

final copy is filed in the receiving department with the

purchase order and packing slip. Vendors send their

[11/4 18.17] Desy Khofifah: faktur ke ap Departemen, di mana mereka digunakan untuk
memperbarui ap anak perusahaan buku besar. dalam pengeluaran kas Departemen, Larry
menerima informasi dari ap Departemen, seperti pembelian permintaan, pesanan pembelian,
menerima laporan, dan faktur. ia kemudian mempersiapkan dan tanda-tanda cek untuk pemasok.
setelah penyusunan pemeriksaan, ini Sup Port dokumen dikirim kembali ke ap Departemen.
setiap Minggu, Larry mempersiapkan sebuah jurnal voucher dan mengirimkannya ke General
Ledger Departemen untuk posting. diperlukan. mempersiapkan rea model pembelian
pembayaran tunai proses. B. lihat tarif dan kardinalitas untuk semua Asosiasi. c. daftar tabel,
kunci, dan atribut yang dibutuhkan untuk imple ment model ini di database relasional. 9. rea
model-sistem penggajian setiap 2 Minggu, karyawan untuk sebuah perusahaan manufaktur
mengajukan waktu kartu dengan Supervisor, yang ulasan dan menyetujui mereka. mereka adalah
disampaikan ke membayar roll Departemen. pada saat itu, sumber daya manusia petugas juga
mengajukan personil tindakan penggajian petugas. penggajian petugas memasuki informasi dari
ini sumber dokumen ke karyawan catatan dan kemudian menambahkan karyawan jam ke
penggajian daftar mencerminkan karyawan membayar tarif, pemotongan, dan pekerjaan
klasifikasi. satu salinan penggajian mendaftar, seiring dengan waktu kartu, diajukan dalam
payroll Departemen, dan satu salinan dikirim ke ap Departemen. berikutnya penggajian petugas
mengirimkan karyawan gaji ke pengeluaran kas Departemen. cek masuk dan didistribusikan
kepada karyawan oleh kasir. yang ap Departemen menyiapkan pengeluaran kas voucher. salinan
voucher dan salinan penggajian daftar dikirimkan pada pengeluaran kas Departemen dan
kemudian dikirim ke buku besar. kas dis bursements petugas menulis cek untuk seluruh
penggajian dan deposit dalam payroll uang muka kas akun. salinan cek, pencairan voucher, dan
penggajian daftar dikirim kembali ke ap Departemen, di mana mereka mengajukan. diperlukan.
mempersiapkan rea model penggajian proses. B. lihat tarif dan kardinalitas untuk semua
Asosiasi. c. daftar tabel, kunci, dan atribut yang dibutuhkan untuk menerapkan model ini di
database relasional. 10. rea model-aset tetap sistem aset akuisisi dimulai ketika manajer
Departemen mengakui kebutuhan untuk memperoleh atau menggantikan yang ada aktiva tetap.
manajer menyiapkan dua salinan yang pur Chase permintaan; salah satu diajukan di Departemen
dan salah satunya adalah dikirim ke Departemen pembelian. beli Departemen menggunakan
pembelian permintaan untuk mempersiapkan tiga salinan pesanan pembelian. satu salinan dari
pur Chase pesanan dikirim ke pemasok, salinan lain adalah dikirim ke ap Departemen, dan ketiga
copy diajukan di Departemen pembelian. penerima Departemen menerima aset dan slip kemasan
dari vendor dan menyiapkan menerima laporan. satu salinan penerima laporan dikirim ke ap,
salah satunya adalah dikirim ke Departemen pria ager, dan salah satunya adalah dikirim ke
persediaan Departemen petugas dan digunakan untuk informasi persediaan catatan. yang ap
petugas menerima faktur, yang dia membandingkan dengan pesanan pembelian dan menerima
laporan. yang ap petugas masukan informasi ke terminal komputer, posting kewajiban, update
pembelian jurnal, dan mencetak salinan cetak jurnal voucher dan kas pencairan voucher. jurnal
voucher dikirim ke General Ledger Departemen, dan pengeluaran kas voucher dan pemasok
faktur yang dikirim ke pengeluaran kas Departemen. pesanan pembelian dan menerima laporan
disampaikan di ap. yang pengeluaran kas petugas mempersiapkan dan posting cek untuk check
daftar menggunakan Informa tion dari pemasok faktur dan uang tunai menyalurkan ments
voucher, dan mencetak hard copy dari cek, yang dikirim ke vendor. yang pengeluaran kas
voucher dikirim ke General Ledger Departemen. Departemen manajer juga menangani aset
mainte nance dan aset pembuangan. manajer menyesuaikan aktiva tetap persediaan anak
perusahaan saldo rekening sebagai aset terdepresiasi dari waktu ke waktu. ketika aset telah
mencapai akhir dari masa manfaat, pembuangan laporan siap. Departemen manajer mengirimkan
aset status ringkasan ke buku besar. General Ledger Departemen petugas mendamaikan yang
pengeluaran kas voucher, jurnal voucher, dan aset status ringkasan dan posting ke General
Ledger account. diperlukan. mempersiapkan rea model aktiva tetap prosedur. B. lihat tarif dan
kardinalitas untuk semua Asosiasi. c. daftar tabel, kunci, dan atribut yang dibutuhkan untuk
imple ment model ini di database relasional
[11/4 18.18] Desy Khofifah: invoices to the AP department, where they are used to

update the AP subsidiary ledger.

In the cash disbursements department, Larry receives

the information from the AP department, such as the

purchase requisition, purchase order, receiving report,

and invoice. He then prepares and signs the checks for

the suppliers. After preparation of the checks, these supporting documents are sent back to the
AP department.

Each week, Larry prepares a journal voucher and sends

it to the general ledger department for posting.

Required

a. Prepare the REA model of the purchase cash

payments process.

b. Show the cardinalities for all associations.

c. List the tables, keys, and attributes needed to implement this model in a relational database.

9. REA MODEL—PAYROLL SYSTEM

Every 2 weeks, employees for a manufacturing firm

submit their time cards to the supervisor, who reviews

and approves them. They are the submitted to the payroll department. At that time, the human
resources clerk

also submits a personnel action to the payroll clerk. The

payroll clerk enters the information from these source

documents into the employee records and then adds the

employee hours to a payroll register reflecting employee

pay rates, deductions, and job classification. One copy

of the payroll register, along with the time cards, is filed

in the payroll department, and one copy is sent to the

AP department.

Next the payroll clerk sends the employee paychecks

to the cash disbursements department. The checks are

signed and distributed to the employees by the paymaster.

The AP department prepares a cash disbursements

voucher. A copy of the voucher and a copy of the payroll

register are sent to the cash disbursements department

and are then posted to the general ledger. The cash disbursements clerk writes a check for the
entire payroll and

deposits it in the payroll imprest cash account. A copy of

the check, the disbursement voucher, and the payroll

register are sent back to the AP department, where they

are filed.

Required

a. Prepare the REA model of the payroll process.

b. Show the cardinalities for all associations.

c. List the tables, keys, and attributes needed to

implement this model in a relational database.

10. REA MODEL—FIXED ASSET

SYSTEM

Asset acquisition begins when the department manager

recognizes the need to obtain or replace an existing

fixed asset. The manager prepares two copies of a purchase requisition; one is filed in the
department and one

is sent to the purchasing department. The purchasing

department uses the purchase requisition to prepare

three copies of a purchase order. One copy of the purchase order is sent to the supplier, another
copy is sent

to the AP department, and the third copy is filed in the

purchasing department. The receiving department

receives the assets and packing slip from the vendor and

prepares a receiving report. One copy of the receiving

report is sent to AP, one is sent to the department manager, and one is sent to the inventory
department clerk

and used to update the inventory records.

The AP clerk receives the invoice, which she compares

to the purchase order and receiving report. The AP clerk

inputs the information into the computer terminal, posts

the liability, updates the purchase journal, and prints out

hard copies of a journal voucher and cash disbursement

voucher. The journal voucher is sent to the general ledger

department, and the cash disbursements voucher and the

supplier’s invoice are sent to the cash disbursements

department. The purchase order and the receiving report

are filed in AP. The cash disbursements clerk prepares

and posts a check to the check register using the information from the supplier’s invoice and the
cash disbursements voucher, and prints a hard copy of the check,

which is sent to the vendor. The cash disbursements

voucher is sent on to the general ledger department.

The department manager also handles asset maintenance and asset disposal. The manager adjusts
the fixed

asset inventory subsidiary account balances as the assets

depreciate over time. When an asset has reached the

end of its useful life, a disposal report is prepared. The

department manager sends an asset status summary to

the general ledger. The general ledger department clerk

reconciles the cash disbursements voucher, the journal

voucher, and the asset status summary and posts to the

general ledger accounts.

Required

a. Prepare the REA model of the fixed asset

procedures.

b. Show the cardinalities for all associations.

c. List the tables, keys, and attributes needed to implement this model in a relational database.