Phase 1 Flat Files Phase 2 Event-Driven Database Phase 3 REA-Model Database Limitations: Redundant data; Anomalies Limitations: Loss of non- economic information Limitations: Not widely used; Requires detailed analysis Database Applications
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 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?
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
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?
Think back to the purchase order in the SUA that we looked at a few days ago…
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
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
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
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
The REA Data Model ResourcesEventsAgents Give-To- Get Duality
The REA Data Model ResourcesEventsAgents Resources : Those things that have economic value to the firm.
The REA Data Model ResourcesEventsAgents Events : Various Business Activities
The REA Data Model ResourcesEventsAgents Agents: People and Organizations that participate in events.
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
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