USERELATIONSHIP em DAX: o que faz e quando usar (com exemplos)

O problema começa quando a mesma dimensão precisa responder a duas perguntas diferentes#

Você tem uma tabela de vendas com três datas: data do pedido, data de faturamento e data de entrega. Uma única tabela Calendário. E o negócio quer ver receita por data de pedido em um visual, mas prazo médio de entrega por data de entrega em outro. O modelo permite apenas um relacionamento ativo entre a fato e a dimensão Calendário. É exatamente aqui que a função USERELATIONSHIP DAX resolve o problema sem forçar você a duplicar a tabela de datas nem inflar o modelo com colunas redundantes.

Este é um cenário comum em quase todo projeto de BI que passa pela nossa mesa. O Power BI foi desenhado para isso, mas muita gente resolve errado: cria duas ou três tabelas Calendário ou espalha lógica de data por dezenas de medidas. Neste artigo eu explico o que a USERELATIONSHIP faz de verdade, mostro a sintaxe, dou exemplos, aponto as armadilhas que mais causam suporte e fecho com boas práticas de quem já viu isso quebrar em produção.

O que é um relacionamento inativo e por que ele existe#

No modelo de dados do Power BI, duas tabelas podem ter mais de um caminho de relacionamento entre elas. Voltando ao exemplo: a fato Vendas tem DataPedido, DataFaturamento e DataEntrega, e todas as três apontam para a coluna Data da tabela Calendário. O motor não permite dois relacionamentos ativos simultâneos entre o mesmo par de tabelas, porque isso criaria ambiguidade: ao filtrar por um ano, o Power BI não saberia qual das três datas usar para propagar o filtro.

A solução do produto é deixar um relacionamento ativo (a linha sólida no diagrama) e os demais inativos (a linha pontilhada). O relacionamento inativo existe no modelo, está pronto para uso, mas não propaga filtro automaticamente. Ele só entra em ação quando você o ativa explicitamente dentro de uma medida. E o mecanismo para isso é a USERELATIONSHIP.

Vale entender o pano de fundo técnico. O motor de armazenamento do Power BI, o VertiPaq, comprime cada coluna em memória por cardinalidade, o que torna barato manter uma única dimensão de datas servindo a três papéis. Duplicar a tabela Calendário três vezes polui o modelo, desperdiça memória e cria três fontes de verdade para a mesma coisa.

USERELATIONSHIP DAX: a sintaxe e o que ela realmente faz#

A função tem assinatura simples:

USERELATIONSHIP(<coluna1>, <coluna2>)

Os dois argumentos são as colunas que definem o relacionamento inativo que você quer ativar. A ordem não importa: você pode escrever USERELATIONSHIP(Vendas[DataEntrega], Calendario[Data]) ou inverter. O que importa é que esse par de colunas corresponda a um relacionamento que já existe no modelo, mesmo que inativo.

Um ponto que confunde muita gente: USERELATIONSHIP não é uma função que você usa sozinha. Ela é um modificador de CALCULATE (ou CALCULATETABLE). Não faz sentido chamá-la fora desse contexto, porque o que ela faz é alterar como os filtros se propagam durante a avaliação de um CALCULATE. Ela não retorna valor, não retorna tabela. Ela reconfigura o comportamento de propagação de filtro para aquela avaliação específica.

Na prática, USERELATIONSHIP faz duas coisas ao mesmo tempo dentro do CALCULATE:

• Ativa o relacionamento inativo indicado.
• Desativa o relacionamento ativo entre as mesmas duas tabelas, para aquela avaliação.

Ou seja, você está trocando qual caminho de filtro fica de pé durante o cálculo. Fora daquela medida, o modelo continua exatamente como estava.

Exemplo conceitual: receita por data de entrega em vez de data de pedido#

Suponha que o relacionamento ativo seja Vendas[DataPedido] para Calendario[Data]. A medida base de receita é:

Receita = SUMX(Vendas, Vendas[Quantidade] * Vendas[PrecoUnitario])

Quando você coloca essa medida em uma matriz por ano, ela responde pela data do pedido, porque é o relacionamento ativo. Para ter a mesma receita, mas reconhecida pela data de entrega, você escreve:

Receita por Entrega = CALCULATE([Receita], USERELATIONSHIP(Vendas[DataEntrega], Calendario[Data]))

Agora, no mesmo relatório, você tem duas medidas convivendo: uma respondendo pela data de pedido, outra pela data de entrega, ambas usando a mesma tabela Calendário e o mesmo eixo de tempo. Nenhuma tabela duplicada, nenhuma coluna extra.

O mesmo raciocínio vale para prazos, combinando a data de entrega ativada temporariamente com cálculos de diferença de datas.

Quando usar e quando não usar#

Nem todo cenário de múltiplas datas ou múltiplas chaves pede USERELATIONSHIP. A tabela abaixo resume como decidimos em projeto.

