Chapter 10 The REA Approach to Business Process Modeling

Hall, Accounting Information Systems, 7e

©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.

Accounting Information Systems, 7eJames A. Hall

Chapter 10The REA Approach to

Business Process Modeling

1

Hall, Accounting Information Systems, 7e©2011 Cengage Learning. All Rights Reserved. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part.

Objectives for Chapter 10 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 REA diagram by applying

the view modeling steps to a business case. Be able to create an entity-wide REA diagram by

applying the view integration steps to a business case.

2


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

3


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

4


Resources, Events, and Agents Model

REA models consists of three entity types and the associations linking them. Resources Events Agents

5


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

6


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

7


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

8


EconomicResource

Economic Event

External EconomicAgent

Internal EconomicAgent

Stock Flow

Duality

Participates

Participates

Basic REA Model

9

Figure 10-1


Resources, Events, and Agents 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

10


Resource AGive EconomicEvent

External Agent

Internal Agent

Out Flow

Duality

Inflow Receive EconomicEvent

External Agent

Internal Agent

Resource B

Participates

Give Activity

Receive Activity

Participates

Participates

Participates

REA Model showing Duality of a Give and Receive Exchange

11

Figure 10-2


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)

12


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

13


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

14


Take Order

Receive Cash

Verify Availability

Ship Product

Arrangement of Events Entities in Order of Occurrence

Order of Events

Events

15

Figure 10-5


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.

16


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.

17


18

REA Model Showing Events and Related Resources and Agents

Figure 10-6


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


Associations and Cardinality in REA Diagram

20Figure 10-8


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’.21


22

Link Tables in an REA Diagram

Figure 10-9


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


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.

24


Integrated REA Diagram

25

Figure 10-12


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

26


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

27


Attributes

28

Financial Customer name Customer address Customer telephone numberAmount owed by customerValue of total sales to dateTerms of trade offered

NonfinancialCustomer credit ratingDamaged goods recordOn-time payment recordCustomer volume recordEDI accessInternet access

Using the customer as an example, these data include:


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.

29


User-Views

30

User-View #1

Past Due AccountsName AmountJames $500.00Henry $100.00 … …

Sales Report

User-View #2

REA Database


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.

31


Competitive Advantages of theREA 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.

32


Competitive Advantages of the REA Model

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 processes33

Chapter 10 The REA Approach to Business Process Modeling

Documents

Transcript of Chapter 10 The REA Approach to Business Process Modeling