The REA Approach to Database Modeling

THE REA MODEL

Gambar

Elements of an REA Model

RESOURCES. Economic resources are things of economic value to the organization. They are defined as
objects that are both scarce and under the control of the enterprise. Resources are used in economic
exchanges with trading partners and are either increased or decreased by the exchange.

EVENTS.

Economic events are phenomena that effect changes (increases or decreases) in resources as
represented by the stock flow relation in Figure 10-1. ThEconomic events are phenomena that effect
changes (increases or decreases) in resources as represented by the stock flow relation in Figure 10-1.

Support events (not shown in Figure 10-1) include control, planning, and management activities that are
related to economic events but do not directly effect a change in resources.

AGENTS. Economic agents are individuals and departments that participate in economic and support
events. Each economic event is associated with at least one internal agent and one external agent who
participate in the exchange.

DUALITY.

Gambar

Developing an REA Model

DIFFERENCES BETWEEN ER AND REA DIAGRAMS

ER and REA diagrams differ visually in a significant way. Entities in ER diagrams are of one class, and their
proximity to other entities is determined by their cardinality and by what is visually pleasing to keep the
diagrams readable. Entities in an REA diagram, however, are divided into three classes (resources,
events, and agents) and organized into constellations by class on the diagram.

Gambar

A second difference between ER and REA diagrams involves the sequencing of events. ER diagrams
present a static picture of the underlying business phenomena. Relationships between data are shown
through cardinality and associations, but the sequence of activities that determine the cardinality and
associations is not clearly represented. REA diagrams, however, are typically organized from top to
bottom within the constellations to focus on the sequence of events. An advantage of this is that during
systems development, management and non-technical users better understand REA diagrams.

The third difference between ER and REA diagrams pertains to naming conventions for entities. In ER
diagrams, entity names are always represented in the singular noun form. REA modeling applies this rule
when assigning names to resource and agent entities.

VIEW MODELING: CREATING AN INDIVIDUAL REA DIAGRAM

This section describes the view modeling process as applied to creating an REA diagram. The process
involves the following steps:

1. Identify the event entities.

VERIFY AVAILABILITY

TAKE ORDER.

SHIP PRODUCT.

RECEIVE CASH.

INVALID ENTITY TYPES.

2. Identify the resource entities.

Each economic event in an REA model must be linked to at least one resource 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.

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.

3. The shipping clerk, who participates in the Ship Product event.
4. The cash receipts clerk, who participates in the Receive Cash event.

4. Determine associations and cardinalities between entities.

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).

CARDINALITY BETWEEN THE VERIFY AVAILABILITY AND TAKE ORDER ENTITIES.

Each occurrence of the Verify Availability entity is the result of a customer inquiry.

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.

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.

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 imprest account, and petty cash.

MANY-TO-MANY 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.

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 are constructed. The view integration process involves three basic steps:

1. Consolidate the individual models.

Purchases and Cash Disbursements Procedures

Gambar

Payroll Procedures
Gambar

Merge Individual REA Diagrams

By flipping the expenditure cycle diagrams to create a mirror image effect, the common resources of
Inventory and Cash are centered in the diagram

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

Gambar

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 require 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

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.
Rules for Foreign Keys
The degree of association between tables (i.e., 1:1, 1:M, and M:M) determines how foreign keys are
assigned.

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.

Keys in 1:M Associations

When a 1:M association exists between tables, the primary key of the 1 side is embedded in the table of
the M side.

Keys in M:M Associations

Tables in an M:M association cannot accept an embedded foreign key from the related table. Instead,
the database designer must create a separate link table to contain the foreign keys.

Normalized Tables
Recall that improperly normalized tables exhibit negative operational symptoms called anomalies,
including the update anomaly, the insertion anomaly, and the deletion anomaly. One or more of these
anomalies will exist in tables that are not normalized to the third normal form (3NF) level. These
anomalies are caused by structural problems within tables known as repeating groups, partial
dependencies, and transitive dependencies. Normalization involves systematically identifying and
removing these dependencies from the table(s) under review. Tables in 3NF will be free of anomalies
and will meet two conditions:
1. All nonkey attributes will be wholly and uniquely dependent on (defined by) the primary key.

