Gatilho (banco de dados)

Origem: Wikipédia, a enciclopédia livre.
Disambig grey.svg Nota: Este artigo é sobre recurso de programação de banco de dados. Para o estúdio de animação japonês, veja Studio Trigger.

Definição:

Gatilho ou trigger é um recurso de programação executado sempre que o evento associado ocorrer. Trigger é um tipo especial de procedimento armazenado, que é executado sempre que há uma tentativa de modificar os dados de uma tabela que é protegida por ele.

É muito utilizada para ajudar a manter a consistência dos dados ou para propagar alterações em um determinado dado de uma tabela para outras. Um bom exemplo é um gatilho criado para controle de quem alterou a tabela, nesse caso, quando a alteração for efetuada, o gatilho é "disparado" e grava em uma tabela de histórico de alteração, o usuário e data/hora da alteração. Os gatilhos podem ser DML ou DDL. Os DML são executados quando um usuário tentar modificar dados através de um evento de linguagem de manipulação de dados (utilização de INSERT, UPDATE ou DELETE). Os DDLs são executados em resposta a diversos eventos de linguagem de definição de dados (como o Transact-SQL CREATE, ALTER ou DROP).

Em SQL, para se criar um trigger utiliza-se do CREATE TRIGGER, e para removê-lo deve-se usar DROP TRIGGER. Um gatilho típico é composto de três componentes, que seguem o Modelo: evento - condição - ação[1]. Exemplo: (MS-SQL Server)

CREATE TRIGGER nome_do_gatilho ON dono.Nome_da_tabela
FOR INSERT (ou SELECT ou UPDATE ou DELETE)
AS
Codigo para execucao

Outro exemplo:

CREATE TRIGGER <Nome>
         Momento_Exec (BEFORE/AFTER)
         Evento_disparador (INSERT/UPDATE/DELETE)
ON tabela_evento
[REFERENCING NEW AS novo_nome OLD AS nome_antigo] (Opcional, em caso de delete para copiar os dados para outra tabela)
[nivel_gatilho] (FOR EACH ROW (linha) / FOR EACH STATEMENT (comando) - determina como será executado o BLOCO_COMANDOS_SQL)
[condição_exec] (WHEN <condição>)
BLOCO_COMANDOS_SQL

O Modelo de ação de condição de evento (Event-Condition-Action)

Evento: é um sinal específico que realiza uma chamada de alguma regra, podendo ser:

Alguma operação que faça uma atualização no banco de dados.

Um evento sistemático ou evento externo.

Condição: atua na presença do Evento, é a realização de um teste lógico que, caso verdadeira, permite que a Ação seja realizada. A condição é opcional portanto, se não houver será executada sempre que ocorrer o evento. Caso esteja presente, somente será executada se a mesma for verdadeira.

Ação: consiste na ação a ser tomada uma vez que a Condição seja satisfeita. Geralmente é uma sequência de comandos SQL ou códigos de linguagens de programação proprietárias como PL/SQL, usada em bancos de dados. Oracle ou Transact-SQL usado em banco de dados Microsoft.


Características dos Gatilhos:

Os gatilhos não aceitam parâmetros ou argumentos, podem até ser armazenados os seus dados afetados durante a execução em tabelas temporárias.

Fácil ocorrência de erros de mutação de dados de tabelas por causa de imperfeições na implementação do gatilho.


Tipos: Os gatilhos são classificados em dois tipos, sendo eles de acordo com o número de execuções que irão realizar:

Row Triggers (ou gatilhos de linha): serão aquelas que executarão a cada vez que se chamar o gatilho que está associado a tabela em questão.

Statement triggers (ou gatilhos de sequência): são aqueles que independentemente do número de vezes que a condição é aceita, sua execução é única.


Funcionamento do Gatilho de Update:

No sentido de entender o funcionamento do gatilho de UPDATE podemos vê-lo como dois passos. Sendo ele o de DELETE, onde irá capturar os dados antes da modificação, movendo-os para a tabela de deleted. E o segundo passo, o INSERT que captura a imagem dos dados após já modificados. Importante salientar que quando executado os dados são movidos para a tabela deleted e as linhas atualizadas movidas para uma tabela de inserted, sendo estás tabelas temporárias.


Utilidades:

Um trigger ajuda na verificação de integridade de dados, assim como suas validações. Ela também auxilia no rastreamento e registro de logs de atividades nas tabelas e no arquivamento de registros excluídos.


Modos de disparo de um Trigger:

Em SQL, os Triggers podem ser disparados de dois modos diferentes:

1. Trigger After: Ocorre quando o código presente no trigger for executado depois das ações terem sido completadas na tabela especificada. Ou seja, depois que determinada ação na tabela é finalizada, o trigger é disparado e realiza uma ação adicional.

Ex.: Se o usuario manda inserir um registro novo na tabela, o trigger só será disparado após a realização da inserção deste registro.

