A teoria de bancos de dados de Jeffrey Ullman por trás de consultas rápidas e escaláveis

Por que Ullman importa para o trabalho moderno com dados

A maioria das pessoas que escreve SQL, monta dashboards ou afina uma consulta lenta já se beneficiou do trabalho de Jeffrey Ullman — mesmo que nunca tenha ouvido seu nome. Ullman é um cientista da computação e educador cuja pesquisa e livros ajudaram a definir como bancos de dados descrevem dados, raciocinam sobre consultas e as executam eficientemente.

A influência discreta por trás de ferramentas do dia a dia

Quando um motor de banco de dados transforma seu SQL em algo que ele pode executar rápido, está confiando em ideias que precisam ser ao mesmo tempo precisas e adaptáveis. Ullman ajudou a formalizar o significado das consultas (para que o sistema possa reescrevê-las com segurança) e a conectar o pensamento sobre bancos de dados com o pensamento de compiladores (para que uma consulta seja analisada, otimizada e traduzida em passos executáveis).

Essa influência é discreta porque não aparece como um botão na sua ferramenta de BI ou como uma opção visível no console da nuvem. Ela aparece como:

• Consultas que rodam rápido depois que você adiciona um índice ou reescreve um JOIN
• Otimizadores que escolhem planos diferentes conforme os dados crescem
• Sistemas que conseguem escalar sem alterar o resultado retornado pela sua consulta

O que você vai aprender neste artigo (sem sobrecarga matemática)

Este post usa as ideias centrais de Ullman como um guia pelos internos de bancos de dados que mais importam na prática: como a álgebra relacional fica por baixo do SQL, como reescritas de consulta preservam significado, por que otimizadores baseados em custo tomam certas escolhas e como algoritmos de join frequentemente decidem se um trabalho termina em segundos ou horas.

Também vamos aproveitar alguns conceitos parecidos com compiladores — parsing, reescrita e planejamento — porque engines de banco de dados se comportam mais como compiladores sofisticados do que muita gente imagina.

Uma promessa rápida: manteremos a discussão precisa, mas evitaremos provas pesadas. O objetivo é dar modelos mentais que você possa aplicar no trabalho na próxima vez que desempenho, escalabilidade ou comportamento confuso de uma consulta aparecer.

Fundamentos de banco de dados que Ullman ajudou a consolidar

Se você já escreveu uma consulta SQL e esperou que ela “signifique apenas uma coisa”, está confiando em ideias que Jeffrey Ullman ajudou a popularizar e formalizar: um modelo limpo para dados, mais formas precisas de descrever o que uma consulta pede.

O modelo relacional em termos simples

No essencial, o modelo relacional trata dados como tabelas (relações). Cada tabela tem linhas (tuplas) e colunas (atributos). Isso soa óbvio hoje, mas a parte importante é a disciplina que isso cria:

• Chaves identificam linhas. Uma primary key é a “etiqueta de nome” de cada registro.
• Relacionamentos conectam tabelas via foreign keys, para que você possa manter fatos em um lugar e referenciá-los em outro.

Esse enquadramento torna possível raciocinar sobre correção e desempenho sem superficialidade. Quando você sabe o que uma tabela representa e como linhas são identificadas, consegue prever o que joins devem fazer, o que duplicatas significam e por que certos filtros mudam resultados.

Álgebra relacional: uma calculadora para consultas

O ensino de Ullman frequentemente usa a álgebra relacional como uma espécie de calculadora de consultas: um pequeno conjunto de operações (select, project, join, union, difference) que você pode combinar para expressar o que deseja.

Por que isso importa para quem trabalha com SQL: os bancos de dados traduzem SQL para uma forma algébrica e então reescrevem essa forma em outra equivalente. Duas consultas que parecem diferentes podem ser algebraicamente iguais — é assim que otimizadores podem reordenar joins, empurrar filtros para baixo ou remover trabalho redundante mantendo o significado intacto.

