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

O erro de divisão por zero quebra mais relatório do que você imagina#

Você monta uma medida de margem, ticket médio ou taxa de conversão, publica no Power BI e no dia seguinte alguém abre um filtro que isola um mês sem vendas. O denominador vira zero, o cartão exibe Infinity ou um erro feio, e a reunião de resultados trava numa discussão sobre por que o dashboard "está com bug". Nada disso é bug. É comportamento previsível de uma divisão comum em DAX que ninguém protegeu. É exatamente esse cenário que a função DIVIDE DAX existe para resolver, e usá-la bem separa a medida que aguenta produção da medida que só funciona no ambiente de desenvolvimento.

Neste artigo vou direto ao ponto: o que a DIVIDE faz de fato, como sua sintaxe funciona, quando ela ajuda, quando ela não é a ferramenta certa e quais armadilhas eu vejo com frequência em projetos que chegam para revisão. A ideia não é decorar sintaxe, e sim entender o comportamento do motor para você escrever medidas que não vão explodir na frente do cliente.

O que a função DIVIDE faz na prática#

A DIVIDE é uma função de divisão segura. Ela executa a divisão entre um numerador e um denominador e, quando o denominador é zero ou em branco (BLANK), retorna um valor alternativo que você define, em vez de gerar um erro ou um resultado indefinido.

A sintaxe é curta:

DIVIDE(<numerador>, <denominador>, [resultado_alternativo])

Os dois primeiros argumentos são obrigatórios. O terceiro, o resultado_alternativo, é opcional. Se você não informá-lo, a DIVIDE retorna BLANK quando o denominador é zero. Isso é importante: por padrão a função não devolve zero, devolve vazio. E BLANK tem um comportamento próprio no Power BI, como veremos mais adiante.

Compare com o operador de divisão comum. Se você escreve [Lucro] / [Receita] e a receita é zero, o DAX segue a matemática pura e o resultado é um erro de divisão por zero, que aparece como Infinity, NaN ou uma célula de erro dependendo do contexto. A DIVIDE intercepta esse caso antes de o motor tentar calcular o impossível.

Situação do denominador	Operador /	DIVIDE(n, d)	DIVIDE(n, d, 0)
Denominador válido (ex.: 100)	Resultado normal	Resultado normal	Resultado normal
Denominador igual a zero	Erro / Infinity	BLANK	0
Denominador em branco (BLANK)	Erro / Infinity	BLANK	0
Numerador BLANK, denominador válido	BLANK	BLANK	BLANK

A leitura dessa tabela resume tudo o que a maioria das pessoas precisa saber para começar a usar a função com confiança.

A sintaxe é simples, o comportamento do BLANK é onde as pessoas tropeçam#

O ponto que mais gera dúvida não é a divisão em si, e sim o que fazer no caso protegido. A pergunta prática é: quando não dá para dividir, você quer mostrar vazio ou zero?

Não existe resposta única. Depende do significado da medida no relatório.

• Deixar BLANK (sem terceiro argumento): costuma ser a escolha certa para indicadores percentuais e razões, porque uma linha ou período sem base de cálculo simplesmente não deveria mostrar número. O BLANK some naturalmente de muitos visuais e evita poluir a leitura com zeros que não significam nada.
• Forçar 0 (terceiro argumento = 0): faz sentido quando o zero é uma informação legítima de negócio, por exemplo uma taxa de conversão de zero por cento num período em que houve visitas mas nenhuma compra. Aqui o zero comunica algo real.

A diferença tem efeito colateral direto em totais, em ordenação e na exibição de eixos. Uma medida que retorna BLANK pode desaparecer de um gráfico de linhas, enquanto a versão com 0 mantém a série contínua. Decida isso de propósito, não por acaso.

Exemplos conceituais que você vai reaproveitar#

Os padrões abaixo cobrem a esmagadora maioria dos casos reais. Uso nomes genéricos de medidas e colunas para você adaptar ao seu modelo.

Margem percentual

Margem % = DIVIDE([Lucro], [Receita])

Aqui deixo BLANK de propósito. Se não houve receita, não existe margem para exibir, e mostrar zero por cento seria enganoso.

Ticket médio

Ticket Médio = DIVIDE([Receita Total], [Qtd de Pedidos])

Sem pedidos, não há ticket. BLANK é honesto.

Taxa de conversão

Conversão % = DIVIDE([Compras], [Visitas], 0)

Neste caso o zero é legítimo. Houve visitas, ninguém comprou, a conversão foi zero por cento e isso é um fato de negócio que o gestor precisa ver.

Participação sobre o total

% do Total = DIVIDE([Vendas], CALCULATE([Vendas], ALL(Produto)))

