Chapter 10

THE REA APPROACH TO

DATABASE MODELING

Presenters:
RUFO, Maricris Jenn
SUSTIGER, Estelle Faith
OBJECTIVES
• Recognize the economic foundations of the resources, events, and
agents (REA) model.
• Understand the key differences between traditional entity
relationship modeling and REA modeling.
• Understand the structure of an REA diagram.

• Be able to create an entity-wide REA diagram by applying the view

integration steps to a business
THE REA APPROACH
• The center of the database philosophy - recognition that corporate data should
support the information needs of all users in the organization.

• An important aspect of data modeling - faithful reflection of the organization’s

physical reality
THE REA APPROACH
• Modern managers need both financial and nonfinancial information in formats and at
levels of aggregation that the traditional GAAP-based accounting systems generally
fail to provide.
• The response to this dominant single view of accounting information - create
separate information systems to support each user’s view. This has resulted in
organizations with multiple information systems that are functionally disconnected.

• Such concerns have led database researchers to develop semantic models -

capturing the operational meaning of the user’s data and provides a concise
description of it.
• In 1982, REA was originally proposed as a theoretical framework for accounting - it
has gained considerable attention as a practical alternative to traditional accounting
systems
THE REA MODEL
• an accounting framework for modeling organization’s critical resources,
events, and agents and the relationships between them.
• permits both accounting and nonaccounting data to be identified, captured,
and stored in a centralized database.
• may be implemented within either relational or object-oriented database
architectures.

• it is a unique version of an entity relationship ( RE ) diagram.

• three entity types - resource, events, and agents and a set of
associations linking them.
ELEMENTS OF REA MODEL

RESOURCES
• are things of economic value to the organization.
• objects that ate both scarce and under the control of the enterprise.
• they are used in economic exchanges with trading partners and are either
increased or decreased by the exchange.
ELEMENTS OF REA MODEL

EVENTS - two classes of events : economic and support

Economic events
• are phenomena that effect changes (increases or decreases) in resources as
represented by the stock flow relation.
• they result from activities such as sales of products receipt of cash from
customers, and purchases of raw materials from vendor.
• these are critical information elements of the accounting system and must be
captured in as disaggregated form as possible to provide a rich database.

Support events
• include control, planning, and management activities that are related to
economic events, but do not directly effect a change in resources.
ELEMENTS OF REA MODEL
AGENTS
• are individuals and departments that participate in economic and support
events.
• parties that are both inside and outside the organization with discretionary
power to use or dispose economic resources.
• each economic event is associated with at least one internal agent and on
external agent who participate in the exchange.
• internal - employees
• external - customers
• they are also invloved in support events, but the exchange involves
information rather than economic resources.
DUALITY
REA’s semantic features derive from the elements of an economic transactions.
• Two agents each give the other a resource in exchange for another resource.
• In actuality, the exchange is a pair of economic events - each economic event is
mirrored by an associated economic
• event in the opposite direction.

Dual Events
• give event
• receive event

Organization’s function perspective

• give half of the exchange - decreases the economic resource, as represented by
the outflow association.
• receive half of the exchange - increases the economic resources represented by
an inflow association.
• An economic exchange does not require duality events to occur
simultaneously.
• REA model accommodates credit-based transactions and the associated time
lags, but does not employ traditional mechanisms such as AR or AP ledgers in
accounting for these events.
• In fact, REA rejects the need for any accounting artifacts, including journals,
ledgers, and double-entry bookkeeping.
• REA systems capture the essence of what accountants account for by
modeling the underlying economic phenomena directly.
• Organizations employing REA can thus produce financial statements, journals,
ledgers, and double-entry accounting reports directly from event database
tables via user views.
DEVELOPING A REA MODEL
• The REA approach uses semantic modeling to construct a REA diagram, which
in some ways is similar to an ER diagram, but in other respects is quite
different.

DIFFERENCES BETWEEN ER AND REA DIAGRAMS

• they differ visually in a significant way.

Entities in ER diagrams
• one of a 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 REA diagram