Álgebra vs. cálculo (visão geral)

• Álgebra relacional é mais “como”: uma sequência de operações para calcular o resultado.
• Cálculo relacional é mais “o quê”: uma descrição do resultado que você quer.

SQL é em grande parte “o quê”, mas engines frequentemente otimizam usando álgebra “como”.

Fundamento vence decorar um dialeto

Dialetos SQL variam (Postgres vs. Snowflake vs. MySQL), mas os fundamentos não. Entender chaves, relacionamentos e equivalência algébrica ajuda você a perceber quando uma consulta está logicamente errada, quando está apenas lenta e quais mudanças preservam significado entre plataformas.

Álgebra relacional: a linguagem escondida sob o SQL

Álgebra relacional é a “matemática por trás” do SQL: um pequeno conjunto de operadores que descrevem o resultado que você quer. O trabalho de Jeffrey Ullman ajudou a tornar essa visão por operadores nítida e ensinável — e é ainda o modelo mental que a maioria dos otimizadores usa.

Os operadores principais (e o que significam)

Uma consulta de banco de dados pode ser expressa como um pipeline de poucos blocos de construção:

• Select (σ): filtrar linhas (a ideia do WHERE do SQL)
• Project (π): manter colunas específicas (a ideia de SELECT col1, col2)
• Join (⋈): combinar tabelas com base numa condição (JOIN ... ON ...)
• Union (∪): empilhar resultados com o mesmo formato (UNION)
• Difference (−): linhas em A mas não em B (como EXCEPT em vários dialectos)

Por ser um conjunto pequeno, fica mais fácil raciocinar sobre correção: se duas expressões algébricas são equivalentes, elas retornam a mesma tabela para qualquer estado de banco de dados válido.

Como o SQL mapeia para a álgebra (conceitualmente)

Considere uma consulta familiar:

SELECT c.name
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.total > 100;

Conceitualmente, isso é:

1. comece com um join de customers e orders: customers ⋈ orders

2. select apenas orders acima de 100: σ(o.total > 100)(...)

3. project a coluna que você quer: π(c.name)(...)

Isso não é a notação interna exata usada por todo motor, mas é a ideia certa: SQL vira uma árvore de operadores.

Equivalência: a porta para otimização

Muitas árvores diferentes podem significar o mesmo resultado. Por exemplo, filtros podem frequentemente ser empurrados para mais cedo (aplicar σ antes de um grande join), e projeções podem eliminar colunas não usadas mais cedo (aplicar π antecipadamente).

Essas regras de equivalência é que permitem que um banco de dados reescreva sua consulta para um plano mais barato sem mudar o significado. Uma vez que você vê consultas como álgebra, “otimização” deixa de ser mágica e vira um remodelamento guiado por regras seguras.

Do SQL a planos de consulta: reescritas que preservam significado

Quando você escreve SQL, o banco de dados não executa “como está escrito”. Ele traduz sua instrução em um plano de consulta: uma representação estruturada do trabalho a ser feito.

Um bom modelo mental é uma árvore de operadores. Folhas leem tabelas ou índices; nós internos transformam e combinam linhas. Operadores comuns incluem scan, filter (seleção), project (escolha de colunas), join, group/aggregate e sort.

Plano lógico vs. plano físico (o quê vs. como)

Bancos de dados normalmente separam o planejamento em duas camadas:

• Plano lógico: o quê resultado calcular, expresso com operadores abstratos (filter, join, aggregate) e relações entre eles.
• Plano físico: como executar isso no armazenamento e hardware reais (index scan vs. full scan, hash join vs. nested-loop, paralelo vs. single-threaded).

A influência de Ullman aparece na ênfase em transformações que preservam o significado: rearranje o plano lógico de várias maneiras sem mudar a resposta, então escolha uma estratégia física eficiente.

Reescritas baseadas em regras que reduzem trabalho

Antes de escolher a abordagem final de execução, otimizadores aplicam regras algébricas de “limpeza”. Essas reescritas não mudam os resultados; elas reduzem trabalho desnecessário.

