What is a star schema and why does it matter in Power BI?

A star schema separates tables into two kinds:

• Fact tables — the events or transactions you measure. Long and narrow, containing numeric values and foreign keys. Sales, orders, page views.
• Dimension tables — the context you slice by. Short and wide, containing descriptive attributes. Date, Product, Customer, Region.

Dimensions relate to facts one-to-many, with filters flowing from dimension to fact — producing a diagram shaped like a star.

Why it matters so much in Power BI:

• The engine is built for it. VertiPaq compresses columns, and a star schema produces exactly the pattern it optimises for. A flat wide table or a snowflake with many joins performs worse, often dramatically so.
• Filters behave predictably. Ambiguous paths and bidirectional relationships in a poorly shaped model cause wrong totals that are extremely hard to debug.
• DAX becomes simpler. Many complex measures written to work around a bad model become one line against a good one.
• Slicers work naturally, because dimension attributes are where they belong.

Note: The single most important practical instance is a dedicated Date dimension marked as a date table. Without one, time intelligence functions such as SAMEPERIODLASTYEAR and YTD either fail or return wrong results — and this catches out a large proportion of candidates.