Cardinalidade de Relacionamentos: Entenda de uma vez o que isto significa

Um relacionamento entre duas tabelas pode parecer correto e, ainda assim, fazer seu modelo inteiro produzir resultados errados.

É aqui que entra a cardinalidade dos relacionamentos no Power BI. Ela define como os registros de uma tabela se relacionam com os registros de outra e influencia diretamente o comportamento dos filtros e das medidas.

Neste artigo, você vai entender os quatro tipos de cardinalidade, como eles funcionam e qual é a relação entre cardinalidade, a direção de filtro, e por que esse é um dos assuntos que mais separa um modelo amador de um modelo profissional.

1. O que é cardinalidade e por que ela existe

Antes de falar de cardinalidade, é preciso relembrar o que é um relacionamento:

No Power BI, um relacionamento é a conexão entre duas tabelas, feita através de uma coluna em comum, geralmente chamada de chave (key). Essa conexão é o que permite que um filtro aplicado em uma tabela, por exemplo, um segmentador de Categoria na tabela dProdutos se propague e afete os valores calculados em outra tabela, como o total de vendas na tabela fVendas.

A cardinalidade é a característica que descreve quantos valores repetidos existem de cada lado dessa conexão. Em outras palavras: para cada valor da coluna-chave em uma tabela, quantos registros correspondentes existem na outra tabela?

Pense em duas listas de nomes: se uma lista tem cada cliente aparecendo uma única vez, mas a outra lista tem o mesmo cliente aparecendo várias vezes (uma vez por compra realizada), a cardinalidade entre essas duas listas não é simétrica, e é exatamente essa assimetria (ou a ausência dela) que o Power BI precisa entender para calcular corretamente qualquer medida.

⚠️ Atenção: Cardinalidade não é uma configuração decorativa dentro da caixa de diálogo de relacionamento. Ela define matematicamente como o motor do Power BI (VertiPaq) vai propagar o contexto de filtro entre as tabelas. Configurá-la errado não gera necessariamente um erro visível, na maioria das vezes, gera um número errado sem nenhum aviso.

Leia também: Dado bruto x Dado tratado x Informação: entenda as diferenças

2. Os quatro tipos de cardinalidade no Power BI

Ao criar ou editar um relacionamento, seja arrastando uma coluna sobre a outra na Visão de Modelo, seja pelo menu Gerenciar Relacionamentos, o Power BI exibe um campo chamado Cardinalidade, com quatro opções possíveis.

2.1 Um para muitos (1:*)

Esta é, de longe, a cardinalidade mais comum e a mais recomendada em qualquer modelo bem construído. Ela ocorre quando:

• Uma tabela tem valores únicos na coluna-chave (o lado "1") normalmente uma tabela dimensão, como dProdutos, dClientes ou dCalendario.
• A outra tabela tem valores repetidos na mesma coluna (o lado muitos “*”) normalmente uma tabela fato, como fVendas.

Exemplo: a tabela dProdutos tem uma linha para cada produto, com a chave primária ID_Produto sem nenhuma duplicata. Já a tabela fVendas tem uma linha para cada venda realizada, e o mesmo ID_Produto pode aparecer centenas de vezes, uma para cada vez que aquele produto foi vendido.

Na Visão de Modelo, esse relacionamento aparece com o número 1 próximo à tabela dimensão e o símbolo * (asterisco) próximo à tabela fato.

Leia também: Power BI vs Excel: qual a diferença e quando usar cada um?

2.2 Muitos para um (*:1)

Tecnicamente, é o mesmo relacionamento do tópico anterior, apenas descrito a partir do ponto de vista oposto. Se você está olhando da tabela fato em direção à tabela dimensão, o Power BI descreve a cardinalidade como "Muitos para um". A lógica matemática por trás é idêntica, o que muda é apenas qual tabela está sendo referenciada primeiro.

2.3 Um para um (1:1)

Ocorre quando ambos os lados da coluna-chave possuem valores únicos, sem nenhuma repetição. É a cardinalidade menos comum em modelos corporativos.

Quando ela aparece de forma legítima:

• Duas tabelas que descrevem a mesma entidade, mas foram divididas por algum motivo técnico (por exemplo, uma tabela dFuncionarios com dados cadastrais e outra dFuncionarios_Salarios com dados sensíveis, separadas propositalmente por segurança).
• Integração de duas fontes distintas que representam o mesmo conjunto de entidades (um cadastro que vem do ERP e um complemento que vem de um sistema de RH, ambos com uma linha por funcionário).

💡 Dica: Na maioria dos casos, quando você se depara com uma cardinalidade Um para Um, vale perguntar: "essas duas tabelas não deveriam, na verdade, ser uma única tabela?". Se ambas têm exatamente uma linha por registro e não existe um motivo técnico ou de governança para separá-las, mesclar as tabelas no Power Query (via Mesclar Consultas) costuma simplificar o modelo e melhorar a performance.

2.4 Muitos para muitos (*:*)

Ocorre quando nenhum dos dois lados possui valores únicos na coluna-chave, ambas as tabelas têm o mesmo valor se repetindo.

Exemplo: imagine uma tabela fVendas e uma tabela dVendedores_Regioes, em que um mesmo vendedor pode atender múltiplas regiões e uma mesma região pode ter múltiplos vendedores atribuídos. Se você tentar relacionar fVendas diretamente a essa tabela pela coluna ID_Vendedor, nenhum dos dois lados terá unicidade.

O relacionamento Muitos para muitos é suportado nativamente pelo Power BI, mas deve ser tratado com cautela: ele é mais custoso em termos de performance do que um relacionamento 1:* / *:1, pode gerar ambiguidade de filtro e, em cenários mal modelados, é uma das causas mais comuns de valores duplicados ou valores incorretos em medidas de soma.

⚠️ Atenção: Relacionamentos Muitos para muitos entre duas tabelas fato (por exemplo, fVendas e fMetas, ambas com granularidades diferentes) são especialmente perigosos. Eles tendem a multiplicar linhas silenciosamente durante o cálculo, inflando totais sem gerar nenhum erro visível na tela.

3. Direção do filtro (Cross Filter Direction): o outro lado da moeda

Além da cardinalidade, todo relacionamento tem uma segunda propriedade que trabalha em conjunto com ela: a Direção do filtro cruzado (Cross Filter Direction). Essa configuração define para qual lado o contexto de filtro pode se propagar.

Existem duas opções:

• Único (Single): o filtro flui apenas do lado "1" para o lado "muitos", ou seja, da dimensão para o fato. É o comportamento padrão e o mais recomendado na grande maioria dos modelos em esquema estrela.
• Ambos (Both): o filtro flui nos dois sentidos: da dimensão para o fato e do fato para a dimensão. Costuma ser necessário em cenários específicos, como tabelas ponte em relacionamentos Muitos para muitos, mas seu uso indiscriminado é uma das causas mais comuns de ambiguidade de filtro e de degradação de performance em modelos maiores.

Por que "Ambos" pode ser um problema?

Quando várias tabelas fato estão conectadas a uma mesma dimensão com filtro bidirecional habilitado, o Power BI pode se deparar com múltiplos caminhos possíveis para propagar um mesmo filtro. Nesses casos, ele pode:

• Recusar a criação do relacionamento, exibindo um aviso de ambiguidade; ou
• Aceitar a configuração, mas gerar comportamentos de filtro inesperados em medidas específicas, difíceis de depurar.

💡 Dica prática: Como regra geral, mantenha a direção do filtro como Único, com o fluxo saindo da dimensão em direção ao fato. Só habilite Ambos quando você tiver um motivo técnico claro (como uma tabela ponte em um relacionamento Muitos para muitos) e tiver testado o impacto nas medidas existentes.

4. Como o Power BI detecta relacionamentos automaticamente

Ao carregar duas ou mais tabelas no modelo, o Power BI pode tentar detectar e criar relacionamentos automaticamente, com base em colunas de nomes coincidentes. Essa detecção define tanto a cardinalidade quanto a direção do filtro sem nenhuma intervenção do analista.

Embora seja conveniente para prototipagem rápida, essa automação é uma fonte comum de relacionamentos incorretos, especialmente quando duas colunas têm o mesmo nome, mas representam conceitos de negócio diferentes (por exemplo, duas colunas Código que, coincidentemente, têm o mesmo nome, mas pertencem a domínios distintos).

A opção que controla esse comportamento fica em:

Arquivo > Opções e configurações > Opções > GLOBAL > Carregamento de Dados > Detectar relações quando os dados são carregados no modelo

