O esquema estrela é o conceito central por trás de uma pergunta comum do DP-900: que forma os dados analíticos devem ter quando são armazenados? Tabelas de fatos e de dimensões, a diferença entre os modelos estrela e floco de neve e o modelo de dados analítico (modelo semântico) construído sobre eles abrangem dois itens do Domínio 4 do conteúdo oficial: "Descrever opções para armazenamentos de dados analíticos" e "Descrever recursos de modelos de dados no Power BI". Aprenda uma vez e você responde a perguntas das duas áreas.
Este post é um complemento da nossa série de estudos do DP-900. Partindo dos conceitos de OLTP versus OLAP e de data lake versus data warehouse vistos antes, ele mostra como os dados analíticos são de fato organizados em tabelas e como viram um modelo no Power BI.
---
Por que os dados analíticos precisam de outro formato?
Pense no sistema de pedidos de uma loja virtual. Cada pedido é registrado em várias tabelas separadas: pedidos, itens do pedido, clientes, endereços, produtos e pagamentos. A normalização elimina a duplicação e mantém as gravações rápidas, mas responder a "receita por região e categoria no último trimestre" exige juntar cinco ou seis tabelas com JOIN.
É a diferença entre uma caixa cheia de notinhas e um caderno de contas da casa bem organizado. As notinhas são rápidas de guardar uma a uma, mas para saber quanto você gastou com mercado no mês passado é preciso revirar todas. O caderno já organiza data, categoria e valor em colunas fixas, então o total está ali na hora.
Por isso os armazenamentos analíticos não copiam os dados transacionais do jeito que estão. Eles os reorganizam em um formato fácil de agregar.
| Aspecto | Esquema transacional (OLTP) | Esquema analítico (OLAP) | |------|------|------| | Finalidade | Registrar pedidos e pagamentos com rapidez e precisão | Agregar e comparar grandes volumes de dados | | Princípio de design | Normalizar para minimizar a duplicação | Separar fatos e dimensões para agregar com facilidade | | Consulta típica | Ler ou atualizar um único pedido | Totais por mês ou por região, tendências | | Estrutura das tabelas | Muitas tabelas pequenas | Uma tabela de fatos central mais tabelas de dimensões | | Exemplo típico | Banco de dados de pedidos de uma loja virtual | Data warehouse, modelo do Power BI |
Dica de prova: "Transformar dados transacionais em um esquema otimizado para consultas analíticas" → data warehouse. O design de tabelas mais comum para isso é o esquema estrela.
---
Tabelas de fatos e tabelas de dimensões
Um esquema estrela é formado por dois tipos de tabela: tabelas de fatos, que guardam os números, e tabelas de dimensões, que guardam os atributos usados para agrupar e filtrar esses números.
Tabelas de fatos: o que aconteceu, em números
Cada linha de uma tabela de fatos é um evento registrado. Uma venda, uma entrega ou uma leitura de sensor viram, cada uma, uma linha. A linha traz os valores numéricos que você quer analisar (quantidade, receita, custo) e as chaves que apontam para as dimensões às quais o evento pertence (chave de data, chave de produto, chave de cliente).
Tabelas de dimensões: o "por quê" da sua análise
Uma tabela de dimensões representa uma entidade pela qual você agrega. Uma dimensão de produto guarda nome do produto, categoria e marca; uma dimensão de cliente guarda nome, cidade e nível. Cada linha tem um valor de chave único, e a tabela de fatos referencia as linhas da dimensão por meio dessa chave.
Quase todo modelo analítico inclui uma dimensão de data (tempo). Com uma dimensão de data que já tem colunas de dia, mês, trimestre e ano, perguntas como "receita por mês" ou "comparado com o mesmo trimestre do ano passado" ficam fáceis de responder.
| Aspecto | Tabela de fatos | Tabela de dimensões | |------|------|------| | O que guarda | Medidas (números) mais chaves de dimensão | Atributos descritivos (nomes, categorias, locais) | | O que uma linha significa | Um evento (uma venda) | Uma entidade (um produto) | | Quantidade de linhas | Muito grande e sempre crescendo | Relativamente pequena | | Colunas de exemplo | Quantidade, receita, chave de data, chave de produto | Nome do produto, categoria, marca | | Papel em uma consulta | Os valores que você soma ou tira média | O que você usa para agrupar e filtrar |
Em um modelo analítico, essas duas ideias se chamam medidas e dimensões. "Receita total por cliente" e "unidades vendidas por mês por produto" são medidas agregadas por uma ou mais dimensões.
Dica de prova: "Valores numéricos a agregar, como quantidade ou receita" → tabela de fatos. "Atributos para agrupar ou filtrar, como nome do produto, categoria ou cidade" → tabela de dimensões.
---
Esquema estrela vs esquema floco de neve
Uma única tabela de fatos no centro com tabelas de dimensões ao redor parece uma estrela; daí o nome esquema estrela. As tabelas de dimensões se relacionam com a tabela de fatos em uma relação de um para muitos (1:N): um produto aparece em muitos registros de venda, mas cada venda aponta para exatamente um produto.
Um esquema floco de neve pega as tabelas de dimensões de um esquema estrela e as divide ainda mais. Em vez de repetir o nome da categoria dentro da dimensão de produto, por exemplo, você cria uma tabela de categorias separada e a liga à tabela de produtos. Os galhos que se estendem para fora lembram um floco de neve, e é daí que vem o nome.
!Esquema estrela vs esquema floco de neve
| Aspecto | Esquema estrela | Esquema floco de neve | |------|------|------| | Estrutura da dimensão | Uma tabela por dimensão | A dimensão é normalizada em várias tabelas | | Como as hierarquias são guardadas | Colunas na mesma tabela (produto → categoria) | Tabelas separadas (tabela de produtos → tabela de categorias) | | Quantidade de JOINs | Poucos | Mais | | Consultas e modelo | Simples e rápidos | Mais complexos | | Duplicação | Alguma duplicação permitida nas dimensões | Menos duplicação |
A orientação oficial do Power BI recomenda projetar os modelos como esquemas estrela. Relações simples fazem os filtros fluírem como você espera e deixam as fórmulas DAX mais fáceis de escrever. Quando a origem tem formato de floco de neve, é comum mesclar as tabelas de dimensões em uma só para que o modelo fique em estrela.
Dica de prova: "Uma tabela de dimensões se liga a mais uma tabela (por exemplo, produto → categoria) para representar uma hierarquia" → esquema floco de neve. "As tabelas de dimensões se conectam diretamente a uma tabela de fatos" → esquema estrela.
---
Dos cubos aos modelos semânticos
Analistas podem consultar diretamente as tabelas do data warehouse, mas, para facilitar a criação de relatórios e dashboards, costuma haver um modelo de dados analítico por cima. Ele é uma planta que define de antemão quais tabelas se conectam, o que conta como medida e por quais hierarquias você pode detalhar.
O jeito antigo: cubos OLAP
No passado, os cubos eram criados com tecnologias como o SQL Server Analysis Services (SSAS) Multidimensional. Os números eram pré-agregados e armazenados para cada combinação de dimensões, como receita por produto e região. As consultas eram rápidas, mas qualquer agregação nova exigia reprocessar o cubo.
O jeito atual: modelos semânticos
O Power BI e o Microsoft Fabric usam um modelo semântico, também chamado de modelo tabular. Ele define tabelas, relações, hierarquias e medidas escritas em DAX, e as agregações são calculadas no momento da consulta em vez de armazenadas de antemão. No modo Import, os dados são carregados no armazenamento colunar em memória do mecanismo VertiPaq para cálculos rápidos. No Fabric, o modo Direct Lake carrega tabelas Delta do OneLake direto na memória do modelo, sem uma cópia separada.
| Aspecto | Cubo OLAP (multidimensional) | Modelo semântico (tabular) | |------|------|------| | Tecnologia típica | SSAS Multidimensional | Power BI, Microsoft Fabric | | Quando a agregação acontece | Pré-calculada e armazenada | Calculada na consulta | | Como os cálculos são definidos | MDX e similares | Medidas DAX | | Situação atual | Abordagem legada | Abordagem recomendada hoje |
Hierarquias de atributos: subir e descer de nível
As hierarquias permitem que você se mova entre níveis dentro de uma dimensão. Ver a receita por ano e clicar em um ano para vê-la por mês é detalhar (drill down); voltar à visão anual é subir de nível (drill up).
Dimensão de data: dia → mês → ano Dimensão de produto: produto → categoria Dimensão de cliente: cliente → cidade
Na exibição Modelo do Power BI Desktop, você cria as relações entre as tabelas de fatos e de dimensões, define hierarquias e configura tipos de dados e formatos de exibição. Para a diferença entre medidas e colunas calculadas e para os modos de conexão de dados, continue em Power BI: Conceitos Essenciais.
Dica de prova: "Uma estrutura multidimensional que armazena os números pré-agregados por dimensão" → cubo. "Começar pelos valores anuais e descer para os valores mensais" → detalhar por meio de uma hierarquia. "Carregar tabelas Delta do Fabric em um modelo sem copiá-las" → Direct Lake.
---
Data warehouse, data lake e lakehouse
Se o esquema estrela trata de como dar forma às tabelas, os armazenamentos de dados analíticos tratam de onde os dados ficam e em que formato. O DP-900 espera que você diferencie três opções.
| Aspecto | Data warehouse | Data lake | Data lakehouse | |------|------|------|------| | Forma de armazenamento | Tabelas relacionais | Arquivos em um sistema de arquivos distribuído | Arquivos do lake mais tabelas Delta | | Quando o esquema é aplicado | Na gravação (esquema estrela etc.) | Na leitura | As tabelas Delta Lake impõem o esquema | | Dados que guarda | Estruturados | Estruturados, semiestruturados e não estruturados | Principalmente estruturados e semiestruturados | | Principal forma de consulta | SQL | Apache Spark e mecanismos semelhantes | SQL e Spark | | Exemplos no Azure | Fabric Ware