DevMedia
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login

Introdução à TRIGGERS

Veja neste artiogo uma introdução sobre Triggers.

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você poderia comentar o que não lhe agradou?

Confirmo meu voto negativo

INTRODUÇÃO À TRIGGERS

 

Há tempos que venho estudando sobre esse tipo de implementação voltada primeiramente ao SQL Server e agora também, podendo ser utilizada no MySQL em sua versão de número 5 ou posterior.

Embora muitos desenvolvedores e entusiastas digam que eles são boas práticas dentro de bancos de dados, resolvi estudar a fundo, para deixar aqui a minha posição sobre o assunto.

Existem várias maneiras de tratarmos ou nos dirigirmos a esse tipo de implementação.  Podemos chamar de TRIGGER, gatilhos ou disparadores. Neste artigo, usarei o termo mais conhecido entre administradores de Banco de Dados, TRIGGER.

Todos os scripts que aqui serão exibidos foram testados em um ambiente Windows XP Professional, rodando SQL Server 2000 Service Pack 4.

 

CONCEITOS:

 

·         O que são TRIGGERS;

·         Usos e aplicabilidade dos TRIGGERS;

·         Considerações e boas práticas em relação aos TRIGGERS;

·         Quando e como usá-los;

 

            Primeiramente, vamos abordar o conceito central de TRIGGERS:

 

 

Um 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.

                                                                      

           

- Associados a uma tabela

           

Os TRIGGERS são definidos em uma tabela específica, que é denominada tabela de TRIGGERS;

 

- Chamados Automaticamente

 

Quando há uma tentativa de inserir, atualizar ou excluir os dados em uma tabela, e um TRIGGER tiver sido definido na tabela para essa ação específica, ele será executado automaticamente, não podendo nunca ser ignorado.

 

- Não podem ser chamados diretamente

 

Ao contrário dos procedimentos armazenados do sistema, os disparadores não podem ser chamados diretamente e não passam nem aceitam parâmetros.

 

- É parte de uma transação

 

O TRIGGER e a instrução que o aciona são tratados como uma única transação, que poderá ser revertida em qualquer ponto do procedimento, caso você queria usar “ROLLBACK”, conceitos que veremos mais a frente.

 

Orientações básicas quando estiver usando TRIGGER.

 

             - As definições de TRIGGERS podem conter uma instrução “ROLLBACK TRANSACTION”, mesmo que não exista uma instrução explícita de “BEGIN TRANSACTION”;

 

             - Se uma instrução “ROLLBACK TRANSACTION” for encontrada, então toda a transação (o TRIGGER e a instrução que o disparou) será revertida ou desfeita. Se uma instrução no script do TRIGGER seguir uma instrução “ROLLBACK TRANSACTION”, a instrução será executada, então, isso nos obriga a ter uma condição IF contendo uma cláusula RETURN para impedir o processamento de outras instruções.

 

             - Não é uma boa prática utilizar “ROLLBACK TRANSACTION” dentro de seus TRIGGERS, pois isso gerará um retrabalho, afetando muito no desempenho de seu banco de dados, pois toda a consistência deverá ser feita quando uma transação falhar, lembrando que tanto a instrução quanto o TRIGGER formam uma única transação. O mais indicado é validar as informações fora das transações com TRIGGER para então efetuar, evitando que a transação seja desfeita.

 

             - Para que um TRIGGER seja disparado, o usuário o qual entrou com as instruções, deverá ter permissão de acessar tanto a entidade e consequentemente ao TRIGGER.

 

           

Usos e aplicabilidade dos TRIGGERS

 

  • Impor uma integridade de dados mais complexa do que uma restrição CHECK;
  • Definir mensagens de erro personalizadas;
  • Manter dados desnormalizados;
  • Comparar a consistência dos dados – posterior e anterior – de uma instrução UPDATE;

 

