REA analysis and 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.

Slides:



Advertisements
Similar presentations
Database Design Using the REA Data Model
Advertisements

Business Processes, Data Modeling and Information Systems
Phase 1 Flat Files Phase 2 Event-Driven Database Phase 3 REA-Model Database Limitations: Redundant data; Anomalies Limitations: Loss of non- economic.
Copyright © 2015 Pearson Education, Inc. Database Design Chapters 17 and
©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart 5-1 Accounting Information Systems 9 th Edition Marshall.
Concepts of Database Management Sixth Edition
FIS 431/631 Financial Information Systems: Analysis and Design REA Modeling Joe Callaghan Oakland University Department of Accounting & Finance.
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart1 of 121 C HAPTER 16 Implementing an REA Model in a Relational.
Agenda for Week 1/31 & 2/2 Learn about database design
Technology Review-II Professor Martin Professor Xiong CSUS
Database Design Using the REA Data Model
Entity-Relationship Model and Diagrams (continued)
Concepts of Database Management Seventh Edition
Implementing an REA Model in a Relational Database
Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall 18-1.
Database Basics Overview of Databases. Arrivederci Pacioli Five primary weaknesses of traditional accounting system (debits and credits): Focus on subset.
Database Design Using the REA Data Model
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
Database Design Using the REA Data Model
Chapter 6 Data Flow Diagramming Copyright © 2010 by The McGraw-Hill Companies, Inc. All rights reserved.McGraw-Hill/Irwin.
Database Design Using the REA Data Model
REA analysis and E-R diagramming Part I April 10, 2008.
Introduction to Accounting Information Systems
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
1 Chapter 1 Overview of Database Concepts. 2 Chapter Objectives Identify the purpose of a database management system (DBMS) Distinguish a field from a.
REA analysis and E-R diagramming December 2, 2008.
1 ER Modeling BUAD/American University Entity Relationship (ER) Modeling.
The REA Model. The REA model provides structure for developing an accounting database It helps to identify It helps to The REA Model.
Accounting Information Systems 9th Edition
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
© 2006 Prentice Hall Business Publishing Accounting Information Systems, 10/e Romney/Steinbart1 of 96 C HAPTER 17 Special Topics in REA Modeling for the.
Entity Relationship Diagrams (ERDs). Entity Relationship Diagram (ERD) documentation technique to represent relationship between entities in system. Think.
McGraw-Hill/Irwin © 2013 The McGraw-Hill Companies, Inc., All Rights Reserved. Chapter 7 Data Flow Diagramming.
Avoiding Database Anomalies
Normalization A technique that organizes data attributes (or fields) such that they are grouped to form stable, flexible and adaptive entities.
Acct 316 Acct 316 Acct 316 Data Modeling and Database Design 5 UAA – ACCT 316 Accounting Information Systems Dr. Fred Barbee Chapter.
Implementing an REA Model in a Relational Database
1 Relational Databases and SQL. Learning Objectives Understand techniques to model complex accounting phenomena in an E-R diagram Develop E-R diagrams.
Concepts of Database Management Eighth Edition Chapter 6 Database Design 2: Design Method.
Concepts of Database Management Sixth Edition Chapter 6 Database Design 2: Design Method.
Chapter 1Introduction to Oracle9i: SQL1 Chapter 1 Overview of Database Concepts.
Implementing an REA Model in a Relational Database
Lecture 4 Conceptual Data Modeling. Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship,
REA analysis and E-R diagramming 4/27/2011. What are we hoping to achieve? Tool for designing a database system to meet the needs of the organization.
Concepts of Database Management, Fifth Edition Chapter 6: Database Design 2: Design Methodology.
An Entity Relationship (ER) Diagram is a graphic that shows the interrelationship between entities in a database.
© 2006 Prentice Hall Business Publishing Accounting Information Systems, 10/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
© 2006 Prentice Hall Business Publishing Accounting Information Systems, 10/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
1 6 Concepts of Database Management, 5 th Edition, Pratt & Adamski Chapter 6 Database Design 2: Design Methodology Spring 2006.
BSA206 Database Management Systems Lecture 2: Introduction to Oracle / Overview of Database Concepts.
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
Entity Relationship Diagrams (ERDs)
Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall 18-1.
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
Database Design Chapters 17 and 18.
Implementing an REA Model in a Relational Database
View Integration and Implementation Compromises
Sales Order/Sale Entry Form
Implementing an REA Model in a Relational Database
ER MODEL Lecture 3.
Implementing an REA Model in a Relational Database
Accounting Information Systems 9th Edition
Database Design Using the REA Data Model
Database Design Chapters 17 and 18.
Database Modeling using Entity Relationship Model (E-R Model)
Database Design Using the REA Data Model
Entity-Relationship (E-R) Modeling
Presentation transcript:

REA analysis and 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-Agent 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) 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 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 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

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. 1M

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

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

Entity-Relationship diagrams

tblEMPLOYEE EMPNUM EMPNUM tblIDTAG TAGNUM PACKID tblTAGNO TAGNUM TAGNUM (1,M) tblTAGNO TAGNUM 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

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

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

Example WE-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 10 th 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.

Order Invty Receive Invty Cash Disb Inventory Cash Vendor Employee Vendor

Order Invty Receive Invty Cash Disb Inventory Cash Vendor Employee Vendor

Order Invty Receive Invty Cash Disb Inventory Cash Vendor Employee PO Vendor 1 M 1 M Here, there is only one employee… the purchase manager… that is called by the purchase order.

Order Invty Receive Invty Cash Disb Inventory Cash Vendor Employee PO PO- ItemID 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.

Order Invty Receive Invty Cash Disb Inventory Cash Vendor Employee PO Vendor 1 M 1 M ItemID PO- Line Item PO 1 1 M M We create a NEW table with a composite primary key to resolve the M-M dilemma.

Order Invty Receive Invty Cash Disb Inventory Cash Vendor Employee PO Vendor 1 M 1 M ItemID PO- Line Item PO 1 1 M M 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

Order Invty Receive Invty Cash Disb Inventory Cash Vendor Employee PO Vendor 1 M 1 M ItemID PO- Line Item PO 1 1 M M Again, we have a Many to Many relationship that we must resolve. 1 M M M

Order Invty Receive Invty Cash Disb Inventory Cash Vendor Employee PO Vendor 1 M 1 M ItemID PO- Line Item PO 1 1 M M 1 M Rec. Rept. - Line Item RR ItemID 1 1 M M Again, we create a NEW table with a composite primary key to resolve the M-M dilemma.

Order Invty Receive Invty Cash Disb Inventory Cash Vendor Employee PO RR PO Vendor RR Vendor 1 M 1 M ItemID PO- Line Item PO 1 1 M M 1 M Rec. Rept. - Line Item RR ItemID 1 1 M M 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.