1. The REA Data Model Resources Events Agents Based on:
©2003 Prentice Hall Business Publishing,
Accounting Information Systems, 9/e, Romney/Steinbart

2. Chapter 5: Data Modeling and Database Design
3/31/2017
The REA Data Model
The REA data model is a conceptual modeling tool specifically designed to provide structure for designing AIS data bases.
Dr. Fred Barbee

3. Chapter 5: Data Modeling and Database Design
3/31/2017
The REA Data Model
The REA data model provides structure in two ways:
By identifying what entities should be included in the AIS database
By prescribing how to structure relationships among the entities in the AIS database
Dr. Fred Barbee

4. Business Activities Business transactions are exchanges.
Who “gets” what and who “gives” what in return are separate transactions.
The exchange occurs between the business entity and usually an outside agent.
The business gives something and then gets something in return.

5. Resources, Events, and Agents
Every business transaction is made up of three components:
Resources are the things of economic value exchanged.
Events are the actual giving and getting of the resources.
Agents are the people who actually make the exchange.

6. Steps and Documents in the Acquisition/Payment Process
(as used in the SUA)

7. Steps and Documents in the Sales/Collection Process
(as used in the SUA)

8. The Accounting Equation
Assets = Claims
Assets = Liabilities + Owner’s Equity
Asset: economic resources owned by the business.
Liability: obligations of the business to creditors.
Equity: owner’s claims to the assets.

9. Four Basic Financial Statements
Balance Sheet
Assets = Liabilities + Equity
Income Statement
Revenues - Expenses = Net income
Statement of Retained Earnings
Beginning RE + Net income - Dividends = Ending RE
Cash Flow Statement
Cash inflow - Cash outflow = Net cash flow

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

11. Traditional Approaches: Financial Accounting Orientation
Dominance of traditional accounting as the primary information provider leads to problems:
single view of business entity using the accounting/balance sheet model:
double-entry, debits and credits
high level of aggregation
ignoring non-financial data
inability to serve diverse enterprise-wide needs
Assets = Liabilities + Owners’ Equity

12. The REA Approach to Business Modeling31

13. Resources, Events, and Agents (REA) Model
Developed in the ‘70's by Dr. Bill McCarthy of Michigan State University
The definition of events is broad enough to encompass both operational and accounting transactions.
Expands the scope and usefulness of AIS by making it capable of providing both financial and nonfinancial information.
Data for each event is stored in disaggregated form.
Outputs are subsequently produced by assembling the required data from the various records.
Many firms have not adopted the REA model since it is a major change from the traditional double-entry approach.
The REA or events perspective is increasingly seen as necessary to meet changing information needs.

14. Resources, Events, and Agents (REA) Model …
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

15. Resources, Events, and Agents (REA) Model …
The REA model is an alternative accounting framework for modeling an organization’s
economic resources
economic events
economic agents, and
their interrelationships
A variation of entity-relationship diagramming (ERD) is used to model these relationships. 42

16. Resources in the REA Model
Economic resources are the assets of the company.
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:
for example, Accounts Receivables
artifacts that can be generated from other primary data 42

17. Events in the REA Model
Economic events are phenomena that effect changes in resources.
a source of detailed data in the REA approach to databases
Three classes of events:
operating events--what happens
information events--what is recorded
decision/management events--what is done as a result
Only operating events are included in the REA model. 42

18. Agents in the REA Model Can be individuals or departments
Can participate in events
Can 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 42

19. Resources, Events, and Agents (REA) Model …
A variation of the entity-relationship diagramming (ERD) is used in REA modeling.
Basic ERD symbols:
entity
attribute
(optional)
relationship
(optional) 42

20. Advantages of the REA Model
Using REA can lead to more efficient operations
helps managers identify non-value added activities that can be eliminated
increased 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
detailed financial and nonfinancial business data supports a wider range of management decisions
increased competitive advantage by providing more relevant, timely, and accurate information to managers 43

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

22. Database Applications
Phase 1
Flat Files
Phase 2
Event-Driven
Database
Phase 3
REA-Model
Database
Limitations:
Not widely used;
Requires detailed analysis
Limitations:
Redundant data;
Anomalies
Limitations:
Loss of non-economic information

23. Database Sales Order Entry/Cash Receipts System

24. Database Purchases/Cash Disbursement System

25. Limitations of Transaction-Based Systems
Event: a single business activity within a business process which involves resources and agents
Traditional event-based database systems tend to focus exclusively on economic events.
loss of non-economic/non-financial information
REA is event-oriented versus event-based.
includes non-economic and economic event information