Exemplos comuns:

• Selection pushdown: aplicar filtros o mais cedo possível para que menos linhas fluam para passos posteriores.
• Projection pruning: manter apenas as colunas necessárias, reduzindo I/O e memória.
• Join reordering: juntar resultados menores/intermediários primeiro (quando seguro), em vez de seguir a ordem superficial do SQL.

Um exemplo simples de reescrita

Suponha que você queira pedidos de usuários de um país:

SELECT o.order_id, o.total
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE u.country = 'CA';

Uma interpretação ingênua poderia juntar todos os users com todos os orders e só depois filtrar para Canadá. Uma reescrita que preserva o significado empurra o filtro para baixo para que o join toque menos linhas:

• Filtrar usuários para country = 'CA'
• Depois juntar esses usuários aos orders
• Depois projetar apenas order_id e total

Em termos de plano, o otimizador tenta transformar:

Join(Users, Orders) → Filter(country='CA') → Project(order_id,total)

em algo mais próximo de:

Filter(country='CA') on Users → Join(with Orders) → Project(order_id,total)

Mesmo resultado. Menos trabalho.

Essas reescritas são fáceis de ignorar porque você nunca as digita — e ainda assim são uma das grandes razões de o mesmo SQL rodar rápido em um banco e lento em outro.

Otimização baseada em custo sem o jargão

Quando você executa uma consulta SQL, o banco de dados considera múltiplas maneiras válidas de obter a mesma resposta e escolhe a que espera ser mais barata. Esse processo de decisão é chamado otimização baseada em custo — e é um dos pontos mais práticos onde a teoria no estilo de Ullman aparece no desempenho do dia a dia.

O que um “modelo de custo” realmente é

Um modelo de custo é um sistema de pontuação que o otimizador usa para comparar planos alternativos. A maioria dos motores estima custo usando alguns recursos centrais:

• Linhas processadas (o trabalho costuma escalar com quanto dado flui por cada passo)
• I/O (leitura de páginas do disco ou SSD, mais efeitos de cache)
• CPU (filtragem, hashing, ordenação, agregação)
• Memória (se uma operação cabe em RAM ou derrama para disco)

O modelo não precisa ser perfeito; precisa ser direcionalmente correto com frequência suficiente para escolher bons planos.

Estimativa de cardinalidade, em termos simples

Antes de pontuar planos, o otimizador pergunta em cada passo: quantas linhas isso vai produzir? Isso é a estimativa de cardinalidade.

Se você filtra WHERE country = 'CA', o motor estima qual fração da tabela casa. Se você junta customers com orders, estima quantos pares vão bater na chave do join. Esses palpites de contagem de linhas determinam se ele prefere um index scan a uma varredura completa, um hash join a um nested loop ou se uma ordenação será pequena ou enorme.

Por que estatísticas importam (e o que dá errado sem elas)

Os palpites do otimizador são guiados por estatísticas: contagens, distribuições de valores, taxas de nulos e às vezes correlações entre colunas.

Quando estatísticas estão desatualizadas ou ausentes, o motor pode errar a estimativa por ordens de grandeza. Um plano que parecia barato no papel pode ficar caro na prática — sintomas clássicos incluem quedas de desempenho após aumento de dados, mudanças “aleatórias” de plano ou joins que inesperadamente derramam para disco.

O trade-off inevitável: precisão vs. tempo de planejamento

Melhores estimativas frequentemente exigem mais trabalho: estatísticas mais detalhadas, amostragem ou explorar mais planos candidatos. Mas planejar também custa tempo, especialmente para consultas complexas.

Então os otimizadores equilibram dois objetivos:

• Planejar rápido o suficiente para cargas interativas
• Planejar suficientemente bem para evitar escolhas catastróficas

Entender esse trade-off ajuda a interpretar EXPLAIN: o otimizador não tenta ser genial — tenta ser previsivelmente correto com informação limitada.