2. None of the nonkey attributes will be dependent on (defined by) other nonkey attributes.

3. Construct the physical database and produce user views.

Producing Financial Statements and Other Accounting Reports

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.

PRODUCING MANAGEMENT REPORTS FROM REA TABLES.

A key objective of REA is to create a database capable of supporting multiple user views.

REA AND VALUE CHAIN ANALYSIS

value chain 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.

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.
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, high-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.
Pendekatan REA untuk Pemodelan Basis Data

MODEL REA

gambar

Elemen Model REA

SUMBER DAYA. Sumber daya ekonomi adalah hal-hal yang bernilai ekonomis bagi organisasi. Mereka
didefinisikan sebagai objek yang langka dan berada di bawah kendali perusahaan. Sumber daya
digunakan dalam pertukaran ekonomi dengan mitra dagang dan ditingkatkan atau dikurangi oleh
pertukaran.

ACARA

Peristiwa ekonomi adalah fenomena yang mempengaruhi perubahan (peningkatan atau penurunan)
sumber daya yang diwakili oleh hubungan aliran stok pada Gambar 10-1. Peristiwa ekonomi adalah
fenomena yang mempengaruhi perubahan (peningkatan atau penurunan) sumber daya yang diwakili
oleh hubungan aliran stok pada Gambar 10-1.

Peristiwa pendukung (tidak diperlihatkan dalam Gambar 10-1) mencakup kegiatan pengendalian,
perencanaan, dan pengelolaan yang terkait dengan peristiwa ekonomi tetapi tidak secara langsung
mempengaruhi perubahan sumber daya.

AGEN. Agen ekonomi adalah individu dan departemen yang berpartisipasi dalam acara ekonomi dan
dukungan. Setiap peristiwa ekonomi dikaitkan dengan setidaknya satu agen internal dan satu agen
eksternal yang berpartisipasi dalam pertukaran.

DUALITAS.

gambar
Mengembangkan Model REA

PERBEDAAN ANTARA DIAGRAM ER DAN REA

Diagram ER dan REA berbeda secara visual secara signifikan. Entitas dalam diagram ER adalah satu kelas,
dan kedekatannya dengan entitas lain ditentukan oleh kardinalitasnya dan oleh apa yang
menyenangkan secara visual untuk membuat diagram tetap dapat dibaca. Entitas dalam diagram REA,
bagaimanapun, dibagi menjadi tiga kelas (sumber daya, peristiwa, dan agen) dan diatur ke dalam
konstelasi berdasarkan kelas pada diagram.

gambar

Perbedaan kedua antara diagram ER dan REA melibatkan urutan kejadian. Diagram ER menyajikan
gambaran statis dari fenomena bisnis yang mendasarinya. Hubungan antar data ditunjukkan melalui
kardinalitas dan asosiasi, tetapi urutan aktivitas yang menentukan kardinalitas dan asosiasi tidak
terwakili dengan jelas. Diagram REA, bagaimanapun, biasanya diatur dari atas ke bawah dalam
konstelasi untuk fokus pada urutan peristiwa. Keuntungan dari ini adalah bahwa selama pengembangan
sistem, manajemen dan pengguna non-teknis lebih memahami diagram REA.

Perbedaan ketiga antara diagram ER dan REA berkaitan dengan konvensi penamaan untuk entitas.
Dalam diagram ER, nama entitas selalu direpresentasikan dalam bentuk kata benda tunggal. Pemodelan
REA menerapkan aturan ini saat menetapkan nama ke entitas sumber daya dan agen.

LIHAT PEMODELAN: MENCIPTAKAN DIAGRAM REA INDIVIDU

Bagian ini menjelaskan proses pemodelan tampilan yang diterapkan untuk membuat diagram REA.
Prosesnya melibatkan langkah-langkah berikut:

1. Identifikasi entitas acara.

VERIFIKASI KETERSEDIAAN

Terima pesanan.

PRODUK KAPAL.

MENERIMA UANG TUNAI.

JENIS ENTITAS TIDAK VALID.

2. Identifikasi entitas sumber daya.

