DP-600 Step by step · Module 8

Direct Lake Semantic Models: The Star Schema Done Right

Import, DirectQuery or Direct Lake? Create a Fabric semantic model in Direct Lake mode over a lakehouse star schema with correct relationships.

8 November 2026 · 5 min read

Three storage modes: Import, DirectQuery and Direct Lake, where the data lives and the trade-off — Watch the lesson: Module 8: The semantic model, Direct Lake and relationships - Hands-On Lab | Microsoft Fabric DP-600

The lakehouse holds a clean star: six dimensions and two fact tables. But a report does not read tables. It reads a semantic model: the tables, the relationships between them, and the calculations. In Module 8 of the DP-600 course we build one for Wide World Importers.

The first decision: storage mode

Import: a copy inside the model; DirectQuery: in the source; Direct Lake: in OneLake as Delta — Three storage modes and their trade-offs.

Import copies the data into the model. Queries are the fastest, and the copy must be refreshed.
DirectQuery copies nothing: every visual sends a query to the source. Always current, and slower.
Direct Lake reads the Delta tables in OneLake directly: the speed of import, without the copy.

When the data is already in a Fabric lakehouse or warehouse, start with Direct Lake.

Step 1: Create the model

From the lakehouse, create a new semantic model named WWI Sales, in the WWI-Dev workspace.

New semantic model dialog: Direct Lake semantic model name and workspace — A Direct Lake model starts from the lakehouse.

Step 2: Pick exactly the tables you need

The lakehouse also holds the raw tables from Lab 1, and we do not want those. Tick exactly eight: the six dimensions (customer, date, geography, product, salesperson and territory) and the two facts.

Select tables for the semantic model with the dimension tables listed — Only the curated star; raw tables stay out of the model.

The model opens in model view: eight tables as cards, and no lines between them yet. Nothing was copied; the model points at the Delta tables of the lakehouse.

Model view with table cards for dimensions and no relationships yet — The tables, before any relationship.

Step 3: Build the star

A relationship connects a key of the fact to the same key of a dimension: many sales, one customer. A filter travels along it, from the dimension to the fact.

The budget is kept per territory and per month, not per city and per day, so it joins the dimensions at a different grain. And one relationship is easy to forget: dim geography → dim territory (many cities, one territory). With it, a slicer on the territory filters the cities, the cities filter the sales, and the budget follows.

Relationship properties: dim geography SalesTerritory to dim territory, many to one, active — Many to one, single direction, active: the default for a star.

Exam warning: in Direct Lake, the editor does not check your keys for you. A wrong relationship gives wrong totals, not an error.

How you know it worked

The relationships list shows every relationship with its two columns and cardinality, all active, and the diagram shows the fact table in the middle of its dimensions, with the budget joined through the territory and the date.

Rules to remember

Between two tables only one relationship is active. A second one, such as the delivery date, stays inactive until a measure asks for it.
Many-to-many and both-direction filters are exceptions: they cost performance and can give surprising totals. Use them only with a reason.

Do it yourself

Lab guides, practice and full mock exams come with a subscription. See the plans