Questão de Banco de Dados — PL/SQL e Outras Extensões SQL — FCC 2026
Banco de Dados›PL/SQL e Outras Extensões SQL
Código
fc142363
Banca
FCC
Órgão
MPE SE
Ano
2026
Cargo
Ana ( )
Atenção: A tabela Processos deve ser utilizada para resolver a questão seguinte. A tabela Processos armazena informações sobre processos judiciais e possui os campos id, classe (trabalhista, penal etc), status (ativo, inativo, encerrado etc) e valor (custas associadas). A equipe de TI precisa garantir rastreabilidade em operações críticas no banco de dados. Foi solicitado que qualquer alteração na coluna status da tabela Processos seja registrada em uma tabela de auditoria. Nesse contexto foi criado o código SQL abaixo. CREATE TABLE Auditoria_Processos ( id_auditoria INT IDENTITY PRIMARY KEY, id_processo INT, status_antigo VARCHAR(20), status_novo VARCHAR(20), data_alteracao DATETIME DEFAULT GETDATE() ); Em condições ideais e considerando as boas práticas em SQL/T-SQL para implementar a rastreabilidade, a melhor forma de completar a solução é criar
Auma view combinando Processos e Auditoria_Processos e usá-la em todas as consultas para simular a rastreabilidade.
Bum triggerINSTEAD OF UPDATE na tabela Processos, que insira em Auditoria_Processos os valores antigos e novos nos campos correspondentes, sem precisar executar a atualização na tabela Processos.
Cuma procedure que receba o id e o status_novo como parâmetros e os insira diretamente na tabela Auditoria_Processos.
Dum triggerAFTER UPDATE na tabela Processos, que capture INSERTED.status e DELETED.status e insira os valores nos campos correspondentes na tabela Auditoria_Processos.
Eum package que contenha procedures de atualização e, dentro delas, inserir os registros de auditoria manualmente.
Revelar gabarito e comentário▾
GabaritoD — um trigger AFTER UPDATE na tabela Processos, que capture INSERTED.status e DELETED.status e insira os valores nos campos correspondentes na tabela Auditoria_Processos.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Triggers no SQL Server: auditoria automática com AFTER UPDATE
Gabarito: letra D. Para registrar automaticamente qualquer alteração na coluna status da tabela Processos, a solução mais adequada é criar um trigger AFTER UPDATE que capture os valores antigos e novos por meio das tabelas virtuais DELETED e INSERTED, inserindo-os na tabela de auditoria. Essa é a abordagem que garante rastreabilidade completa sem depender de intervenção manual ou de rotinas externas.
Um trigger (ou gatilho) é um objeto de banco de dados que é executado automaticamente em resposta a eventos de DML (INSERT, UPDATE, DELETE) em uma tabela. No SQL Server, os triggers podem ser classificados em duas categorias principais: AFTER (ou FOR) e INSTEAD OF. Os triggers AFTER são executados após a operação que os disparou ser concluída com sucesso, enquanto os INSTEAD OF substituem a operação original. Para auditoria de alterações, o trigger AFTER é o mais indicado, pois a operação de UPDATE já ocorreu e podemos capturar os valores antes e depois da modificação.
No SQL Server, quando um trigger de UPDATE é disparado, duas tabelas virtuais são criadas: INSERTED e DELETED. A tabela INSERTED contém os novos valores das linhas afetadas, enquanto a tabela DELETED contém os valores antigos. Assim, dentro do trigger, podemos acessar DELETED.status para obter o status anterior e INSERTED.status para obter o novo status, e então inserir esses valores na tabela Auditoria_Processos. Essa é a técnica padrão e mais eficiente para implementar trilhas de auditoria em bancos de dados SQL Server.
A alternativa correta (D) descreve exatamente esse mecanismo: um trigger AFTER UPDATE que captura INSERTED.status e DELETED.status e insere os valores na tabela de auditoria. As demais alternativas apresentam abordagens que não garantem a rastreabilidade automática e completa, como veremos a seguir.
A principal distinção que separa as alternativas é o mecanismo de captura automática versus a intervenção manual. Enquanto o trigger AFTER UPDATE captura automaticamente os valores antigos e novos, as outras opções dependem de ações externas (views, procedures, packages) que podem ser esquecidas ou contornadas, comprometendo a integridade da auditoria. Guarde essa fronteira: auditoria confiável exige que o registro seja feito pelo próprio banco, de forma automática e atômica com a alteração.
Alternativa
Mecanismo
Automático?
Registra status_antigo?
Executa o UPDATE original?
Veredito
A
View
Não
Não
—
❌ Incorreta
B
Trigger INSTEAD OF UPDATE
Sim
Sim
Não (substitui)
❌ Incorreta
C
Procedure manual
Não
Não (depende de parâmetro)
—
❌ Incorreta
D
Trigger AFTER UPDATE
Sim
Sim (via DELETED)
Sim
✅ Gabarito
E
Package com procedures manuais
Não
Sim (manual)
—
❌ Incorreta
Trigger AFTER UPDATE: Tabelas virtuais (INSERTED (valores novos), DELETED (valores antigos)); Execução automática (Após o UPDATE, Independente de quem alterou); Uso em auditoria (Registra status_antigo, Registra status_novo); Trigger INSTEAD OF UPDATE (Substitui a operação original, Exige UPDATE manual no trigger, Não indicado para auditoria)
Alternativa A — ❌ Incorreta
Uma view é uma consulta virtual que não armazena dados e não tem capacidade de registrar alterações. Criar uma view combinando Processos e Auditoria_Processos apenas permitiria consultar os dados, mas não capturaria automaticamente as mudanças de status. A rastreabilidade exige que cada alteração seja registrada no momento em que ocorre, o que uma view não faz. Além disso, a view não teria como acessar os valores antigos e novos, pois não há tabelas virtuais INSERTED/DELETED em uma view.
Alternativa B — ❌ Incorreta
Um trigger INSTEAD OF UPDATE substitui a operação de UPDATE original. Isso significa que, se você criar um trigger INSTEAD OF UPDATE na tabela Processos, o UPDATE não será executado a menos que você o faça explicitamente dentro do trigger. A alternativa afirma que o trigger insere na auditoria "sem precisar executar a atualização na tabela Processos", o que é um erro grave: se a atualização não for executada, o status não será alterado, e a auditoria registraria uma mudança que não ocorreu. Para usar INSTEAD OF corretamente, seria necessário executar o UPDATE dentro do trigger, o que tornaria a solução mais complexa e propensa a erros. O trigger AFTER UPDATE é a escolha natural para auditoria.
Alternativa C — ❌ Incorreta
Uma procedure que recebe id e status_novo e insere diretamente na tabela Auditoria_Processos depende de ser chamada manualmente por cada aplicação ou usuário que fizer a alteração. Isso não garante rastreabilidade, pois qualquer UPDATE direto na tabela Processos (fora da procedure) não seria registrado. Além disso, a procedure não teria acesso ao status_antigo, a menos que fosse passado como parâmetro, o que é inviável na prática. A auditoria deve ser automática e independente da forma como a alteração é feita.
Alternativa D — ✅ Correta ⟵ GABARITO
O trigger AFTER UPDATE é a solução ideal. Ele é executado automaticamente após cada UPDATE na tabela Processos, e as tabelas virtuais INSERTED e DELETED fornecem, respectivamente, os valores novos e antigos da linha alterada. O trigger pode então inserir um registro em Auditoria_Processos com id_processo, status_antigo (de DELETED.status), status_novo (de INSERTED.status) e a data da alteração (gerada automaticamente pelo DEFAULT GETDATE()). Isso garante que toda alteração de status seja registrada, independentemente de quem a executou, cumprindo o requisito de rastreabilidade.
Alternativa E — ❌ Incorreta
Um package (no Oracle) ou um conjunto de procedures que atualizam a tabela e inserem manualmente os registros de auditoria sofre do mesmo problema da alternativa C: depende de que todas as atualizações passem por essas procedures. Se qualquer UPDATE for feito diretamente na tabela Processos, a auditoria será ignorada. Além disso, a manutenção manual é mais sujeita a erros e não é uma prática recomendada quando se deseja rastreabilidade completa.
NÃO CAIA NESSA!
A banca tenta confundir o candidato com o trigger INSTEAD OF UPDATE (alternativa B), que parece plausível, mas na verdade substitui a operação original. Muitos candidatos lembram que triggers podem ser INSTEAD OF e acham que servem para auditoria, mas esquecem que, nesse caso, o UPDATE original não é executado automaticamente. O trigger AFTER UPDATE é o que captura os valores antigos e novos sem interferir na operação.
PEGA ESSA DICA!
Para questões de auditoria com triggers, lembre-se: AFTER UPDATE é o padrão para registrar alterações, pois as tabelas INSERTED e DELETED estão disponíveis. INSTEAD OF é usado para substituir a operação, como em views não atualizáveis. Se a alternativa mencionar "sem executar a atualização", desconfie: a auditoria deve registrar a mudança que realmente ocorreu.