Relationships and Star Schema

A relationship in Power BI links two tables through a common column, allowing a filter or selection applied to one table to automatically propagate to another — clicking a region in a slicer built from a Region dimension table filters the Sales fact table down to that region's rows without any manual join in every visual. Under the hood, Power BI's VertiPaq engine stores relationships as one-to-many or many-to-many cardinality with a defined cross-filter direction, and every visual's query is resolved by walking these relationships rather than executing an explicit SQL join.

A star schema organizes a model into one or more fact tables — tall tables holding numeric, transactional measurements like Sales Amount or Quantity, one row per event — surrounded by dimension tables that hold descriptive attributes like Product Name, Customer City, or Calendar Date, each connected to the fact table by a one-to-many relationship radiating outward like the points of a star. This shape keeps fact tables narrow and fast, avoids storing repeated descriptive text in every transaction row, and matches exactly how DAX filter context and the VertiPaq engine are optimized to work, which is why Microsoft's own modeling guidance treats star schema as the default recommended design.

Each relationship has a cardinality — most commonly one-to-many, where one row in a dimension table matches many rows in a fact table — and a cross-filter direction, which controls whether filtering flows one way (single, the default and recommended setting) or both ways (bidirectional). Bidirectional filtering can be useful for specific scenarios like a many-to-many bridge table, but overusing it across a model risks ambiguous filter paths and circular logic that silently changes measure results, so Microsoft's guidance is to default to single-direction filtering and enable bidirectional only when a specific, understood need exists.