PARTE I – RETA FINAL FCC – BANCO DE DADOS – CPU PERNAMBUCO

Olá, alunos!

Sejam muito bem-vindos à nossa reta final FCC rumo à CPU Pernambuco.
Este material foi elaborado especificamente para quem está na última fase da preparação e precisa de clareza, objetividade e foco absoluto no que a banca realmente cobra — e não no que culturalmente se estuda em Banco de Dados.

A FCC 2024–2025 consolidou um estilo muito claro: simples, direto e eliminatório.
Ela não quer criatividade, não quer floreio, não quer complexidade teórica.
Ela quer a execução exata, sem erro conceitual e sem inventar sintaxe.

Neste primeiro artigo (Parte I), nosso objetivo é fixar quatro pontos críticos:

• UPDATE condicional sem função agregadora
• Integridade referencial (bloqueio x cascata)
• CHECK em Oracle
• HAVING apenas após agrupamento

1. Quando FCC quer reduzir valores: só multiplicação

Não invente, não insira AVG, não subtraia.

UPDATE multas_tributarias

   SET valor_multa = valor_multa * 0.9

 WHERE status = ‘Pendente’

   AND data_aplicacao < ‘2023-01-01’;

 Por que FCC ama essa questão?

• Porque 70% dos candidatos trocam:
  • 0.9 por -10
  • multiplicação por AVG()
  • ‘2023-01-01’ por 2023 sem formato

 Regra final para memorizar:
Percentual em UPDATE = multiplicação, nunca subtração.

 2. Integridade Referencial: a banca só quer o desfecho

A FCC está programaticamente usando o seguinte cenário:

FCC não quer narrativa, quer o que acontece.

Exemplo clássico:

“Se a empresa for excluída, todas as fiscalizações associadas serão removidas automaticamente.”

Só será verdade se houver ON DELETE CASCADE.

Caso contrário:

Erro. Exclusão impedida.

 3. CHECK em Oracle virou atenção obrigatória

A banca está cobrando exatamente a forma correta de adição de restrição.

ALTER TABLE processo

  ADD custas NUMBER(10,2)

  CONSTRAINT processo_custas_ck CHECK (custas > 10000);

Pegadinhas:

• >= no lugar de >
• WHERE no lugar de CHECK
• CHECK sem operador (custas 10000)
• sintaxe invertida

 A restrição é avaliada no momento da inserção, não de uso posterior.

 4. HAVING não é WHERE

FCC repete a mesma matriz:

SELECT id_vara, COUNT(*) AS total, SUM(valor_processo) AS valor_total

  FROM rprocessos

 WHERE data_abertura < ‘2020-01-01’

 GROUP BY id_vara

HAVING COUNT(*) > 100

 ORDER BY SUM(valor_processo) DESC;

Erros previstos pela banca:

• inverter HAVING e ORDER BY
• trocar COUNT por SUM
• repetir filtro que era de WHERE no HAVING

 Regrinha de ouro:

• WHERE filtra antes
• HAVING filtra depois

 Encerramento da Parte I

Nesta primeira parte, asseguramos o essencial:

• UPDATE sem invenção
• integridade sem teoria prolixa
• CHECK como bloqueio real
• HAVING no lugar certo

Na Parte II, vamos descer para:

• BCNF sem dramatização conceitual
• JOIN com intenção da FCC
• Dicas finais de decoreba para véspera

Agora, siga direto para o próximo artigo !!!