2 Chapter 5: Data Modeling and Database Design 3/31/2017The REA Data ModelThe REA data model is a conceptual modeling tool specifically designed to provide structure for designing AIS data bases.Dr. Fred Barbee
3 Chapter 5: Data Modeling and Database Design 3/31/2017The REA Data ModelThe REA data model provides structure in two ways:By identifying what entities should be included in the AIS databaseBy prescribing how to structure relationships among the entities in the AIS databaseDr. Fred Barbee
4 Business Activities Business transactions are exchanges. Who “gets” what and who “gives” what in return are separate transactions.The exchange occurs between the business entity and usually an outside agent.The business gives something and then gets something in return.
5 Resources, Events, and Agents Every business transaction is made up of three components:Resources are the things of economic value exchanged.Events are the actual giving and getting of the resources.Agents are the people who actually make the exchange.
6 Steps and Documents in the Acquisition/Payment Process (as used in the SUA)
7 Steps and Documents in the Sales/Collection Process (as used in the SUA)
8 The Accounting Equation Assets = ClaimsAssets = Liabilities + Owner’s EquityAsset: economic resources owned by the business.Liability: obligations of the business to creditors.Equity: owner’s claims to the assets.
9 Four Basic Financial Statements Balance SheetAssets = Liabilities + EquityIncome StatementRevenues - Expenses = Net incomeStatement of Retained EarningsBeginning RE + Net income - Dividends = Ending RECash Flow StatementCash inflow - Cash outflow = Net cash flow
10 Traditional Approaches: User-View Orientation When data-modeling and IS design is too oriented toward the user’s views, problems arise:multiple information systemsduplication of datarestricted user-view leads to poor decision-makinginability to support change
11 Traditional Approaches: Financial Accounting Orientation Dominance of traditional accounting as the primary information provider leads to problems:single view of business entity using the accounting/balance sheet model:double-entry, debits and creditshigh level of aggregationignoring non-financial datainability to serve diverse enterprise-wide needsAssets = Liabilities + Owners’ Equity
13 Resources, Events, and Agents (REA) Model Developed in the ‘70's by Dr. Bill McCarthy of Michigan State UniversityThe definition of events is broad enough to encompass both operational and accounting transactions.Expands the scope and usefulness of AIS by making it capable of providing both financial and nonfinancial information.Data for each event is stored in disaggregated form.Outputs are subsequently produced by assembling the required data from the various records.Many firms have not adopted the REA model since it is a major change from the traditional double-entry approach.The REA or events perspective is increasingly seen as necessary to meet changing information needs.
14 Resources, Events, and Agents (REA) Model … An approach to database design meant to overcome problems with traditional approaches:formalized data modeling and design of ISuse of centralized databaseuse of relational database structurecollects detailed financial and non-financial datasupports accounting and non-accounting analysissupports multiple user viewssupports enterprise-wide planning
15 Resources, Events, and Agents (REA) Model … The REA model is an alternative accounting framework for modeling an organization’seconomic resourceseconomic eventseconomic agents, andtheir interrelationshipsA variation of entity-relationship diagramming (ERD) is used to model these relationships.42
16 Resources in the REA Model Economic resources are the assets of the company.able to generate revenueobjects that are scarce and under the control of the organizationcan be tangible or intangibleDoes not include some traditional accounting assets:for example, Accounts Receivablesartifacts that can be generated from other primary data42
17 Events in the REA ModelEconomic events are phenomena that effect changes in resources.a source of detailed data in the REA approach to databasesThree classes of events:operating events--what happensinformation events--what is recordeddecision/management events--what is done as a resultOnly operating events are included in the REA model.42
18 Agents in the REA Model Can be individuals or departments Can participate in eventsCan affect resourceshave discretionary power to use or dispose of resourcesCan be inside or outside the organizationclerksproduction workerscustomerssuppliers, vendorsdepartments, teams42
19 Resources, Events, and Agents (REA) Model … A variation of the entity-relationship diagramming (ERD) is used in REA modeling.Basic ERD symbols:entityattribute(optional)relationship(optional)42
20 Advantages of the REA Model Using REA can lead to more efficient operationshelps managers identify non-value added activities that can be eliminatedincreased productivity via elimination of non-value added activities generates excess capacitystoring both financial and nonfinancial data in the same central database reduces multiple data collection, data storage, and maintenancedetailed financial and nonfinancial business data supports a wider range of management decisionsincreased competitive advantage by providing more relevant, timely, and accurate information to managers43
21 Value Chain AnalysisCompetitive advantages from the REA approach can be see via value chain analysis.Value chain analysis distinguishes between primary activities (create value) and support activities (assist performing primary activities).REA provides a model for identifying and differentiating between these activities.Prioritizing Strategy: Focus on primary activities; eliminate or outsource support activities.43
22 Database Applications Phase 1Flat FilesPhase 2Event-DrivenDatabasePhase 3REA-ModelDatabaseLimitations:Not widely used;Requires detailed analysisLimitations:Redundant data;AnomaliesLimitations:Loss of non-economic information
23 Database Sales Order Entry/Cash Receipts System
25 Limitations of Transaction-Based Systems Event: a single business activity within a business process which involves resources and agentsTraditional event-based database systems tend to focus exclusively on economic events.loss of non-economic/non-financial informationREA is event-oriented versus event-based.includes non-economic and economic event information
26 Developing an REA Model: Overview Before developing the REA model, identify events and classify as:Operating events--activities that produce goods and servicesInformation events--activities associated with recording, maintaining, and reporting informationDecision/Management events--activities that lead to decisions being takenREA model uses only operating events.
27 Chapter 5: Data Modeling and Database Design 3/31/2017Basic REA templateDr. Fred Barbee
28 Chapter 5: Data Modeling and Database Design 3/31/2017The REA Data ModelGive-To- Get DualityResourcesEventsAgentsDr. Fred Barbee
29 Chapter 5: Data Modeling and Database Design 3/31/2017The REA Data ModelResources: Those things that have economic value to the firm.ResourcesEventsAgentsDr. Fred Barbee
30 Chapter 5: Data Modeling and Database Design 3/31/2017The REA Data ModelEvents: Various Business ActivitiesResourcesEventsAgentsDr. Fred Barbee
31 Chapter 5: Data Modeling and Database Design 3/31/2017The REA Data ModelAgents: People and Organizations that participate in events.ResourcesEventsAgentsDr. Fred Barbee
32 Chapter 5: Data Modeling and Database Design Developing an REA Diagram 3/31/2017Developing an REA DiagramDr. Fred Barbee
33 Step 1: Identify the Economic Exchange Events Chapter 5: Data Modeling and Database Design3/31/2017Step 1: Identify the Economic Exchange Events1Identify the pair of events that reflect the basic economic exchange (give-to-get duality relationship) in that cycle.Dr. Fred Barbee
34 Chapter 5: Data Modeling and Database Design Identify the PAIR of eventsOne GETOne GIVE3/31/2017Dr. Fred Barbee
35 Step 2: Identify Resources and Agents Chapter 5: Data Modeling and Database Design3/31/2017Step 2: Identify Resources and Agents2Identify the Resources affected by each event and the agents who participate in those events.Dr. Fred Barbee
36 Chapter 5: Data Modeling and Database Design 3/31/2017Identify . . .RESOURCES affected by each event.AGENTS who participate in the events.Dr. Fred Barbee
37 Step 3: Include commitment Events Chapter 5: Data Modeling and Database Design3/31/2017Step 3: Include commitment Events3Analyze each economic exchange event to determine whether it should be decomposed into a combination of one or more commitment events and an economic exchange event.Dr. Fred Barbee
38 Chapter 5: Data Modeling and Database Design 3/31/2017Include commitment events.Dr. Fred Barbee
39 Step 4: Determine Cardinalities of Relationships Chapter 5: Data Modeling and Database Design3/31/2017Step 4: Determine Cardinalities of Relationships4Determine the cardinalities of each relationship.Dr. Fred Barbee
40 Chapter 5: Data Modeling and Database Design 3/31/2017Determine cardinalities of relationships.Dr. Fred Barbee
41 Chapter 5: Data Modeling and Database Design 3/31/2017How many sales transactions can be linked to each individual customer?SalesCustomerHow many customers can be linked to each individual sales transaction?Dr. Fred Barbee
42 Chapter 5: Data Modeling and Database Design 3/31/2017CardinalitiesMinimum(1,N)MaximumDr. Fred Barbee
43 Chapter 5: Data Modeling and Database Design 3/31/2017The first number is the minimum cardinality. It indicates whether a row in this table must be linked to at least one row in the table on the opposite side of that relationship.Dr. Fred Barbee
44 Chapter 5: Data Modeling and Database Design 3/31/2017Minimum CardinalityThe minimum cardinality of a relationship indicates whether each row in that entity MUST be linked to a row in the entity on the other side of the relationship.Minimum cardinalities can be either 0 or 1.Dr. Fred Barbee
45 Minimum Cardinalities Chapter 5: Data Modeling and Database Design3/31/2017Minimum CardinalitiesA minimum cardinality of zero means that a new row can be added to that table without being linked to any rows in the other table.A minimum cardinality of one means that each row in that table MUST be linked to at least one row in the other tableDr. Fred Barbee
46 Chapter 5: Data Modeling and Database Design 3/31/2017CardinalitiesThe minimum cardinality of zero in the (0, N) cardinality pair to the left of the customer entity in the customer-sales relationship . . .Made toSales(0, N)Customer. . . indicates that a new customer may be added to the database without being linked to any sales events.Dr. Fred Barbee
47 Chapter 5: Data Modeling and Database Design 3/31/2017CardinalitiesThe minimum cardinality of 1 in the (1,1) cardinality pair to the right of the sales entity in the customer-sales relationship . . .Made toSales(1,1)(0, N)Customer. . . indicates that a new sales transaction CAN ONLY be added if it is linked to a customer.Dr. Fred Barbee
48 Chapter 5: Data Modeling and Database Design 3/31/2017The second number is the maximum cardinality. It indicates whether one row in that table can be linked to more than one row in the other table.Dr. Fred Barbee
49 Maximum Cardinalities Chapter 5: Data Modeling and Database Design3/31/2017Maximum CardinalitiesThe maximum cardinality of a relationship indicates whether each row in that entity CAN be linked to more than one row in the entity on the other side of the relationship.Maximum cardinalities can be either 1 or N.Dr. Fred Barbee
50 Maximum Cardinalities Chapter 5: Data Modeling and Database Design3/31/2017Maximum CardinalitiesA maximum cardinality of 1 means that each row in that table can be linked to at most only 1 row in the other table.A maximum cardinality of N means that each row in that table MAY be linked to more than one row in the other table.Dr. Fred Barbee
51 Chapter 5: Data Modeling and Database Design 3/31/2017CardinalitiesThe maximum cardinality of N in the (0,N) cardinality pair to the left of the customer entity in the customer-sales relationship . . .Made toSales(0, N)Customer. . . indicates that a given customer MAY be linked to many sales events.Dr. Fred Barbee
52 Chapter 5: Data Modeling and Database Design 3/31/2017CardinalitiesThe maximum cardinality of 1 in the (1,1) cardinality pair to the right of the sales entity in the customer-sales relationship . . .Made toSales(1,1)(0, N)Customer. . . indicates that a given sales transaction can only be linked to one customer.Dr. Fred Barbee
53 Determine Cardinalities Chapter 5: Data Modeling and Database Design3/31/2017Determine CardinalitiesCardinalities are not arbitrarily chosen by the database designer.They reflect facts about the organization being modeled and its business practices obtained during the requirements analysis stage of the database design process.Dr. Fred Barbee
54 Cardinalities: Types of Relationships Chapter 5: Data Modeling and Database Design3/31/2017Cardinalities: Types of RelationshipsThree basic types - depending on the maximum cardinality associated with each entity.A one-to-one relationship (1:1)A one-to-many relationship (1:N)A many-to-many relationship (M:N)Dr. Fred Barbee
55 Types of Relationships Panel A: One-to-One (1:1) RelationshipSalesCash Receipts(0,1)(1,1)
56 Types of Relationships Panel B: One-to-Many (1:N) RelationshipSalesCash Receipts(0,N)(1,1)
57 Types of Relationships Panel C: One-to-Many (1:N) RelationshipSalesCash Receipts(0,1)(1,N)
58 Types of Relationships Panel D: Many-to-Many (M:N) RelationshipSalesCash Receipts(0,N)(1,N)
59 Chapter 5: Data Modeling and Database Design 3/31/2017Build a Set of Tables to Implement an REA Model of an AIS in a Relational DatabaseDr. Fred Barbee
60 Implementing an REA Diagram in a Relational Database Chapter 5: Data Modeling and Database Design3/31/2017Implementing an REA Diagram in a Relational DatabaseAn REA diagram can be used to design a well-structured relational database.A well-structured relational database is one that is not subject to update, insert, and delete anomaly problems.Dr. Fred Barbee
61 Three Step ProcessCreate a table for each distinct entity and for each many-to many relationshipAssign attributes to appropriate tablesUse foreign keys to implement one-to-one and one-to-many relationships
62 Chapter 5: Data Modeling and Database Design 3/31/2017Implementing an REA DiagramDr. Fred Barbee
64 Create TablesFrom the previously discussed REA diagram, nine tables would be created: one for each of the seven entities and one for each of the many-to-many relationships.InventoryPurchasesEmployeesVendorsCashierCash disbursementsCashPurchases-inventoryPurchases-cash disbursements
65 Assign Attributes for Each Table Primary keys: Usually, the primary key of a table representing an entity is a single attribute.Other Attributes: Additional attributes are included in each table to satisfy transaction processing requirements.
66 Chapter 5: Data Modeling and Database Design 3/31/2017Implementing an REA DiagramDr. Fred Barbee
67 Chapter 5: Data Modeling and Database Design 3/31/2017Implementing an REA DiagramDr. Fred Barbee
68 Documentation of Business Practices REA diagrams are especially useful for documenting an advanced AIS built using databases.REA diagrams provide information about the organization’s business practices
69 Documentation of Business Practices The zero minimum for the sales event indicates that credit sales are madeThe N maximum for the sales event means that customers may make installment paymentsSales- Cash ReceiptsCash ReceiptsSales(1, N)(0, N)
70 Documentation of Business Practices The one minimum for the cash receipts event indicates that cash is not received prior to delivering the merchandiseThe N maximum for the cash receipts event means that customers may pay for several sales with one checkSales- Cash ReceiptsCash ReceiptsSales(1, N)(0, N)
71 Extracting Information From the AIS A complete REA diagram serves as a useful guide for querying an AIS database.Queries can be used to generate journals and ledgers from a relational database built on the REA model.
72 Extracting Information From the AIS (0, 1)(1, N)SalesCashcollectionsEach sales transaction is paid in full by a cash collection event.Each customer payment may be for more than one sale.What is the query logic?Total accounts receivable is the sum of all sales for which there is no remittance number.
73 Extracting Information From the AIS (1, 1)SalesCashcollectionsEach sales transaction can be paid in installments.Each customer payment is for just one sale.What is the query logic?(1) sum all sales; (2) sum cash collections; then A/R = (1)-(2)
74 Extracting Information From the AIS (0, 1)(1, 1)SalesCashcollectionsEach sales transaction is paid in full by a cash collection event.Each customer payment is for one sale.What is the query logic?Total accounts receivable is the sum of all sales for which there is no remittance number.
75 Extracting Information From the AIS SalesCashcollectionsEach sales transaction may be paid for in installments.Each customer payment may be for more than one sale.What is the query logic?(1) Sum all sales; (2) Sum all cash collections; Then A/R = (1)-(2)
76 Let’s Review with a Little Help From My Friends ….
77 An REA Model of an Economic Exchange William E. McCarthy*Michigan State University(These slides may be copied as long as original source is cited)*http://www.msu.edu/user/mccarth4/
78 Cookie-Monster (the customer) and Elmo (the entrepreneur) meet in the (real or virtual) marketplace, thus setting the stage for an Economic Exchange
79 Economic Exchange Pattern EventAgentResourcedualityREASource:W. E. McCarthy “The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment,” The Accounting Review, July 1982, ppW.E. McCarthy “The REA Modeling Approach to Teaching Accounting Information Systems,” Issues in Accounting Education, November 2003, pp (source of following slides)
80 Cookie-Monster (the customer) and Elmo (the entrepreneur) engage in a SHIPMENT (transfer of Cookie Inventory)
81 outside participation outside participation Economic ResourceCOOKIESinside participationEconomic AgentELMOstock-flowEconomic EventSALEEconomic Agentoutside participationcookiemonsterGivedualityTakeoutside participationEconomic Agentstock-flowEconomic EventEconomic Agentinside participationEconomic ResourceREA model of cookie sale from entrepreneur’s (ELMO) perspective
82 Cookie-Monster (the customer) and Elmo (the entrepreneur) engage in a PAYMENT (transfer of Cash)
83 outside participation outside participation Economic ResourceCOOKIESinside participationEconomic AgentELMOstock-flowEconomic EventSALEEconomic Agentoutside participationcookiemonsterGivedualityTakeoutside participationEconomic Agentcookiemonsterstock-flowEconomic EventCASHRECEIPTEconomic Agentinside participationEconomic ResourceELMOCASHREA model of cookie sale from entrepreneur’s (ELMO) perspective
84 outside participation GiveTakeEconomic Resourceinside participationoutside participationstock-flowEconomic EventCash ReceiptEconomic AgentSalespersonCustomerCashierCashCookiesdualitySalemore general exchange model from the entrepreneur’s (ELMO’s) internal perspective
85 COOKIES-stockflow-SALE Product#DescriptionPriceQOHP-1Chocolate Chip1.05200P-2Chocolate.95205P-3Peanut Butter1.0097P-4Pecan1.10257Product#Invoice#QuantityP-2I-15P-310I-220P-4I-39P-1I-44SALE-duality-CASH_RECEIPTSALEInvoice#Dollar AmountDateSalesperson Employee#Customer #I-114.751JULE-1234C-987I-220.002JULE-1235C-888I-39.903JULE-1236C-999I-49.205JULE-1237Invoice#Receipt TimestampAmount AppliedI-12JUL083014.75I-23JUL08002.005JUL080018.00I-38JUL11459.90I-49.20Partial Database for Elmo’s Cookie BusinessWhy is this invoice amount $14.75 ??How is customer paying for this ???
86 A business process is a set of activities that takes one or more kinds of input and creates an output that is of greater value to the customer (Hammer and Champy)business processlaborcookiesConversion Cyclebusiness processRevenue Cyclecashbusiness processcookie ingredientsAcquisition Cyclecashvalue chainA value chain is a purposeful network of business processes aimed at assembling the individual components of a final product (i.e., its portfolio of attributes) of value to the customer (Porter and Geerts/McCarthy)Part of ELMO’s Value Chain for Providing Cookies
87 Enterprise Information Basic Systems Counting Accounting Semantic infrastructure of system matches extended REA patternEnterpriseInformationSystemsBasicAccountingSystemsCountingartifactse-collaborationsystemsEnterprise Systems classification structure is from David, McCarthy & Sommer, Communications of the ACM, May 2003, pp
88 Different perspectives on REA modeling needed for enterprise modeling (value chains) and collaboration space (supply chains)Enterprise modeling (as evidenced in normal ERP systems) is done from the perspective of one company or entrepreneur. Business processes are viewed as components of a single value chain. A single exchange (like the sale of a product for money) would be modeled twice, once in the enterprise system of each trading partner.Collaboration space modeling (as evidenced in ebXML or ISO Open-edi) is done from a perspective independent of each trading partner. A single exchange is modeled once in independent terms that can be then mapped into internal enterprise system components. Supply chains are networks of business processes that alternate internal transformations and external exchanges (definition due to Bob Haugen).REA modeling works in both cases and the independent to trading partner mapping is absolutely straightforward and completely defined.
89 Used for collaboration space modeling BusinessProcessIndependent view ofInter-enterprise eventsEnterpriseIllustration of Perspective: Trading Partner vs. IndependentTrading Partner view ofInter-enterprise events (upstream vendors and downstream customers)Blue arrows represent flow of goods, services, and cash between different companies; green arrows represent flows within companiesUsed for collaboration space modelingSOURCE: Adapted from ISO , K. Morita
90 COOKIES ELMO SHIPMENT ELMO CASH cookie monster cookie monster Economic ResourceEconomic AgentCOOKIESfromELMOstock-flowEconomic EventSHIPMENTEconomic Agenttocookiemonsterinitiating transferdualityresponding transferEconomic AgenttoELMOstock-flowEconomic EventPAYMENTEconomic AgentfromEconomic ResourcecookiemonsterCASHREA model of cookie sale from independent (collaboration space) perspective
91 Ontological Extensions to the REA Model (Geerts and McCarthy) Type images for basic objects allows specification of policies and controls plus abstract specification of negotiation componentsCommitment images for economic events allows specification of contracts and agreementsState machine model allows specification and ordering of business events as collaboration space messaging and/or internal workflowAggregation of binary collaborations allows mediated collaboration with third partiesSOURCE: Geerts and McCarthy, The Ontological Foundations of REA Enterprise Information Systems, 2003.
92 Bilateral Collaboration Economic Resource Type Mediated Collaboration ISO Open-edi Ontology Collaboration ModelBilateral CollaborationgovernsEconomic EventEconomic ResourceEconomic AgentstockflowfromtoEconomic ContractEconomic CommitmentreciprocalfulfillsestablishdualityEconomic Resource TypetypifiesspecifiesEconomic Event TypeBusiness RolequalifiesreservesinvolvesPartnerThird PartyMediated CollaborationBusiness TransactionparticipatesrequiresAgreementRegulatorconstrainsSOURCE: Adapted from ISO , W.E. McCarthy
93 Cookie-Monster and Elmo after their economic exchange (both economic agents have now reached higher levels of utility)
94 Cookie Monster and Elmo are of course characters from the Public Broadcasting Service TV show Sesame Street*. Their use here is only illustrative. Cookie Monster is a great example of a typical buyer (has money, wants goods) because he is most happy when he has a cookie to eat. The use of Elmo as a typical seller (has goods, wants money) is only a convenient illustration. * see
95 Online resources:AIS Romney 2006 notes Chapter15 Database Design Using the REAAIS Romney 2006 notes Chapter 16 Implementing an REA