Resumo TI Banco de Dados: Otimização Algébrica de Consultas

SQL é uma linguagem declarativa: o usuário diz o que quer obter, não como obter. Antes de executar, o SGBD converte a consulta numa expressão inicial de álgebra relacional — uma árvore de consulta, com as relações base nas folhas e os operadores (seleção, projeção, junção) nos nós internos. Essa árvore inicial costuma ser ingênua, cheia de produtos cartesianos e seleções aplicadas tarde demais. É aí que entra a otimização algébrica.

Neste resumo, você vai ver como o otimizador usa as regras de equivalência do resumo anterior para transformar essa árvore inicial numa árvore mais barata, entender a diferença entre otimização heurística e otimização baseada em custo, e acompanhar um exemplo completo de transformação passo a passo.

🌳 Da consulta declarativa à árvore de operadores

Ao receber uma consulta SQL, o SGBD a converte numa árvore de consulta (query tree): as relações base ficam nas folhas, e cada operador da álgebra relacional (seleção, projeção, junção, produto cartesiano) vira um nó interno. Na tradução mais direta, um JOIN implícito de SQL costuma virar um produto cartesiano seguido de uma seleção com a condição de junção, e a projeção final costuma aparecer no topo da árvore, sobre todo o resultado — uma forma correta, mas ineficiente, de representar a consulta.

🔧 Otimização heurística (baseada em regras)

A otimização heurística aplica, em sequência, as regras de equivalência vistas no resumo anterior para reescrever essa árvore inicial numa árvore equivalente e mais barata — sem nunca mudar o resultado lógico da consulta. As transformações mais usadas, nesta ordem típica, são:

• Decompor seleções compostas em seleções em cascata, separando cada condição unida por E lógico, para que cada uma possa ser movida de forma independente;
• Empurrar cada seleção para o mais perto possível das folhas, reduzindo o tamanho das relações antes das operações mais custosas, como junção e produto cartesiano;
• Combinar produto cartesiano seguido de seleção com condição de junção numa única operação de junção (⋈), evitando materializar o produto cartesiano completo;
• Reordenar as junções para que as relações resultantes de filtros mais restritivos sejam combinadas primeiro, mantendo as relações intermediárias as menores possíveis;
• Empurrar as projeções para baixo, em cascata, descartando cedo qualquer atributo que não seja necessário nem para o resultado final, nem para nenhuma operação posterior.

📊 Otimização baseada em custo

A otimização heurística só aplica regras — não olha o tamanho real das relações. Já a otimização baseada em custo usa estatísticas do catálogo do sistema (cardinalidade das tabelas, seletividade dos predicados, existência de índices) para estimar o custo de diferentes planos de execução equivalentes, e escolhe o de menor custo estimado. É esse processo que produz o plano de execução efetivamente executado pelo SGBD — tema aprofundado mais adiante na trilha, junto com índices. Aqui, o ponto central é que uma etapa não substitui a outra: a heurística prepara uma árvore já mais enxuta, que alimenta a decisão baseada em custo.

🧩 Exemplo de transformação heurística

Considere a consulta: selecione o nome dos clientes de São Paulo com pedidos acima de R$ 1.000, sobre as relações Cliente e Pedido (unidas por Cliente.id = Pedido.cliente_id). A árvore inicial, ingênua, equivale a:

• π_nome(σ_{cidade=’SP’ ∧ valor>1000 ∧ Cliente.id=Pedido.cliente_id}(Cliente × Pedido))

Aplicando as heurísticas, a seleção composta é decomposta em três condições independentes. As duas que usam atributos de um único lado (cidade='SP', só de Cliente; valor>1000, só de Pedido) são empurradas para perto de cada folha. A condição restante (Cliente.id=Pedido.cliente_id) some como seleção separada e vira a própria condição da junção, expressa como subscrito de ⋈ — o resultado é uma equijunção, caso particular de junção-theta, substituindo o produto cartesiano. O resultado é uma árvore equivalente, porém mais barata:

• π_nome(σ_{cidade=’SP’}(Cliente) ⋈_{Cliente.id=Pedido.cliente_id} σ_valor>1000(Pedido))

As duas expressões produzem exatamente o mesmo resultado, mas a segunda junta relações já filtradas e menores, em vez de calcular primeiro o produto cartesiano completo de Cliente e Pedido para só depois filtrar e descartar a maior parte das linhas.

⚠️ Pegadinhas comuns

• Heurística não garante o plano ótimo, só um plano tipicamente melhor que a árvore ingênua — “melhor” não é sinônimo de “ótimo global”;
• Otimização baseada em regras (heurística) não é o mesmo que otimização baseada em custo: a primeira só aplica equivalências algébricas; a segunda usa estatísticas reais do catálogo para estimar custo — é a troca mais cobrada em prova sobre este tema;
• Empurrar seleção continua exigindo a ressalva de atributos vista no resumo anterior: só pode ser antecipada se a condição usar exclusivamente atributos do lado para o qual está sendo movida;
• Produto cartesiano isolado não vira junção automaticamente: a fusão em ⋈ só é válida quando existe, de fato, uma condição de comparação (igualdade ou não) equivalente à condição de junção — vale tanto para equijunção quanto para junção-theta em geral;
• A ordem escrita no SQL não é a ordem realmente executada: o otimizador pode reorganizar internamente a sequência de junções e filtros, mesmo que o texto da consulta liste os JOINs em outra ordem.

🎯 Dica Final para a Prova

Quando a questão pedir para justificar uma transformação entre duas árvores de consulta, identifique primeiro qual regra de equivalência está em jogo (comutatividade, associatividade, distribuição de seleção/projeção) — a resposta quase sempre está numa dessas regras. E, sempre que a questão comparar abordagens de otimização, separe com clareza: heurística usa regras algébricas; baseada em custo usa estatísticas e estimativas.

✓ Agora que você viu como o otimizador reorganiza uma consulta usando as regras de equivalência, vale voltar um passo atrás na cadeia de decisões: nem toda consulta lenta é culpa do otimizador — muitas vezes o problema está na própria estrutura das tabelas. É isso que a próxima seção da trilha investiga, começando pelas anomalias de inserção, atualização e exclusão que aparecem quando um esquema não está bem projetado.

📍Gostou do conteúdo? Deixe um comentário, compartilhe e continue acompanhando o Dicionário do Concurseiro para mais Resumos de TI – Banco de Dados. Aqui você encontra explicações claras, atualizadas e com foco total no que cai em prova!

👉 Leia também no Dicionário do Concurseiro: Resumo TI Banco de Dados: Anomalias de Inserção, Atualização e Exclusão

📘 A otimização algébrica reescreve a consulta usando regras de equivalência, sem mudar o resultado — só o caminho até ele. Continue estudando!