Modelagem de dados do Power BI: design de esquema em estrela para Business Intelligence

O modelo de dados é a base de todo relatório do Power BI. Um modelo bem projetado torna as medidas DAX simples, o desempenho das consultas é rápido e o desenvolvimento de relatórios é intuitivo. Um modelo mal projetado torna tudo difícil: as medidas exigem soluções alternativas complicadas, as consultas são executadas lentamente e os desenvolvedores passam mais tempo lutando contra o modelo do que criando insights.

O esquema em estrela é o padrão ouro para modelos de dados analíticos e tem sido assim há décadas. Os bancos de dados relacionais que alimentam seus sistemas ERP e CRM são projetados para eficiência transacional usando esquemas normalizados com dezenas de tabelas interconectadas. Esse design é ideal para registrar transações individuais, mas péssimo para agregação, comparação e análise de tendências. O esquema estrela reestrutura os mesmos dados para desempenho analítico, separando-os em tabelas de fatos (o que aconteceu) e tabelas de dimensões (o contexto em torno do que aconteceu).

Este guia aborda princípios de design de esquema em estrela especificamente para Power BI, incluindo como criar tabelas de fatos e dimensões, configurar relacionamentos, escrever medidas DAX eficientes, aproveitar grupos de cálculo, implementar inteligência de tempo e usar modelos compostos para conectar-se a várias fontes de dados.

Principais conclusões

• O esquema estrela separa os dados em tabelas de fatos (medidas numéricas, chaves estrangeiras) e tabelas de dimensões (atributos descritivos) --- esta estrutura é otimizada para o mecanismo VertiPaq do Power BI
• Cada relacionamento em um modelo do Power BI deve fluir de dimensão para fato (um para muitos), com filtragem cruzada em apenas uma direção
• As medidas DAX têm um desempenho muito melhor em esquemas em estrela porque o VertiPaq pode compactar colunas de dimensão com eficiência e filtrar fatos por meio de relacionamentos
• Os grupos de cálculo substituem dezenas de medidas redundantes (acumulado no ano, trimestre trimestral, MTD, ano anterior) por um único padrão aplicado a todas as medidas básicas
• A inteligência temporal requer uma tabela de dimensão de data dedicada --- nunca use data/hora automática ou confie em colunas de data em tabelas de fatos
• Os modelos compostos permitem combinar dados importados com conexões DirectQuery, proporcionando o desempenho na memória com a atualização das consultas em tempo real
• Dimensões de role-playing (uma tabela usada em múltiplas funções de relacionamento) requerem a função USERELATIONSHIP do DAX

---

Fundamentos do esquema em estrela

Por que o esquema Star para Power BI

O mecanismo na memória do Power BI, VertiPaq, usa compactação colunar para armazenar dados. Ele compacta cada coluna de forma independente, e colunas com baixa cardinalidade (poucos valores exclusivos) são compactadas drasticamente --- uma coluna "País" com 40 valores exclusivos em 10 milhões de linhas é compactada para quase nada. Colunas com alta cardinalidade (muitos valores exclusivos), como IDs de transação ou carimbos de data/hora, são pouco compactadas.

O esquema estrela explora isso isolando dados transacionais de alta cardinalidade (datas, valores, quantidades) em tabelas de fatos estreitas e colocando dados descritivos de baixa cardinalidade (nomes, categorias, regiões) em tabelas de dimensões separadas. O resultado é um modelo de dados com menos memória e mais rápido de consultar.

Considere a diferença. Uma tabela plana desnormalizada para uma empresa de varejo pode ter 50 colunas: OrderDate, CustomerName, CustomerEmail, CustomerCity, CustomerCountry, CustomerSegment, ProductName, ProductCategory, ProductSubcategory, Brand, Supplier, SupplierCountry, Quantidade, UnitPrice, Discount, TotalAmount e assim por diante. Cada linha repete “Estados Unidos” milhares de vezes, “Eletrônicos” centenas de vezes e o nome completo do cliente para cada pedido que o cliente já fez.

O esquema em estrela equivalente separa isso em:

