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

Trazer colunas de outra tabela é onde o iniciante trava primeiro#

Toda vez que alguém pergunta por que a coluna de categoria do produto não aparece na tabela de vendas, a resposta cai em duas funções: RELATED e RELATEDTABLE DAX são as ferramentas que atravessam relacionamentos do modelo para buscar dados de uma tabela em outra. Parecem simples, e são, até você tentar usar uma no lugar da outra e receber um erro que não explica nada. É aí que a maioria dos analistas descobre que não entendia direito como o Power BI enxerga os relacionamentos.

Este artigo é direto ao ponto. Vou explicar o que cada função faz, a diferença que importa entre elas, os erros que aparecem toda semana em projeto de cliente e como decidir se você realmente precisa dessas funções ou se está resolvendo no lugar errado. Spoiler: na maioria dos casos, você não deveria estar escrevendo RELATED numa coluna calculada. Mas vamos por partes.

RELATED busca um único valor do lado "um" do relacionamento#

RELATED pega uma coluna de uma tabela relacionada e traz o valor correspondente para a linha atual. A sintaxe é curta:

RELATED(NomeDaTabela[NomeDaColuna])

O ponto que trava todo mundo é a direção. RELATED só funciona quando a tabela onde você está escrevendo a fórmula está no lado "muitos" do relacionamento, e a tabela que você quer consultar está no lado "um". Em um modelo star schema clássico, a tabela fato (Vendas) está no lado muitos e as dimensões (Produto, Cliente, Calendário) estão no lado um. Então, dentro de Vendas, você consegue puxar qualquer coluna de Produto com RELATED, porque para cada linha de venda existe exatamente um produto.

O exemplo mais comum é criar uma coluna calculada na tabela de vendas que traz a categoria do produto:

Categoria = RELATED(Produto[Categoria])

Cada linha de venda tem um ProdutoID, o relacionamento resolve qual produto é, e RELATED devolve a categoria daquele produto. Um valor por linha, sempre. É esse "sempre um valor" que define quando RELATED serve.

RELATED também navega por múltiplos saltos. Se Vendas se relaciona com Produto, e Produto se relaciona com Fornecedor, você consegue chegar em RELATED(Fornecedor[Nome]) de dentro de Vendas, desde que todos os relacionamentos no caminho apontem na direção certa (muitos para um em cada salto). O Power BI segue a cadeia sozinho.

RELATEDTABLE devolve a tabela inteira do lado "muitos"#

RELATEDTABLE faz o caminho contrário. Ela retorna uma tabela com todas as linhas relacionadas, e você usa isso do lado "um" olhando para o lado "muitos". A sintaxe:

RELATEDTABLE(NomeDaTabela)

Repare que RELATEDTABLE não recebe uma coluna, recebe uma tabela. Ela nunca devolve um valor sozinha. Você quase sempre a envolve em uma função de agregação como COUNTROWS, SUMX ou AVERAGEX. O caso clássico é uma coluna calculada na dimensão Produto que conta quantas vezes cada produto foi vendido:

Qtd Vendas = COUNTROWS(RELATEDTABLE(Vendas))

Aqui você está em Produto (lado um) e quer olhar todas as linhas de Vendas (lado muitos) ligadas àquele produto. RELATEDTABLE devolve o subconjunto de vendas daquele produto, e COUNTROWS conta as linhas. Se quiser somar o faturamento por produto direto na dimensão, usa SUMX sobre a tabela relacionada:

Faturamento Produto = SUMX(RELATEDTABLE(Vendas), Vendas[Quantidade] * Vendas[PrecoUnitario])

Por baixo dos panos, RELATEDTABLE é praticamente um atalho para CALCULATETABLE(Vendas) respeitando o contexto de linha atual. Quem já entende contexto de filtro reconhece o comportamento na hora. Se esse conceito ainda parece nebuloso, vale ler nosso material sobre modelagem e boas práticas de DAX no Power BI antes de seguir.

A diferença que importa, lado a lado#

A confusão entre as duas some quando você fixa uma ideia: RELATED vai do muitos para o um e traz um valor; RELATEDTABLE vai do um para o muitos e traz várias linhas. A tabela abaixo resume o que decide qual usar.

Aspecto	RELATED	RELATEDTABLE
O que retorna	Um único valor (escalar)	Uma tabela de linhas
Direção do relacionamento	Do lado "muitos" para o lado "um"	Do lado "um" para o lado "muitos"
Onde você escreve	Na tabela fato (ex.: Vendas)	Na tabela dimensão (ex.: Produto)
Precisa de agregação em volta	Não	Sim, quase sempre (COUNTROWS, SUMX...)
Recebe como argumento	Uma coluna	Uma tabela
Uso típico	Trazer categoria, região, nome	Contar ou somar linhas filhas