Algoritmos de join e o coração do desempenho de consultas

O trabalho de Ullman ajudou a popularizar uma ideia simples mas poderosa: SQL não é tanto “executado” quanto traduzido em um plano de execução. Em nenhum lugar isso é mais óbvio do que nos joins. Duas consultas que retornam as mesmas linhas podem ter tempos de execução muito diferentes dependendo de qual algoritmo de join o motor escolhe — e em que ordem ele junta as tabelas.

Nested loop, hash join, merge join — quando cada um faz sentido

Nested loop join é conceitualmente simples: para cada linha à esquerda, encontre linhas que batem à direita. Pode ser rápido quando o lado esquerdo é pequeno e o lado direito tem um índice útil.

Hash join constrói uma tabela hash a partir de uma entrada (frequentemente a menor) e a consulta com a outra. Brilha com entradas grandes e não ordenadas em condições de igualdade (ex.: A.id = B.id), mas precisa de memória; derramar para disco pode eliminar a vantagem.

Merge join percorre dois inputs em ordem ordenada. É ótimo quando ambos os lados já estão ordenados (ou ordenáveis barato), por exemplo quando índices entregam linhas na ordem da chave de join.

Por que a ordem de join pode dominar o desempenho

Com três ou mais tabelas, o número de ordens de join possíveis explode. Juntar duas tabelas grandes primeiro pode criar um resultado intermediário enorme que atrasa tudo. Uma ordem melhor costuma começar pelo filtro mais seletivo (menos linhas) e expandir a partir daí, mantendo intermediários pequenos.

Índices mudam o cardápio de planos viáveis

Índices não apenas aceleram buscas — eles tornam certas estratégias de join viáveis. Um índice na chave de join pode transformar um nested loop caro em um padrão de “seek por linha” rápido. Por outro lado, índices faltantes ou inúteis podem empurrar o motor para hash joins ou grandes ordenações para um merge join.

Checklist prático: sintomas de um plano de join ruim

• O tempo cresce dramaticamente com pouco mais de dados (provavelmente a ordem de join amplificando intermediários).
• O plano mostra grandes diferenças entre “rows estimated vs. rows actual” (palpites de cardinalidade ruins levam a escolhas erradas).
• Você vê grandes ordenações ou derramamentos de hash para disco (pressão de memória ou falta de índices de suporte).
• Uma tabela pequena filtrada é juntada tardiamente em vez de cedo (filtros não aplicados prontamente).
• O predicado de join não é uma igualdade limpa em tipos compatíveis (impede comportamento eficiente de hash/merge).

Ideias de compilador dentro de engines de banco de dados

Bancos de dados não apenas “rodam SQL”. Eles o compilam. A influência de Ullman se estende tanto à teoria de banco de dados quanto ao pensamento de compiladores, e essa conexão explica por que engines de consulta se parecem com toolchains de linguagens: elas traduzem, reescrevem e otimizam antes de fazer qualquer trabalho.

Parsing e árvores sintáticas: como o SQL é lido

Quando você envia uma consulta, o primeiro passo se parece com a front-end de um compilador. O motor tokeniza palavras-chave e identificadores, checa gramática e constrói uma árvore de parse (frequentemente simplificada em uma árvore de sintaxe abstrata). É aqui que erros básicos são capturados: vírgulas faltando, nomes de coluna ambíguos, regras de agrupamento inválidas.

Um modelo mental útil: SQL é uma linguagem de programação cujo “programa” descreve relacionamentos de dados em vez de loops.

Da árvore de parse para operadores lógicos

Compiladores convertem sintaxe em uma representação intermediária (IR). Bancos fazem algo similar: traduzem a sintaxe SQL em operadores lógicos tais como:

• Seleção (filtragem de linhas)
• Projeção (escolha de colunas)
• Join (combinação de tabelas)
• Agregação (GROUP BY)

Essa forma lógica fica mais próxima da álgebra relacional do que do texto SQL, o que facilita raciocinar sobre significado e equivalência.

