← tópicos

Específicos · Bancos de Dados

BI: DW (Inmon × Kimball), ETL × ELT, Data Mart, Data Lake, Lakehouse, Data Mesh

Quase todo item deste tópico se resolve por duas perguntas: o ambiente é operacional ou analítico, e o esquema é aplicado na escrita ou na leitura.

Média132 itens no tópico

A ideia que organiza o assunto

O banco que sustenta a operação do dia a dia foi projetado para uma coisa: registrar transações curtas, muitas, concorrentes e corretas. Ele é normalizado para não guardar o mesmo dado duas vezes, ele muda a cada segundo, e a pergunta que ele responde bem é “qual é o saldo desta conta agora”.

A pergunta do negócio é outra: “como a inadimplência evoluiu por região nos últimos cinco anos”. Respondê-la no banco operacional é pedir uma varredura de milhões de linhas com uma dúzia de junções, sobre dados que mudam enquanto a consulta corre, espalhados por seis sistemas que chamam o mesmo cliente por três códigos diferentes. Todo o assunto nasce dessa incompatibilidade. O ambiente analítico não é um banco maior: é um banco construído por oposição ao operacional, invertendo deliberadamente cada decisão de projeto.

o operacional éo analítico é
volátil — muda a cada operaçãonão volátil — carregado, não alterado
do agorahistórico, variável no tempo
por sistema (vendas, RH, crédito)orientado por assunto e integrado
normalizado, para escreverdimensional e desnormalizado, para ler
transação (OLTP)análise multidimensional (OLAP)

Essa coluna da direita são as quatro propriedades clássicas do data warehouse — orientado por assunto, integrado, não volátil e variável no tempo — e elas não são um decorado à parte: são o resultado de inverter o banco transacional. Guardada a oposição, metade dos itens se responde sem saber mais nada. Se a frase puser atualização em tempo real, exclusão frequente, transação diária, deadlock ou normalização dentro do data warehouse, ela mudou de coluna.

A segunda pergunta organiza o resto. Quando o esquema é imposto: na escrita ou na leitura? O data warehouse decide a estrutura antes de carregar — por isso o dado precisa ser transformado antes de entrar, e por isso existe o ETL. O data lake guarda o dado bruto no formato nativo e só impõe estrutura quando alguém o consome — e é exatamente por isso que o ELT, que carrega primeiro e transforma depois, pertence à era do lake. As duas perguntas — qual ambiente, qual momento do esquema — cobrem quase todo o tópico.

Por que se usa (e o que custa)

O data warehouse entrega uma versão única e reconciliada da verdade: o dado passou por limpeza, padronização e integração, o histórico é estável e a mesma consulta feita amanhã devolve o mesmo número. Paga-se em rigidez e em prazo — é preciso modelar antes de carregar, e toda fonte nova custa um projeto de ETL. Paga-se também em redundância deliberada: desnormaliza-se para evitar junções, o que é tolerável justamente porque ninguém escreve concorrentemente ali.

O data lake entrega o oposto: ingere qualquer formato imediatamente, sem modelagem prévia, e preserva o dado bruto para perguntas que ainda não foram formuladas. Paga-se em governança — sem catálogo, linhagem e controle de qualidade, o lake vira o pântano de sempre, cheio de arquivos que ninguém sabe interpretar. O custo que o lake economiza na entrada ele cobra na saída, de cada consumidor.

Daí a fórmula honesta para a prova: o warehouse troca flexibilidade por confiabilidade; o lake troca confiabilidade por flexibilidade. Item que anuncia o ganho de um sem o custo, ou que atribui a um deles a vantagem característica do outro, é o item errado.

Como funciona

O caminho do dado. Fontes operacionais → extração → área de preparação (staging area) → transformação → carga → data warehouse → data marts → ferramentas de consulta e OLAP. A staging area fica entre as origens e os destinos, é área de trabalho e não de consulta: o usuário final não a acessa.

ETL, letra por letra. Extract lê das origens heterogêneas. Transform adequa o dado ao modelo do destino e é onde moram as subtarefas que a banca confunde entre si: limpeza (corrige e elimina duplicados), conformação (padroniza formatos e domínios de valores vindos de fontes distintas, para que possam ser comparados), junção (vincula dados semelhantes de origens diferentes), derivação (calcula um atributo novo a partir dos existentes) e agregação. Load move o resultado ao destino — e só ele move.

