REA analysis
and
E-R diagramming
12/8/2011
What are we hoping to achieve?
• Tool for designing a database system to
meet the needs of the organization
• REA modeling is a method of analyzing and
thinking about the system
• E-R diagramming is a means of diagramming
what the database should look like based
upon the analysis above.
What are we hoping to achieve?
• What we want to do is follow a structured
approach for designing databases.
• The basic element in a database is called an
entity – What do you think an entity might be relative
to an ACCESS database?
Some of the usual suspects…
• Entities from the DFD/flowchart
world(people)
• Events
• Resources
Resource-Event-Agent modeling
• REA modeling is a hot topic in systems circles
• Some books combine REA and E-R diagramming and
some make no distinction
Resource-Event-Agent
analysis and modeling
• We focus on events, which are things that get
recorded in our system
• For each event we will possibly have
–
–
–
–
The event itself
Resources consumed or obtained
Internal agents (entities)
External agents (entities)
• The reason that the word entities is in
parentheses is that with this type of modeling, all
five of these things are referred to as “entities”
REA analysis
• Think back to the purchase order in the
SUA that we looked at a few days ago…
Who
What
Where
Entity-Relationship diagramming
• It uses three symbols
– A rectangle
• An entity (but not the same as in DFDs and
flowcharts
– A diamond
• A relationship
– An oval
• An attribute
• A specific form of E-R model is called REA
(Resource-Event-Agent) modeling
Resource-Event-Agent modeling
basic template
Internal
agent
Resource
These are all
considered
entities
Event
External
Agent
Location
(if needed)
(if needed)
Internal
agent
Resource
Event
Location
(if needed)
External
Agent
(if needed)
Entity-Resource-Agent modeling
Entity
Relationship
Attribute
-Resource - such as merchandise or cash
-Person (what we referred to as entities in DFDs)
-Event
-Describes how two entities relate
-Provides specifics for an entity (the column
information)
Entity-Relationship modeling
Entity-Relationship modeling
tblCashDisbursement
Check No.
Date
PO
No.
tblPurchaseOrder
PO No.
PO
No.
Check
No.
tblCashDisbursement
InventoryReceipt
Inv Rec No. + Chk No
tblInventoryReceipt
Inv Rec No
Inv
Receipt
No.
tblPO
InventoryReceipt
PO No. + Inv Stck No.
Inv
Stock
No.
Vendor
No.
tblVendor
Vendor No.
Vendor data
tblMaterialsInventory
Inv. Stck No
Inventory data
Entity-Relationship modeling
tblCashDisbursement
Check No.
Date
PO
No.
tblPurchaseOrder
PO No.
PO
No.
Check
No.
tblCashDisbursement
InventoryReceipt
Inv Rec No. + Chk No
tblInventoryReceipt
Inv Rec No
Inv
Receipt
No.
tblPO
InventoryReceipt
PO No. + Inv Stck No.
Inv
Stock
No.
Vendor
No.
tblVendor
Vendor No.
Vendor data
tblMaterialsInventory
Inv. Stck No
Inventory data
Entity-Relationship modeling
• Cardinality
– Within the context of ER modeling, we can characterize
the cardinality of a relationship.
– Cardinality has to do with the number of possible
outcomes that we are combining together
• Designations
– 1-1 (one to one)
• This is when two tables are related and for every
occurrence of the primary key in the first table, there is
one and only one occurrence of the foreign key in the
second table. Third normal form does not require any 1 - 1
relations
• Example:
Entity-Relationship modeling
Example from last class
Notice how each SSN is unique in the first AND the second table. If you
know any of the information in the table, you know it all. There are reasons
you might want to design things this way though...
Let’s rewrite this ONE table as
two separate tables (like we did
last class)
Entity-Relationship modeling
• Designations
– 1-1 (one to one)
Person ID
SSN
Plate ID
Entity-Relationship modeling
• Designations
– 1-M (one to many)
• This is the most common relationship
• The primary key of the first table is unique in the second
table
• Consider a customer table and an invoice table
– Each customer may have MANY invoices
– Each invoice relates to ONLY ONE customer
tblCustomer
CustNo.
1
CustNo.
M
tblInvoice
InvoiceNo.
Entity-Relationship modeling
• Designations
– M-M (many to many)
• This is frequent in accounting contexts.
• You have two tables
– In each table, there are multiple occurrences of the primary key
of the other table
• Example is Invoices and Inventory Items
– Each invoice may have several items in inventory
– Each item in inventory may appear on several invoices
• The solution is to create a table that has a COMPOSITE
PRIMARY KEY and build TWO relations
tblInventory
ItemNo
1
ItemNo.
M
tblInvoiceLine
ItemNo
InvoiceNo
M
InvoiceNo.
1
tblInvoice
InvoiceNo
Entity-Relationship diagrams
CustomerID
M
tblINVOICE
InvoiceID
1
InvoiceID
tblINVITEM
InventoryID
InvoiceID
M
M
1
tblCUSTOMER
CustomerID
InventoryID
1
tblITEM
InventoryID
Entity-Relationship diagrams
Entity-Relationship diagrams
(1,M)
tblEMPLOYEE
EMPNUM
TAGNUM
1
EMPNUM
M
tblTAGNO
TAGNUM
1
M
tblIDTAG
TAGNUM
PACKID
Entity-Relationship diagrams
REA data model
• REA is specifically for Accounting
Information Systems
• 3 types of entities
– Resources
– Events
– Agents
• Basic Template
Basic Template
• This is a slightly more restrictive view than
we previously took.
– Exchange event is two sided (balance sheet
equation)
– Commitment events (inquiry events?) LEAD TO
exchange events (don’t worry about these)
– Every exchange must have an internal and
external agent
Four steps to developing
an REA Diagram
• Identify the pair of economic exchange
events
• Identify resources (balance sheet
accounts) and agents
– There will always be at least one internal and
one external agent for economic exchange
events.
• Examine whether it should be broken down
to include “commitment-type” events
• Determine cardinalities of relationships
Identify the pair of economic exchange events
Example - Revenue Cycle:
Give
Inventory
Get
Cash
Identify resources and agents
• Resources for the sales (revenue) cycle:
– Inventory
– Cash
• Agents for the sales cycle:
– Internal - Salesperson/Cashier
– External - Customer
USING the REA diagram
• Create a table for each entity and one for
each M:N relationship
– You need a table for each M:N relationship to
concatenate the primary keys for the two
tables
• Put the appropriate attributes (columns) in
the tables
• Implement relationships
Example
WE-FIX-COMPUTERS operates a repair shop for PCs. This describes
their purchase system for parts.
They order parts from more than a dozen vendors. Sometimes
vendors ship partial orders. We-Fix pays for purchases by the 10th of
the next month. It always pays each invoice in full (no installment
payments). There is a single purchase manager through which all
purchases are made.
Let’s consider the Order event and the Purchase event. We will have
“place holders” for the Cash Disbursement event, but will not worry
about it.
Order
Invty
Vendor
Inventory
Employee
Vendor
Receive
Invty
Employee
Vendor
Cash
Cash
Disb
Employee
Order
Invty
Vendor
Inventory
Employee
Vendor
Receive
Invty
Employee
Vendor
Cash
Cash
Disb
Employee
Order
Invty
1
PO
M
Vendor
1
Inventory
PO
M
Employee
Vendor
Here, there is only one
employee… the purchase
manager… that is called by the
purchase order.
Receive
Invty
Employee
Vendor
Cash
Cash
Disb
Employee
POItemID
Inventory
M
Order
Invty
1
PO
M
Vendor
1
M
PO
M
Employee
Vendor
Here, we have a Many to Many
relationship because each item
in inventory can appear on
several purchase orders and
each purchase order has
possibly several inventory
items. See next slide for
solution.
Cash
Receive
Invty
Employee
Vendor
Cash
Disb
Employee
M
POM
Line Item
PO
1
Order
Invty
1
PO
M
Vendor
1
ItemID
1
Inventory
PO
M
Employee
Vendor
We create a NEW table with a
composite primary key to
resolve the M-M dilemma.
Receive
Invty
Employee
Vendor
Cash
Cash
Disb
Employee
M
POM
Line Item
ItemID
PO
1
Order
Invty
1
1
1
PO
M
Vendor
1
Inventory
PO
PO
M
We have a 1-M relation
between orders and receipts
ONLY because vendors might
make partial shipments (so
more than one shipment is
received for a given PO)
Cash
M
Employee
Vendor
Receive
Invty
Employee
Vendor
Cash
Disb
Employee
M
POM
Line Item
PO
1
ItemID
Order
Invty
1
1
1
PO
M
Vendor
1
Inventory
PO
M
PO
M
Again, we have a Many to Many
relationship that we must
resolve.
M
M
Employee
Vendor
Receive
Invty
Employee
Vendor
Cash
Cash
Disb
Employee
M
POM
Line Item
PO
ItemID
1
Order
Invty
1
1
1
PO
M
Vendor
1
Inventory
PO
1
PO
M
Employee
ItemID
M
Rec. Rept. M Line Item
M
RR
Vendor
1 Receive
Invty
Employee
Again, we create a NEW table
with a composite primary key
to resolve the M-M dilemma.
Cash
Vendor
Cash
Disb
Employee
M
POM
Line Item
PO
ItemID
1
Order
Invty
1
1
1
PO
M
Vendor
1
Inventory
PO
1
PO
M
Employee
ItemID
M
Rec. Rept. M Line Item
M
RR
1 Receive
Invty
The internal and external
agents are handeled in the
same way as the order process,
but there is a different
employee.
Cash
1
1
RR
RR
M
M
Vendor
Employee
Vendor
Cash
Disb
Employee