FactSales (estreito, uma linha por linha de pedido): OrderDateKey, CustomerKey, ProductKey, Quantidade, UnitPrice, Desconto, TotalAmount.

DimCustomer: CustomerKey, CustomerName, Email, Cidade, País, Segmento.

DimProduct: ProductKey, ProductName, Categoria, Subcategoria, Marca.

DimDate: DateKey, Data, Ano, Trimestre, Mês, MonthName, DayOfWeek.

A tabela de fatos possui apenas 7 colunas em vez de 50. Cada tabela de dimensão armazena cada valor exclusivo exatamente uma vez. O VertiPaq compacta essa estrutura de 3 a 5 vezes melhor do que a tabela plana, e as consultas são executadas de 2 a 10 vezes mais rápido porque o mecanismo filtra tabelas de pequenas dimensões e, em seguida, resolve apenas as linhas correspondentes na tabela de fatos.

Tabelas de fatos: princípios de design

As tabelas de fatos registram eventos de negócios --- vendas, pedidos, remessas, tickets de suporte, visitas à web, execuções de fabricação. Cada linha representa um evento ou um item de linha de um evento.

Definição de granulação. A granulação é o nível de detalhe na tabela de fatos. Defina-o com precisão e aplique-o de forma consistente. Uma tabela de fatos de vendas pode ter uma granularidade de "uma linha por item de linha do pedido" ou "uma linha por resumo diário de vendas de produtos". Misturar grãos em uma única tabela de fatos (algumas linhas são transações individuais, outras são agregações diárias) cria erros de cálculo que são extremamente difíceis de depurar.

Somente chaves estrangeiras. A tabela de fatos contém chaves estrangeiras para tabelas de dimensão, e não atributos descritivos. Uma tabela de fatos não deve conter "CustomerName" ou "ProductCategory" --- eles pertencem às tabelas de dimensões. A tabela de fatos possui CustomerKey e ProductKey, que vinculam às dimensões onde residem os detalhes descritivos.

Medidas aditivas. As colunas numéricas em uma tabela de fatos devem ser aditivas --- valores que podem ser somados de forma significativa em qualquer dimensão. Receita, quantidade, custo e desconto são aditivos. Percentagens, proporções e preços unitários não são aditivos (não é possível somar os preços unitários dos produtos). Armazene os componentes (numerador e denominador) na tabela de fatos e calcule a proporção em uma medida DAX.

Evite colunas calculadas em fatos. Adicionar colunas calculadas a uma tabela de fatos aumenta o consumo de memória da tabela e aumenta o tempo de processamento durante a atualização. Em vez disso, calcule valores derivados em medidas DAX, que são computadas no momento da consulta e não consomem armazenamento.

Tabelas de dimensões: princípios de design

As tabelas de dimensões descrevem "quem, o quê, onde, quando, por quê" dos eventos de negócios. Eles contêm os atributos que os usuários filtram, agrupam e dividem.

Chaves substitutas. Use chaves substitutas inteiras (CustomerKey, ProductKey) como chave primária em tabelas de dimensões, não chaves naturais (e-mail do cliente, SKU do produto). As chaves substitutas são menores, compactam melhor e isolam o modelo de alterações nas chaves do sistema de origem.

Desnormalizar dimensões. Em um esquema em estrela, as tabelas de dimensões são desnormalizadas deliberadamente. Uma tabela DimProduct inclui Categoria, Subcategoria e Marca como colunas na mesma tabela, e não como tabelas normalizadas separadas com suas próprias chaves. Isto é o oposto do design de banco de dados transacional e é intencional. Dimensões desnormalizadas produzem consultas mais rápidas e DAX mais simples porque o mecanismo VertiPaq verifica uma única tabela em vez de unir várias tabelas.

Inclua hierarquias descritivas. Se os usuários fizerem uma busca detalhada de categoria para subcategoria e produto, todos os três níveis deverão ser colunas em DimProduct. Crie um objeto de hierarquia no modelo do Power BI que defina esse caminho de detalhamento.

