Multidimensional: fato × dimensão, estrela × floco de neve, SCD, OLTP × OLAP

A ideia que organiza o assunto

Comece pela medição, porque ela muda a ordem do estudo. São 51 itens neste tópico — 26 Certos e 25 Errados. O título promete fato × dimensão, estrela × floco de neve, SCD e OLTP × OLAP, e a contagem confirma dois desses quatro com folga e desmente a importância dos outros dois: fato ou dimensão aparece em 16 itens, estrela ou floco de neve em 11, OLTP × OLAP em 4 e slowly changing dimension em exatamente 1. O que o título não menciona é justamente o maior bloco: 11 itens cobram operações de cubo — drill down, roll up, slice, dice, drill across, cube — e mais 5 cobram MOLAP × ROLAP. Quem estuda este assunto pelo nome estuda o esquema; a prova cobra a navegação.

A ideia que organiza tudo cabe em uma frase: o modelo dimensional separa o que se mede do contexto em que se mede. A tabela de fatos guarda os números — valor vendido, tempo de resolução, quantidade — e as chaves que apontam para as perspectivas. As tabelas de dimensão guardam os adjetivos: quem, quando, onde, de que tipo. Nenhuma das duas faz o papel da outra, e é essa fronteira que decide a maior parte dos itens do assunto.

Fixada a fronteira, o resto se deduz sem decorar. A chave primária da fato é composta porque é a junção das chaves das dimensões que definem o grão. A fato é a maior tabela porque cresce a cada evento, enquanto a dimensão tem uma linha por entidade descrita. Texto descritivo nunca mora na fato porque descrever é serviço da dimensão. E estrela e floco de neve não são dois modelos diferentes: são a mesma estrela com a dimensão inteira em uma tabela ou quebrada em várias.

A segunda ideia é a que resolve os itens de operação, e é ainda mais barata: toda operação OLAP se move em um de dois eixos. Ou muda o nível de detalhe — drill down desce, roll up sobe — ou muda o recorte, mantendo o detalhe: slice e dice filtram valores, drill across atravessa para outra tabela de fatos, pivot gira os eixos. Antes de julgar qualquer item de operação, pergunte apenas isto: mudou o detalhe ou mudou o recorte? Cinco dos 25 itens errados do corpus caem com essa única pergunta.

Por que se usa (e o que custa)

O banco transacional normaliza para gravar: cada informação em um lugar só, sem redundância, com atualização barata e consistente. O preço dessa escolha aparece na leitura analítica — responder “faturamento por região por trimestre” exige percorrer dezenas de tabelas normalizadas e agregar milhões de linhas.

A modelagem dimensional faz a troca inversa e assume o custo com os olhos abertos: desnormaliza para ler. A hierarquia inteira de uma dimensão cabe em uma tabela, a consulta faz uma junção por dimensão em vez de uma cadeia de junções por nível, e o plano do otimizador fica previsível. Ganha-se tempo de resposta e, não menos importante, um modelo que o usuário de negócio entende sem tradutor.

Paga-se em três moedas. Redundância: o nome do estado se repete em cada linha da dimensão de município, e a dimensão desnormalizada é maior que a normalizada. Preparação: o dado não chega pronto — é preciso reestruturá-lo em esquema estrela ou carregá-lo em cubo antes de consultar, e essa reestruturação é obrigatória, não opcional. Rigidez: agregações pré-calculadas e cubos respondem rápido justamente porque a resposta já foi computada, de modo que mudar a estrutura obriga a reprocessar tudo.

A formulação honesta para a prova: o modelo dimensional troca espaço em disco, tempo de carga e flexibilidade de estrutura por tempo de resposta e clareza de leitura. Item que prometa velocidade sem nenhum desses custos desfez a troca.

Como funciona

A tabela de fatos. Contém três coisas e nada mais: as chaves estrangeiras das dimensões, as medidas (as métricas numéricas do processo de negócio) e, no máximo, alguma dimensão degenerada — um identificador de documento, como o número da nota fiscal ou do processo, que não tem atributos a descrever e por isso fica na própria fato, integrando a chave. A chave primária é a composição das chaves dimensionais, e a dimensão tempo participa dela sempre: não existe fato sem quando.

A granularidade. É a primeira e mais importante decisão do projeto: o que representa uma linha da tabela de fatos. “Uma linha é uma movimentação de um processo, em uma data, sob um juiz” é uma declaração de grão. O conjunto de chaves estrangeiras da fato é o grão, e o grão é o piso do modelo — nenhuma operação analítica desce abaixo dele. Quanto mais fino o grão, maior a tabela e maior a flexibilidade de análise.

