Search for “semantic model” and you’ll get three different answers. Microsoft means the thing Power BI used to call a dataset. dbt and Snowflake mean a YAML definition of entities and metrics. Database researchers mean a formalism from 1981. And AI agents, the newest consumer of all this, need something none of the three fully provides.

This guide gives one definition that fits every version, maps the term across seven tools, and shows what an AI agent needs from a semantic model that a BI dashboard never asked for.

What Is a Semantic Model?

A semantic model is a layer of definitions that maps raw tables and columns to business concepts: entities like customer, metrics like revenue, and the relationships between them. Every report, tool, or AI agent that reads it then computes the same number the same way. It describes what the data means, while the physical data model describes how the data is stored.

“Semantic” Plus “Model”

The name is literal. Semantic means meaning. Model means a structured representation: tables, the relationships between them, and the calculations on top. Put together, a semantic model is a structured representation of what your data means to the business.

A 30-Second Semantic Model Example

Take a small sales schema with three tables:

The physical model stops there. The semantic model adds meaning:

• Relationships: fact_orders.customer_id joins to dim_customer.customer_id, many-to-one.

• Metric: Net revenue = SUM(amount) - SUM(refund_amount), excluding rows where is_test_account = true.

• Dimensions: You can slice net revenue by segment, region, category, and order_date by month or quarter.

• Vocabulary: “Sales,” “bookings,” and “revenue” all refer to net revenue unless someone says otherwise.

Now a dashboard, a spreadsheet, and an AI agent asking “what was net revenue in EMEA last quarter?” all apply the same formula, the same join, and the same exclusion.

Semantic Model vs Data Model vs Semantic Layer

These three terms get used interchangeably, and they shouldn’t be:

Longtime Power BI and Analysis Services expert Chris Webb summed up the relationship when Microsoft made the rename: Power BI “is a semantic layer, a semantic layer made up of one or more semantic models.” A semantic model is one unit of meaning. A semantic layer is the infrastructure that hosts and serves those units. We compare the main options in our semantic layer tools guide.

What Is a Semantic Model in Power BI?

A Power BI semantic model is a prepared, reusable source of data for reports and dashboards. It contains tables, relationships, DAX measures, and security rules. Under the hood it is an Analysis Services tabular model; Microsoft’s docs say a Power BI Desktop model “is effectively an Analysis Services tabular model.” Many reports can connect to one semantic model, so every report shares the same measures.

Why Microsoft Renamed Datasets to Semantic Models

In November 2023, Microsoft renamed the Power BI dataset content type to semantic model. It gave two reasons: “dataset” was too generic now that Power BI is one of many experiences in Microsoft Fabric, and “semantic model” better reflects the depth of Analysis Services models. The change was name-only, with no interruption to service. A few places still say “dataset,” including the REST APIs and push or streaming datasets.

Power BI Storage Modes

How a semantic model stores data affects speed, freshness, and cost. Microsoft documents four main options:

Direct Lake requires a Fabric capacity and is where Microsoft is steering large models.

DAX Measures, Relationships, and Row-Level Security

Measures are where the business logic lives. An illustrative measure:

Net Revenue = SUM(Sales[Amount]) - SUM(Sales[Refunds]

Net Revenue = SUM(Sales[Amount]) - SUM(Sales[Refunds]

Net Revenue = SUM(Sales[Amount]) - SUM(Sales[Refunds]

Net Revenue = SUM(Sales[Amount]) - SUM(Sales[Refunds]

Relationships define how tables filter each other. Row-level security (RLS) restricts which rows each user sees. A report built on the model inherits all three, so the report author never rewrites the logic.

Power BI’s AI Layer: Prep Data for AI

Here’s a telling detail. Microsoft now ships a Prep data for AI feature that adds AI data schemas, verified answers, and natural-language AI instructions to a semantic model, so Copilot answers correctly. Microsoft notes that when data is ambiguous, “AI systems can struggle to correctly interpret it.” In other words, even the company that popularized the term agrees a BI semantic model isn’t enough context for AI on its own.

Semantic Models in dbt, Snowflake, Cube, Looker, and Tableau

Outside Power BI, “semantic model” means a definition file or object that a semantic layer or AI service reads:

dbt Semantic Models

In dbt, a semantic model is the foundation of MetricFlow, and each one maps to a single dbt model. In the latest spec (dbt Core 1.12+ and the Fusion engine), the semantic model nests inside the model’s YAML, and simple metrics replace the older measures block:

models:
-name: fact_transactions
description:"Transaction fact table, one row per transaction."
semantic_model:
enabled:true
agg_time_dimension: transaction_date
columns:
-name: transaction_id
entity:{type: primary,name: transaction}
-name: customer_id
entity:{type: foreign,name: customer}
-name: transaction_date
granularity: day
dimension:{type: time}
metrics:
-name: transaction_total
type: simple
agg: sum
expr

models:
-name: fact_transactions
description:"Transaction fact table, one row per transaction."
semantic_model:
enabled:true
agg_time_dimension: transaction_date
columns:
-name: transaction_id
entity:{type: primary,name: transaction}
-name: customer_id
entity:{type: foreign,name: customer}
-name: transaction_date
granularity: day
dimension:{type: time}
metrics:
-name: transaction_total
type: simple
agg: sum
expr

models:
-name: fact_transactions
description:"Transaction fact table, one row per transaction."
semantic_model:
enabled:true
agg_time_dimension: transaction_date
columns:
-name: transaction_id
entity:{type: primary,name: transaction}
-name: customer_id
entity:{type: foreign,name: customer}
-name: transaction_date
granularity: day
dimension:{type: time}
metrics:
-name: transaction_total
type: simple
agg: sum
expr

models:
-name: fact_transactions
description:"Transaction fact table, one row per transaction."
semantic_model:
enabled:true
agg_time_dimension: transaction_date
columns:
-name: transaction_id
entity:{type: primary,name: transaction}
-name: customer_id
entity:{type: foreign,name: customer}
-name: transaction_date
granularity: day
dimension:{type: time}
metrics:
-name: transaction_total
type: simple
agg: sum
expr

Entities (primary, foreign, unique, natural) tell MetricFlow how to join models automatically, which is what makes cross-model metrics possible. Our dbt Semantic Layer guide walks through a full MetricFlow setup.

Snowflake: Semantic Model vs Semantic View

Snowflake originally defined business meaning for Cortex Analyst as a semantic model: a YAML file uploaded to a stage. It now recommends semantic views for all new implementations. Semantic views are schema-level objects you can grant privileges on, share, and query with SQL. Existing YAML still works, and SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML converts it. For syntax, querying, and limits, see our Snowflake semantic views guide.

Snowflake’s spec is a good example of a semantic model built for AI. Look at the fields on a single dimension in its YAML specification:

dimensions:
-name: customer_segment
expr: c_mktsegment
data_type: VARCHAR
description: Market segment the customer belongs to
synonyms:["segment","market segment"]
is_enum:true
sample_values:["AUTOMOBILE","BUILDING","MACHINERY"

dimensions:
-name: customer_segment
expr: c_mktsegment
data_type: VARCHAR
description: Market segment the customer belongs to
synonyms:["segment","market segment"]
is_enum:true
sample_values:["AUTOMOBILE","BUILDING","MACHINERY"

dimensions:
-name: customer_segment
expr: c_mktsegment
data_type: VARCHAR
description: Market segment the customer belongs to
synonyms:["segment","market segment"]
is_enum:true
sample_values:["AUTOMOBILE","BUILDING","MACHINERY"

dimensions:
-name: customer_segment
expr: c_mktsegment
data_type: VARCHAR
description: Market segment the customer belongs to
synonyms:["segment","market segment"]
is_enum:true
sample_values:["AUTOMOBILE","BUILDING","MACHINERY"

is_enum: true tells Cortex Analyst that the sample values are the complete list. That one field prevents the agent from filtering on a value that doesn’t exist.

Cube, LookML, and Tableau Semantics

In Cube, the semantic model is made of cubes (usually one per table) with measures, dimensions, and joins, plus views that expose curated slices to consumers (more on how the Cube semantic layer works). In Looker, LookML is “the language that is used in Looker to create semantic data models”, organized into views, explores, and models. Tableau Semantics is the AI-assisted semantic layer behind Tableau Next. Each stores the same kind of thing in a different format, which is why the industry’s Apache Ossie project (formerly the Open Semantic Interchange) is working on a shared spec. Databricks takes a similar approach with metric views in Unity Catalog.

The Original Meaning: The Semantic Data Model

Long before BI vendors used the phrase, “semantic data model” was a database research term. Hammer and McLeod’s 1981 paper “Database Description with SDM” proposed describing databases in terms of real-world entities, classes, and relationships rather than storage structures. The same idea fed the US Air Force’s ICAM program and the IDEF1X modeling standard, as Wikipedia’s history of the semantic data model covers.

The core abstractions still apply: classification (this row is a Customer), aggregation (an Order is made of line items), and generalization (an Enterprise Customer is a kind of Customer). Modern BI semantic models are a practical, metrics-focused descendant of that theory.

Semantic Model vs Ontology

A semantic model and an ontology overlap, but they answer different questions. A semantic model is built for analytics. It defines metrics, dimensions, and join paths so numbers compute correctly. An ontology is built for meaning across the business. It defines entity types, their properties, how they relate, and sometimes what actions can be taken on them, often across systems beyond the warehouse.

Think of it as a spectrum of increasing richness: glossary → taxonomy → semantic model → ontology. Our data ontology guide shows the same example built as each. Upsolve calls its Data Models feature the “ontology” layer for this reason. It describes what your data is and how it connects, not just how to aggregate it.

Why AI Agents Need More Than a BI Semantic Model

A BI semantic model was designed for a person clicking a report. That person already knows what “active” means and picks values from a dropdown. An agent writing SQL has no dropdown. It has to know, before it writes a WHERE clause, which values exist, which table is authoritative, and which definition applies.

The evidence that richer models help is consistent:

• Snowflake found that agentic improvements to the semantic model (better descriptions, synonyms, and sample values) raised average accuracy from 57% to 78% across four BIRD datasets with Claude 3.5 Sonnet. This was a vendor test.

• dbt Labs’ 2026 benchmark found raw-schema text-to-SQL at 64.5% with current models, while the dbt Semantic Layer on a modeled project scored 98–100%.

• Column descriptions alone help, but modestly. An Alibaba study on BIRD found gains of a point or two, with human-written descriptions beating generated ones and overly long descriptions hurting.

That last point matters. Descriptions are necessary but not sufficient. The big gains come from the structure around them. Together, that structure is what we call a context layer.

What an Agent-Ready Data Model Contains

Pro tip: Scope beats size. Databricks recommends that a Genie space aim for five or fewer tables, and says quality table and column descriptions are “critical for Genie accuracy.” A tight model with complete descriptions outperforms a sprawling one.

How to Create a Semantic Model in 7 Steps

1. Start from questions, not tables. List the 5–10 questions people ask most, and the metrics they argue about.

2. Register only the tables those questions need. Leave staging and deprecated tables out.

3. Declare keys and relationships. Primary keys, foreign keys, and the cardinality of each join.

4. Write short descriptions with units and exclusions. “ARR in USD, MRR × 12, excludes one-time fees” beats “ARR.” The same rules apply to a good data dictionary.

5. Define each metric once. One formula, one owner, one source table. That discipline is what a metrics layer formalizes.

6. List allowed values for categorical columns. Statuses, plan tiers, regions, payment terms.

7. Version it and test it with real questions. Every wrong or refused answer points to the next definition to add.

Don’t Have a Semantic Layer Yet? Start With a Data Model

Most teams don’t have a complete, maintained semantic model, and they shouldn’t need one before an agent can help. Upsolve Data Models is built for exactly that situation:

• Register your tables with descriptions, types, and primary and foreign keys, directly on your warehouse. No dbt required.

• Encode your vocabulary (canonical definitions, analysis approaches, and output formats) in a versioned system prompt with drafts and rollback.

• Mark columns as selectable so Upsolve pre-caches their values on a nightly or custom schedule. The agent knows your five contract statuses and four payment terms before it writes SQL.

If you already have dbt semantic models, import them. If you don’t, start from your warehouse and add definitions as gaps appear.

Frequently Asked Questions

What is a semantic model example?

A simple example is a sales model where fact_orders joins to dim_customer, and “net revenue” is defined as SUM(amount) - SUM(refund_amount) excluding test accounts. Every tool that reads the model computes net revenue the same way and can slice it by segment, region, or month.

Is a semantic model the same as a data model?

No. A data model describes how data is stored: tables, columns, data types, and keys. A semantic model sits on top of it and describes what the data means: business entities, metrics, dimensions, and approved join paths. You need the data model first.

Is a Power BI semantic model the same as a dataset?

Yes. Microsoft renamed Power BI datasets to semantic models in November 2023. Functionality didn’t change. A few areas, including the REST APIs and streaming datasets, still use the old name.

What is the difference between a semantic model and a semantic view in Snowflake?

A semantic model is a YAML file stored on a Snowflake stage, originally the only way to configure Cortex Analyst. A semantic view stores the same definitions as a schema-level database object, with privileges, sharing, and SQL querying. Snowflake recommends semantic views for new work.

What is the difference between a semantic layer and a semantic model?

A semantic model is a set of definitions for one domain or dataset. A semantic layer is the system that hosts one or more semantic models and serves them to many tools through APIs, a query engine, and access controls.

Do AI agents need a semantic model?

They need what a semantic model provides (definitions, relationships, and metrics) plus allowed values, authoritative tables, and vocabulary. Agents grounded in that context are measurably more accurate. A formal semantic layer is one way to provide it; an agent data model built directly on the warehouse is another.

Sources

1. Microsoft Learn: Datasets renamed to semantic models. https://learn.microsoft.com/en-us/power-bi/connect-data/service-datasets-rename

2. Microsoft Learn: Understand Power BI semantic models. https://learn.microsoft.com/en-us/power-bi/connect-data/service-datasets-understand

3. Microsoft Learn: Semantic model modes in the Power BI service. https://learn.microsoft.com/en-us/power-bi/connect-data/service-dataset-modes-understand

4. Microsoft Learn: Direct Lake overview. https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview

5. Microsoft Learn: Prepare your data for AI. https://learn.microsoft.com/en-us/power-bi/create-reports/copilot-prepare-data-ai

6. Chris Webb’s BI Blog: Thoughts on Power BI datasets being renamed to semantic models (Nov 2023). https://blog.crossjoin.co.uk/2023/11/18/thoughts-on-power-bi-datasets-being-renamed-to-semantic-models/

7. dbt Labs: Semantic models documentation. https://docs.getdbt.com/docs/build/semantic-models

8. Snowflake: Semantic models vs. semantic views. https://docs.snowflake.com/en/user-guide/views-semantic/semantic-models-vs-views

9. Snowflake: Semantic view YAML specification. https://docs.snowflake.com/en/user-guide/views-semantic/semantic-view-yaml-spec

10. Snowflake Engineering: Agentic semantic model improvement for text-to-SQL (Mar 2025). https://www.snowflake.com/en/engineering-blog/agentic-semantic-model-text-to-sql/

11. Cube: Data modeling overview. https://docs.cube.dev/docs/data-modeling/overview

12. Google Cloud: What is LookML? https://docs.cloud.google.com/looker/docs/what-is-lookml

13. Salesforce: Tableau Semantics. https://www.salesforce.com/analytics/tableau-semantics/

14. Apache Ossie: Project home. https://ossie.apache.org/

15. Hammer & McLeod (ACM TODS, 1981): Database Description with SDM: A Semantic Database Model. https://dl.acm.org/doi/10.1145/319587.319588

16. Wikipedia: Semantic data model. https://en.wikipedia.org/wiki/Semantic_data_model

17. dbt Labs: Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update. https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026

18. Gao & Luo (arXiv, 2025): Column descriptions and text-to-SQL accuracy on BIRD. https://arxiv.org/html/2502.20657v1

19. Databricks: Genie best practices. https://docs.databricks.com/aws/en/genie/best-practices

20. Upsolve AI: Data Models. https://upsolve.ai/features/data-models