Analistas que preferem ter controle total sobre a modelagem costumam desmarcar essa opção e criar todos os relacionamentos manualmente, validando a cardinalidade correta para cada par de tabelas.

Leia também: Decifrando o Power Query #2: Guia Arquivos - Configurações Locais x Configurações Gerais

5. Problemas comuns causados por cardinalidade mal configurada

5.1 Ambiguidade de caminhos de filtro

Quando existe mais de um caminho possível para o filtro chegar de uma tabela a outra, por exemplo, duas colunas de data diferentes conectando fVendas a dCalendario, o Power BI não permite que os dois caminhos estejam ativos ao mesmo tempo. Ele mantém apenas um relacionamento ativo (representado por uma linha contínua na Visão de Modelo) e marca o(s) demais como inativo(s) (linha tracejada).

Um caso muito comum: uma tabela fVendas com as colunas DataVenda e DataEnvio, ambas relacionadas à mesma dCalendario. Apenas uma dessas relações pode estar ativa por padrão.

5.2 Relacionamentos inativos e a função USERELATIONSHIP

Para aproveitar um relacionamento inativo em um cálculo específico, sem alterar o comportamento padrão do modelo, usa-se a função USERELATIONSHIP dentro de uma medida DAX.

Cenário de negócio: uma empresa de logística quer comparar o faturamento por Data de Venda (relacionamento ativo, padrão) com o volume de pedidos por Data de Envio (relacionamento inativo).

Pedidos por Data de Envio =

CALCULATE(

COUNTROWS(fVendas),

USERELATIONSHIP(fVendas[DataEnvio], dCalendario[Data])

)

O que cada argumento faz:

• CALCULATE(...): modifica o contexto de filtro da expressão interna.
• COUNTROWS(fVendas): conta o número de linhas (pedidos) da tabela fato.
• USERELATIONSHIP(fVendas[DataEnvio], dCalendario[Data]): ativa temporariamente, apenas para esse cálculo, o relacionamento entre DataEnvio e a tabela dCalendario, sem desativar o relacionamento padrão do modelo.

5.3 Duplicação de valores ("fan-out")

Esse é o sintoma mais perigoso de todos, porque não gera erro, apenas números errados silenciosos. Ele acontece quando um relacionamento configurado incorretamente como Muitos para muitos (mesmo que deveria ser 1:*) faz com que uma medida de soma multiplique valores.

Exemplo: se uma tabela fVendas for relacionada a outra tabela fato fComissoes diretamente pelo ID_Vendedor (em vez de relacionar cada uma delas separadamente à dimensão dVendedores), e ambos os lados tiverem valores repetidos, uma medida de soma de faturamento pode aparecer multiplicada pelo número de linhas correspondentes na outra tabela.

⚠️ Atenção: Como regra prática, evite relacionar duas tabelas fato diretamente entre si. O caminho correto é sempre conectar cada tabela fato às tabelas dimensão compartilhadas, mantendo o esquema estrela.

6. Tabela Ponte (Bridge Table): a solução para o relacionamento Muitos para muitos

Quando o relacionamento Muitos para muitos é uma necessidade real do negócio e não um erro de modelage, a prática recomendada é resolver a ambiguidade criando uma tabela ponte (bridge table): uma tabela dimensão auxiliar, com valores únicos, posicionada entre as duas tabelas que originalmente teriam uma relação N:N.

Cenário de negócio: uma rede de varejo tem vendedores que atuam em múltiplas filiais, e cada filial pode ter múltiplos vendedores atribuídos. Em vez de relacionar fVendas diretamente a uma tabela Vendedor_Filial (que teria duplicidade nos dois lados), o modelo correto seria:

dVendedores (1) ──── (*) fVendas
dFiliais (1) ──── (*) fVendas

Aqui, a própria tabela fato fVendas já funciona como o ponto de encontro entre vendedor e filial, porque cada linha de venda registra qual vendedor atendeu em qual filial. A tabela ponte só se torna necessária quando não existe uma tabela fato natural unindo as duas entidades. Um exemplo é modelar quais vendedores estão habilitados a atender quais filiais, independentemente de terem realizado uma venda ali.