Padrão clássico de participação. O denominador remove o filtro de produto para calcular o total geral, e a DIVIDE protege contra o caso de o total ser vazio.

Se você quer aprofundar esses padrões de contexto de filtro e escrever medidas mais previsíveis, vale conferir nosso material sobre modelagem e boas práticas de DAX no Power BI, que trata justamente de como CALCULATE e o contexto interagem.

Por que a DIVIDE existe se o operador de divisão já funciona#

A resposta curta é performance e robustez, e vale entender a mecânica.

Quando você usa o operador /, o motor precisa avaliar cada divisão e, para cada caso de denominador zero, disparar e capturar uma condição de erro. Se você tenta se proteger manualmente com IF([Receita] = 0, BLANK(), [Lucro] / [Receita]), o motor acaba avaliando o denominador mais de uma vez: uma no teste do IF e outra na divisão. Em uma medida simples isso é irrelevante. Em uma tabela com milhões de linhas, contexto de filtro pesado e várias medidas empilhadas, a diferença aparece.

A DIVIDE foi construída como uma função nativa que trata o caso de denominador zero internamente, de forma otimizada, sem o padrão de avaliar duas vezes e sem o custo de captura de erro do operador puro. Ou seja, além de mais legível, ela tende a ser igual ou mais eficiente que a alternativa manual. Não é uma diferença dramática na maioria dos relatórios, mas é a escolha tecnicamente correta.

Vale lembrar o contexto do motor por trás disso. O Power BI roda sobre o VertiPaq, o motor colunar em memória que comprime colunas por cardinalidade e é otimizado para operações vetorizadas. Funções nativas como a DIVIDE conversam melhor com esse motor do que construções manuais equivalentes. Quando falamos de modelos grandes, seja em capacidade dedicada do Microsoft Fabric, seja em Power BI Premium, cada padrão de código que evita reavaliação desnecessária ajuda a manter o consumo sob controle.

Abordagem	Legibilidade	Trata zero e BLANK	Risco de reavaliar denominador
[a] / [b]	Alta	Não	Não, mas gera erro
IF([b]=0, BLANK(), [a]/[b])	Média	Parcial	Sim
DIVIDE([a], [b])	Alta	Sim	Não

A conclusão é direta: para divisão em medidas, a DIVIDE deveria ser o seu padrão, e o operador / fica reservado para casos onde você tem certeza absoluta de que o denominador nunca será zero, ou para expressões escalares triviais que não dependem de dados.

As armadilhas que aparecem em projeto real#

Já revisei bastante modelo com problema de divisão, e os erros se repetem. Vou listar os que mais custam caro.

Achar que DIVIDE resolve o numerador também#

A DIVIDE protege o denominador, não o numerador. Se o seu numerador vier com problema de contexto, com relacionamento errado ou com uma coluna que deveria ser medida, a DIVIDE vai dividir um número errado sem reclamar. Ela não valida a lógica do cálculo, apenas o caso de divisão impossível. Continue responsável pela correção do numerador.

Usar zero como alternativo quando o certo seria BLANK#

Colocar , 0 em toda DIVIDE por hábito é um erro comum. Em medidas de razão e percentual, forçar zero cria linhas fantasmas em tabelas, distorce médias de médias e pode enganar quem lê. Pergunte sempre: neste período sem base, o número correto a exibir é zero ou é "não se aplica"? Se for "não se aplica", deixe BLANK.

Confundir denominador zero com denominador ausente#

Zero e BLANK são coisas diferentes no DAX, e a DIVIDE trata os dois como caso protegido, o que é bom. O problema é quando o seu denominador está vindo BLANK por causa de um relacionamento quebrado ou de uma tabela sem correspondência, e você mascara isso com a DIVIDE em vez de corrigir a modelagem. A função vai esconder o sintoma e você perde a pista do problema real. Se um denominador está vindo vazio quando não deveria, isso é assunto de modelagem, não de divisão.

Dividir colunas em vez de medidas#

Escrever DIVIDE em uma coluna calculada linha a linha, quando o certo seria uma medida agregada, é fonte de resultado errado. Divisão de totais não é a mesma coisa que a soma de divisões linha a linha. Na maioria dos indicadores de negócio você quer dividir o total do numerador pelo total do denominador, o que é trabalho de medida, avaliada no contexto de filtro do visual, e não de coluna materializada.

Esperar que DIVIDE trate texto ou tipos incompatíveis#

A DIVIDE espera valores numéricos. Se algum argumento chega como texto ou tipo incompatível, você terá erro de tipo, não o resultado alternativo. O terceiro argumento cobre denominador zero ou BLANK, não erro de conversão. Garanta os tipos antes.

Onde a DIVIDE entra numa estratégia de BI que se sustenta#

