REA analysisand

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-Agentanalysis 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…

Where

Who

What

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 modelingbasic template

Event

Resource Internalagent

Location(if needed)

ExternalAgent

(if needed)

Event

Resource Internalagent

Location(if needed)

ExternalAgent

(if needed)

These are allconsideredentities

Entity-Resource-Agent modeling

Entity

Relationship - Describes how two entities relate

Attribute - Provides specifics for an entity (the column information)

- Resource - such as merchandise or cash- Person (what we referred to as entities in DFDs)- Event

Entity-Relationship modeling

Entity-Relationship modeling

tblCashDisbursementCheck No.

tblPurchaseOrderPO No.

tblCashDisbursementInventoryReceipt

Inv Rec No. + Chk No

tblInventoryReceiptInv Rec No

tblMaterialsInventoryInv. Stck No

tblVendorVendor No.

tblPOInventoryReceipt

PO No. + Inv Stck No.

CheckNo.

InvReceipt

No.

VendorNo.

PONo.

PONo.

InvStockNo.

Date

Inventory data

Vendor data

Entity-Relationship modeling

tblCashDisbursementCheck No.

tblPurchaseOrderPO No.

tblCashDisbursementInventoryReceipt

Inv Rec No. + Chk No

tblInventoryReceiptInv Rec No

tblMaterialsInventoryInv. Stck No

tblVendorVendor No.

tblPOInventoryReceipt

PO No. + Inv Stck No.

CheckNo.

InvReceipt

No.

VendorNo.

PONo.

PONo.

InvStockNo.

Date

Inventory data

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

Let’s rewrite this ONE table as two separate tables (like we did last class)

Entity-Relationship modelingExample from last class

Notice how each SSN is unique in the first AND the second table. If youknow any of the information in the table, you know it all. There are reasonsyou might want to design things this way though...

Entity-Relationship modeling• Designations

– 1-1 (one to one)

Person ID Plate IDSSN

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

tblCustomerCustNo.

tblInvoiceInvoiceNo.CustNo.

1 M

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

tblInventoryItemNo

tblInvoiceInvoiceNoItemNo. InvoiceNo.

tblInvoiceLineItemNo

InvoiceNo

1 1MM

Entity-Relationship diagrams

tblCUSTOMERCustomerID

CustomerID tblINVOICEInvoiceID

tblINVITEMInventoryID

InvoiceID

tblITEMInventoryID

InvoiceID

InventoryID

tblINVITEMInventoryID

InvoiceID

M

MM

1

1

1

Entity-Relationship diagrams

Entity-Relationship diagrams

tblEMPLOYEEEMPNUM

EMPNUM

tblIDTAGTAGNUMPACKID

tblTAGNOTAGNUM

TAGNUM

(1,M)

tblTAGNOTAGNUM

M

M 1

1

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

GiveInventory

GetCash

Example - Revenue Cycle:

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

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

OrderInvty

ReceiveInvty

CashDisb

Inventory

Cash

Vendor

Employee

Employee

Employee

Vendor

Vendor

OrderInvty

ReceiveInvty

CashDisb

Inventory

Cash

Vendor

Employee

Employee

Employee

Vendor

Vendor

OrderInvty

ReceiveInvty

CashDisb

Inventory

Cash

Vendor

Employee

Employee

Employee

PO

PO

Vendor

Vendor

1 M

1

M

Here, there is only one employee… the purchase manager… that is called by the purchase order.

OrderInvty

ReceiveInvty

CashDisb

Inventory

Cash

Vendor

Employee

Employee

Employee

PO

PO

PO-ItemID

Vendor

Vendor

1 M

1

M

M

M

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.

OrderInvty

ReceiveInvty

CashDisb

Inventory

Cash

Vendor

Employee

Employee

Employee

PO

PO

Vendor

Vendor

1 M

1

M

ItemID

PO-Line Item PO

1

1MM

We create a NEW table with a composite primary key to resolve the M-M dilemma.

OrderInvty

ReceiveInvty

CashDisb

Inventory

Cash

Vendor

Employee

Employee

Employee

PO

PO

PO

Vendor

Vendor

1 M

1

M

ItemID

PO-Line Item PO

1

1MM

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)

1

M

OrderInvty

ReceiveInvty

CashDisb

Inventory

Cash

Vendor

Employee

Employee

Employee

PO

PO

PO

Vendor

Vendor

1 M

1

M

ItemID

PO-Line Item PO

1

1MM

Again, we have a Many to Many relationship that we must resolve.

1

MM

M

OrderInvty

ReceiveInvty

CashDisb

Inventory

Cash

Vendor

Employee

Employee

Employee

PO

PO

PO

Vendor

Vendor

1 M

1

M

ItemID

PO-Line Item PO

1

1MM

1

MRec. Rept. -Line Item RR

ItemID

1

1

MM

Again, we create a NEW table with a composite primary key to resolve the M-M dilemma.

OrderInvty

ReceiveInvty

CashDisb

Inventory

Cash

Vendor

Employee

Employee

Employee

PO

PO

RR

PO

Vendor

RR Vendor

1 M

1

M

ItemID

PO-Line Item PO

1

1MM

1

MRec. Rept. -Line Item RR

ItemID

1

1

MM

1

1

M

M

The internal and external agents are handeled in the same way as the order process, but there is a different employee.