Nesse caso, cria-se uma tabela auxiliar pVendedorFilial, contendo apenas a combinação de ID_Vendedor e ID_Filial, relacionada como 1:* tanto a dVendedores quanto a dFiliais. Isso decompõe o relacionamento Muitos para muitos original em dois relacionamentos Um para muitos, eliminando a ambiguidade e restaurando a performance do esquema estrela.

7. Passo a passo: verificando e editando a cardinalidade no Power BI Desktop

1. Acesse a Visão de Modelo no painel lateral esquerdo do Power BI Desktop.
2. Localize a linha que conecta as duas tabelas que você deseja revisar. Os símbolos 1 e exibidos próximos a cada extremidade indicam a cardinalidade atual.
3. Clique duas vezes sobre a linha de relacionamento (ou clique com o botão direito e selecione Propriedades) para abrir a caixa Editar relacionamento.
4. No campo Cardinalidade, confirme se a opção selecionada corresponde à realidade dos dados (Um para muitos, Muitos para um, Um para um ou Muitos para muitos).
5. No campo Direção do filtro cruzado, valide se está definida como Único ou Ambos, de acordo com a necessidade do modelo.
6. Caso a fonte seja DirectQuery, você também verá a opção Assumir integridade referencial, que informa ao mecanismo que todos os valores do lado "muitos" possuem correspondência garantida no lado "1", permitindo consultas SQL mais eficientes (do tipo INNER JOIN).
7. Clique em OK para salvar as alterações.

💡 Dica prática: Antes de confiar na cardinalidade proposta automaticamente pelo Power BI, valide a unicidade da coluna-chave usando a ferramenta Distribuição de Coluna no Power Query: se o número de Valores distintos for igual ao total de linhas da tabela, essa coluna pode ser usada com segurança como o lado "1" de um relacionamento.

Leia também: Ferramentas de Qualidade da Coluna Power Query

8. Dica de Ouro: modele o esquema estrela antes de criar qualquer relacionamento

Grande parte dos problemas de cardinalidade não nasce na caixa de diálogo de relacionamento: nasce antes, na forma como as tabelas foram estruturadas no Power Query. Algumas práticas que evitam a maioria dos problemas descritos neste artigo:

• Prefira sempre 1:* com direção Única. É a configuração mais previsível, mais performática e mais fácil de auditar.
• Nunca relacione duas tabelas fato diretamente. Sempre passe por uma tabela dimensão compartilhada.
• Trate a duplicidade na origem, não no relacionamento. Se uma coluna que deveria ser única (como ID_Cliente em uma tabela dClientes) apresenta duplicatas, o problema deve ser resolvido no Power Query (removendo duplicidades ou agregando os dados) antes de criar o relacionamento.
• Reserve "Ambos" e "Muitos para muitos" para exceções documentadas. Se o modelo exige esse tipo de relacionamento, documente o motivo no nome da tabela ou em uma anotação, para que outra pessoa que herdar o projeto entenda a decisão.
• Valide o resultado com o Performance Analyzer. Relacionamentos bidirecionais e Muitos para muitos tendem a aparecer como gargalo em consultas mais lentas.

Leia também: Erros Comuns de Iniciantes no Power BI: Como Evitá-los e Ter Resultados Profissionais

9. Comparativo entre os quatro tipos de cardinalidade

Qual o próximo passo?

Entender a diferença entre os tipos de cardinalidade é o que separa um modelo que "parece funcionar" de um modelo que entrega números confiáveis de forma consistente. Relacionamentos não são um detalhe técnico escondido nos bastidores eles são a estrutura que sustenta cada medida DAX do seu relatório.

Com a cardinalidade e a direção do filtro sob controle, o próximo passo natural é aprofundar o entendimento sobre como o esquema estrela organiza tabelas fato e dimensão, e como transformar dados brutos em um modelo pronto para receber esses relacionamentos com segurança.

Leia também: Como destravar o verdadeiro poder do Power BI - Integrando dados de fontes distintas

Disponibilidade dos recursos citados neste artigo:

📌 Nota sobre versões: Os caminhos de menu e o comportamento das caixas de diálogo de relacionamento descritos neste artigo referem-se ao Power BI Desktop com atualização até Agosto de 2026. Consulte sempre a página Relacionamentos de modelo no Power BI Desktop, no Microsoft Learn, para verificar mudanças recentes no comportamento do motor de modelagem.