Why Data Modelers Keep Reinventing the Same Ideas — and How to Finally Align Meaning, Structure, and Integration
💡 Introduction — The Great Modeling Divide
Everyone talks about data models, but few mean the same thing.
🔹 In business circles, requirements describe intent.
🔹 In conceptual circles, conceptual models define ideas.
🔹 In data circles, logical models define structure.
🔹 In architecture circles, canonical models define interoperability.
🔹 In engineering circles, Data Vault models define implementation and automation.The result? A modeling Tower of Babel — multiple dialects of the same language, each insisting it’s the “right” one.
This article connects these viewpoints into a single semantic continuum — from requirements to automation — showing how each plays a vital, complementary role in turning understanding into knowledge.
🧱 1. The Requirement Model — Capturing Intent
Every model starts as a need. The Requirement Model defines what the business wants to achieve — not yet how it’s represented or implemented.
It captures:
- Business goals and drivers
- Key questions and KPIs
- Scope boundaries and assumptions
- Data needs for decisions or compliance
Requirements form the north star for all later models. They articulate the why behind every data concept, and serve as a bridge between strategy and semantics.
“Requirements are not documentation — they are the conversation that defines purpose.”
When linked to conceptual and logical models, requirements make traceability visible: every data structure can be justified by a business purpose.
🧠2. The Conceptual Model — Defining the Universe of Discourse
A Conceptual Model describes the universe of things that matter to the business — at a level of meaning, not structure.
It defines the key entities, relationships, and categories that express how the business perceives its world. It’s the model of understanding, independent of technology or platform.
- Entities: What we talk about (Customer, Product, Contract)
- Relationships: How they connect (Customer buys Product)
- Boundaries: What belongs inside our domain of meaning
Conceptual models are the bridge between requirements and structure — ensuring that what we design reflects what the business actually means.
🧠3. The Business-Oriented Model — The Language of Collaboration
Alec Sharp reframed modeling around people, not databases. His Business-Oriented Data Modeling (BODM) approach turned conceptual ideas into conversational models — tools to align teams around shared understanding.
Principles of BODM:
- Shared meaning over formal notation
- Business language over technical jargon
- Examples over abstraction
“The goal is not to model the database — it’s to model the business.”
— Alec Sharp
Business-oriented models are communication artifacts — the living vocabulary that connects analysts, architects, and engineers.
🧩 4. The Concept Model — Semantics and Rules (Ross & Lam)
Ronald Ross and Gladys Lam formalized semantics into a discipline: the Concept Model. It defines how business language and rules operate — the ontology of meaning.
“A concept model is a collection of conceptual buckets into which you can place like things.”
— Ronald G. Ross
A Concept Model specifies:
- Definitions and business criteria
- Verb concepts (how things relate)
- Classification and categorization
It aligns closely with SBVR and business rules, extending modeling beyond nouns into verbs and intent. If the Requirement Model defines why, and the Conceptual Model defines what, the Concept Model defines what it means.
🔗 5. Ensemble Logical Data Modeling — Structure with Meaning
Hans Hultgren’s Ensemble Logical Data Modeling (ELDM) reintroduces structure without losing semantics. It organizes data around ensembles — cohesive clusters of business identity, context, and relationships.
- Models remain logical and business-driven
- Entities have clear identity and evolution
- Structures are pattern-based and auditable
ELDM unites the business and technical worlds: structured enough for databases, but meaningful enough for conversation. It’s the foundation for metadata-driven automation and modern data warehousing.
🧩 6. The Canonical Model — Consistency Across Systems
The Canonical Model extends the ensemble idea outward — across systems, domains, and integrations.
It defines a common language for exchange, ensuring that “Customer” or “Order” means the same thing everywhere, whether in APIs, events, or data pipelines.
Core principles:
- Neutral: Independent of any single system
- Stable: Represents enduring business entities
- Mappable: Sources and targets connect through simple transformations
- Governed: Managed under enterprise architecture
In modern architectures, canonical models form the semantic backbone of event-driven and service-oriented ecosystems. They make data interoperable, not just integrated.
🏗️ 7. Data Vault Modeling — From Semantics to Automation
Data Vault brought repeatable pattern-based automation to enterprise data modeling. It turned conceptual meaning into auditable, incremental, metadata-driven design.
A Data Vault model is built from:
- Hubs (core business keys)
- Links (relationships between hubs)
- Satellites (context and history)
It enforces traceability, scalability, and historical accuracy — bridging logical structure and physical automation.
Data Vault’s genius lies in connecting semantic models with platform execution.
🧠8. The Complete Semantic Continuum
Seen together, these models form a connected chain — each solving a specific kind of problem while building upon the previous one:
Press enter or click to view image in full size
Each layer adds a dimension — from meaning to execution, from intent to automation.
🚀 9. From Chaos to Clarity
The evolution of modeling isn’t about finding the best method — it’s about recognizing each method’s place in the continuum.
- Requirement Models define purpose.
- Conceptual Models define scope.
- Concept Models define semantics.
- Business-Oriented Models enable collaboration.
- Logical/Ensemble Models provide structure.
- Canonical Models ensure interoperability.
- Data Vault Models deliver automation and traceability.
Each evolved as a response to the limits of the previous one — yet all are part of the same story. Together, they describe how understanding becomes executable knowledge.
Modeling isn’t about notation — it’s about narrative.
A story that begins with intent and ends with integration_._
đź’¬ Epilogue
The next time someone says,
“We already have a data model,”
ask them:
“Do you mean requirement, conceptual, business-oriented, concept, ensemble, canonical, or Data Vault?”
Their answer won’t just describe a model — it will reveal how they think about meaning.