Observe a inserção dos registros pelo seguinte script SQL. INSERT INTO Parte (ParteID, idade) VALUES (1 ,17); INSERT INTO Parte (ParteID, idade) VALUES (2 ,16); INSERT INTO Processo (processoID, data_audiencia, valor_causa) VALUES (1 ,'2025-02-05',1000); INSERT INTO Processo (processoID, data_audiencia, valor_causa) VALUES (2 ,'2025-10-05',2000); INSERT INTO ProcessoParte (processoID, parteid) VALUES (1 ,1); INSERT INTO ProcessoParte (processoID, parteid) VALUES (2 ,2); No PostgreSQL, para consultar os Processos (Processos) que envolvem partes menores que 18 anos, por ordem de maior Valor de Causa (valor_causa), cuja Audiência (data_audiencia) está agendada para os próximos 30 dias, deve-se executar o comando SQL:
- A)SELECT p.processoid, p.valor_causa, p.data_audiencia FROM Parte pt, ProcessoParte pp , Processo p WHERE pp.parteid = pt.parteid and pp.processoid = p.processoid AND pt.idade < 18 AND p.data_audiencia BETWEEN NOW()::DATE AND NOW()::DATE + INTERVAL '30 days' ORDER BY p.valor_causa DESC
Certa: faz os JOINs necessários, filtra partes menores de 18 anos, limita a audiência aos próximos 30 dias e ordena o valor da causa em ordem decrescente.
- B)SELECT p.processoid as numero, SUM(p.valor_causa) as ValorCausa, p.data_audiencia FROM processo p INNER JOIN parte pt ON pt.idade < 18 INNER JOIN ProcessoParte pp ON pp.parteid = pt.parteid WHERE p.data_audiencia BETWEEN NOW() AND NOW() + INTERVAL '30 days' GROUP BY p.processoid, p.data_audiencia ORDER BY ValorCausa DESC
Errada: usa INNER JOIN de forma inadequada, falta relacionar corretamente as tabelas por chaves na cláusula ON e ainda soma valor_causa sem necessidade.
- C)SELECT p.processoid as numero, SUM(p.valor_causa) as ValorCausa, p.data_audiencia as DataAudiencia FROM Processo p INNER JOIN ProcessoParte pp ON p.ProcessoID = pp.ProcessoID INNER JOIN Parte pt ON pp.ParteID = pt.ParteID WHERE pt.idade < 18 AND p.data_audiencia > NOW() + INTERVAL '30 days' GROUP BY p.processoid, p.data_audiencia ORDER BY ValorCausa ASC
Errada: filtra datas para depois de 30 dias, quando o enunciado pede os próximos 30 dias, e ainda ordena em ordem crescente.
- D)SELECT p.processoid as numero, p.valor_causa, p.data_audiencia FROM Parte pt INNER JOIN Processo p ON pt.idade < 18 AND p.data_audiencia BETWEEN NOW() AND CURRENT_DATE + DATE_PART('DAY', 30)
Errada: a junção entre Parte e Processo está incompleta e a expressão com DATE_PART('DAY', 30) não é a forma correta de somar 30 dias nessa consulta.
- E)SELECT p.processoid, p.valor_causa, p.data_audiencia FROM processo p INNER JOIN parte pt ON pt.idade < 18 WHERE p.data_audiencia BETWEEN NOW() AND NOW() + 30
Errada: o filtro de idade está no JOIN sem vínculo com ProcessoParte e a comparação de datas com + 30 não representa corretamente um intervalo de 30 dias no PostgreSQL.
Gabarito: A
A questão cobra uma consulta com junção entre três tabelas: Parte, ProcessoParte e Processo. A lógica é simples: primeiro você identifica as partes menores de 18 anos, depois encontra os processos vinculados a essas partes e, por fim, filtra os processos cuja data de audiência esteja dentro dos próximos 30 dias. Em SQL, isso normalmente é feito com JOIN entre as tabelas e um filtro de faixa de datas usando NOW() e INTERVAL, recurso bem típico do PostgreSQL. O ponto central aqui é não se perder no caminho: a idade está em Parte, o vínculo entre parte e processo está em ProcessoParte e os dados do processo estão em Processo. Sem essas três peças, a consulta fica incompleta ou errada. Além disso, para ordenar por maior valor da causa, usa-se ORDER BY p.valor_causa DESC. O gabarito A está correto porque faz exatamente essa amarração: junta Parte, ProcessoParte e Processo, filtra idade menor que 18, restringe a audiência aos próximos 30 dias com BETWEEN NOW()::DATE AND NOW()::DATE + INTERVAL '30 days', e ordena por valor_causa em ordem decrescente. Em PostgreSQL, essa forma de somar intervalo de tempo é perfeitamente válida e muito cobrada. Um detalhe importante: não há necessidade de SUM, porque a pergunta pede os processos, não a soma de valores. Também não há motivo para agrupar se cada processo já aparece uma vez no resultado. Em prova da FGV, desconfie de alternativas com excesso de enfeite SQL: às vezes elas parecem sofisticadas, mas estão só confundindo o caminho.