Os TRIGGERS são usados com enorme eficiência para impor e manter integridade referencial de baixo nível, e não para retornar resultados de consultas. A principal vantagem é que eles podem conter uma lógica de processamento complexa.

Você pode usar TRIGGERS para atualizações e exclusões em cascata através de tabelas relacionadas em um banco de dados, impor integridades mais complexas do que uma restrição CHECK, definir mensagens de erro personalizadas, manter dados desnormalizados e fazer comparações dos momentos anteriores e posteriores a uma transação.

Quando queremos efetuar transações em cascata, por exemplo, um TRIGGER de exclusão na tabela PRODUTO do banco de dados Northwind pode excluir os registros correspondentes em outras tabelas que possuem registros com os mesmos valores de PRODUCTID excluídos para que não haja quebra na integridade, como a dito popular “pai pode não ter filhos, mas filhos sem um pai é raro”.

 

Você pode utilizar os TRIGGERS para impor integridade referencial da seguinte maneira:

 

·         Executando uma ação ou atualizações e exclusões em cascata:

 

      A integridade referencial pode ser definida através do uso das restrições FOREIGN KEY e REFERENCE, com a instrução CREATE TABLE. Os TRIGGERS fazem bem o trabalho de checagem de violações e garantem que haja coerência de acordo com a sua regra de negócios. Se você exclui um cliente, de certo, você terá que excluir também todo o seu histórico de movimentações. Não seria boa coisa se somente uma parte desta transação acontecesse.

 

·         Criando disparadores de vários registros:

 

Quando mais de um registro é atualizado, inserido ou excluído, você deve implementar um TRIGGER para manipular vários registros.

 

CRIANDO TRIGGERS

 

As TRIGGERS são criadas utilizando a instrução CREATE TRIGGER que especifica a tabela onde ela atuará, para que tipo de ação ele irá disparar suas ações seguido pela instrução de conferência para disparo da ação.

E meio a esses comandos, temos algumas restrições para o bom funcionamento. O SQL Server não permite que as instruções a seguir, sejam utilizadas na definição de uma TRIGGER:

 

·         ALTER DATABASE;

·         CREATE DATABASE;

·         DISKINIT;

·         DISKRESIZE;

·         DROP DATABASE;

·         LOAD DATABASE;

·         LOAD LOG;

·         RECONFIGURE;

·         REATORE DATABASE;

·         RESTORELOG.

 

Caso você queira determinar referencias que um TRIGGER faz a objetos, execute o procedimento armazenado do sistema sp_depends, criando o seguinte comando:

 

 25-04pic1.JPG

Imagem nº 1 – Mostra que o TRIGGER criado, não referencia e nem é referenciado por nenhum outro objeto.

 

Para determinar os TRIGGERS existentes em uma específica e suas ações, execute o procedimento armazenado do sistema sp_helptrigger, criando o seguinte comando:

 

25-04pic2.JPG 

Imagem nº 2 – Mostra que temos um TRIGGER somente para INSERT.

 

           

COMO FUNCIONAM OS TRIGGERS

 

·     Como funciona um TRIGGER INSERT;

·     Como funciona um TRIGGER DELETE;

·     Como funciona um TRIGGER UPDATE;

 

Quando incluímos, excluímos ao alteramos algum registro em um banco de dados, são criadas tabelas temporárias que passam a conter os registros excluídos, inseridos e também o antes e depois de uma atualização.

Quando você exclui um determinado registro de uma tabela, na verdade você estará apagando a referência desse registro, que ficará, após o DELETE, numa tabela temporária de nome DELETED. Um TRIGGER implementado com uma instrução SELECT poderá lhe trazer todos ou um número de registro que foram excluídos.

Assim como acontece com DELETE, também ocorrerá com inserções em tabelas, podendo obter os dados ou o número de linhas afetadas buscando na tabela INSERTED.

Já no UPDATE ou atualização de registros em uma tabela, temos uma variação e uma concatenação para verificar o antes e o depois.

