Extrair, transformar e Carregar dados
(Power Query)
(Power Query)
No processo de ETL (Extract, Transform, Load) dentro do Power BI (usando o Power Query), é importante manter consultas bem estruturadas, claras e eficientes. As práticas a seguir visam facilitar a compreensão das transformações de dados e otimizar o desempenho da carga.
Consultas de Referência
Sempre que precisar usar a mesma lógica de transformação em várias consultas, evite duplicar passos manualmente. Em vez disso, crie uma consulta base (com Carga Desabilitada) e faça com que outras consultas referenciem essa consulta base. Assim, você mantém a lógica central em um só lugar, facilitando atualizações futuras.
Atenção: Cuidado com desempenho e consultas dinâmicas
Embora úteis, consultas referenciadas podem impactar o tempo de atualização. Cada consulta que referencia outra pode fazer a fonte de dados ser acessada várias vezes (não há "cache" automático do resultado da primeira).
Embora úteis, consultas referenciadas podem impactar o tempo de atualização. Cada consulta que referencia outra pode fazer a fonte de dados ser acessada várias vezes (não há "cache" automático do resultado da primeira).
Talvez considere a utilização da função Table.Buffer - PowerQuery M
Descrição de Consultas
Aproveite o campo de Descrição das consultas (em Propriedades da consulta, no editor do Power Query) para anotar o que cada consulta faz, sua origem ou qualquer detalhe relevante. Essa descrição não aparece para os usuários finais, mas serve como documentação interna do projeto – útil para você no futuro ou outros desenvolvedores que forem dar manutenção.
Legibilidade da Consulta
Renomeie as etapas aplicadas
O Power Query gera nomes automáticos para cada passo (por ex.: Tipo Alterado, Linhas Filtradas, Índice Adicionado), muitas vezes incluindo espaços e caracteres especiais, o que resulta em código M com #"Nome da Etapa" entre aspas. É recomendável renomear cada etapa para um nome sem espaços e que indique claramente sua ação.
Dica – aproveite a IA
Ferramentas de Inteligência Artificial podem ajudar na organização das etapas. Por exemplo, você pode copiar o código M da sua consulta e pedir para um assistente de IA (como o ChatGPT) sugerir nomes melhores ou explicar cada etapa.
Exemplo:
Prompt: Melhore a organização da seguinte consulta em Power Query M deixando-a mais legível e melhorando a nomenclatura das etapas, evitando o uso de # "" e adicionando comentários.
let
Fonte = fx_API_query("CadUsuario/GetAllUsers", api_key),
#"/CadUsuario/GetAllUsers Expandido" = Table.ExpandRecordColumn(Fonte, "CadUsuario/GetAllUsers", {"nomeUsuario", "dataInicio", "situacao", "tipoUsuario", "email", "telefone", "id"}, {"nomeUsuario", "dataInicio", "situacao", "tipoUsuario", "email", "telefone", "id"}),
#"Duplicatas Removidas" = Table.Distinct(#"/CadUsuario/GetAllUsers Expandido", {"id"}),
#"Tipo Alterado" = Table.TransformColumnTypes(#"Duplicatas Removidas",{{"nomeUsuario", type text}, {"dataInicio", type datetime}, {"situacao", type logical}, {"tipoUsuario", type text}, {"email", type text}, {"telefone", type any}, {"id", Int64.Type}}),
#"Data Inserida" = Table.AddColumn(#"Tipo Alterado", "Data", each DateTime.Date([dataInicio]), type date)
in
#"Data Inserida"Resultado (Usando GPT-4o)
let
// --- Parâmetros ---------------------------------------------------------
EndpointPath = "CadUsuario/GetAllUsers",
// --- 1) Consulta a API ---------------------------------------------------
FonteAPI = fx_API_query(EndpointPath, api_key),
// --- 2) Expande os campos do registro retornado -------------------------
UsuariosExpandido =
Table.ExpandRecordColumn(
FonteAPI,
EndpointPath,
{"nomeUsuario", "dataInicio", "situacao", "tipoUsuario", "email", "telefone", "id"},
{"NomeUsuario", "DataInicio", "Situacao", "TipoUsuario", "Email", "Telefone", "Id"}
),
// --- 3) Remove possíveis duplicidades pelo Id ---------------------------
UsuariosUnicos = Table.Distinct(UsuariosExpandido, {"Id"}),
// --- 4) Ajusta tipos de dados -------------------------------------------
TiposConvertidos =
Table.TransformColumnTypes(
UsuariosUnicos,
{
{"NomeUsuario", type text},
{"DataInicio", type datetime},
{"Situacao", type logical},
{"TipoUsuario", type text},
{"Email", type text},
{"Telefone", type any},
{"Id", Int64.Type}
}
),
// --- 5) Cria coluna Data (apenas a parte da data) -----------------------
UsuariosComData =
Table.AddColumn(
TiposConvertidos,
"Data",
each DateTime.Date([DataInicio]),
type date
)
in
UsuariosComDataCarregue Somente Colunas Necessárias
Remova colunas que não serão usadas em visuais, relacionamentos ou cálculos. Menos colunas = modelo menor, refresh mais rápido e lista de campos limpa.
Table.SelectColumns(Source, {"Pedido", "Cliente", "Valor"})Referências: Optimize column load
Renomeie Colunas com Nomes de Negócio
Converta siglas técnicas (cust_id) em termos claros (Cliente ID) e mantenha idioma consistente. Isso melhora legibilidade, uso de IA e entendimento pelos usuários.
Faça isso somente na última etapa da consulta.
Referências: Rename columns
Nomenclatura de Tabelas
Use prefixos para tipo de tabela
Uma prática comum é prefixar o nome das tabelas de acordo com seu papel no modelo. Por exemplo, usar f_ (de fact) no início de tabelas de fato (transacionais, geralmente valores numéricos acumuláveis) e d_ (de dimension) em tabelas dimensionais (categorização, informações descritivas). Ex.: f_Vendas, d_Produto, d_Calendario.
Nomes descritivos e sem espaços
Evite espaços ou caracteres especiais nos nomes de tabela. Use _ (underline) se precisar separar palavras, ou CamelCase/PascalCase. Por exemplo, em vez de "Tabela Vendas 2023", use f_Vendas2023 ou f_Vendas_2023.
Exemplo de padronização
Considere um modelo simples de vendas: poderíamos ter as tabelas d_Calendario, d_Cliente, d_Produto e f_Vendas. Sem espaços e com prefixos, fica claro. Outro exemplo, para dados financeiros: d_ContaContabil, d_CentroCusto e f_Lancamentos.
Data de atualização do relatório
Exibir a data e hora da última atualização no seu dashboard traz mais transparência e confiança para quem consome o relatório. Usuários têm clareza sobre quão frescas estão as informações, evitam decisões baseadas em dados defasados e facilitam o diagnóstico de falhas de agendamento ou inconsistências entre ambientes (Desktop × Serviço).
let
// Parâmetros
UTCOffsetHoras = -3, // ajuste de fuso (ex.: Brasília = UTC-3)
ETLOffsetHoras = -6, // atraso/adiantamento para refletir janelas de ETL
// 1. Captura o timestamp em UTC
HoraUTC = DateTimeZone.FixedUtcNow(),
// 2. Converte para o fuso desejado
HoraComFuso = DateTimeZone.SwitchZone(HoraUTC, UTCOffsetHoras),
// 3. Remove o componente de fuso para obter um DateTime puro
HoraSemZona = DateTimeZone.RemoveZone(HoraComFuso),
// 4. Aplica o offset de ETL
HoraFinal = HoraSemZona + #duration(0, ETLOffsetHoras, 0, 0),
// 5. Gera uma tabela de uma linha só, com a coluna “AtualizadoEm”
Fonte = #table(
{"AtualizadoEm"},
{ { HoraFinal } }
),
// 6. Define o tipo correto da coluna
FonteTyped = Table.TransformColumnTypes(
Fonte,
{ {"AtualizadoEm", type datetime} }
)
in
FonteTyped Como funciona
FixedUtcNow()garante que o serviço e o Desktop usam o mesmo relógio.
SwitchZone+RemoveZoneajustam o fuso sem perder rastreabilidade.
#durationcomETLOffsetHorasatrasa ou adianta o timestamp conforme suas janelas de dataflows dependentes.
- O resultado é uma tabela de uma linha.
Exibição no dashboard
- Medida DAX Para apresentar esse campo em um Card ou Card visual, crie uma medida que capture o valor da única linha, por exemplo:
Data/Hora de atualização = SELECTEDVALUE('MetaRefresh'[AtualizadoEm])
- Formatação No visual, escolha o formato de data e hora que faça sentido para seus usuários (por ex.
dd/MM/yyyy HH:mm) e posicione o cartão em um local visível, como rodapé ou canto superior.
Com essa abordagem, você garante que a hora exibida seja coerente, seguível e personalizável de acordo com as janelas de ETL — mantendo seu relatório profissional e confiável.
Com essas práticas de ETL, suas consultas serão mais organizadas, documentadas e otimizadas. Isso estabelece uma base sólida para a próxima etapa: a Modelagem de Dados.
Modelagem de Dados
A modelagem é o coração do projeto Power BI. É onde estruturamos as tabelas importadas, definimos relações entre elas e preparamos o terreno para cálculos DAX eficientes. Seguir um esquema estrela, configurar corretamente os relacionamentos e evitar armadilhas como excesso de colunas calculadas no modelo garante que o desempenho e a usabilidade do relatório sejam os melhores possíveis. Vamos às guidelines de modelagem:
Esquema Estrela
Exemplo de modelo de dados com esquema em estrela (tabela fato "Sales" conectada a quatro dimensões: Date, Product, State, Region). As setas indicam relações de 1 (um) para * (muitos), das dimensões filtrando a fato
Referências: Designing star schemas
Relacionamentos
- Direção do filtro (Cross-filter direction): Por padrão, use relacionamentos unidirecionais (Single) filtrando do lado "um" para o lado "muitos".
- Evite relacionamentos muitos-para-muitos diretos: Se encontrar necessidade de relacionar duas tabelas em uma cardinalidade : (muitos-para-muitos) – algo que o Power BI até suporta nativamente – reavalie o design.
- Relações ativas vs. inativas: O Power BI permite marcar apenas um relacionamento ativo entre duas tabelas por vez (caso haja mais de um caminho possível - como por exemplo Data de Entrega e Data de Pagamento - para alterar o comportacamento da pra usar CALCULATE + USERELATIONSHIP).
Evitar Colunas Calculadas em DAX
- Prefira colunas calculadas no Power Query (M) ou fonte de dados: Uma coluna calculada DAX é criada dentro do modelo Power BI, após a carga dos dados.
- Impacto no processamento e memória: Quando você adiciona N colunas calculadas no modelo, o processo de refresh precisa recalcular todas elas sempre que os dados são atualizados.
- Exceções – quando usar colunas calculadas: Há casos em que uma coluna calculada é justificável ou mesmo necessária.
Desative data/hora automática
No Power BI Desktop, a opção "Data/Hora Automática" (ou "Auto Date/Time" em inglês) pode parecer útil, mas geralmente é melhor desativá-la.
📌 Por que remover Data/Hora Automática?
- Cria tabelas ocultas desnecessárias
- Para cada campo de data no modelo, o Power BI cria automaticamente uma tabela de calendário oculta.
- Isso polui o modelo e pode impactar a performance, especialmente com muitos campos de data.
- Falta de controle
- Essas tabelas automáticas são geradas nos bastidores, então você não consegue editar, personalizar ou reutilizar facilmente.
- Dificulta a modelagem de tempo centralizada
- O ideal é criar uma única tabela calendário personalizada (ex: d_Calendario), com todos os atributos que você precisa (Ano, Mês, Trimestre, etc.).
- Isso garante consistência e governança no modelo.
✅ O que fazer no lugar?
- Desative nas opções globais e do arquivo atual:
- Arquivo > Opções e configurações > Opções > "Data/Hora Automática" (desmarque as duas opções).
- Crie uma tabela calendário em DAX e marque como "Date Table".
Tabela calendário
Ao criar sua tabela calendário, você pode optar por DAX ou pelo Power Query (M). Cada abordagem tem pontos fortes: DAX simplifica a manutenibilidade diretamente no modelo e ajusta automaticamente o intervalo conforme seus dados, enquanto M oferece mais flexibilidade no ETL e permite pré-processar colunas antes de carregar no modelo.
Além disso, criar a tabela em M ajuda a padronizar e replicar o mesmo processo em vários relatórios—uma vantagem para governança e consistência—mas pode se tornar pouco ágil quando são necessárias pequenas adaptações específicas.
Pessoalmente, costumo escolher DAX para facilitar atualizações e ajustes rápidos sem reprocessar toda a consulta. Mas não há nada de errado em usar M quando você precisar de transformações mais complexas antes do carregamento.
Tabela Calendário via DAX
A
d_Calendario é a tabela de datas principal do modelo, criada com CALENDAR + ADDCOLUMNS, cobrindo um período contínuo e completo com colunas úteis como Ano, Mês, Trimestre, Dia da Semana e chaves de ordenação.Ela substitui o uso do
CALENDARAUTO, oferecendo mais controle, previsibilidade e performance, além de estar pronta para ser marcada como Date Table. Isso garante:- Maior precisão nas análises temporais
- Ordenação correta nos visuais
- Integração com funções de inteligência de tempo (YTD, MTD etc.)
- Estrutura limpa, reutilizável e fácil de manter
É a base ideal para qualquer modelo com análise temporal no Power BI.
d_Calendario =
VAR _datamin = MIN( TabelaFato[colunaData] ) //substituir pela coluna de data da tabela fato principal
VAR _datamax = MAX( TabelaFato[colunaData] ) //substituir pela coluna de data da tabela fato principal
VAR _start = DATE( YEAR( _datamin ), 1, 1 )
VAR _end = DATE( YEAR( _datamax ), 12, 31 )
VAR _calendar = CALENDAR( _start, _end )
VAR _add = ADDCOLUMNS( _calendar ,
"Ano", DATE(YEAR([Date]), 1 , 1 ),
"Ano Número", YEAR([Date]) ,
"Mês Texto", FORMAT([Date],"mmm-yy"),
"Class-Mes", YEAR([Date])*100 + MONTH([Date]),
"Mês", EOMONTH([Date], -1) + 1,
"Semestre", IF(MONTH([Date]) <= 6, DATE(YEAR([Date]), 1, 1), DATE(YEAR([Date]), 7, 1)),
"Trimestre", DATE(YEAR([Date]), ((QUARTER([Date]) - 1) * 3) + 1, 1),
"Dia da Semana" , WEEKDAY([Date]),
"Dia da Semana Texto" ,
SWITCH(
WEEKDAY([Date]),
1, "Domingo",
2, "Segunda",
3, "Terça",
4, "Quarta",
5, "Quinta",
6, "Sexta",
7, "Sábado",
BLANK()
),
"Dia Número", DAY([Date])
)
RETURN
_addCriar a tabela calendário diretamente em DAX traz benefícios práticos em comparação ao Power Query, embora não seja errado fazer no Power Query (nem perto disso).
Primeiro, você não precisa sair do Power BI Desktop ou abrir o Editor avançado – basta colar a expressão DAX e a tabela já aparece no modelo. Além disso, o intervalo de datas se ajusta de forma automática conforme as datas da sua tabela fato, sem escrever etapas extras em M.
Quando for necessário incluir ou alterar colunas, você faz isso com poucos cliques no próprio modelo, sem reprocessar toda a consulta.
E, por fim, o mecanismo VertiPaq comprime essas tabelas calculadas ao final do processamento, garantindo uso de memória otimizado e performance estável.
Tabela Calendário Especial
A
d_Calendario_Especial é uma dimensão de datas “auxiliar”, criada para complementar a d_Calendario principal. Enquanto a d_Calendario garante granularidade diária e colunas clássicas (Ano, Mês, Trimestre etc.), a d_Calendario_Especial agrupa essas mesmas datas em períodos relativos prontos para uso – como “Hoje”, “Últimos 30 Dias”, “Mês Anterior”, “Ano até Agora (YTD)” e “Últimos 12 Meses”.Essa tabela tem três papéis centrais:
- Filtro dinâmico e simultâneo de vários períodos Como cada linha traz a data e, ao lado, uma coluna
Periodidentificando a qual janela ela pertence, você pode:
- Criar slicers de período (com
PeriodouSigla) e deixá-los multi-selecionáveis – permitindo comparar, por exemplo, YTD x PY1 ou “Mês Atual” x “Mês Anterior” sem escrever nenhuma medida adicional.
- Empilhar comparações relativas em visuais, mantendo apenas uma relação bidirecional 1:N com a
d_Calendario.
- Simplificação de medidas de tempo Em vez de usar funções time-intelligence (que geralmente exigem uma única seleção de período ou medidas diferentes para cada janela), basta filtrar pela
d_Calendario_Especial; sua medida de vendas, receita ou KPIs já calculará o subtotal correto porque a tabela carrega todas as datas correspondentes ao período escolhido.
- Atualização automática e consistente Os períodos são calculados a partir de
TODAY(), garantindo que “Últimos 7 Dias” ou “Ano até Agora” mudem diariamente sem manutenção manual. Como os limites (start/end) são sincronizados com ad_Calendario, todos os dias do modelo permanecem cobertos e coerentes.
Em resumo: ad_Calendario_Especialcoloca na mão do analista um painel de filtros prontos, tornando análises comparativas e rolling windows muito mais rápidas, legíveis e fáceis de manter – especialmente quando diferentes usuários precisam ver várias janelas de tempo lado a lado no mesmo relatório.
d_Calendario_Especial =
VAR _incio = MIN(d_Calendario[Date])
VAR _fim = MAX(d_Calendario[Date] )
VAR _datetable = CALENDAR ( _incio, _fim )
VAR _today = TODAY()
VAR _month = MONTH(_today)
VAR _day = day(_today)
VAR _year = YEAR(_today)
VAR _lastyear1 = YEAR(_today)-1
VAR _lastyear2 = YEAR(_today)-2
VAR _thismonthstart = DATE(_year,_month,1)
VAR _thismonthend = EOMONTH(DATE(_year, _month, 1),0)
VAR _thisyearstart = DATE(_year,1,1)
VAR _thisyearend = DATE(_year,12,31)
VAR _lastyearstart1= DATE(_lastyear1,1,1)
VAR _lastyearend1= DATE(_lastyear1,12,31)
VAR _lastyearstart2= DATE(_lastyear2,1,1)
VAR _lastyearend2= DATE(_lastyear2,12,31)
VAR _lastmonthstart = EDATE(_thismonthstart,-1)
VAR _lastmonthend = _thismonthstart-1
VAR _thisquarterstart = DATE(YEAR(_today),SWITCH(true,_month>9,10,_month>6,7,_month>3,4,1),1)
VAR _last12month = EDATE(_thismonthstart,-12)
RETURN
UNION(
ADDCOLUMNS(FILTER(_datetable,[Date] >= _today ),"Period","Hoje", "Sigla", "HJ" ,"Order",1),
ADDCOLUMNS(FILTER(_datetable,[Date] >= _today -1 ),"Period","Ontem", "Sigla", "LD1" ,"Order",2),
ADDCOLUMNS(FILTER(_datetable,[Date] >= _today -7 && [Date] <= _today ),"Period","Últimos 7 Dias", "Sigla", "LD7" ,"Order",3),
ADDCOLUMNS(FILTER(_datetable,[Date] >= _today -15 && [Date] <= _today ),"Period","Últimos 15 Dias", "Sigla", "LD15" ,"Order",4),
ADDCOLUMNS(FILTER(_datetable,[Date] >= _today -30 && [Date] <= _today ),"Period","Últimos 30 Dias", "Sigla", "LD30" ,"Order",5),
ADDCOLUMNS(FILTER(_datetable,[Date] >= _today -60 && [Date] <= _today ),"Period","Últimos 60 Dias", "Sigla", "LD60" ,"Order",6),
ADDCOLUMNS(FILTER(_datetable,[Date] >= _today -90 && [Date] <= _today ),"Period","Últimos 90 Dias", "Sigla", "LD90" ,"Order",7),
ADDCOLUMNS(FILTER(_datetable,[Date] >= _today -180 && [Date] <= _today ),"Period","Últimos 180 Dias", "Sigla", "LD180" ,"Order",8),
ADDCOLUMNS(FILTER(_datetable,[Date] >= _today -360 && [Date] <= _today ),"Period","Últimos 360 Dias", "Sigla", "LD360" ,"Order",9),
ADDCOLUMNS(FILTER(_datetable,[Date]>= _lastmonthstart && [Date] <= _lastmonthend ),"Period","Mês Anterior", "Sigla", "LM" ,"Order",1),
ADDCOLUMNS(FILTER(_datetable,[Date]>= _lastmonthstart && [Date] <= _lastmonthend ),"Period","Mês Anterior", "Sigla", "LM" ,"Order",1),
ADDCOLUMNS(FILTER(_datetable,[Date]>= _thismonthstart && [Date] <= _thismonthend ),"Period","Mês Atual", "Sigla", "CM", "Order",2),
ADDCOLUMNS(FILTER(_datetable,[Date]>= _thisyearstart && [Date] <= _thismonthend ) ,"Period","Ano até Agora", "Sigla", "YTD", "Order",3),
ADDCOLUMNS(FILTER(_datetable,[Date]>= _thisyearstart && [Date]<= _thisyearend ),"Period","Ano até Final", "Sigla","FY", "Order",4),
ADDCOLUMNS(FILTER(_datetable,[Date]>= _last12month && [Date] <= _thismonthend ) ,"Period","Últimos 12 meses", "Sigla","LM12", "Order",5),
ADDCOLUMNS(FILTER(_datetable,[Date]>= _lastyearstart1 && [Date] <= _lastyearend1),"Period","Ano Anterior 1", "Sigla","PY1", "Order",6),
ADDCOLUMNS(FILTER(_datetable,[Date]>= _lastyearstart2 && [Date] <= _lastyearend2),"Period","Ano Anterior 2", "Sigla", "PY2", "Order",7),
ADDCOLUMNS(_datetable, "Period", "Todos", "Sigla","TDS" , "Order", 10)
)Cálculos, Análises e Fórmulas DAX
Nesta seção abordamos boas práticas ao criar medidas, métricas e outras fórmulas DAX no Power BI. Escrever DAX de forma consistente e eficiente é crucial para obter resultados corretos e facilitar a manutenção por você ou outros desenvolvedores. Também trataremos de recursos avançados como grupos de cálculo e parâmetros de campo, que ajudam a organizar e simplificar análises complexas.
Convenção de Nomes para medidas DAX
Com os avanços recentes em IA generativa, já é possível plugar o modelo semântico do Power BI diretamente em LLMs como o ChatGPT. Dessa forma, o usuário faz perguntas em linguagem natural (“Como está a margem bruta deste trimestre?”) e o assistente transforma a frase em consultas DAX.
Esse fluxo só funciona bem quando as medidas e colunas seguem uma convenção de nomes que seja clara para o negócio. Caso contrário, o LLM aposta — e às vezes erra — ao mapear termos ambíguos (“MVL”, “Calc01”, “tbl_Sales”) para a métrica correta. Resultado: respostas imprecisas e desconfiança no dashboard.
Para evitar esse gargalo, adote as regras abaixo e torne o seu modelo legível tanto para analistas quanto para a IA.
- Clareza no nome
- Formato recomendado:
Verbo + Objeto ou Métrica (Contexto)
- Evite nomes “de programador” ou siglas de banco/SQL.
- Exemplos bons:
Total Vendas
Qtd Clientes Únicos
Ticket Médio (Mês)
- Termos de negócio
- Use a linguagem que o usuário final reconhece no dia a dia.
- Evite IT jargon e sufixos de código, p.ex.
SomaAcumulada_Vendas,VariacaoMensal_YoY.
- Prefira
Total Vendasem vez deTotalVendas.
- Contextualização explícita
- Coloque variações temporais ou filtros principais entre parênteses.
- Exemplos:
Vendas Acumuladas (Ano)
Margem Bruta (%)
Qtd Leads (Segmento Enterprise)
- Prefixo para medidas de apoio
- Inicie com
(Aux)tudo que serve de cálculo intermediário e não deve aparecer em visuais.
- Exemplos:
(Aux) Cor Dinâmica Venda Líquida
(Aux) Fator de Conversão
Seguindo esses pilares, o modelo permanece fácil de navegar, reduz os erros de interpretação por IA e acelera tanto o debug quanto a evolução do relatório.
Criar a tabela de medidas e usar pastas
- À medida que o número de medidas cresce, pode ficar confuso encontrá-las se elas estiverem misturadas em várias tabelas e é interessante centralizar as medidas em tabelas dedicadas
- Outra funcionalidade útil são as pastas de medidas. No editor de modelo, você pode atribuir às medidas (e também colunas, hierarquias) um "Nome da Pasta de Exibição".
- Use \ para criar subpastas
Escrita DAX
- Ao escrever medidas DAX não tenha receio de usar variáveis (VAR). Elas ajudam a quebrar a lógica em partes nomeadas, melhorando tanto a performance quanto a legibilidade.
Lucro % =
VAR _Vendas = [Total Vendas]
VAR _Custos = [Total Custos]
VAR _return = DIVIDE(_Vendas - _Custos, _Vendas)
RETURN _returnAtenção ao comportamento de variáveis: Variáveis DAX
- O DAX permite comentários de linha usando // ou comentários de múltiplas linhas entre /* ... */. Faça uso disso em medidas complexas ou de lógica menos óbvia.
// Calcula clientes ativos (aqueles sem data de cancelamento até hoje)
Clientes Ativos =
CALCULATE(
DISTINCTCOUNT(Clientes[ClienteID]);
FILTER(Clientes; Clientes[DataCancelamento] = BLANK() || Clientes[DataCancelamento] > TODAY())
)Crie cálculos uma vez, use em várias medidas
- Os Grupos de Cálculo agilizam a modelagem ao reunir em um único objeto lógicas que, de outra forma, teriam de ser replicadas em diversas medidas, eliminando redundâncias e facilitando a manutenção centralizada. Com eles você define itens de cálculo — como variações de período ou formatações dinâmicas — apenas uma vez e aplica a qualquer medida existente, garantindo consistência em todo o relatório. Além disso, esse padrão reduz a complexidade do modelo e acelera tanto o desenvolvimento quanto a atualização de novos cenários, mantendo a performance e a clareza do seu projeto em Power BI
- Avalie usar Calculation Groups quando notar um "padrão" repetitivo de medidas no seu modelo. Time intelligence é o caso mais evidente (vários KPIs querendo versões MTD, YTD, YOY).
Referência: Grupos de Cálculo
Permita o usuário escolher o que analisar
- Os Parâmetros de Campo são um recurso que permite ao usuário final trocar dinamicamente dimensões ou medidas em um visual através de seleções em um slicer. Em vez de usar múltiplas páginas ou bookmarks para oferecer diferentes cortes de análise, você pode usar um parâmetro de campo e um slicer para que o usuário escolha, por exemplo, qual métrica mostrar em um gráfico ou qual categoria usar no eixo X.
- Para criar, vá em Modelagem > Novo parâmetro > Campos.
- Use o nome da tabela criada p_ para permitir ao usuário alternar medidas ou dimensões via slicer, economizando páginas e visuais.
Referências: Field parameters