Questão de Banco de Dados — Modelagem de dados — CESPE / CEBRASPE 2025
Banco de Dados›Modelagem de dados
Código
ce195202
Banca
CESPE / CEBRASPE
Órgão
BANRISUL
Ano
2025
Nível
Superior
Cargo
Técnico em Tecnologia da Informação II - Desenvolvimento de Software
Um administrador de banco de dados pretende melhorar o desempenho de relatórios executivos que são lidos com muita frequência e executam joins complexos. Para tanto, ele considera desnormalizar algumas tabelas.Nessa situação hipotética,
Adevem ser usadas, no processo de geração dos relatórios, somente tabelas que sejam temporárias e não persistentes.
Bdevem ser mantidas somente visões materializadas com dados agregados, eliminando-se as tabelas originais.
Ca melhor solução é manter as tabelas normalizadas e fazer que os relatórios executem os joins complexos, embora com resultado mais lento.
Dalguns dados devem ser duplicados em tabelas de relatório, embora o procedimento crie certo nível de redundância controlada.
Edevem ser criados novos índices para todas as tabelas que sejam usadas nos relatórios.
Revelar gabarito e comentário▾
GabaritoD — alguns dados devem ser duplicados em tabelas de relatório, embora o procedimento crie certo nível de redundância controlada.
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”.
Desnormalização para desempenho em consultas
Gabarito: letra D. A desnormalização consiste em introduzir redundância controlada em tabelas (duplicar dados) para evitar joins complexos em consultas frequentes, melhorando a velocidade de leitura — exatamente a estratégia indicada para relatórios executivos muito lidos com joins complexos.
A banca cobra o trade-off entre normalização (que reduz redundância) e desempenho de consultas. Em cenários com alta frequência de leitura e joins pesados, a desnormalização é uma técnica válida, desde que gerenciada com controle (redundância controlada).
Critério
Desnormalização (Alternativa D)
Visões Materializadas (Alternativa B)
Índices (Alternativa E)
Tabelas Temporárias (Alternativa A)
Objetivo principal
Reduzir joins complexos duplicando dados
Pré-calcular e armazenar resultados de consultas
Acelerar busca em colunas específicas
Armazenar dados voláteis para processamento temporário
Impacto na redundância
Cria redundância controlada
Não duplica dados das tabelas base (apenas agrega)
Não cria redundância
Não cria redundância
Persistência dos dados
Dados persistentes em tabelas de relatório
Dados persistentes (atualizáveis)
Estrutura persistente (índices)
Dados voláteis (descartados ao final da sessão)
Adequação para relatórios frequentes
Alta: elimina joins em cada execução
Alta: consulta pré-agregada
Média: acelera joins, mas não os elimina
Baixa: dados não persistem entre execuções
Flexibilidade para consultas detalhadas
Mantida (tabelas originais preservadas)
Perdida (tabelas originais eliminadas)
Mantida
Mantida (tabelas originais preservadas)
Complexidade de manutenção
Média (sincronização de dados duplicados)
Alta (atualização da visão materializada)
Baixa (criação de índices)
Baixa (criação automática)
Alternativa A — ❌ Incorreta
Afirma que "devem ser usadas somente tabelas temporárias e não persistentes". Tabelas temporárias são voláteis e não resolvem o problema estrutural; além disso, relatórios executivos geralmente precisam de dados persistentes e atualizados. A desnormalização é aplicada em tabelas permanentes.
Alternativa B — ❌ Incorreta
Propõe manter "somente visões materializadas com dados agregados, eliminando-se as tabelas originais". Visões materializadas podem acelerar consultas, mas eliminar as tabelas originais é inviável: perde-se a flexibilidade de consultas detalhadas e a capacidade de atualização incremental dos dados. A desnormalização sugerida na alternativa D é mais moderada e prática.
Alternativa C — ❌ Incorreta
Diz que "a melhor solução é manter as tabelas normalizadas e fazer que os relatórios executem os joins complexos, embora com resultado mais lento". Ignora o problema de desempenho, que é o cerne da questão. O administrador busca melhorar o desempenho, portanto aceitar lentidão não é solução.
Alternativa D — ✅ Correta ⟵ GABARITO
Afirma que "alguns dados devem ser duplicados em tabelas de relatório, embora o procedimento crie certo nível de redundância controlada". Isso é exatamente a desnormalização: replicar dados em tabelas auxiliares (ou colunas extras) para evitar joins, aceitando redundância em troca de ganho de desempenho em leitura. É uma prática comum em data warehouses e relatórios.
Alternativa E — ❌ Incorreta
Sugere "criar novos índices para todas as tabelas que sejam usadas nos relatórios". Índices aceleram consultas, mas não eliminam a necessidade de joins complexos; além disso, criar índices em todas as tabelas pode piorar a performance de escritas e consumir espaço excessivo. A desnormalização ataca a causa (joins) de forma mais direta.
PEGA ESSA DICA!
A banca testa o conceito de desnormalização como estratégia de otimização de consultas. Lembre-se: normalização reduz redundância e é boa para integridade; desnormalização aumenta redundância controlada para ganhar velocidade em leituras — é uma escolha deliberada de projeto.