What is a semantic data model?

What a semantic data model is

A semantic data model is a description of data in business terms. It has three kinds of statement:

• Entities: the things the business tracks, such as Customer, Order and Product.
• Attributes: what is recorded about each entity, such as an order’s date and status.
• Relationships: how entities connect, with a name and a direction: a customer places an order.

The idea comes from database research. Michael Hammer and Dennis McLeod presented the Semantic Data Model at ACM SIGMOD in 1978 and described it in full in “Database Description with SDM: A Semantic Database Model” (ACM Transactions on Database Systems, 1981). Their argument was that a relational schema records structure and loses meaning: a column called status does not say which statuses count as a sale.

That gap is still the reason people build one. The tables are correct, and two analysts still get two revenue numbers from them.

Semantic data model, semantic model, semantic layer

Three terms sound alike and get searched together. They are not the same thing.

Two of these are product names with exact meanings:

• Power BI. Microsoft renamed the Power BI dataset to semantic model in November 2023, saying the new name “better reflects the rich functionality of Analysis Services data models” (Microsoft Learn, checked October 2026). If a colleague says “the semantic model is broken”, this is usually what they mean.
• dbt. In the dbt Semantic Layer, a semantic model is YAML that sits on a dbt model and declares its entities (the join keys), dimensions and metrics. MetricFlow reads it and builds the SQL (dbt documentation, checked October 2026).

The rest of this guide is about the first row: the description itself, whichever tool ends up holding it. For the third row set against a data model and a Data Mart, and when it is worth building, see semantic layer vs data model vs Data Mart.

The parts of a semantic data model

Every semantic data model answers four questions about the data. If one is missing, the model is a diagram and not yet a definition.

Entities

An entity is something the business would name in a meeting: a customer, an order, a product, a campaign. One row of an entity is one real thing. The first decision is the hardest one, which is what a row stands for. “One row per order” and “one row per order line” give different totals from the same data.

Attributes

Attributes are the facts recorded about an entity. For an order: the date, the status, the customer who placed it. A useful attribute comes with a plain description and its allowed values, because the allowed values are where the business rules hide.

Relationships

A relationship says how two entities connect and through which key. It also says how many: one customer has many orders, one order has many lines. Getting the “how many” wrong is what duplicates revenue in a join.

Business rules

Rules turn attributes into numbers people argue about. “Revenue counts completed orders only” is a rule. So is “a customer is new in the month of their first completed order”. A semantic data model that stops at boxes and arrows leaves these to whoever writes the next query.

A worked example: an online store

Take a store that tracks customers, orders, order lines, products and categories. The diagram adds payment method and region.

In words, the model says:

1. A customer places many orders. An order belongs to one customer.
2. An order has one or more order lines. Each line is one product and a quantity.
3. A product belongs to one category.
4. An order has a status: Completed, Cancelled or Returned.
5. Revenue is the sum of line revenue on Completed orders.

Statements 1 to 4 are structure. Statement 5 is meaning, and it is the one that changes the number.

Here is revenue by category written against that model. The tables are the OWOX demo e-commerce dataset in Google BigQuery. The query was run on 8 October 2026 and the figures below are its output:

SELECT
  c.category_name,
  COUNT(DISTINCT o.order_id)
    AS orders,
  ROUND(SUM(p.line_revenue))
    AS revenue
FROM
  `owox-demo.ecommerce.orders` o
JOIN
  `owox-demo.ecommerce.purchases` p
  ON p.order_id = o.order_id
JOIN
  `owox-demo.ecommerce.products` pr
  ON pr.product_id = p.product_id
JOIN
  `owox-demo.ecommerce.product_category` c
  ON c.category_id = pr.category_id
WHERE o.status = 'Completed'
GROUP BY c.category_name
ORDER BY revenue DESC

Remove the WHERE line and the query still runs and still looks right. On this dataset, line revenue across every order is 8,835,903. On completed orders it is 7,497,509. The difference, 1,338,394, is cancelled and returned orders: 15% of the larger number.