Dimensões mudando lentamente. Quando os atributos de dimensão mudam ao longo do tempo (um cliente muda de cidade, um produto muda de categoria), você precisa de uma estratégia. O tipo 1 (sobrescrever) é mais simples --- atualize a linha da dimensão com o novo valor. O tipo 2 (adicionar nova linha) preserva o histórico --- adiciona uma nova linha com um intervalo de datas efetivo, para que as transações históricas sejam associadas aos valores de atributos que eram atuais no momento. O tipo 2 é mais complexo, mas necessário quando a precisão histórica é importante (auditorias financeiras, relatórios regulamentares).

---

Configurando relacionamentos

Regras de Relacionamento para Power BI

Os relacionamentos do Power BI definem como as tabelas se conectam e como os filtros se propagam. Acertar os relacionamentos é fundamental – relacionamentos incorretos produzem números errados silenciosamente, o que é pior do que produzir erros.

Somente um para muitos. Cada relacionamento em um esquema em estrela conecta uma tabela de dimensões (um lado) a uma tabela de fatos (muitos lados). A tabela de dimensões possui valores exclusivos na coluna chave. A tabela de fatos possui valores repetidos. O Power BI valida isso e sinaliza violações. Se o Power BI detectar uma relação muitos para muitos, você terá um problema de modelagem para corrigir.

Filtragem cruzada de direção única. Defina a direção do filtro cruzado como "Single" em todos os relacionamentos. Isso significa que os filtros fluem da dimensão para o fato (quando você seleciona um cliente em uma segmentação de dados, somente as linhas desse cliente aparecem nos visuais da tabela de fatos), mas não do fato de volta para a dimensão. A filtragem bidirecional cria caminhos de filtro ambíguos em modelos com diversas tabelas de fatos e deve ser evitada, exceto em cenários muito específicos.

Relacionamentos ativos versus inativos. O Power BI permite apenas um relacionamento ativo entre duas tabelas quaisquer. Se uma tabela de fatos tiver diversas colunas de data (OrderDate, ShipDate, DeliveryDate), crie um relacionamento ativo (geralmente OrderDate a DimDate) e relacionamentos inativos para os outros. Use a função USERELATIONSHIP em medidas DAX para ativar o relacionamento inativo quando necessário:

Shipped Revenue =
CALCULATE(
    [Total Revenue],
    USERELATIONSHIP(FactSales[ShipDateKey], DimDate[DateKey])
)

Dimensões de RPG

Uma dimensão de role-playing é uma tabela de dimensão única que atende a diversas funções no modelo. A dimensão de data é o exemplo mais comum – ela se conecta a OrderDate, ShipDate e DeliveryDate na tabela de fatos, desempenhando um “papel” diferente em cada relacionamento.

No Power BI, você pode lidar com dimensões de representação de duas maneiras:

Relacionamentos inativos + USERELATIONSHIP (recomendado). Mantenha uma única tabela DimDate com um relacionamento ativo (para OrderDate) e relacionamentos inativos para as outras colunas de data. Crie medidas que utilizem USERELATIONSHIP para as perspectivas de datas alternativas. Isso mantém o modelo compacto e evita a duplicação de dados.

Tabelas de dimensões duplicadas. Crie cópias separadas de DimDate (DimOrderDate, DimShipDate, DimDeliveryDate), cada uma com um relacionamento ativo com sua respectiva coluna de fatos. Esta abordagem é mais simples do ponto de vista DAX (sem necessidade de USERELATIONSHIP), mas aumenta o tamanho do modelo e a carga de manutenção.

Para a maioria das implementações, a abordagem de relacionamento inativo é preferida. Ele produz um modelo mais limpo e menor consumo de memória ao custo de um DAX um pouco mais detalhado.

Relacionamentos muitos-para-muitos

Alguns cenários de negócios exigem genuinamente relacionamentos muitos-para-muitos. Um cliente pode pertencer a múltiplos segmentos, um produto pode estar em múltiplas campanhas promocionais, um vendedor pode abranger múltiplos territórios. O esquema em estrela lida com isso por meio de tabelas de ponte.