Por que otimizadores se parecem com otimizações de compiladores

Otimizações de compilador mantêm o resultado do programa idêntico enquanto tornam a execução mais barata. Otimizadores de banco fazem o mesmo, usando sistemas de regra como:

• empurre filtros para mais cedo (reduza trabalho mais cedo)
• reordene joins (mesmo resultado, custo diferente)
• remova computações redundantes

Essa é a versão de banco de dados de “eliminação de código morto”: não são técnicas idênticas, mas a mesma filosofia — preservar semântica, reduzir custo.

Depuração: ler planos como código compilado

Se sua consulta está lenta, não fique só no SQL. Olhe o plano de consulta como inspecionaria a saída de um compilador. Um plano mostra o que o motor escolheu de fato: ordem de join, uso de índice e onde o tempo é gasto.

Conclusão prática: aprenda a ler EXPLAIN como uma listagem de assembly de desempenho. Isso transforma tuning de adivinhação em depuração baseada em evidência. Para mais sobre transformar isso em hábito, veja /blog/practical-query-optimization-habits.

Teoria de design de esquema que impacta desempenho real

Bom desempenho muitas vezes começa antes de você escrever SQL. A teoria de design de esquema de Ullman (especialmente normalização) trata de estruturar dados para que o banco consiga mantê-los corretos, previsíveis e eficientes conforme crescem.

Objetivos da normalização (por que existe)

A normalização visa:

• Reduzir anomalias (ex.: atualizar um endereço de cliente em cinco lugares e perder um)
• Melhorar a consistência fazendo cada fato viver em um único “lar”
• Tornar restrições expressáveis (chaves, foreign keys) para que o motor possa aplicar regras em vez de confiar só na aplicação

Essas vitórias de correção se traduzem em ganhos de desempenho depois: menos campos duplicados, índices menores e menos updates caros.

Formas normais em linguagem simples

Você não precisa decorar provas para usar as ideias:

• 1NF: armazene valores em colunas atômicas (sem listas separadas por vírgula). Isso torna filtragem e indexação diretas.
• 2NF: em tabelas com chave composta, toda coluna não-chave deve depender da chave inteira (não apenas de parte dela). Evita repetir atributos por muitas linhas.
• 3NF: colunas não-chave devem depender apenas da chave, não de outras não-chaves. Evita duplicação escondida.
• BCNF: versão mais estrita da 3NF onde todo determinante é uma candidate key — útil quando colunas “quase únicas” criam duplicações sutis.

Quando denormalizar faz sentido

Denormalização pode ser uma escolha inteligente quando:

• Você está construindo tabelas analíticas pesadas (wide fact tables, reporting)
• Joins viram gargalo e você aceita redundância controlada
• Está otimizando leitura com regras de refresh claras (ex.: reconstruições noturnas)

O importante é denormalizar deliberadamente, com um processo para manter duplicações sincronizadas.

Como escolhas de esquema afetam o otimizador e a escalabilidade

O design do esquema molda o que o otimizador pode fazer. Chaves claras e foreign keys permitem melhores estratégias de join, reescritas mais seguras e estimativas de contagem de linhas mais acuradas. Em contrapartida, duplicação excessiva pode inflar índices e desacelerar escritas, e colunas multivalor bloqueiam predicados eficientes. Conforme o volume cresce, decisões de modelagem iniciais frequentemente contam mais do que micro‑otimizações de uma única consulta.

Como a teoria aparece quando sistemas escalam

Quando um sistema “escala”, raramente é só adicionar máquinas maiores. Frequentemente o ponto difícil é que o mesmo significado de consulta precisa ser preservado enquanto o motor escolhe uma estratégia física bem diferente para manter tempos previsíveis. A ênfase de Ullman em equivalências formais é justamente o que permite essas trocas de estratégia sem mudar resultados.

Escala é frequentemente layout físico + escolha de plano

