If you work with business intelligence, you know the problem: the same KPI appears in three dashboards, but each definition is slightly different. Revenue in one report excludes returns, in another it includes them. Often they start from the same definition, but over time a change to the metric is applied only in dashboards 1 and 2, another only in 1 and 3, and a third only in dashboard 2. Management compares figures that are not comparable — and nobody knows exactly where the difference lies.
The cause often lies not in the visualisation, but in how the semantic layer is set up: where definitions of dimensions and measures live, and how dashboards are linked to them.
In DataOwn you build that layer centrally with the Model Builder. One place for all your star schemas, one shared definition of every measure — and in every dashboard you can combine all the star schemas you need.
What is a semantic layer?
A semantic layer is the translation layer between raw database tables and what people see in reports. It contains dimensions (fields you group or filter by), measures (aggregations such as sum or average) and relationships between fact and dimension tables in a star schema.
Without a central layer, every report builder copies this logic again. With a central layer, your BI team defines "revenue" once — and every dashboard uses the same definition.
That aligns with how open-source BI tools set up semantic models. Lightdash, which DataOwn uses for dashboards, describes the same principle in their semantic layer: define metrics, dimensions and tables once in YAML (often via dbt), and then use them consistently in the app, via API and by AI agents.
AI-based chat-with-your-data is the current talk of the town in BI. Ask questions in plain language and get a full analysis of your data back. However, reliability is a problem. Research consistently suggests that a semantic layer is essential for reliable answers — and it gives AI a single source of truth for every definition.
One Model Builder, multiple star schemas
In DataOwn, the Model Builder is the heart of your semantic layer. You can build star schemas: a fact table with measures, surrounded by dimension tables (customer, product, time, organisation). That follows common Kimball principles — but a star schema is one option; other modelling approaches are possible too.
The difference from "writing a query per report" is structural:
- You define multiple star schemas — sales, inventory, service costs — each with clear granularity.
- Measures are defined centrally — name, aggregation, display format and description.
- All star schemas live in the same semantic layer — joins are defined in the Model Builder.
- Every dashboard can use all star schemas — including across different star schemas, without a separate data model per report.
How this differs from the standard Power BI workflow
In Power BI Desktop, the standard workflow for many teams is: new .pbix file, load data, model in that file, build visuals, publish. The semantic model sits in or is directly linked to that report. Two dashboards on the same source data easily lead to two parallel models.
Power BI has alternatives: shared datasets with "thin reports", or semantic models in Fabric. That works, but requires extra setup — central dataset management, often Premium/Fabric capacity, and discipline not to fall back on separate .pbix files. Without that setup, the pattern is often: effectively one semantic layer per dashboard.
DataOwn turns that around: by default one semantic layer for the platform, with the Model Builder as the central place. Dashboards consume that layer; they do not redefine it.
Get started
Read the full explanation in our documentation: Model Builder.