Uma tabela ponte fica entre as duas tabelas em um relacionamento muitos para muitos e contém uma linha para cada combinação:

BridgeCustomerSegment: CustomerKey, SegmentKey

DimCustomer se conecta a BridgeCustomerSegment (um para muitos em CustomerKey). DimSegment se conecta a BridgeCustomerSegment (um para muitos em SegmentKey). A tabela ponte permite filtrar FactSales por segmento enquanto lida corretamente com clientes em vários segmentos.

Seja cauteloso com tabelas bridge – elas podem produzir contagem dupla se não forem combinadas com medidas DAX apropriadas que lidam com a alocação muitos-para-muitos. Teste exaustivamente com dados conhecidos para validar se os totais estão corretos.

---

Medidas DAX: Padrões e Desempenho

Medidas Básicas

Todo modelo analítico precisa de um conjunto de medidas básicas que realizem agregações simples nas colunas da tabela de fatos. Defina-os primeiro – eles servem como blocos de construção para cálculos mais complexos.

Total Revenue = SUM(FactSales[TotalAmount])
Total Quantity = SUM(FactSales[Quantity])
Total Cost = SUM(FactSales[CostAmount])
Order Count = COUNTROWS(FactSales)
Average Order Value = DIVIDE([Total Revenue], [Order Count])
Gross Margin = DIVIDE([Total Revenue] - [Total Cost], [Total Revenue])

Observe que o Valor Médio do Pedido e a Margem Bruta fazem referência a outras medidas em vez de repetir a lógica de agregação. Isto é deliberado --- se a definição de Receita Total for alterada (por exemplo, para excluir devoluções), as medidas posteriores refletirão automaticamente a mudança.

CALCULAR: O Núcleo do DAX

CALCULATE é a função DAX mais importante. Avalia uma expressão em um contexto de filtro modificado. Compreender CALCULATE é compreender DAX.

Revenue Last Year =
CALCULATE(
    [Total Revenue],
    SAMEPERIODLASTYEAR(DimDate[Date])
)

Esta medida pega a medida Receita Total e a avalia em um contexto de filtro onde o intervalo de datas é retrocedido em um ano. Se o contexto de filtro atual for “Janeiro de 2026”, CALCULATE o modificará para “Janeiro de 2025” e avaliará a Receita Total nesse contexto modificado.

CALCULATE aceita vários argumentos de filtro e eles interagem de maneira diferente dependendo do tipo:

Filtros de tabela (como SAMEPERIODLASTYEAR) substituem o filtro existente nas colunas dessa tabela. Se o visual já tiver um filtro de mês, SAMEPERIODLASTYEAR o substituirá pelo mês correspondente do ano anterior.

Filtros booleanos (como DimProduct[Category] = "Electronics") são adicionados ao contexto existente. Se o visual for filtrado para 2026, o resultado CALCULATE mostrará a receita de eletrônicos de 2026.

REMOVEFILTERS limpa os filtros existentes. CALCULATE([Total Revenue], REMOVEFILTERS(DimProduct[Category])) retorna a receita total em todas as categorias, independentemente de quais filtros de categoria estão ativos.

Variáveis para legibilidade e desempenho

Variáveis ​​(VAR) calculam um valor uma vez e fazem referência a ele várias vezes. Eles tornam medidas complexas legíveis e eliminam cálculos redundantes:

Revenue YoY Growth =
VAR CurrentRevenue = [Total Revenue]
VAR PriorRevenue = [Revenue Last Year]
VAR Growth = CurrentRevenue - PriorRevenue
VAR GrowthPct = DIVIDE(Growth, PriorRevenue)
RETURN
    GrowthPct

Sem variáveis, esta medida calcularia [Receita Total] e [Receita do Ano Passado] múltiplas vezes (uma vez para a subtração, uma vez para a divisão), duplicando o custo de cálculo. As variáveis ​​garantem que cada uma seja calculada exatamente uma vez.

Funções do iterador: quando usá-las

