Considere o seguinte esquema de banco de dados relacional, supondo que as consultas são executadas utilizando SQL padrão (ANSI SQL):
CLIENTES
PEDIDOS
Considere a seguinte consulta SQL:
SELECT c.nome, COUNT(p.id_pedido) AS total_pedidos, SUM(p.valor) AS total_valor FROM clientes c INNER JOIN pedidos p ON c.id_cliente = p.id_cliente GROUP BY c.id_cliente, c.nome HAVING SUM(p.valor) > 150;
Assinale a alternativa que apresenta o resultado da consulta.
A
B
C
D
E
Revelar gabarito e comentário▾
GabaritoA — [imagem]
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Consulta SQL com GROUP BY e HAVING
Gabarito: letra A. A consulta agrupa os pedidos por cliente, calcula o total de pedidos e o valor total, e filtra os grupos cuja soma dos valores seja maior que 150. O resultado mostra apenas os clientes que atendem a essa condição, com as colunas nome, total_pedidos e total_valor.
A consulta SQL apresentada utiliza as cláusulas INNER JOIN, GROUP BY, HAVING e funções de agregação (COUNT e SUM). O INNER JOIN combina as tabelas clientes e pedidos com base na igualdade das chaves id_cliente, retornando apenas os registros que possuem correspondência em ambas as tabelas. Em seguida, o GROUP BY agrupa os resultados por id_cliente e nome, permitindo que as funções de agregação sejam aplicadas a cada grupo. A cláusula HAVING filtra os grupos após a agregação, mantendo apenas aqueles cuja soma dos valores dos pedidos seja maior que 150.
É importante destacar a diferença entre WHERE e HAVING: o WHERE filtra linhas antes do agrupamento, enquanto o HAVING filtra grupos após a agregação. Nesta consulta, não há cláusula WHERE, então todas as linhas resultantes do INNER JOIN são consideradas para o agrupamento. O HAVING atua sobre o resultado agregado, eliminando grupos que não atendem à condição.
Para ilustrar, suponha que a tabela clientes tenha os registros: (1, 'Ana'), (2, 'Bruno'), (3, 'Carla'). A tabela pedidos tenha: (101, 1, 100), (102, 1, 80), (103, 2, 200), (104, 3, 50). O INNER JOIN produziria as combinações: (Ana, 101, 100), (Ana, 102, 80), (Bruno, 103, 200), (Carla, 104, 50). Após o GROUP BY, teríamos os grupos: Ana (total_pedidos=2, total_valor=180), Bruno (total_pedidos=1, total_valor=200), Carla (total_pedidos=1, total_valor=50). O HAVING SUM(p.valor) > 150 filtraria os grupos de Ana e Bruno, excluindo Carla. O resultado final seria: Ana, 2, 180 e Bruno, 1, 200.
A pegadinha desta questão está na interpretação do HAVING: muitos candidatos confundem com WHERE e tentam filtrar antes do agrupamento, ou esquecem que o HAVING é aplicado após a agregação. Além disso, é comum errar ao considerar que o INNER JOIN exclui clientes sem pedidos, o que é verdade, mas não afeta o resultado se todos os clientes tiverem pedidos.
Guarde a distinção entre WHERE e HAVING e a ordem de execução das cláusulas: FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY. É exatamente essa ordem que determina o resultado da consulta.
1FROM
2JOIN
3WHERE
4GROUP BY
5HAVING
6SELECT
7ORDER BY
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
A alternativa A apresenta o resultado correto da consulta, listando apenas os clientes cuja soma dos valores dos pedidos é maior que 150, com as colunas nome, total_pedidos e total_valor. O GROUP BY agrupa corretamente por cliente e o HAVING filtra os grupos conforme a condição.
Alternativa B — ❌ Incorreta
A alternativa B provavelmente inclui clientes que não atendem à condição do HAVING, como aqueles com soma de valores menor ou igual a 150. Isso ocorre quando o candidato ignora o filtro do HAVING ou o aplica incorretamente, considerando todos os grupos.
Alternativa C — ❌ Incorreta
A alternativa C pode apresentar um resultado sem a aplicação do GROUP BY, mostrando uma linha por pedido em vez de uma linha por cliente. Isso acontece quando o candidato não entende que o GROUP BY consolida os registros por grupo.
Alternativa D — ❌ Incorreta
A alternativa D pode conter valores incorretos de total_pedidos ou total_valor, como resultado de um agrupamento inadequado ou de uma condição de HAVING mal aplicada. Por exemplo, pode ter usado WHERE em vez de HAVING, filtrando pedidos individuais antes da agregação.
Alternativa E — ❌ Incorreta
A alternativa E pode listar todos os clientes, inclusive aqueles sem pedidos, o que não ocorre com INNER JOIN. Isso acontece quando o candidato confunde INNER JOIN com LEFT JOIN, que preservaria clientes sem pedidos.