26. Developing an REA Model: Overview
Before developing the REA model, identify events and classify as:
Operating events--activities that produce goods and services
Information events--activities associated with recording, maintaining, and reporting information
Decision/Management events--activities that lead to decisions being taken
REA model uses only operating events.

27. Chapter 5: Data Modeling and Database Design
3/31/2017
Basic REA template
Dr. Fred Barbee

28. Chapter 5: Data Modeling and Database Design
3/31/2017
The REA Data Model
Give-To- Get Duality
Resources
Events
Agents
Dr. Fred Barbee

29. Chapter 5: Data Modeling and Database Design
3/31/2017
The REA Data Model
Resources: Those things that have economic value to the firm.
Resources
Events
Agents
Dr. Fred Barbee

30. Chapter 5: Data Modeling and Database Design
3/31/2017
The REA Data Model
Events: Various Business Activities
Resources
Events
Agents
Dr. Fred Barbee

31. Chapter 5: Data Modeling and Database Design
3/31/2017
The REA Data Model
Agents: People and Organizations that participate in events.
Resources
Events
Agents
Dr. Fred Barbee

32. Chapter 5: Data Modeling and Database Design Developing an REA Diagram
3/31/2017
Developing an REA Diagram
Dr. Fred Barbee

33. Step 1: Identify the Economic Exchange Events
Chapter 5: Data Modeling and Database Design
3/31/2017
Step 1: Identify the Economic Exchange Events 1
Identify the pair of events that reflect the basic economic exchange (give-to-get duality relationship) in that cycle.
Dr. Fred Barbee

34. Chapter 5: Data Modeling and Database Design
Identify the PAIR of events
One GET
One GIVE
3/31/2017
Dr. Fred Barbee

35. Step 2: Identify Resources and Agents
Chapter 5: Data Modeling and Database Design
3/31/2017
Step 2: Identify Resources and Agents 2
Identify the Resources affected by each event and the agents who participate in those events.
Dr. Fred Barbee

36. Chapter 5: Data Modeling and Database Design
3/31/2017
Identify . . .
RESOURCES affected by each event.
AGENTS who participate in the events.
Dr. Fred Barbee

37. Step 3: Include commitment Events
Chapter 5: Data Modeling and Database Design
3/31/2017
Step 3: Include commitment Events 3
Analyze each economic exchange event to determine whether it should be decomposed into a combination of one or more commitment events and an economic exchange event.
Dr. Fred Barbee

38. Chapter 5: Data Modeling and Database Design
3/31/2017
Include commitment events.
Dr. Fred Barbee

39. Step 4: Determine Cardinalities of Relationships
Chapter 5: Data Modeling and Database Design
3/31/2017
Step 4: Determine Cardinalities of Relationships 4
Determine the cardinalities of each relationship.
Dr. Fred Barbee

40. Chapter 5: Data Modeling and Database Design
3/31/2017
Determine cardinalities of relationships.
Dr. Fred Barbee

41. Chapter 5: Data Modeling and Database Design
3/31/2017
How many sales transactions can be linked to each individual customer?
Sales
Customer
How many customers can be linked to each individual sales transaction?
Dr. Fred Barbee

42. Chapter 5: Data Modeling and Database Design
3/31/2017
Cardinalities
Minimum
(1,N)
Maximum
Dr. Fred Barbee

43. Chapter 5: Data Modeling and Database Design
3/31/2017
The first number is the minimum cardinality. It indicates whether a row in this table must be linked to at least one row in the table on the opposite side of that relationship.
Dr. Fred Barbee

44. Chapter 5: Data Modeling and Database Design
3/31/2017
Minimum Cardinality
The minimum cardinality of a relationship indicates whether each row in that entity MUST be linked to a row in the entity on the other side of the relationship.
Minimum cardinalities can be either 0 or 1.
Dr. Fred Barbee

45. Minimum Cardinalities
Chapter 5: Data Modeling and Database Design
3/31/2017
Minimum Cardinalities
A minimum cardinality of zero means that a new row can be added to that table without being linked to any rows in the other table.
A minimum cardinality of one means that each row in that table MUST be linked to at least one row in the other table
Dr. Fred Barbee

46. Chapter 5: Data Modeling and Database Design
3/31/2017
Cardinalities
The minimum cardinality of zero in the (0, N) cardinality pair to the left of the customer entity in the customer-sales relationship . . .
Made to
Sales
(0, N)
Customer
. . . indicates that a new customer may be added to the database without being linked to any sales events.
Dr. Fred Barbee