A aditividade das medidas. Medida aditiva pode ser somada em todas as dimensões (valor vendido). Medida semiaditiva soma em algumas e não no tempo (saldo de conta, estoque: somar saldos de janeiro e fevereiro não produz nada). Medida não aditiva não soma em nenhuma (percentual, razão, média — soma-se o numerador e o denominador, nunca o quociente).

As tabelas de dimensão. Guardam os atributos descritivos, textuais e hierárquicos, pelos quais se filtra e se agrupa. São largas em colunas e curtas em linhas. Três recebem nome próprio e caem: conformada, a mesma dimensão compartilhada por várias tabelas de fatos, o que torna possível o drill across; degenerada, sem tabela, residente na fato; e junk ou lixo, que reúne indicadores esparsos em uma tabela só.

As dimensões que mudam devagar (SCD). O atributo descritivo muda — o cliente troca de cidade — e é preciso decidir o que fazer com a história. Tipo 0: não muda, o valor original é preservado. Tipo 1: sobrescreve, e o histórico se perde. Tipo 2: insere uma nova linha, com chave substituta nova e marcadores de vigência, preservando a história. Tipo 3: guarda o valor anterior em uma coluna adicional, preservando apenas a versão imediatamente anterior.

Os esquemas. No estrela, cada dimensão é uma única tabela desnormalizada, ligada diretamente à fato. No floco de neve, as dimensões são normalizadas e quebradas em tabelas de hierarquia encadeadas — município aponta para estado, que aponta para região. Na constelação de fatos, várias tabelas de fatos compartilham dimensões conformadas; é a organização normal de um data warehouse maduro, e por isso não existe o limite de uma fato por modelo.

O cubo e suas operações. O cubo organiza as medidas em n eixos de análise — o nome é metáfora, não limite de três dimensões. Sobre ele: drill down desce na hierarquia e detalha; roll up (ou drill up) sobe e agrega; slice seleciona valores ou intervalos de uma dimensão, recortando o cubo; dice faz o mesmo recorte em várias dimensões ao mesmo tempo; pivot gira os eixos da tabulação cruzada; drill across vai lateralmente para outra tabela de fatos no mesmo nível de detalhe, exigindo dimensões conformadas; drill through abandona o cubo e busca o detalhe no sistema de origem.

Onde o cubo mora. MOLAP carrega os dados em estrutura multidimensional proprietária, com agregações pré-calculadas — rápido, porém limitado em volume e preso a um formato específico. ROLAP deixa tudo em tabelas relacionais, em esquema estrela, e traduz a consulta multidimensional para SQL — escala melhor e responde mais devagar. HOLAP combina os dois: detalhe no relacional, agregados no cubo.

A otimização. Três técnicas caem juntas: particionamento da tabela de fatos por período, que permite descartar partições inteiras fora da janela consultada; índice bitmap sobre as chaves dimensionais, indicado por causa da baixa cardinalidade e da combinação de predicados por operações de bits; e agregações pré-calculadas ou visões materializadas, que trocam espaço por tempo de resposta.

O que decide os itens

Fato × dimensão — a fronteira que sozinha resolve 16 itens:

	tabela de fatos	tabela de dimensão
guarda	medidas e chaves estrangeiras	atributos descritivos e hierarquias
verbo	mede, quantifica, soma	descreve, qualifica, contextualiza
tamanho	a maior do modelo; cresce por evento	pequena; uma linha por entidade
chave	composta, formada pelas chaves das dimensões	chave substituta simples
colunas	poucas, numéricas	muitas, textuais
cardinalidade	muitas linhas	poucas linhas

Estrela × floco de neve — decore a linha inteira, porque a banca troca um adjetivo só:

	estrela	floco de neve
dimensões	desnormalizadas	normalizadas
tabelas por dimensão	uma	várias, encadeadas por hierarquia
redundância	aceita	eliminada
junções na consulta	menos (uma por dimensão)	mais
espaço ocupado	maior	menor
tempo de resposta	melhor	pior

As operações do cubo — organize pelo eixo, não pelo nome:

eixo	operações	o que muda
vertical (nível de detalhe)	drill down, roll up / drill up	desce ou sobe na hierarquia da dimensão
horizontal (recorte, mesmo detalhe)	slice, dice	filtra valores ou intervalos das dimensões
lateral (outro conjunto de dados)	drill across	vai a outra fato pelas dimensões conformadas
rotação	pivot	troca os eixos da tabulação cruzada
saída do cubo	drill through	busca o detalhe na base de origem

