Project Management Data Models and Entity Descriptions Checklist

The following guidelines provide a basic checklist for reviewing data models and entity descriptions.
Basic review of model
- Ensure each entity has a singular noun as a name.
- Ensure the diagram is well laid out. Topology guidelines include:
- relationship lines as direct as possible, but retaining clarity;
- master entities higher in the diagram than their details (so avoiding upward pointing relationship arrows);
- minimum crossing lines.
- The diagram should have no visible storage connotations, e.g.:
- indexes and arrays should not be shown unless logically significant;
- business relationships as opposed to physical access paths should be defined.

Review of business implications
Relationship review
- Do the relationships in the model correctly portray business rules?
- does the relationship between two entities actually exist (can an example be given)?
- is the relationship correctly established (e.g. can a customer actually have multiple orders? Is it possible for one order to be jointly placed by more than one customer)?
- have many-to-many relationships been established with the use of associate entities?
- Are the relationships:
- unambiguous?
- correctly named?
- All present, e.g. is there more than one relationship between two given entities, or relationships between currently unlinked entities?
- Are optional relationships being correctly used, i.e. can a detail exist without being linked to an occurrence of its master entity?
- Where a mandatory relationship is shown, ensure that there are no instances in the business processing cycle where a detail entity could exist without its master entity being present.
- Are the relationships redundant, i.e. can they be derived from other relationships in the model?
- Are recursive relationships (bill structures) justified and accurate? (Are hierarchies, networks, or subtypes more appropriate?)
- For each detail in the entity, check that the keys of each of its master entities have been included in the detail, as either foreign keys or as part of the compound key of the detail. Check there are no data items in an entity, which are key of another entity and not linked to it by a relationship.
- Have the data, as opposed to the functional relationship, been modelled?
- Ensure that the exclusivity relationship notation is being used correctly – see icon section of the methods handbook.
- Has the model been oversimplified, e.g. use of ‘bill’ structures where hierarchies, networks or subtypes more appropriate?

Entity review
- Are the entities too generic? Are relationships imprecise (often shown by many optional and exclusive relationships associated with one entity)?
- Can entities be combined to simplify the model without losing meaning?
- Do all data model entities reflect business entities, about which data must be stored? e.g.:
People Employees
Places Depots
Intersections Assignments
Objects Products
Organizations Customers
Events Sales orders
- Does each entity have a unique key? Check that none of the items in the primary key is optional.
- Has the key too many components – would an ‘inverted’ identifier be better?
- Does the entity name accurately reflect the object it represents?

Check that the data item name is not the same as the entity name except for operational masters where they should be the same.
- Do two entities have the same key?
- Are the date items in the key sufficient to uniquely identify a single occurrence within the entity? Are any data items in the key not required to uniquely identify a single occurrence?
- Where a data store contains more than one entity it should not have the same name as one of those entities.
- Are there too few or too many entities in a data store?
- Has the entity at least one non-key data item. If not, does it represent a true many-tomany relationship?
- Can at least three real world examples of each entity be identified?

Functional review
- The data model should be cross-checked against the functional documentation to ensure that the scope of the model is correct and consistent.
- Have the entities in the data model been cross-referenced to the data stores in the data flow diagram set? This will ensure that all the entities required by the DFD processing are present, and conversely, that all the entities are being processed.
- Do operational masters represent actual business needs?

Basic review
- When the required system is being specified, are the data items for the entity present?
- Are the data items named according to standards?
- Have role names been used when required? Have they been used inappropriately?
- Have the system volumetrics been included, including rate of birth and death?
- Have descriptions been included for each relationship – are these consistent with entity volumes.

Business review
- Does the description:
- clearly describe the entity (not its identification or other specific data item)?
- explain what the entity is and its purpose in this system?
- give an example of the entity?
- put the entity into context with its master entities?
- define the domain of occurrences (e.g. does ‘customer’ mean all active customers, active and past customers, potential customers, businesses actually buying goods or also those businesses’ administrative offices)?
- Has an adequate view of the future growth been taken into account when defining volumetrics?
- Are any other objects mentioned in the description related to the entity or is the description inaccurate? Are any items mentioned in the descriptions included in the date items listed?
- Have current restrictive business practices been retained in the model? For example, should one-to-many relationships be replaced by many-to-many relationships in order to provide flexibility?
- Are key structures restrictive? For example, a sales location entity may have a key of state code and location number. This may have been originally created to meet a sorting need.

Data items
- Are data items correctly named? Are they missing a qualifier, e.g. order number rather than order?
- Are all data items described, including their length and format?
- Does data item description cover all uses or only some roles?
- Are all data items described included in entities except for calculated only items?
- Do calculated only descriptions include details for calculation?
- Does description clearly describe the item?
- Does it
- explain what it is and its purpose?
- give an example?
- cover all its uses (not just a few of its roles)?
- Check for synonyms (the same data item given different names).
- Check for homonyms (the same data item used to express different things, check entities used are in the same length and format.