Data models attempt to express the business rules of an organization. A good data model reflects the semantics used within an organization to such an extent that business people within that organization can relate to and easily agree with what is being expressed. In this regard the data modeler’s goal is to properly mirror back the organization’s concepts onto those people within the organization. The goal is not to force an organization into a “standard” data model, nor is the goal to abstract everything in the creation of a master model that will never need to change even if the business rules were drastically shifted.
The creation of an organization’s data model is a learning experience for the architect establishing the design. And at times, data modeling can also be a learning experience for the business people involved in the modeling efforts. The data modeling effort is a window for organizational change. While the data modeler should not be attempting to force a generic industry model upon the business, some needs for change may arise. In the formalization that comes with translating the business semantics into a data model, inconsistencies or incomplete thoughts may be exposed. For example, it can become apparent that different areas of the business are using the same term, but have meanings behind them that differ in a fashion that causes problems. Under these kinds of circumstances, the organization may only know that the area related to this subject is a “problem,” but have no real understanding about the true nature of the problem. The data modeler can direct further conversations into overcoming the inconsistencies and completing those thoughts. Often in working through these issues, the data modeler needs to expand the language in use to account for the possible conceptual variations conflicting and generating these difficulties.
Abstraction within a data model is a subject that needs to be approached cautiously. A data modeler should not focus concern over the possibility of everything changing at the drop of a hat. Data does change, but not nearly as often as processes may change. Data models should be as explicit as practical. Occasionally, areas of the business may be acknowledged as still in formation and therefore they serve as gravity wells of change. For these specific areas, and for those things most changeable, high level abstractions may serve best simply because nothing other than an abstraction can serve in its place. Similarly, for operational models of a physical implementation, there may be a greater need to use an abstraction here or there to provide the necessary operational flexibility.
All in all, this means that a final data model for an organization should closely resemble the perceptions held by the business people within the organization. How the business works, or more accurately, how the business thinks it works should drive the shape that a data model takes. In this way, each organization will likely have a unique data model, a semantic child of the corporate parent that “looks just like them.” Yes, businesses within the same industry will have similarities, but similarities are as close as it usually comes. Every single organization has its own individual quirks and oddities. And those quirks and oddities have contributed to the culture within the business. And those quirks and oddities should be embraced by the data model supporting that organization’s business processes. A good data modeler will attempt to avoid bringing their preconceptions from other organizations into play when building a new organization’s data model. Experience is a tool and a gift, not an answer that must be repeated.