MOLAP × ROLAP × HOLAP — a inicial diz onde o dado mora:

	armazena em	ponto forte	ponto fraco
MOLAP	cubo multidimensional proprietário	desempenho; agregação pronta	volume limitado; formato específico
ROLAP	tabelas do banco relacional	escala; muitos atributos	mais lento; depende de SQL
HOLAP	detalhe relacional + agregado em cubo	meio-termo	complexidade de administração

OLTP × OLAP:

	OLTP	OLAP
finalidade	registrar a operação	apoiar a decisão
modelo	entidade-relacionamento normalizado	dimensional desnormalizado
complexidade do esquema	maior (dezenas ou centenas de tabelas)	menor (uma fato e suas dimensões)
operação típica	inserção e atualização; transações curtas	consulta e agregação; leituras longas
dado	atual e detalhado	histórico e agregado

Slowly changing dimension — a pergunta é sempre a mesma, o histórico sobrevive?

tipo	o que faz	histórico
0	não altera; preserva o valor original	congelado
1	sobrescreve o valor antigo	perdido
2	insere nova linha versionada	preservado, completo
3	cria coluna com o valor anterior	preservado, só a versão anterior

Aditividade das medidas:

tipo	soma em	exemplo
aditiva	todas as dimensões	valor vendido, quantidade
semiaditiva	todas, menos o tempo	saldo, estoque, número de clientes
não aditiva	nenhuma	percentual, razão, média

Como a CEBRASPE derruba você aqui

Dos 51 itens, 25 são Errados, e em 19 deles a banca não inventou conteúdo nenhum: ela colou o nome errado em uma definição correta — 11 itens — ou virou a direção de um par — 8. O resto é cauda: generalização (3), atribuição errada (2) e causalidade inventada (1). Traduzido para o vocabulário do assunto, isso quer dizer que aqui não se estuda para reconhecer absurdo; estuda-se para reconhecer troca. As cinco famílias abaixo, mais três caudas soltas, cobrem os 25.

A definição certa com o nome errado — 5 itens, e todos de operação OLAP. É a maior família do corpus. “a operação de drill down” assinando a descrição de slice; “a funcionalidade drill-down retira os dados filtrados por valor ou intervalo”, que é dice; “vão além do nível de granularidade existente” atribuído ao drill across, que é lateral e mantém o grão. Uma vez a banca inverteu a direção pura: “do nível mais baixo da hierarquia de dados de um esquema para níveis mais altos” chamado de drill-down — o down está no nome. Uma vez inventou nomes: “Roll-down, Drill-up, Peach e Push-up”. A defesa é ler a frase de trás para diante: identifique o que está descrito e só depois confira o nome que o item deu. Quem lê na ordem natural aceita o nome e julga apenas o conteúdo, que está correto.

As siglas irmãs trocadas — 4 itens, todos MOLAP contra ROLAP. “fisicamente e em formato relacional” dito de MOLAP; “O OLAP multidimensional (MOLAP) é o resultado de um banco de dados OLAP implementado sobre um banco de dados relacional existente”; e o inverso, ROLAP que armazena “exclusivamente em estruturas multidimensionais, como cubos OLAP, ignorando bancos de dados relacionais”. Há ainda a variante ortográfica: MOLAP que aceitaria “dados multimídia, não havendo necessidade de se usar formato específico” — multidimensional virou multimídia. Defesa mecânica: ache a palavra relacional ou multidimensional na frase e confira se ela combina com a inicial da sigla.

A fronteira fato × dimensão invertida — 3 itens. “A tabela de fatos de um modelo dimensional descreve as dimensões com sua semântica” — descrever é verbo de dimensão. “as tabelas de dimensões são sempre as maiores tabelas do modelo dimensional” — a fato é a maior. E a versão mais elaborada, em item com tabelas apresentadas no enunciado: a fato “deveria conter informações detalhadas acerca do nome do juiz e do ano de referência” para dispensar as dimensões. Leia o verbo antes do substantivo: medir, somar e quantificar pertencem à fato; descrever, qualificar e contextualizar pertencem à dimensão.

A negação de uma função que a tecnologia tem — 4 itens. “OLAP possui a vantagem de não requerer reestruturação de dados em um esquema estrela/snowflake”; cubos que permitiriam “apenas análises pré-definidas, inviabilizando operações ad hoc”; otimização que “dispensa o uso de índices, uma vez que operações OLAP dependem exclusivamente de varreduras completas”; e o cubo visto “em somente uma dimensão”. É a modalidade restritiva do padrão geral de TI e aqui ela se confirma: 11 dos 25 itens errados carregam apenas, somente, exclusivamente, sempre ou uma negação, contra 3 dos 26 Certos — e, desses três, o mais instrutivo é “a dimensão tempo sempre será parte integrante dessa chave”, Certo, porque o absoluto é da doutrina dimensional, não do redator. A pergunta certa nunca é “há um absoluto?”, e sim “de quem é o absoluto?”.

