Questão de Banco de Dados — Banco de Dados Relacionais — FGV 2025
Banco de Dados›Banco de Dados Relacionais
Código
fg107153
Banca
FGV
Órgão
CPRM
Ano
2025
Nível
Superior
Cargo
Analista em Geociências - Análise e Desenvolvimento de Sistemas
No contexto de tuning de consultas em bancos de dados relacionais, certas práticas podem introduzir sobrecarga desnecessária ou impedir o uso eficiente de índices.Assinale a opção que corresponde a uma prática que deve ser evitada por resultar, em geral, em pior desempenho.
ACriar uma visão (VIEW) e consultá-la em substituição às tabelas base, com o objetivo de otimizar automaticamente o desempenho.
BEliminar o uso do qualificador DISTINCT quando uma superchave mínima é listada na cláusula SELECT de uma consulta realizada sobre uma única relação.
CReescrever subconsultas correlacionadas utilizando relações temporárias obtidas por GROUP BY, de modo a reduzir varreduras redundantes.
DSubstituir uma consulta com operador OR por duas consultas unidas por UNION, quando o plano de execução da consulta original não utilizar índices.
EUtilizar índices de agrupamento (clustering indexes) em atributos envolvidos em junções para favorecer a eficiência do plano de execução.
Revelar gabarito e comentário▾
GabaritoA — Criar uma visão (VIEW) e consultá-la em substituição às tabelas base, com o objetivo de otimizar automaticamente o desempenho.
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”.
Tuning de Consultas em Bancos de Dados Relacionais
Gabarito: letra A. A criação de visões (views) comuns não acelera consultas automaticamente; pelo contrário, pode introduzir sobrecarga, pois a view é uma tabela virtual que, ao ser consultada, executa a consulta subjacente. As demais alternativas descrevem práticas de otimização válidas que geralmente melhoram o desempenho.
A banca explora o equívoco comum de que views são uma panaceia para performance. Na verdade, salvo visões materializadas, elas apenas encapsulam a lógica da consulta, sem acelerar o acesso.
Prática
Descrição
Efeito no Desempenho
Deve ser Evitada?
Criar uma VIEW comum e consultá-la em vez das tabelas base
A view é uma tabela virtual que executa a consulta subjacente a cada acesso
Piora o desempenho, pois não acelera automaticamente e pode introduzir sobrecarga
Sim (GABARITO)
Eliminar DISTINCT quando superchave mínima está no SELECT
A chave já garante unicidade, tornando DISTINCT redundante
Melhora o desempenho ao reduzir processamento desnecessário
Não
Reescrever subconsultas correlacionadas com GROUP BY e relações temporárias
Transforma dependência linha a linha em agregação pré-calculada
Melhora o desempenho ao reduzir varreduras redundantes
Não
Substituir OR por UNION
Permite que cada parte da consulta use índices separadamente
Melhora o desempenho quando o OR impede uso de índices
Não
Usar índices de agrupamento (clustering) em atributos de junção
Organiza fisicamente os dados conforme a chave de junção
Melhora a eficiência do plano de execução em junções
Não
Alternativa A — ✅ Correta ⟵ GABARITO
Criar uma view e consultá-la em vez das tabelas base, esperando otimização automática, é uma prática que deve ser evitada. Views comuns (não materializadas) não armazenam dados fisicamente; cada consulta à view executa a consulta interna, que pode ser complexa e não otimizada pelo SGBD simplesmente por estar encapsulada. Isso tende a piorar o desempenho, não melhorar.
NÃO CAIA NESSA!
Muitos candidatos acreditam que views sempre aceleram consultas, mas isso é um engano. A view é apenas uma "janela" sobre os dados; a otimização depende do plano gerado para a consulta subjacente. Na dúvida, lembre-se: view não é tabela física.
Alternativa B — ❌ Incorreta
Eliminar o DISTINCT quando uma superchave mínima está no SELECT é uma boa prática, pois garante unicidade sem custo extra. Como a chave já torna as linhas únicas, o DISTINCT é redundante e sua remoção reduz processamento. Portanto, não é uma prática a ser evitada.
Alternativa C — ❌ Incorreta
Reescrever subconsultas correlacionadas com relações temporárias obtidas por GROUP BY é uma técnica de otimização reconhecida. Ela reduz varreduras redundantes ao transformar uma subconsulta que depende de cada linha externa em uma agregação pré-calculada, melhorando o desempenho.
Alternativa D — ❌ Incorreta
Substituir consultas com OR por UNION pode permitir que cada parte da consulta utilize índices, já que o OR muitas vezes impede o uso eficiente de índices. Essa reescrita é uma estratégia válida de tuning quando o plano original não usa índices.
Alternativa E — ❌ Incorreta
Índices de agrupamento (clustered indexes) ordenam fisicamente os dados da tabela. Utilizá-los em atributos envolvidos em junções pode acelerar significativamente as operações de junção, pois os dados já estão ordenados e o SGBD pode usar merge join ou reduzir seek. É uma prática recomendada, não a ser evitada.