Pular para o conteúdo principal

Questão de Banco de Dados — DW - Data Warehouse — FGV 2026

Banco de DadosDW - Data Warehouse
Código
fg129176
Banca
FGV
Órgão
AMAZUL
Ano
2026
Nível
Superior
Cargo
Engenheiro de Computação
Em um sistema de Data Warehouse, a equipe de BI precisa criar um modelo dimensional para análise de vendas por produto, região e tempo.Considerando a modelagem multidimensional, assinale a opção que apresenta corretamente a estrutura que é mais adequada para organizar os dados, de forma que permita análises OLAP eficientes com agregações em diferentes níveis de granularidade.
  1. AModelo relacional normalizado em 3FN com tabelas de junção
  2. BModelo de grafo com nós representando entidades e arestas representando relacionamentos
  3. CModelo entidade-relacionamento estendido com herança e generalização
  4. DModelo estrela (Star Schema) com tabela fato central e dimensões desnormalizadas
  5. EModelo de documento JSON com estruturas aninhadas e flexíveis
Revelar gabarito e comentário

GabaritoD — Modelo estrela (Star Schema) com tabela fato central e dimensões desnormalizadas

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Modelagem dimensional para Data Warehouse

Gabarito: letra D. O modelo estrela (Star Schema) é a estrutura mais adequada para análises OLAP em um Data Warehouse, pois centraliza os dados em uma tabela fato com chaves estrangeiras para tabelas dimensão desnormalizadas, permitindo agregações eficientes em diferentes níveis de granularidade. Essa é a abordagem consagrada por Kimball para suportar consultas multidimensionais rápidas e flexíveis.

A modelagem dimensional contrasta com modelos normalizados (como 3FN) porque prioriza a performance de leitura e a facilidade de navegação analítica, em vez da eliminação de redundância típica de sistemas transacionais (OLTP). O Star Schema é o padrão mais utilizado em projetos de Business Intelligence, juntamente com o Snowflake Schema (que normaliza as dimensões).

Alternativa A — ❌ Incorreta

O modelo relacional normalizado em 3FN com tabelas de junção é projetado para sistemas OLTP, onde o foco é a integridade e eficiência em operações de escrita (INSERT/UPDATE/DELETE). Em um DW, a normalização excessiva gera muitas junções (joins), degradando o desempenho de consultas agregadas — exatamente o oposto do que se deseja em OLAP. A redundância controlada do Star Schema é intencional para acelerar as consultas.

Alternativa B — ❌ Incorreta

Modelos de grafo são adequados para representar relacionamentos complexos e conexões entre entidades (redes sociais, recomendação, fraudes), mas não são otimizados para agregações hierárquicas como vendas por produto, região e tempo. Eles carecem das estruturas de cubo e hierarquias dimensionais típicas do DW.

Alternativa C — ❌ Incorreta

O modelo entidade-relacionamento estendido com herança e generalização é uma técnica de modelagem conceitual, útil na fase de projeto, mas não é uma estrutura pronta para consultas OLAP. Ele não oferece os mecanismos de agregação e navegação multidimensional que o Star Schema proporciona (drill-down, roll-up, slice, dice).

Alternativa D — ✅ Correta ⟵ GABARITO

O Star Schema consiste em uma tabela fato central, que armazena as medidas (ex.: valor de venda, quantidade), e tabelas dimensão desnormalizadas ao redor (ex.: produto, região, tempo). As dimensões são desnormalizadas propositalmente para evitar joins extras, garantindo consultas rápidas e eficientes. Esse modelo é o mais recomendado para ferramentas OLAP, pois permite agregações em qualquer combinação de dimensões com alto desempenho.

PEGA ESSA DICA!

Em provas de DW, lembre-se: Star Schema = tabela fato + dimensões desnormalizadas; Snowflake Schema = tabela fato + dimensões normalizadas. O Star Schema é mais comum e mais rápido em consultas, enquanto o Snowflake economiza espaço mas aumenta a complexidade dos joins.

Alternativa E — ❌ Incorreta

Modelos baseados em documentos JSON são típicos de bancos NoSQL (como MongoDB), que oferecem flexibilidade de esquema. No entanto, não são projetados para análises OLAP eficientes com agregações hierárquicas e multidimensionais. Eles não possuem conceitos nativos de fatos e dimensões, nem suporte a drill-down/roll-up otimizado.

Gabarito: letra D.

Link permanente: /questoes/fg129176