Semantic Layer vs Data Model: How Do They Differ?

---

A data model defines how data is stored: the tables, columns, keys and grain that a database engine and the engineers behind it work with. A semantic layer defines what that stored data means: the metrics, dimensions, entities and join paths that every dashboard, notebook and AI agent should read the same way. The two differ in audience and in job, and they stack, because the semantic layer reads from the data model and does not replace it.

---

What does a data model define?

A data model is the structural design of your data. It answers questions a database has to settle before anyone runs a report: which entities exist, how they relate, what each column holds, and which keys connect them.

Data modeling has a long, settled vocabulary. Peter Chen’s entity-relationship model, published in ACM Transactions on Database Systems in 1976, gave the field its standard way to draw entities and relationships. A University of Minnesota lecture on data model levels describes the common split into three levels: a high-level conceptual model, a logical model that adds detail, and a physical model of how the data is stored in a specific database system.

For analytics, the most consequential modeling decision is the grain. The Kimball Group says the grain must be declared before choosing dimensions or facts, because it fixes exactly what one row of a fact table represents. Kimball recommends starting from atomic grain, the lowest level at which a business process captures data, since summary tables assume which questions people will ask.

If you use dbt, your data models are the SQL transformations in your project: staging models, intermediate models and marts such as an orders model. Their audience is the engine and the analytics engineer. A well-built data model is correct and performant. It still says nothing about whether “revenue” includes refunds, and that gap is where the semantic layer starts.

---

What does a semantic layer define?

A semantic layer is the place where business meaning gets defined once and then served to every tool that asks. It sits on top of modeled tables and holds five kinds of definition:

• Metrics, such as net revenue or monthly active users, with the exact aggregation and filters.
• Dimensions for grouping and filtering, such as region, plan or order date.
• Entities and their keys, so a tool knows what a “customer” is and how it joins to an “order”.
• Relationships, the approved join paths between tables.
• Access rules that decide who sees which rows and columns.

At query time the layer compiles a business request into SQL. Google’s Looker documentation describes this for its own modeling language: LookML describes “dimensions, aggregates, calculations, and data relationships” in your database, and Looker uses that model to construct SQL queries.

Warehouses now ship the same idea natively. If your data lives in Snowflake, semantic views store logical tables, relationships, facts, dimensions and metrics as a schema-level object. If it lives in Databricks, Unity Catalog metric views separate measure definitions from the fields used to group them, so a metric defined once can be grouped by any available field at runtime. The audience for all of these is people and tools that think in business terms.

---

How do a semantic layer and a data model differ, side by side?

The clearest way to see the difference is to ask what each one is responsible for, and what goes wrong when it is wrong.

	Data model	Semantic layer
Question it answers	How is the data stored and connected?	What does the data mean, and how is each number calculated?
Primary audience	Database engine, data and analytics engineers	Analysts, business users, BI tools, AI agents
Unit of work	Tables, columns, keys, data types, grain	Metrics, dimensions, entities, join paths, access rules
Typical artifacts	ER diagrams, DDL, dbt SQL models, fact and dimension tables	LookML, dbt semantic models, Snowflake semantic views, Databricks metric views, Power BI semantic models
When it changes	When sources, volumes or performance needs change	When the business changes a definition, such as what counts as an active customer
What breaks when it is wrong	Pipelines fail, joins fan out, queries slow down	Two dashboards show different revenue for the same month
Stores data?	Yes, it shapes the physical tables	No, it stores definitions and generates queries

Two rows matter most in practice. First, the semantic layer depends on the grain of the model under it. An order-level fact table lets the layer roll revenue up to day, week or month; a table pre-aggregated to monthly revenue locks every consumer to one time grain. Second, a semantic layer cannot repair bad records. If the model loads duplicate orders, the layer will define revenue consistently and still report the wrong number.

---

Is a semantic model the same as a semantic layer?

Not quite, and tool vocabulary makes it confusing. A semantic model is the set of definitions you author. A semantic layer is the system that serves those definitions to consumers, compiles them into SQL and applies access rules.

Microsoft renamed the Power BI dataset to “semantic model”, saying the new term better reflects the Analysis Services data models that Power BI reports are built on. The same page notes that Power BI is now one of many experiences in Microsoft Fabric.

dbt uses the term for a narrower artifact. A dbt semantic model is a YAML configuration attached to one dbt model, declaring its entities, dimensions and metrics so MetricFlow can generate queries. Here the boundary between data model and semantic model is literal: the SQL model builds the table, and the semantic model block describes what its columns mean.

So when someone asks “semantic layer vs data model”, check which tool they are in. In Power BI, “semantic model” names the whole model that reports are built on. In dbt, the semantic model is a YAML block embedded in the model’s definition, apart from the SQL that builds the table. For a deeper look at the Power BI case, see Power BI semantic model vs a dedicated semantic layer for AI agents.

