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.
Jonathan G. Geiger is executive vice president at Intelligent Solutions, Inc. Geiger has been involved in many corporate information factory and customer relationship management projects within the utility, telecommunications, manufacturing, education, chemical, financial and retail industries. In his more than three decades as a practitioner and consultant, Geiger has managed or performed work in virtually every aspect of information management. He has authored or co-authored numerous articles and three books, presents frequently at national and international conferences, and teaches several public seminars. Geiger may be reached at JGeiger@IntelSols.com.
Be the first to comment on this post using the section below.