Every new platform generation arrives with a claim that modeling is no longer necessary: the cube made it unnecessary, then the data lake, then the lakehouse, and now the language model that will “just understand the tables.” Each time, the organizations that skipped the modeling paid for it in reconciliation meetings. The dimensional techniques Ralph Kimball codified are still the shortest path from raw tables to numbers executives trust, and Microsoft’s own guidance for Power BI says so in as many words [1][2]. What has changed is what sits around the model.
What still holds
The Kimball Group’s technique catalog, drawn from The Data Warehouse Toolkit, remains the working reference: fact and dimension tables, grain, conformed dimensions, slowly changing dimensions, hierarchies and the bus matrix [1]. Five of those techniques do most of the work in practice.
- Declare the grain first. One row per order line, per shipment event, per policy-month. Every modeling argument I have seen in twenty years traces back to an undeclared grain.
- Conform the dimensions. One Customer dimension shared by sales, service and finance facts, with the same keys and attributes, is what lets a report cross business processes without a committee.
- Handle change explicitly. Type 1 (overwrite) for corrections, Type 2 (new row with effective dates) for history that matters, such as a customer’s sales territory or a product’s category. Decide per attribute, write it down.
- Use surrogate keys. Integer keys the warehouse controls insulate the model from source-system key changes and make Type 2 history possible.
- Build the bus matrix before the tables. A grid of business processes against dimensions is the plan, the scope document and the integration test in one page.
What has changed underneath
The physical layer is different and in some ways easier. Columnstore storage and lakehouse formats (Delta tables on OneLake) make wide, denormalized dimensions cheap to scan, so there is less pressure to snowflake for storage reasons [3]. Direct Lake lets a Power BI semantic model read Delta tables in OneLake directly into memory, without an import refresh, which rewards a clean star in the gold layer because the model and the storage now share a shape [4]. And the medallion pattern (bronze raw, silver cleaned, gold modeled) gives the star schema a named home: gold is where dimensional modeling happens [5].
What this does not change: the gold layer still needs grain, conformed dimensions and surrogate keys. A lakehouse with a hundred silver tables and no gold stars is a data swamp with better compression.
Where the toolkit needs help
1. The semantic layer is now part of the model
Kimball’s model stopped at the tables; the measures lived in the reporting tool. Today the measures, their format strings, the relationships, security roles and descriptions are a governed artifact in their own right, and in Power BI that artifact can be stored as readable text (TMDL) and version-controlled like code [6]. Treat the semantic model as the last layer of the dimensional design, not as a report-side afterthought, and give every measure a definition a business reader could audit.
2. Data contracts and tests at the grain
The original toolkit assumed a warehouse team controlled the sources. Modern pipelines ingest from SaaS APIs, event streams and vendor feeds that change without notice. The fix is a contract per source (schema, keys, freshness, allowed values) and automated tests that assert the grain: uniqueness of the business key, not-null foreign keys, referential integrity between fact and dimension. dbt’s data tests make these assertions one line of YAML each [7], and the same tests can run against SQL Server or a Fabric warehouse.
3. Near-real-time facts
Nightly batch is no longer the only cadence. Operational dashboards want minutes. The modeling answer is not to abandon the star but to add a hot fact partition fed by streaming or mirroring, with the same grain and keys, and to be explicit that late-arriving dimensions will be resolved on the next batch [4]. Incremental refresh and real-time partitions in Power BI exist precisely for this split [8].
4. Models that machines read
Copilot and Fabric data agents answer questions by reading the semantic model’s names, descriptions, relationships and synonyms [9]. A fact table called F_SHP_LN2 with a measure called Amt3 is unreadable to a person and to a model. Dimensional modeling always rewarded business-readable naming; AI makes it mandatory. Descriptions on every table and measure, synonyms for business terms, and a short “how to answer common questions” note in the model are now part of the design deliverable.
5. Security as a modeled dimension
Row-level security used to be a report setting. It is better modeled as a security dimension (user to region, user to customer group) that the semantic model’s roles filter on with a dynamic rule such as [UserEmail] = USERPRINCIPALNAME() [10]. It belongs on the bus matrix like any other dimension, because every fact that carries a region key inherits it.
A 2026 modeling checklist
| Deliverable | Classic Kimball | Added in 2026 |
|---|---|---|
| Bus matrix | Yes | Add a security dimension and a freshness column per fact |
| Grain statement per fact | Yes | Encoded as a uniqueness test in the pipeline |
| Conformed dimensions with SCD policy | Yes | Stored as Delta tables in the gold layer; policy in the data contract |
| Measures and definitions | In the BI tool | In the semantic model, in TMDL, in source control, with descriptions and synonyms |
| Load design | Nightly batch | Batch plus a hot partition; mirroring where the source supports it |
| Tests | Manual reconciliation | Automated uniqueness, referential and accepted-value tests on every run |
Kimball’s core insight was never about tables. It was that analytics should be modeled around how the business thinks about its processes, so that a question asked in business language has an obvious path to an answer. That is exactly the property that fast storage, live data and language models reward. The toolkit needs a few new chapters; it does not need replacing.
Related: OLTP vs OLAP and Microsoft Fabric for SQL Server shops.
References
- Kimball Group, “Dimensional Modeling Techniques,” kimballgroup.com/…/dimensional-modeling-techniques (accessed 9 Oct 2026).
- Microsoft Learn, “Understand star schema and the importance for Power BI,” learn.microsoft.com/en-us/power-bi/guidance/star-schema (accessed 9 Oct 2026).
- Microsoft Learn, “What is a lakehouse in Microsoft Fabric?” learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-overview (accessed 9 Oct 2026).
- Microsoft Learn, “Direct Lake overview,” learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview (accessed 9 Oct 2026).
- Microsoft Learn, “Implement medallion lakehouse architecture in Fabric,” learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture (accessed 9 Oct 2026).
- Microsoft Learn, “Tabular Model Definition Language (TMDL),” learn.microsoft.com/en-us/analysis-services/tmdl/tmdl-overview (accessed 9 Oct 2026).
- dbt Labs, “Add data tests to your DAG,” docs.getdbt.com/docs/build/data-tests (accessed 9 Oct 2026).
- Microsoft Learn, “Configure incremental refresh and real-time data for Power BI semantic models,” learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-overview (accessed 9 Oct 2026).
- Microsoft Learn, “Fabric data agent concepts,” learn.microsoft.com/en-us/fabric/data-science/concept-data-agent (accessed 9 Oct 2026).
- Microsoft Learn, “Row-level security (RLS) with Power BI,” learn.microsoft.com/en-us/fabric/security/service-admin-row-level-security (accessed 9 Oct 2026).
