Model Your Data in Power BI: Star Schemas, Filter Flow & Field Lists

Video by: Reid Havens

Plenty of Power BI issues that look like DAX issues start one layer down, in the model. The formula is correct, the relationship underneath it isn't doing what you assumed, and you spend an afternoon rewriting a measure that was never the problem.

This one covers the foundation the rest of it sits on. Why a model beats one giant flat table (smaller storage, better compression, faster refresh, and filter paths you get without writing any code), how dimensions and facts split the who-what-when-where from the numeric events, and what actually happens when someone picks a value in a slicer and that filter travels down the relationship into the fact table.

Then star versus snowflake, compared on the four things that decide it in practice: query performance, DirectQuery latency, how long the DAX ends up, and whether business users can find a field without asking someone. Star wins on all four. I also get into why the snowflake version keeps turning up anyway, since it usually arrives from a source system rather than from a decision anyone made.

The last section is the one that gets skipped. Every visual in Power BI generates a query with three ingredients (filter, group, summarize), and once that clicks, a wrong number stops being mysterious. After that it's the fields list itself: friendly names instead of cgo_key_fk, display folders, hidden keys, and descriptions that surface as tooltips. It sounds cosmetic, but an unreadable fields list is how you end up with six competing Excel copies of the same report.

DAX Fundamentals Part 3: The Patterns That Make Reports Work

You've learned how filter context and CALCULATE actually work. This is where it pays off. Part 3 of the DAX Fundamentals series covers the patterns you'll keep reaching for in real models, and why they behave the way they do.

We get into time intelligence (YTD, QTD, prior cycle, and why these functions return tables of dates rather than numbers), variables for cleaner and faster formulas, and SWITCH as the cure for nested IF chains nobody wants to maintain. Then inactive relationships and USERELATIONSHIP for when one fact table has two date columns fighting over the same date table.

The pattern that saves the most pain is calculation groups. Write three base measures, add one calc group with YTD, Prior Cycle, and YoY%, and you've replaced nine measures (and growing) with something you maintain in one place.

The video closes on the part most people skip: how the engine splits work between the Storage Engine and the Formula Engine, and why pushing work toward simple aggregations on a star schema is the difference between fast DAX and slow DAX.