Banco de Dados · FGV · 2026 | Questão sqc-fg133975

Banco de DadosDW - Data Warehouse

Código: fg133975
Banca: FGV
Órgão: TJ-RJ
Ano: 2026
Nível: Superior

Cargo: Analista Judiciário - Tecnologia da Informação - Cientista 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:

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;
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;
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;
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;
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 normaliza a hierarquia de produtos em múltiplas tabelas – Departamento → Divisão → Categoria → Subcategoria → Produto – configurando um esquema floco de neve (Snowflake Schema). Embora economize espaço em disco e facilite a integridade referencial, essa abordagem exige múltiplas junções (joins) para recuperar descrições completas, prejudicando o desempenho de consultas OLAP. A metodologia Kimball recomenda o esquema estrela (desnormalizado) para otimizar a performance em Business Intelligence.

A banca testa a diferença entre esquema estrela e floco de neve, um dos conceitos centrais da modelagem dimensional.

NÃO CAIA NESSA!

A banca troca os conceitos de esquema estrela e floco de neve. Muitos candidatos confundem a normalização das dimensões com o esquema estrela, mas a normalização (múltiplas tabelas) é justamente o floco de neve. O estrela é desnormalizado, com uma única tabela por dimensão. Fique atento: a proposta do DBA é claramente normalizar → snowflake.

Alternativa A — ✅ Correta ⟵ GABARITO

Afirma corretamente que a proposta configura um esquema floco de neve, com vantagens de economia de espaço e integridade, mas com desvantagem de múltiplos joins que prejudicam a performance de consultas analíticas. É exatamente o trade-off descrito na literatura de Kimball.

Alternativa B — ❌ Incorreta

Erra ao chamar a proposta de esquema estrela. A normalização das dimensões caracteriza o floco de neve, não o estrela. Além disso, índices bitmap são mais eficientes em esquemas estrela (menos joins), não em floco de neve.

Alternativa C — ❌ Incorreta

Afirma que a desnormalização (estrela) deve ser evitada em DWs colunares. Na verdade, bancos colunares comprimem muito bem dados repetitivos (como nomes de departamentos), tornando a redundância aceitável e até benéfica para performance de leitura. A desnormalização é prática comum e recomendada.

Alternativa D — ❌ Incorreta

Diz que a proposta transforma o modelo em 3FN e inviabiliza ferramentas de BI. Na verdade, o floco de neve ainda é um modelo dimensional (não relacional puro 3NF), e ferramentas como Power BI e Tableau suportam tabelas normalizadas – embora o estrela seja preferido. Não há incompatibilidade técnica.

Alternativa E — ❌ Incorreta

A tabela fato já é naturalmente normalizada (chaves estrangeiras para dimensões). A diferença entre estrela e floco de neve não está no uso de chaves naturais vs. substitutas; ambos geralmente usam surrogate keys. A diferença é a normalização das dimensões.

Resumo comparativo:

Característica	Esquema Estrela	Esquema Floco de Neve
Dimensões	Desnormalizadas (1 tabela)	Normalizadas (várias tabelas)
Espaço em disco	Maior (redundância)	Menor (sem redundância)
Performance de consulta	Melhor (menos joins)	Pior (mais joins)
Manutenção	Mais complexa (redundância)	Mais simples (integridade)
Recomendação Kimball	Preferido para BI	Evitado em geral

Gabarito: letra A

Link permanente: /questoes/fg133975