Bài giảng Enterprise information systems - Chapter 10: View Integration and Implementation Compromises

Chapter 10View Integration and Implementation CompromisesChapter Learning ObjectivesIdentify the steps needed to integrate multiple business process level REA modelsComplete an integration of two or more business process level REA conceptual modelsIdentify and create common conceptual level, logical level, and physical level implementation compromisesExplain common reasons for compromising implementationsIdentify information needs that require information from multiple tables in multiple business processesCreate queries to satisfy information needs that require information from multiple business processes2View Modeling and View IntegrationRecall that one reason we use models in designing information systems is to reduce complexity and to simplify the reality into manageable pieces. The separate modeling of each transaction cycle is called “view modeling”.Combining the models together to form a complete whole is called “view integration”.3View IntegrationStep 1: Identify the common entities in two conceptual level viewsEach pair of cycles that is connected in the value chain shares at least one common resource. Many cycles have at least one agent in common.Cash receipt events and Cash disbursement events exist in multiple cycles.4Step 2: Merge the common entities, resolving entity and attribute conflictsEntity name conflictsSynonyms: two or more different entity names used to represent the same entityHomonyms: one entity name used to represent two or more different entities Attribute conflictsDifferent attributes used to describe the same entity in various viewsInclude all attributes needed for all transaction cycles as attributes for the entity in the integrated modelView Integration5View IntegrationStep 3: Resolve relationship conflicts, including name conflicts and structural conflictsEnsure each relationship has a unique nameEnsure cardinalities are appropriate for relationships once common entities are merged6Revenue Cycle View7Acquisition Cycle View8Identify the common entities9 Merge on Common Entities10Resolve Relationship Name Conflicts11Implementation CompromisesConceptual Level CompromisesExclusion of an entity (usually a resource) because of inadequate measurement toolsE.g. labor and use of fixed assets, supplies, and services in non-conversion processesExclusion of a relationship because of inadequate traceability or because no decision information is needed regarding that relationshipCaution should be exercised because decision information may be needed at a later point in time12Implementation CompromisesConceptual Level CompromisesConsolidate conceptually congruent entities e.g. events that always happen simultaneously13Implementation CompromisesConceptual Level CompromisesMaterialization of tasks as entitiesE.g. Request for Quote, Receive BidsUse “what is needed to plan, control, execute, and evaluate” criteria to determine when to separately model “steps needed to achieve an event”If attributes are needed for decision-making purposes and they can’t be stored within the existing event entities, often the tasks will need to be materialized as entities 14Implementation CompromisesLogical Level CompromisesLoad considerations discussed in chapter 6 are actually an implementation compromise. A “pure” relational database should never include a null value.15Implementation CompromisesLogical Level CompromisesPosting keys of similar entities in combination to avoid null values OR Combination of similar entities without a generalization relationshipE.g. creating a column called “Payee” in cash disbursement to enable posting a foreign key from Suppliers, Employees (for payroll checks), Creditors (for loan payments), etc. without causing null values. Disallows enforcement of referential integrityMay instead combine similar entities into one entity and then create the relationship. E.g. Peoplesoft Enterprise One Address Book combines Customers, Suppliers, Employees 16Combined entity key posting17Combined entity key posting18Combination of Entity Sets without Generalization19Implementation CompromisesPhysical Level CompromisesStorage of derivable attributesStatic derivable attribute storage is advised if it facilitates querying; volatile derivable attribute storage should be done only if software is capable of triggers (stored formulae rather than stored data values for the volatile derivable attributes)Event History Roll-upA benefit of databases is the “virtual close” – that is, the ability to produce financial statements without actually closing the books. The disadvantage of this is that the database can get too large to allow efficient processingSolution: once event data is no longer needed in disaggregated format, “roll” it up into a single event. 20Event History Roll-up21Multiple Cycle Information NeedsMany information needs combine data from multiple transaction cyclesCash balanceQuantity on Hand of Inventory TypesInventory total cost valueCost of Goods SoldMany others22Query for Cash BalanceDetermine which table contains the cash receipt date (usually the cash receipt event table) and make sure the same table also contains the cash receipt amount field Determine which table contains the cash disbursement date (usually the cash disbursement event table) and make sure the same table also contains the cash disbursement amount fieldCreate a query that establishes the ending date constraint (with no beginning date constraint) and sums the cash receipt dollar amount identified in step 1Create a query that establishes the ending date constraint (with no beginning date constraint) and sums the cash disbursement dollar amount identified in step 2Create a query that subtracts the total in step 4 from the total in step 323Query for Cash BalanceStep 1: Identify table with cash receipt date and amount fieldsStep 2: Identify table with cash disbursement date and amount fields24Query for Cash BalanceStep 3: Query to sum date constrained cash receiptsStep 4: Query to sum date constrained cash disbursements25Query for Cash BalanceStep 5: Compute Cash Balance (Step 3 – Step 4)Results as of May 31, 201026Query for Inventory Type Quantity on HandDetermine which table contains the purchase dateUsually in purchase event tableDetermine which table contains the purchase quantity and the inventory item id Usually in purchase-inventory stockflow relationship tableDetermine which table contains purchase return date Usually in purchase return event tableDetermine which table contains the quantity returned and the inventory item id Usually in purchase return-inventory stockflow relationship table27Determine which table contains the sale dateUsually in sale event tableDetermine which table contains the quantity sold and the inventory item id Usually in sale-inventory stockflow relationship tableJoin the tables identified in steps 1 and 2 (with purchase dates & quantities), group by inventory item, set the ending date constraint (with no beginning date constraint) and sum the quantity purchased to get the total quantity purchased per inventory item. Include the inventory item id attribute in the query result to provide a means for linking to other intermediate results.Query for Inventory Type Quantity on Hand28Join the tables identified in steps 3 and 4 (with purchase return dates and quantities), group by inventory item, set the ending date constraint (with no beginning date constraint) and sum the quantity returned to get the total quantity returned per inventory item. include the inventory item id attribute in the query result to provide a means for linking to other intermediate results Join the tables identified in steps 5 and 6 (with sale dates and quantities), group by inventory item, set the ending date constraint (with no beginning date constraint) and sum the quantity sold to get the total quantity sold per inventory item. include the inventory item id attribute in the query result to provide a means for linking to other intermediate resultsQuery for Inventory Type Quantity on Hand29Query for Inventory Type Quantity on HandJoin the results from steps 7 (purchase quantities by item id) and 8 (purchase return quantities by item id). Change the join type to include all records from the total quantity purchased query and the matches from the total quantity returned query. The null to zero (Nz) function is necessary in the calculation to subtract total quantity returned from total quantity purchased. E.g. Nz(SumPurchaseQty) – Nz(SumQtyReturned). 30Join the results from steps 10 (unreturned purchase quantities by item id) and 9 (quantities sold by item id). Change the join type to include all records from the total unreturned quantities purchased query and the matches from the total quantity sold query.Nz function is needed in the calculation to subtract total quantity sold from total unreturned purchase quantity. E.g. Nz(SumUnreturnedPurchaseQty) – Nz(SumSaleQty)This query result yields a separate total quantity on hand for each inventory typeQuery for Inventory Type Quantity on Hand31Steps 1, 2, and 7 Constrain purchase date, sum quantities purchased for each inventory typeQuery for Inventory Type Quantity on Hand32Steps 3, 4, and 8: Constrain purchase return date; sum quantities returned by inventory typeQuery for Inventory Type Quantity on Hand33Steps 5, 6, and 9: Constrain sale date; sum quantities sold for each inventory typeQuery for Inventory Type Quantity on Hand34Step 10: Join Quantities purchased and returned to calculate unreturned purchase quantitiesQuery for Inventory Type Quantity on Hand35Step 11: Join net purchase quantities and quantities sold to calculate quantity on hand Result for May 31, 2010Query for Inventory Type Quantity on Hand36To calculate inventory cost valueIf applying an inventory costing assumption such as weighted average unit cost, first-in-first-out (FIFO), or last-in-first-out (LIFO)Build on the quantity on hand queries Build queries to determine assumed unit costsMultiply Quantity on Hand by Assumed Unit Cost If applying actual costs based on specific identificationNeed queries to specifically identify which inventory items were included in each sale and assign costs accordinglyFIFO, LIFO, and actual costs based on specific identification require very complex queries with programming beyond the scope of this courseQuery for Inventory Type Cost Value37Query for Inventory Type Cost ValueQuery to Calculate Weighted Average Unit Cost38Query for Inventory Type Cost ValueQuery to Calculate Weighted Average Unit Cost: Constrain purchase end date, calculate purchase line extensions39Query to Calculate Weighted Average Unit Cost: Sum purchase quantities and purchase line extensionsQuery for Inventory Type Cost Value40Query to Calculate Weighted Average Unit Cost: Divide total purchase line extensions by quantities to get weighted average unit costsQuery for Inventory Type Cost Value41Query for Inventory Type Cost ValueMultiply QOH by WAUC to get total cost value per item42Query for Inventory Type Cost ValueSum cost values per item to get total inventory cost valueResult for May 31, 201043Query for Cost of Goods SoldDetermine which table contains the sale dateusually this is in the table that represents the sale eventDetermine which table contains the sale quantities usually this is in the table that represents the stockflow relationship between sale and inventoryJoin the tables together; set date constraints for the beginning and ending of the income statement period; group by inventory id, and sum the quantity soldJoin a weighted average unit cost query result to the quantities sold result; multiply the quantity sold by the weighted average unit cost yields total weighted average cost separated by inventory itemsCreate a final query that sums the weighted average cost per inventory item sold to get the total COGS for the income statement 44Query for Cost of Goods SoldSteps 1, 2, 3: Constrain sale date, group by inventory item ID, and sum sale quantity45Query for Cost of Goods SoldStep 4: Multiply quantities sold by weighted average unit costs to get cost of goods sold per item46Query for Cost of Goods SoldStep 5: Sum cost of goods sold per item to get total cost of goods soldResult for May 1-31, 201047SummaryTo reduce complexity, in practice separate conceptual models are often constructed based on different views (views may be separated by transaction cycle or by some other delineation)Once each view is modeled, the views must be integrated to form a complete conceptual model and then converted to the logical levelCompromises often must be made to the “theoretic ideal” conceptual, logical, or physical level models based on insufficient measurement techniques, practical considerations and other constraintsQueries often require integration of data from different transaction cycles; an integrated database supports such complex queries48Chapter 10End of Chapter