As funções iteradoras (SUMX, AVERAGEX, MAXX, MINX, COUNTX, RANKX) avaliam uma expressão linha por linha em uma tabela. Eles são poderosos, mas caros – eles verificam todas as linhas da tabela especificada.

Use iteradores quando precisar de cálculos em nível de linha antes da agregação:

Weighted Average Price =
DIVIDE(
    SUMX(FactSales, FactSales[Quantity] * FactSales[UnitPrice]),
    SUM(FactSales[Quantity])
)

Isso não pode ser alcançado com SUM simples porque você precisa multiplicar Quantidade por UnitPrice em cada linha antes de somar. O iterador SUMX lida com essa multiplicação linha por linha.

Evite iteradores quando uma agregação simples for suficiente. SUMX(FactSales, FactSales[TotalAmount]) é funcionalmente equivalente a SUM(FactSales[TotalAmount]), mas mais lento porque o iterador verifica linha por linha enquanto SUM aproveita a compactação colunar.

---

Grupos de cálculo

O que os grupos de cálculo resolvem

Antes dos grupos de cálculo, um modelo de dados com 10 medidas básicas (receita, quantidade, custo, margem, etc.) e 5 variações de inteligência temporal (acumulado no ano, trimestre trimestral, MTD, ano anterior, ano anterior no acumulado do ano) exigia 50 medidas separadas. Adicionar uma nova medida básica significou a criação de mais 5 variantes de inteligência temporal. Adicionar um novo padrão de inteligência temporal significou a criação de mais 10 medidas. Esta explosão combinatória tornou os modelos difíceis de manter.

Os grupos de cálculo resolvem isso definindo padrões de inteligência temporal uma vez e aplicando-os a qualquer medida de forma dinâmica.

Construindo um Grupo de Cálculo de Inteligência de Tempo

No Power BI Desktop, crie um grupo de cálculo por meio da visualização Modelo ou usando ferramentas externas como o Editor Tabular (que fornece mais controle).

Defina itens de cálculo para cada padrão de inteligência de tempo:

Atual: Sem modificação --- retorna a medida como está.

SELECTEDMEASURE()

Acumulado no ano (acumulado no ano):

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(DimDate[Date])
)

Ano anterior:

CALCULATE(
    SELECTEDMEASURE(),
    SAMEPERIODLASTYEAR(DimDate[Date])
)

Acumulado no ano anterior:

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(SAMEPERIODLASTYEAR(DimDate[Date]))
)

Alteração anual:

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN CurrentValue - PriorValue

Variação percentual anual:

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN DIVIDE(CurrentValue - PriorValue, PriorValue)

Depois de definido, os usuários colocam o grupo de cálculo na coluna ou no eixo da linha de um visual, e o Power BI aplica cada item de cálculo a qualquer medida que esteja nos valores. Um grupo de cálculo com 6 itens substitui 60 medidas individuais (para 10 medidas básicas).

Formatar Expressões de String

Cada item de cálculo pode ter uma expressão de string de formato que altera dinamicamente o formato do número com base no cálculo:

Para medidas absolutas (atual, acumulado no ano, ano anterior): use o formato da medida base. Para medidas percentuais (% de variação anual): formato como porcentagem.

// Format string for YoY % Change
"0.0%;-0.0%;0.0%"

Isso garante que quando um usuário alterna entre "Atual" (mostrando US$ 1.234.567) e "% de alteração anual" (mostrando 12,5%), a formatação está correta sem intervenção manual.

---

Inteligência de Tempo

A tabela de dimensão de data

A inteligência temporal no Power BI requer uma tabela de dimensão de data dedicada. Não confie no recurso automático de data/hora (desative-o em Arquivo → Opções → Carregamento de dados) --- ele cria tabelas de datas ocultas para cada coluna de data, sobrecarregando seu modelo e limitando seu controle.

Crie uma tabela de dimensão de data que cubra toda a gama de seus dados, além de pelo menos um ano de cada lado. Se a sua primeira transação for janeiro de 2020, comece a tabela de datas em janeiro de 2019. Se a sua análise incluir previsões para 2027, termine em dezembro de 2027.

