Questão de Banco de Dados — Consultas e Comandos em SQL — Quadrix 2025
Banco de Dados›Consultas e Comandos em SQL
Código
qa699137
Banca
Quadrix
Órgão
CRMV GO
Ano
2025
Cargo
Ana Adm ( )
O Conselho Regional de Medicina Veterinária do Estado de Goiás (CRMV‑GO) mantinha um banco de dados relacional denominado CRMV_GO, que registrava veterinários, especialidades, clínicas e atendimentos. As principais tabelas estão dispostas a seguir. VETERINARIO (id_vet, nome, crmv, data_inscricao, id_especialidade, ativo) ESPECIALIDADE (id_especialidade, descricao) CLINICA (id_clinica, nome_clinica, cidade) ATENDIMENTO (id_atendimento, id_vet, id_clinica, data_atendimento, status) Com base nessa situação hipotética e no uso do comando SELECT no banco de dados CRMV_GO, julgue o item seguinte. O comando a seguir apresenta corretamente os veterinários que possuem mais atendimentos em clínicas de Brasília do que em Goiânia. SELECT v.nome FROM VETERINARIO v INNER JOIN ATENDIMENTO a ON v.id_vet = a.id_vet INNER JOIN CLINICA c ON a.id_clinica = c.id_clinica WHERE c.cidade = 'Brasília' GROUP BY v.id_vet HAVING COUNT(a.id_atendimento) > ( SELECT COUNT(a2.id_atendimento) FROM ATENDIMENTO a2 INNER JOIN CLINICA c2 ON a2.id_clinica = c2.id_clinica WHERE c2.cidade = 'Goiânia' );
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
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”.
Consultas SQL: agrupamento, HAVING e subconsultas correlacionadas
Gabarito: ERRADO (letra E). O comando apresentado não apresenta corretamente os veterinários que possuem mais atendimentos em clínicas de Brasília do que em Goiânia, porque a subconsulta na cláusula HAVING não é correlacionada — ela calcula o total de atendimentos em Goiânia de todos os veterinários, e não apenas do veterinário do grupo atual. Para que a comparação fosse correta, seria necessário correlacionar a subconsulta com o v.id_vet do grupo, algo como WHERE c2.cidade = 'Goiânia' AND a2.id_vet = v.id_vet.
O comando SQL apresentado tenta responder a uma pergunta que envolve comparar, para cada veterinário, a quantidade de atendimentos em duas cidades diferentes. A estrutura geral está correta: usa INNER JOIN para combinar as tabelas, WHERE para filtrar os atendimentos de Brasília, GROUP BY para agrupar por veterinário e HAVING para filtrar os grupos que atendem à condição. O problema está na subconsulta dentro do HAVING.
A cláusula HAVING é aplicada após o agrupamento e permite filtrar grupos com base em funções de agregação. No comando, o HAVING COUNT(a.id_atendimento) > (SELECT COUNT(a2.id_atendimento) ...) compara a contagem de atendimentos em Brasília de cada veterinário com o resultado da subconsulta. Porém, a subconsulta não possui nenhuma referência ao veterinário do grupo externo — ela simplesmente conta todos os atendimentos em clínicas de Goiânia, independentemente de qual veterinário os realizou. Isso faz com que a comparação seja feita contra um valor global, e não contra o número de atendimentos em Goiânia daquele veterinário específico.
Para ilustrar, imagine que o veterinário João tenha 5 atendimentos em Brasília e 2 em Goiânia, e que o total de atendimentos em Goiânia de todos os veterinários seja 100. O comando compararia 5 > 100, o que é falso, e João não seria listado, mesmo tendo mais atendimentos em Brasília do que em Goiânia. A subconsulta precisaria ser correlacionada, referenciando o v.id_vet do grupo externo, para que a contagem fosse apenas dos atendimentos daquele veterinário em Goiânia.
A pegadinha da banca está em apresentar uma consulta que parece correta à primeira vista, mas que falha justamente na correlação da subconsulta. O candidato que não percebe que a subconsulta não está vinculada ao grupo externo pode marcar a alternativa como correta. A distinção crucial é entre uma subconsulta não correlacionada (que é executada uma única vez e retorna um valor fixo) e uma subconsulta correlacionada (que é executada para cada linha ou grupo externo, referenciando valores da consulta externa).
NÃO CAIA NESSA!
A banca explora a confusão entre subconsulta correlacionada e não correlacionada. A subconsulta no HAVING não referencia o v.id_vet do grupo externo, então ela retorna o total de atendimentos em Goiânia de todos os veterinários, não de cada um. Para corrigir, seria necessário adicionar AND a2.id_vet = v.id_vet na subconsulta.
Subconsulta no HAVING
1Não correlacionada (errada)
Calcula total de Goiânia de todos os veterinários
Compara contra valor global
Resultado incorreto
2Correlacionada (correta)
Referencia v.id_vet do grupo externo
Conta só os atendimentos daquele veterinário
Comparação individual correta
LEVEL · soulevel.com.br
Item — ❌ ERRADO
O comando está incorreto porque a subconsulta na cláusula HAVING não é correlacionada. Ela calcula o total de atendimentos em Goiânia para todos os veterinários, e não apenas para o veterinário do grupo atual. A comparação COUNT(a.id_atendimento) > (SELECT COUNT(a2.id_atendimento) ...) compara a contagem de cada veterinário em Brasília com um valor global, o que não atende ao requisito de "possuem mais atendimentos em clínicas de Brasília do que em Goiânia". Para que a consulta ficasse correta, a subconsulta deveria ser correlacionada, incluindo a condição AND a2.id_vet = v.id_vet.