• divided into three classes (resources, events, and agents) and organized into
constellations by class on the diagram.
DIFFERENCES BETWEEN ER AND REA DIAGRAMS
• second difference - 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
• typically organized from top to bottom within the constellations to focus on
the sequence of events.
• advantage - during systems development, management and nontechnical
users better understand REA diagrams.
DIFFERENCES BETWEEN ER AND REA DIAGRAMS
• third difference - ER and REA diagrams pertain to naming conventions for
entities.

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.
• Event entities
• are given verb (action) names such as Sell inventory, Take order, and Receive
cash.
• represent and describe database tables that will store data processes, but the
are not representing or describing the process themselves.
VIEW MODELING: CREATING AN INDIVIDUAL REA
DIAGRAM
This section describes the view modeling processes as applied to creating a REA
diagram. The process involves the following steps:
1. Identify the event entities.
2. Identify the resource entities.
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 where individual models are consolidated into a
single model.
• To illustrate REA view modeling, we will use a simplified description of a revenue
cycle process. Following are its key features:
VIEW MODELING: CREATING AN INDIVIDUAL REA
DIAGRAM
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.
Step 1. Identify the Event Entities
• Is to identify the event entities in the function being modeled.
• A minimum of two economic events: give and receive activities - reduce and
increase economic resources in the exchange.
• It may include support events, which do not change resources directly.

VERIFY AVAILABILITY. It 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.

TAKE ORDER. Depending on the circumstances, Take order could be either an

economic or support event. It 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.
However, it does not cause a real decrease in inventory and is not an economic
exchange.
Step 1. Identify the Event Entities
SHIP PRODUCT. It is an economic event. This is the give half of an economic
exchange and reduces the inventory resource directly.

RECEIVE CASH. It 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.

• Value Chain. These are the activities that use cash to obtain resources, including
equipment, materials, and labor and then employ those resources to earn new
revenues. These are invalid types and should not be included in a REA diagram.
• A fundamental precept of REA is the rejection of accounting artifacts (journals,
ledgers, and double-entry bookkeeping.
Step 2. Identify the Resource Entities

• The next step is to identify the resources that are impacted by the events
selected to be modeled.
• Each economic event must be linked to at least one resource entity whose
economic value will be either reduced or increased by the event.
• Support event are also related to resources but do not effect a change in the
resource value.

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.
Step 3. Identify the Agent Entities

• Each economic event in an entity in a REA diagram is associated with at least two
agent entities: internal agent and 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 (participates in the Verify Availability event).
2. The sales representative (participates in the Take Order event).
3.The shipping clerk (participates in the Ship Product event).
4. The cash receipts clerk (participates in the Receive Cash event).

Note: 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
as a seperate entity.
Step 4. Determine Associations and Cardinalities between Entities

• Association is the nature of the relationships 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 one only (1,1),
zero or many (0, M), and one or many (1,M).

CARDINALITY BETWEEN THE VERIFY AVAILABILITY AND TAKE ORDER.

Each occurrence of the Verify Availability entity is the result of a customer inquiry.
From the case description, however, that not all inquiries result in a customer order.
The cardinality on the Take Order side of the relation, therefore is 0,1. On the Verify
Availability side, it is 1,1.
Step 4. Determine Associations and Cardinalities between Entities

CARDINALITY BETWEEN THE TAKE ORDER AND SHIP PRODUCTS 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 SHIP PRODUCTS AND RECEIVE CASH ENTITIES.

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.
CARDINALITY BETWEEN THE CASH AND RECEIVE CASH ENTITIES.
The cash resource of an organization is composed of several different accounts.
These are consolidated for financial reporting into a single account, but are used to
track 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.
Figure 10-8 depicts examples of M:M associations.

First, 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.
MANY-TO-MANY ASSOCIATIONS.
Figure 10-8 depicts examples of M:M associations.

Second, 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.

Similar situation between the Ship Goods and Inventory entities. 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 must be reconciled.
 • When modeling a traditional ER diagrams, it is often convenient to include the
link tables in the model so that it reflects closely the actual database.
• 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. 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
• It explains how multiple REA diagrams, each created in its own view modeling
process, are integrated into a single global or enterprise model.
• It 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
Purchases and Cash Disbursement Procedures
• 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 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.
Step 1. CONSOLIDATE THE INDIVIDUAL MODELS
Purchases and Cash Disbursement Procedures
• 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.

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.
Step 1. CONSOLIDATE THE INDIVIDUAL MODELS
Purchases and Cash Disbursement Procedures
• Second event entity - Receive Product. An economic event that causes a change
in an economic resource.
• This is the receive half of the exchange and increases the inventory. Goods are
received from the supplier and the receiving clerk processes them.

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).
 Step 1. CONSOLIDATE THE INDIVIDUAL MODELS

Purchases and Cash Disbursement Procedures

