Por que relacionamentos corretos são decisivos no Power BI
Em um modelo de dados, relacionamentos são as “pontes” que permitem que uma tabela filtre a outra. Quando essas pontes estão corretas, os números respondem de forma previsível: ao selecionar um produto, o relatório mostra apenas as vendas daquele produto; ao selecionar um cliente, aparecem apenas as transações daquele cliente; ao selecionar um mês, o faturamento e as quantidades se ajustam sem surpresas.
Quando os relacionamentos estão errados (ou ambíguos), surgem sintomas comuns em dashboards de pequenos negócios: totais inflados (duplicidade), valores que mudam ao clicar em visuais diferentes sem lógica aparente, medidas que “somem” (retornam em branco), filtros que não afetam certas tabelas, ou ainda números corretos em um cartão e errados em uma tabela detalhada. A causa quase sempre está em um destes pontos: cardinalidade incorreta (1:* vs *:*), direção de filtro mal definida, chaves com duplicidade na dimensão, múltiplos caminhos de filtro entre as mesmas tabelas (ambiguidade) ou uso indevido de colunas de texto/descrição como chave.
Conceitos essenciais: cardinalidade, direção de filtro e caminho de filtro
Cardinalidade: 1 para muitos, muitos para 1 e muitos para muitos
Cardinalidade descreve como os valores de uma coluna se relacionam com os valores da outra coluna no relacionamento.
- Um para muitos (1:*): uma linha na dimensão (ex.: um Produto) aparece em muitas linhas na fato (ex.: várias Vendas do mesmo Produto). É o padrão mais seguro e desejável.
- Muitos para um (*:1): é a mesma relação vista do outro lado; no Power BI você escolhe qual coluna é “um” e qual é “muitos”.
- Muitos para muitos (*:*): ocorre quando ambos os lados têm valores repetidos. Deve ser evitado na maioria dos casos porque aumenta o risco de duplicidade e ambiguidade, além de dificultar medidas. Só use quando você entende exatamente o impacto e não há alternativa melhor (por exemplo, tabelas de ponte bem definidas).
Direção do filtro: simples vs bidirecional
A direção do filtro define para onde o filtro “viaja”. Em modelos típicos, a direção recomendada é da dimensão para a fato (filtro simples). Isso significa que selecionar um Produto filtra Vendas, mas Vendas não filtra Produto. Esse padrão reduz ambiguidade e mantém o modelo previsível.
O filtro bidirecional (ambas as direções) pode parecer conveniente, mas frequentemente cria efeitos colaterais: uma tabela fato passa a filtrar outra fato por meio de dimensões compartilhadas, ou cria múltiplos caminhos de filtro. Em dashboards de vendas, caixa e estoque, isso costuma gerar números inconsistentes e difíceis de depurar.
- Ouça o áudio com a tela desligada
- Ganhe Certificado após a conclusão
- + de 5000 cursos para você explorar!
Baixar o aplicativo
Caminho de filtro e ambiguidade
Ambiguidade acontece quando existe mais de um caminho para um filtro chegar a uma tabela. Exemplo: a tabela de Vendas pode ser filtrada por Data (Calendário) e também por uma tabela de Recebimentos que se relaciona com a mesma Data e com Clientes, formando um “circuito” de filtros. O Power BI pode bloquear um relacionamento (ficar inativo) ou permitir, mas o resultado pode variar conforme o visual e as medidas.
Duplicidade: como ela nasce e como identificar
Duplicidade na dimensão (chave não é única)
O caso mais comum: a dimensão que deveria ter uma linha por entidade (um produto, um cliente, uma loja) contém duplicatas na coluna usada como chave. Exemplo: DimProduto tem duas linhas com o mesmo SKU, talvez por variação de descrição, categoria ou erro de cadastro. Se você relacionar Vendas[SKU] com DimProduto[SKU] e DimProduto[SKU] não for único, o relacionamento pode virar *:* ou gerar comportamento inesperado, como multiplicação de valores em medidas que dependem de contexto.
Como identificar: no Power BI, ao criar/editar relacionamento, verifique se a cardinalidade está como 1:* (Dimensão no lado 1). Se não estiver, desconfie de duplicidade. Outra forma prática é criar uma tabela visual com a coluna-chave da dimensão e uma contagem de linhas; se aparecer mais de 1 para o mesmo valor, a chave não é única.
Duplicidade na fato (granularidade diferente do esperado)
Às vezes a dimensão está correta, mas a tabela fato tem linhas repetidas para o mesmo evento por causa de junções no Power Query, importações duplicadas ou mistura de granularidades (por exemplo, vendas por item misturadas com vendas por pedido). Isso não é “duplicidade de chave” no relacionamento, mas gera totais inflados do mesmo jeito.
Como identificar: procure por um identificador do evento (ID do pedido, ID do lançamento, número do documento). Se não existir, crie uma chave composta (por exemplo: Data + NúmeroDocumento + Produto + Quantidade + Valor) apenas para auditoria. Em seguida, conte ocorrências repetidas.
Duplicidade por relacionamento errado (coluna errada como chave)
Outro erro frequente é relacionar por colunas descritivas: Nome do Produto, Descrição, Categoria, Nome do Cliente. Textos mudam, têm variações de acentuação, abreviações e podem se repetir. O resultado é filtro falhando (sem correspondência) ou *:* (muitos para muitos). A regra prática: relacione por IDs estáveis (SKU, Código do Produto, ID do Cliente, CNPJ/CPF quando aplicável, ID da Loja), não por descrições.
Passo a passo prático: checklist para criar relacionamentos corretos
1) Liste as tabelas e defina quem filtra quem
Antes de clicar em “Gerenciar relacionamentos”, defina o papel de cada tabela:
- Dimensões: tabelas com entidades (Produto, Cliente, Fornecedor, Loja, Vendedor, Categoria). Elas devem filtrar as tabelas de movimento.
- Fatos: tabelas de transações (vendas, recebimentos, despesas, movimentações de estoque). Elas devem ser filtradas pelas dimensões.
Essa decisão evita a tentação de usar filtro bidirecional para “fazer funcionar” um visual, o que costuma criar problemas maiores depois.
2) Escolha a coluna-chave correta em cada dimensão
Para cada dimensão, selecione uma coluna que seja:
- Única (sem duplicatas).
- Estável (não muda com o tempo).
- Sem nulos (ou com tratamento claro para “desconhecido”).
Exemplos práticos: DimProduto[SKU], DimCliente[IdCliente], DimLoja[IdLoja]. Se você só tem Nome, considere criar um ID no processo de origem ou no Power Query (por exemplo, uma tabela de cadastro mestre com IDs). Evite criar IDs aleatórios que mudam a cada atualização, pois isso quebra histórico.
3) Valide unicidade da chave na dimensão
Faça uma validação objetiva. Uma forma simples é criar uma medida de auditoria ou uma tabela de verificação. Exemplo de medida para checar duplicidade na dimensão (use em um visual de tabela com a coluna-chave):
QtdLinhasDimProduto = COUNTROWS ( DimProduto )Para identificar quais SKUs estão duplicados, use uma tabela visual com DimProduto[SKU] e uma medida:
OcorrenciasSKU = COUNTROWS ( DimProduto )Depois filtre OcorrenciasSKU > 1. Se aparecerem valores, a dimensão precisa ser corrigida (deduplicar, consolidar, ou criar uma chave realmente única).
4) Garanta que a fato tenha a mesma “linguagem” da dimensão
Mesmo com chave correta, o relacionamento falha se os valores não “batem”. Verifique:
- Tipos de dados iguais (texto com texto, número com número).
- Padronização (zeros à esquerda, espaços, hífens, maiúsculas/minúsculas).
- Valores inexistentes na dimensão (fato tem SKU que não existe no cadastro).
Uma prática útil é criar uma dimensão com uma linha “Não cadastrado/Desconhecido” e mapear itens sem correspondência para esse valor, quando fizer sentido para o negócio. Isso evita que vendas “sumam” por falta de correspondência.
5) Crie o relacionamento com cardinalidade 1:* e filtro simples
No Power BI, ao criar o relacionamento:
- Selecione a coluna-chave da dimensão (lado 1) e a coluna correspondente na fato (lado *).
- Defina cardinalidade como Um para muitos (1:*).
- Defina direção de filtro como Única (da dimensão para a fato).
Se o Power BI não permitir 1:* e insistir em *:*, pare e volte para investigar duplicidade ou coluna errada. Não “aceite” *:* como solução rápida sem entender a causa.
6) Teste com um cenário controlado
Depois de criar o relacionamento, teste com um caso conhecido. Exemplo:
- Escolha um SKU específico e um período curto.
- Compare o total de vendas no Power BI com a fonte (planilha/ERP) para aquele SKU e período.
- Repita com 2 ou 3 SKUs e um cliente.
O objetivo é validar que o filtro está atravessando corretamente as tabelas e que não há multiplicação de valores.
Prevenção de ambiguidade: padrões seguros de modelagem de relacionamentos
Evite “loops” (ciclos) de relacionamento
Um loop acontece quando você consegue sair de uma tabela e voltar para ela seguindo relacionamentos. Exemplo: Cliente filtra Vendas, Vendas filtra Recebimentos (por bidirecional), Recebimentos filtra Cliente. Esse ciclo cria ambiguidade. O Power BI pode desativar um relacionamento automaticamente ou gerar resultados inesperados.
Como prevenir: mantenha filtro simples (dimensão → fato) e evite relacionar fatos diretamente entre si. Se duas tabelas fato precisam conversar, faça isso por meio de dimensões compartilhadas (Cliente, Produto, Loja, Calendário) e com direção única.
Use tabelas ponte (bridge) quando houver relação muitos-para-muitos legítima
Alguns cenários reais exigem muitos-para-muitos. Exemplo: um produto pode pertencer a várias categorias (ou tags) e você quer filtrar vendas por tag. Se você relacionar diretamente DimTag com DimProduto e DimProduto com Vendas, pode surgir ambiguidade dependendo da estrutura.
O padrão mais controlado é criar uma tabela ponte com pares únicos (ProdutoID, TagID). Assim:
- DimProduto (1) → PonteProdutoTag (*)
- DimTag (1) → PonteProdutoTag (*)
- DimProduto (1) → FatoVendas (*)
Com isso, o filtro de Tag chega até Produto via ponte e depois alcança Vendas. O ponto crítico é garantir que a ponte não tenha duplicatas do mesmo par ProdutoID-TagID.
Relacionamentos ativos vs inativos: quando usar e como não se perder
Às vezes você precisa de mais de um relacionamento possível entre duas tabelas, mas apenas um pode ficar ativo. Exemplo comum: uma tabela de transações pode ter DataEmissao e DataPagamento. Ambas se relacionam com o Calendário, mas só uma pode estar ativa.
O erro típico é tentar ativar as duas e acabar criando ambiguidade ou resultados confusos. O padrão recomendado é:
- Manter um relacionamento ativo (por exemplo, DataEmissao).
- Manter o outro inativo (por exemplo, DataPagamento).
- Em medidas específicas, ativar o relacionamento inativo com DAX quando necessário.
Exemplo de medida que calcula valor por DataPagamento (assumindo que o relacionamento ativo é por DataEmissao):
ValorPorDataPagamento = CALCULATE ( [ValorTotal], USERELATIONSHIP ( Calendario[Data], FatoRecebimentos[DataPagamento] ) )Esse padrão evita bidirecionalidade e mantém o modelo controlado: você escolhe explicitamente qual data está sendo usada em cada métrica.
Erros comuns que geram duplicidade e como corrigir
Erro 1: dimensão com linhas repetidas por “atributos variáveis”
Exemplo: DimCliente tem uma linha por cliente, mas você importou também o endereço e o cliente aparece repetido porque tem mais de um endereço. Resultado: Cliente deixa de ser dimensão “1” e vira *:*, causando multiplicação.
Correção: se endereço é necessário, crie uma dimensão separada (DimEndereco) e relacione com Cliente por uma chave apropriada, ou mantenha apenas um endereço “principal” na DimCliente. O que não pode é a chave do cliente deixar de ser única.
Erro 2: relacionamento por coluna com nulos ou vazios
Se a coluna-chave na fato tem muitos nulos (ex.: vendas sem SKU), esses registros não serão filtrados como esperado e podem “sumir” em análises por produto. Além disso, nulos podem atrapalhar a interpretação do relacionamento.
Correção: tratar nulos na origem/Power Query e mapear para um código padrão (ex.: “SEM_SKU”) que exista na dimensão como “Produto não identificado”, quando fizer sentido. Alternativamente, separar esses registros para auditoria.
Erro 3: uso de bidirecional para “fazer o filtro funcionar”
Quando um visual não filtra outro, a reação comum é ativar filtro bidirecional. Isso pode até resolver um caso, mas cria efeitos colaterais em outros. O correto é entender por que o filtro não está chegando: falta de dimensão compartilhada, relacionamento inativo, ou necessidade de uma tabela ponte.
Correção: volte ao desenho do modelo e garanta que exista um caminho único e intencional de filtro (dimensão → fato). Se precisar de comportamento especial, resolva com medidas (por exemplo, USERELATIONSHIP) ou com uma ponte.
Erro 4: duas dimensões diferentes para a mesma entidade
Exemplo: você tem DimProduto (do cadastro) e também uma “DimProduto” criada a partir de Vendas (lista distinta de produtos vendidos). Se ambas se relacionam com Vendas ou com outras tabelas, pode surgir ambiguidade e inconsistência de atributos (categoria diferente, nome diferente).
Correção: escolha uma dimensão mestre. Se precisar de uma lista derivada, use-a apenas como tabela auxiliar (desconectada) ou consolide tudo na dimensão mestre, garantindo chave única e atributos consistentes.
Passo a passo prático: diagnóstico rápido de modelo com números inflados
1) Confirme se o problema é multiplicação por relacionamento
Pegue um valor simples (ex.: soma de ValorTotal de Vendas) e compare:
- Um cartão com a soma total.
- Uma tabela com a dimensão suspeita (ex.: Produto) e a soma por produto.
Se a soma na tabela (total geral) ficar maior do que o cartão, há grande chance de duplicidade/ambiguidade no caminho de filtro ou de uma dimensão não única.
2) Verifique cardinalidade de todos os relacionamentos ligados à fato
Abra a visão de modelo e clique na tabela fato principal. Para cada relacionamento:
- Confirme se o lado da dimensão está marcado como 1.
- Se houver *:* investigue imediatamente.
- Se houver bidirecional, marque como suspeito e avalie se é realmente necessário.
3) Procure dimensões com chave duplicada
Para cada dimensão conectada à fato, valide a unicidade da chave. Se encontrar duplicatas, corrija antes de mexer em DAX. Medidas complexas raramente “consertam” um relacionamento ruim; elas apenas mascaram o problema.
4) Procure caminhos múltiplos entre as mesmas tabelas
Observe se existe mais de um caminho para filtrar a mesma fato. Exemplo: Cliente → Vendas e também Cliente → Recebimentos → Vendas (se houver bidirecional ou relacionamento entre fatos). Se existir, simplifique: desative um relacionamento, ajuste direção para simples, ou remodele com ponte.
5) Refaça o teste controlado
Após ajustes, repita o teste com um SKU/cliente e período conhecido. Só avance para construir visuais e KPIs quando o comportamento de filtro estiver estável e reproduzível.
Boas práticas objetivas para evitar problemas no dia a dia
- Dimensões com chave única: trate duplicatas como erro de modelagem, não como “dado normal”.
- Relacionamentos 1:* sempre que possível; evite *:*.
- Filtro simples (dimensão → fato) como padrão; bidirecional apenas com justificativa clara.
- Não relacione por texto descritivo; use IDs.
- Evite relacionar fatos entre si; use dimensões compartilhadas ou tabelas ponte.
- Quando houver duas datas relevantes, use relacionamento inativo + USERELATIONSHIP em medidas específicas.
- Auditoria contínua: mantenha visuais/medidas de checagem (duplicatas, itens sem correspondência) em uma página técnica do relatório.
