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

SQL: subconsultas correlacionadas e junções

Gabarito: letra B. A consulta SELECT p.numero_processo FROM Processo p WHERE EXISTS(SELECT 1 FROM Decisao d WHERE d.id_processo=p.id_processo) é a única que lista apenas os processos que possuem pelo menos uma decisão, sem repetições, pois o EXISTS verifica a existência de pelo menos uma linha correspondente na tabela Decisao para cada processo, retornando o processo uma única vez.

O problema pede para listar os processos que já possuem pelo menos uma decisão registrada. Isso é uma consulta de semi-junção (semi-join): queremos os registros da tabela Processo que têm correspondência na tabela Decisao, mas sem duplicar o resultado caso um processo tenha várias decisões. O comando EXISTS é a forma mais direta e idiomática de expressar essa necessidade em SQL: para cada linha de Processo, o banco verifica se existe ao menos uma linha em Decisao com o mesmo id_processo. Se existir, o processo entra no resultado; se não, é descartado. Como a verificação é de existência (e não de junção), não há risco de duplicação — cada processo aparece exatamente uma vez.

Outra forma equivalente seria usar IN com uma subconsulta que retorna os id_processo distintos da tabela Decisao: SELECT p.numero_processo FROM Processo p WHERE p.id_processo IN (SELECT DISTINCT d.id_processo FROM Decisao d). Essa abordagem também evita repetições, pois o IN testa pertinência a um conjunto. No entanto, a alternativa D usa IN (SELECT 1 FROM Decisao), que é incorreta porque a subconsulta retorna o valor constante 1 para cada linha de Decisao, e não os id_processo — o teste p.id_processo IN (1, 1, 1, ...) só seria verdadeiro se algum processo tivesse id_processo igual a 1, o que não atende ao requisito.

A alternativa C usa um JOIN simples (inner join), que retorna uma linha para cada par (processo, decisão). Se um processo tiver múltiplas decisões, ele aparecerá múltiplas vezes no resultado — violando o requisito de "sem repetições". Para corrigir, seria necessário adicionar DISTINCT ao SELECT, mas a alternativa não o faz. A alternativa A usa um LEFT JOIN com filtro WHERE d.id_processo IS NULL, que retorna exatamente os processos sem nenhuma decisão — o oposto do que se pede. A alternativa E seleciona d.descricao da tabela Decisao, não o número do processo, e não atende ao comando.

A pegadinha central desta questão é a distinção entre junção (que combina linhas e pode duplicar) e semi-junção (que filtra por existência e não duplica). O EXISTS é a ferramenta certa para o requisito "pelo menos uma decisão, sem repetições".

Alternativa A — ❌ Incorreta

Esta consulta usa LEFT JOIN e filtra WHERE d.id_processo IS NULL. O LEFT JOIN preserva todas as linhas da tabela à esquerda (Processo) e traz as correspondências da direita (Decisao); quando não há correspondência, os campos de Decisao ficam NULL. O filtro IS NULL seleciona exatamente esses processos sem nenhuma decisão — o inverso do que o enunciado pede. Para listar os processos com decisão, o filtro correto seria WHERE d.id_processo IS NOT NULL (e ainda assim precisaria de DISTINCT para evitar repetições).

Alternativa B — ✅ Correta ⟵ GABARITO

O EXISTS é a forma canônica de expressar uma semi-junção. Para cada linha de Processo p, a subconsulta correlacionada verifica se existe ao menos uma linha em Decisao d com d.id_processo = p.id_processo. Se existir, o processo é incluído no resultado; caso contrário, é descartado. Como a verificação é de existência, cada processo aparece exatamente uma vez, mesmo que tenha várias decisões — atendendo perfeitamente ao requisito "pelo menos uma decisão, sem repetições".

Alternativa C — ❌ Incorreta

O JOIN (inner join) combina cada linha de Processo com cada linha correspondente de Decisao. Se um processo tiver três decisões, ele aparecerá três vezes no resultado — o que viola o requisito de "sem repetições". Para obter o resultado desejado, seria necessário usar SELECT DISTINCT p.numero_processo, mas a alternativa não inclui DISTINCT. O JOIN é útil quando se precisa de dados de ambas as tabelas, mas não é adequado para uma simples verificação de existência.

Alternativa D — ❌ Incorreta

A subconsulta SELECT 1 FROM Decisao retorna o valor constante 1 para cada linha da tabela Decisao. O teste p.id_processo IN (1, 1, 1, ...) só seria verdadeiro se algum processo tivesse id_processo igual a 1 — o que não tem relação com o requisito. A forma correta com IN seria WHERE p.id_processo IN (SELECT DISTINCT d.id_processo FROM Decisao d), que retorna os identificadores dos processos que possuem decisão. A alternativa troca a coluna correta pela constante 1, tornando a consulta semanticamente errada.

Alternativa E — ❌ Incorreta

Esta consulta seleciona d.descricao da tabela Decisao, não o numero_processo da tabela Processo. Além disso, filtra apenas d.id_processo IS NOT NULL, o que é sempre verdadeiro para linhas existentes em Decisao (a chave estrangeira não pode ser nula por definição). O resultado seria uma lista de descrições de decisões, não de números de processos — completamente fora do que o enunciado pede.

Gabarito: letra B