Setiap peristiwa ekonomi dalam model REA harus dikaitkan dengan setidaknya satu entitas sumber daya
yang nilai ekonominya akan berkurang atau meningkat oleh peristiwa tersebut. Peristiwa dukungan juga
terkait dengan sumber daya tetapi tidak mempengaruhi perubahan nilai sumber daya.

3. Identifikasi entitas agen.

Setiap entitas peristiwa ekonomi dalam diagram REA dikaitkan dengan setidaknya dua entitas agen.
Salah satunya adalah agen internal dan yang lainnya adalah agen eksternal. Agen eksternal yang terkait
dengan keempat peristiwa dalam kasus Apex adalah Pelanggan. Selain itu, empat agen internal terkait
dengan empat peristiwa:

1. Petugas layanan pelanggan, yang berpartisipasi dalam acara Verifikasi Ketersediaan.

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

3. Petugas pengiriman yang mengikuti event Ship Product.

4. Petugas penerimaan kas yang mengikuti acara Terima Kas.

4. Menentukan asosiasi dan kardinalitas antar entitas.

Asosiasi adalah sifat hubungan antara dua entitas, seperti yang diwakili oleh garis berlabel yang
menghubungkannya. Kardinalitas (derajat asosiasi antar entitas) menggambarkan jumlah kemungkinan
kejadian dalam satu entitas yang terkait dengan satu kejadian dalam entitas terkait. Empat bentuk dasar
kardinalitas dimungkinkan: nol atau satu (0, 1), satu dan hanya satu (1,1), nol atau banyak (0,M), dan
satu atau banyak (1,M).

KARDINALITAS ANTARA ENTITAS VERIFIKASI KETERSEDIAAN DAN TAKE ORDER.

Setiap kemunculan entitas Verifikasi Ketersediaan adalah hasil dari pertanyaan pelanggan.

KARDINALITAS ANTARA BADAN PEMESANAN DAN PENGIRIMAN PRODUK.

Kardinalitas 0,1 di sisi Produk Kapal dari relasi mencerminkan perbedaan waktu antara pesanan yang
diambil dan dikirim.

KARDINALITAS ANTARA PRODUK KAPAL DAN BADAN MENERIMA UANG.

Ketentuan perdagangan dan kebijakan pembayaran bisnis sangat bervariasi. Perusahaan yang
melakukan penjualan kredit kepada konsumen sering kali menerima pembayaran sebagian dari waktu
ke waktu. Ini akan menghasilkan banyak kejadian penerimaan kas untuk satu kejadian pengiriman.

KARDINALITAS ANTARA BADAN KAS DAN MENERIMA KAS.

Sumber daya kas organisasi terdiri dari beberapa akun yang berbeda, seperti akun operasi umum, akun
imprest penggajian, dan kas kecil.
ASOSIASI BANYAK KE BANYAK.

Yang pertama adalah antara entitas Verifikasi Ketersediaan dan Inventaris. Kardinalitas 1,M ada di ujung
Inventaris asosiasi, dan kardinalitas 0,M terletak di ujung Verifikasi Ketersediaan.

Lihat Integrasi: Membuat Model REA Seluruh Perusahaan

Proses pemodelan tampilan yang dijelaskan di bagian sebelumnya menghasilkan model REA individu
dari siklus pendapatan untuk Pasokan Apex. Bagian ini menjelaskan bagaimana beberapa diagram REA,
masing-masing dibuat dalam proses pemodelan tampilannya sendiri, diintegrasikan ke dalam satu model
global atau perusahaan.

Bagian ini kemudian menjelaskan bagaimana model perusahaan diimplementasikan ke dalam database
relasional dan pandangan pengguna dibangun. Proses integrasi tampilan melibatkan tiga langkah dasar:

1. Konsolidasikan model individu.

Prosedur Pembelian dan Pengeluaran Tunai

gambar

Prosedur Penggajian

gambar

Gabungkan Diagram REA Individu

Dengan membalik diagram siklus pengeluaran untuk membuat efek bayangan cermin, sumber daya
umum Inventaris dan Uang Tunai dipusatkan di diagram

2. Tentukan kunci utama, kunci asing, dan atribut.

