1 Interactive DAX and semantic model concepts
This chapter reframes DAX as an interactive, model-aware language where results are driven as much by evaluation context as by the formula itself. It distinguishes between Interactive DAX, where slicers, visuals, and filters continuously shape calculations on a report canvas, and Standard DAX, where queries run in a fixed environment for learning, validation, and debugging. The central mindset shift is to design calculations that intentionally respond to user behavior, recognizing that both report authors and consumers shape outcomes without necessarily writing any DAX.
The chapter exposes the hidden mechanics of interactivity: Power BI silently gathers all active filters and evaluates measures within that composite context, effectively wrapping expressions in logic that accumulates page, visual, and slicer filters. This filter context flows across relationships, creating per-cell contexts in visuals and making even simple measures dynamic. Authors are encouraged to decide which filters to preserve, override, or selectively allow, using interaction-management techniques to trace, manage, and control filter application so results remain predictable, performant, and aligned with business rules.
Underpinning this behavior is the semantic model—the structure of tables, relationships, and metadata that enables consistent filtering, implicit joins, and reusable logic. Relationships unify tables and drive filter propagation; expanded tables let DAX reference related columns without explicit joins; and data lineage tracks each column’s origin so filters can traverse valid paths. The chapter also covers complex models, disconnected tables (useful for parameters and what-if logic), and the difference between connected and disconnected intermediate recordsets, warning that certain transformations can break lineage and alter filter behavior. Techniques such as TREATAS can restore intentional filter flow, reinforcing the need to understand model design to build reliable, context-aware DAX.
A Power BI report with matrix visual and slicer and filter panes.
Visual flow, from user interaction to execution of DAX in a specific context.
Physical model relationships and various components of a semantic model.
Relationship setup and navigating an expanded table
An illustration of a semantic model in interactive mode showing both connected (fact, dimension) entities and disconnected entities.
Summary
- Every DAX calculation is context-driven—shaped by a combination of user interactions and semantic model relationships.
- The semantic model enables automatic filter propagation across related tables, eliminating the need for explicit joins.
- Expanded tables allow DAX to seamlessly access related dimension data without manual navigation.
- Preserving data lineage is critical to ensuring filters propagate correctly through virtual tables and intermediate logic.
- Disconnected tables are intentional design tools—used for scenarios like what-if analysis—and can be selectively reconnected using functions like TREATAS().
FAQ
What is “Interactive DAX” and how is it different from “Standard DAX”?
Interactive DAX runs inside a Power BI report, where slicers, filters, and visuals continuously reshape the evaluation context. Standard DAX runs as standalone queries in a fixed environment (for example, DAX Studio or Query View) without user-driven filters—useful for learning, debugging, and validating results.
What is evaluation context in DAX?
Evaluation context is the set of conditions that determine what data is visible when an expression runs. It is shaped by three factors:
- DAX functions that add/override/remove filters (for example, CALCULATE, REMOVEFILTERS)
- The semantic model’s structure (relationships, filter propagation, expanded tables, data lineage)
- User interactions (slicers, visuals, cross-filtering, filter pane)
Filter context is the collection of all active filters at evaluation time.
How do user interactions influence my measures?
Both report authors and consumers influence measures via slicers, filters, and visual interactions. Each visual (for example, a matrix row) creates its own filter context. As selections change, Power BI reevaluates measures in the new context—often without any changes to your DAX code.
Why do simple measures change per visual, and what is Power BI doing behind the scenes?
Power BI effectively wraps your measure in CALCULATE and injects all active filters (from slicers, filter panes, and the current visual cell). The engine merges these filters into a single context and reevaluates the expression for every combination—hence different results for different selections or rows.
What is the Power BI semantic model and why is it essential?
The semantic model defines structure, relationships, and business logic so raw data gains analytical meaning. It enables:
- Consistent filtering and relationship-based navigation
- Reusable measures and calculated fields
- Interactive, context-aware calculations
Key components include tables, relationships, measures/calculated fields, and hierarchies/metadata.
How do relationships and filter propagation work in Power BI?
Relationships unify tables so filters applied on one table propagate to related tables in the relationship direction. DAX doesn’t require explicit JOINs—once relationships exist, the engine can traverse them automatically and apply filters across the model in real time.
What are expanded tables, and why do they matter?
Expanded tables are a logical view where a base table is extended with columns from related one-side tables (and upstream via many-to-one chains). Benefits:
- Reference related attributes without explicit joins
- Cleaner, concise DAX that leverages the model
- Accurate, context-aware logic as filters traverse relationships
What is data lineage in DAX?
Data lineage is metadata that tracks a column’s “home address”—its origin and relationship path. With lineage, DAX can resolve filters across indirect relationships, knowing where a column comes from, how it connects to others, and how filters should propagate. This is why expressions referencing indirectly related tables often “just work.”
What can break lineage, and what are the symptoms?
Lineage can be lost when transformations discard source references, for example:
- SELECTCOLUMNS with new names (aliased outputs)
- Virtual tables from ADDCOLUMNS/SUMMARIZE that drop metadata
- Manipulations that decouple columns from their origins
Symptoms include unexpected filter behavior, incorrect totals, or blanks because filters no longer propagate as intended.
When should I use disconnected tables, and how can I reconnect virtual tables?
Disconnected tables are useful for parameters, what-if analysis, or slicers that drive logic without altering the model’s filter context. You can capture input with SELECTEDVALUE or LOOKUPVALUE and simulate filtering with TREATAS. If a virtual table loses lineage, use TREATAS to map its values to model columns and restore filter propagation.
DAX Reimagined ebook for free
