1.4.2. How Filters Flow Through Relationships
💡 First Principle: A relationship is a one-way valve for filters. When rows on the one side are filtered, the matching rows on the many side are filtered too, because each fact row points to exactly one dimension row. The reverse isn't automatic: filtering fact rows doesn't tell Power BI which dimension rows to hide unless you open the valve in both directions.
In a standard one-to-many relationship from Product (one) to Sales (many), selecting Kitchen in a Product slicer keeps only Kitchen rows in Product, and the relationship keeps only Sales rows whose ProductKey matches those Kitchen products. A measure over Sales now aggregates only Kitchen sales. This is filter propagation, and in a star schema it flows from every dimension inward to the fact table, which is why one fact can be sliced by every dimension at once.
Two consequences matter for the exam. First, dimensions don't filter each other through a fact table by default. A slicer on Customer won't reduce the list of items in a Product slicer, because that would require filtering from Sales back up to Product, against the arrow. When a scenario requires "show only products this customer bought," options include a measure-based visual-level filter on the slicer (e.g., [Total Sales] is not blank), or bidirectional cross-filtering on that relationship with care.
Second, blank rows appear when the fact contains keys with no match in the dimension. Power BI adds a virtual blank row to the dimension so those fact rows still have somewhere to go; you see it as "(Blank)" in slicers and visuals. The fix is upstream: correct missing or mismatched keys in Power Query, or add an "Unknown" member to the dimension.
Cross-filter direction, cardinality options, inactive relationships, and their performance trade-offs are covered in depth in 3.1.2 and 3.1.3. For now, carry the valve: one side filters many side, by default, one way.
⚠️ Exam Trap: "(Blank)" appearing in a slicer or visual after a refresh is a referential integrity symptom, not a formatting problem. Fact rows reference keys that don't exist in the dimension. Fix the keys or add an Unknown member; hiding the blank with a visual filter hides real sales from totals.
Reflection Question: Sales has a relationship to both Customer and Product, each single-direction. A user selects one customer and expects the Product slicer to shrink to only products that customer bought, but it doesn't. Trace why, and name one approach that satisfies the requirement without enabling bidirectional filtering.
