The Role of Logical Data Models

By Caryn Maresic, Senior Consultant

Logical Data Models (LDMs) were the standard means of recording business rules and data definitions back in the ‘80s and ‘90s.  Business and IT partnered to learn the art of data modeling and 3rd normal form in hopes of finding a common ground to record requirements.  Over time, it became evident that in today’s fast-paced development environment the business doesn’t have the time to digest all the nuances in a data model.  It is IT’s job to gather information via interviews.  Many times, we skip the LDM task because we don’t have time and LDMs are too academic and we find ourselves asking…

Are Logical Data Models really necessary?  Yes!

LDMs drive BI design by defining business rules independent of physical implementation.  There are many tools (CA ERwin Data Modeling, Embarcadero Technologies), and techniques (UML, IDEF, Bachman) in use today. To illustrate the difference between the benefits of a PDM and an LDM, let’s look at an example:  Customer/Address relationships.

The PDM above (created using) supports many Customer/Address business rules, but it does not tell me the Customer/Address relationships as defined by the business.

In contrast, the following LDM is more rigorous and definitive:

What does the LDM above tell me that the PDM did not? 

• There are two types of Addresses – Physical and Mailing.
• The Customer Bill To Address can be either a Physical or Mailing Address
• Customer Ship To Addresses must be Physical Addresses.
• Every customer must have a Bill To Address.
• A Customer has zero, one or many Ship To Addresses.

All of these relationships can be implemented using the PDM, but they aren’t dictated by the PDM.  The LDM explicitly defines each relationship and prompts us to ask better questions of the business, such as:

• Are there any Customers who do not have a Bill To Address?
• Are there any Customers who do not have a Ship To Address?
• When there are multiple Ship To Addresses, how do you know which one to use?
• Are there any Customers who have more than one Bill To Address?
• Do you know of any upcoming business initiatives that might change these rules?
• Was there ever a time when the business rules were different?

The answers to these questions may require changes to the model, but without the LDM, we may not have asked the right questions!  The best part about the LDM is how valuable it is to the rest of the development process.  It will be used in production of training materials, test plans and test cases, data profiling and migration efforts and, finally, physical database design.

---

Caryn has over 20 years experience in providing high-quality data solutions to clients in the areas of Business Intelligence, Data Warehousing and System Integration.  Caryn has expertise in across industries with an emphasis in Pharmaceutical, Manufacturing, and Insurance.  Prior to joining to Baseline, she ran her own consulting company.

Comments

[Michael McIntire]

The question of the usefulness of LDMs is largely moot - they are very useful, particularly as reference material. The question unanswered is when to rationalize the investment in the process and content of a logical model.

Many organizations force commitment of these documentary processes prior to the testing of a data informed hypothesis or data persistence process which is wasteful from both a time and resource commitment perspective, particularly when the persistence is likely to be temporary or of unknown temporal duration.

Point is: before we invest in the costs of an LDM, and the potential benefits, we should rationalize the benefit with high probability outcome. Fail Fast. We lack these concepts and supporting methods in the Data Information Factory and its peers.

[Caryn Maresic]

If what we produce becomes shelf-ware, then I agree -- it is difficult to rationalize the investment. My point was that by not creating and using the LDM we are skipping over an integral part of the process -- that is, accurately/clearly/succinctly recording the business rules -- we are breaking our own process.