ETL × ELT. A letra do meio diz o que acontece em segundo lugar. No ETL transforma-se antes de carregar, em servidor próprio, com staging; no ELT carrega-se o dado bruto e transforma-se dentro do destino, usando o poder de processamento elástico dele. Daí as vantagens que a banca enuncia para o ELT: carregamento mais rápido e menos infraestrutura intermediária a manter.

Como o data warehouse se atualiza. Duas arquiteturas, distintas por quem toma a iniciativa: controlada por destino, em que o DW solicita periodicamente dados novos às fontes; controlada por origem, em que a fonte notifica ou envia a alteração assim que ela ocorre. A carga pode ser total, incremental por CDC (change data capture, que captura só o que mudou, no momento em que muda, e transporta o delta com baixa latência) ou contínua em fluxo. Nenhum desses regimes é obrigatório — e é aí que a banca põe o exige.

Data warehouse, data mart, data lake. O escopo separa os três:

OLAP. Analisa o cubo por operações de navegação: drill down desce na hierarquia da dimensão e detalha; roll up (ou drill up) sobe e agrega; slice fixa um valor em uma dimensão, recortando uma fatia; dice restringe faixas em várias dimensões ao mesmo tempo; pivot (ou rotação) gira os eixos para trocar a perspectiva. Quanto ao armazenamento, a primeira letra da sigla entrega a resposta: ROLAP guarda em banco relacional e traduz a consulta em SQL; MOLAP guarda em banco multidimensional (MDDB), em cubos pré-agregados; HOLAP é híbrido — agregado no multidimensional, detalhe no relacional.

A vizinhança, que aqui não é tão vizinha assim. As formas do esquema — fato × dimensão, estrela × floco de neve, granularidade — têm nota própria, a de modelagem multidimensional, mas dezesseis itens deste tópico as cobram, e nove deles são Errados: vá lá para a profundidade e guarde daqui o mínimo que os decide. A tabela de fatos guarda as medidas e as chaves estrangeiras, é a maior do esquema; os atributos descritivos (data da venda, nome do cliente) são das dimensões. O esquema estrela é um fato central ligado às dimensões por chaves. E granularidade é o inverso do detalhe: quanto mais detalhe, mais baixa a granularidade. Mineração de dados é ainda mais frequente — dezessete itens — e o que basta guardar é a separação por rótulo: classificação exige classes predefinidas, agrupamento não tem rótulo nenhum, associação procura co-ocorrência, regressão prevê valor numérico. O ecossistema de processamento distribuído — Hadoop, Spark, Kafka — está na nota de Big data.

O que decide os itens

Uma advertência sobre o título deste tópico. O eixo Inmon × Kimball não decide nenhum item nos 131 medidos: o nome de Inmon não aparece uma única vez em todo o corpus deste assunto, e Kimball aparece em um item só. Também não há item sobre top-down × bottom-up, sobre dimensões conformadas ou sobre lakehouse. O que a banca cobra no lugar é o escopo — data warehouse corporativo × data mart departamental — e o regime do repositório. Vale conhecer o eixo doutrinário em uma linha (Inmon: DW corporativo normalizado primeiro, marts dependentes depois; Kimball: marts dimensionais primeiro, integrados por dimensões conformadas), mas não é ali que os pontos estão.

paro que decide
OLTP × OLAPtransação curta e concorrente × consulta longa e agregadora. Deadlock, normalização e operação diária são do OLTP
DW × data martcorporativo e integrador × departamental ou funcional
DW × data lakeesquema na escrita, dado modelado × esquema na leitura, dado bruto
ETL × ELTtransforma antes de carregar × carrega bruto e transforma no destino
Transformação × cargaadequar o dado × mover o dado para o destino
Limpeza × conformaçãoeliminar duplicados e corrigir × padronizar formatos entre fontes
Junção × derivaçãovincular dados de fontes diferentes × calcular atributo novo
ROLAP × MOLAP × HOLAPrelacional × MDDB × híbrido
Drill down × roll upmais detalhe × mais agregação
Controlada por destino × por origemo DW solicita × a fonte envia
Classificação × agrupamentoclasses predefinidas × sem rótulo algum
Staging × apresentaçãoárea de trabalho do ETL × camada consultada pelo usuário

As quatro propriedades do DW, e o que cada uma proíbe.

