Data Warehouse e Data Mart

O que mais cai

Do que trata o tópico

Este tópico trata do armazém de dados que uma organização monta para analisar a própria história e tomar decisões. Ele cobre o Data Warehouse e o Data Mart, a modelagem dimensional que organiza os dados em fatos e dimensões, o processo ETL que leva os dados dos sistemas de origem até o armazém e o OLAP, que é a forma de consultar esses dados por vários ângulos. O tópico fecha com a comparação entre OLAP e OLTP, que é o sistema do dia a dia que registra cada operação.

Conteúdo

Definições e funções de Data Warehouse e Data Mart

Um órgão público tem vários sistemas: um de protocolo, um de recursos humanos, um de folha de pagamento e um de compras. Cada sistema guarda os dados do seu jeito, com códigos próprios e só com a situação de hoje. Quando a direção pergunta quanto o órgão gastou com cada setor nos últimos cinco anos, nenhum desses sistemas responde sozinho, e uma consulta pesada num deles deixa o atendimento lento. O Data Warehouse (DW, armazém de dados) resolve esse problema: ele é um banco de dados separado, feito para análise, que junta os dados de todos os sistemas num formato único e guarda o histórico.

A definição mais cobrada é a de Bill Inmon. Para ele, o Data Warehouse é um conjunto de dados orientado por assunto, integrado, variante no tempo e não volátil, que apoia o processo de decisão da gerência. Cada uma dessas quatro características tem um sentido preciso, e a banca troca uma delas pela característica oposta.

• Orientado por assunto: os dados se organizam pelos grandes temas do negócio (cliente, produto, venda, servidor), e não pelas aplicações que os geraram (sistema de protocolo, sistema de folha).
• Integrado: os dados de origens diferentes passam a seguir um padrão só de nomes, códigos, formatos e unidades. Se um sistema grava o sexo como "M" e "F" e outro grava como "1" e "2", o DW guarda uma forma só.
• Variante no tempo: todo dado do DW está ligado a um momento ou período, e o DW guarda um horizonte longo, de vários anos. O sistema de origem mostra o salário de hoje; o DW mostra o salário de cada mês.
• Não volátil: depois que entra, o dado não é alterado nem apagado pelo usuário. O DW recebe cargas periódicas e consultas, e não as operações de inserção, alteração e exclusão de cada transação.

A não volatilidade é a característica mais trocada em prova. Ela não quer dizer que o DW nunca muda: o DW cresce a cada carga, e a equipe técnica pode corrigir um erro de carga. Ela quer dizer que o usuário de negócio não atualiza registro por registro, como faz no sistema de cadastro.

A granularidade é o nível de detalhe do dado guardado. Uma granularidade fina guarda cada venda, item por item; uma granularidade grossa guarda só o total vendido por mês. Quanto mais fina a granularidade, mais perguntas o DW responde e mais espaço ele ocupa.

Na terminologia de Inmon, quanto maior o nível de granularidade, menor o detalhe: o total mensal tem granularidade alta, e a venda item por item tem granularidade baixa. Essa inversão engana quem lê "alta granularidade" como "muito detalhe".

O Data Mart (DM) é um recorte do armazém voltado para uma área ou um departamento, como o financeiro, o de vendas ou o de recursos humanos. Ele é menor, tem menos assuntos, fica pronto mais rápido e custa menos.

Os Data Marts se dividem em dois tipos pela origem dos dados. O Data Mart dependente recebe os dados do Data Warehouse corporativo, que já está integrado. O Data Mart independente recebe os dados direto dos sistemas de origem, sem passar por um DW central. Vários Data Marts independentes, cada um com seus próprios códigos, tendem a dar números diferentes para a mesma pergunta, e o mercado chama esse problema de "ilhas de dados".

Duas linhas de projeto disputam a forma de construir o armazém. Bill Inmon defende a construção de cima para baixo (top-down): primeiro se monta o Data Warehouse corporativo, integrado e normalizado, e depois se tiram dele os Data Marts dependentes. Ralph Kimball defende a construção de baixo para cima (bottom-up): a equipe entrega um Data Mart dimensional por processo de negócio, e os Data Marts se ligam por dimensões conformadas, isto é, dimensões com o mesmo conteúdo e o mesmo significado em todos eles.

