Culture of Cooperation

Published
  • December 17 2007, 3:36pm EST
More in

Logical data model reviews are an integral part of the modeling process. Periodic reviews of the logical data model allow the data architect to make minor adjustments rather than radical change. The number and frequency of reviews vary according to the size of the modeling effort. However, even the smallest modeling project should include at least two reviews, an initial review and a final review. For extensive modeling efforts that span several months, consider reviewing the logical data model at evenly spaced intervals, no more than three to four weeks apart.

 

The initial logical data model review should occur immediately upon completion of the first draft of the model. Conducting the review before the logical data model is fairly stable is a wasted effort because the model will likely experience substantial change. On the other hand, waiting until the logical data model is complete can be an expensive delay that might require extensive rework. Problems that could have been corrected with little effort early in the process might result in errors that compound into fatal flaws.

 

A review of the logical data model involves a comprehensive analysis of the entities, data elements and relationships in the model. The model is reviewed for completeness, standards compliance, clarity, reuse of existing designs and business partner understanding.

 

During the review process, defect severity levels should be assigned to each logical data model defect:

 

  • Major – Major standards violation (project cannot continue unless and until defect is corrected).
  • Minor – Minor standards violation (format, typographical).
  • Comment – No impact (possible better way to same result).

Completeness and Standards Compliance Review

 

During the completeness and standards compliance review, the following questions should be asked. If a component of the logical data model fails a given question, a defect severity level should be assigned to the component/question combination.

 

  • Does the logical data model include information pertinent to the business requirements and exclude nonpertinent information?
  • Will all business questions be met by the logical data model?
  • Is the logical data model in third normal form?
  • Are all states of time (present, future, history) adequately reflected in the logical data model?
  • Is there an IT activity or business process that will create, update, retrieve or delete each data element in the logical data model? If not, the data element is not necessary.
  • Are the entities a person, place, thing (concept or event)?
  • Are all entities named singularly?
  • Is each entity fully described in the data dictionary?
  • Is each entity named according to the naming standards?
  • Is each entity defined according to the definition standards?
  • Do all entities have a surrogate primary key?
  • Is each data element fully described in the data dictionary?
  • Is each data element named according to the naming standards?
  • Is each data element defined according to the definition standards?
  • Does each data element name have an approved and proper class word?
  • Does each data element have an approved data type?
  • Is each data element “self defining” (no other data is kept about it)?
  • Do the relationship verb phrases (a.k.a. business rules) construct grammatically correct English sentences between the child and parent entities? E.g., “A Mortgage Product may be sold through one or more Parties.”
  • Are all relationships important associations between occurrences of one or more entities that give information of value to the business?
  • Is each relationship defined according to the definition standards?
  • Is each relationship named according to the naming standards?
  • Is each relationship fully described in the data dictionary?
  • Do any outstanding completeness issues remain unresolved?

Clarity Review

 

During the clarity review, the following questions should be asked. If a component of the logical data model fails a given question, a defect severity level should be assigned to the component/question combination.

 

  • Will any technical person reading the logical data model have the same understanding of its contents?
  • Will any subject matter expert reading the logical data model have the same understanding of its contents?
  • Will any business partner reading the logical data model have the same understanding of its contents?
  • Are any of the entity names incorrect or misleading?
  • Are any of the entity definitions incorrect or misleading?
  • Are any of the data element names incorrect or misleading?
  • Are any of the data element definitions incorrect or misleading?
  • Are any of the relationship definitions incorrect or misleading?
  • Are any of the relationship verb phrases incorrect or misleading?
  • Could more information be added to improve the clarity of the logical data model?
  • Could any of the information contained in the logical data model lead someone to an incorrect conclusion or misuse of the data?
  • Do any outstanding “clarity” issues remain unresolved?

Reuse of Existing Designs Review

 

During the reuse of existing designs review, the following questions should be asked. If a component of the logical data model fails a given question, a defect severity level should be assigned to the component/question combination.

 

  • Is the component under review based upon one of the logical data model reusable design patterns? Which one?
  • Are you reusing existing enterprise logical data model entities? Which ones?
  • Are all entities that reflect the same business requirement spelled, defined, and used in the same fashion?
  • Are you reusing existing enterprise logical data model data elements? Which ones?
  • Are all data elements that reflect the same business requirement spelled, defined and used in the same fashion?
  • Are you reusing existing enterprise logical data model relationships? Which ones?
  • Are all relationships that reflect the same business requirement spelled, defined and used in the same fashion?
  • Do any outstanding reuse issues remain unresolved?

Business Partner Understanding Review

 

During the business partner understanding review, the following questions should be asked. If a component of the logical data model fails a given question, a defect severity level should be assigned to the component/question combination.

 

  • Are all entity definitions meaningful and correct?
  • Are all data element definitions meaningful and correct?
  • Are all relationship definitions meaningful and correct?
  • Do all relationship verb phrases represent business reality?
  • Will any subject matter expert reading the logical data model have the same understanding of its contents?
  • Will any business partner reading the logical data model have the same understanding of its contents?
  • Could more information be added to improve the clarity of the logical data model?
  • Could any of the information contained in the logical data model lead someone to an incorrect conclusion or misuse of the data?
  • Does the business partner have the means and the will to collect the data for each data element?
  • Does the logical data model include information pertinent to the business requirements and exclude nonpertinent information?
  • Will all business questions be met by the logical data model?
  • Do any outstanding “business partner review” issues remain unresolved?

Business Partner Review Techniques

 

We must be cognizant of different communication techniques while reviewing the logical data model with the business partner or subject matter expert. Some trained business partners and subject matter experts may be skilled in reading a logical data model directly while others are more effective using other forms of documentation to fully understand its contents.

 

For those who are not skilled at reading a logical data model directly, the following business rules spreadsheet provides effective documentation. The spreadsheet provides the business partner with a concise and understandable way to communicate and validate the business rules that are represented in the logical data model as relationship verb phrases between child and parent entities. Relationship verb phrases (a.k.a. business rules) construct grammatically correct English sentences between the child and parent entities. For example, “A Mortgage Product may be sold through one or more Parties.”

 

  

With the business rules spreadsheet and data dictionary reports of all entities, data elements and relationships of interest to the business partner, you will be successful at validating your logical data model without forcing them to read the model directly.

 

Thriving in a Culture of Cooperation

 

A high-quality logical data model is built according to a recognized set of rules that enable the model to be used to greatest effect. The importance of these rules is that the organization can use their logical data models with assurance that they will be uniformly understandable and consistent regardless of who developed the model or when it was designed.

 

Integration is defined as the organization of all parts of the problem domain into a unified whole. Translated into a logical data modeling context, this definition means that all entities, data elements and relationships that reflect the same business requirement are spelled, defined and used in the same fashion.

 

Logical data models are used as a communication tool between the business community and the IT staff. Data requirements must be well documented and understood by all involved, must be business-oriented and must consist of an appropriate level of detail. When developing these models, the objectives must always be clarity and precision. When adding information to a logical data model, the data architect should ask whether the addition adds to clarity or subtracts from it.

 

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access