De fato, quando executamos uma instrução UPDATE, a “engine” de qualquer banco de dados tem um trabalho semelhante, primeiro exclui os dados tupla e posteriormente faz a inserção do novo registro que ocupará aquela posição na tabela, ou seja, um DELETE seguido por um INSERT. Quando então, há uma atualização, podemos buscar o antes e o depois, pois o antes estará na tabela DELETED e o depois estará na tabela INSERTED.

Nada nos impede de retornar dados das tabelas temporárias (INSERTED, DELETED) de volta às tabelas de nosso banco de dados, mas atente-se, os dados manipulados são temporários assim como as tabelas e só estarão disponíveis nesta conexão. Após fechar, as tabelas e os dados não serão mais acessíveis.

 

TRIGGER INSERT

 

De acordo com a sua vontade, um TRIGGER por lhe enviar mensagens de erro ou sucesso, de acordo com as transações. Estas mensagens podem ser definidas em meio a um TRIGGER utilizando condicionais IF e indicando em PRINT sua mensagem personalizada. Por exemplo, vamos criar uma tabela chamada tbl_usuario, com a qual simularemos um cadastro de usuários que você também poderá criar para fazer os seus testes. A cada inserção de novo usuário, podemos exibir uma mensagem personalizada de sucesso na inserção.

 

Criamos a tabela:

 

25-04pic3.JPG 

Imagem nº 3 – Criando então a tabela.     

 

 

Após criamos a tabela iremos criar nossa TRIGGER personalizada que nos mostrará uma mensagem personalizada a partir de uma inserção.

 

Criamos o TRIGGER INSERT:

 

25-04pic4.JPG 

Imagem nº 4 – Criando então o trigger.

 

 

Assim que começarmos a pular nossa tabela tbl_usuario, a cada registro inserido, o SGBD nos devolverá uma mensagem, caso a inserção seja realizada com sucesso, com base nos registros que são adicionados também a nossa tabela lógica/temporária INSERTED.

 

Mensagem disparada pelo TRIGGER:

 

25-04pic5.JPG 

Imagem nº 5 – Recebendo a mensagem disparada pelo TRIGGER.

           

Existem várias outras abordagens para o uso de TRIGGERS com INSERTS, por exemplo, quando se faz um controle de entrada e saídas de produtos, podemos ter um TRIGGER executando a baixa dos produtos no estoque (entrada) diante daqueles que foram solicitados num pedido (saída). O TRIGGER pode automatizar essa rotina.

 

TRIGGER DELETE

 

Podemos usar um TRIGGER para monitorar certas exclusões de registros de acordo com a sua regra de negócios e também para proteger a integridade dos dados em um determinado banco de dados.

Alguns fatos devem ser considerados ap usar TRIGGERS DELETE:

 

·               Quando um registro é acrescentado a tabela temporária DELETED, ele deixa de existir na tabela do banco de dados. Portanto, a tabela DELETED, não apresentará registros em comum com as tabelas do banco de dados;

·               É alocado espaço na memória para criar a tabela DELETED, que está sempre em cache;

·               Um TRIGGER para uma ação DELETE não é executado para a instrução TRUNCATE TABLE porque a mesma não é registrada no log de transações.

 

Podemos criar um TRIGGER não permita a exclusão de usuários de nossa tabela tbl_usuario, da seguinte forma:

 

Criando o TRIGGER DELETE:

 

25-04pic6.JPG 

Imagem nº 6 – Criando o TRIGGER DELETE.

 

O TRIGGER foi criado com sucesso. Na seqüência tentaremos executar uma instrução para excluir o usuário que temos já em nossa tabela.

 

Mensagem disparada pelo TRIGGER:

 

 25-04pic7.JPG

 Imagem nº 7 – Veja que é apresentada também a mensagem de erro que definimos no TRIGGER e depois a mensagem que personalizamos.

 

