Data decomposition is recorded using a Data Decomposition Diagram, which can be built with the Data Model List tool. The Data Model Diagram, which shows relationships between subject areas and between entity types, is used to confirm the decomposition.
The same principles used for decomposition of activities are used for decomposing data. Business object type classification yields corresponding structures on both sides of the model, and decomposing by life-cycle on the activity side often reveals new business object types on the data side.
Following the Procurement example in Decomposing Activities, the subject area procurement, corresponding to the like-named function, is the starting point for data decomposition.
PROCUREMENT decomposes into a set of subject areas based on reasonable, proposed business object types:
Supplier management can be further classified into subject areas based on the distinct proposed business object types suppliers, supplier products, supplier contracts, and supplier evaluations. This decomposition is depicted in the following illustration.
Each of the subject areas has a single central entity type for which instances can be imagined, that is, supplier, supplier product, and so forth. The functions associated with each subject area can be considered to deal with entities of that type as they make their way through life. Since these conditions are true, the lowest level subject areas in the illustration must be primitive subject areas.
On the data side of the model, decomposition ends at the primitive subject area. Each primitive subject area is composed of a central entity type and its dependents.
The most common mechanism used to model data once decomposition concludes is normalization, described in the chapter "Analyzing Data."
For example, consider the primitive subject area suppliers. It is identified as a primitive subject area because it is represented by a single central entity type, supplier. Business users of the application are likely to recognize supplier as a significant concept. However, supplier may not be fully normalized as it stands.
For example, each supplier might have multiple addresses. Each address might fulfill a particular role. The supplier might have one address for payment, one address to contact for shipping queries, and another address to contact for product problems.
Assume that the identifier for a single occurrence of an address of supplier is based on who the supplier is and which role the address fulfills. Further assume that the business has identified a standard set of roles for which each supplier must provide an address and that the identifier of each is a designed attribute.
Following the rules of normalization, supplier, supplier address and supplier address role must be separated into their own entity types, as shown in the following illustration.
Supplier is the central entity type; supplier address and supplier address role are its dependents.
|
Copyright © 2014 CA.
All rights reserved.
|
|