Nothing in the tables says which is correct. The semantic data model does, in statement 5. That is the whole job of the model: to make the second number the only one anybody can get.

How it differs from conceptual, logical and physical models

A semantic data model is often confused with the three classic levels of data modeling. The difference is the question each one answers.

The first three describe the data at different levels of detail. The semantic model describes its meaning, and it can sit on top of any of them. A conceptual data model is the nearest relative: both use entities and relationships, but a conceptual model is drawn before the tables exist and a semantic model has to stay true to the tables that do. For the other two levels, see logical vs physical data models, and for the wider map, types of data models.

What a semantic data model costs to keep

Writing the model is the cheap part. The cost arrives with the first change.

Suppose the store adds a status, Partially refunded. The revenue rule now needs a decision, and the decision has to be made in every place the rule is written down:

• the SQL that builds the reporting tables,
• the semantic model or layer that defines “revenue” for the tools,
• each dashboard or sheet that carries its own filter,
• the documentation people read.

If those are four separate artifacts, the analyst maintains four descriptions of one rule, and the report is wrong for as long as any one of them is behind. Nothing fails. The old number keeps arriving, and it looks exactly like a correct one.

This is the practical argument about semantic layers. A separate layer is a second description of logic that already exists in SQL, written in another language (YAML, LookML, DAX) and kept by hand. It pays off when many tools must share many metrics and a team owns the layer full time. It does not pay off when one analyst is asked to keep it in step with the business alongside everything else. For the same question asked about AI, see whether an AI agent needs a semantic layer.

So before choosing a tool, count the copies. The useful question is not “which semantic layer” but “where will a rule live so that it is written once?”

Keeping the meaning next to the SQL

One answer is to stop separating the two. Instead of a model that describes the queries from a distance, attach the meaning to the query that produces the data.

This is how OWOX Data Marts is built. A Data Mart is a dataset an analyst defines with SQL, a table or a view, plus the metadata that would otherwise go into a separate layer:

• a description and an owner,
• a name, a type and a description for each output field,
• relationships to other Data Marts, declared on join keys.

The Data Marts in one data storage, with the relationships between them, form the data model. In the store example, “Completed orders only” is written once, in the SQL of the Orders Data Mart. A report in Google Sheets, a dashboard in Looker Studio and a question asked in an AI assistant all read that Data Mart, so none of them can pick the other revenue.

Two things this approach does not do, and it is better to know them first:

• It does not write the SQL. The analyst defines every Data Mart. The product publishes, schedules and governs what the analyst wrote.
• It covers what has been defined. A metric nobody has put into a Data Mart is not answered by approximation. The request goes back to the data owner.

It also assumes the data is already in a warehouse: Google BigQuery, Snowflake, AWS Redshift, AWS Athena or Databricks. For how relationships are declared, see Joinable Data Marts. For field names, keys and descriptions on a single Data Mart, see governed metrics with output schemas. A store model of this shape is available ready-made as the E-commerce data model.

How to choose

Three questions settle most cases.

1. How many tools read the numbers? One BI tool can hold the meaning itself, as a Power BI semantic model does. Several tools need the meaning outside any one of them.
2. Who will maintain it? A dedicated analytics engineering team can run a semantic layer. One analyst should have one place to edit.
3. Is the SQL already written? If the business logic exists as tested queries, a model that reuses them is days of work. A model that restates them in another language is a project, and the restated copy starts to drift the day it ships.

Whichever way it goes, test the result the same way as the example above: pick one disputed number, change its rule, and count how many files you had to open.

Data ModelingWhat is data modeling? Process, types and techniquesFebruary 27, 2025→Data ModelingTypes of data models: the three levels and seven structures, with examplesOctober 7, 2026→Data Modeling8 data modeling mistakes and how to avoid themApril 9, 2025→

See all articles →