¤ Gather user view sources
First select the layouts to be analyzed. It is not necessary to analyze every layout. Try to select a sample that covers the full range of data used by the system; the master files or database must be analyzed, plus all heavily used screen layouts and reports. Only include layout forms and lightly used layouts if they appear to contain further basic implied attribute types, or if they are considered to be documents of major importance by end users.
Each layout is examined, and its fields and keys are highlighted for contrast. Objects such as page numbers, processing dates, and line sequence number should be omitted unless they are vital to the purpose of the system (e.g., if they identify another field).
¤ Develop initial data analysis diagrams
Draw first versions of each data analysis diagram by working downward from the top left of each layout. At this stage, do not attempt to check that all the rules and guidelines have been obeyed, or to optimize the shape of the diagram.
¤ Refine data analysis diagrams
Once you have drawn the initial diagrams, produce second versions that obey the rules and follow the guidelines, including the "hierarchical downwards" convention. Check that the names of the same field on different charts are consistent, and note any anomalies on the problems and issues list.
¤ Perform canonical synthesis
Canonical synthesis is best performed with automated tools. When you perform the synthesis manually, you develop a key-oriented list by analyzing each data analysis diagram in turn.
If difficulties arise during the synthesis (e.g., because of possible synonyms), record them on the problems and issues list and refer them to appropriate users.
~ Analysis of First Data Analysis Diagram
For each key:
1. Create an entry in the key-oriented list that corresponds to the key and enter an appropriate name for the implied entity type.
2. Create an entry in the index.
3. Create an entry for each non-key field that is dependent on the key in this view.
For each multiple association:
1. If joining two keys, enter an association membership against both the key groups -- 1:M for the key at the multiple end of the association, and 1:1 for the other.
2. If a non-key field points to a key, it belongs to the key group as a secondary key.
3. If a key has a multiple association with a non-key field, add the non-key field as a temporary identifier. It will probably be a key in subsequent views. If the non-key field has no other fields dependent on it, it will be changed in the key-oriented list to become a multi-valued field corresponding to the key field.
~ Analysis of Subsequent Data Analysis Diagrams
For each key:
1. Check if it is already represented as a key in the index. If not, proceed as above; then check that it does not already appear in some list as a non-identifying field. If it does, follow the guidelines for building key-oriented lists.
2. Add any new non-key fields that are dependent on this key in this diagram to the existing list against the key group identified by the key. If any of the fields are already in the index as keys, follow the guidelines for building key-oriented lists.
3. If the key is already included in a composite key, add a 1:M association membership from the key field to the composite key, and a 1:1 association membership from the composite key to the new key.
For each multiple association:
1. If joining two keys, add the association between the key groups if it does not already exist. If it results in a M:M (many to many) association, follow the guidelines for building key-oriented lists.
2. For other cases, proceed as in 1 above, if the details are not already recorded.
¤ Review implied entity types
Perform the following checks:
* Non-identifying fields should be 1:1 with keys.
* No fields listed as keys should be left as non-identifying.
+ Checks to Perform
~ No fields should be repeated in more than one key group.
No fields, especially non-key fields, should be repeated in more than one key group; if they are, follow the guidelines for building key-oriented lists.
~ There should be no transitive associations.
This involves following the chains of associations. Follow the guidelines for building key-oriented lists.
~ Add key groups with no non-identifying fields to other key groups.
If any key group has no non-identifying fields but has associations with other key groups, add it to these; otherwise, remove it. If a field is added to more than one key group, follow the guidelines for building key-oriented lists.
+ When the checks are complete
Once these checks are complete, each key group entry in the key-oriented list can be taken to be an implied entity type. Its key and non-key fields become implied attribute types, and the association memberships between key group entries become implied relationship types.
¤ Construct implied entity relationship diagram
Draw up the implied entity relationship diagram from the key-oriented list, using the entity relationship diagram conventions. Optionality of relationship types can be added if they are evident at the time the diagram is drawn up.
» Creates deliverable D3.8.2 Problem Report
» Creates deliverable D3.8.4 Data Analysis Diagram
» Creates deliverable D3.8.5 Implied Entity Relationship Diagram
» Creates deliverable D3.8.6 Key-Oriented List
Previous : A3.12.1
Activity Overview : A3.12
Stage Overview : Analysis Stage
Overview : Table of Contents