Questão de Banco de Dados — Visão (View) — FGV 2024

Otimização de consultas em bancos de dados em memória

Gabarito: letra C. A otimização mais eficaz para a consulta que busca os 10 melhores atletas de 2023 é materializar uma view pré-agregada com as pontuações totais dos atletas por ano, pois elimina a necessidade de recalcular as agregações (SUM, GROUP BY) a cada execução, armazenando fisicamente o resultado pré-computado. Essa é a essência das views materializadas, que trocam frescor dos dados por velocidade de leitura — exatamente o que uma consulta analítica de ranking exige.

A consulta em questão envolve, tipicamente, um JOIN entre tabelas de atletas e competições, um filtro por ano (WHERE data_competicao BETWEEN '2023-01-01' AND '2023-12-31'), uma agregação (SUM(pontuacao)) e uma ordenação com LIMIT 10. Em um banco em memória, o custo principal não é o acesso a disco, mas o processamento da agregação e da ordenação sobre um grande volume de linhas. Vamos entender por que cada alternativa se comporta de um jeito.

O que é uma view materializada? Uma view comum (não materializada) é apenas uma consulta armazenada: cada vez que é referenciada, o SGBD executa a consulta subjacente sobre os dados atuais. Já a view materializada armazena fisicamente o resultado da consulta em uma tabela auxiliar, como se fosse uma tabela real. Isso significa que, ao consultá-la, o SGBD lê os dados já agregados, sem refazer o JOIN, o GROUP BY e o SUM a cada chamada. O ganho é enorme quando a consulta é executada repetidamente e os dados subjacentes não mudam com frequência — exatamente o cenário de um ranking anual de atletas.

Por que a view materializada é a melhor opção aqui? A consulta pede o ranking dos 10 melhores atletas de 2023. Se os dados de competições forem volumosos (milhares de registros por ano), calcular a soma das pontuações por atleta a cada execução é caro. Com a view materializada, esse cálculo é feito uma única vez (ou quando a view é atualizada), e a consulta final se torna um simples SELECT ... ORDER BY ... LIMIT 10 sobre dados já prontos. É a diferença entre processar milhões de linhas a cada consulta e ler apenas 10 linhas de um resultado pré-computado.

A pegadinha da banca: a alternativa A (índice na coluna data_competicao) parece razoável, mas um índice ajuda a filtrar linhas por data, não a agregar e ordenar. O filtro por ano reduz o conjunto de linhas, mas a agregação (SUM + GROUP BY) e a ordenação ainda precisam ser feitas sobre todas as linhas do ano. O índice não elimina esse custo. Já a view materializada elimina o custo da agregação por completo, pois o resultado já está calculado.

Distinção importante: view comum × view materializada. A view comum é uma consulta armazenada, executada a cada referência — não ocupa espaço físico e sempre reflete os dados atuais. A view materializada ocupa espaço físico, armazena o resultado e pode ficar desatualizada até ser atualizada (REFRESH). Para consultas analíticas repetitivas, a materializada é superior em desempenho; para dados que mudam constantemente e exigem frescor, a comum é mais adequada.

Guarde essa fronteira: índice acelera filtro; view materializada acelera agregação. É exatamente nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Criar um índice na coluna data_competicao acelera o filtro por ano (WHERE data_competicao BETWEEN ...), reduzindo o número de linhas lidas. Porém, a consulta ainda precisa agregar (SUM + GROUP BY) e ordenar os resultados. O índice não elimina o custo da agregação, que é o gargalo principal em uma consulta de ranking sobre um volume grande de dados. Em um banco em memória, onde o acesso a disco não é o problema, o ganho do índice é marginal comparado ao da view materializada.

Alternativa B — ❌ Incorreta

Particionar a tabela competicoes por ano também ajuda a reduzir o escopo da leitura (o SGBD pode acessar apenas a partição de 2023), mas, assim como o índice, não elimina o custo da agregação e da ordenação. O particionamento é uma técnica de organização física que melhora a varredura, mas não pré-computa resultados. A view materializada vai além: ela já entrega o resultado agregado pronto.

Alternativa C — ✅ Correta ⟵ GABARITO

Materializar uma view pré-agregada com as pontuações totais dos atletas por ano é a otimização mais eficaz. A view materializada armazena fisicamente o resultado da agregação (SUM(pontuacao) GROUP BY atleta, ano), de modo que a consulta final lê apenas os dados já somados e ordena 10 linhas. Isso elimina o custo de processamento da agregação a cada execução, que é o principal gargalo. É a técnica clássica para consultas analíticas repetitivas sobre dados históricos.

Alternativa D — ❌ Incorreta

Utilizar um banco de dados NoSQL orientado a documentos não é uma otimização direta da consulta. Trocar o SGBD é uma decisão arquitetural de grande impacto, que envolve migração de dados, reescrita de consultas e possíveis perdas de funcionalidades relacionais (JOINs, agregações SQL). Além disso, um banco orientado a documentos não elimina a necessidade de agregar e ordenar os dados — apenas muda a forma de armazenamento. Não é uma otimização pontual e eficaz para a consulta em questão.

Alternativa E — ❌ Incorreta

Aplicar algoritmos de aprendizado de máquina para prever os atletas com as melhores pontuações é completamente inadequado. A consulta pede um ranking real baseado em pontuações efetivamente registradas em competições oficiais de 2023. Previsão por ML introduz incerteza e não reflete os dados reais — o resultado seria uma estimativa, não o ranking verdadeiro. Além disso, ML não é uma técnica de otimização de consulta; é uma ferramenta de análise preditiva, fora do escopo do problema.

Gabarito: letra C