Imagine que sua tabela de pedidos tem três colunas de data: Data do Pedido, Data de Entrega e Data de Cancelamento. Você quer analisar o faturamento por data de pedido em um visual e por data de entrega em outro — com a mesma tabela calendário filtrando os dois.

O problema: o Power BI só permite um relacionamento ativo por vez entre duas tabelas. O restante fica inativo. E um relacionamento inativo não filtra nada — a não ser que você chame USERELATIONSHIP explicitamente na medida DAX.

Neste artigo você vai entender por que essa limitação existe, como criar os relacionamentos inativos corretamente no modelo e como usar USERELATIONSHIP dentro de CALCULATE para ativar o relacionamento que precisar — medida a medida.

Pré-requisito

Este artigo assume que você já tem uma tabela calendário configurada e marcada como tabela de datas no Power BI. Se ainda não tem, leia primeiro o artigo Tabela Calendário no Power Query.

Por que o Power BI limita a um relacionamento ativo

O motor DAX usa os relacionamentos do modelo para propagar filtros entre tabelas. Quando você tem dCalendario[Data] ligada a fPedidos[DataPedido], qualquer filtro aplicado no calendário (via segmentação, eixo de gráfico ou medida) se propaga automaticamente para a tabela de fatos pelo lado ativo.

Se o DAX permitisse dois relacionamentos ativos entre o mesmo par de tabelas, ele não saberia qual caminho usar para propagar o filtro — o resultado seria ambíguo e imprevisível. Por isso a regra: apenas um relacionamento ativo por par de tabelas.

Os outros relacionamentos entre o mesmo par ficam inativos — representados por linha tracejada no diagrama de modelo. Eles existem no modelo, mas não propagam filtros automaticamente. USERELATIONSHIP é a função que ativa um desses relacionamentos inativos temporariamente, apenas dentro do contexto de uma medida.

Atenção

USERELATIONSHIP só funciona dentro de CALCULATE. Usá-la fora de CALCULATE gera erro de sintaxe. Ela não é uma função que retorna valor — é um modificador de contexto de filtro.

1 Configure os relacionamentos inativos no modelo

Antes de escrever qualquer DAX, você precisa criar todos os relacionamentos entre dCalendario[Data] e cada coluna de data da sua tabela de fatos.

No Power BI Desktop, vá para a Exibição de Modelo e arraste as colunas para criar os relacionamentos:

  1. Arraste dCalendario[Data] até fPedidos[DataPedido] → esse será o relacionamento ativo (linha sólida).
  2. Arraste dCalendario[Data] até fPedidos[DataEntrega] → o Power BI vai criar automaticamente como inativo (linha tracejada), pois já existe um ativo entre as mesmas tabelas.
  3. Arraste dCalendario[Data] até fPedidos[DataCancelamento] → também inativo.

Confirme que todos os três são de um para muitos — dCalendario[Data] no lado "1" e as colunas de data de fatos no lado "N". Direção de filtro cruzado: "Única" (do calendário para os fatos).

Como identificar um relacionamento inativo

Na Exibição de Modelo, o relacionamento ativo aparece como uma linha sólida e contínua. Os inativos aparecem como linhas tracejadas. Ao passar o mouse sobre a linha você vê o tooltip com "Ativo: Não" para os inativos.

2 Escreva as medidas com USERELATIONSHIP

Com os três relacionamentos criados no modelo, você usa USERELATIONSHIP para ativar o que quiser dentro de cada medida. A sintaxe é:

CALCULATE(
    [expressão],
    USERELATIONSHIP(Tabela1[Coluna], Tabela2[Coluna])
)

Os dois argumentos de USERELATIONSHIP são as colunas que formam o relacionamento que você quer ativar — na mesma ordem em que foram criadas (tanto faz a ordem, o DAX identifica o par).

Exemplo real: faturamento por data de pedido vs. data de entrega

Começamos com a medida base (usa o relacionamento ativo — DataPedido):

Faturamento = SUM(fPedidos[Valor])

Para analisar o mesmo faturamento pela data de entrega:

Faturamento por Entrega =
CALCULATE(
    SUM(fPedidos[Valor]),
    USERELATIONSHIP(dCalendario[Data], fPedidos[DataEntrega])
)

E pela data de cancelamento:

Faturamento Cancelado por Data =
CALCULATE(
    SUM(fPedidos[Valor]),
    USERELATIONSHIP(dCalendario[Data], fPedidos[DataCancelamento])
)

Com essas três medidas, você pode colocar a mesma segmentação de data no relatório e cada visual vai filtrar pela data correta — sem criar três tabelas calendário diferentes.

3 Use com funções de Time Intelligence

USERELATIONSHIP funciona junto com todas as funções de inteligência de tempo — TOTALYTD, SAMEPERIODLASTYEAR, DATEADD e afins. Mas a ordem dos modificadores dentro de CALCULATE importa.

O padrão correto é colocar USERELATIONSHIP como argumento adicional dentro da própria função de time intelligence ou no CALCULATE externo, dependendo da função:

