Pular para o conteúdo principal

Questão de Banco de Dados — Banco de Dados Multidimensionais — FGV 2026

Banco de DadosBanco de Dados Multidimensionais
Código
fg133949
Banca
FGV
Órgão
TJ-RJ
Ano
2026
Nível
Superior
Cargo
Analista Judiciário - Tecnologia da Informação - Arquiteto de Dados
Um arquiteto de dados está projetando o Data Warehouse (DW) de uma grande rede de varejo. A tabela de fatos de vendas (Fato_Vendas) deverá ser conectada a uma dimensão de produtos. A hierarquia dos produtos é complexa e profunda: Departamento → Divisão → Categoria → Subcategoria → Produto.O administrador de banco de dados (DBA), preocupado com a integridade dos dados e o espaço de armazenamento, propôs que essa hierarquia fosse modelada seguindo os princípios da normalização. Segundo a proposta, a tabela de produtos conteria apenas o ID da subcategoria, que apontaria para uma tabela de subcategorias, que, por sua vez, apontaria para uma tabela de categorias, e assim sucessivamente, evitando a repetição de textos descritivos (como o nome do departamento) em milhões de linhas de produtos.Considerando os conceitos de modelagem dimensional (Ralph Kimball) e o impacto dessa decisão na performance de consultas analíticas (OLAP), é correto afirmar que:
  1. Aa proposta do DBA configura um esquema floco de neve (Snowflake Schema); embora economize espaço em disco e facilite a manutenção da integridade referencial, essa abordagem prejudica o desempenho das consultas de Business Intelligence (BI) ao exigir múltiplas junções (joins) para recuperar a descrição completa dos atributos hierárquicos;
  2. Ba abordagem sugerida caracteriza um esquema estrela (Star Schema), que é o padrão recomendado pela metodologia Kimball, pois a normalização das dimensões garante que o motor de banco de dados utilize índices bitmap de forma mais eficiente, acelerando o filtro de consultas agregadas;
  3. Ca desnormalização completa da dimensão, consolidando todos os níveis hierárquicos em uma única tabela Dim_Produto (esquema estrela), deve ser evitada em Data Warehouses modernos baseados em armazenamento colunar, pois a redundância de dados textuais impede a compressão eficiente e aumenta o I/O de disco;
  4. Da proposta do DBA visa a transformar o modelo dimensional em um modelo relacional de Terceira Forma Normal (3FN), o que inviabiliza o uso de ferramentas de visualização de dados (como Power BI ou Tableau), visto que essas ferramentas são tecnicamente incompatíveis com tabelas normalizadas;
  5. Ea tabela fato, tanto no esquema estrela quanto no floco de neve, deve ser normalizada para evitar a duplicação de métricas; a diferença reside apenas no fato de que o esquema floco de neve utiliza chaves naturais (CPF, CNPJ) nas junções, enquanto o esquema estrela exige o uso de chaves substitutas (Surrogate Keys).
Revelar gabarito e comentário

GabaritoA — a proposta do DBA configura um esquema floco de neve (Snowflake Schema); embora economize espaço em disco e facilite a manutenção da integridade referencial, essa abordagem prejudica o desempenho das consultas de Business Intelligence (BI) ao exigir múltiplas junções (joins) para recuperar a descrição completa dos atributos hierárquicos;

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: Snowflake vs Star Schema

Gabarito: letra A. A proposta do DBA de normalizar a hierarquia de produtos (Departamento → Divisão → Categoria → Subcategoria → Produto) caracteriza o esquema floco de neve (snowflake). Embora essa abordagem reduza a redundância e o espaço de armazenamento, ela introduz múltiplas junções entre as tabelas de dimensão, prejudicando o desempenho de consultas OLAP, conforme a metodologia de Ralph Kimball.

A questão testa o conhecimento dos dois principais esquemas de modelagem dimensional: Star Schema (esquema estrela) e Snowflake Schema (floco de neve). No primeiro, as dimensões são desnormalizadas em uma única tabela; no segundo, são normalizadas em subdimensões hierárquicas.

Alternativa A — ✅ Correta ⟵ GABARITO

A descrição corresponde exatamente ao snowflake: dimensão normalizada com tabelas separadas para cada nível da hierarquia. Isso economiza espaço (evita repetição do nome do departamento em milhões de linhas) e facilita a manutenção, mas exige múltiplos joins (produto → subcategoria → categoria → divisão → departamento), o que degrada a performance em consultas analíticas que exigem navegação por todos os níveis.

Alternativa B — ❌ Incorreta

A proposta não é um esquema estrela, mas sim floco de neve. No esquema estrela, a dimensão produto conteria todos os atributos (Departamento, Divisão, Categoria, Subcategoria) em uma única tabela, sem normalização. Além disso, a normalização não acelera índices bitmap; pelo contrário, os joins adicionais podem prejudicar.

Alternativa C — ❌ Incorreta

Afirma que o esquema estrela deve ser evitado em data warehouses colunares. Na prática, bancos colunares (como Amazon Redshift, Google BigQuery) se beneficiam da compressão de dados repetitivos, tornando o esquema estrela ainda eficiente. A redundância não impede a compressão, e o I/O pode ser menor que no snowflake devido ao menor número de joins. Portanto, a afirmação é falsa.

Alternativa D — ❌ Incorreta

A proposta não transforma o modelo em um modelo relacional 3NF; permanece um modelo dimensional normalizado (snowflake). Ferramentas de BI (Power BI, Tableau) são perfeitamente compatíveis com esquemas snowflake, suportando múltiplas tabelas e relacionamentos. A incompatibilidade alegada não existe.

Alternativa E — ❌ Incorreta

A tabela fato não é normalizada entre os dois esquemas; ela permanece igual. A diferença está na dimensão, não na fato. Além disso, ambos os esquemas geralmente usam chaves substitutas (surrogate keys) para garantir integridade e performance; chaves naturais não são exclusivas do snowflake. A afirmação sobre chaves é equivocada.

Gabarito: letra A.

Link permanente: /questoes/fg133949