Uma regra mental que funciona: se a pergunta é "qual o valor daquilo lá?", é RELATED. Se a pergunta é "quantos" ou "qual a soma daqueles?", é RELATEDTABLE. Errar a direção é o erro número um, e o Power BI não é gentil na mensagem quando isso acontece.

Quando usar cada uma na prática, e quando não usar#

Vou ser honesto sobre uma coisa que muita gente aprende tarde: você raramente precisa de RELATED em uma coluna calculada num modelo bem feito. Se o seu modelo é um star schema limpo, as dimensões já têm as colunas descritivas e você filtra os visuais por elas diretamente. Criar Categoria = RELATED(Produto[Categoria]) dentro de Vendas duplica a informação, aumenta o tamanho do modelo e não traz benefício nenhum na maioria dos relatórios.

RELATED em coluna calculada só se justifica em casos específicos:

• Você precisa da coluna para uma segmentação ou lógica que exige o valor materializado na tabela fato.
• Você vai usar aquela coluna dentro de uma expressão de linha que combina campos de tabelas diferentes (por exemplo, comparar o preço da venda com o preço de tabela do produto na mesma linha).
• Você está aplainando o modelo de propósito por uma razão de performance bem medida.

RELATEDTABLE em coluna calculada tem uma armadilha parecida. Contar vendas por produto e gravar isso como coluna na dimensão congela o número. Ele não responde a filtros de data, região ou nada. No dia seguinte, alguém coloca um segmentador de ano no relatório, a coluna continua mostrando o total histórico, e o número "não bate". Na esmagadora maioria dos casos, o certo é uma medida, não uma coluna:

Qtd Vendas = COUNTROWS(Vendas)

Essa medida respeita o contexto de filtro do visual e do relacionamento automaticamente, sem RELATEDTABLE nenhum. O relacionamento já propaga o filtro de Produto para Vendas. É por isso que digo que essas funções são menos necessárias do que parecem: numa medida bem escrita, a propagação de filtro do relacionamento faz o trabalho sozinha.

A tabela abaixo ajuda a decidir entre coluna calculada e medida nesses cenários.

Situação	Coluna calculada	Medida
Trazer atributo descritivo para a fato	RELATED, se realmente precisar	Não se aplica
Contar linhas filhas por item	Evite (número congela)	COUNTROWS(Fato), sem RELATEDTABLE
Somar valor filho respeitando filtros	Evite	SUMX ou SUM na medida
Segmentar por atributo de dimensão	Use a coluna da própria dimensão	Não se aplica
Cálculo linha a linha entre tabelas	RELATED faz sentido	Depende do caso

Se você quer entender por que "medida ou coluna" muda tudo em performance e tamanho de modelo, esse é um dos assuntos que mais aparece em projeto e vale aprofundar com um time que faz isso todo dia. É parte do trabalho de modelagem e DAX que a gente entrega.

Contexto de linha é o que faz as duas funcionarem#

Nenhuma das duas funções funciona sem contexto de linha. RELATED e RELATEDTABLE precisam saber "em qual linha estou agora" para resolver o relacionamento. É por isso que elas funcionam naturalmente em colunas calculadas (que têm contexto de linha por definição) e dentro de iteradores como SUMX, FILTER e AVERAGEX.

Se você tentar usar RELATED direto no corpo de uma medida, sem um iterador em volta, vai tomar erro, porque medida não tem contexto de linha por padrão. Esse detalhe conecta com o assunto mais importante do DAX. Se contexto de linha e contexto de filtro ainda são confusos para você, pare aqui e resolva isso primeiro, porque metade dos erros com RELATED vem daí. Nosso guia completo de Power BI para empresas toca nesses fundamentos de modelagem.

Um exemplo de RELATED dentro de iterador numa medida, que é válido:

Margem = SUMX(Vendas, (Vendas[Preco] - RELATED(Produto[Custo])) * Vendas[Quantidade])

Aqui o SUMX cria contexto de linha percorrendo Vendas, e dentro dele o RELATED consegue buscar o custo do produto daquela linha. Funciona porque o iterador forneceu o contexto que RELATED exige.

Erros comuns que aparecem toda semana#

Alguns tropeços se repetem tanto que dá para listar de olhos fechados. Vale conhecer antes de bater neles.