Colunas essenciais para uma tabela de dimensão de data:

Crie a tabela de datas no Power Query ou como uma tabela calculada DAX:

DimDate =
VAR StartDate = DATE(2019, 1, 1)
VAR EndDate = DATE(2027, 12, 31)
RETURN
ADDCOLUMNS(
    CALENDAR(StartDate, EndDate),
    "DateKey", YEAR([Date]) * 10000 + MONTH([Date]) * 100 + DAY([Date]),
    "Year", YEAR([Date]),
    "Quarter", "Q" & QUARTER([Date]),
    "MonthNumber", MONTH([Date]),
    "Month", FORMAT([Date], "MMMM"),
    "DayOfWeek", FORMAT([Date], "dddd"),
    "IsWeekend", WEEKDAY([Date], 2) >= 6
)

Marque a tabela como uma tabela de datas no Power BI (Ferramentas de tabela → Marcar como tabela de datas → selecione a coluna Data). Isso ativa as funções integradas de inteligência de tempo.

Padrões comuns de inteligência de tempo

Com uma dimensão de data adequada, as funções de inteligência temporal do Power BI lidam com os cálculos temporais mais comuns:

Acumulado no ano: DATESYTD(DimDate[Date]) Acumulado no trimestre: DATESQTD(DimDate[Date]) Acumulado no mês: DATESMTD(DimDate[Date]) Mesmo período do ano passado: SAMEPERIODLASTYEAR(DimDate[Date]) Acumulando 12 meses: DATESINPERIOD(DimDate[Date], MAX(DimDate[Date]), -12, MONTH) Período Paralelo: PARALLELPERIOD(DimDate[Date], -1, QUARTER) (janela do mesmo tamanho deslocada para trás)

Essas funções modificam o contexto do filtro de data quando usadas dentro de CALCULATE. Eles só funcionam corretamente quando a coluna de data vem de uma tabela marcada como Tabela de datas com um intervalo de datas contíguo e completo.

Suporte ao calendário fiscal

Se o ano fiscal da sua organização não estiver alinhado com o ano civil, modifique os cálculos de inteligência temporal para usar o calendário fiscal:

Fiscal YTD Revenue =
CALCULATE(
    [Total Revenue],
    DATESYTD(DimDate[Date], "6/30")  -- Fiscal year ends June 30
)

O segundo argumento para DATESYTD especifica a data de encerramento do ano fiscal. Todos os cálculos acumulados no ano usam o limite do ano fiscal em vez de 31 de dezembro.

---

Modelos Compostos

Quando usar modelos compostos

Os modelos compostos combinam dados importados (armazenados no VertiPaq) com dados DirectQuery (consultados ao vivo na fonte) em um único modelo. Essa abordagem híbrida é valiosa quando você precisa do desempenho dos dados importados para análise histórica e da atualização dos dados em tempo real para métricas operacionais.

Cenários comuns:

Histórico + em tempo real. Importe 3 anos de dados históricos de vendas para análise de tendências (consultas rápidas, sem impacto no banco de dados de origem). Conecte-se aos dados do mês atual via DirectQuery para obter visualizações operacionais atualizadas.

Modelo central + enriquecimento local. Conecte-se a um conjunto de dados gerenciado centralmente por meio do DirectQuery (garantindo o uso das definições governadas da organização). Adicione tabelas locais importadas para dados específicos do departamento (metas orçamentárias, classificações personalizadas) que não existem no modelo central.

Sistemas de origem múltipla. Importe dados de um data warehouse em nuvem (Snowflake, Azure Synapse) e conecte-se via DirectQuery a um banco de dados operacional (PostgreSQL, SQL Server) em um único relatório, sem criar um pipeline ETL separado para consolidá-los.

Arquitetura de modelo composto

Em um modelo composto, cada tabela possui um modo de armazenamento:

Importação: Os dados são carregados na memória do VertiPaq. Desempenho de consulta mais rápido, mas requer atualização agendada para atualização.

