Banco de Dados · FGV · 2024 | Questão sqc-fg165208

GabaritoE — armazenar previamente os resultados de consultas frequentes utilizando visões materializadas.

Otimização de Consultas SQL: Visões Materializadas

Gabarito: letra E. A estratégia de armazenar previamente os resultados de consultas frequentes e complexas é exatamente o papel das visões materializadas (materialized views), que persistem o resultado da consulta em disco e o atualizam periodicamente, evitando recálculo a cada execução. As demais alternativas tratam de outras técnicas (transações, índices, normalização, particionamento) que não atendem diretamente ao objetivo de otimizar consultas com agregações e cálculos complexos.

O problema apresentado é clássico em bancos de dados: uma tabela com milhares de registros e consultas que envolvem agregações (SUM, COUNT, AVG) e cálculos complexos (joins, subconsultas, funções) tendem a ser lentas porque o SGBD precisa processar todos os dados a cada execução. A otimização de consultas busca reduzir o custo de execução, seja reescrevendo a consulta, criando estruturas auxiliares (índices) ou armazenando resultados pré-computados.

Uma visão materializada é um objeto do banco que armazena fisicamente o resultado de uma consulta. Diferente de uma visão comum (que é apenas uma definição lógica, executada a cada acesso), a visão materializada guarda os dados em uma tabela física, podendo ser indexada e consultada diretamente. O SGBD pode atualizá-la automaticamente (por triggers ou refresh programado) ou manualmente. Isso é especialmente útil para consultas analíticas e de agregação, onde o custo de recálculo é alto e os dados não mudam com frequência.

Na prática, imagine um relatório mensal de vendas por região: a consulta faz JOIN entre várias tabelas e agrega milhares de registros. Com uma visão materializada, o resultado é calculado uma vez e armazenado; o relatório passa a ler apenas a visão, reduzindo drasticamente o tempo de resposta. O trade-off é a necessidade de atualização (refresh) e o espaço em disco, mas para consultas frequentes o ganho de performance compensa.

A banca explora a confusão entre visões materializadas e outras técnicas de otimização. O candidato pode pensar em índices ou particionamento, mas o enunciado fala em "armazenar previamente os resultados" — isso é a definição literal de visão materializada. As outras alternativas são técnicas válidas, mas não correspondem ao que foi descrito.

NÃO CAIA NESSA!

A banca troca a técnica de otimização pelo seu efeito. O particionamento (D) também melhora a performance, mas não armazena resultados prévios — apenas divide a tabela. A pegadinha está em associar "otimização" a qualquer técnica, quando o enunciado especifica "armazenar previamente os resultados", que é exclusivo das visões materializadas.

Critério	Visões Materializadas (E)	Particionamento Horizontal (D)	Índices Bitmap (B)
Objetivo principal	Armazenar previamente resultados de consultas complexas	Dividir fisicamente a tabela em segmentos menores	Acelerar buscas em colunas de baixa cardinalidade
Mecanismo de otimização	Pré-computação e persistência do resultado	Redução do escopo de leitura (partition pruning)	Acesso direto via bitmap de valores
Adequação a agregações/cálculos	Alta — elimina recálculo a cada execução	Média — melhora performance, mas não evita recálculo	Baixa — não otimiza agregações nem dados calculados
Atualização dos dados	Requer refresh (manual ou automático)	Automática, pois os dados continuam na tabela original	Automática, via manutenção do índice
Custo de armazenamento	Alto (duplicação física do resultado)	Baixo (mesma tabela, apenas dividida)	Médio (estrutura de índice adicional)

Alternativa A — ❌ Incorreta

Aplicar "commits" aninhados não é uma técnica de otimização de consultas. Commits aninhados (ou savepoints) são mecanismos de controle de transações, usados para gerenciar pontos de rollback dentro de uma transação. Eles não aceleram consultas nem armazenam resultados; apenas controlam a atomicidade e a consistência das operações de escrita.

Alternativa B — ❌ Incorreta

Índices bitmap são eficientes para colunas com baixa cardinalidade (poucos valores distintos), como sexo ou status. No entanto, o enunciado fala em "colunas que envolvam dados calculados" — índices bitmap não são adequados para colunas calculadas, pois o índice é criado sobre valores armazenados, não sobre expressões. Para dados calculados, o correto seria um índice baseado em função (function-based index), não bitmap. Além disso, índices bitmap são mais comuns em ambientes de data warehouse, mas não armazenam resultados de consultas.

Alternativa C — ❌ Incorreta

Reduzir a redundância dos dados aplicando técnicas de normalização é uma prática de modelagem de dados, não de otimização de consultas. A normalização visa eliminar anomalias de atualização e redundância, mas pode até piorar a performance de consultas (por exigir mais joins). Para otimizar consultas, muitas vezes se faz o oposto: desnormalizar (denormalização) para reduzir joins. Portanto, não atende ao objetivo de armazenar resultados prévios.

Alternativa D — ❌ Incorreta

O particionamento horizontal divide a tabela em segmentos menores (partições) com base em um critério, como faixa de valores. Isso pode melhorar a performance de consultas que acessam apenas uma partição (partition pruning), mas não armazena resultados de consultas. O particionamento é uma técnica de organização física dos dados, não de pré-computação de resultados.

Alternativa E — ✅ Correta ⟵ GABARITO

Visões materializadas armazenam fisicamente o resultado de uma consulta, permitindo que consultas frequentes e complexas sejam respondidas rapidamente, sem recálculo. O SGBD mantém os dados pré-computados e os atualiza conforme necessário. É exatamente a estratégia descrita no enunciado: "armazenar previamente os resultados de consultas frequentes".

Gabarito: letra E