Questão de Tecnologia da Informação · CESGRANRIO BASA 02/2021 (nº 34)

Conceito-chave: Para saber o que está em uma tabela mas não em outra, usamos uma subconsulta (um SELECT dentro de outro) combinada com o operador NOT IN, que filtra os registros que não aparecem na lista retornada pela subconsulta. É como perguntar: "me dê os CPFs da tabela A que não estão na lista de CPFs da tabela B".

• (A) Correta: WHERE PESSOA_FISICA.CPF NOT IN (SELECT CPF FROM CLIENTE...) — exatamente o que a tarefa pede: seleciona da tabela PESSOA_FISICA apenas os CPFs que não estão na subconsulta que lista todos os CPFs da tabela CLIENTE.
• (B) Incorreta: HAVING é usado para filtrar grupos após GROUP BY, não para comparar colunas de tabelas diferentes; além disso, a condição PESSOA_FISICA.CPF != CLIENTE.CPF compararia linha a linha sem critério de junção, gerando um produto cartesiano e resultados errados.
• (C) Incorreta: WHERE PESSOA_FISICA.CPF <> CLIENTE.CPF sem um JOIN ou subconsulta compara cada CPF de uma tabela com cada CPF da outra, retornando linhas incorretas (inclusive clientes que existem, pois o CPF deles é diferente de outros CPFs).
• (D) Incorreta: DISTINCT PESSOA_FISICA.CPF FROM CLIENTE é sintaxe inválida — DISTINCT não vem antes do nome da coluna dessa forma, e a consulta está lendo da tabela CLIENTE, não da PESSOA_FISICA, invertendo a lógica.
• (E) Incorreta: IN PESSOA_FISICA BUT NOT IN CLIENTE não é sintaxe SQL válida; o correto seria NOT IN (SELECT ...), e a palavra BUT não existe em SQL.

Armadilha da banca na alternativa (C): Ela parece lógica à primeira vista ("CPF diferente"), mas esquece que, sem uma subconsulta ou JOIN, o banco compara todas as combinações entre as duas tabelas. Assim, um CPF que é cliente apareceria como "não cliente" porque ele é diferente de outros CPFs da tabela CLIENTE, gerando um resultado absurdo e cheio de duplicatas.