• Usar RELATED na direção errada. Escrever RELATED numa dimensão tentando puxar da fato não funciona. Nesse sentido você precisa de RELATEDTABLE. O erro típico é "a coluna não existe ou não tem relacionamento".
• Esperar um valor único de RELATEDTABLE. Ela devolve tabela. Sem COUNTROWS, SUMX ou algo que agregue, não vira número. Colocar RELATEDTABLE sozinha numa coluna dá erro de tipo.
• Relacionamento inativo. Se existe mais de um relacionamento entre as tabelas, só um fica ativo. RELATED segue apenas o ativo. Para usar outro caminho, você precisa de USERELATIONSHIP dentro de CALCULATE, e isso é outro tema.
• Relacionamento com cardinalidade errada. Um relacionamento muitos para muitos ou uma direção de filtro cruzada mal configurada faz RELATED se comportar de forma inesperada ou retornar erro. Cheque o modelo antes de culpar a fórmula.
• Congelar número em coluna calculada. Já falei, mas repito porque dói: contar filhos com RELATEDTABLE em coluna gera um número que ignora filtros. Quase sempre você queria uma medida.
• Excesso de colunas RELATED "por garantia". Aplainar a fato trazendo dez colunas de dimensão com RELATED incha o modelo sem necessidade. Traga só o que a lógica de linha realmente exige.

Boas práticas de quem faz isso em produção#

Depois de muitos projetos, algumas regras se firmaram. Primeiro: prefira medidas a colunas calculadas sempre que o cálculo depender de filtros do usuário. Segundo: mantenha um star schema limpo, com dimensões contendo os atributos descritivos, e deixe os relacionamentos fazerem a propagação de filtro. Isso reduz drasticamente a quantidade de RELATED e RELATEDTABLE que você precisa escrever. Terceiro: quando usar RELATED, use dentro de iteradores para cálculos linha a linha, não para materializar atributos que a dimensão já tem.

Um modelo bem desenhado quase não precisa dessas funções, e é aí que mora a maturidade. Elas são úteis, mas o excesso delas costuma ser sintoma de um modelo mal montado, não de uma análise sofisticada. Quando a gente faz assessment de um ambiente Power BI, o número de colunas calculadas com RELATED espalhadas pelo modelo é um dos primeiros sinais de que a modelagem precisa de atenção.

Perguntas frequentes#

Qual a diferença essencial entre RELATED e RELATEDTABLE?

RELATED traz um único valor de uma tabela do lado "um" para a linha atual do lado "muitos". RELATEDTABLE faz o contrário: retorna todas as linhas do lado "muitos" para você agregar a partir do lado "um". Uma devolve escalar, a outra devolve tabela. A direção do relacionamento decide qual serve em cada caso.

Posso usar RELATED diretamente dentro de uma medida?

Não sem um contexto de linha. RELATED precisa saber em qual linha está para resolver o relacionamento, e medidas não têm contexto de linha por padrão. Se você envolver o RELATED em um iterador como SUMX ou AVERAGEX, funciona, porque o iterador cria o contexto de linha necessário.

RELATEDTABLE precisa sempre de uma função de agregação em volta?

Na prática, quase sempre. Como RELATEDTABLE devolve uma tabela e não um valor, você usa COUNTROWS para contar, SUMX para somar, AVERAGEX para média, e assim por diante. Sozinha, ela só faz sentido como argumento de outra função que espera uma tabela.

RELATED funciona com relacionamentos inativos?

Não automaticamente. RELATED segue apenas o relacionamento ativo entre as tabelas. Se você tem relacionamentos múltiplos e quer usar um inativo, precisa ativar aquele caminho com USERELATIONSHIP dentro de um CALCULATE. Fora disso, RELATED sempre pega o ativo.

Devo criar uma coluna calculada com RELATED para trazer a categoria do produto para a tabela de vendas?

Na maioria dos casos, não. Num star schema bem feito, você filtra e agrupa pela coluna de categoria da própria dimensão Produto, e o relacionamento propaga tudo. Materializar a categoria na fato só se justifica quando alguma lógica de linha específica exige o valor ali. Fora disso, é peso morto no modelo.

RELATED deixa meu relatório mais lento?

Colunas calculadas com RELATED são computadas na atualização e ocupam espaço no modelo, aumentando o tamanho e o consumo de memória. Em modelos grandes, dezenas dessas colunas fazem diferença. Medidas, por outro lado, calculam sob demanda e não incham o modelo. Por isso a recomendação de preferir medidas sempre que o cálculo puder viver nelas.

Fechando#

RELATED e RELATEDTABLE resolvem um problema real: atravessar relacionamentos para buscar dados de outra tabela. RELATED traz um valor do lado um, RELATEDTABLE traz as linhas do lado muitos, e a direção do relacionamento é o que separa uma da outra. O aprendizado mais valioso, porém, é perceber que um modelo bem desenhado precisa muito menos dessas funções do que parece. Quando você domina contexto e monta um star schema limpo, os relacionamentos fazem quase todo o trabalho sozinhos.

Se o seu ambiente Power BI está cheio de colunas calculadas que ninguém sabe explicar e os números vivem "não batendo", isso costuma ser problema de modelagem, não de fórmula solta. Fale com a gente e a gente ajuda a colocar o modelo nos trilhos.