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

Quando o relacionamento físico não existe, mas você ainda precisa filtrar#

Existe um problema clássico em qualquer projeto de Power BI que amadurece: você tem duas tabelas que precisam conversar, mas não há um relacionamento físico entre elas. Talvez a chave tenha cardinalidade ruim, talvez o modelo já tenha muitos relacionamentos ativos disputando o mesmo caminho, talvez você esteja calculando algo dentro de uma tabela que nasceu de um SUMMARIZE e não pertence ao modelo. É exatamente aí que o TREATAS DAX entra. Ele permite aplicar um filtro de uma tabela sobre outra sem que exista uma relação física declarada no modelo, ou seja, cria o que chamamos de relacionamento virtual.

Este artigo é para quem já escreve DAX e quer entender o que o TREATAS faz por baixo do capô, quando ele é a ferramenta certa e como evitar as armadilhas que geram resultados sutilmente errados. Vou ser direto: TREATAS é poderoso, mas não é substituto universal para modelagem. Usá-lo para tapar buraco de modelo ruim é receita para relatórios lentos e difíceis de manter.

O que o TREATAS realmente faz#

A definição curta: TREATAS pega o resultado de uma expressão de tabela e o aplica como filtro sobre uma ou mais colunas de destino, tratando aqueles valores como se fossem dessas colunas. A palavra "treat" no nome é literal. Você diz ao motor: trate estes valores como se fossem daquela coluna.

A sintaxe é enxuta:

TREATAS(<expressão_de_tabela>, <coluna_destino_1>, <coluna_destino_2>, ...)

O primeiro argumento é uma tabela. As colunas seguintes são as colunas de destino que receberão o filtro, na mesma ordem das colunas da tabela de origem. Se a tabela de origem tem duas colunas, você precisa informar duas colunas de destino, e a correspondência é posicional, não por nome.

O detalhe técnico que diferencia o TREATAS de alternativas mais antigas: ele propaga o filtro pelo modelo. Quando você trata os valores como pertencentes a uma coluna real, esse filtro flui pelos relacionamentos existentes a partir daquela coluna, exatamente como se um slicer a tivesse filtrado. Isso é o que torna o TREATAS tão útil.

Vale lembrar como o motor trabalha por baixo. O VertiPaq, engine colunar do Power BI, comprime cada coluna com base na sua cardinalidade. O TREATAS conversa bem com essa arquitetura porque aplica o filtro diretamente na coluna de destino, aproveitando a compressão existente, em vez de forçar comparações linha a linha.

A sintaxe na prática, passo a passo#

Imagine que você tem uma tabela de metas mensais que não está relacionada à sua tabela de calendário, porque veio de uma planilha e a granularidade de chave não bateu. Você quer que o slicer de mês do calendário filtre as metas mesmo assim.

A medida seria algo como:

Meta Filtrada = CALCULATE( SUM( Metas[Valor] ), TREATAS( VALUES( Calendario[MesAno] ), Metas[MesAno] ) )

O que acontece aqui, na ordem:

• VALUES( Calendario[MesAno] ) devolve os valores de mês visíveis no contexto atual, ou seja, o que o slicer deixou passar.
• TREATAS pega esses valores e os aplica como filtro sobre Metas[MesAno].
• CALCULATE executa a soma já com a tabela de metas filtrada pelos meses corretos.

Nenhum relacionamento físico entre Calendario e Metas foi criado. O filtro é virtual, existe só durante a execução daquela medida.

Um segundo padrão muito comum é o filtro por múltiplas colunas, útil quando a chave é composta:

TREATAS( SUMMARIZE( Vendas, Vendas[Regiao], Vendas[Produto] ), Orcamento[Regiao], Orcamento[Produto] )

Aqui a correspondência posicional importa. Regiao mapeia para Regiao, Produto para Produto. Inverter a ordem gera um filtro errado sem lançar erro, e esse é um dos perigos que trato mais adiante.

Onde o TREATAS ganha das alternativas#

Antes do TREATAS ganhar tração, o padrão clássico para relacionamento virtual era combinar FILTER, CONTAINS ou INTERSECT. Esses métodos funcionam, mas costumam ser mais lentos porque forçam o motor a materializar tabelas intermediárias e comparar valores fora do caminho otimizado da coluna. O TREATAS aplica o filtro nativamente na coluna de destino, o que o torna, na maioria dos cenários, mais rápido e mais legível.

A tabela abaixo resume as diferenças práticas entre as abordagens mais comuns.

Abordagem	Como funciona	Legibilidade	Desempenho típico
TREATAS	Aplica valores como filtro direto na coluna de destino	Alta	Bom, aproveita a compressão do VertiPaq
FILTER + CONTAINS	Varre a tabela comparando valores linha a linha	Média	Costuma ser mais lento em volumes altos
INTERSECT	Cruza duas tabelas e retorna a interseção	Média	Aceitável, mas menos direto
Relacionamento físico	Relação declarada no modelo	Muito alta	Melhor opção quando é viável

