1. REA analysis and E-R diagramming Part I April 10, 2008

2. What are we hoping to achieve? Tool for designing a database system to meet the needs of the organization –or the system - if you are not considering an enterprise wide system (ERP). REA modeling (ERA modeling, REA analysis, etc.) 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.

3. 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?

4. Some of the usual suspects… Entities Relations Events Resources Agents Locations Concatenated keys Cardinality

5. Resource-Event-Agent modeling REA modeling is a hot topic in systems circles It has gone through several name/content variations –ERA modeling (more of a focus on events - typically this is the way it is done - but the name is not as easy to remember) –REAL Resources Events Agents Locations Some books combine REA and E-R diagramming and some make no distinction –IT CAN GET CONFUSING

6. 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?

7. REA analysis Think back to the purchase order in the SUA that we looked at a few days ago…

8. Where Who What

9. Entity-Relationship diagramming Sometimes called REA diagramming (a specific form of E-R) 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

10. Entity-Resource-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

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

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

13. Entity-Resource-Agent modeling Entity Relationship -Describes how two entities relate Attribute -Specifies an entity (a record) -Resource - such as merchandise or cash -Person (what we referred to as entities in DFDs) -Location (such as the cash register) -Note that we never specified this before -Event

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

15. Entity-Relationship modeling

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

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

18. 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:

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

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

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

22. 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)

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