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.
