The Power BI data model connects tables through relationships, and the structure of these relationships directly affects DAX behavior. Relationships can have cardinality of one-to-many, many-to-one, one-to-one, or many-to-many. The most common is many-to-one, where a fact table holds foreign keys that match unique keys in dimension tables. Filter propagation defines how filters flow across the model: in a one-to-many relationship, filters propagate from the 'one' side to the 'many' side by default. Active relationships propagate filters automatically, while inactive relationships do not unless activated on demand inside CALCULATE using USERELATIONSHIP. CROSSFILTER can temporarily alter the filter direction without changing the model definition.
A star schema is the recommended modeling pattern in Power BI. It features a central fact table containing measurable business events surrounded by independent dimension tables, each connected via a single-hop relationship. This structure improves query performance, simplifies DAX, and ensures predictable filter behavior compared to a snowflake schema, where dimensions are normalized into multiple related tables. A snowflake schema complicates DAX because filters must traverse multiple hops, and it is generally avoided unless the source data cannot be restructured. Fact tables store numeric measures and foreign keys, while dimension tables contain descriptive attributes used for filtering, grouping, and labeling.
Advanced modeling features include role-playing dimensions, where a single date table relates to a fact table multiple times through separate relationships for order date, ship date, or delivery date. Each role requires its own relationship, with only one active at a time. Slowly changing dimensions track historical changes to dimension attributes: Type 1 overwrites old values, Type 2 keeps history with effective dates, and Type 3 stores the previous value. Bridge tables resolve many-to-many relationships between dimensions and fact tables, while factless fact tables record events without numeric measures. Bidirectional filtering allows filters to flow in both directions between tables, useful for crossing many-to-many relationships or bridge tables, but should be applied cautiously because it can introduce ambiguity in larger models.