A leitura honesta é simples: se você pode criar um relacionamento físico, crie. TREATAS não é escolha de primeira linha para um problema que a modelagem resolve melhor. Ele brilha quando o relacionamento físico não é possível ou não é desejável.

Os casos em que o TREATAS é a escolha certa#

Nem todo problema de filtro entre tabelas deve virar um relacionamento no modelo. Alguns cenários pedem TREATAS de forma legítima:

• Comparações orçado versus realizado com granularidades diferentes. A tabela de metas costuma ser mensal e por categoria, enquanto a de vendas é transacional. Relacionar fisicamente exigiria uma tabela ponte; o TREATAS resolve com uma medida limpa.
• Segmentação dinâmica. Você quer classificar clientes em faixas calculadas em tempo de execução e filtrar fatos por essas faixas sem criar uma coluna física de faixa.
• Filtro a partir de tabelas de parâmetro. Tabelas de parâmetro ficam desconectadas de propósito. O TREATAS aplica a escolha do usuário sobre a tabela de fatos.
• Relacionamentos por chave composta. O Power BI não permite relacionamento físico por múltiplas colunas de uma vez. Quando a chave real é composta, o TREATAS com SUMMARIZE cobre o caso sem uma coluna concatenada artificial.

Se o seu caso não se parece com nenhum desses, questione se você não está evitando uma decisão de modelagem que deveria ter tomado. Essa disciplina separa um modelo saudável de um relatório que ninguém consegue manter, tema que aprofundamos em modelagem e DAX: boas práticas no Power BI.

As armadilhas que geram resultados errados sem avisar#

Aqui está a parte que a maioria dos tutoriais omite. O TREATAS não reclama quando você usa errado: ele devolve um número, e o número parece plausível. Esses são os erros mais comuns.

Ordem das colunas trocada#

Como a correspondência é posicional, trocar a ordem entre origem e destino produz um filtro sem sentido, e o motor não avisa. Em chaves compostas, revise sempre se a ordem das colunas de destino espelha exatamente a ordem das colunas da tabela de origem.

Tipos de dados incompatíveis#

TREATAS compara valores. Se a coluna de origem é texto e a de destino é número, ou se há diferença de formatação, a correspondência simplesmente não acontece e você recebe totais zerados ou em branco. Garanta que origem e destino tenham o mesmo tipo e a mesma representação de valor.

Cardinalidade alta na coluna filtrada#

Aplicar TREATAS sobre uma coluna de altíssima cardinalidade, como um ID transacional único, força o motor a carregar um conjunto enorme de valores no filtro. Isso pesa. O VertiPaq comprime melhor colunas de baixa cardinalidade, e o TREATAS respeita essa lógica: quanto mais distinta a coluna, mais caro o filtro.

Esperar propagação bidirecional#

O filtro do TREATAS flui a partir da coluna de destino seguindo os relacionamentos existentes. Ele não inventa caminhos. Se o modelo não tem um relacionamento que leve o filtro adiante, ele para ali. TREATAS aplica o filtro, mas não substitui a topologia do modelo.

Usar como muleta para modelo ruim#

O erro mais caro não é técnico, é arquitetural. Espalhar TREATAS por dezenas de medidas para compensar a ausência de uma dimensão bem construída transforma o modelo em uma teia frágil, onde cada medida reimplementa um relacionamento que deveria existir uma única vez.

A tabela a seguir organiza sintoma, causa provável e correção.

Sintoma	Causa provável	Correção
Total zerado ou em branco	Tipos de dados incompatíveis entre origem e destino	Alinhar tipo e formato das colunas
Números plausíveis mas errados	Ordem das colunas trocada na chave composta	Revisar correspondência posicional
Medida lenta	TREATAS sobre coluna de altíssima cardinalidade	Filtrar por coluna de menor cardinalidade ou repensar o modelo
Filtro não chega ao fato	Falta relacionamento a partir da coluna de destino	Ajustar topologia do modelo
Modelo difícil de manter	TREATAS usado no lugar de dimensão	Criar a dimensão física adequada

Boas práticas para não se arrepender depois#

Depois de muitos projetos usando relacionamento virtual, algumas regras se consolidaram como confiáveis.

• Prefira o modelo físico sempre que possível. TREATAS é a segunda opção, não a primeira. Se um relacionamento resolve, ele resolve melhor e mais rápido.
• Filtre pela coluna de menor cardinalidade. Chave de mês, categoria ou região é barata. ID transacional é caro. Escolha o ponto de filtro com isso em mente.
• Documente a medida. Um relacionamento virtual é invisível no diagrama do modelo. Quem abrir o arquivo daqui a seis meses não vai ver a conexão. Deixe um comentário claro na medida explicando qual filtro está sendo tratado.
• Teste com e sem contexto de filtro. Valide a medida com o slicer ativo e sem ele. Muitos erros de TREATAS só aparecem em combinações específicas de filtro.
• Padronize tipos na camada de dados. Resolva incompatibilidade de tipo no Power Query ou na origem, não na medida. Isso evita a classe inteira de erros de correspondência silenciosa. Se a sua ingestão está bagunçada, vale investir em engenharia de dados antes de sofisticar as medidas.

