Checklist Description

For most systems, the underlying database is the key to application-development success. Get the database structures right and everything else will normally follow. Get it wrong and chaos ensues as developers apply workarounds and temporary measures to get the application to work.

Often, the analysis phase can produce a pristine, logical data model. However, if the model is implemented without modifications, it can lead to a whole host of performance problems. The two main reasons to physicalize (or, more correctly, productionize) a logical data model are:

• speed/performance

• save space.

In preparation for this analysis, it is useful to list each entity with its attributes and mark each column as follows:

• Whether it is key to this or another table:

  • Primary (P)

  • Primary/Foreign (P/F)

  • Foreign (F)

  • Access Path or Secondary Index (A).

• Entity subtype indicator:

  • List the different subtypes for this entity (e.g. a customer could be a prospect or live and also a corporate or a consumer).

• Optionality of the data item:

  • Mandatory (M) always present on every row.

  • Sometimes mandatory (S) presence depends on the setting of another column typical where there are entity subtypes, e.g. customer record may have forenames + surname or company-name depending on customer-type.

  • True optional (T) may or may not be present.

This checklist gives some areas to consider in performing that exercise.

Checklist