There are three different types of data models: conceptual, logical and physical, and each has a specific purpose.
An organization’s approach to data modeling will be influenced by its particular needs and the goals it is trying to reach, as explained here:
But with the different types of data models, an organization benefits from using all three, depending on the information it wishes to convey and the use cases it wants to satisfy.
That’s because all three types of data models have their advantages and ideal instances in which they should be applied.
The conceptual data model should be used to organize and define concepts and rules.
Typically, business stakeholders and data architects will create such a model to convey what a system contains.
In contrast, the logical data models and physical data models are concerned with how such systems should be implemented.
Like the conceptual data model, the logical data model is also used by data architects, but also will be used by business analysts, with the purpose of developing a database management system (DBMS)-agnostic technical map of rules and structures.
The physical data model is used to demonstrate the implementation of a system(s) using a specific DBMS and is typically used by database analysts (DBAs) and developers.
Oftentimes, data professionals want the full picture found in logical and physical data models. But data professionals aren’t the sole audience for data models.
Stakeholders from the wider business – business leaders, decision-makers, etc. – are less likely less concerned with the specifics than with the outcomes.
Therefore, when using a data model to communicate with such stakeholders, the conceptual data model should not be ignored.
As outlined above, different types of data models will be most applicable – or effective – depending on their context.
To determine context, you have to look at who the data model is being created for and what it will be used to communicate.
An important part of communication is making concepts understandable and using terms that are meaningful to the audience.
Another key aspect is making the information readily available. While it may be feasible to have working sessions with stakeholders to review a logical and/or physical data model, it’s not always possible to scale these workshops to everyone within the organization.
In any data governance endeavour, it’s a best practice to prioritize business-critical data elements and relate them to key business drivers. This approach helps gain the buy-in and interest of business users – essential factors in getting projects of the ground.
The same mode of thinking can and should be applied to data models.
Although it may be tempting to always include fully realized and in-depth data models to paint the fullest picture possible, that will not resonate with all parties.
When gathering business requirements, for example, it’s often more effective to use a conceptual data model and be creative with its display, as shown below.
The use of icons and graphics help tell the “story” of the model and ultimately the story of the business. In this approach, data models can be read as a sentence, with the entities as the nouns and the relationships as the verbs.
For example, we can group the “customer” and its relationship to/action concerning the “product.” In this case, the model represents that “a customer may buy one or more products” via a visual “story” that makes sense to the business.
This high-level perspective makes it easier to quickly understand information, omitting the more technical information that would only be useful to those in the weeds (e.g., business analysts, DBAs and developers).
In the example above, business leaders will be able to make better informed decisions regarding important distinctions in business rules and definitions.
For instance, in the example above, is a “customer” the same as a “client?”
The support team uses the term “client,” while sales uses the term “customer.” Are the concepts the same? Both buy products and/or services from the company.
But if a product or service has not actually been purchased, perhaps “prospect” would be a better term to use.
Can relationships between customers (or customers and prospects) be evaluated and grouped together by household for better sales and support?
None of these answers can be determined without the input of business stakeholders. By showing the concepts and their interrelationships in an intuitive way, definitions and business rules more easily come to light.
erwin Data Modeler (erwin DM) supports conceptual as well as logical and physical models to help business and technical stakeholders collaborate on the design of information systems and the databases that power them.
With erwin DM, data models and database designs can be generated automatically to increase efficiency and reduce errors, making the lives of data modelers – and other stakeholders – much more productive.
New to erwin DM? Try the latest version of erwin DM for yourself for free!