Questão de Banco de Dados — Consultas e Comandos em SQL — Quadrix 2025
Banco de Dados›Consultas e Comandos em SQL
Código
qa699136
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 apenas veterinários ativos cujo CRMV termina com “1234” e que realizaram atendimentos na cidade de Goiânia, utilizando subconsulta correlacionada. SELECT nome FROM VETERINARIO v WHERE ativo = 1 AND crmv LIKE '%1234' AND EXISTS ( SELECT 1 FROM ATENDIMENTO a INNER JOIN CLINICA c ON a.id_clinica = c.id_clinica WHERE a.id_vet = v.id_vet AND c.cidade = 'Goiânia' );
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoC — Certo
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”.
Subconsultas correlacionadas e o operador EXISTS em SQL
Gabarito: CERTO (letra C). O comando apresentado está sintaticamente correto e semanticamente adequado: filtra veterinários ativos (ativo = 1), cujo CRMV termina com "1234" (crmv LIKE '%1234') e que possuam ao menos um atendimento em clínica localizada em Goiânia, por meio de uma subconsulta correlacionada com o operador EXISTS. A correlação é estabelecida pela condição a.id_vet = v.id_vet, que referencia a tabela externa VETERINARIO v dentro da subconsulta.
A subconsulta correlacionada é um dos conceitos mais cobrados em SQL e, ao mesmo tempo, um dos mais mal compreendidos. Diferentemente de uma subconsulta simples (não correlacionada), que é executada uma única vez e cujo resultado é usado pela consulta externa, a subconsulta correlacionada é executada para cada linha da consulta externa. Isso ocorre porque ela faz referência a uma coluna da tabela externa — no caso, v.id_vet — e, portanto, seu resultado depende da linha que está sendo avaliada no momento.
O operador EXISTS é um predicado lógico que retorna verdadeiro se a subconsulta retornar pelo menos uma linha. Ele não retorna dados; apenas testa a existência. No comando em questão, para cada veterinário ativo com CRMV terminando em "1234", o banco executa a subconsulta: se existir algum registro em ATENDIMENTO cujo id_vet seja igual ao id_vet do veterinário atual e cuja clínica associada (via INNER JOIN com CLINICA) esteja em Goiânia, o veterinário é incluído no resultado. Caso contrário, é excluído.
A cláusula LIKE '%1234' merece atenção especial. O caractere % é um curinga que corresponde a qualquer sequência de caracteres (inclusive vazia). Assim, '%1234' casa com qualquer valor de crmv que termine com "1234", independentemente do que vier antes. Isso atende exatamente ao requisito do enunciado: "CRMV termina com '1234'".
O INNER JOIN entre ATENDIMENTO e CLINICA é necessário porque a cidade da clínica não está na tabela ATENDIMENTO — ela está em CLINICA. O join conecta as duas tabelas pela chave id_clinica, permitindo filtrar por c.cidade = 'Goiânia'. A condição a.id_vet = v.id_vet dentro da subconsulta é o que a torna correlacionada, amarrando cada avaliação ao veterinário da consulta externa.
A pegadinha que a banca poderia explorar — e que não está presente aqui — seria trocar EXISTS por IN com uma subconsulta que retorna múltiplas colunas, ou usar NOT EXISTS sem necessidade. Outra armadilha comum seria afirmar que a subconsulta não é correlacionada, quando claramente é, pela referência v.id_vet. Nesta questão, todos os elementos estão corretos e a descrição do comando bate perfeitamente com o que ele faz.
NÃO CAIA NESSA!
A banca poderia ter trocado o operador EXISTS por IN ou invertido a correlação (por exemplo, v.id_vet = a.id_vet dentro da subconsulta, o que quebraria a lógica). Aqui, porém, a correlação está correta: a.id_vet = v.id_vet referencia a tabela externa VETERINARIO v, tornando a subconsulta genuinamente correlacionada. Fique atento a essa inversão em outras questões — é o erro clássico.
1Filtra ativo = 1
2Filtra CRMV LIKE '%1234'
3Para cada linha, roda EXISTS
4Join ATENDIMENTO × CLINICA
5Filtra cidade = Goiânia
6Inclui se EXISTS retorna linha
LEVEL · soulevel.com.br
Item — ✅ CERTO
O comando está correto por três razões:
Filtro de veterinários ativos: WHERE ativo = 1 seleciona apenas os veterinários com o campo ativo igual a 1.
Filtro do CRMV: crmv LIKE '%1234' seleciona apenas os veterinários cujo número de CRMV termina com "1234".
Subconsulta correlacionada com EXISTS: a subconsulta verifica, para cada veterinário que passou nos filtros anteriores, se existe ao menos um atendimento (ATENDIMENTO a) cujo id_vet seja igual ao id_vet do veterinário externo (a.id_vet = v.id_vet) e cuja clínica (CLINICA c, via INNER JOIN) esteja em Goiânia (c.cidade = 'Goiânia').
A correlação é o ponto central: a condição a.id_vet = v.id_vet referencia a tabela VETERINARIO v da consulta externa, fazendo com que a subconsulta seja reavaliada para cada linha candidata. O EXISTS retorna verdadeiro se houver pelo menos um atendimento correspondente, incluindo o veterinário no resultado final.