O join que dobra seu faturamento no relatório (e ninguém percebe)

Em resumo: quando você junta duas tabelas por uma chave que se repete de um dos lados, cada linha original vira várias. O total soma o mesmo dinheiro N vezes e o faturamento no relatório infla. Sem erro, sem alerta, sem ninguém perceber. É o problema oposto ao do INNER JOIN que come registros: aqui não falta dado, sobra. O nome dele é fan-out join.

Por que o número infla sem ninguém ver

Um join não é uma soma de tabelas lado a lado. É um produto entre as linhas que casam. Se a chave é única dos dois lados, cada linha encontra no máximo um par e a contagem se mantém. Mas se do outro lado a chave se repete (um pedido com 3 itens, um jogador com 2 afiliados, uma nota com vários lançamentos), a linha original é duplicada uma vez para cada correspondência.

O detalhe cruel: as linhas multiplicam, mas os valores vêm junto. Some amount depois de um fan-out e você soma o mesmo valor quantas vezes ele foi duplicado. O total cresce. Parece plausível ("vendemos mais mesmo") e vai para a diretoria como verdade.

Um caso real: faturamento que quase triplicou

Num pipeline que montei, um join entre uma tabela de atribuição de afiliados e a de transações tinha um problema de granularidade: alguns registros apareciam sob mais de um afiliado. O join multiplicou as linhas em cerca de 3,4×. O faturamento reportado saltou junto, de um valor real para quase o triplo dele.

Nada quebrou. O build rodou e o relatório abriu, com um número três vezes maior do que devia. Só apareceu quando conferi o total contra a fonte — exatamente como quando o fechamento não bate.

Como detectar o fan-out

1. Conte antes e depois do join. Se o número de linhas subiu, uma das chaves não é única. Um INNER JOIN correto por chave única nunca aumenta a contagem.
2. Verifique a unicidade da chave do lado que deveria ser "um": count(*) vs. count(distinct chave). Se diferem, você tem repetição — e ela vai multiplicar.
3. Reconcilie o total monetário com a origem. Se a soma de amount no resultado é maior que na tabela-fonte, é fan-out até prova em contrário.

Como corrigir (na origem, não no relatório)

A tentação é remendar com distinct ou uma agregação no fim para "desinflar". Não faça isso. Você esconde o sintoma e o próximo join herda o mesmo grão errado. O conserto certo é resolver a granularidade na origem:

• Defina o grão de cada tabela antes de juntar (uma linha é um quê? um pedido, um item, uma transação?). Junte só tabelas do mesmo grão, ou agregue uma delas ao grão da outra primeiro.
• Deduplique a dimensão que se repete (escolha o afiliado/atribuição correto por regra) antes do join, não depois da soma.
• Teste a unicidade da chave como parte do pipeline, para o fan-out quebrar alto em vez de passar em silêncio — o mesmo princípio de um pipeline confiável.

Perguntas frequentes

Como sei se meu relatório está inflado por um join?

Faça um teste rápido. Pegue o faturamento total do relatório e compare com a soma direta na tabela-fonte, sem nenhum join. Se o relatório vem maior, quase sempre é fan-out. O sinal clássico é um número que cresceu de um período para o outro sem que ninguém tenha vendido mais.

Dá para corrigir sem refazer o relatório inteiro?

Dá. O erro costuma estar em um join específico, não no relatório todo. Eu isolo qual junção multiplica as linhas, corrijo o grão naquele ponto e o resto continua igual. Na prática é uma cirurgia, não uma reconstrução.

Isso acontece só em SQL ou também no Power BI e no Excel?

Acontece em todos. No Power BI, um relacionamento muitos-para-muitos infla a medida do mesmo jeito. No Excel, um PROCV para uma tabela com chave repetida traz o valor errado ou duplica linhas. A ferramenta muda, o mecanismo é o mesmo: chave que se repete, valor que soma mais de uma vez.

O ponto não é ter medo de join. É saber o grão de cada tabela e validar a unicidade da chave de propósito. Faço esse tipo de blindagem em pipelines ETL/ELT. Se o número do relatório cresceu e ninguém sabe explicar por quê, eu ajudo a achar onde ele inflou.