Power BI
Advanced 16 min read Power BI

Power BI Modeling

Star-shaped, filter-directionally correct

The Power BI model (Analysis Services tabular) is where relationships, hierarchies, measures and roles come together. A clean star-style model is the difference between a reliable platform and a house of cards.

Power BI modelrelationshipsmodel viewhierarchiesmeasuresstar model
Prerequisites: Star Schemas Data Modeling
Before we start

What you will learn

  • Design a star-shaped model in Model view
  • Configure relationship cardinality and filter direction correctly
  • Put measures and hierarchies in the model, not the report
Introduction

What is this?

The Power BI model is a tabular (Analysis Services) in-memory model holding tables, relationships, hierarchies, calculated columns/measures and security roles. Best practice is a star/snowflake of dims around facts, with one-way filter propagation from dim to fact. The model — not the report — is the durable asset you publish.

Motivation

Why do you need it?

  • Relationships + filter direction determine every aggregate on every visual.
  • A reused measure in the model stops 40 visuals from re-deriving 'revenue'.
  • Star shapes make filter logic predictable and avoid ambiguity errors.
  • Hierarchies and roles in the model serve the whole report gallery.
Think about it

Mental model

Imagine

A city's power grid

Think of

The Power BI model

Lines (relationships) carry current (filters) in one direction from stations (dimensions) to users (facts). Mis-wire the direction and whole districts flicker wrong. The grid is engineered once; every building (report) simply plugs in.

Mechanics

How it works

  • Model view shows tables and relationship lines; you set cardinality (1:* etc.) and filter direction.
  • One-way dim→fact filtering propagates slicers and filters predictably.
  • Hierarchies (region → country → city) enable drill-down across visuals.
  • Measures live in the model: DAX evident where context is applied.
  • Roles in the model define row-level security for the service layer.

A star-shaped Power BI model with one-way filter flow.

Dim tables
One-way filters
Fact tables
Measures
Reports
Hands-on

Examples

What belongs in the model vs the report

What belongs in the model vs the report
-- MODEL side (measures):
Revenue    = SUMX(fact_orders, fact_orders[amount] * (1 - fact_orders[discount]))
Orders     = COUNTROWS(fact_orders)
AOV        = DIVIDE([Revenue], [Orders], 0)
 
-- REPORT side: visuals just reference the measures and group by dims
-- Revenue by region (dim_customer), by fiscal quarter (dim_date)

The model owns definitions; the report owns layout. Same revenue everywhere, regardless of how many visuals reference it.

Real world

In production

  • A finance dataset models fact_pnl with dim_date/dim_entity/dim_acct, one-way filtered; every report inherits consistent slicing.
  • A sales model stores [Revenue], [Orders], [AOV] and roles per region, so dashboards never recalc.
  • A star-shaped customer model uses role-playing date dims (order, ship, due) without ambiguity errors.
Guidelines

Best practices

  • Keep the model star-shaped: facts + few conformed dims.
  • One active relationship per dimension path; use inactive for alternate roles.
  • Store measures in the model with clear names and documentation.
  • Calibrate cardinality: avoid many-to-many except with explicit bridge tables.
Watch out

Common mistakes

  • Many-to-many relationships configured as 1:* causing ambiguous filters.
  • Both-direction filtering creating slow, circular dependency behavior.
  • No measures in the model — every visual re-implements the same logic.
  • Deep snowflakes defeating the in-memory advantage.
Root cause analysis

Common issues

Error
Slicer on 'region' filters unrelated tables
Root cause

Bidirectional filtering crossing unwanted paths

Fix

Revert to one-way dim→fact and route alternates via DAX (USERELATIONSHIP).

Error
Distinct count doubled on cross-slicing
Root cause

Snapshot/dim relationship fan-out

Fix

Model the correct grain (bridge or fact-level membership).

When things break

Debugging tips

  • Wrong aggregate → check relationship path and filter direction first.
  • Ambiguity error → more than one active path; disable one or use a bridge.
  • Slow model → inspect model size, cardinality and DAX; disable unused relationships.
Interviews

Interview checkpoint

Practice

Hands-on lab

Build a Star Model in Model View
40 min · advanced
In progress
Objectives
  • Create facts + dims and relationships in the Power BI model view
  • Wire one-way filter direction correctly
  • Add a hierarchy and a model measure

Build a Star Model in Model View

40 min · advanced

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Best-practice filter direction in a Power BI star model is:

2

Measures should be defined once in the model rather than per-visual.

Go deeper

Official documentation

Power BI — model relationships
docs
Power BI — star schema guidance
docs