rea analysis and e-r diagramming part i april 10, 2008
TRANSCRIPT
REA analysisand
E-R diagramming
Part IApril 10, 2008
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.
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• Relations• Events• Resources• Agents• Locations• Concatenated keys• Cardinality
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
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
• 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
Entity-Resource-Agent modelingbasic template
Event
ResourceInternalagent
Location(if needed)
ExternalAgent
(if needed)
Event
ResourceInternalagent
Location(if needed)
ExternalAgent
(if needed)
These are allconsideredentities
Entity-Resource-Agent modeling Example
SellMerchandise
MerchandiseSalesperson
Customer
ReceiveCustomerpayment
Cash
CashRegister
decreases
increases
Takes place at
Takes place at
Collects payment
Sold by
Sold to
Received from
Resultsin
Now we add relations
Entity-Resource-Agent modelingwith diamonds
SellMerchandise
MerchandiseSalesperson
CashRegister
Customer
ReceiveCustomerpayment
Cash
decreases
increases
Takes place at
Collects payment
Sold by
Sold to
Received fromTakes place atR
esul
ts
in
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
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
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 modeling
REGISTRATIONSSN LAST_NAME FIRST_NAME PHONE_NO LIC_PLATE_ST LIC_PLATE_NO123-34-5678 Curry Dorothy (916)358-4448 CA 123 MCD134-56-7783 Fong May (916)563-7865 CA 253 DAL
Example from last classNotice 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...
Person IDSSN LAST_NAME FIRST_NAME PHONE_NO123-34-5678 Curry Dorothy (916)358-4448134-56-7783 Fong May (916)563-7865
Plate IDLIC_PLATE_NO LIC_PLATE_ST SSN123 MCD CA 123-34-5678253 DAL CA 134-56-7783
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.
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