propriedadeo item que a viola diz
orientado por assuntoorganizado por sistema ou por aplicação
integradomantém os códigos e formatos originais de cada fonte
não volátilatualização contínua, alteração em tempo real, exclusão pelo usuário
variável no tempoguarda apenas a situação atual

Não volátil não significa parado. A propriedade diz que o que já entrou não é alterado pelo usuário — não que o DW deixe de receber cargas periódicas nem que não acumule histórico. Não volatilidade e variação no tempo convivem, e o item que usa uma para negar a outra está errado.

Nada entra na base analítica pela porta lateral. O dado chega ao ambiente de BI pela extração a partir dos sistemas transacionais; inserir informação diretamente no repositório de BI quebra a rastreabilidade e produz número que não se reconcilia com origem nenhuma.

Nas definições de BI e de DSS, o verbo decide. Apoiar, subsidiar, permitir análise interativa, possibilitar manipulação dos dados pelo analista: Certo. O sistema substituir o julgamento humano, decidir sozinho, dispensar o analista: Errado. O DSS combina dados, modelos e interface sob controle do usuário — a autonomia do decisor faz parte da definição.

Como a CEBRASPE derruba você aqui

Medido sobre os 131 itens do tópico, todos explicados: 75 Certos e 56 Errados. Nos 56 Errados: inversão 21 (38%), troca de termo 20 (36%), generalização 8 (14%) e atribuição errada 7 (13%). Mais nada — nenhum item erra um número, nenhum inventa uma causa, nenhum estende o escopo. Este é um tópico de vocabulário, e a banca o ataca por um caminho só.

O rótulo diz “inversão”; a frase útil é outra: a banca não erra o conceito, ela dá a propriedade de um repositório ao outro. Treze dos 21 itens invertidos são exatamente isso, e se dividem em duas famílias.

A primeira, e a mais repetida do tópico inteiro: o data warehouse descrito como se fosse o banco transacional. Seis itens: “os data warehouses caracterizam-se pela volatilidade, já que neles as informações armazenadas são alteradas com muito mais frequência”; “os data warehouses são mais voláteis”; “repositório de dados dinâmico, que sofre alterações frequentes”; “em um ambiente de atualização contínua, no qual as informações são alteradas em tempo real”; “constantemente atualizado a partir dos sistemas de fontes de dados, em horário comercial, em tempo real e com queries diretas aos bancos em produção”; “é projetado para suportar operações transacionais diárias”. Um sétimo transporta para o DW um problema que é do OLTP: “a ocorrência de deadlocks causados por grande fluxo de dados é um fator crítico”. Todos caem com a mesma pergunta: esse comportamento é de quem escreve ou de quem lê?

A segunda: o data lake com o regime do data warehouse, ou o contrário. Sete itens, e o eixo é sempre o momento do esquema: o lake que “deve armazenar dados já transformados e normalizados, evitando a ingestão de dados brutos”; o lake que “requer que todos os dados sejam estruturados e limpos antes de serem armazenados”; dados “refinados em processos anteriores” dados como característica do lake; o lake que “não oferece suporte para dados semiestruturados e não estruturados”; o data warehouse como repositório “em que os dados podem ser armazenados em formatos variados”; e as origens que “devem ser abrigadas em plataformas diferentes” quando o lake existe justamente para reuni-las. Pergunte quando o esquema é imposto — na escrita é warehouse, na leitura é lake — e os sete caem juntos.

Troca de termo, 20 itens, e a etapa do ETL é o alvo preferido. A banca descreve corretamente uma subtarefa e lhe dá o nome da vizinha. O par junção × derivação sozinho rende três itens: “a técnica de derivação” para vincular dados semelhantes de fontes distintas; “a derivação, em que são vinculados dados semelhantes”; “A técnica de junção do ETL” para criar atributo novo a partir dos existentes. O par transformação × carga rende dois: “Transformação é o processo de gravar os dados”; “a etapa de transformação é responsável por mover os dados extraídos para o sistema de destino”. Somam-se “A extração converte registros” (converter é transformar) e “o processo de conformidade” para eliminar duplicados (isso é limpeza). Fora do ETL, o mesmo movimento: “o ROLAP usa MDDB” e o MOLAP que “armazena os dados exclusivamente em estruturas multidimensionais… ignorando bancos relacionais” descrito como ROLAP; “bases centralizadas e corporativas que integram dados de diferentes áreas” chamadas de data marts; “classificar dados em categorias predefinidas” chamado de agrupamento; OLAP posto a “desempenhar funções empresariais cotidianas”. Leia a descrição primeiro, ignorando o nome, decida de que conceito ela é, e só então volte ao sujeito da frase. Quando a descrição estiver impecável, é no sujeito que está o erro.