Na visão de Kimball, o Data Warehouse é a união dos Data Marts ligados por essas dimensões comuns. A matriz que mostra quais processos usam quais dimensões se chama matriz de barramento (bus matrix), e a arquitetura se chama arquitetura de barramento. Na visão de Inmon, o DW central fica em modelo normalizado (próximo da terceira forma normal), e só os Data Marts usam o modelo dimensional.

Ao redor do DW aparecem outras peças que a banca cita. A staging area (área de preparação) é o espaço onde o ETL deixa os dados enquanto os trata, sem acesso do usuário final. O ODS (Operational Data Store, armazenamento de dados operacionais) guarda dados integrados e atuais, com atualização frequente, para consultas operacionais rápidas; ele é volátil e tem pouco histórico, ao contrário do DW. Os metadados são os dados sobre os dados: a origem de cada campo, a regra de transformação aplicada, a data da última carga e o significado de cada medida.

Exemplo resolvido: uma secretaria de saúde quer saber se cada característica de Inmon está presente num banco que ela já tem.

1. Entrada: o banco junta os atendimentos de três sistemas, com o código do município no mesmo padrão. Saída: o banco é integrado.
2. Entrada: o banco organiza as tabelas por paciente, atendimento e unidade de saúde. Saída: o banco é orientado por assunto.
3. Entrada: cada atendimento tem a data e o banco guarda dez anos. Saída: o banco é variante no tempo.
4. Entrada: a recepção altera o endereço do paciente no próprio banco a cada consulta. Saída: o banco não é não volátil, porque o usuário atualiza registro por registro.
5. Resultado: o banco tem três das quatro características. Como falta a não volatilidade, ele não é um Data Warehouse no sentido de Inmon. Ele também não é um ODS típico, porque o ODS é volátil e guarda só dados atuais, e este banco guarda dez anos de histórico.

Na prática, uma prefeitura que precisa só de um painel de arrecadação para a Secretaria de Fazenda pode começar por um Data Mart de arrecadação. Se a prefeitura seguir Kimball, ela projeta a dimensão de contribuinte e a dimensão de tempo já como dimensões conformadas, para que o próximo Data Mart (o de fiscalização, por exemplo) use as mesmas dimensões. Se ela seguir Inmon, ela monta primeiro o DW corporativo e tira dele o Data Mart de arrecadação.

O Data Mart é confundido com uma simples visão (view) do banco. A visão é só uma consulta guardada, sem dados próprios, e o Data Mart é um banco com dados próprios, carregados e organizados para a área.

O erro comum de quem está começando é achar que o Data Mart independente e o dependente diferem pelo tamanho. Os dois podem ter o mesmo tamanho: o que os separa é de onde vêm os dados, do DW corporativo ou direto dos sistemas de origem.

Como a banca cobra: a banca troca uma das quatro características de Inmon pela oposta (volátil, orientado por aplicação) e mistura as abordagens de Inmon e de Kimball.

Modelagem dimensional

O modelo relacional normalizado, usado nos sistemas de cadastro, divide os dados em muitas tabelas para evitar repetição. Uma pergunta simples de análise, como "quanto vendemos por categoria e por cidade em março", obriga essa estrutura a juntar dez ou quinze tabelas. A modelagem dimensional, sistematizada por Ralph Kimball, reorganiza os dados para a análise: ela põe os números que se medem numa tabela central e as descrições que dão contexto em tabelas ao redor.

A tabela fato guarda as medidas de um processo de negócio, como valor da venda, quantidade vendida, horas trabalhadas ou valor pago. Cada linha da tabela fato é um evento ou uma medição, e ela tem as chaves estrangeiras que apontam para as dimensões. A tabela fato é a maior do modelo em número de linhas e é estreita, com poucas colunas.

A tabela dimensão guarda o contexto do fato: quem, o quê, onde, quando e como. São dimensões típicas a de tempo (dia, mês, trimestre, ano), a de produto (nome, marca, categoria), a de cliente e a de loja. A dimensão tem poucas linhas em relação à tabela fato e é larga, com muitos atributos descritivos, que são os campos que o usuário usa para filtrar e agrupar.

O projeto dimensional de Kimball segue quatro passos, nesta ordem:

1. Escolher o processo de negócio. Entra o que a área quer medir; sai o processo, por exemplo "vendas no caixa".
2. Declarar a granularidade. Entra o processo; sai o que uma linha da tabela fato representa, por exemplo "um item de um cupom fiscal".
3. Identificar as dimensões. Entra a granularidade; saem as descrições que valem para cada linha (data, produto, loja, forma de pagamento).
4. Identificar os fatos. Entra a granularidade; saem as medidas de cada linha (quantidade, valor, desconto).

