2. Acknowledgement
These slides have been
adapted from
Considine, B et al. (2012).
Accounting Information
Systems: Understanding
Business Processes, 4th edition.
Chapter 4
3. Acknowledgement
These slides have been
adapted from
Hall, James A. (2013).
Accounting Information
Systems, 8th edition, South-
Western : Cengage Learning.
Chapter 10
4. Learning Objectives
• Discuss the REA (resources–events–agents) Accounting Model as
a template for modeling accounting systems
• Understand the differences between REA and entity-relationship
modeling
• 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
integration steps to a business case
5. Sub Topics
1. The REA Accounting Model
2. The REA Approach
3. Developing an REA Model
4. View integration : Creating an
enterprise-wide REA Model
7. The Rea Accounting Model
• Another way to model data is to use the REA
Accounting Model
• This model is based on the premise that in
every exchange in a process there is a
resource, event and agent involved
12. • Despite the reluctance of businesses to use REA to
implement accounting systems, one of the REA
model’s greatest advantages is that it can store
non-financial data as well as financial data
• It is possible for organizations to use REA to model
their business processes, but then implement the
relationships via a traditional accounting system
The Rea Accounting
Model
14. 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
The REA Approach
15. 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
The REA Approach
17. 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
Resources
The REA Approach
19. Events
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
Events
The REA Approach
22. 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
Agents
The REA Approach
25. 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
26. The Narration
Apex Supply Company is a downtown Philadelphia wholesaler of
electrical products that sells to electrical retailers. It carries an inventory
of approximately 10,000 items. Customers place orders by phone and
buy on credit through a line-of-credit arrangement with Apex. A
typical transaction involves the customer first contacting the customer
services department to verify availability and check the price of the item
or items being sought. If the customer decides to buy, he or she is
transferred to a sales agent, who takes the order. The shipping clerk
sends the products to the customer by a common carrier. The billing
clerk records the sale in the sales journal, prepares an invoice, and sends
it to the customer, who is given 30 days to make payment. The
accounts receivable clerk also receives a copy of the invoice and records
it in the accounts receivable ledger. Subsequently (within 30 days) the
customer sends a check and the remittance advice to Apex. The cash
receipts clerk receives the check, records it in the cash receipts journal,
and updates the cash account. The remittance advice goes to the
accounts receivable clerk, who updates (reduces) the customer’s account
receivable.
27. 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 such invalid events such as:
• bookkeeping tasks
• accounting artifacts, e.g., accounts receivable
Developing an REA Model
29. 2. Identify the Resources 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
Developing an REA
Model
31. 3. Identifies the Agents 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
Developing an REA Model
32. Verify
Availability
Take Order
Ship Product
Receive Cash
EVENTS
Inventory
Inventory
Inventory
Cash
RESOURCES AGENTS
Customer Service
Clerk
Customer
Sales
Representative
Customer
Shipping Clerk
Customer
Cash Receipt Clerk
Customer
33. 4. Determine Associations and Cardinalities
• 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.
36. 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’.
39. 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
View Integration:
Creating an Enterprise-
Wide REA Model
40. 1. Consolidate the Individual Model
• 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.
View Integration:
Creating an Enterprise-
Wide REA Model
43. 2. Define Primary Keys, Foreign Keys & 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
View Integration:
Creating an Enterprise-
Wide REA Model
45. Tables, Keys & Attributes
(Cont.)
Source: Hall (2008:507-515)
46. 3. Construct Physical Database & 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.
View Integration:
Creating an Enterprise-
Wide REA Model
47. Source: Hall (2008:507-517)
User-View #1
Past Due Accounts
Name Amount
James $500.00
Henry $100.00
… …
Sales Report
User-View #2
REA Database
View Integration:
Creating an Enterprise-
Wide REA Model