Cardinalidade
| Tipo | Quando ocorre | Recomendação |
|---|---|---|
| Um para muitos (1:N) | Dimensão → Fato | O padrão. 95% dos seus relacionamentos. |
| Um para um (1:1) | Duas tabelas com a mesma chave | Quase sempre deveriam ser uma tabela só. |
| Muitos para muitos (N:N) | Nenhum lado tem chave única | Evite. Crie uma dimensão-ponte com valores únicos. |
Direção do filtro
Por padrão o filtro flui do lado 'um' para o lado 'muitos': ao selecionar uma categoria em dProduto, a fVendas é filtrada. O caminho inverso não acontece — e isso é uma proteção, não uma limitação.
DAXBidirecional apenas onde é necessário
Clientes com Compra =CALCULATE( DISTINCTCOUNT( dCliente[IdCliente] ), CROSSFILTER( fVendas[IdCliente], dCliente[IdCliente], BOTH ))Relacionamentos inativos e USERELATIONSHIP
Uma fato de pedidos tem várias datas: pedido, faturamento, entrega. Só uma pode estar ativa contra o calendário. As outras ficam pontilhadas (inativas) e você as ativa dentro de medidas específicas.
DAXTrês visões da mesma fato, uma tabela calendário
Pedidos Realizados = -- usa o relacionamento ativo (DataPedido)COUNTROWS( fPedidos ) Pedidos Faturados =CALCULATE( COUNTROWS( fPedidos ), USERELATIONSHIP( fPedidos[DataFaturamento], dCalendario[Data] )) Pedidos Entregues =CALCULATE( COUNTROWS( fPedidos ), USERELATIONSHIP( fPedidos[DataEntrega], dCalendario[Data] ))Chaves compostas
O Power BI não aceita relacionamento por duas colunas. Quando a chave real é Loja + Produto, crie uma coluna concatenada nos dois lados — de preferência no Power Query.
Linguagem MChave composta no Power Query
Table.AddColumn( Etapa_Anterior, "ChaveLojaProduto", each Text.From([IdLoja]) & "|" & Text.From([IdProduto]), type text)