O par estrela × floco de neve, com um adjetivo trocado — 3 itens errados de 5 que dependem do eixo. “caracterizado pela normalização de suas tabelas dimensionais”, dito do estrela. “seu desempenho é melhor que o do modelo estrela”, dito do floco de neve — nesse item, a metade sobre normalização e tamanho está correta, e só a comparação de desempenho quebra. E “os principais modelos de dados relacionais”, quando estrela e floco são esquemas dimensionais. Os dois itens Certos do mesmo eixo mostram o que a banca aceita: enunciar a diferença na direção certa (“o modelo snowflake utiliza dados normalizados, enquanto o modelo estrela utiliza dados não normalizados”) ou enunciar a troca completa, com ganho e custo (“apesar de poupar espaço de armazenamento, a modelagem snowflake é contraindicada para consultas com alta demanda”). Item que conceda as duas vantagens ao mesmo esquema desfez a troca e está errado.

Três caudas soltas, que não formam família. A modelagem dimensional colada ao mundo transacional, em 2 itens — “o modelo dimensional surgiu para atender os sistemas transacionais (OLTP)” e esquemas dimensionais “mais complexos que os dos modelos relacionais utilizados nos sistemas que processam transações on-line”. Os limites fabricados, em 1 — “limitada a uma métrica aditiva por dimensão e a uma tabela fato por modelo”, tetos que não existem na disciplina. E duas finalidades emprestadas de outro modelo: o estrela que existiria “visando tornar aqueles dados mais representativos em semântica e construções de modelagens por meio de nós e suas ligações”, que é modelo semântico ou de grafos, e o operador CUBE que devolveria “três dimensões: colunas, linhas e metadados”, quando ele devolve os subtotais de todas as combinações dos atributos agrupados — e metadado nunca é dimensão de análise.

Onde a evidência é fina. SCD aparece em um único item (tipo 2 descrito como se fosse tipo 1) e aditividade em um único item, e ainda assim como limite inventado. As tabelas desses dois assuntos nesta nota são disciplina, não frequência medida: estude-as porque a prova pode cobrá-las amanhã, não porque elas tenham caído ontem.

Erros clássicos

Achar que “cubo” significa três dimensões. O nome é metáfora. Um cubo tem tantas dimensões quantas forem as perspectivas modeladas, e item que fixe o número em três — ou que inclua metadados na lista de dimensões — está errado.

Esperar que alguma operação desça abaixo do grão. Nenhuma desce. O grão é o piso do modelo dimensional. A única forma de obter detalhe que a fato não armazena é sair do cubo pelo drill through, indo ao sistema de origem.

Trocar drill across por drill down. Drill across é lateral: outra tabela de fatos, mesmo nível de detalhe, ligadas por dimensões conformadas. Quem confunde os dois erra também a razão pela qual as dimensões conformadas existem.

Colocar atributo descritivo na tabela de fatos “para otimizar”. O ganho prometido não existe e o custo é real: o texto se repete em milhões de linhas, infla a maior tabela do modelo e destrói o ponto de contexto único da dimensão.

Confundir operar o cubo com alterar o cubo. Navegar por drill down e slice é livre e imediato dentro da estrutura existente. Mudar a estrutura — acrescentar dimensão, hierarquia ou medida — invalida as agregações e exige reprocessamento completo.

Somar o que não é aditivo. Saldo e estoque não se somam ao longo do tempo; percentual e média não se somam em nenhuma dimensão. Item que trate toda medida como aditiva ignorou a classificação.

Trocar SCD tipo 1 por tipo 2. Sobrescrever e perder o histórico é tipo 1. Criar linha nova e guardar o histórico é tipo 2. Antes de olhar o número, pergunte se o histórico sobreviveu.

Supor que o data warehouse tem uma só tabela de fatos. Várias fatos compartilhando dimensões conformadas formam a constelação de fatos, que é o arranjo normal de um data warehouse corporativo.

Ler “implementado em banco relacional” como “é um modelo relacional”. O esquema estrela roda sobre um SGBD relacional e continua sendo um esquema dimensional. O modelo relacional se descreve por relações, chaves, dependências funcionais e formas normais.