Chapter 10

The REA Approach to Business

Process Modeling

Traditional Approaches: User-View Orientation

 When data-modeling and IS design is too oriented
toward the user’s views, problems arise:
 multiple information systems
 duplication of data
 restricted user-view leads to poor decision-
making
 inability to support change

Resources, Events, and Agents Model

 REA is an approach to database design meant to
overcome problems with traditional approaches:
 formalized data modeling and design of IS
 use of centralized database
 use of relational database structure
 collects detailed financial and non-financial
data
 supports accounting and non-accounting
analysis
 supports multiple user views
 supports enterprise-wide planning
  REA models consists of three entity types and the
associations linking them.
 Resources
 Events
 Agents

Resources in the REA Model

 Resources – the ‘assets’ of the company
 things of economic value
 objects of economic exchanges able to
generate revenue
 objects that are scarce and under the control
of the organization
 can be tangible or intangible
 Does not include some traditional accounting assets:
 artifacts that can be generated from other
primary data
 for example, accounts receivables

Events in the REA Model

 Events are phenomena that effect changes in
resources.
 a source of detailed data in the REA
approach to databases
 Events fall into two groups:
 Economic – increases or decreases resources
 Support – control, planning, and other
management activities; but do not directly
affect resources
Agents in the REA Model
 Agents can be individuals or departments.
 Participate in events
 Affect resources
 Have discretionary power to use or dispose
of resources
 Can be inside or outside the organization
 Clerks
 Production workers
 Customers
 Suppliers, vendors
 Departments, teams

Basic REA Model

 Another key feature of the REA model is economic

duality.
 Events occur in pairs
 Represent the give event and receive event of
an economic exchange
REA Model showing Duality of a Give and Receive
Exchange

ER Diagrams (ERD’s) versus REA Diagrams (READ’s)

 Classes of entities
 ERD’s – one class
 READ’s – three classes (resources, events,
and agents)
 Arrangement of entities
 ERD’s – determined by cardinality and
readability
 READ’s – organized into constellations by
class
 Sequencing of events
 ERD’s – static
 READ’s – chronological sequence of
business processes
  Naming conventions
 ERD’s – all nouns
 READ’s – nouns (R’s and A’s) and verbs
(E’s)
View Modeling: Creating an Individual REA Diagram
 View modeling is a multistep process for creating an
individual REA model.
 The result is a single view of the entire
database.
 The four steps involved are:
 Identify the event entities to be modeled.
 Identify the resource entities changed by
events.
 Identify the agent entities participating in
events.
 Determine associations and cardinalities
between entities.
Step 1: Identify the Event Entities
 Identify the events that are to be included in the
model.
 Include at least two economic events
(duality)
 May include support events
 Arrange events in chronological sequence
 Focus on value chain events.
 Do not include invalid events such as:
 bookkeeping tasks
 accounting artifacts, e.g., accounts receivable
Arrangement of Events Entities in Order of Occurrence
Step 2. Identify the Resource Entities
 Identify the resources impacted by events identified
in step 1.
 Each event must be linked to at least one resource.
 Economic events directly affect resources.
 Support events indirectly affect them.
Step 3. Identify the Agent Entities
 Each economic event entity in an REA diagram is
associated with at least two agent entities.
 One internal agent
 One external agent
 It is possible to have only an internal agent when no
exchange occurs, as with certain ‘internal’
manufacturing processes.

REA Model Showing Events and Related Resources and

Agents
Step 4. Determine Associations and Cardinalities
between Entities
 Association – reflects the nature of the relationship
between two entities
 Represented by the labeled line connecting
the entities
 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
 Cardinality reflects the business rules that are in play
for a particular organization.
 Sometimes the rules are obvious and are the
same for all organizations.
 Sometimes the rules differ, e.g., whether
inventory items are tracked individually or as
quantity on hand.
Associations and Cardinality in REA Diagram

Many-to-Many Associations
 Many-to-many (M:M) associations cannot be directly
implemented into relational databases.
 They require the creation of a new linking table.
 This process splits the M:M association into
two 1:M associations.
 The linking table requires a ‘composite
primary key’.
Link Tables in an REA Diagram

View Integration: Creating an Enterprise-Wide REA

Model
 View integration – combining several individual REA
diagrams into a single enterprise-wide model
 The three steps involved in view integration are:
1. Consolidate the individual models.
2. Define primary keys, foreign keys, and
attributes.
3. Construct physical database and produce
user views.
Step 1. Consolidate the Individual Models
 Merging multiple REA models requires first a
thorough understanding of the business processes
and entities involved in the models.
 Individual models are consolidated or linked together
based on shared entities.
 For example, procurement (expenditures)
and sales (revenue) both use inventory and
cash resource entities.
Integrated REA Diagram

Step 2. Define Primary Keys, Foreign Keys, and

Attributes
 Implementation into a working relational database
requires primary keys, foreign keys and attributes in
tables.
 Primary key – uniquely identifies an instance
of an entity (i.e., each row in the table)
 Foreign key – the primary key embedded in the
related table so that the two tables can be
linked
 Attribute – a characteristic of the entity to be
recorded in the table
Rules for Foreign Keys
 Primary key  Foreign key: Relations are formed
by an attribute that is common to both tables in the
relation.
 Assignment of foreign keys:
 if 1 to 1 (1:1) association, either of the table’s
primary key may be the foreign key
 if 1 to many (1:m) association, the primary key
on one of the sides is embedded as the
foreign key on the other side
 if many to many (m:m) association, create a
separate linking table with a composite
primary key

Attributes
Using the customer as an example, these data include:
Financial Nonfinancial
Customer name Customer Customer credit rating
address
Damaged goods record
Customer telephone
number On-time payment record

Amount owed by Customer volume record

customer EDI access
Value of total sales to date Internet access
Terms of trade offered
Step 3. Construct Physical Database and Produce User
Views
 The database designer is now ready to create the
physical relational tables using software.
 Once the tables have been constructed, some of them
must be populated with data.
 Resource and Agent tables
 Event tables must wait for business transactions to
occur before data can be entered.
 The resulting database should support the
information needs of all users.
 SQL is used to generate reports, computer
screens, and documents for users.

User-Views
Value Chain Analysis
 Competitive advantages from the REA approach can be
see via value chain analysis.
 Value chain analysis distinguishes between
primary activities (create value) and support
activities (assist performing primary activities).
 REA provides a model for identifying and
differentiating between these activities.
 Prioritizing Strategy: Focus on primary activities;
eliminate or outsource support activities.

Competitive Advantages of the REA Model

 Using REA can lead to more efficient operations.
 Helps managers identify non-value added
activities that can be eliminated

• Increasing productivity via elimination

of non-value added activities generates
excess capacity
 Storing both financial and nonfinancial data in
the same central database reduces multiple data
collection, data storage, and maintenance.
 Using REA can lead to more efficient operations.
 Detailed financial and nonfinancial business data
supports a wider range of management decisions

• supporting multiple user views (e.g.,

different perspectives on a problem)
 Provides managers with more relevant, timely,
and accurate information.

• leading to better customer service,

higher-quality products, and flexible
production processes