Situação	Abordagem recomendada
Vários papéis de data (pedido, faturamento, entrega) e poucos visuais que trocam a data	USERELATIONSHIP em medidas específicas
Usuário precisa fatiar o relatório inteiro por uma data alternativa, com muita interação	Avaliar tabela Calendário adicional (role-playing dimension)
Duas chaves entre fato e dimensão (ex.: cliente comprador e cliente pagador)	USERELATIONSHIP por medida ou dimensão dedicada, conforme o uso
Relacionamento com granularidade ou direção diferente por cálculo	USERELATIONSHIP dentro de CALCULATE
Modelo com muitas medidas repetindo a mesma troca de data	Considerar dimensão dedicada para reduzir repetição

A regra prática que aplicamos: se a troca de data é pontual e vive em poucas medidas, USERELATIONSHIP é mais limpo. Se o usuário final precisa escolher a data em segmentadores e filtrar o relatório todo por ela, uma tabela Calendário adicional costuma dar melhor experiência, porque o filtro passa a ser interativo e não fica preso na definição da medida. Esse tipo de decisão separa um relatório que escala de um que vira dívida técnica, tema central de modelagem e boas práticas em DAX.

As armadilhas que mais geram suporte#

Depois de muitos projetos, algumas dores se repetem. Vale conhecê-las antes de escrever a primeira medida.

USERELATIONSHIP não sobrevive a medidas que ignoram o relacionamento#

Se sua medida base usa ALL sobre a tabela Calendário ou remove o filtro de contexto de forma agressiva, ativar o relacionamento inativo pode não produzir o efeito esperado, porque não há filtro para propagar pelo novo caminho. USERELATIONSHIP muda o caminho da propagação, mas se não existe filtro fluindo, não há o que propagar. O sintoma clássico é a medida retornar o total geral em todas as linhas.

Só funciona com relacionamentos regulares e válidos#

O par de colunas passado precisa corresponder a um relacionamento existente no modelo. Se você digitar colunas que não têm relacionamento definido, o DAX retorna erro. USERELATIONSHIP não cria relacionamento na hora: ela ativa um que já está lá, inativo.

Relacionamentos bidirecionais e ambiguidade#

Em modelos com filtros cruzados bidirecionais, ativar um relacionamento inativo pode introduzir caminhos ambíguos de propagação e gerar erro na avaliação. Modelos com muitos relacionamentos bidirecionais já são frágeis, e a troca de caminho por medida aumenta a chance de comportamento imprevisível. Prefira relacionamentos de direção única sempre que possível.

Efeito confinado ao CALCULATE#

O relacionamento só fica ativo dentro daquele CALCULATE. Se você tem uma medida que chama outra medida, e espera que a ativação valha para toda a cadeia, precisa garantir que o USERELATIONSHIP envolve o cálculo certo. Um erro comum é ativar o relacionamento em uma camada externa e esperar que uma medida aninhada, avaliada em outro contexto, respeite a troca. Nem sempre respeita, dependendo de como o contexto é reconstruído.

Desempenho em tabelas muito grandes#

Trocar o caminho de relacionamento não é gratuito em fatos com centenas de milhões de linhas. Na maioria dos casos o custo é irrelevante, mas em modelos pesados vale testar. Se você percebe lentidão, o problema raramente é a USERELATIONSHIP em si, e sim a combinação dela com medidas mal escritas ou colunas de alta cardinalidade. Diagnóstico de performance de modelo é parte do que fazemos em sustentação de BI.

USERELATIONSHIP versus CROSSFILTER: não confunda as duas#

As duas funções são modificadores de CALCULATE ligados a relacionamentos, mas fazem coisas diferentes. A tabela abaixo separa os papéis.

Aspecto	USERELATIONSHIP	CROSSFILTER
O que faz	Ativa um relacionamento inativo (troca o caminho de filtro)	Muda a direção do filtro de um relacionamento
Uso típico	Papéis de data, múltiplas chaves	Forçar filtro cruzado bidirecional ou desligar propagação
Cria relacionamento?	Não, ativa um já existente	Não, altera comportamento de um existente
Escopo	Dentro do CALCULATE	Dentro do CALCULATE
Combina com a outra?	Sim, podem coexistir no mesmo CALCULATE	Sim

O erro que vejo é usar CROSSFILTER tentando resolver um problema de papel de data, ou usar USERELATIONSHIP para forçar direção de filtro. Cada uma tem seu lugar. Papel de data e múltiplas chaves são território da USERELATIONSHIP. Direção de propagação é território da CROSSFILTER.

Múltiplas chaves, não só datas#

Embora datas sejam o caso mais comum, USERELATIONSHIP serve para qualquer relacionamento inativo. Um exemplo frequente no varejo e em serviços financeiros: a fato tem ClienteComprador e ClientePagador, ambos apontando para a dimensão Cliente. O relacionamento ativo é o comprador. Para uma análise de receita pela ótica de quem paga, você ativa o relacionamento do pagador dentro da medida.

Outro caso: hierarquias organizacionais, onde a mesma dimensão de funcionário serve como colaborador e como gestor. Ou logística, com origem e destino apontando para a mesma localidade. A lógica é idêntica à das datas: um caminho ativo, outros inativos, ativados sob demanda. Estruturar isso desde o início é parte de um bom trabalho de modelagem e engenharia de dados.

