Ontology vs. Data Model
Key takeaways
- A well-designed dimensional model is good engineering and this is not an argument to replace it.
- A data model is scoped to a system. An ontology is scoped to the business, which is why two correct warehouses can still disagree.
- Three things a star schema cannot carry: subsumption, constraints that travel with meaning, and identity across systems.
- Often the data model is the right and sufficient answer. The test is whether a second team has to agree.
Anyone searching ontology vs data model has usually built a few. That matters. Most of what is written on this comparison is addressed to people who have not, and it shows.
So, first, without qualification: a well-designed dimensional model is good engineering. It is the reason the warehouse answers in two seconds instead of two minutes. The discipline behind it is real. Nothing here is an argument that it should be replaced.
The objection to the word is also fair. From a data engineering forum, one of the better-argued sceptical comments:
"I hate vague words like this. What is an ontology vs a semantic layer in your mind[?] A semantic layer is almost always a dimensional model."
Concede the first four words. The word is vague, and vendors made it that way by attaching it to whatever they were already selling. So this answer uses dimension tables and attributes. Triples stay out of it.
What does an ontology actually model?
An ontology is a formal, machine-readable model of the things in a domain: their types, the properties they carry, and the relationships between them. In an enterprise, an ontology is the agreed answer to two questions. What are the organization's core things, and how do they relate? Every person, system and agent then resolves those questions the same way.
One clause of housekeeping. Some analytics platforms use ontology to mean the object layer inside their own workspace. That is a product feature wearing the same word. It describes their workspace. This article means something portable.
How does an ontology differ from a data model?
A data model describes how data is structured. An ontology describes what that data means in the business. Your dimension table says a customer row has these columns and this grain. It does not say what qualifies something as a customer, or who decided that.
A data model is scoped to a system. An ontology is scoped to the business. This is the part your own experience already argues. Two warehouses can each be internally correct and still disagree about active customer count. Correctness inside a schema says nothing about agreement across schemas. Nobody modelled anything wrong. There was simply never one answer.
Three things a dimensional model structurally cannot carry. The schema is not at fault here. These are simply outside what a schema can express.
| What it means | How a schema fakes it | Why the fake does not travel | |
|---|---|---|---|
| Subsumption | A helicopter is an aircraft, everywhere, without a join | A type column, or a view that unions the subtypes | The next system has to be told the rule. It cannot read it off the data |
| Constraints that travel with meaning | The rule rides with the concept, not the table | A check constraint, or validation in the loading job | Loading the same data elsewhere leaves the rule behind |
| Identity across systems | The same customer is one thing, not three rows | A mastered key, maintained per integration | Every new source restarts the reconciliation |
A star schema can be extended to imitate all three. What it cannot do is carry them in a form another system reads without being told how. That difference is the whole of what an ontology adds. It is also why open standards matter more than preference here. RDF, OWL and SHACL let the type relationship, the constraint and the identity statement travel. Something that was never built to read your warehouse can still read them.
When is a data model the right answer?
Often. The test has three parts. Does the question live inside one system? Is the grain stable? Does any second team need to agree on the vocabulary? Yes, yes and no means a dimensional model is sufficient and an ontology is overhead. Whether you actually need one is a real question with a real "no" available.
The register here is addition. Nothing gets replaced. Most organizations end up with both. Enterprise data modeling covers how the data is laid out. An agreed model above it covers what the data means. Ontology management keeps that agreement true as the business changes.
Where the two layers have to stay connected
- Schema change to definition. A migration upstream should reach whoever owns the affected meaning. Silent invalidation is the failure mode.
- Definition to validation. The constraint in the model and the check running against the data have to be the same statement, or one of them is decoration.
- Both to the consumers. An application or agent resolving a term at query time should get the agreed answer. Whichever system it happened to ask is not the authority.
Those connections are the maintenance surface. They are why an ontology belongs in open standards, outside whichever tool drew it. A model the next system cannot read is a model the next team has to rebuild.
So what should I take away?
My data model is a first pass at an ontology. It gets me the entities and the joins. The table above named three things it cannot carry. Two more matter just as much, and both are about keeping the agreement alive. A named owner for the definition, because schemas have owners for tables and never for what a word means. And portability, so the model outlives the warehouse it was built in.
A model inferred from a schema tells me how my data is organised. It cannot tell me what my business agreed that data means. That agreement was never in the schema. Nothing is ground truth until the people accountable for it say so, and TopQuadrant builds the place where they say it.
