Análise Multidimensional

Objetivos de aprendizagem #

• O1. Modelar um domínio em esquema estrela, distinguindo fatos de dimensões.
• O2. Executar operações OLAP: drill-down, roll-up, slice, dice e pivot.
• O3. Justificar a desnormalização deliberada de um repositório analítico.
• O4. Relacionar o cubo à tabela que um modelo preditivo consome.

O problema: vendas por produto, por região, por trimestre #

Você já viu SQL. Então já viu esta cena: a diretora pede "vendas por produto, por região, por trimestre" — e você escreve um GROUP BY com três colunas, três JOIN e um SUM. Funciona. Aí ela pergunta: "e sem a região Sul?". Depois: "e agora por categoria em vez de produto?". Depois: "e mês a mês, só no Nordeste?". Cada pergunta é uma consulta nova, escrita do zero, que varre a mesma base de novo.

O aperto é estrutural. O modelo relacional é excelente para transação — normalizado para escrever rápido e sem inconsistência. E é desajeitado para a pergunta gerencial típica, que agrega em vários eixos ao mesmo tempo e muda de eixo a cada trinta segundos de reunião. São dois objetivos opostos no mesmo banco, e o segundo sempre perde: a consulta demora, e quem perguntou já mudou de assunto.

O erro que este capítulo previne é tratar isso como problema de otimização de SQL. Não é. É problema de modelo de dados.

De onde isto veio #

O aperto. Anos 1980–90: as empresas já tinham o dado transacional em bancos relacionais e não conseguiam interrogá-lo na velocidade da conversa. O analista pedia um relatório; o relatório vinha no dia seguinte, respondendo a uma pergunta que já não era a pergunta.

O que se fazia antes. SQL direto sobre o transacional, com muitos GROUP BY encadeados — lento, e reescrito por inteiro a cada nova pergunta. O conhecimento acumulado ficava nas consultas de alguém, não no modelo.

A virada. Parar de tratar o dado como tabelas e passar a tratá-lo como cubo: eixos (as dimensões — produto, região, tempo) e medidas (o que se soma — receita, quantidade). Com as agregações pré-computadas, mudar de pergunta deixa de ser reescrever a consulta e vira navegar: descer o nível de detalhe, subir, fatiar, girar.

A ideia reaproveitável. Trocar espaço e frescor por tempo de resposta é uma decisão de projeto, não um detalhe. O cubo é essa troca tornada arquitetura: ele ocupa mais disco, duplica dado e responde com números de ontem — em troca de responder agora. É o mesmo padrão do capítulo 22, onde Playfair inventa a barra por falta de dados, e do capítulo 18, onde o neurônio nasce sem aprendizado porque não havia como treinar: restrição material gera forma nova, e a forma sobrevive à restrição que a criou.

O nome. Online Analytical Processing (OLAP) é cunhado no relatório de 1993 de E. F. Codd, S. B. Codd e C. T. Salley, "Providing OLAP to User-Analysts: An IT Mandate", que também lista 12 regras para o que seria um produto OLAP legítimo. Codd é o mesmo Codd do modelo relacional — o que dá ao documento uma autoridade imediata.

O episódio que convém não omitir #

E aqui entra a parte incômoda, com o cuidado que ela exige.

A versão corrente é que o relatório que cunhou "OLAP" foi patrocinado pela Arbor Software, fabricante do Essbase — um produto lançado no ano anterior —, e que as 12 regras coincidiam notavelmente com as características desse produto. Conta-se também que o patrocínio não estava declarado no documento, que a Computerworld apurou o caso, e que o artigo acabou retirado.

Registre o estatuto disto: é uma acusação de conduta envolvendo pessoas reais, e a fonte primária não foi conferida — o material da Computerworld da época não foi aberto para escrever este capítulo. O que existe aqui é um relato repetido de forma consistente em fontes secundárias. Por isso o selo é ⏳, e por isso o texto diz "a versão corrente é que", nunca "aconteceu que". A diferença entre essas duas formas é o capítulo inteiro em matéria de método. O que se sabe com segurança é o resto: Codd seguiu reconhecido como o pai do modelo relacional, e a categoria OLAP permaneceu — e prosperou por três décadas.