47. Chapter 5: Data Modeling and Database Design
3/31/2017
Cardinalities
The minimum cardinality of 1 in the (1,1) cardinality pair to the right of the sales entity in the customer-sales relationship . . .
Made to
Sales
(1,1)
(0, N)
Customer
. . . indicates that a new sales transaction CAN ONLY be added if it is linked to a customer.
Dr. Fred Barbee

48. Chapter 5: Data Modeling and Database Design
3/31/2017
The second number is the maximum cardinality. It indicates whether one row in that table can be linked to more than one row in the other table.
Dr. Fred Barbee

49. Maximum Cardinalities
Chapter 5: Data Modeling and Database Design
3/31/2017
Maximum Cardinalities
The maximum cardinality of a relationship indicates whether each row in that entity CAN be linked to more than one row in the entity on the other side of the relationship.
Maximum cardinalities can be either 1 or N.
Dr. Fred Barbee

50. Maximum Cardinalities
Chapter 5: Data Modeling and Database Design
3/31/2017
Maximum Cardinalities
A maximum cardinality of 1 means that each row in that table can be linked to at most only 1 row in the other table.
A maximum cardinality of N means that each row in that table MAY be linked to more than one row in the other table.
Dr. Fred Barbee

51. Chapter 5: Data Modeling and Database Design
3/31/2017
Cardinalities
The maximum cardinality of N in the (0,N) cardinality pair to the left of the customer entity in the customer-sales relationship . . .
Made to
Sales
(0, N)
Customer
. . . indicates that a given customer MAY be linked to many sales events.
Dr. Fred Barbee

52. Chapter 5: Data Modeling and Database Design
3/31/2017
Cardinalities
The maximum cardinality of 1 in the (1,1) cardinality pair to the right of the sales entity in the customer-sales relationship . . .
Made to
Sales
(1,1)
(0, N)
Customer
. . . indicates that a given sales transaction can only be linked to one customer.
Dr. Fred Barbee

53. Determine Cardinalities
Chapter 5: Data Modeling and Database Design
3/31/2017
Determine Cardinalities
Cardinalities are not arbitrarily chosen by the database designer.
They reflect facts about the organization being modeled and its business practices obtained during the requirements analysis stage of the database design process.
Dr. Fred Barbee

54. Cardinalities: Types of Relationships
Chapter 5: Data Modeling and Database Design
3/31/2017
Cardinalities: Types of Relationships
Three basic types - depending on the maximum cardinality associated with each entity.
A one-to-one relationship (1:1)
A one-to-many relationship (1:N)
A many-to-many relationship (M:N)
Dr. Fred Barbee

55. Types of Relationships
Panel A: One-to-One (1:1) Relationship
Sales
Cash Receipts
(0,1)
(1,1)

56. Types of Relationships
Panel B: One-to-Many (1:N) Relationship
Sales
Cash Receipts
(0,N)
(1,1)

57. Types of Relationships
Panel C: One-to-Many (1:N) Relationship
Sales
Cash Receipts
(0,1)
(1,N)

58. Types of Relationships
Panel D: Many-to-Many (M:N) Relationship
Sales
Cash Receipts
(0,N)
(1,N)

59. Chapter 5: Data Modeling and Database Design
3/31/2017
Build a Set of Tables to Implement an REA Model of an AIS in a Relational Database
Dr. Fred Barbee

60. Implementing an REA Diagram in a Relational Database
Chapter 5: Data Modeling and Database Design
3/31/2017
Implementing an REA Diagram in a Relational Database
An REA diagram can be used to design a well-structured relational database.
A well-structured relational database is one that is not subject to update, insert, and delete anomaly problems.
Dr. Fred Barbee

61. Three Step Process
Create a table for each distinct entity and for each many-to many relationship
Assign attributes to appropriate tables
Use foreign keys to implement one-to-one and one-to-many relationships

62. Chapter 5: Data Modeling and Database Design
3/31/2017
Implementing an REA Diagram
Dr. Fred Barbee

63. Implementing an REA model

64. Create Tables
From the previously discussed REA diagram, nine tables would be created: one for each of the seven entities and one for each of the many-to-many relationships.
Inventory
Purchases
Employees
Vendors
Cashier
Cash disbursements
Cash
Purchases-inventory
Purchases-cash disbursements

65. Assign Attributes for Each Table
Primary keys: Usually, the primary key of a table representing an entity is a single attribute.
Other Attributes: Additional attributes are included in each table to satisfy transaction processing requirements.

66. Chapter 5: Data Modeling and Database Design
3/31/2017
Implementing an REA Diagram
Dr. Fred Barbee

67. Chapter 5: Data Modeling and Database Design
3/31/2017
Implementing an REA Diagram
Dr. Fred Barbee