gambar

Ini akan membutuhkan 18 tabel, yang dijelaskan dalam paragraf berikut:

• Sepuluh agen internal yang ditunjukkan pada Gambar 10-12 akan diciutkan menjadi satu tabel
Karyawan.

• Dua agen eksternal (Pelanggan dan Pemasok) masing-masing akan membutuhkan tabel terpisah.

• Kedua sumber daya Inventarisasi dan Kas masing-masing akan membutuhkan sebuah tabel.
• Delapan acara akan membutuhkan tabel masing-masing.

• Lima relasi M:M yang direpresentasikan dalam diagram masing-masing akan membutuhkan tabel
penghubung.

Aturan untuk Kunci Utama dan Atribut

Penentuan kunci dan atribut utama berasal dari pemahaman tentang tujuan setiap tabel, yang
dihasilkan dari analisis kebutuhan pengguna yang terperinci. Perancang database harus memilih kunci
utama yang secara logis dan unik mendefinisikan atribut bukan kunci dalam tabel.

Aturan untuk Kunci Asing

Tingkat asosiasi antara tabel (yaitu, 1:1, 1:M, dan M:M) menentukan bagaimana kunci asing ditetapkan.

Kunci dalam Asosiasi 1:1

Dalam asosiasi 1:1, satu sisi asosiasi biasanya memiliki kardinalitas minimum nol. Jika hal ini terjadi,
kunci utama tabel dengan kardinalitas 1,1 harus disematkan sebagai kunci asing dalam tabel dengan
kardinalitas 0,1.

Kunci dalam Asosiasi 1:M

Ketika asosiasi 1:M ada di antara tabel, kunci utama dari sisi 1 disematkan di tabel sisi M.

Kunci dalam Asosiasi M:M

Tabel dalam asosiasi M:M tidak dapat menerima kunci asing yang disematkan dari tabel terkait. Sebagai
gantinya, perancang database harus membuat tabel tautan terpisah untuk memuat kunci asing.

Tabel yang dinormalisasi

Ingatlah bahwa tabel yang dinormalisasi secara tidak benar menunjukkan gejala operasional negatif
yang disebut anomali, termasuk anomali pembaruan, anomali penyisipan, dan anomali penghapusan.
Satu atau lebih dari anomali ini akan ada dalam tabel yang tidak dinormalisasi ke tingkat bentuk normal
ketiga (3NF). Anomali ini disebabkan oleh masalah struktural dalam tabel yang dikenal sebagai grup
berulang, dependensi parsial, dan dependensi transitif. Normalisasi melibatkan pengidentifikasian dan
penghapusan dependensi ini secara sistematis dari tabel yang sedang ditinjau. Tabel di 3NF akan bebas
dari anomali dan akan memenuhi dua kondisi:

1. Semua atribut bukan kunci akan sepenuhnya dan secara unik bergantung pada (didefinisikan oleh)
kunci utama.

2. Tak satu pun dari atribut bukan kunci akan bergantung pada (didefinisikan oleh) atribut bukan kunci
lainnya.
3. Membangun database fisik dan menghasilkan tampilan pengguna.

Pembuatan Laporan Keuangan dan Laporan Akuntansi Lainnya

Total Penjualan: Jumlah atribut Invoice Amount di tabel Ship Product untuk semua item yang dikirim
pada atau sebelum tanggal penutupan akhir tahun.

Piutang Usaha: Total Penjualan dikurangi jumlah atribut Jumlah dari tabel Terima Kas untuk semua
pengiriman uang yang diterima pada atau sebelum tanggal penutupan akhir tahun.

Harga Pokok Penjualan: Jumlah Kuantitas yang terjual di tabel Inventory-Ship Link dikalikan dengan
atribut Unit Cost di tabel Inventory.

Inventory: Atribut Quantity on Hand dikalikan dengan atribut Unit Cost di tabel Inventory.

MENGHASILKAN LAPORAN MANAJEMEN DARI REA TABLES.

Tujuan utama REA adalah untuk membuat database yang mampu mendukung banyak tampilan
pengguna.

REA DAN ANALISIS RANTAI NILAI

