CHAPTER 10: THE REA APPROACH TO BUSINESS PROCESS AND MODELLING

Traditional Approaches:

User-View Orientation

When data-modeling and IS design is too oriented toward the user’s views, the following problems
arise:

a. multiple information systems

b. duplication of data
c. restricted user-view leads to poor decision-making
d. inability to support change

RESOURCES, EVENTS, AND AGENTS MODEL

REA is an approach to database design meant to overcome problems with traditional approaches:

1. formalized data modeling and design of IS

2. use of centralized database
3. use of relational database structure
4. collects detailed financial and non-financial data
5. supports accounting and non-accounting analysis
6. supports multiple user views
7. supports enterprise-wide planning

FEATURES OF THE REA MODEL

REA models consists of three entity types and the associations linking them. These are: resources,
events and agents

1. 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 which can be tangible or intangible.

This does not include some traditional accounting assets such as artifacts that can be generated from
other primary data (for example, accounts receivables)

Events in the REA Model

2. Events are phenomena that effect changes in resources. It is a source of detailed data in the REA
approach to databases.
Events fall into two groups:

1. Economic – increases or decreases resources

2. Support – control, planning, and other management activities; but do not directly affect
resources

Agents in the REA Model

3. Agents can be individuals or departments. They participate in events and affect resources.
Agents have discretionary power to use or dispose of resources and can be inside or outside the
organization.

Examples: Clerks, Production workers, Customers, Suppliers, vendors, Departments, teams

Economic Resource - Another key feature of the REA model is economic duality. Events occur in pairs
and represent the give event and receive event of an economic exchange.

ER DIAGRAMS (ERD’S) VERSUS REA DIAGRAMS (READ’S)

In terms of classes of entities:

 ERD’s – one class

 READ’s – three classes (resources, events, and agents)

In 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 in view modeling are:

1. identify the event entities to be modeled

2. identify the resource entities changed by events
3. identify the agent entities participating in events
4. determine associations and cardinalities between entities

Step 1: Identify the Event Entities

This steps involves the following activities:

 Identify the events that are to be included in the model

- This may include at least two economic events (duality) and may include support events.
Events are also arranged in chronological sequence.
 Focus on value chain events
 Do not such invalid events such as bookkeeping tasks, accounting artifacts, e.g., accounts
receivable

Arrangement of Events Entities in Order of Occurrence

1. Verify Availability
2. Take order
3. Ship product
4. Receive cash

Step 2. Identify the Resource Entities

This steps involves the following activities:

 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
and 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 and one external agent.
 It is possible to have only an internal agent when no exchange occurs, as with certain ‘internal’
manufacturing processes.
Step 4. Determine Associations and Cardinalities between Entities

Association reflects the nature of the relationship between two entities and is represented by the
labeled line connecting the entities. Cardinality, on the other hand pertains to the degree of association
between the entities. It 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.

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 splits the M:M association into two 1:M associations.

- The linking table requires a ‘composite primary key’

VIEW INTEGRATION: CREATING AN ENTERPRISE-WIDE REA MODEL

View integration refers to the process of 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.

Step 2. Define Primary Keys, Foreign Keys, and Attributes

Implementation into a working relational database requires primary keys, foreign keys and attributes in
tables.
 a) Primary key – uniquely identifies an instance of an entity (i.e., each row in the table)
b) Foreign key – the primary key embedded in the related table so that the two tables can be
linked
c) Attribute – a characteristic of the entity to be recorded in the table

RULES FOR FOREIGN KEYS

Primary key to 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 credit rating

- Customer address - Damaged goods record
- Customer telephone number - On-time payment record
- Amount owed by customer - Customer volume record
- Value of total sales to date - EDI access
- Terms of trade offered - Internet access

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

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.

1. It helps managers identify non-value added activities that can be eliminated. This is done by
increasing productivity via elimination of non-value added activities generates excess capacity
2. Storing both financial and nonfinancial data in the same central database reduces multiple data
collection, data storage, and maintenance.
3. 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)
4. Provides managers with more relevant, timely, and accurate information leading to better
customer service, higher-quality products, and flexible production processes.