A granularidade vem antes das dimensões e dos fatos porque é ela que diz o que pode entrar no modelo. Se a linha é "o total do dia por loja", o produto não cabe como dimensão, porque um total diário mistura vários produtos.

As medidas da tabela fato se classificam pela possibilidade de soma. A medida aditiva pode ser somada por todas as dimensões, como o valor da venda e a quantidade vendida. A medida semiaditiva pode ser somada por algumas dimensões e não pela dimensão de tempo, como o saldo de uma conta ou o estoque: somar os estoques de várias lojas no mesmo dia faz sentido, mas somar o estoque de segunda com o de terça não faz. A medida não aditiva não pode ser somada por dimensão nenhuma, como percentuais, razões e preço unitário; o certo é guardar o numerador e o denominador e calcular a razão no fim.

As tabelas fato também se classificam pelo tipo de registro:

• Fato transacional: uma linha por evento, como cada venda.
• Fato de snapshot periódico: uma foto em intervalos regulares, como o saldo de cada conta no fim do mês.
• Fato de snapshot acumulado: uma linha por processo, com várias datas que se preenchem ao longo do caminho (pedido, faturamento, envio, entrega).
• Fato sem fatos (factless): sem medida numérica, só registra que um evento ocorreu, como a presença de um aluno numa aula.

Algumas dimensões têm nome próprio:

• Dimensão conformada: o mesmo conteúdo e o mesmo sentido em vários Data Marts, o que permite comparar os processos.
• Dimensão degenerada: um atributo que fica na própria tabela fato, sem tabela de dimensão, como o número do cupom fiscal.
• Dimensão de papel (role-playing): a mesma dimensão com papéis diferentes, como a de tempo usada como data do pedido e data da entrega.
• Dimensão lixo (junk): uma tabela que junta indicadores soltos, como "pago com cartão" e "entrega expressa".

As dimensões usam uma chave substituta (surrogate key): um número sequencial criado pelo DW, sem significado de negócio, no lugar da chave natural do sistema de origem (CPF, matrícula, código do produto). A chave substituta isola o DW das mudanças de código da origem e permite guardar várias versões do mesmo cliente, que é a base da dimensão que muda lentamente.

A dimensão que muda lentamente (SCD, Slowly Changing Dimension) é a dimensão cujos atributos mudam de vez em quando, como a cidade do cliente ou a lotação do servidor. A forma de tratar a mudança tem tipos numerados.

• Tipo 0: o atributo nunca muda no DW, mesmo que mude na origem, como a data de nascimento.
• Tipo 1: o novo valor sobrescreve o antigo, e o histórico se perde.
• Tipo 2: a mudança cria uma nova linha, com nova chave substituta, e a linha antiga fica guardada com a data de fim de vigência. O histórico é completo.
• Tipo 3: a linha ganha uma coluna para o valor anterior, e o histórico fica limitado a uma mudança.

Exemplo resolvido: a cliente Ana, de CPF fictício 111, morava em Recife e se mudou para Olinda em 01/06/2026. A dimensão usa SCD tipo 2.

1. Antes da mudança, a dimensão tem uma linha: chave 501, CPF 111, cidade Recife, início 01/01/2025, fim aberto, atual sim.
2. O ETL detecta a nova cidade na origem e fecha a linha 501, com fim em 31/05/2026 e atual não.
3. O ETL cria a linha 502, com o mesmo CPF 111, cidade Olinda, início 01/06/2026, fim aberto e atual sim.
4. Resultado: as vendas de maio continuam ligadas à chave 501 e aparecem em Recife; as vendas de junho usam a chave 502 e aparecem em Olinda.

O desenho em que a tabela fato fica no centro, ligada direto a cada dimensão, se chama esquema estrela (star schema). No esquema estrela, cada dimensão é uma tabela só, desnormalizada, e por isso a categoria do produto se repete em cada linha de produto. A repetição gasta um pouco de espaço, mas a consulta fica simples, com uma junção por dimensão.

O esquema floco de neve (snowflake) normaliza as dimensões: a dimensão de produto aponta para uma tabela de categoria, que aponta para uma tabela de departamento. Ele economiza espaço na dimensão e evita repetição, mas a consulta pede mais junções e o modelo fica mais difícil para o usuário. A diferença entre estrela e floco de neve está só nas dimensões: a tabela fato é a mesma nos dois.

