The Logical Model

The backbone of any data modelling strategy. A backbone so critical, so important, so key that … it is almost always ignored. See my post that talks to this:

Just Build the Physical Models?

So why is the logical model not something that has equal value to its twin, the physical model? Fundamentally its a lack of understanding of what the logical model actually is and (of equal importance) what it isn’t.

The logical model IS the model. Print that out and stick it to a wall near you. The physical models evolve from it. The logical model is the most complex form of either the conceptual and physical model. It needs to be rich in semantic meaning and accurately convey the underlying business objects in their digital form.

The logical model is the bridge between the conceptual business models and the physical structure of the database. It gives us more context as to the nature of the data than either the conceptual or physical models can.

Diagram illustrating the logical data model structure, including entities like Supplier, Orders, Inventory, and Part, with defined attributes and relationships.

Clarifies business data structure: Helps stakeholders understand key data elements and their interrelationships, critical for ensuring accurate and consistent database design
Reduces redundancy and inconsistencies: By clearly defining entities and normalization rules, it minimizes duplicate data and transactional anomalies
Serves as a foundation for physical design: Once validated, the logical model guides the construction of efficient, DBMS-specific physical schemas

A black graduation cap placed on top of an old, weathered book, set against a wooden surface.

One problem is that engineers view the very notion of a logical model as something of an academic relic. They were probably not taught formal data modelling at university and modern development stacks (ORMs, schema-as-code tools like Liquibase/Flyway, dbt) emphasize physical schemas.

In addition, Agile/DevOps workflows prioritize working software over documentation and clarity.

In our new dopamine depleted world, people want quick wins. Why bother with this old approach to data modeling. And didn’t DataLakes just tell us to ignore the models altogether? They did, and look where that got us…

Ignoring the logical model is like building a city with roads but no map. You can still drive, but every new connection becomes harder, riskier, and more expensive. Teams may think they’re saving time, but they’re really accruing semantic debt, a form of technical debt that’s far harder to pay down.

This again comes down to data literacy in an organisation and the value it places on data modelling in general. With the wrong approach taken in most large organisations we only ever see the logical model emerge in those unicorn-like teams that understand the real value.