68. Documentation of Business Practices
REA diagrams are especially useful for documenting an advanced AIS built using databases.
REA diagrams provide information about the organization’s business practices

69. Documentation of Business Practices
The zero minimum for the sales event indicates that credit sales are made
The N maximum for the sales event means that customers may make installment payments
Sales- Cash Receipts
Cash Receipts
Sales
(1, N)
(0, N)

70. Documentation of Business Practices
The one minimum for the cash receipts event indicates that cash is not received prior to delivering the merchandise
The N maximum for the cash receipts event means that customers may pay for several sales with one check
Sales- Cash Receipts
Cash Receipts
Sales
(1, N)
(0, N)

71. Extracting Information From the AIS
A complete REA diagram serves as a useful guide for querying an AIS database.
Queries can be used to generate journals and ledgers from a relational database built on the REA model.

72. Extracting Information From the AIS
(0, 1)
(1, N)
Sales
Cash
collections
Each sales transaction is paid in full by a cash collection event.
Each customer payment may be for more than one sale.
What is the query logic?
Total accounts receivable is the sum of all sales for which there is no remittance number.

73. Extracting Information From the AIS
(1, 1)
Sales
Cash
collections
Each sales transaction can be paid in installments.
Each customer payment is for just one sale.
What is the query logic?
(1) sum all sales; (2) sum cash collections; then A/R = (1)-(2)

74. Extracting Information From the AIS
(0, 1)
(1, 1)
Sales
Cash
collections
Each sales transaction is paid in full by a cash collection event.
Each customer payment is for one sale.
What is the query logic?
Total accounts receivable is the sum of all sales for which there is no remittance number.

75. Extracting Information From the AIS
Sales
Cash
collections
Each sales transaction may be paid for in installments.
Each customer payment may be for more than one sale.
What is the query logic?
(1) Sum all sales; (2) Sum all cash collections; Then A/R = (1)-(2)

76. Let’s Review with a Little Help From My Friends ….

77. An REA Model of an Economic Exchange
William E. McCarthy*
Michigan State University
(These slides may be copied as long as original source is cited) *

78. Cookie-Monster (the customer) and Elmo (the entrepreneur) meet in the (real or virtual) marketplace, thus setting the stage for an Economic Exchange

79. Economic Exchange Pattern
Event
Agent
Resource
duality R E A
Source:
W. E. McCarthy “The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment,” The Accounting Review, July 1982, pp
W.E. McCarthy “The REA Modeling Approach to Teaching Accounting Information Systems,” Issues in Accounting Education, November 2003, pp (source of following slides)

80. Cookie-Monster (the customer) and Elmo (the entrepreneur) engage in a SHIPMENT (transfer of Cookie Inventory)

81. outside participation outside participation
Economic Resource
COOKIES
inside participation
Economic Agent
ELMO
stock-flow
Economic Event
SALE
Economic Agent
outside participation
cookie
monster
Give
duality
Take
outside participation
Economic Agent
stock-flow
Economic Event
Economic Agent
inside participation
Economic Resource
REA model of cookie sale from entrepreneur’s (ELMO) perspective

82. Cookie-Monster (the customer) and Elmo (the entrepreneur) engage in a PAYMENT (transfer of Cash)

83. outside participation outside participation
Economic Resource
COOKIES
inside participation
Economic Agent
ELMO
stock-flow
Economic Event
SALE
Economic Agent
outside participation
cookie
monster
Give
duality
Take
outside participation
Economic Agent
cookie
monster
stock-flow
Economic Event
CASH
RECEIPT
Economic Agent
inside participation
Economic Resource
ELMO
CASH
REA model of cookie sale from entrepreneur’s (ELMO) perspective

84. outside participation
Give
Take
Economic Resource
inside participation
outside participation
stock-flow
Economic Event
Cash Receipt
Economic Agent
Salesperson
Customer
Cashier
Cash
Cookies
duality
Sale
more general exchange model from the entrepreneur’s (ELMO’s) internal perspective

85. COOKIES-stockflow-SALE
Product#
Description
Price
QOH
P-1
Chocolate Chip
1.05
200
P-2
Chocolate
.95
205
P-3
Peanut Butter
1.00 97
P-4
Pecan
1.10
257
Product#
Invoice#
Quantity
P-2
I-1 5
P-3 10
I-2 20
P-4
I-3 9
P-1
I-4 4
SALE-duality-CASH_RECEIPT
SALE
Invoice#
Dollar Amount
Date
Salesperson Employee#
Customer #
I-1
14.75
1JUL
E-1234
C-987
I-2
20.00
2JUL
E-1235
C-888
I-3
9.90
3JUL
E-1236
C-999
I-4
9.20
5JUL
E-1237
Invoice#
Receipt Timestamp
Amount Applied
I-1
2JUL0830
14.75
I-2
3JUL0800
2.00
5JUL0800
18.00
I-3
8JUL1145
9.90
I-4
9.20
Partial Database for Elmo’s Cookie Business
Why is this invoice amount $14.75 ??
How is customer paying for this ???