Em tamanhos pequenos, muitos planos “funcionam”. Em escala, a diferença entre varrer uma tabela, usar um índice ou usar um resultado pré‑computado pode ser segundos vs. horas. O lado teórico importa porque o otimizador precisa de um conjunto seguro de regras de reescrita (ex.: empurrar filtros antes, reordenar joins) que não alterem a resposta — mesmo que mudem radicalmente o trabalho realizado.

Particionamento muda a consulta que você executa, mesmo que o SQL seja o mesmo

Particionamento (por data, cliente, região etc.) transforma uma tabela lógica em muitos pedaços físicos. Isso afeta o planejamento:

• quais partições podem ser ignoradas (partition pruning)
• se joins acontecem dentro de partições ou precisam embaralhar dados entre nós
• se agregação pode ser feita localmente antes de combinar resultados

O texto SQL pode permanecer inalterado, mas o melhor plano passa a depender de onde as linhas vivem.

Views materializadas: pré‑cálculo como atalhos algébricos

Views materializadas são essencialmente “subexpressões salvas”. Se o motor puder provar que sua consulta coincide (ou pode ser reescrita para coincidir) com um resultado armazenado, ele pode substituir trabalho caro — como joins e agregações repetidas — por uma busca rápida. Isso é álgebra relacional em prática: reconhecer equivalência e então reutilizar.

Cache: útil, mas não corrige formato de trabalho errado

Cache pode acelerar leituras repetidas, mas não salva uma consulta que precisa varrer muitos dados, embaralhar intermediários enormes ou computar um join gigantesco. Quando aparecem problemas de escala, a solução frequentemente é: reduzir a quantidade de dados tocados (layout/particionamento), reduzir computação repetida (views materializadas) ou mudar o plano — não apenas “adicionar cache”.

Hábitos práticos de otimização inspirados por Ullman

A influência de Ullman aparece em uma mentalidade simples: trate uma consulta lenta como uma declaração de intenção que o banco é livre para reescrever e, depois, verifique o que ele realmente decidiu fazer. Você não precisa ser teórico para se beneficiar — só precisa de uma rotina repetível.

1) Leia um plano EXPLAIN: o que olhar primeiro

Comece pelas partes que geralmente dominam o tempo de execução:

• Método de acesso: o motor está varrendo uma tabela inteira quando você esperava um lookup por índice?
• Estimativas vs. reais (se o banco mostra ambos): grandes gaps frequentemente explicam lentidão misteriosa.
• Ordem de join: qual tabela dirige o join, e ela começa com o filtro mais seletivo?
• Operadores caros: ordenações, builds de hash, nested loops grandes — estes frequentemente revelam onde o trabalho realmente está.

Se só fizer uma coisa, identifique o primeiro operador onde a contagem de linhas explode. Normalmente ali está a causa raiz.

2) Anti‑padrões comuns que derrotam otimizadores

São fáceis de escrever e surpreendentemente custosos:

• Funções em colunas indexadas: WHERE LOWER(email) = ... pode impedir uso de índice (use uma coluna normalizada ou índice funcional se suportado).
• Predicados faltando: esquecer um range de datas ou filtro por tenant transforma uma consulta direcionada em uma varredura ampla.
• Cross joins acidentais: uma condição de join faltante pode multiplicar linhas e forçar resultados intermediários enormes.

3) Formule uma hipótese usando pensamento algébrico

Álgebra relacional incentiva dois movimentos práticos:

• Empurre filtros mais cedo: aplique condições WHERE antes de joins sempre que possível para reduzir inputs.
• Reduza colunas cedo: selecione só as colunas necessárias (especialmente antes de joins) para cortar memória e I/O.

Uma boa hipótese soa como: “Este join é caro porque estamos juntando muitas linhas; se filtrarmos orders dos últimos 30 dias primeiro, a entrada do join cai.”

4) Índice, reescrever ou mudar esquema?

Use uma regra de decisão simples:

