REA analysis and E-R diagramming December 2, 2008

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 (people) Events Resources Locations

Resource-Event-Agent modeling REA modeling is a hot topic in systems circles It has gone through several name/content variations Some books combine REA and E-R diagramming and some make no distinction –IT CAN GET CONFUSING

Resource-Event-Agent(-Location) 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) –Perhaps a location 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”. This sounds a lot like narratives, DFDs and flowcharts, huh?

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 modeling basic template Event Resource Internal agent Location (if needed) External Agent (if needed) Event Resource Internal agent Location (if needed) External Agent (if needed) These are all considered entities

Entity-Resource-Agent modeling Example Sell Merchandise Salesperson Customer Receive Customer payment Cash Register decreases increases Takes place at Collects payment Sold by Sold to Received from Results in Now we add relations

Entity-Resource-Agent modeling with diamonds Sell Merchandise Salesperson Cash Register Customer Receive Customer payment Cash decreases increases Takes place at Collects payment Sold by Sold to Received from Takes place at Results in

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 diagrams There is a distinction between REA modeling and E-R diagramming! –This distinction is not really important, though. E-R diagrams can be used to graphically show the REA model This type of modeling is useful for designing databases Notice that the database/relationships design for the Ch03.mdb database looks very much like the ER diagram

Entity-Relationship modeling

tblCashDisbursement Check No. tblPurchaseOrder PO No. tblCashDisbursement InventoryReceipt Inv Rec No. + Chk No tblInventoryReceipt Inv Rec No tblMaterialsInventory Inv. Stck No tblVendor Vendor No. tblPO InventoryReceipt PO No. + Inv Stck No. Check No. Inv Receipt No. Vendor No. PO No. Inv Stock No. Date Inventory data Vendor data

Entity-Relationship modeling tblCashDisbursement Check No. tblPurchaseOrder PO No. tblCashDisbursement InventoryReceipt Inv Rec No. + Chk No tblInventoryReceipt Inv Rec No tblMaterialsInventory Inv. Stck No tblVendor Vendor No. tblPO InventoryReceipt PO No. + Inv Stck No. Check No. Inv Receipt No. Vendor No. PO No. Inv Stock No. 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 relations Example:

Let’s rewrite this ONE table as two separate tables (like we did last class) 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...

Entity-Relationship modeling Designations –1-1 (one to one) Person IDPlate ID SSN

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. tblInvoice InvoiceNo. CustNo.

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. tblInvoice InvoiceNo. 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 tblInventory ItemNo tblInvoice InvoiceNo ItemNo.InvoiceNo. tblInvoiceLine ItemNo InvoiceNo

Entity-Relationship diagrams tblCUSTOMER CustomerID CustomerID tblINVOICE InvoiceID tblINVITEM InventoryID InvoiceID tblITEM InventoryID InvoiceID InventoryID (1,M) (M,1) tblINVITEM InventoryID InvoiceID

Entity-Relationship diagrams

tblEMPLOYEE EMPNUM EMPNUM tblIDTAG TAGNUM PACKID tblTAGNO TAGNUM TAGNUM (1,M) tblTAGNO TAGNUM

Entity-Relationship diagrams

tblINDIVIDUAL SSN SSN TICKETS TICKETNO tblREGISTRATION STLICNO_PLATE STLICNO_P FINES CODE STLICNO_P (1,M) (M,1) TICKETS TICKETNO

Entity-Relationship diagrams

REA data model REA is specifically for Accounting Information Systems 3 types of entities –Resources –Events –Agents Basic Template

Resource A Get Resource A Internal Agent External Agent Inflow Participant Resource B Give Resource B Internal Agent External Agent Outflow Participant Economic Duality

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 –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 Give Inventory Get Cash 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

Cardinality How many “instances” (e.g. rows) in one entity can be linked to a specific instance in the other entity. A new concept: –Minimum cardinality –Maximum cardinality This is the number that we previously referred to a “cardinality” Notation for cardinality is (min,max) for one side of a relation or A:B for cardinality as we have discussed it.

Each of the panels in figure 5-7 describes one possible way that the company might structure the relationship between Sales and Cash Receipts. The CARDINALITY TELLS YOU QUITE A BIT ABOUT THE STRUCTURE OF THE DATABASE Sales has a (0,1) cardinality. That means that there may exist NO cash receipt for a given sale (the purchase is never paid for!) - or (the 1) tells you that for this setup there may be a single payment made at a later date- but there are no installment sales!! The (1,1) next to cash receipts tells us that there is exactly 1 sale that generated a given cash receipt (the receipt must be full payment). Sales Cash Receipts (0,1)(1,1)

Sales has a (0,N) cardinality. Again, there may exist NO cash receipt for a given sale (the purchase is never paid for) For this setup, the customer CAN make installments (more than one cash receipt transaction for a given sale) The (1,1) next to cash receipts tells us that there is exactly 1 sale that generated a given cash receipt (you can’t have a revolving account where payment is “on account”) - each payment is by Invoice - but may only be a partial payment on the invoice Sales Cash Receipts (0,N)(1,1)

Sales has (0,1) cardinality - Again, there may exist NO cash receipt for a given sale (the purchase is never paid for) or it may have a single subsequent payment - but NO INSTALLMENTS Each cash receipt of course must relate to some sale (the minimum of 1) and it may cover MORE THAN ONE SALE. So a payment can cover one or several invoices, but no partial payments are allowed! Sales Cash Receipts (0,1)(1,N)

Sales has (0,N) cardinality - Again, there may exist NO cash receipt for a given sale (the purchase is never paid for) or it may have subsequent payments (including installments) Each cash receipt of course must relate to some sale (the minimum of 1) and it may cover MORE THAN ONE SALE. This is what we typically think of as a revolving credit account Sales Cash Receipts (0,N)(1,N)

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