Restrição indevida, 8 itens — menos do que a intuição sugere, e é bom saber disso antes da prova. Ela fecha uma alternativa que o conceito mantém aberta: a carga que “exige que os dados sejam carregados em lotes programados” (lote, incremental e contínua são todas admissíveis); a mineração para a qual “é necessário que esse processo seja executado dentro dos data warehouses”; o DW que “deve conter apenas dados atualizados” (variação no tempo é o oposto); o sistema de apoio que “pode substituir o julgamento humano em todos os casos”; a mineração que “limita-se na predição dos eventos futuros”; o viés algorítmico como “preocupação restrita à fase de desenvolvimento”.

Mas a palavra absoluta, sozinha, não decide nada aqui — e isso é medido. Nove dos 75 itens Certos carregam apenas, somente, deve, sem que haja ou desde que, contra onze dos 56 Errados. Em quase metade das vezes o absoluto está num item Certo, e a diferença é sempre de quem ele é: “A desnormalização é apenas tolerável quando houver imperativos rígidos de desempenho” é doutrina de projeto; “deve ser precedida pela definição de metas e requisitos” é o DMBOK; “sem que haja acréscimo de informações diretamente da base de BI” é a arquitetura falando. A pergunta útil nunca é “há um absoluto na frase?”, e sim “de quem é esse absoluto?”.

Atribuição errada, 7 itens: a ação existe, o componente é outro. “Um data warehouse usa técnicas estatísticas e de aprendizagem automática” (quem analisa é a mineração; o DW armazena); a modelagem dimensional como “um tratamento aplicado na transformação de dados em ETL” (é projeto do modelo, não etapa de carga); “sendo o OLTP uma ferramenta de software cuja função é a extração de dados de diversos sistemas” (o OLTP é a fonte; quem extrai é o ETL); o OLTP usado “como armazenamento temporário” no lugar da área de estágio; a otimização “no processamento de transações online” atribuída ao BI; e a data da venda e o nome do cliente apresentados como conteúdo da tabela de fatos (são atributos de dimensão).

Uma advertência sobre o que este tópico não cobra, agora medida sobre os 131. O eixo Inmon × Kimball não decide nada: o nome de Inmon não aparece uma única vez no corpus, e Kimball aparece em um item, Errado, em que o modelo dimensional é descrito como “estruturas normalizadas” — quem é normalizado é o relacional OLTP. Também não há item sobre top-down × bottom-up, sobre dimensões conformadas ou sobre lakehouse (zero ocorrências em 131). O que a banca cobra no lugar é o escopo — warehouse corporativo × mart departamental — e o regime do repositório.

O que o título também não anuncia, mas cai. Dezesseis itens tocam fato, dimensão, esquema estrela e granularidade — nove deles Errados —, ainda que o assunto tenha nota própria: a granularidade invertida (“quanto mais detalhes, mais alto o nível de granularidade” — é o contrário), a tabela de fatos recheada de atributos descritivos, o modelo dimensional chamado de normalizado, a arquitetura de eixos e raios atribuída ao “data warehouse centralizado”. Dezessete itens são de mineração e aprendizado de máquina (classificação × agrupamento, associação, árvore de decisão, KDD, CRISP-DM, monitoramento de modelo em produção). E um punhado é de banco de dados puro — escalabilidade de relacional × NoSQL, banco em memória, grafos, MapReduce, tabelas imutáveis do Oracle 21c e até uma sintaxe de ALTER TABLE. Não é ruído a ignorar: é um sexto do tópico.

Uma advertência de calendário, essa não medida em frequência: os cadernos deste corpus vão de 2016 a 2026, e o vocabulário recente — ELT, data lake, MLOps, BI 3.0 — só aparece nos editais de 2021 em diante, que concentram a maior parte dos itens. Se o lakehouse aparecer, é como convergência dos dois modelos — armazenamento de objetos do lake com transações, esquema e governança do warehouse.

Erros clássicos

Praticar131 itens