Enterprise Information Systems: A PatternBased Approach By Dunn, Cherrington, and Hollander

1
Enterprise Information Systems A Pattern-Based
ApproachBy Dunn, Cherrington, and Hollander
Chapter 10 View Integration and Implementation
Compromises As modified by JKW
2
Implementation Compromises

• Conceptual Level Compromises
• Deciding not to include 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
• Deciding not to include 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

3
Implementation Compromises

• Conceptual Level Compromises (continued)
• Collapsing conceptually congruent entities
• (usually events, e.g. events that happen
  simultaneously)
• Materializing Tasks as Entities
• E.g. Request for Quote, Receive Bids
• Normally these would be tasks included within the
  event Purchase Requisition
• Use 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 cant be stored within the
  existing event entities, often the tasks will
  need to be materialized as entities

4
Implementation Compromises

• Logical Level Compromises
• Load considerations discussed in earlier are
  actually an implementation compromise. A pure
  relational database should never include a null
  value.
• Posting keys of similar entities in combination
  to avoid null values OR Combination of similar
  entities without a generalization relationship
• E.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 integrity
• May instead combine similar entities into one
  entity and then create the relationship.
• E.g. JD Edwards Address Book combines Customers,
  Suppliers, Employees

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

6
View Integration

• Steps in view integration for REA business
  process level models
• 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.

7
View Integration

• Steps in view integration for REA business
  process level models
• Step 2 Merge the common entities, resolving
  entity and attribute conflicts
• Resolve name conflicts, such as synonyms and
  homonyms
• If different attributes have been identified as
  information needs for the same entity, include
  all attributes needed for all transaction cycles
  as attributes for the entity in the integrated
  model

8
View Integration

• Steps in view integration for REA business
  process level models
• 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

9
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
• E.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 integrity
• May instead combine similar entities into one
  entity and then create the relationship.
• E.g. JD Edwards Address Book combines Customers,
  Suppliers, Employees

10
Example of combined entity key posting
Supplier
(0,N)
(0,1)
name
SupplierID
Note Participate2 is employee processing of
payment Participate3 is employee receiving
payment (paycheck)
Cash Disbursement
(0,N)
(1,1)
Employee
(0,N)
(0,1)
amount
date
Cd
name
EmplID
(0,1)
Lender
(0,N)
name
LenderID
11
Example of combined entity key posting
Cash Disbursement
Employee
Implements Participate2 Implements
Participate1, 3, and 4
Supplier
Lender
12
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 activity 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.

13
Example of Event Activity Roll-up
Sale
becomes
Sale
14
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