Chapter 10 Elemental REA Model
The REA Approach to Business Process Modeling
Objectives for Chapter 10
Economic foundations of the REA model
Key differences between traditional ER modeling and REA
modeling
The structure of an REA diagram
Create an REA diagram by applying the view modeling steps to
a business case
Create an entity-wide REA diagram by applying the view Resources, Events, and Agents Model
integration steps to a business case Another key feature of the REA model is economic duality.
Events occur in pairs
Traditional Approaches:User-View Orientation Represent the give event and receive event of an
When data-modeling and IS design is too oriented toward the economic exchange
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
Resources, Events, and Agents Model
REA models consists of three entity types and the associations
linking them.
Resources
Events ER Diagrams (ERD’s) versus REA Diagrams (READ’s)
Agents Classes of entities
ERD’s – one class
Resources in the REA Model READ’s – three classes (resources, events, and agents)
Resources – the ‘assets’ of the company Arrangement of entities
things of economic value ERD’s – determined by cardinality and readability
objects of economic exchanges able to generate revenue READ’s – organized into constellations by class
objects that are scarce and under the control of the Sequencing of events
organization ERD’s – static
can be tangible or intangible READ’s – chronological sequence of business processes
Does not include some traditional accounting assets: Naming conventions
artifacts that can be generated from other primary data ERD’s – all nouns
for example, accounts receivables READ’s – nouns (R’s and A’s) and verbs (E’s)
Events in the REA Model View Modeling: Creating an Individual REA Diagram
Events are phenomena that effect changes in resources. View modeling is a multistep process for creating an
a source of detailed data in the REA approach to individual REA model.
databases The result is a single view of the entire database.
Events fall into two groups: The four steps involved are:
Economic – increases or decreases resources 1. identify the event entities to be modeled
Support – control, planning, and other management 2. identify the resource entities changed by events
activities; but do not directly affect resources 3. identify the agent entities participating in events
4. determine associations and cardinalities between entities
Agents in the REA Model
Agents can be individuals or departments. Step 1: Identify the Event Entities
Participate in events Identify the events that are to be included in the model
Affect resources Include at least two economic events (duality)
Have discretionary power to use or dispose of resources May include support events
Can be inside or outside the organization Arrange events in chronological sequence
Clerks Focus on value chain events
Production workers Do not such invalid events such as:
Customers bookkeeping tasks
Suppliers, vendors accounting artifacts, e.g., accounts receivable
Departments, teams
Arrangement of Events Entities in Order of Occurrence are tracked individually or as quantity on hand.
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 Many-to-Many Associations
Each economic event entity in an REA diagram is associated Many-to-many (M:M) associations cannot be directly
with at least two agent entities. implemented into relational databases.
One internal agent They require the creation of a new linking table.
One external agent This process splits the M:M association into two 1:M
It is possible to have only an internal agent when no associations.
exchange occurs, as with certain ‘internal’ manufacturing The linking table requires a ‘composite primary key’.
processes.
View Integration: Creating an Enterprise-Wide REA Model
View integration – combining several individual REA
Step 4. Determine Associations and Cardinalities between diagrams into a single enterprise-wide model
Entities The three steps involved in view integration are:
Association – reflects the nature of the relationship between 1. consolidate the individual models
two entities 2. define primary keys, foreign keys, and attributes
Represented by the labeled line connecting the entities 3. construct physical database and produce user views
Cardinality – the degree of association between the entities
Describes the number of possible occurrences in one Step 1. Consolidate the Individual Models
entity that are associated with a single occurrence in a Merging multiple REA models requires first a thorough
related entity understanding of the business processes and entities involved
Cardinality reflects the business rules that are in play for a in the models.
particular organization. Individual models are consolidated or linked together based
Sometimes the rules are obvious and are the same for all on shared entities.
organizations. For example, procurement (expenditures) and sales
Sometimes the rules differ, e.g., whether inventory items (revenue) both use inventory and cash resource entities.
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.
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.
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 toForeign 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 Competitive Advantages of the REA Model
if 1 to many (1:m) association, the primary key on one of Using REA can lead to more efficient operations.
the sides is embedded as the foreign key on the other side Helps managers identify non-value added activities that
if many to many (m:m) association, create a separate can be eliminated
linking table with a composite primary key Increasing productivity via elimination of non-value added
Attributes 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
Step 3. Construct Physical Database and Produce User Views
The database designer is now ready to create the physical