Uma função de divisão parece detalhe, mas medidas robustas são a base de um modelo confiável. Relatório que quebra na frente do usuário destrói confiança, e confiança é o ativo mais caro de recuperar num projeto de dados. Padronizar o uso da DIVIDE, junto com convenções claras de nomenclatura e de tratamento de BLANK, faz parte de um trabalho maior de qualidade que a gente costuma tratar em governança de dados e em sustentação de BI.

Vale o contexto de mercado: o Power BI tem ampla adoção no Brasil, puxada pela penetração do ecossistema Microsoft nas empresas, e a Microsoft é reconhecida como Líder no Quadrante Mágico do Gartner para plataformas de Analytics e BI há anos. Isso significa muita gente escrevendo DAX, muita medida herdada e muito código que ninguém revisou. Padrões simples e corretos, como usar DIVIDE no lugar de divisão nua, escalam bem quando o time cresce e o número de relatórios explode. É trabalho de fundação, não de vitrine, e é onde nosso time de Power BI mais gera valor no médio prazo.

Se o seu ambiente já passou da fase de dashboards isolados e caminha para modelos corporativos, capacidade dedicada e Microsoft Fabric, a disciplina no DAX deixa de ser preferência estética e vira fator de custo. Consumo em capacidade se mede em Capacity Units, e código previsível ajuda a manter esse consumo saudável. Para quem está avaliando esse cenário, escrevemos um panorama honesto sobre o que é o Microsoft Fabric e se vale a pena em 2026.

Perguntas frequentes#

Qual a diferença entre DIVIDE e o operador de divisão em DAX?

O operador / faz a divisão pura e gera erro quando o denominador é zero. A DIVIDE executa a mesma divisão mas trata internamente o caso de denominador zero ou BLANK, retornando um valor alternativo que você escolhe, ou BLANK por padrão. Além de mais segura, a DIVIDE é uma função nativa otimizada e evita a reavaliação dupla do denominador que acontece quando você tenta proteger a divisão manualmente com IF.

A DIVIDE retorna zero ou vazio quando não consigo dividir?

Depende do terceiro argumento. Sem ele, a DIVIDE retorna BLANK quando o denominador é zero ou vazio. Se você passar um terceiro argumento, por exemplo DIVIDE([a], [b], 0), ela retorna esse valor no caso protegido. A escolha entre BLANK e zero deve seguir o significado de negócio da medida, não o hábito.

A DIVIDE é mais lenta que a divisão comum?

Não. Em geral ela é igual ou mais eficiente que proteger a divisão com IF, porque trata o caso de zero internamente e não avalia o denominador duas vezes. Contra o operador / puro a diferença de desempenho é pequena, mas a DIVIDE ganha em robustez, então ela deve ser o padrão em medidas.

Posso usar DIVIDE dentro de outras funções como CALCULATE e SUMX?

Sim. A DIVIDE é uma função escalar comum e se combina livremente com CALCULATE, SUMX, AVERAGEX e o resto do DAX. Um padrão frequente é dividir uma agregação por outra usando CALCULATE no denominador para alterar o contexto de filtro, como no cálculo de participação sobre o total. Só tome cuidado com o contexto em que numerador e denominador são avaliados, porque a função não corrige lógica de contexto errada.

DIVIDE trata erros de texto ou tipo incompatível?

Não. O tratamento da DIVIDE cobre apenas denominador zero ou BLANK. Se algum argumento chega como texto ou tipo incompatível, você terá erro de conversão de tipo, não o resultado alternativo. Garanta que numerador e denominador sejam numéricos antes de dividir.

Devo sempre colocar zero como terceiro argumento por segurança?

Não como regra automática. Forçar zero faz sentido quando o zero é uma informação real, como uma taxa de conversão de zero por cento num período com visitas e sem compras. Para razões e percentuais sem base de cálculo, deixar BLANK costuma ser mais honesto e evita zeros fantasmas em tabelas e gráficos. Decida caso a caso.

Fechando#

A DIVIDE é uma dessas funções pequenas que separam o relatório amador do relatório profissional. Ela não vai transformar sua análise, mas vai evitar que ela quebre na hora errada, e em BI isso conta muito. Adote como padrão para toda divisão em medidas, escolha entre BLANK e zero de forma consciente e nunca use a função para mascarar problema de modelagem que deveria ser corrigido na raiz.

Se o seu time quer padronizar DAX, revisar medidas herdadas ou estruturar um ambiente de Power BI que aguente crescer sem virar bola de neve, fale com a gente. A Fynx já entregou mais de 2.000 soluções Microsoft para mais de 50 clientes em 6 anos de mercado, e esse tipo de fundação é exatamente onde a gente atua.