DirectQuery: os dados são consultados em tempo real a partir da origem. Sempre atual, mas depende do desempenho do banco de dados de origem.

Duplo: A tabela é importada e está disponível para DirectQuery. Usado para tabelas de dimensões que precisam estar relacionadas às tabelas de fatos Import e DirectQuery.

Defina tabelas de dimensão que unem dados de importação e DirectQuery para o modo "Dual". Isso permite que o mecanismo VertiPaq use a cópia na memória ao filtrar fatos de importação e gere consultas SQL ao filtrar fatos do DirectQuery.

Considerações de desempenho

Modelos compostos introduzem complexidade. As consultas que abrangem tabelas de importação e DirectQuery exigem que o Power BI mescle resultados de dois mecanismos diferentes, o que pode ser lento se a origem do DirectQuery não estiver otimizada.

Minimize as junções de origem cruzada estruturando seu modelo para que a maioria das consultas analíticas atinjam tabelas de importação. Use o DirectQuery somente para tabelas específicas que exigem atualização em tempo real. Indexe as tabelas de origem do DirectQuery nas colunas usadas em relacionamentos e filtros.

Para organizações que criam modelos de dados complexos do Power BI, os serviços de modelagem de dados da ECOSIRE fornecem orientação especializada sobre design de esquema em estrela, otimização de DAX e arquitetura de modelo composto adaptada ao seu cenário de dados e requisitos de desempenho específicos.

---

Otimização do modelo

Reduzindo o tamanho do modelo

Modelos grandes consomem mais memória, atualizam mais lentamente e consultam com menor capacidade de resposta. Otimize o tamanho do modelo por meio destas técnicas:

Remova colunas não utilizadas. Se uma coluna não for usada em nenhuma regra visual, medida, relacionamento ou RLS, remova-a. Cada coluna consome memória mesmo que nenhum visual faça referência a ela. Os infratores comuns incluem colunas geradas automaticamente, colunas de auditoria (CreatedBy, ModifiedDate) e identificadores técnicos que não servem a nenhum propósito analítico.

Reduza a cardinalidade. Colunas com milhões de valores exclusivos (carimbos de data/hora, GUIDs, campos de texto livre) são compactadas de maneira inadequada. Arredondar carimbos de data/hora para a granularidade apropriada (diariamente, de hora em hora). Substitua GUIDs por chaves substitutas de número inteiro. Mova os campos de texto livre para uma tabela de detalhes separada que só será consultada durante o drill through.

Use tipos de dados apropriados. O Power BI armazena "Número inteiro" com mais eficiência do que "Número decimal". Se uma coluna contiver apenas números inteiros (quantidades, contagens), defina seu tipo como Número inteiro. As colunas de texto consomem mais memória do que as colunas numéricas da mesma cardinalidade --- sempre que possível, codifique as categorias de texto como números inteiros com uma dimensão de pesquisa.

Desative data/hora automática. O recurso de data/hora automática cria uma tabela de datas oculta para cada coluna de data no modelo. Para um modelo com 10 colunas de datas, são 10 tabelas de datas ocultas consumindo memória. Desative esse recurso e use uma única dimensão de data explícita.

Diagnóstico de desempenho de consulta

Use o DAX Studio para analisar o desempenho da consulta além do que o Analisador de Desempenho integrado do Power BI mostra. DAX Studio revela:

Consultas do mecanismo de armazenamento. Quantas consultas são enviadas ao mecanismo VertiPaq e quantos dados elas verificam. Menos consultas verificando menos dados significa melhor desempenho.

Atividade do mecanismo de fórmula. Quanto trabalho o mecanismo de fórmula realiza (cálculos linha por linha, expressões complexas). O alto tempo do mecanismo de fórmula indica medidas que devem ser reescritas para enviar mais trabalho ao mecanismo de armazenamento.

Plano de consulta. O plano de execução lógico e físico para uma consulta DAX, mostrando como o Power BI decompõe uma medida em consultas do mecanismo de armazenamento e operações do mecanismo de fórmula.