-- Acumulado no ano pela data de entrega
YTD por Entrega =
CALCULATE(
    SUM(fPedidos[Valor]),
    DATESYTD(dCalendario[Data]),
    USERELATIONSHIP(dCalendario[Data], fPedidos[DataEntrega])
)
-- Mesmo período do ano anterior, filtrado por data de entrega
LY por Entrega =
CALCULATE(
    SUM(fPedidos[Valor]),
    SAMEPERIODLASTYEAR(dCalendario[Data]),
    USERELATIONSHIP(dCalendario[Data], fPedidos[DataEntrega])
)
Atenção com TOTALYTD

TOTALYTD tem um terceiro argumento opcional para a data de fim do ano fiscal — mas não aceita USERELATIONSHIP diretamente como argumento. Nesse caso, envolva em CALCULATE externo: CALCULATE(TOTALYTD(...), USERELATIONSHIP(...)).

Quer conectar APIs de ERP e CRM direto no Power BI?

Na formação Chora API Revolution você aprende a puxar dados de qualquer sistema via API — sem exportar arquivo, sem planilha intermediária.

Ver a Formação →

Erros comuns ao usar USERELATIONSHIP

Erro 1

Relacionamento não existe no modelo
A medida retorna erro: "A coluna especificada não existe ou não há nenhum relacionamento ativo ou inativo..."

Correção: USERELATIONSHIP só funciona se o relacionamento já existir no modelo — mesmo que inativo. Vá para a Exibição de Modelo e confirme que o relacionamento entre as duas colunas está criado antes de referenciar no DAX.

Erro 2

Usar USERELATIONSHIP fora de CALCULATE
O Power BI retorna erro de sintaxe ao usar a função diretamente em uma expressão.

Correção: USERELATIONSHIP não é uma função de valor — é um modificador de filtro. Ela só pode aparecer dentro de CALCULATE ou CALCULATETABLE, como um dos argumentos de filtro.

Erro 3

Tentar ativar o relacionamento que já está ativo
Se você usar USERELATIONSHIP apontando para o relacionamento que já é o ativo no modelo, a medida vai funcionar — mas é redundante e pode gerar confusão.

Correção: USERELATIONSHIP é necessário somente para relacionamentos inativos. Para o relacionamento padrão (ativo), basta usar a medida diretamente sem o modificador.

Erro 4

Filtro da segmentação não funciona com a medida USERELATIONSHIP
A medida retorna o total geral e ignora a segmentação de datas.

Correção: Confirme que a segmentação está usando a coluna dCalendario[Data] — a mesma coluna referenciada em USERELATIONSHIP. Se a segmentação usar fPedidos[DataEntrega] diretamente, o relacionamento inativo não vai propagar o filtro.

Erro 5

Ambiguidade de caminho de relacionamento
O modelo tem caminhos múltiplos entre tabelas e o DAX retorna erro de relacionamento ambíguo.

Correção: Revise o diagrama do modelo. Quando USERELATIONSHIP ativa um relacionamento inativo, ele pode criar um segundo caminho ativo no grafo — se isso causar ambiguidade, use CROSSFILTER para desativar o relacionamento ativo enquanto o inativo está em uso.

Bônus

Combine USERELATIONSHIP com CROSSFILTER

Em modelos mais complexos, ativar um relacionamento inativo pode criar um caminho duplicado no grafo — e o DAX reclamar de ambiguidade. Nesses casos, combine USERELATIONSHIP com CROSSFILTER para desativar explicitamente o relacionamento que você não quer usar:

Faturamento por Entrega (sem ambiguidade) =
CALCULATE(
    SUM(fPedidos[Valor]),
    CROSSFILTER(dCalendario[Data], fPedidos[DataPedido], None),
    USERELATIONSHIP(dCalendario[Data], fPedidos[DataEntrega])
)

CROSSFILTER(..., None) desativa o relacionamento ativo original. Depois, USERELATIONSHIP ativa o inativo desejado. O resultado: apenas um caminho ativo no contexto da medida — sem ambiguidade.

Use esse padrão quando o modelo tiver tabelas de dimensão compartilhadas entre múltiplos fatos ou quando o Power BI acusar erro de caminho ambíguo mesmo com o modelo aparentemente limpo.

Resumindo o que você tem agora

Com o padrão de relacionamentos inativos + USERELATIONSHIP você consegue:

  • Analisar múltiplas colunas de data da mesma tabela de fatos com uma única tabela calendário
  • Manter o modelo limpo — sem duplicar dCalendario para cada data
  • Usar todas as funções de time intelligence em qualquer coluna de data
  • Controlar exatamente qual relacionamento está ativo em cada medida

O fluxo é sempre o mesmo: crie o relacionamento no modelo (ativo ou inativo), depois use USERELATIONSHIP dentro de CALCULATE para ativar o que precisar — medida a medida, sem mexer no modelo.

Quer dominar DAX e APIs no mesmo lugar?

Na formação Chora API Revolution você conecta ERPs, bancos e plataformas direto no Power BI via API — com DAX avançado, n8n e Supabase inclusos.

Ver a Formação →