BI & Analytics
Fundamentos

Star Schema: a estrutura que torna o BI rápido

Antes de qualquer medida DAX ou query SQL poder funcionar corretamente, o modelo de dados tem de estar certo. A maioria dos problemas de performance em BI (relatórios lentos, totais errados, medidas que se comportam de forma inesperada) remonta a um modelo mal desenhado. Acerta no modelo e tudo o resto fica mais fácil.

O padrão dominante em BI é o Star Schema. Organiza os dados em dois tipos de tabelas:

A forma de "estrela" emerge naturalmente: a fact table fica no centro, com as dimension tables a irradiar para fora. Cada chave estrangeira na fact table liga à chave primária de uma dimensão. Uma fact table de vendas pode ter chaves para Data, Cliente, Produto e Região, quatro dimension tables, quatro pontas da estrela.

A alternativa é o Snowflake Schema, onde as dimensões são normalizadas em subdimensões. Poupa armazenamento mas obriga o Power BI a fazer mais joins, abranda as queries e torna o DAX significativamente mais complexo de escrever. Para a maioria das cargas de BI, o Star Schema ganha ao Snowflake. A troca de um pouco mais de armazenamento por medidas dramaticamente mais simples e melhor performance compensa quase sempre.

DAX: a linguagem de medidas que precisas de perceber

DAX (Data Analysis Expressions) é a linguagem de fórmulas do Power BI, do Analysis Services e do Power Pivot do Excel. Parece fórmulas de Excel, mas opera sobre tabelas e colunas, não células. Perceber um conceito separa os principiantes dos praticantes:

Para além destes três, os padrões que aparecem em quase todas as soluções de BI em produção são:

• Medidas vs colunas calculadas: As medidas são calculadas em tempo de query usando o filter context atual. As colunas calculadas são calculadas no refresh e guardadas no modelo. Usa medidas para agregações, colunas calculadas só quando precisas de um valor para filtrar ou agrupar.
• DIVIDE() em vez do operador /: lida com a divisão por zero de forma elegante, devolvendo um blank (ou uma alternativa indicada) em vez de partir o visual.
• VAR / RETURN: guardam resultados intermédios para evitar recalcular a mesma expressão várias vezes numa medida complexa. Melhora a legibilidade e a performance.
• ALL() e ALLEXCEPT(): removem filtros do contexto, usadas dentro do CALCULATE para calcular totais, percentagens ou rankings que ignoram os slicers.

Padrões de SQL que todo o analista de BI usa

SQL é a linguagem do data warehouse, a camada onde os dados de origem em bruto são transformados em tabelas limpas e modeladas que o Power BI consegue consultar. Para além do básico SELECT/WHERE/GROUP BY, a analytics de BI depende muito de um conjunto específico de padrões.

Um padrão que vale a pena destacar em detalhe: a comparação período-a-período. Em SQL, isto significa juntar uma tabela a si própria (ou usar o LAG com uma window function) para obter o valor do período anterior na mesma linha que o do período atual, para que se calcule a diferença num único SELECT.

Os KPIs que os stakeholders de negócio pedem mesmo

Competências técnicas de BI sem conhecimento de domínio produzem dashboards que ninguém usa. As métricas que aparecem nos relatórios executivos e nos board packs seguem padrões reconhecíveis na maioria das indústrias. Finanças e RH são os dois domínios mais comuns para analistas de BI, e cada um tem o seu próprio vocabulário.

O erro mais comum nos dashboards de finanças: confundir Orçamentado vs Real com Previsão vs Real. O orçamento é fixado no início do ano e mede contra o plano original. A previsão atualiza-se ao longo do ano e reflete a melhor estimativa atual de onde o ano vai terminar. Um bom dashboard de FP&A acompanha ambos: o desvio do orçamento diz-te onde estás face ao plano; a previsão diz-te para onde vais.

Na analytics de RH, headcount parece simples mas tem três definições válidas: num momento (colaboradores ativos numa data específica), médio (headcount médio ao longo de um período) e ajustado a FTE (ponderado para part-time). Quando os stakeholders dizem "headcount", esclarece sempre qual a definição que querem antes de construir a medida.

A stack de BI moderna: por onde os dados passam antes do Power BI

O Power BI é a última milha, a camada de visualização com que os executivos interagem. Por trás dele está uma stack que ingere, armazena e transforma os dados antes de chegarem a um dashboard. Perceber a stack ajuda-te a fazer debug de problemas, a comunicar com engenheiros de dados e a desenhar soluções que escalam.

O data warehouse está tipicamente organizado em camadas: uma camada raw que guarda os dados de origem exatamente como recebidos, uma camada de staging onde os dados são limpos e padronizados, e uma camada de marts onde vivem os star schemas específicos de cada domínio: o mart de Finanças, o de RH, o de Vendas. O Power BI liga-se à camada de marts.

A camada de transformação (a lógica SQL que move os dados de raw para mart) é cada vez mais construída com dbt (data build tool), que te deixa escrever transformações SQL como modelos versionados, testados e documentados. No lado cloud, as combinações comuns são Snowflake + dbt + Fivetran, ou Azure Synapse + Power BI numa stack nativa da Microsoft.

Como analista de BI, não precisas de construir o pipeline de ingestão, mas precisas de saber que existe, perceber como os dados chegam ao warehouse, e ser capaz de rastrear um número errado de trás para a frente pelas camadas até encontrar onde correu mal.