Quando o modelo tem várias tabelas fato que compartilham dimensões conformadas, o desenho se chama constelação de fatos ou esquema galáxia.

Exemplo resolvido: um esquema estrela de vendas tem a fato_vendas e duas dimensões. A dim_produto tem (1, Caderno, Papelaria), (2, Caneta, Papelaria) e (3, Mochila, Acessórios). A dim_loja tem (10, Recife) e (20, Olinda).

SELECT p.categoria, l.cidade, SUM(f.valor) AS total
FROM fato_vendas f
JOIN dim_produto p ON f.id_produto = p.id_produto
JOIN dim_loja l ON f.id_loja = l.id_loja
GROUP BY p.categoria, l.cidade;

A consulta junta a tabela fato com cada dimensão por uma chave, uma junção por dimensão, como pede o esquema estrela. O GROUP BY agrupa as linhas pela categoria e pela cidade, e o SUM soma o valor de cada grupo.

1. Papelaria em Recife: linhas do caderno e da caneta, 50,00 + 40,00 = 90,00.
2. Acessórios em Recife: linha da mochila, 300,00.
3. Papelaria em Olinda: linha do caderno, 30,00.
4. Acessórios em Olinda: linha da mochila, 150,00.

Na prática, um tribunal que quer medir o tempo dos processos escolhe o processo "tramitação", declara a granularidade "uma linha por processo" e monta uma fato de snapshot acumulado, com as datas de distribuição, de sentença e de baixa. As dimensões são vara, classe processual e tempo, e a dimensão de tempo aparece em três papéis, um para cada data.

A modelagem dimensional é confundida com a normalização. A normalização separa dados para evitar repetição e é a regra dos sistemas transacionais; a modelagem dimensional aceita repetição nas dimensões para ganhar simplicidade e velocidade na consulta. Dentro da modelagem dimensional, o floco de neve é a variante que volta a normalizar as dimensões.

O erro comum é pôr na dimensão uma medida que se soma, como o valor da venda, ou pôr na tabela fato um texto descritivo, como o nome do produto. Medida numérica de evento fica na fato; descrição usada para filtrar e agrupar fica na dimensão.

SELECT l.cidade, SUM(f.quantidade) AS total
FROM fato_vendas f
JOIN dim_produto p ON f.id_produto = p.id_produto
JOIN dim_loja l ON f.id_loja = l.id_loja
WHERE p.categoria = 'Papelaria'
GROUP BY l.cidade;

Como a banca cobra: a banca pede a diferença entre estrela e floco de neve, a ordem dos quatro passos do projeto e o tipo de SCD que guarda histórico. Ela também dá uma medida, como saldo ou percentual, e pergunta se ela é aditiva.

ETL (Extração, Transformação e Carga)

Os dados que o Data Warehouse precisa estão espalhados em sistemas de origem diferentes, com formatos diferentes e com erros de digitação. O ETL (Extract, Transform, Load, em português extração, transformação e carga) é o processo que tira esses dados das origens, trata e padroniza os dados e grava o resultado no DW. É o ETL que entrega a característica "integrado" de Inmon.

O ETL roda em lotes, em geral fora do expediente. Os dados passam pela staging area, a área de preparação, que é um espaço intermediário onde o ETL grava os dados extraídos e faz as transformações. O usuário final não consulta a staging area.

1. Extração. Entra o dado dos sistemas de origem (bancos de dados, planilhas, arquivos texto, serviços). Sai uma cópia na staging area. A extração pode ser completa (full), que lê tudo de novo, ou incremental, que lê só o que mudou desde a última carga.
2. Transformação. Entra o dado bruto da staging area. Sai o dado limpo, padronizado e integrado, no formato do modelo dimensional.
3. Carga. Entra o dado transformado. Sai o dado gravado nas tabelas do DW, primeiro as dimensões e depois a tabela fato.

A extração incremental usa a captura de dados de mudança (CDC, Change Data Capture), que identifica o que foi inserido, alterado ou excluído na origem. O CDC pode ler uma coluna de data de alteração, comparar cópias da tabela ou ler o log de transações do banco de origem.

A transformação concentra as regras de negócio e é a fase mais cobrada. Ela reúne várias atividades:

• Limpeza: corrige ou descarta dados com erro, campo vazio obrigatório ou valor fora da faixa.
• Padronização: põe o mesmo dado num formato só, como datas em um padrão, CPF só com dígitos e nomes em maiúsculas.
• Conversão de códigos: troca códigos diferentes da mesma coisa por um código único, como "M", "1" e "Masculino".
• Eliminação de duplicidade: junta registros que são a mesma pessoa ou o mesmo produto vindo de origens diferentes.
• Derivação: cria campos novos a partir dos existentes, como a faixa etária a partir da data de nascimento.
• Agregação: soma ou resume os dados quando a granularidade do DW é mais grossa que a da origem.
• Troca de chaves: busca a chave substituta da dimensão para cada chave natural (lookup) e grava essa chave na tabela fato.

A carga tem duas formas. A carga inicial enche o DW pela primeira vez, com todo o histórico disponível. A carga incremental acrescenta, a cada execução, só os dados novos ou alterados. As dimensões são carregadas antes da tabela fato porque a linha da fato precisa da chave substituta que já existe na dimensão.

Exemplo resolvido: o ETL de um órgão junta os servidores de dois sistemas de origem. O sistema de RH grava o CPF com pontos e o sexo em letra; o sistema de folha grava o CPF só com dígitos e o sexo em número (1 para masculino, 2 para feminino).

1. Padronização do CPF: tira pontos e traço, e 123.456.789-00 vira 12345678900.
2. Padronização do nome: põe tudo em maiúsculas, e Ana Lima vira ANA LIMA.
3. Conversão de códigos: "F" e "2" viram FEMININO; "M" e "1" viram MASCULINO.
4. Eliminação de duplicidade: a linha 1 e a linha 3 têm agora o mesmo CPF, o mesmo nome e o mesmo sexo, e viram um registro só.
5. Troca de chaves: cada CPF recebe uma chave substituta na dimensão de servidor.
6. Resultado: 4 linhas de origem viram 3 linhas na dimensão.

O ELT (Extract, Load, Transform) muda a ordem: os dados são extraídos, carregados brutos no destino e transformados lá dentro, com a capacidade de processamento do próprio destino. O ELT é comum em data lakes e em bancos em nuvem com muito poder de processamento, onde guardar o dado bruto custa pouco e permite refazer a transformação depois. No ETL, a transformação ocorre antes da carga, num servidor ou na staging area; no ELT, ela ocorre depois da carga, no destino.

Na prática, uma agência reguladora recebe todo dia arquivos das empresas fiscalizadas, cada uma com um layout. O ETL extrai os arquivos para a staging area, rejeita as linhas com CNPJ inválido e as grava num relatório de erros, converte as unidades para um padrão único e carrega primeiro a dimensão de empresa e depois a fato de indicadores.

O ETL é confundido com a simples replicação de banco. A replicação copia os dados como estão, para ter uma segunda cópia; o ETL muda os dados, integra origens diferentes e grava no formato do DW.

O erro comum é pôr a limpeza e a padronização na fase de extração ou de carga. A extração só lê e copia; a carga só grava; quem limpa, padroniza, converte, elimina duplicidade e troca chaves é a transformação.

Como a banca cobra: a banca descreve uma atividade (limpeza, conversão, eliminação de duplicidade, troca de chaves) e pergunta em que fase ela ocorre, quase sempre a transformação. Ela também troca a ordem do ETL com a do ELT e confunde carga inicial com carga incremental.

OLAP e suas diferenças com OLTP

O sistema de uma loja registra cada venda no caixa, em frações de segundo, e não pode parar. O gerente, por outro lado, quer ver o total vendido por região, por mês e por produto, e trocar de ângulo várias vezes na mesma reunião. As duas tarefas pedem sistemas diferentes: o OLTP (Online Transaction Processing, processamento de transações em tempo real) registra a operação, e o OLAP (Online Analytical Processing, processamento analítico em tempo real) analisa os dados acumulados.

O OLTP é o sistema de cadastro e de movimento do dia a dia: o sistema de protocolo, o de matrícula, o caixa da loja. Ele faz muitas transações curtas de inserção, alteração e exclusão, cada uma mexendo em poucos registros, e usa o modelo relacional normalizado para evitar repetição e manter a consistência. Ele guarda o dado atual, tem muitos usuários ao mesmo tempo e precisa de resposta rápida a cada operação.

O OLAP é a ferramenta de análise sobre o Data Warehouse ou o Data Mart. Ele faz poucas consultas, mas cada consulta lê e soma milhares ou milhões de registros, quase só para leitura. Ele usa o modelo dimensional, guarda o histórico e atende gestores e analistas que tomam decisões.

