Chapter 8
REA Modeling
Copyright © 2016 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education.
Outline
• Learning objectives
• Purpose and uses
• Terminology
• Cardinalities
• Database design
8-2
Learning objectives
1. Compare and contrast view-driven and
event-driven accounting information
systems.
2. Use REA modeling to represent an eventdriven AIS.
3. Use a REA model to design a relational
database for an event-driven AIS.
8-3
Purpose and uses
• Purpose
To describe an event-driven accounting
information system
• Uses
– Identify the essential Resources, Events and
Agents of the AIS
– Establish relationships between them
– Design relational databases to implement an
event-driven AIS
8-4
Terminology
• Events (center column)
– Three types
• Operating: sell inventory to customers
• Information: record inventory sales in the AIS
• Decision / management: decide whether to drop a
specific product line
– Only strategically significant operating
events appear in a REA model
– Determining strategically significant operating
events is a matter of judgment and practice
8-5
Terminology
• Resources (leftmost column)
– Items needed to carry out the events
– Examples
•
•
•
•
Cash
Inventory
Equipment
Employment application
8-6
Terminology
• Agents (rightmost column)
– People needed to carry out the events
– Examples
•
•
•
•
Employees
Vendors
Customers
Stockholders
8-7
Terminology
Vendor
Inventory
Buy
inventory
Employee
All entities in a REA model are illustrated with rectangles.
Resources on the left, events in the middle, agents on the
right.
8-8
Cardinalities
• Show relationships
between elements of
the REA model
• Facilitate creation of
database tables
• Three common
symbols
–0
–1
–*
• An employee might
process no purchase
orders. (“0”)
• Every order involves
exactly one customer.
(“1”)
• A single purchase
requisition can
include multiple
inventory items. (“*”)
8-9
Cardinalities
• To create cardinalities
between two
elements of a REA
• Set 1
a) For each “x,” what is the
minimum number of “y?”
b) For each “x,” what is the
maximum number of “y?”
• Set 2
model, ask four
a) For each “y,” what is the
minimum number of “x?”
questions.
b) For each “y,” what is the
maximum number of “x?”
8-10
Cardinalities
Vendor
Inventory
Buy
inventory
Employee
Suppose:
X = inventory
Y = buy inventory
8-11
Cardinalities
• Set 1
a) For each inventory item, what is the smallest
number of “buy inventory” transactions?
• Hint: minimums are either 0 or 1
• Answer: 1
b) For each inventory item, what is the greatest
number of “buy inventory” transactions?
• Hint: maximums are either 1 or * (many)
• Answer: * (many)
8-12
Cardinalities
(1,*)
Inventory
Buy
inventory
Every inventory item can be bought one to many
times.
Every inventory item participates in one to many “buy
inventory” events.
8-13
Cardinalities
• Set 2
a) For each “buy inventory” transaction, what is
the smallest number of inventory items?
• Hint: minimums are either 0 or 1
• Answer: 1
b) For each “buy inventory” transaction, what is
the greatest number of inventory items?
• Hint: maximums are either 1 or * (many)
• Answer: * (many)
8-14
Cardinalities
Inventory
(1,*)
Buy
inventory
Every “buy inventory” event includes one to many
inventory items.
8-15
Cardinalities
Inventory
(1,*)
(1,*)
Buy
inventory
8-16
Cardinalities
Buy
inventory
(0,*)
(1,1)
Employee
Every employee participates
Every “buy inventory”
in zero to many “buy
event involves exactly one
inventory” events.
employee.
8-17
Database design
• Every “box” in the
REA model needs at
least one database
table
• When maximum
cardinalities are 1 and
*, include the key
from the “one side” in
the table on the
“many side.”
• When maximum
cardinalities are * and
*, create a junction
table to express the
relationship.
• Follow the rules of
normalization.
• Do not store
calculated data.
8-18
Database design
(1,1)
Vendor
(1,*)
Inventory
(1,*)
(1,*)
Buy
inventory
Tables indicated by this REA model:
• Vendor
• Employee
(0,*)
(1,1)
Employee
• Inventory
• Buy inventory
• Inventory / buy inventory
8-19
Database design
• Vendor table
–
–
–
–
–
–
–
–
Vendor ID
Vendor name
Vendor address
Vendor city
Vendor state
Vendor ZIP code
Vendor web site
And many others!
• Employee table
–
–
–
–
–
–
Employee ID
Employee last name
Employee first name
Employee department
Employee job title
And many others!
8-20
Database design
• Inventory table
– Inventory ID
– Inventory item name
– Beginning quantity on hand
– Beginning inventory cost per unit
– Beginning inventory date
8-21
Database design
• Buy inventory table
(1,1)
(1,*)
Buy
inventory
Vendor
– Purchase order
number
– Purchase order date
– [Vendor ID]
– [Employee ID]
Remember: When the maximum cardinalities are “one” and
“many,” put the primary key from the “one side” (vendor)
into the table on the “many side” (buy inventory).
8-22
Database design
• Inventory / buy inventory table
– [Inventory ID]
– [Purchase order number]
– Quantity purchased
– Cost per unit purchased
Remember: When the
maximum cardinalities are
“many” and “many,” create a
Inventory
(1,*)
(1,*)
Buy
inventory
junction table.
8-23
8-24