Analyzing Current Systems › Analyzing Current Data › Developing an Implied Data Model

Developing an Implied Data Model

You develop a model from the record types, keys, and fields of each data store and data view. The conventions used to model this data are exactly the same as those used during data analysis.

Guidelines for developing the data model:

• Include each key group as an entity type.

  A key group is a key and a set of fields that are dependent on that key. For example, in the Purchasing data store structure, Supplier Name and Address depend on Supplier Number, so they become attributes of entity type SUPPLIER, with Supplier Number as the identifier. Within a concatenated key, each key component defines a separate key group. Each of the separate key groups will be related to the key group containing the concatenation.

• Define relationships between all key groups.

  PURCHASE ORDER has a one-to-many relationship with PURCHASE ORDER ITEM. A relationship cannot always be defined with certainty. Supplier, for example, cannot be associated with any other entity type based solely on its key.

• Include every relationship.

  The implied data model includes many relationships, some of which may be redundant. See the chapter "Analyzing Data" for information on redundancy. During comparison checking, determine which relationships to keep.

• Resolve each many-to-many relationship for which additional attributes are needed about the relationship (for an implied data model only).

  In each of these cases, create an associative entity type. Use the identifying attributes of the entity types involved as a composite identifier, and then add the necessary relationships and attributes.

In the Purchasing data store structure, a purchase order may contain many PRODUCTs. Likewise, a PRODUCT may appear on many purchase orders. This is resolved by creating an associative entity type PURCHASE ORDER ITEM, which has for its key the two identifiers PRODUCT and PURCHASE ORDER as well as the attribute Quantity. This is shown in the following illustration.

• Do not represent the optionality of relationships.

  In the example, it was inferred that a product is ordered by means of many purchase order items. Optionality allows for an instance when a particular product is never purchased perhaps because it is obsolete and never appears on a purchase order item.

• Remove duplicate attributes that are not identifiers.

  Perform this for an implied data model only. To remove duplicates without losing information, you may need to create relationship memberships between the entity type of the duplicate attribute and an entity type currently identified by or containing the attribute.

  First check whether the required memberships already exist directly or indirectly. The Purchasing data store in the example contains in Purchase Order fields for Supplier Name and Supplier Address, which appear also in the Supplier record type and can therefore be removed.