analisis rantai nilai membedakan antara aktivitas utama dan aktivitas pendukung: aktivitas utama
menciptakan nilai; mendukung kegiatan membantu dalam pencapaian kegiatan utama. Dengan
menerapkan analisis rantai nilai, sebuah organisasi dapat melihat melampaui dirinya sendiri dan
memaksimalkan kemampuannya untuk menciptakan nilai, misalnya, dengan memasukkan kebutuhan
pelanggannya dalam produknya atau mengakomodasi fleksibilitas pemasoknya dalam menjadwalkan
produksinya.

Sebagai kerangka sistem informasi tunggal yang mampu menangkap data generik dan halus, REA dapat
mengatasi masalah ini dan mampu memberikan keuntungan sebagai berikut.

1. Pendekatan REA untuk memodelkan proses bisnis membantu manajer fokus pada elemen kunci dari
peristiwa ekonomi dan mengidentifikasi aktivitas tidak bernilai tambah yang dapat dihilangkan dari
operasi. Meningkatkan efisiensi operasional masing-masing departemen sehingga menghasilkan
kelebihan kapasitas yang dapat diarahkan untuk meningkatkan produktivitas perusahaan secara
keseluruhan.

2. Penyimpanan data keuangan dan non-keuangan dalam database umum mengurangi kebutuhan akan
beberapa prosedur pengumpulan, penyimpanan, dan pemeliharaan data.
3. Menyimpan data keuangan dan nonkeuangan tentang peristiwa bisnis dalam bentuk terperinci
memungkinkan pengambilan keputusan manajemen yang lebih luas dengan mendukung banyak
pandangan pengguna.

4. Model REA memberikan manajer informasi yang lebih relevan, tepat waktu, dan akurat. Ini akan
diterjemahkan ke dalam layanan pelanggan yang lebih baik, produk berkualitas tinggi, dan proses
produksi yang fleksibel.

REA KOMPROMI DALAM PRAKTEK

Keuntungan efisiensi operasional, integrasi sistem, dan analisis rantai nilai telah menarik perhatian besar
REA sebagai model teoritis untuk sistem dan desain database. Namun, sebagai masalah praktis,
organisasi yang lebih besar sering mengkompromikan model REA untuk tujuan pelaporan laporan
keuangan.

The REA model is an accounting framework for modeling an organization’s critical resources, events, and
agents and the relationships between them. Unlike some traditional accounting systems, REA systems
permit both accounting and nonaccounting data to be identified, captured, and stored in a centralized
database. From this repository, user views that meet the needs of all users in the organization can be
constructed. REA models may be implemented within either relational or object-oriented database
architectures. For purposes of discussion in this chapter, we will assume a relational database because
this is the more common architecture for business applications.

Model REA adalah kerangka kerja akuntansi untuk memodelkan sumber daya, peristiwa, dan agen
penting organisasi dan hubungan di antara mereka. Tidak seperti beberapa sistem akuntansi tradisional,
sistem REA mengizinkan data akuntansi dan non-akuntansi untuk diidentifikasi, ditangkap, dan disimpan
dalam database terpusat. Dari repositori ini, tampilan pengguna yang memenuhi kebutuhan semua
pengguna dalam organisasi dapat dibangun. Model REA dapat diimplementasikan dalam arsitektur
database relasional atau berorientasi objek. Untuk tujuan diskusi dalam bab ini, kita akan
mengasumsikan database relasional karena ini adalah arsitektur yang lebih umum untuk aplikasi bisnis.
Model REA adalah sebuah framework akuntansi untuk memodelkan resources, events, dan agents yang
penting dalam suatu organisasi dan membuat garis hubungan/keterkaitan diantara ketiganya. Tidak
seperti dalam sistem akuntansi tradisional, sistem REA membolehkan baik data akuntansi dan
nonakuntansi untuk diidentifikasi, diambil, dan disimpan dalam database yang terpusat. Dengan
database ini, tampilan/sudut-pandang pengguna bisa dibuat untuk memenuhi kebutuhan para
pengguna dalam organisasi tersebut. Model REA bisa diimplementasikan dalam arsitektur database
relasional maupun object-oriented.