Por que não omitir. Porque ensina uma coisa que nenhum tutorial ensina: categorias de tecnologia às vezes nascem de marketing, não de necessidade técnica. Antes de aceitar que uma categoria é natural — data lakehouse, feature store, vector database —, pergunte de onde ela veio e quem se beneficia de ela existir. É a lição de ceticismo mais barata deste livro, e a única que você vai usar em toda contratação de ferramenta pelo resto da carreira. Note o detalhe fino: a técnica do cubo era boa e resolvia um problema real — o que está em causa é a embalagem, não a engenharia. As duas coisas podem ser julgadas em separado.

Procedência das afirmações desta seção:

Fundamentos: fato, dimensão e grão #

O vocabulário é curto e faz todo o trabalho.

Fato é o que aconteceu e se mede: uma venda, um atendimento, um clique. A tabela-fato guarda as medidas (valor, quantidade) e as chaves que apontam para os eixos. Ela é comprida e estreita — milhões de linhas, poucas colunas.

Dimensão é o eixo pelo qual se corta o fato: produto, cliente, loja, tempo. A tabela-dimensão é curta e larga — poucas linhas, muitos atributos descritivos (nome, categoria, marca, região, gerente). É por ela que vêm os rótulos dos relatórios. O teste rápido: se você somaria a coluna, é medida; se você agruparia por ela, é dimensão.

Grão (granularidade) é a pergunta mais cara do projeto: o que é uma linha da tabela-fato? Uma venda? Um item de venda? O total de um produto por loja por dia? O grão define o teto do detalhe — você sempre pode agregar para cima, nunca desagregar para baixo. Escolher grão grosso porque "ninguém vai precisar do detalhe" é a decisão que se paga um ano depois, quando alguém precisa.

Estrela e floco de neve #

No esquema estrela, a tabela-fato fica no centro e cada dimensão é uma única tabela desnormalizada ao redor. A dimensão Produto carrega produto, subcategoria, categoria e departamento na mesma linha — texto repetido milhares de vezes.

No floco de neve, cada dimensão é normalizada em várias tabelas (Produto → Subcategoria → Categoria), sem repetição.

O floco é mais "correto" segundo a terceira forma normal. E a estrela quase sempre vence, por três razões: menos JOIN por consulta, um modelo que um analista de negócio consegue ler sozinho, e a percepção de que a redundância aqui é barata — a dimensão é pequena, e o que ela repete é texto, não a fonte da verdade. A normalização existe para proteger a escrita de anomalias; no repositório analítico, a escrita é uma carga controlada, feita por um processo só, em janela conhecida (ver capítulo 20). A anomalia que a 3NF previne simplesmente não tem por onde entrar. Desnormalizar aqui não é relaxar o rigor: é aplicá-lo a um problema diferente.

As cinco operações #

Modelado o cubo, a análise vira navegação — e são só cinco movimentos:

Repare no que mudou em relação ao SQL do início do capítulo: as cinco operações são fechadas — a saída de qualquer uma é outro cubo, pronto para receber a próxima. É por isso que a reunião flui. O analista não escreve nada; ele clica, e cada clique é uma dessas cinco coisas.

Por que muito cubo virou consulta direta #

Uma nota de leitura editorial (📖), para você não sair daqui achando que precisa construir um cubo: o cubo pré-computado perdeu bastante terreno. Quando o armazenamento colunar e o processamento distribuído ficaram baratos, varrer bilhões de linhas na hora deixou de ser proibitivo — e a agregação prévia passou a custar mais do que rende, em espaço, em manutenção e em atraso do dado. O que não perdeu terreno é a parte que interessa: fato, dimensão, grão, hierarquia e as cinco operações continuam sendo o vocabulário da análise, mesmo quando a resposta é calculada na hora. A implementação envelheceu; o modelo, não.

Nem toda medida pode ser somada #

Este é o detalhe que separa quem entendeu o modelo de quem decorou o desenho. Medidas se dividem em três tipos:

Aditivas — somam em todas as dimensões. Receita, quantidade vendida, custo. É o caso confortável, e o que todo mundo assume por padrão.

Semi-aditivas — somam em algumas dimensões e não em outras. O exemplo clássico é estoque: somar o estoque de um produto ao longo das lojas faz todo sentido (é o estoque da rede); somar o estoque ao longo do tempo não significa nada — janeiro tinha 100 unidades, fevereiro tinha 100 unidades, e "200" não descreve coisa nenhuma. Ao longo do tempo, o que faz sentido é o último valor ou a média. Saldo bancário e número de assinantes ativos têm exatamente o mesmo comportamento.

Não aditivas — não somam em dimensão nenhuma. Razões e percentuais: a margem média de duas lojas não é a soma das margens, nem a média simples delas. A regra é guardar no fato os componentes (receita e custo) e calcular a razão depois da agregação, no nível pedido.

Um painel que soma coluna semi-aditiva ao longo do tempo é um dos erros mais silenciosos do BI: ninguém vê erro de execução, o total simplesmente cresce mês a mês, e a empresa acredita ter um estoque que nunca teve.

Do cubo ao modelo #

O cubo responde "o que aconteceu"; o modelo preditivo responde "o que vai acontecer" — e os dois consomem o mesmo trabalho de base. A tabela que um modelo consome é, quase sempre, um cubo achatado num grão escolhido: uma linha por entidade-e-instante, medidas agregadas em janelas (receita nos últimos 30 dias, número de compras no trimestre) e atributos vindos das dimensões. Duas armadilhas na travessia. A primeira: o grão do cubo vira o grão do dataset, e um grão grosso demais impede o modelo de existir. A segunda, e mais grave: agregar sem respeitar o corte de tempo é o vazamento do capítulo 02 na forma mais fácil de cometer — se a janela de agregação inclui informação posterior ao instante da previsão, seu modelo tem um desempenho excelente e inútil.

Síntese — o que levar #

• O modelo relacional é ótimo para transação e desajeitado para a pergunta gerencial, que agrega em vários eixos ao mesmo tempo e muda a cada trinta segundos.
• Fato é o que se mede; dimensão é por onde se corta. Teste: somaria a coluna → medida; agruparia por ela → dimensão.
• O grão é a decisão mais cara. Agregar para cima sempre dá; desagregar para baixo, nunca.
• Estrela vence floco de neve quase sempre: menos JOIN, modelo legível, redundância barata porque acontece na dimensão. Desnormalizar aqui não é relaxar o rigor — a 3NF protege a escrita, e a escrita analítica é uma carga controlada.
• Cinco operações fechadas: drill-down, roll-up, slice, dice, pivot. A saída de cada uma é outro cubo, e é isso que faz a reunião fluir.
• Nem toda medida soma. Estoque soma entre lojas e não soma ao longo do tempo; razão não soma em lugar nenhum — guarde os componentes, calcule depois.
• Trocar espaço e frescor por tempo de resposta é decisão de projeto. O cubo é essa troca virada arquitetura — o mesmo padrão da barra de Playfair (22) e do neurônio sem aprendizado (18).
• O cubo pré-computado perdeu terreno para o colunar barato; o vocabulário do cubo não perdeu nada.
• A categoria "OLAP" nasceu com um episódio incômodo. Pergunte de onde veio a categoria antes de aceitá-la como natural — e julgue a embalagem separadamente da engenharia.

Verificação #

1. Escolha um sistema que você conhece e diga qual seria o grão da tabela-fato. Depois diga o que se perde ao subir um nível — e quem vai reclamar primeiro.
2. Dê um exemplo, do seu contexto, de medida semi-aditiva. Em quais dimensões ela soma, e o que se calcula naquela em que não soma?
3. O colega da farmácia diz que o cubo é dispensável porque "hoje o banco colunar aguenta". Em que ele tem razão, e o que continua valendo do modelo dimensional mesmo sem cubo pré-computado?
4. Você usaria as agregações do cubo como variáveis de um modelo preditivo (capítulo 21 antes, capítulo 02 como alerta). Que verificação você faria antes, para não vazar o futuro para dentro do passado?