Power BI Star Schema Explainer

What a star schema is

A star schema has one fact table at the center — the table with your actual measures (sales amount, order count, revenue) and one row per event or transaction — surrounded by dimension tables that each describe one aspect of that event: who the customer was, what product it was, when it happened, where it happened. Every dimension connects directly to the fact table, never to another dimension, which is what gives the shape its name — a central point with spokes radiating out.

Why Power BI prefers it

Power BI's engine (VertiPaq) is built around exactly this shape: short, direct relationship paths between a fact table and its dimensions compress better, filter faster, and produce fewer ambiguous filter-propagation paths than a deeply nested or circular model. A flat, single-table model works for small, simple data but wastes storage repeating dimension values on every row; a star schema normalizes those values into their own small tables instead.

Star schema vs. snowflake schema

A snowflake schema is a star schema where some dimension tables are broken down further into their own sub-dimensions (Product → Subcategory → Category, each its own table). It can save some storage, but every extra hop adds a relationship Power BI has to traverse, which usually makes queries slower and the model harder to reason about. For most Power BI reports, flattening those sub-dimensions back into one Product table (a plain star schema) performs better and is simpler to build measures against.

A worked example

A retail dataset with one wide table (every sale, with the customer's full name, address, and product description repeated on every row) is NOT a star schema — it's flat. Splitting it into a Sales fact table (just the transaction: date, customer ID, product ID, amount) plus separate Customer, Product, and Date dimension tables turns it into one.