Almeje tempos de consulta inferiores a 500 ms para recursos visuais interativos. Consultas com mais de 2 segundos parecem lentas e desencorajam o uso do painel. Se um visual específico exceder consistentemente 2 segundos, simplifique seu DAX, reduza o volume de dados que ele processa ou mova-o para uma página de detalhamento onde os usuários aceitam uma breve espera.

---

Perguntas frequentes

Devo usar o esquema em estrela ou o esquema em floco de neve no Power BI?

O esquema em estrela é quase sempre a melhor escolha para o Power BI. O esquema Snowflake normaliza tabelas de dimensões em subtabelas (Categoria → Subcategoria → Produto), o que funciona bem em bancos de dados relacionais, mas cria junções desnecessárias no mecanismo VertiPaq do Power BI. O VertiPaq compacta colunas de dimensões desnormalizadas de forma extremamente eficiente, de modo que a economia de espaço resultante da formação de flocos de neve é ​​insignificante, enquanto o custo de desempenho de relacionamentos adicionais é real. Achate suas dimensões em esquema em estrela, a menos que você tenha um motivo técnico específico para não fazê-lo (como uma tabela de dimensões muito grande com uma coluna de alta cardinalidade raramente usada que você deseja isolar).

Qual é o tamanho máximo do conjunto de dados no Power BI?

O Power BI Pro oferece suporte a conjuntos de dados compactados de até 1 GB. Premium por usuário suporta até 100 GB. A capacidade premium (P1 e superior) suporta até 400 GB com armazenamento de grandes conjuntos de dados habilitado. Esses limites referem-se ao tamanho compactado na memória, não ao tamanho dos dados de origem. O VertiPaq normalmente compacta dados na proporção de 10:1, portanto, um conjunto de dados compactados de 1 GB pode representar 10 GB de dados de origem. Para conjuntos de dados que se aproximam desses limites, considere agregações, atualização incremental ou modelos compostos com DirectQuery para dados em nível de detalhe.

Como lidar com relacionamentos muitos-para-muitos em um esquema em estrela?

Use uma tabela de ponte (também chamada de tabela de fatos sem fatos ou tabela de junção). A tabela ponte possui uma linha para cada combinação no relacionamento muitos-para-muitos --- por exemplo, uma linha para cada atribuição de segmento de cliente. Crie relacionamentos um-para-muitos de cada dimensão para a tabela ponte. Esteja ciente de que as tabelas ponte podem causar contagem dupla; combine-os com medidas DISTINCTCOUNT ou use CROSSFILTER no DAX para controlar a propagação do filtro. Teste minuciosamente com dados conhecidos para garantir que os totais estejam corretos.

Devo criar colunas calculadas ou medidas DAX?

Prefira medidas a colunas calculadas em quase todos os casos. As medidas são calculadas no momento da consulta e não consomem armazenamento. As colunas calculadas são computadas durante a atualização e armazenadas na memória, aumentando o tamanho do modelo. Use colunas calculadas somente quando precisar do valor disponível para filtragem, classificação ou relacionamentos (você não pode filtrar por uma medida em uma segmentação de dados, mas pode filtrar por uma coluna calculada). Uma exceção comum é uma coluna concatenada para rótulos em nível de linha (FullName = FirstName + " " + LastName) que os usuários precisam em segmentações de dados ou visuais de tabela.

Como os grupos de cálculo interagem com as medidas existentes?

Os grupos de cálculo interceptam a avaliação da medida envolvendo a medida na expressão do item de cálculo. Quando um visual contém uma medida e um grupo de cálculo, o Power BI aplica o item de cálculo à medida por meio da função SELECTEDMEASURE(). Isso significa que suas medidas básicas não precisam ser modificadas. No entanto, as medidas que já contêm inteligência temporal (como uma medida acumulada no ano) terão o grupo de cálculo aplicado na parte superior, produzindo potencialmente uma aplicação dupla. Para evitar isso, defina apenas medidas básicas (agregações simples) e use grupos de cálculo exclusivamente para toda a inteligência temporal e lógica de comparação.