I recently had the opportunity to sit on a panel and discuss issues of data modeling. One question focused on the purpose of the model. As a data modeler, how often do you stop to think about why you're creating the model? When we dissected the reasons for developing the data model, they boiled down to two. The main purpose of the logical model is to understand, and the main purpose of the physical model is construction and maintenance support. In this column, we'll deal with the purpose of the logical model; a future column will address the physical model.

In one of my early projects, I ran into great resistance to the very notion of building a data model. After listening to the objections, I acquiesced and told my client that I wouldn't be building a data model. Instead, I told him, I would speak with businesspeople and take notes in a shorthand notation that consisted of rectangles and lines, with funny symbols at the ends of those lines. My client understood that I was building a model, but he also understood that the model was being created as a means to an end, not as an end in itself. The model would provide a way to understand the business, a basis for the physical structure needed to support the business.

The model also helps us understand the project. As we create the data model, we speak with the business representatives to comprehend the business in general, and also to understand what needs to be provided by the project under way. This ensures that we will include the required entities and attributes in our model.

When applied to data marts, the logical model is useful for verifying that business needs can be met and that the desired navigation capabilities are being provided. This understanding goes two ways - the model not only reflects the modeler's interpretation of the project scope and business needs, but it also provides a means to communicate that understanding so that its accuracy can be confirmed by the business community. I have found that business users can comprehend a logical dimensional model and hence are better positioned to confirm its accuracy before the physical structure is designed and built.

A third important aspect is that the model helps us understand our project within the context of the overall enterprise. In the absence of an enterprise business data model, the business model is built incrementally. As it is built, the modeler is constantly aware that this is part of a larger picture, and while the picture is not fully painted, adjacent areas are often sketched (e.g., modeled at the entity level) to minimize - though not necessarily eliminate - the need to rework portions of the model as the scope of the BI environment expands over time. Having the broader picture enables us to detect commonalities across organizational and functional lines and maximize the potential for reuse of the data relationships. I encountered a company that unnecessarily spent millions of dollars because this was not done. That company had two major departments, each of which was responsible for managing a set of equipment. Because the equipment was different, each department pushed for its own system. A good logical (business) data model would have revealed that by focusing on the entity "equipment" and subtyping it as needed, common relationships would become apparent. These relationships transfer to the business functions and activities, and with this enlightenment, a generic system to meet both departments' needs was feasible. In building the dimensional model in a bus architecture, this enterprise perspective provides the foundation for the conformed dimensions.

It is important to understand why we create the data model. The logical model provides an understanding of the business, of the project and of the enterprise perspective. This understanding improves communications among the data modelers, other IT representatives and the business stakeholders, and it provides a strong foundation for the physical structures that must be built. I welcome your thoughts on the purpose of logical and physical data models.

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