O OLAP apresenta os dados como um cubo, que é uma estrutura com várias dimensões (o cubo pode ter mais de três, apesar do nome). Cada eixo do cubo é uma dimensão, como produto, região e mês, e cada célula guarda a medida para aquela combinação, como o total vendido do produto X na região Y no mês Z. As dimensões têm hierarquias, que são os níveis de detalhe, como dia, mês, trimestre e ano na dimensão de tempo.

As operações OLAP mudam o ângulo ou o nível de detalhe do cubo:

• Drill-down (detalhar): desce na hierarquia e mostra mais detalhe, como passar do ano para os meses.
• Roll-up ou drill-up (agregar): sobe na hierarquia e resume, como passar dos meses para o trimestre.
• Slice (fatiar): fixa um valor de uma dimensão e tira uma fatia do cubo, que fica com uma dimensão a menos, como ver só o mês de março.
• Dice (cortar em cubos): escolhe um conjunto de valores em duas ou mais dimensões e tira um subcubo, como dois produtos, três regiões e dois meses.
• Pivot ou rotação: troca a posição dos eixos na tela, como pôr os meses nas linhas e as regiões nas colunas, sem mudar os dados.
• Drill-across: compara dados de cubos ou tabelas fato diferentes que compartilham dimensões conformadas.
• Drill-through: sai do cubo e vai até os dados detalhados de origem de uma célula.

Exemplo resolvido: um cubo de vendas tem as dimensões cidade e mês, com a quantidade vendida no primeiro trimestre.

1. Roll-up do mês para o trimestre em Recife: 10 + 12 + 8 = 30.
2. Roll-up do mês para o trimestre em Olinda: 5 + 7 + 6 = 18.
3. Roll-up também da cidade para o total: 30 + 18 = 48 no trimestre.
4. Slice no mês de fevereiro: a fatia mostra Recife 12 e Olinda 7, e a dimensão mês some da tela.
5. Pivot: as cidades passam para as colunas e os meses para as linhas, e os seis números continuam os mesmos.

O OLAP se classifica pela forma de guardar o cubo. O MOLAP (OLAP multidimensional) guarda o cubo num banco multidimensional próprio, com os totais já calculados; ele responde muito rápido, mas ocupa espaço e tem limite de volume. O ROLAP (OLAP relacional) guarda os dados em tabelas relacionais, no esquema estrela, e calcula os totais em SQL na hora da consulta; ele aguenta volumes maiores, mas responde mais devagar. O HOLAP (OLAP híbrido) junta os dois: os dados detalhados ficam no relacional e os totais ficam no cubo multidimensional.

Na prática, a coordenação de um programa de vacinação consulta um cubo com as dimensões município, faixa etária, vacina e semana. A coordenadora faz um slice na vacina contra gripe, um roll-up de semana para mês e um drill-down no município com a menor cobertura para ver as unidades de saúde. O sistema que registra cada dose aplicada na unidade é o OLTP; o cubo que ela consulta é o OLAP.

O OLAP é confundido com o próprio Data Warehouse. O DW é o depósito dos dados; o OLAP é a forma de consultar e analisar esses dados em cubos. A mineração de dados (data mining) é outra vizinha: ela procura padrões escondidos com algoritmos, enquanto o OLAP responde perguntas que o usuário já sabe fazer.

O erro comum é trocar slice por dice e roll-up por drill-down. O slice fixa um valor de uma dimensão só; o dice escolhe valores em duas ou mais dimensões; o roll-up sobe para o resumo; o drill-down desce para o detalhe.

Como a banca cobra: a banca atribui ao OLAP uma característica do OLTP (dado atual, modelo normalizado, muitas atualizações) ou o contrário. Ela também descreve uma operação e pede o nome dela, e troca MOLAP com ROLAP.

Quadros e comparações

A primeira tabela compara as duas abordagens de construção do armazém.

A segunda tabela compara os dois esquemas dimensionais.

A terceira tabela põe OLTP e OLAP ponto a ponto.

A quarta tabela compara os tipos de dimensão que muda lentamente.

Para decorar

Pegadinhas

Fontes e data

• [1] Literatura de referência de Data Warehouse (linhas de Bill Inmon e de Ralph Kimball), explicada com palavras próprias. O guia não usa norma técnica pública.

Texto conferido em 14/10/2026.