Boas práticas que aplicamos em projeto#

Sintetizando o que funciona quando o modelo precisa durar:

• Nomeie as medidas pelo papel, não pela função. Receita por Entrega comunica melhor que Receita USEREL. Quem abre o relatório daqui a um ano agradece.
• Mantenha uma única dimensão Calendário sempre que possível. Uma tabela de datas bem construída, marcada como tabela de datas no modelo, serve a todos os papéis via relacionamentos inativos. Menos tabelas, menos confusão.
• Documente qual relacionamento é o ativo. A escolha de qual data é a ativa é uma decisão de negócio. Deixe claro no modelo e na documentação. Isso é governança básica e conversa direto com práticas de governança de dados.
• Evite empilhar bidirecionais com troca de relacionamento. Se o modelo já tem filtros cruzados bidirecionais, pense duas vezes antes de somar USERELATIONSHIP. A combinação é fonte recorrente de bugs de ambiguidade.
• Teste com o total e com o detalhe. Sempre valide a medida em um cartão de total e em uma matriz detalhada. Muitos erros de USERELATIONSHIP só aparecem quando você compara os dois.
• Prefira medidas a colunas calculadas. Ativar relacionamento é comportamento de tempo de consulta. Fazer isso em coluna calculada raramente é o que você quer, porque a coluna é materializada uma única vez, no contexto de linha.

Essas escolhas parecem pequenas isoladamente, mas somadas são o que diferencia um projeto de Power BI sustentável de um que trava a cada nova demanda.

Contexto de mercado: por que isso importa no Brasil#

O Power BI tem adoção ampla no mercado brasileiro, puxada pela penetração do ecossistema Microsoft nas empresas. A Microsoft é reconhecida como Líder no Quadrante Mágico do Gartner para plataformas de Analytics e BI, e a maturidade da ferramenta se reflete em recursos como relacionamentos inativos, estáveis há anos. Com o Microsoft Fabric, anunciado em 2023, e o modo Direct Lake lendo do OneLake, a base de modelagem em DAX segue a mesma: entender contexto de filtro e relacionamentos é o que separa quem entrega valor de quem só monta gráficos.

Ou seja, dominar USERELATIONSHIP não é um detalhe de nicho. É parte do repertório mínimo de quem trabalha modelagem semântica a sério, seja em um modelo importado clássico, seja em um modelo sobre o Fabric. Se você quer entender o cenário completo da plataforma, vale ler nosso guia de Power BI para empresas no Brasil.

Perguntas frequentes#

USERELATIONSHIP funciona sem CALCULATE?

Não. Ela é um modificador de CALCULATE e CALCULATETABLE. Fora desse contexto, não faz sentido e não é avaliada. Sempre que você usar USERELATIONSHIP, ela estará dentro de um CALCULATE, alterando a propagação de filtro daquela avaliação específica.

Posso ativar mais de um relacionamento inativo na mesma medida?

Sim. Você pode passar vários USERELATIONSHIP como modificadores no mesmo CALCULATE, desde que cada um se refira a um relacionamento inativo válido e que a combinação não gere ambiguidade de caminho no modelo. Em modelos complexos, teste com cuidado.

Qual a diferença entre criar outra tabela Calendário e usar USERELATIONSHIP?

Uma tabela Calendário adicional (role-playing dimension) dá ao usuário um segmentador interativo para filtrar o relatório inteiro por aquela data. USERELATIONSHIP mantém a troca dentro da medida, sem segmentador próprio. Use a tabela extra quando a interatividade importa, e a função quando a troca é pontual e vive em poucas medidas.

USERELATIONSHIP piora a performance?

Na maioria dos modelos, o custo é irrelevante. Em fatos muito grandes ou combinada com medidas mal escritas, pode pesar. O gargalo quase nunca é a função em si, e sim colunas de alta cardinalidade ou lógica ineficiente ao redor. Vale medir antes de concluir.

Funciona no Microsoft Fabric e em modelos Direct Lake?

Sim. A semântica de DAX e de relacionamentos é a mesma no modelo semântico do Fabric. USERELATIONSHIP continua ativando relacionamentos inativos normalmente, independentemente de o armazenamento ser importado, DirectQuery ou Direct Lake lendo do OneLake.

Serve só para datas?

Não. Serve para qualquer relacionamento inativo: múltiplas chaves de cliente, origem e destino em logística, colaborador e gestor em hierarquias. A lógica é sempre a mesma: um caminho ativo, outros inativos, ativados sob demanda dentro de uma medida.

Fechando#

USERELATIONSHIP é uma daquelas funções que parecem pequenas, mas resolvem um problema estrutural de modelagem com elegância: fazer uma única dimensão responder a vários papéis sem duplicar tabelas nem sujar o modelo. Domine a sintaxe, respeite o escopo do CALCULATE, fuja das armadilhas de bidirecional e ambiguidade, e você terá modelos mais enxutos e mais fáceis de manter. Se o seu modelo já cresceu além do que consegue governar, ou se você quer construir uma base semântica bem feita desde o início, fale com a gente.