86. A business process is a set of activities that takes one or more kinds of input and creates an output that is of greater value to the customer (Hammer and Champy)
business process
labor
cookies
Conversion Cycle
business process
Revenue Cycle
cash
business process
cookie ingredients
Acquisition Cycle
cash
value chain
A value chain is a purposeful network of business processes aimed at assembling the individual components of a final product (i.e., its portfolio of attributes) of value to the customer (Porter and Geerts/McCarthy)
Part of ELMO’s Value Chain for Providing Cookies

87. Enterprise Information Basic Systems Counting Accounting
Semantic infrastructure of system matches extended REA pattern
Enterprise
Information
Systems
Basic
Accounting
Systems
Counting
artifacts
e-collaboration
systems
Enterprise Systems classification structure is from David, McCarthy & Sommer, Communications of the ACM, May 2003, pp

88. Different perspectives on REA modeling needed for enterprise modeling (value chains) and collaboration space (supply chains)
Enterprise modeling (as evidenced in normal ERP systems) is done from the perspective of one company or entrepreneur. Business processes are viewed as components of a single value chain. A single exchange (like the sale of a product for money) would be modeled twice, once in the enterprise system of each trading partner.
Collaboration space modeling (as evidenced in ebXML or ISO Open-edi) is done from a perspective independent of each trading partner. A single exchange is modeled once in independent terms that can be then mapped into internal enterprise system components. Supply chains are networks of business processes that alternate internal transformations and external exchanges (definition due to Bob Haugen).
REA modeling works in both cases and the independent to trading partner mapping is absolutely straightforward and completely defined.

89. Used for collaboration space modeling
Business
Process
Independent view of
Inter-enterprise events
Enterprise
Illustration of Perspective: Trading Partner vs. Independent
Trading Partner view of
Inter-enterprise events (upstream vendors and downstream customers)
Blue arrows represent flow of goods, services, and cash between different companies; green arrows represent flows within companies
Used for collaboration space modeling
SOURCE: Adapted from ISO , K. Morita

90. COOKIES ELMO SHIPMENT ELMO CASH cookie monster cookie monster
Economic Resource
Economic Agent
COOKIES
from
ELMO
stock-flow
Economic Event
SHIPMENT
Economic Agent to
cookie
monster
initiating transfer
duality
responding transfer
Economic Agent to
ELMO
stock-flow
Economic Event
PAYMENT
Economic Agent
from
Economic Resource
cookie
monster
CASH
REA model of cookie sale from independent (collaboration space) perspective

91. Ontological Extensions to the REA Model (Geerts and McCarthy)
Type images for basic objects allows specification of policies and controls plus abstract specification of negotiation components
Commitment images for economic events allows specification of contracts and agreements
State machine model allows specification and ordering of business events as collaboration space messaging and/or internal workflow
Aggregation of binary collaborations allows mediated collaboration with third parties
SOURCE: Geerts and McCarthy, The Ontological Foundations of REA Enterprise Information Systems, 2003.

92. Bilateral Collaboration Economic Resource Type Mediated Collaboration
ISO Open-edi Ontology Collaboration Model
Bilateral Collaboration
governs
Economic Event
Economic Resource
Economic Agent
stockflow
from to
Economic Contract
Economic Commitment
reciprocal
fulfills
establish
duality
Economic Resource Type
typifies
specifies
Economic Event Type
Business Role
qualifies
reserves
involves
Partner
Third Party
Mediated Collaboration
Business Transaction
participates
requires
Agreement
Regulator
constrains
SOURCE: Adapted from ISO , W.E. McCarthy

93. Cookie-Monster and Elmo after their economic exchange (both economic agents have now reached higher levels of utility)

94. Cookie Monster and Elmo are of course characters from the Public Broadcasting Service TV show Sesame Street*. Their use here is only illustrative. Cookie Monster is a great example of a typical buyer (has money, wants goods) because he is most happy when he has a cookie to eat. The use of Elmo as a typical seller (has goods, wants money) is only a convenient illustration. * see

95. Online resources:
AIS Romney 2006 notes Chapter15 Database Design Using the REA
AIS Romney 2006 notes Chapter 16 Implementing an REA