View Integration and Implementation Compromises

1. View Integration and Implementation Compromises Chapter 10

2. Chapter Learning Objectives • Identify the steps needed to integrate multiple business process level REA models • Complete an integration of two or more business process level REA conceptual models • Identify and create common conceptual level, logical level, and physical level implementation compromises • Explain common reasons for compromising implementations • Identify information needs that require information from multiple tables in multiple business processes • Create queries to satisfy information needs that require information from multiple business processes

3. View Modeling and View Integration • Recall 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”.

4. View Integration • Step 1: Identify the common entities in two conceptual level views • Each 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.

5. Revenue Cycle View

6. Acquisition Cycle View

7. Identify the common entities

8. View Integration • Step 2: Merge the common entities, resolving entity and attribute conflicts • Entity name conflicts • Synonyms: two or more different entity names used to represent the same entity • Homonyms: one entity name used to represent two or more different entities • Attribute conflicts • Different attributes used to describe the same entity in various views • Include all attributes needed for all transaction cycles as attributes for the entity in the integrated model

9. Merge on Common Entities

10. View Integration • Step 3: Resolve relationship conflicts, including name conflicts and structural conflicts • Ensure each relationship has a unique name • Ensure cardinalities are appropriate for relationships once common entities are merged

11. Resolve Relationship Name Conflicts

12. Implementation Compromises • Conceptual Level Compromises • Exclusion of an entity (usually a resource) because of inadequate measurement tools • E.g. labor and use of fixed assets, supplies, and services in non-conversion processes • Exclusion of a relationship because of inadequate traceability or because no decision information is needed regarding that relationship • Caution should be exercised because decision information may be needed at a later point in time

13. Implementation Compromises • Conceptual Level Compromises • Consolidate conceptually congruent entities

14. Implementation Compromises • Logical Level Compromises • Load considerations • A “pure” relational database should never include a null value.

15. Implementation Compromises • Logical Level Compromises • Posting keys of similar entities in combination to avoid null values OR Combination of similar entities without a generalization relationship

16. Implementation Compromises • Physical Level Compromises • Storage of derivable attributes • Static 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-up • A 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 processing • Solution: once event data is no longer needed in disaggregated format, “roll” it up into a single event.

17. Multiple Cycle Information Needs • Many information needs combine data from multiple transaction cycles • Cash balance • Quantity on Hand of Inventory Types • Inventory total cost value • Cost of Goods Sold • Many others

18. Summary • To 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 level • Compromises often must be made to the “theoretic ideal” conceptual, logical, or physical level models based on insufficient measurement techniques, practical considerations and other constraints • Queries often require integration of data from different transaction cycles; an integrated database supports such complex queries