• Third event - Disburse Cash. An economic event that constitutes the give of an
economic exchange. It causes the Cash resource to be descreased.
The 1:M association with the Supplier entity implies that each disbursement is made
to only one supplier, but each supplier may receive zero or many disbursements
during the period.

The 1:M association between Disburse Cash and Receive Product implies that each
product receipt is paid in full (no multiple partial payments), but many receipts may
be combined and paid with a single disbursement to reduce check writing.

The M:M associations that exist between the Order Product and Inventory entities and
between the Receive Product and Inventory entities.
Step 1. CONSOLIDATE THE INDIVIDUAL MODELS

Payroll Procedures
• The model consists of only two economic events: Get Time and Disburse Cash.
The Get Time event is the receive half of the economic exchange.
• Involves a worker (internal agent) giving up his or her time, which is represented
by the Employee Services resource.
• The supervisor (external agent) assumes control of the resource.
Step 1. CONSOLIDATE THE INDIVIDUAL MODELS

Payroll Procedures
• The model consists of only two economic events: Get Time and Disburse Cash.
The Disburse Cash event is the give half of the economic exchange.
• Involves distributing cash to an employee (now the external agent) for services
rendered.
• The payroll clerk (internal agent) participates in this event, which reduces the
cash resource.
Merge Individual REA Diagram
• Single enterprise-wide diagram.
By flipping the expenditure cycle diagrams to create a mirror image effect, the
common resources of Inventory and Cash are centered in the diagram. These
are flanked by two constellations of events, which increase and decrease them.
The agents form periphery constellations in the diagram.
• To simplify the diagram, redundant event, agent, and resource entities have
been collapsed into a single entity where possible.
• To maintain perspective as to the roles played by internal agents, they are
depicted as individual entities rather than collectively.
• To avoid crossing association lines between entities.
 Step 2. DEFINE PRIMARY KEYS, FOREIGN KEYS, AND ATTRIBUTES
Design the Relational database tablets
• 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. 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
• 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.
• 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.
• Each attribute assigned to a table should, however, appear directly or
indirectly (a calculated value) in one or more user views.
RULES FOR FOREIGN KEYS
• The degree of association between tablets (that is, 1:1, 1:M, or M:M)
determines how foreign keys are assigned.

KEYS 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.
• 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.

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.
KEYS IN M:M ASSOCIATION
• 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
• The assignment of primary keys and attributes to relational tables must
always comply with the rules of normalization.
• Improperly normalized tables exhibit negative operational symptoms
called anomalies (update, insertion, 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.
• Are caused by structural problems within tables known as repeating groups,
partial dependencies, and transitive dependencies.
Normalization involves systematically identifying and removing the 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 the primary
key.
2. None of the nonkey attributes will be dependent on other nonkey attributes.

Databases are not static. As user needs change and additional user views are
developed, additional attributes and perhaps additional tables may need to be
included in the database. It must be followed with normalization rules to preserve
the structural integrity of tables and avoid anomalies.
 Step 3. CONSTRUCT PHYSICAL DATABASE AND PRODUCE USER VIEWS
At this point, create the Physical Relational tables
• Resource and agent tables must be initialized with data values such as inventory
quantities on hand, customer names and addresses, and employee data.
The new system will start operations with beginning values for the attributes of these
tables.
 PRODUCING FINANCIAL STATEMENTS AND OTHER ACCOUNTING
REPORTS
Traditional system financial statements
• prepared from general ledgers, derived from journal voucher postings
• journals, ledgers, and double-entry accounting

REA model
• traditional accounting mechanisms are reproduced from event tables.

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.
 PRODUCING MANAGEMENT REPORTS FROM REA TABLES

Key objective of REA - create database capable of supporting multiple user views.
 REA AND VALUE CHAIN ANALYSIS
The competitive advantages to organizations that adopt the REA approach are
clearly seen from the perspective of the value chain.
• These are activities that add value or usefulness to an organization’s products
and services.

Value Chain Analysis

It distinguishes between primary activities and support activities:
• primary activities - create value
• support activties - assist in the achievement of the primary activities
REA AND VALUE CHAIN ANALYSIS
• Traditional information systems are not well suited to supporting value chain
activities.
• 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.
2. The 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 AND VALUE CHAIN ANALYSIS
• Traditional information systems are not well suited to supporting value
chain activities.
• 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.
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.
• Larger organizations often compromise the REA model for financial statement
reporting purposes.
• Although it is possible to extract traditional financial information from event
data, doing so from millions of individual event records can be problematic.
• Instead, most companies implementing a 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.
THANK YOU!