Essas práticas se encaixam em um princípio maior: DAX limpo nasce de modelo limpo. O TREATAS existe para os casos legítimos em que a modelagem física não alcança, não para adiar decisões de arquitetura.

Onde o TREATAS se encaixa no ecossistema atual#

Vale um contexto de mercado. O Power BI tem ampla adoção no Brasil, muito por conta da penetração do ecossistema Microsoft nas empresas, e a Microsoft é reconhecida há anos como Líder no Quadrante Mágico do Gartner para plataformas de Analytics e BI. Padrões DAX como o TREATAS são conhecimento durável.

Com o Microsoft Fabric, anunciado em 2023, o mesmo motor de modelagem semântica ganhou novos modos de conexão, como o Direct Lake, que lê dados diretamente do OneLake. O TREATAS continua válido nesses modelos, mas a atenção à cardinalidade fica ainda mais importante, porque o consumo em Fabric é medido em Capacity Units e medidas mal desenhadas queimam capacidade. Se você está avaliando a plataforma, escrevemos uma análise honesta em Microsoft Fabric: o que é e vale a pena em 2026.

Do ponto de vista de licenciamento, nada disso muda a mecânica do TREATAS: ele é DAX puro e funciona igual em Power BI Pro, em PPU e em capacidades Fabric das SKUs F2 a F2048 ou nas antigas P1 a P5. O que muda é o custo de rodar uma medida ineficiente conforme a escala. Otimizar DAX deixa de ser refinamento e vira controle de custo, motivo pelo qual tratamos performance de modelo como parte de analytics avançado.

Perguntas frequentes#

TREATAS substitui um relacionamento físico no modelo?

Não deve ser encarado assim. TREATAS cria um filtro virtual em tempo de execução, útil quando o relacionamento físico não é possível ou não é desejável. Sempre que um relacionamento físico resolver o problema, ele é a escolha melhor: mais rápido, visível no diagrama e mais fácil de manter.

Qual a diferença entre TREATAS e FILTER com CONTAINS?

Ambos produzem relacionamento virtual, mas o TREATAS aplica o filtro diretamente na coluna de destino, aproveitando a arquitetura colunar do VertiPaq, enquanto FILTER com CONTAINS varre a tabela comparando valores. Na maioria dos cenários com volume relevante, o TREATAS é mais rápido e mais legível.

Posso usar TREATAS com chaves compostas de várias colunas?

Sim, e é um dos seus melhores usos, já que o Power BI não permite relacionamento físico por múltiplas colunas. Basta passar uma tabela com as colunas da chave e informar as colunas de destino na mesma ordem. A correspondência é posicional, então a ordem precisa espelhar exatamente a origem.

Por que minha medida com TREATAS retorna zero ou em branco?

A causa mais comum é incompatibilidade de tipo ou formato entre a coluna de origem e a de destino. TREATAS compara valores, e se eles não batem exatamente, nenhuma linha é filtrada. Padronize os tipos na camada de dados, de preferência no Power Query, antes de escrever a medida.

TREATAS deixa o relatório lento?

Pode deixar, se aplicado sobre colunas de altíssima cardinalidade, como IDs transacionais únicos. O ideal é filtrar por colunas de baixa cardinalidade, como mês, categoria ou região, que o VertiPaq comprime melhor. Usado com critério, o impacto de performance é pequeno.

TREATAS funciona no Microsoft Fabric e no modo Direct Lake?

Sim. TREATAS é DAX puro e funciona igual em Power BI e em modelos Fabric, incluindo Direct Lake, que lê do OneLake. A diferença é que, em Fabric, medidas ineficientes consomem Capacity Units, então a atenção à cardinalidade e ao desenho da medida tem impacto direto no custo.

Conclusão#

TREATAS é uma das ferramentas mais úteis do DAX para quando o modelo físico não alcança, mas pede disciplina. Use quando o relacionamento físico não for viável, filtre pela coluna de menor cardinalidade, cuide dos tipos de dados e documente a medida. Feito assim, o TREATAS resolve problemas reais sem transformar o modelo em uma teia frágil. Feito por preguiça de modelar, cobra caro em performance e manutenção.

Se a sua equipe está usando TREATAS para tapar buracos de modelagem, ou se as medidas estão ficando lentas e ninguém sabe por quê, fale com a gente. A Fynx já entregou mais de 2.000 soluções Microsoft e pode ajudar a colocar seu modelo de dados e seu Power BI na direção certa.