Caracteristicas:
-Declaração DML: Executada, mas com a possibilidade de ser revertida (Roll back)
-Timing: Após a transação completa, mas antes do commit
-Nº de eventos por tabéla: Múltiplos
-Recursividade: É possivel, dependendo das configurações do Banco de Dados.

2. Instead Of: Ocorre quando o código presente no trigger é executado no lugar da operação que causou seu disparo. Ou seja, "em vez de" (Instead of) executar a operação em si, executa o trigger.

Ex.: Ao usuario mandar fazer uma ação, como uma inserção ou alguma atualização específica de dados em uma tabela, em vez de fazer esta atualização, será disparado um trigger que realiza uma ação diferente.

Caracteristicas:
-Declaração DML: Simulada, porém não executada
-Timing: Antes das constraints de chave primária e chave estrangeira serem analisadas
-Nº de eventos por tabela: Apenas um
-Recursividade: Não é recursivo


Utilizações para o Instead Of

É importante ressaltar que quando uma transação for iniciada, caso exista algum gatilho vinculado a tabela, ele apenas será executado após o término da transação,mas antes de seu Commit[2].

Por exemplo, um delete sendo executado, a Trigger só se ativará após a atualização da tabela, ou seja, quando o valor encontrado no delete for removido.

Portanto, caso os dados sejam necessários, os mesmos podem ser encontrados nas tabelas Deleted ou Inserted, dependendo da operação.

Em alguns casos, se a transação for feita em uma tabela que tenha atributos FK em outra,

onde não haja um delete cascate ou propriedades que garantam a exclusão de dados da referência,

é possível fazer a remoção dos dados das tabelas antes do delete, utilizando o Insted Of que ira pular a transação.

Mas a operação ainda pode ser forçada dentro da própria Trigger, seus dados se encontrarão nas tabelas Deleted ou Inserted, apesar da operação ter sido pulada pelo Insted of.

Então, para retomar é necessário fazer a mesma operação em que a Trigger fora iniciada, buscando seus dados nas tabelas auxiliares.

Este exemplo é aplicável, em especial, ao SQL Server,visto que não existe o Before no mesmo.

Sendo assim, nesse SGBD[3], é necessário utilizar o Insted Of e aplicar a transação após o término do processo, como no exemplo:

- SQL server triggrer -

CREATE TRIGGER deleteComReferencia

ON Professor INSTEAD OF DELETE

AS

DELETE Escola

WHERE Id_Empregado IN (SELECT Id_Empregado

                       FROM Escola

                       HAVING Id_Empregado IN (SELECT Id_Empregado

                                                FROM deleted))

DELETE Professor

WHERE Id_Empregado IN (SELECT Id_Empregado

                   FROM Professor

                   WHERE Id_Empregado IN (SELECT Id_Empregado

                                        FROM deleted))

- Ativando a triggrer -

DELETE FROM Professor WHERE Id_Empregado=1

Neste exemplo, queremos remover os dados de uma tabela, porém existe uma referência da mesma em outra,

essa referência precisa ser removida antes da remoção principal. Para isso uma das soluções é utilizar o Insted Of, pulando assim a transação e ao final chamando a transação novamente.

Obs: utilizar a tabela Deleted ou Inserted para repetir uma operação pulada, não iniciará novamente a Trigger.

Fluxos das transações:

O fuxo das transações costumam seguir um padrão de ordem de execução de comandos. Primeiro, deve-se fazer a verificação de Identity insert, ou seja, ao inserir um valor, o sistema irá verificar se a coluna é uma Identity. Caso seja, o usuario não poderá inserir dados, já que é o proprio sistema que o gera. Depois, verificamos se para a coluna há alguma restrição (constraint) de campos Nulos (NULL) e em seguida fazemos uma checagem em relação a compatibilidade de tipos de dados. Após todos os passos até agora citados, poderá ser realizada a execução de trigger "Instead of". Depois deverá ser verificada se há alguma restrição de Chave primária, seguido de verificação para a restrição "Check" e restrição de Chave Estrangeira. É após todas estas verificações que o comando DML deverá ser executado, ou seja, é nesse momento que o comando de inserção, atualização ou exclusão será efetivamente terminado. É importante destacar que neste ponto haverá uma atualização do log de transações. Após a finalização do comando, poderemos ter então a execução do trigger After, para por fim, ser realizado o Commit da transação.


Referências

  1. Programando em SQL - Profa. Késsia Marchi (http://kessia.blogs.unipar.br/files/2009/04/trigger.pdf)
  2. «Commit». Wikipédia, a enciclopédia livre. 29 de abril de 2019. Consultado em 21 de novembro de 2020 
  3. «Sistema de gerenciamento de banco de dados». Wikipédia, a enciclopédia livre. 28 de maio de 2020. Consultado em 21 de novembro de 2020 
https://docs.microsoft.com/pt-br/sql/relational-databases/triggers/ddl-triggers?view=sql-server-ver15

Ver também[editar | editar código-fonte]


Ícone de esboço Este artigo sobre banco de dados é um esboço. Você pode ajudar a Wikipédia expandindo-o.