Questão de Banco de Dados — Consultas e Comandos em SQL — FCC 2025

Consultas SQL: agrupamento com GROUP BY, filtro com HAVING e ordenação

Gabarito: letra A. A consulta correta precisa filtrar os processos abertos antes de 1º de janeiro de 2020 (WHERE), agrupar por vara (GROUP BY id_vara), contar e somar os valores por grupo, manter apenas os grupos com mais de 100 processos (HAVING COUNT(*) > 100) e ordenar o resultado pelo valor total em ordem decrescente (ORDER BY SUM(valor_processo) DESC). A alternativa A é a única que apresenta todas essas cláusulas na ordem sintaticamente correta e com a semântica exata pedida.

O comando SQL é uma linguagem declarativa: você diz o que quer obter, não como obter. Para responder a essa questão, é preciso dominar a função de cada cláusula e, principalmente, a ordem lógica de execução de uma consulta, que não é a ordem em que escrevemos o comando. O banco de dados processa a consulta na seguinte sequência: primeiro o FROM (define a tabela), depois o WHERE (filtra as linhas individuais), em seguida o GROUP BY (agrupa as linhas que sobreviveram ao filtro), depois o HAVING (filtra os grupos), na sequência o SELECT (calcula as expressões e projeções) e, por fim, o ORDER BY (ordena o resultado final).

Essa ordem explica os dois erros clássicos que a banca explora nesta questão. O primeiro: o WHERE filtra linhas antes do agrupamento, então não pode usar funções de agregação como COUNT(*) ou SUM(...) — isso é papel do HAVING, que filtra grupos depois do GROUP BY. O segundo: o ORDER BY é a última cláusula a ser executada, por isso pode referenciar os apelidos (alias) criados no SELECT, como valor_total — algo que o WHERE e o HAVING não podem fazer, pois são executados antes.

Vamos aplicar isso ao enunciado. Precisamos listar id_vara, o total de processos por vara e o valor total, em ordem decrescente, somente das varas com mais de 100 processos abertos antes de 1º de janeiro de 2020. O filtro de data (data_abertura < '2020-01-01') é um filtro de linha, então vai no WHERE. O agrupamento por vara é o GROUP BY id_vara. A condição "mais de 100 processos" é uma condição sobre o grupo (o resultado da agregação COUNT(*)), então vai no HAVING. A ordenação decrescente pelo valor total é o ORDER BY SUM(valor_processo) DESC. A alternativa A é a única que monta exatamente essa estrutura.

A pegadinha central desta questão é a ordem das cláusulas e a função de cada uma. A banca mistura a posição do HAVING (que deve vir depois do GROUP BY e antes do ORDER BY), troca o operador de comparação (< por <=), usa COUNT(id_processo) em vez de COUNT(*) (o que não muda o resultado, mas foge do pedido), e até inventa uma ordenação por COUNT(valor_total) que não faz sentido. Guarde a sequência lógica de execução e a fronteira entre WHERE (filtra linha) e HAVING (filtra grupo): é exatamente nesses dois pontos que as alternativas se dividem.

Alternativa A — ✅ Correta ⟵ GABARITO

A consulta está sintaticamente correta e semanticamente exata. O WHERE data_abertura < '2020-01-01' filtra apenas os processos abertos antes da data limite (o enunciado pede "antes de 1º de janeiro de 2020", portanto o operador < é o correto, excluindo o dia 1º de janeiro). O GROUP BY id_vara agrupa os registros por vara. O HAVING COUNT(*) > 100 mantém somente os grupos com mais de 100 processos — repare que o HAVING vem depois do GROUP BY e antes do ORDER BY, na posição correta. O ORDER BY SUM(valor_processo) DESC ordena o resultado pelo valor total em ordem decrescente, exatamente como pedido. Todas as cláusulas estão na ordem lógica de execução correta.

Alternativa B — ❌ Incorreta

O erro está na posição do HAVING: ele aparece depois do ORDER BY. A ordem correta das cláusulas é GROUP BY → HAVING → ORDER BY. O HAVING filtra os grupos antes da ordenação final; colocá-lo depois do ORDER BY é um erro de sintaxe no Oracle e em qualquer SGBD relacional. A banca inverteu a posição para testar se o candidato conhece a ordem lógica de execução.

Alternativa C — ❌ Incorreta

Esta alternativa acumula vários erros. Primeiro, a data está no formato '2020-JAN-01', que não é um formato de data padrão reconhecido pelo Oracle sem conversão explícita (o formato padrão é 'YYYY-MM-DD' ou com TO_DATE). Segundo, o GROUP BY id vara tem um espaço no nome da coluna (id vara em vez de id_vara), o que o tornaria um identificador inválido. Terceiro, o ORDER BY COUNT(valor_total) não faz sentido: COUNT conta linhas, não soma valores, e valor_total é um apelido que representa a soma, não uma coluna a ser contada. O correto seria ORDER BY SUM(valor_processo) DESC.

Alternativa D — ❌ Incorreta

O erro está no operador de comparação da data: data_abertura <= '2020-01-01' inclui os processos abertos no dia 1º de janeiro de 2020, mas o enunciado pede os processos abertos antes dessa data (<). Além disso, a consulta não tem a cláusula HAVING, então não filtra as varas com mais de 100 processos — ela retornaria todas as varas, independentemente da quantidade. E o ORDER BY valor_total ordena em ordem crescente (padrão), enquanto o pedido é decrescente (DESC).

Alternativa E — ❌ Incorreta

O erro está na condição do HAVING: HAVING SUM(valor_processo) > 100000 filtra as varas cujo valor total dos processos é maior que 100.000, mas o enunciado pede as varas com mais de 100 processos (COUNT(*) > 100). A banca trocou a função de agregação: em vez de contar os processos, somou os valores. Além disso, o ORDER BY valor_total DESC referencia o apelido valor_total, o que é válido, mas a condição do HAVING está errada.

Gabarito: letra A