---

Why does the difference matter more once AI agents query the data?

A human analyst who sees a column called amt in a table called ord asks a colleague whether it is gross or net. An AI agent guesses. Give an agent only the data model and it will rebuild business logic from column names on every prompt, which is how the same question returns different numbers across sessions.

If your agents run on Snowflake, Cortex Agents read the semantic view definition and generate SQL against the physical tables beneath it. On Databricks, teams add synonyms and display names to metric views to improve agent accuracy. In both cases, the data model supplies the tables and the semantic layer supplies the meaning the agent uses to pick the right ones.

The harder problem is that most enterprises have more than one semantic layer. A 2021 Forrester survey found that more than 61% of organizations use four or more BI tools and 25% use ten or more. Each BI tool, warehouse and agent framework can carry its own copy of “revenue”. Adding agents multiplies the copies.

That is why 16 named ecosystem partners back the Open Semantic Interchange, an open-source effort announced on 23 September 2025 to create a shared format for exchanging semantic metadata between tools. The data model can stay where it is. The definitions need to move. How a semantic layer relates to the catalog that inventories these assets is covered in semantic layer vs data catalog.

---

How does Atlan connect the data model to the semantic layer?

Atlan starts from what your data model and BI tools already contain. According to atlan.com, Atlan’s AI agents read the Enterprise Data Graph, including SQL query history, BI semantics and pipeline code, and generate asset descriptions and link business terms before a human reviews anything.

Context Engineering Studio then “reads your existing data graph to auto-generate a semantic layer you can build on.” Domain experts refine the draft, and the result ships as a Context Repo that is model-agnostic and exposes context through the Model Context Protocol (MCP), so any agent that supports MCP can read it without being tied to one BI tool. Atlan is also a launch partner in the Open Semantic Interchange.

Workday is the clearest example. Before AI, Workday’s people shared one business language through 1,000 glossary terms and 6 million cataloged assets. When its financial reporting agent could not answer the questions it was asked, the team turned that shared language into a semantic layer machines could use. Joe DosSantos, VP of Enterprise Data and Analytics at Workday, put it this way on Atlan’s Context Engineering Studio page:

“Atlan captures Workday’s shared language to be leveraged by AI via its MCP server. As part of Atlan’s AI labs, we’re co-building the semantic layer that AI needs.”

To see how this semantic layer fits beside a catalog and a context layer, read context layer vs data catalog vs semantic layer.

---

FAQs about semantic layer vs data model

Can you have a semantic layer without a data model?

In practice, no. A semantic layer compiles business requests into SQL against real tables, so it needs modeled tables underneath it. You can point a semantic layer at raw source tables, but every join, filter and deduplication rule then has to live in the metric definitions, which makes them harder to test and reuse.

Which should you build first, the data model or the semantic layer?

Build the data model first, at atomic grain, then define the semantic layer on top of it. The grain decides which questions the layer can answer. Define a handful of high-traffic metrics, such as revenue and active customers, before modeling every edge case, and expand once teams are querying them.

Is a semantic layer the same as a metrics layer?

A metrics layer is a narrower semantic layer. It focuses on metric definitions: aggregations, filters and time grains. A full semantic layer also defines entities, relationships between concepts and access rules. People often use the two terms interchangeably, so check which components a given tool actually defines.

Does a semantic layer store data?

No. A semantic layer stores definitions and generates queries; the data stays in the warehouse or lakehouse tables that the data model created. Some semantic layers cache pre-computed aggregates for speed, and Databricks metric views support materialization, but these caches are derived copies that the layer refreshes from the modeled tables.

Who owns the data model and who owns the semantic layer?

Data and analytics engineers usually own the data model, because it depends on sources, pipelines and performance. The semantic layer needs a business owner for each definition, such as finance for revenue, with engineers maintaining the code. When no one owns a definition, every team writes its own copy and the numbers drift apart.

Can a good data model replace a semantic layer?

For one team on one BI tool, often yes: clean tables plus measures defined in that tool can be enough. Once several tools or agents compute the same metric, each rebuilds the logic and the numbers drift. With more than 61% of organizations using four or more BI tools, most enterprises reach that point.

---

Sources

1. The Entity-Relationship Model: Toward a Unified View of Data, ACM Transactions on Database Systems
2. Conceptual vs. Logical vs. Physical Data Models, University of Minnesota
3. Grain, Kimball Group
4. How we structure our dbt projects, dbt Developer Hub
5. Introduction to LookML, Google Cloud Documentation
6. Overview of semantic views, Snowflake Documentation
7. Unity Catalog metric views, Microsoft Learn
8. New name for Power BI datasets, Microsoft Learn
9. Semantic models, dbt Developer Hub
10. Semantic Layer: What it is and when to adopt it, analytics engineering vendor blog
11. The Open Semantic Interchange initiative announcement, Snowflake