Procedures, triggers e views; PostgreSQL e Oracle

Do zero

Até aqui, o banco de dados foi um armário onde se guarda e se consulta. Ele também pode trabalhar sozinho:

• Uma view é uma janela com moldura: em vez de mostrar a tabela inteira, mostra só uma parte, já filtrada e juntada, como se fosse uma tabela. Você consulta a view como consulta uma tabela, mas ela não guarda dados próprios; é uma consulta salva com nome.
• Uma stored procedure é uma receita guardada no banco: um conjunto de comandos que se executa com uma chamada (“reajustar todos os contratos em 5%”).
• Uma function é parecida, mas devolve um valor e pode ser usada dentro de um SELECT, como calcula_multa(valor).
• Um trigger (gatilho) é um alarme: dispara sozinho quando algo acontece numa tabela, por exemplo, “sempre que o valor de um contrato mudar, grave um registro de auditoria”.

PostgreSQL e Oracle são dois dos SGBDs (sistemas gerenciadores de banco de dados) relacionais mais usados no setor público. Os dois falam SQL, mas cada um tem a sua linguagem procedural (PL/pgSQL e PL/SQL) e as suas ferramentas de administração.

Frase para guardar: view é consulta com nome; procedure executa, function devolve valor; trigger dispara sozinho com um evento.

Em 1 minuto

• View: tabela virtual definida por um SELECT; simplifica consultas e restringe o que o usuário vê. A view materializada guarda o resultado e precisa ser atualizada (REFRESH).
• Stored procedure: no PostgreSQL, chamada com CALL; no Oracle, com CALL, com EXEC no SQL*Plus ou pelo nome dentro de um bloco PL/SQL (EXEC também é o comando do SQL Server). Pode receber parâmetros de entrada e saída.
• Function: devolve um valor e pode aparecer em SELECT e WHERE.
• Trigger: associado a uma tabela e a um evento (INSERT, UPDATE, DELETE), antes (BEFORE) ou depois (AFTER), por linha (FOR EACH ROW) ou por comando. Acessa os valores antigos e novos (OLD e NEW).
• Administração: usuários e papéis com GRANT e REVOKE, backup, estatísticas para o otimizador, monitoramento e ajuste de consultas.

Exemplo concreto: auditoria dos contratos no PostgreSQL

View com os contratos vigentes, para o painel da diretoria:

CREATE VIEW contrato_vigente AS
SELECT c.numero, c.objeto, c.valor, f.nome AS fornecedor
FROM contrato c
JOIN fornecedor f ON f.cnpj = c.cnpj
WHERE c.fim >= CURRENT_DATE;

-- Usada como uma tabela
SELECT * FROM contrato_vigente WHERE valor > 100000;

Trigger que registra toda mudança de valor:

CREATE FUNCTION registra_alteracao() RETURNS trigger AS $$
BEGIN
  INSERT INTO auditoria_contrato (numero, valor_antigo, valor_novo, usuario, alterado_em)
  VALUES (OLD.numero, OLD.valor, NEW.valor, current_user, now());
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_auditoria_valor
AFTER UPDATE OF valor ON contrato
FOR EACH ROW
WHEN (OLD.valor IS DISTINCT FROM NEW.valor)   -- só quando o valor muda de fato
EXECUTE FUNCTION registra_alteracao();

No PostgreSQL, o trigger chama uma função à parte. No Oracle, o mesmo gatilho tem o corpo no próprio trigger, e os registros levam dois-pontos (:OLD e :NEW):

CREATE OR REPLACE TRIGGER trg_auditoria_valor
AFTER UPDATE OF valor ON contrato
FOR EACH ROW
BEGIN
  INSERT INTO auditoria_contrato (numero, valor_antigo, valor_novo, usuario, alterado_em)
  VALUES (:OLD.numero, :OLD.valor, :NEW.valor, USER, SYSTIMESTAMP);
END;
/

Procedure para o reajuste anual:

CREATE PROCEDURE reajustar(p_percentual numeric)
LANGUAGE plpgsql AS $$
BEGIN
  UPDATE contrato SET valor = valor * (1 + p_percentual / 100);
END;
$$;

CALL reajustar(5);   -- e o trigger registra cada contrato alterado

Comparação: os objetos e os dois SGBDs

MVCC (controle de concorrência multiversão) é o que permite que leituras não bloqueiem escritas: cada transação enxerga uma versão consistente dos dados. No PostgreSQL, as versões antigas viram “tuplas mortas”, que o VACUUM limpa.

Como a FCC cobra

• View comum × materializada.
• Procedure × function.
• Uso de triggers para auditoria e as variáveis OLD e NEW.
• Comandos de administração do PostgreSQL (VACUUM, ANALYZE, EXPLAIN, pg_dump) e conceitos do Oracle (tablespace, PL/SQL, RMAN).

Pegadinhas

Explique com suas palavras

Explique a um gestor como um trigger pode garantir a auditoria das mudanças nos contratos, e qual a diferença entre ele e uma procedure.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

Um trigger é um gatilho preso à tabela de contratos: toda vez que alguém muda o valor de um contrato, o próprio banco grava, sozinho, uma linha de auditoria com o valor antigo, o novo, quem mudou e quando. Como quem dispara é o banco, não depende de a aplicação lembrar de registrar: vale para qualquer sistema ou pessoa que alterar a tabela.

A procedure é diferente: é uma rotina guardada no banco que só roda quando alguém a chama, como o reajuste anual de todos os contratos. A procedure executa quando pedida; o trigger reage a um evento.

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

Auditoria é o coração de um tribunal de contas. Num caso sobre rastrear alterações em dados sensíveis, proponha um trigger de auditoria (com usuário, data, valor antigo e novo) numa tabela protegida contra alteração, views para dar a cada perfil só o que ele precisa ver, e GRANT restrito às views em vez das tabelas.

Fontes da lição

• Edital nº 01/2026, Anexo II, Banco de Dados (fontes/edital-01-2026.txt).
• Documentação do PostgreSQL: CREATE TRIGGER, CREATE PROCEDURE e rotinas de manutenção (VACUUM)
• Documentação do Oracle Database: conceitos