• Adicione um índice quando a consulta estiver correta, for seletiva e executada repetidamente.
• Reescreva a consulta quando EXPLAIN mostrar trabalho evitável (joins desnecessários, filtro aplicado tardiamente, predicados não sargáveis).
• Mude o esquema quando o padrão de workload for estável e você estiver repetidamente brigando com o mesmo gargalo (ex.: agregados pré‑computados, campos denormalizados para lookup, particionamento por tempo/tenant).

O objetivo não é “SQL engenhoso”. É obter resultados intermediários previsíveis e menores — exatamente o tipo de melhoria que as ideias de Ullman tornam mais fáceis de identificar.

Aplicando essas ideias ao construir produtos reais

Esses conceitos não são só para DBAs. Se você entrega uma aplicação, está tomando decisões de banco de dados e planejamento de consultas mesmo sem perceber: forma do esquema, escolhas de chave, padrões de consulta e a camada de acesso a dados influenciam o que o otimizador pode fazer.

Se você usa um fluxo de trabalho de vibe‑coding (por exemplo, gerar um app React + Go + PostgreSQL a partir de uma interface de chat no Koder.ai), modelos mentais no estilo Ullman são uma rede de segurança prática: você pode revisar o esquema gerado para checar chaves e relacionamentos limpos, inspecionar as consultas que sua app usa e validar desempenho com EXPLAIN antes que problemas apareçam em produção. Quanto mais rápido você iterar em “intenção da consulta → plano → correção”, mais valor tira do desenvolvimento acelerado.

Onde aprender mais e como aplicar no trabalho

Você não precisa “estudar teoria” como hobby separado. A maneira mais rápida de se beneficiar das bases de Ullman é aprender só o suficiente para ler planos de consulta com confiança — e então praticar no seu próprio banco.

Recursos acessíveis para procurar

Procure por esses livros e tópicos de aula (sem afiliação — apenas pontos de partida amplamente citados):

• “A First Course in Database Systems” (Ullman & Widom) — fundamentos de banco de dados com enquadramento prático.
• “Principles of Database and Knowledge-Base Systems” (Ullman) — teoria mais profunda se você quiser mais rigor.
• “Compilers: Principles, Techniques, and Tools” (Aho, Lam, Sethi, Ullman) — para a conexão “por que otimizadores se parecem com compiladores?”.
• Tópicos/lectures para buscar: álgebra relacional, reescrita de consultas, ordenação de joins, otimização baseada em custo, índices e seletividade, parsing e linguagens de consulta.

Um caminho leve de aprendizado

Comece pequeno e mantenha cada passo vinculado a algo observável:

1. Álgebra relacional: aprenda seleção, projeção, join e regras de equivalência.
2. Planos: aprenda a ler nós de plano (tipos de scan, filtros, joins, ordenações, agregações).
3. Joins: entenda nested loop vs hash join vs merge join e quando cada um tende a vencer.
4. Modelos de custo: aprenda as poucas entradas que dirigem decisões (contagens de linhas, seletividade, I/O vs CPU).

Exercícios pequenos que compensam rápido

Escolha 2–3 consultas reais e itere:

• Reescrever: trocar IN por EXISTS, empurrar predicados, remover colunas desnecessárias e comparar resultados.
• Comparar planos: capture planos “antes/depois” e note o que mudou (ordem de join, tipo de join, tipo de scan).
• Variar índices: adicione/remova um índice por vez e observe estimativas vs contagens reais.

Comunicar achados para colegas

Use linguagem clara, baseada em planos:

• “O plano mudou de uma varredura sequencial para um index scan porque o filtro ficou seletivo.”
• “As estimativas de linhas estavam 100× fora, então o otimizador escolheu a ordem de join errada.”
• “Esta reescrita é equivalente (mesmo resultado), mas permite predicate pushdown e menos linhas entrando no join.”

Esse é o ganho prático das fundações de Ullman: você obtém um vocabulário compartilhado para explicar desempenho — sem ficar adivinhando.