Veja que realmente, TRIGGERS pode nos trazer segurança e também integridade dos dados mesmo que desnormalizados. No caso apresentado, a mensagem de erro em vermelho foi chamada pelo nosso TRIGGER e após ele dispara também, a mensagem que personalizamos.

Assim, existem várias outras maneiras de expandirmos o exemplo.

 

TRIGGER UPDATE:

 

Partindo então do princípio que uma instrução UPDATE apresenta as duas etapas, as quais já citamos, com ela podemos verificar o antes e o depois, já que os dados estarão disponíveis nas tabelas temporárias DELETED – momento anterior – INSERTED – momento atual, logo após o UPDATE.

           

Criando o TRIGGER UPDATE:

 

 25-04pic8.JPG

 Imagem nº 8 – Criamos então a TRIGGER para UPDATE.

 

A qualquer momento daqui por diante, poderemos então contemplar, sempre que executada uma instrução para atualização de registros, o antes e o depois, o que acabamos de definir no TRIGGER para UPDATE.

Vamos então, executar a instrução para atualizar o único registro que temos então em nossa tabela. Mudemos o nome WAGNER BIANCHI para WAGNER BIANCHI Jr. Veremos então como era o nome antes e como é o nome agora!

 

Conteúdo disparado pelo TRIGGER:

 

25-04pic9.JPG 

Imagem nº 9 – Visualizando o antes e o depois com a definição de TRIGGER FOR UPDATE.

 

 

ALTERANDO O CONTEÚDO DE UM TRIGGER

 

O comando ALETR dá suporte para a alteração de muitos objetos criados dentro de um banco de dados. Podemos chamar alterar o conteúdo de um TRIGGER facilmente, trocando a palavra CREATE por ALTER e em seguida, executando o comando.

 

OBS.: Para definição de TRIGGERS, podemos também usar o comando WITH ENCRYPTION, mas, caso você não se lembre do que foi escrito no TRIGGER, não será possível altera-lo.

 

Vamos alterar então o TRIGGER para UPADTE, para que ele, ao invés de mostrar passado e presente, vamos fazer com ele nos mostre uma.

 

ALTERANDO UM TRIGGER:

 

25-04pic10.JPG 

Imagem nº 10 – ALTER TRIGGER para UPDATE.

 

 

Mensagem disparada pelo TRIGGER após um UPDATE:

 

25-04pic11.JPG 

Imagem nº 11 – Exibindo a mensagem de nossa TRIGGER alterada.

 

APAGANDO UM TRIGGER:     

 

Caso você queira apagar um TRIGGER do banco de dados, utilize DROP TRIGGER mais o nome do TRIGGER que deseja apagar.

 

 25-04pic12.JPG

 Imagem nº 12 – Apagando o TRIGGER.

 

 

 

BOAS PRÁTICAS

 

·         Utilize TRIGGER somente quando necessário;

·         Quando for utilizar, que ele seja o mais simples possível;

·         TRIGGERS não tem um bom suporte a muitas transações;

·         Dependendo de como forem definidas, podem originar problemas com performances;

·         Minimize o quanto puder instruções ROLLBACK em TRIGGERS;

 

Muito obrigado a você leitor, e em nosso próximo encontro falaremos sobre recursos avançados em TRIGGERS para fecharmos mais esta série. E meio a isto, falaremos também sobre índices, que são alvos de grandes problemáticas voltadas para otimização de performance.

 

Um abraço a todos e até a próxima!

 



Wagner Bianchi é Tecnólogo em Gerenciamento de Bancos de Dados pela Faculdade Infórium de Tecnologia, Pós-Graduando em Administração Estratégica de Empresas (Executivo Jr.) pela Fundação Getúlio Vargas no Minas Business Institute, [...]

O que você achou deste post?
Conhece a assinatura MVP?
Publicidade
Serviços

Mais posts