Star schema, relationships, and model design.
9 tutorials in this category
Power BI Desktop's Performance Analyzer tells you exactly which visual is slow and why. Learn to record, export, and read its data — plus how to turn those numbers into a fix using DAX Studio.
A star schema is the single most important design decision in your Power BI model. It determines query speed, DAX simplicity, and whether your report scales from 10,000 rows to 10 million. This guide covers the design principles, the star vs snowflake decision, and the five mistakes that kill model performance.
Import Mode caches data in memory for fast queries, while DirectQuery sends every visual request back to the source database. Learn when to use each, how Dual mode works, and the performance trade-offs that determine your report architecture.
Row-Level Security (RLS) filters data at the row level based on the user viewing the report. This guide covers static RLS, dynamic RLS with USERNAME(), deployment to the Power BI Service, and the design patterns for multi-tenant security models.
Slow Power BI reports frustrate users and kill adoption. Learn the systematic approach to diagnosing and fixing performance issues — from Performance Analyzer to DAX optimization to model tuning — with copy-paste patterns that actually speed things up.
Calculated tables let you build tables with DAX instead of loading them from a source. What-if parameters turn static assumptions into interactive slicers. This guide covers both features, the syntax, and five practical patterns — from date tables to scenario analysis.
Bidirectional filtering is powerful and dangerous. It solves certain modeling problems elegantly — and creates performance disasters and ambiguous filter paths when overused. This guide covers what bidirectional filtering does, the three scenarios where it's the right tool, and the warning signs that you're using it wrong.
A well-designed star schema makes DAX easier and reports faster. Learn fact vs. dimension tables, relationship cardinality, and why bidirectional filters are usually a mistake.
Relationship cardinality determines how filters flow through your data model. One-to-many is the default and the safest choice. Many-to-many is sometimes necessary but introduces ambiguity and performance costs. This guide covers both, when each is appropriate, and the patterns that make many-to-many manageable.