Auditoria é a investigação dos procedimentos, processos e práticas relativas ao sistema de gerenciamento de banco de dados de um determinado órgão público. Os auditores se baseiam no histórico de mudanças ocorridas (log) nos dados armazenados em um determinado sistema. Para manter um registro de todas as atualizações realizadas no banco de dados e de usuários em particular que aplicaram cada atualização, é utilizado o log do sistema. O log do sistema inclui uma entrada para cada operação aplicada ao banco de dados. Sistemas de banco de dados baseados em PostgreSQL possuem a função trigger para a criação de logs. Essa função é muito utilizada para atualizar o log do sistema toda vez que uma determinada operação no banco de dados é realizada. Mais especificamente, quando o trigger está associado a tabelas de dados, ele somente pode ser executado
- A)antes ou depois das operações INSERT, UPDATE e DELETE.
Correta, porque em tabelas o PostgreSQL permite triggers BEFORE ou AFTER para INSERT, UPDATE e DELETE.
- B)antes das operações INSERT, UPDATE e DELETE.
Errada, pois ignora a possibilidade de trigger AFTER, que também existe para tabelas.
- C)antes ou depois das operações INSERT e DELETE.
Errada, porque exclui o UPDATE, que também pode acionar triggers em tabelas.
- D)depois das operações INSERT e DELETE.
Errada, pois limita indevidamente aos eventos AFTER e ainda exclui o UPDATE.
- E)antes ou depois da operação DELETE.
Errada, porque restringe demais tanto o momento de execução quanto os comandos cobertos.
Gabarito: A
No PostgreSQL, trigger é aquele mecanismo que dispara automaticamente quando acontece um evento no banco. Pense nele como um "alfinete de segurança": aconteceu a operação, ele entra em cena para registrar, validar ou até barrar a mudança. Em auditoria, ele é muito usado para montar log de alterações, identificando o que foi feito e por quem foi feito. Quando o trigger está associado a tabelas, ele pode ser definido para atuar antes ou depois das operações de INSERT, UPDATE e DELETE. Isso é exatamente o ponto cobrado pela questão: em tabelas, o PostgreSQL permite trigger de BEFORE e AFTER para esses três comandos de manipulação de dados. Na prática, isso dá flexibilidade para controlar a mudança antes que ela ocorra ou registrar o que acabou de acontecer. Em termos doutrinários, o PostgreSQL segue a lógica clássica de triggers em DML, aplicadas sobre eventos de modificação de dados. O banco não restringe esse uso apenas a uma operação nem apenas a um momento, porque auditoria pode precisar tanto prevenir quanto registrar alterações. Por isso, o gabarito A está correto: o trigger em tabelas pode ser executado antes ou depois de INSERT, UPDATE e DELETE. As demais alternativas cortam parte dos comandos ou limitam demais o momento de execução, e aí a resposta escapa do comportamento real do PostgreSQL.