Questão de Tecnologia da Informação · FGV DATAPREV 2024 (nº 63)

O conceito-chave aqui é a pré-agregação de dados, que significa calcular e armazenar resultados de operações como somas e contagens antes que a consulta seja executada. Isso transforma uma consulta complexa e custosa em uma simples busca em dados já processados, otimizando drasticamente o desempenho.

(A) Incorreta: Um índice na coluna `data_competicao` ajudaria a localizar rapidamente os registros de 2023, especialmente se fosse um índice funcional em `EXTRACT(YEAR FROM data_competicao)`. No entanto, mesmo com o filtro rápido, a consulta ainda precisaria realizar a agregação (`SUM` e `GROUP BY`) e a ordenação (`ORDER BY`) sobre todos os dados de 2023, que são as operações mais custosas. Em um banco de dados em memória, o ganho de um índice para filtragem pode ser menor do que em um banco em disco, e não resolve o problema da agregação.
(B) Incorreta: Particionar a tabela `competicoes` por ano também otimizaria a etapa de filtragem, direcionando a consulta apenas para a partição de 2023. Isso reduziria o volume de dados a serem processados. Contudo, assim como o índice, a partição não elimina a necessidade de realizar as operações de agregação (`SUM` e `GROUP BY`) e ordenação (`ORDER BY`) sobre os dados da partição de 2023, que são os gargalos de desempenho.
(C) Correta: Materializar uma view pré-agregada significa criar uma tabela (ou um objeto de banco de dados similar a uma tabela) que já contém os resultados da agregação desejada. Neste caso, uma view materializada poderia armazenar `(ano, atleta_id, total_pontuacao)`. A consulta original, que envolve `EXTRACT`, `SUM`, `GROUP BY` e `ORDER BY` sobre uma tabela potencialmente grande, seria substituída por uma simples `SELECT` na view materializada, filtrando pelo `ano = 2023` e aplicando `ORDER BY` e `LIMIT`. Isso elimina completamente o trabalho computacional de agregação e filtragem complexa em tempo de execução, sendo a otimização mais eficaz para consultas que envolvem agregações repetitivas.
(D) Incorreta: Utilizar um banco de dados NoSQL orientado a documentos seria uma mudança completa da arquitetura do banco de dados, não uma otimização da consulta SQL existente. Embora bancos NoSQL possam oferecer alta performance para certos cenários, a questão pede uma otimização para a consulta SQL fornecida no banco de dados em memória existente. Mudar o tipo de banco de dados é uma solução para um problema diferente. Armadilha da banca: Bancos NoSQL são frequentemente associados a alta performance, mas não são uma otimização para uma consulta SQL específica em um ambiente relacional existente.
(E) Incorreta: Aplicar algoritmos de aprendizado de máquina serve para prever resultados futuros ou identificar padrões, não para otimizar a recuperação de dados históricos exatos conforme solicitado pela consulta. A consulta busca os 10 melhores atletas com base em suas pontuações reais e registradas, não em previsões.