MODELAGEM E APLICAÇÃO DE REGRAS DE NEGÓCIOS
PARA BANCO DE DADOS RELACIONAL
Márcia Terezinha Tonieto - FLF
Hélio Augusto de Sabóia Moura - FLF
Resumo:
Este trabalho apresenta técnicas aplicadas ao SGBD Relacional para se garantir a
integridade do sistema. A integridade do sistema de Banco de Dados depende muito do projeto
lógico e físico, porém boa parte da segurança fica a cargo da programação e de regras
estabelecidas durante a fase de desenvolvimento, o estabelecimento de regras explícitas no
Banco de Dados utilizando estudos de um Sistema Gerenciador de Banco de Dados Relacional
muito utilizado, principalmente em grandes organizações com alta demanda de informações, o
Oracle 9i ®, ferramenta de programação PL/SQL em um Sistema de Gestão Hospitalar.
Abstract:
This work presents technology applied to the DBMs to support the system rightness.
The integrity of a Database System depends a lot on a logical an physical project, although a
security cam be attributed to the programation an rules determined during the development
stage.
In that context, we analise the applications of a business Roles on a Relational
Database Management System very used, mainly in great organizations with demand very
discharge of information - Oracle 9i ®, besides that tool, a tool of development procedures
PLSQL Procedure Builder , was used in a Hospital Management System.
Palavras Chaves: Regras de negócio, ‘triggers’, metamodelos, segurança, integridade e Banco
de Dados.
Introdução
Nos tempos de hoje, as empresas ganham vantagens competitivas, tomando decisões
eficientes baseadas em informações. Com isso, o grande volume de dados armazenados e a
demanda por acesso a estes têm contribuído para o desenvolvimento de novas terminologias,
conceitos e tecnologias mais eficazes no armazenamento e no resgate dessas informações.
Refletindo sobre esse novo paradigma, surgem as perguntas: ao longo da vida útil do
sistema os usuários são capazes de garantir regras impostas na fase de desenvolvimento do
projeto do sistema? A documentação e o entendimento das mesmas é suficiente para não alterar
determinadas regras que possam ser críticas para a integridade dos dados?
O presente projeto vem divulgar o uso de regras em um Sistema Gerenciador de Banco
de Dados Relacional, com o objetivo de assegurar, através do Banco de dados, que as
especificações de negócios, segurança e integridade de informações, definidas no início do
projeto do sistema ou determinadas ao longo de sua vida útil, devam ser mantidas,
Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 2003
71
independentes de implementações ou interferências de usuários, como forma de garantir a
integridade e a propagação dos objetivos do sistema.
Objetivo Geral
Definição de componentes, Metamodelos e Ferramentas de Modelagem de Regras de
Negócios e a verificação dos resultadas da aplicação prática de regras em um banco de dados de
grande porte.
Objetivos Específicos
•Definir regras de negócios, componentes e classificação das mesmas.
•Apresentar os Metamodelos e Ferramentas de Modelagem de Regras de Negócios para
banco de dados relacionais.
•Observar a aplicabilidade prática destes Metamodelos.
•Relatar a experiência da aplicabilidade e resultados das regras em um banco de dados de
grande porte (Oracle 9i ®, Sistema de Gestão Hospitalar).
Justificativa
A vantagem da aplicação de regras de negócios no Banco de Dados não se restringe ao
fato da integridade dos dados. Pelo contrário, há o ganho de performance sobre o trabalho do
programador humano, porque os ‘triggers’ serão disparados a partir de eventos que são
habilitados a avaliar uma gama maior de alternativas do que o programador seria capaz de
fazer. Isso será feito automaticamente em tempo de execução do sistema gerenciador de banco
de dados e o custo será relativamente baixo.
Com o uso de ‘triggers’, eliminar-se-á o esforço manual e repetitivo de identificar e
corrigir comandos e regras mal implementados, pobres em desempenho. O trabalho dos
desenvolvedores de aplicações será facilitado ganhando em produtividade, pois não perderão
tempo com correções e buscas de regras já definidas e controladas pelo banco de dados.
Os clientes ficarão muito satisfeitos, pois suas aplicações terão informações precisas
independentes da ferramenta utilizada para consegui-las.
Regras de Negócio
Definição
Os sistemas de informação abrangem, com freqüência, um grande volume de
conhecimento organizacional formalizado. Tal conhecimento é especificado como regras de
negócio [7], já antes definidas por Bell [10] como sendo “declarações que apresentam a maneira
de como o negócio está sendo feito, além das diretrizes e restrições com respeito a estados e
processos em uma organização”.
Surge com isso a necessidade de se modelar regras de negócio, enfatizando a sua
importância em um esquema conceitual, que representa todas as regras que governam o
universo de discussão [12] devendo estar definidas dentro de um esquema conceitual. A partir
desta necessidade, tais regras de negócio têm sido amplamente utilizadas pelas organizações
como forma de melhorar a qualidade de seus sistemas.
72
Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 2003
Atualmente, os SGBDs têm a capacidade de executar ações através do uso de regras
ativas baseadas no paradigma Evento-Condição-Ação (ECA)[12]. O componente "Evento"
indica o momento do disparo da regra, a "Condição" indica um predicado a ser avaliado e a
"Ação" o que tem de ser feito, caso a condição seja válida. Estes mecanismos ativos,
denominados gatilhos (triggers) em bancos de dados, proporcionam uma funcionalidade aos
SGBDs, cuja principal aplicação tem sido a manutenção de integridade e restrições de acesso
aos bancos de dados. Desde que devidamente especificadas no esquema conceitual, regras de
negócio podem ser implementadas com o paradigma ECA, ampliando a sua aplicação a
problemas do mundo real.
Componentes das Regras Ativas
Para a especificação de regras ativas e de modo a apresentar a importância prática do
paradigma ECA, os componentes evento, Condição e Ação merecem um interesse especial por
sua riqueza semântica e sua complexidade detalhadas a seguir:
Componente Evento: O Evento é o componente disparador da regra. Álgebras de
eventos, como, por exemplo, as usadas nos sistemas Snoop (linguagem de especificação para
SGBDs ativos) e SAMOS (Swiss Active Mechanism Based Object-Oriented Database System)
foram propostas para formalizar o conceito de evento.
A álgebra de evento Snoop é uma linguagem de especificação para SGBDs ativos
desenvolvida na Universidade da Flórida, EUA [5]. Um evento em Snoop é definido como uma
ocorrência atômica de uma operação no banco de dados, uma ação externa explícita ou um fato
temporal.
Figura 1 - Classificação de Eventos Snoop
Eventos podem ser compostos através de operadores lógicos como conjunção, disjunção
ou seqüência, resultando em ocorrências atômicas. A álgebra de eventos SAMOS foi
desenvolvida na Universidade de Zurich, Suíça, utilizando como base o SGBD Orientado a
Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 2003
73
Objeto (SGBDOO) ObjectStore. Semelhantemente ao Snoop, os eventos propostos por SAMOS
são simples ou compostos, com pequenas diferenças quanto à classificação dos eventos simples
e quanto aos operadores de eventos compostos.
•Componente Condição: Condições das regras podem ser classificadas de acordo com os
tipos de restrições de integridade.
À semelhança do evento, o componente Condição pode ser simples e composto [9].
Condições simples são predicados atômicos aplicados sobre o estado corrente do banco de
dados, podendo incluir operadores booleanos unários tal como NOT.
Condições compostas resultam da aplicação dos operadores booleanos binários AND ou OR em
condições simples ou compostas.
•Componente Ação: Para o componente ação das regras ativas, foram propostas várias
classificações, dependendo da natureza das operações que executam (operações de
banco de dados ou das aplicações). De forma semelhante aos componentes Evento e
Condição, as ações também podem ser classificadas em ações simples e compostas.
Ação simples consiste em exatamente uma operação que não seja refinada posteriormente.
Ação composta é uma sucessão de algumas operações a serem executadas.
Classificação das Regras de Negócio
De forma genérica, regras de negócio, sob forma de regras ativas, podem ser
classificadas em dois tipos [11]:
•Regras de Integridade: representam a semântica das restrições de integridade, que são
estendidas tornando explícito o disparo de eventos e a reação sobre uma violação de
restrição. Exemplo:
ON (estoque de produto atualizado)
IF (novo estoque < 0)
THEN emitir mensagem de erro
“O estoque não pode ser menor que zero”
•Regras de Automatização: descrevem a lógica de execução de uma tarefa; assim, a
violação da condição não tem a semântica de um erro. Exemplo:
ON (estoque de produto atualizado)
IF (novo estoque < limite para pedido de reposição)
THEN fazer um pedido do produto.
Metamodelos e Ferramentas de Modelagem de Regras de Negócio
Definição
Os modelos são um dispositivo de abstração e devem ser suficientemente poderosos
para fornecer alguma compreensão dos objetos do nosso mundo e como eles se relacionam. Os
modelos não são somente utilizados para facilitar a compreensão humana e aumentar o número
de detalhes, mas, quando estes são automatizados, definem a nossa realidade.
Os conceitos de metamodelos não são novos. Este modelo conceitual cresceu nos
últimos anos, principalmente, pelo crescimento da Internet, Intranet e, a utilização e o
74
Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 2003
surgimento de novas ferramentas CASE ( Computer-Aided Software Engineering), –
Ferramenta ou conjunto de ferramentas que automatizam tarefas que compõem o processo de
desenvolvimento de software
O motivo principal deste crescimento foi a necessidade de integração dos dados na
etapa de desenvolvimento de software. E, com destaque para as ferramentas CASE. Estas
necessitam que os metamodelos sejam dinâmicos, ou seja, que o usuário possa configurar o
metamodelo de acordo com as suas necessidades.
A abordagem convencional para a modelagem é descrita por meio de níveis de
detalhamento conforme a figura 2. Um metamodelo é um modelo que define outros modelos, ou
seja, modelo de informação para informações que podem ser expressas durante a modelagem.
No nível modelo temos a coleção de artifícios (diagramas, tabelas, descrições etc.) montados
durante a modelagem de um sistema. Cada nível da figura 3 determina a maneira como o nível
inferior será expresso. A figura 2 descreve cada nível de modelagem como um grupo
distintamente separado porque é assim que os níveis tipicamente são desenvolvidos e aplicados.
Na prática, com freqüência, a modelagem é executada com a abordagem "de cima para baixo".
Metamodelo
Modelo
Dados e Processos
Figura 2 - Níveis de modelagem convencional
Os metamodelos vão conter o nível mais amplo das regras de negócios que vão definir a
modelagem de um sistema, é através de metamodelos que as organizações definem suas regras
de negócios, que de algum modo definem ou restringem políticas e práticas de ações.
A seguir serão descritos metamodelos reportados na literatura bem como ferramentas de
modelagem conceitual com especificação de regras de negócio: o BROCOM (Business Rule
Oriented Conceptual Modeling), desenvolvido na Universidade de Bern, Suíça [ 9 ]; o RIM Rechnergestütztes InformationsManagement (gerência de informação baseado em computador),
desenvolvido pelo Instituto de Sistemas de Informação, da Universidade de St. Gall, Alemanha;
e o (ER)2, proposto em e desenvolvido no Instituto Militar de Engenharia, Rio de Janeiro,
Brasil [5, 6].
A tabela abaixo apresenta uma análise comparativa desses metamodelos, a partir dos
seguintes critérios: os componentes do metamodelo como objetos do universo de discussão e os
fatos organizacionais no metamodelo que abrange tipos de metaclasses que são relevantes e
estão relacionadas com as regras de negócio.
Os metamodelos apresentados contemplam apenas modelos tipicamente relacionais.
Nestes modelos existe efetivamente uma carência de componentes que permitam projetar regras
de negócio incluindo a parte dinâmica com o controle interno do objeto, e em particular para
SGBDR.
Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 2003
75
Comparação dos metamodelos
Metamodelo
BROM
RIM
(ER)2
Modelo de
Componentes ativos
Componente
dados
Evento
Condição
Ação
Processo
Simples e Compostos
Condição
Ação
Especificado por
Entidade
Regra de Negócio
Relacionamento
Entidade
Eventos de Negócios Restrições de Função de Especificado por
Relacionamento Associados a Funções integridade
Negócios Função de Negócio
de Negócios
implícitas
Evento de Banco de Condição e Ação são partes
Ausente
Entidade
Dados
do componente Regra
Relacionamento
Figura 3 - Comparação do metamodelos BROM RIM (ER)2
Ferramentas de Modelagem de Regras de Negócio.
Abaixo estão ilustradas as ferramentas de modelagem associada aos metamodelos
descritos.
Modelo (ER)2 - (Entidade-Relacionamento-Evento-Regra) incorpora ao Modelo
Entidade-Relacionamento a especificação de regras e eventos, como objetos de primeira classe,
para a modelagem de banco de dados ativos. As regras e os eventos passam a fazer parte do
modelo, com a notação gráfica e identificação própria. Em um diagrama (ER)2, um evento é
representado por um círculo e uma regra por um paralelogramo. As conexões entre eventos e
regras são intuitivas.
(ER)2 - Entidade ou
Relacionamento
“Afetado por”
Evento
“Dispara”
Regra
“Causa”
Evento
Evento
“Dispara”
Entidade ou
Relacionamento
Regra
Figura 4 - Esquema do metamodelo (ER)2
76
Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 2003
Modelo Evento-Condição-Ação-se-Ação-senão (ECA2): Redes de Petri são modelos
formais para especificar o fluxo de controle em um sistema. A rede ECA2, resultante da
aplicação desses símbolos, é também uma Rede de Petri de alto nível que pretende representar
exatamente o comportamento de um sistema e pode ser empregado como base para a simulação
dos processos.
“Triggering”
Evento (s)
Condição
Se
Ação
Senão
Ação
Origina
Evento(s)
Figura 5 - Esquema do metamodelo (ECA2)
Modelo de Processamento Conceitual - CPM: A metodologia Merise: An Information System
Design and Development Methodology, in: Information & Management emprega o Modelo de
Processamento Conceitual (CPM – Conceptual Processing Model) para a especificação de
processos. Este modelo abrange eventos de ativação, operações (sincronizadas), e eventos
resultantes. Uma operação consiste em uma ou mais tarefas que estão baseadas no
gerenciamento de regras e são executadas seqüencialmente. Em CPM, um evento é visto como
um portador de propriedades, que correspondem aos atributos no modelo de dados do Merise.
Evento
Evento
Operação
...
Operação m
Resultado 1
Evento
Resultado n
Evento
Evento
Figura 6 - Esquema do metamodelo CPM
O Paradigma Evento-Condição-Ação-se-Ação-senão
Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 2003
77
O Modelo Evento-Condição-Ação-se-Ação-senão (ECA2) é tido como paradigma de
modelo de criação de regras de negócios normalmente utilizados por SGBDS. Os SGBS que
utilizam este modelo de regras de negócios são conhecidos como ativos ( reativos ) , pois
possuem a capacidade de detectar a ocorrência de eventos, e executar funções independentes de
solicitação explícita. Onde :
Evento: situação específica que ocorre na base de dados.
Condição: regra de negócio forçada.
Ação: procedimento que implementa uma lógica de processamento.
Normalmente nos SGBDS comerciais este modelo de formalização de regras de
negócios é representado na forma de triggers, que é um tipo de stored procedure (procedimento
armazenado no banco de dados), que é disparado em uma base controlada a evento.
Triggers de banco de dados
Definição
Triggers são blocos PL/SQL nomeados com seções declarativas, executável e de
tratamento de exceções. Os triggers devem ser armazenados na base de dados como objetos
independentes e não podem ser locais a um bloco ou pacote. Ao contrário de procedures
(subprogramas que executam uma ou mais transações sobre dados, e podem ser armazenados
locais, em bibliotecas-conjuntos de subprogramas ou no banco de dados) e funções
(subprogramas retornam uma única informação, e podem ser armazenados locais, em
bibliotecas-conjuntos de subprogramas ou no banco de dados), que são executadas
explicitamente a partir de um outro bloco via uma chamada de procedure que também passa um
argumento, os triggers são executados implicitamente sempre que o acontecimento/ evento
desencadeador de ‘trigerring’ suceder e não aceita argumentos. O ato de executar um trigger é
conhecido como disparar o trigger. O evento desencadeador pode ser uma operação DML
(INSERT, UPDATE, ou DELETE) em uma tabela de base de dados ou certos tipos de visões.
O banco de Dados Oracle 9i estendeu essa funcionalidade permitindo que os triggers sejam
acionados por um evento de sistema como inicialização ou desativação de banco de dados ou
certos tipos de operações DDL. [14]
Os triggers podem ser utilizados para muitas operações, incluindo:
•Manter restrições complexas de integridade que não são possíveis por meio de restrições
declarativas ativas na criação da tabela (integridade de domínio, integridade de atributos
e integridade referencial).
•Fazer a auditoria das informações de uma tabela, registrando as alterações efetuadas e
quem as efetuou.
•Sinalizar automaticamente a outros programas que é necessário efetuar uma ação, quando
são efetuadas alterações numa tabela.
•Publicar informações sobre vários eventos em um ambiente de publicação-assinatura.
•Segurança sobre a base de dados, e ação de usuários, verificando quando uma operação é
realizada sobre uma entidade, o trigger é disparado para verificar as permissões do
usuário.
78
Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 2003
Sintaxe geral para criar um trigger
Independente do tipo, todos os triggers são criados utilizando a mesma sintaxe.
CREATE [ OR REPLACE ] TRIGGER nome_do_trigger
{ BEFORE | AFTER | INSTEAD-OF } evento desencadeador
[cláusula referência]
[WHEN condição_de_trigger]
[ FOR EACH ROW ]
corpo_trigger,
nome_do_trigger – é o nome do trigger. Os nome dos triggers são identificadores de
base de dados e, como tal, seguem as mesmas regras que outros identificadores. Embora
possível, não é recomendável dar ao trigger o mesmo nome de uma tabela.
evento desencadeador – especifíca evento que aciona o trigger ( possivelmente
incluindo uma tabela ou visão específica)
corpo_do_trigger - é o código principal do trigger
cláusula referência - é utilizada para referir-se aos dados na linha que atualmente está
sendo modificada por um nome diferente.
Condição_de_trigger - é a cláusula WHEN – opcional (se existir é avaliada em primeiro
lugar). O corpo do trigger só é executado quando esta condição resulta TRUE.
Tipos de triggers
Há três tipos principais de triggers: DML, insted-of e triggers de sistema (DDL).
Triggers DML
Um trigger de DML é acionado por uma instrução de DML e o tipo de instrução
determina o tipo do trigger de DML. Os triggers de DML podem ser definidos em operações
INSERT, UPDATE, ou DELETE. Eles podem ser acionados antes ou depois da operação, e
também podem acionar operações de linha em instruções.
Um trigger DML é acionado em uma operação INSERT, UPDATE ou DELETE de uma
tabela de dados. Ele pode ser acionado antes ou depois que a instrução é executada e pode ser
acionado uma vez por linha problemática ou uma vez por instrução. A combinação desses
fatores determina o tipo de trigger. Há um total de 12 possíveis tipos: 3 instruções X 2
sincronizações X 2 níveis. Por exemplo, todos os seguintes são tipos válidos de trigger de
DML:
•Antes do nível da instrução UPDATE
•Depois do nível da linha INSERT
•Antes do nível da linha DELETE
Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 2003
79
A tabela a seguir resume as várias opções. Um trigger também pode ser acionado para
mais de um tipo de instrução DML em dada tabela – por exemplo, INSERT e UPDATE.
Qualquer código no trigger será executado junto com a própria instrução desencadeadora como
parte da mesma transação
Categoria
Instrução
Sincronização
Valores
INSERT, DELETE
Ou UPDATE
BEFORE ou AFTER
Nível
Linha de Instrução
Comentários
Define que tipo de instrução de DML faz com que o trigger
seja acionado.
Define se o trigger é acionado antes ou depois que a
instrução executada.
Se o trigger for um trigger de nível de linha, ele é acionado
uma vez para cada linha afetada pela instrução
desencadeadora. Se o trigger for um trigger de nível de
instrução ele é acionado uma vez tanto antes como depois da
instrução. Um trigger de nível de linha é identificado pela
cláusula FOR EACH ROW na definição do trigger.
Figura 7 - Instruções desencadeadoras e ação dos triggers
Ordem de disparo de um trigger de DML
Os triggers são acionados à medida que a instrução de DML é executada. O algoritmo
para executar uma instrução de DML é:
1.Execute os triggers antes do nível de instrução, se presente.
2.Para cada linha afetada pela instrução:
2.1 Execute os triggers antes do nível de linha, se presente
2.2 Execute a própria instrução.
2.3 Execute os triggers depois do nível de linha, se presente.
3. Execute os triggers depois do nível de linha, se presente.
Identificador de correlação em triggers de nível e de linha
Instrução
Old
New
desencadeadora
Indefinido, todos os campos são Valores que serão inseridos quando a instrução
INSERT
NULL
for concluída.
Valores originais da linha antes daNovos valores que serão atualizados quando a
UPDATE
atualização
instrução for concluída.
Valores originais antes de a linha Indefinido – todos os campos são NULL
DELETE
ser excluída
Figura 8 - Valores das linhas afetadas antes e depois da ação do trigger
Triggers insted-of
Os triggers insted-of podem ser definidos apenas em visões (tanto de objeto como
relacional). Diferente de um trigger de DML, o qual é executado além da operação de DML, o
80
Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 2003
trigger insted-of será executado em vez da instrução de DML que o acionou. Triggers insted-of
devem ser de linha.
Diferente dos triggers de DML, os quais são acionados além de uma operação de
INSERT, UPDATE ou de DELETE ( tanto antes como depois deles), os triggers insted-of são
acionados em uma operação DML. Além disso, os triggers insted-of podem ser definidos apenas
em visões, ao passo que os triggers de DML são definidos em tabelas. Os triggers insted-of são
utilizados em dois casos:
•Para permitir que uma visão, que caso contrário não poderia ser modificada, seja
modificada.
•Para modificar as colunas de uma tabela aninhada em uma visão.
Triggers de sistema
Um trigger de sistema é acionado quando um evento de sistema como uma inicialização
ou desativação de banco de dados ocorrer, em vez de em uma operação DML em uma tabela.
Um trigger de sistema também pode ser acionado em operações de DDL como a criação de uma
tabela.
Triggers são objetos de banco de dados e como tais estão registrados no Dicionário de
dados. A visão user_triggers contém todas as informações sobre os triggers do banco em uso.
Quando um trigger é criado, seu código-fonte é armazenado na visão user triggers. Esta
visão inclui o corpo do trigger, a cláusula WHEN, a tabela desencadeadora e o tipo de trigger. A
seguir a estrutura da visão user_triggers
user_triggers;
Column Name
Null?
Type
------------------------------------------------------------- -----TRIGGER_NAME
VARCHAR2(30)
TRIGGER_TYPE
VARCHAR2(16)
TRIGGERING_EVENT
VARCHAR2(216)
TABLE_OWNER
VARCHAR2(30)
BASE_OBJECT_TYPE
VARCHAR2(16)
TABLE_NAME
VARCHAR2(30)
COLUMN_NAME
VARCHAR2(4000)
REFERENCING_NAMES
VARCHAR2(128)
WHEN_CLAUSE
VARCHAR2(4000)
STATUS
VARCHAR2(8)
DESCRIPTION
VARCHAR2(4000)
ACTION_TYPE
VARCHAR2(11)
TRIGGER_BODY
LONG
Os triggers devem ser compilados pelo banco para serem objetos ‘válidos’ e devem ser
habilitados ‘ENABLED’, para serem ativados. Triggers podem ser desabilitados ‘DISABLED’
temporariamente sem excluí-los do banco de dados, e reativados posteriormente.
Não há limite para o número de triggers para cada tabela ou visão de dados, a ordem de
disparo será dada pelo evento desencadeador. No Oracle 9i ® não há como em outros bancos de
dados a numeração seqüencial identificadora da ordem de execução de cada trigger.
Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 2003
81
O DBA (já definido anteriormente) fará uso de triggers de Banco de Dados sempre que
este recurso representar qualquer ganho ao sistema.
Descartando e desativando triggers
Semelhantes a outros objetos de banco de dados os triggers podem ser descartados. O
comando para fazer isto tem a sintaxe:
DROP TRIGGER nome_do_trigger
Onde nome_do_trigger é o nome do trigger a ser descartado. Isso remove
permanentemente o trigger do dicionário de dados. Triggers também podem ser desativados sem
ser descartado. Para desativar ou ativar um trigger usa-se a instrução:
ALTER TRIGGER nome_do_trigger| {DISABLE | ENABLE};
Onde nome_do_trigger é o nome do trigger a ser ativado/desativado. Todos os triggers
por padrão são criados ativados. Desativar um trigger não o remove do dicionário de dados.
Triggers como qualquer subprograma armazenado dever ter seu código compilado. A
execução de um trigger não compilado desencadeará a compilação do mesmo, que só será
executado se o mesmo não apresentar erro em tempo de compilação.
Conclusão
Os triggers são uma adição valiosa aos Bancos de Dados. Eles podem ser utilizados para
impor restrições de dados que são muito mais complexas do que restrições referenciais normais
de integridade.
Com a evolução dos triggers e a capacidade de estender a ação destes para além de
eventos de operações DML em uma tabela ou visão possibilitou ainda mais a aplicação de
regras de integridade aos Bancos de Dados, além de vantagens como:
• Reduzir o tráfico de rede.
• Criar um conjunto comum de regras de negócios no banco de dados que se aplicará a
todas as aplicações cliente, independente da ação do usuário, seja este programador ou
usuário do aplicativo. Garantido:
§ controle de integridade: - integridade de domínio.
- integridade de atributos.
- integridade referencial.
§ segurança: - situações importantes de segurança sobre a base de dados. Quando
uma operação é realizada sobre uma entidade, o trigger é disparado para
verificar as permissões do usuário.
§ auditoria: - incluir registros em tabelas de auditoria
- registrar todas as informações sobre tabelas importantes do
sistema.
• Fornecer rotinas comuns que estarão disponíveis para todas as aplicações cliente
reduzindo assim o tempo de desenvolvimento e manutenção, bem como a garantia da
aplicação correta destas rotinas e a confiabilidade dos resultados fornecidos pelas
mesmas.
82
Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 2003
• Centralizar o processamento no servidor e reduzir os requisitos de hardware nas ações
cliente.
• Aumentar a performance das aplicações.
Como exemplo prático aplicado ao módulo de controle de estoque, citamos o exemplo
de um trigger de banco de dados, disparado sobre a tabela de cadastro de materiais, sempre que
um usuário fizer uma tentativa de modificar a unidade de medida de um item. O evento alterar,
a coluna ‘unidade de medida’ acionará o trigger, impedindo que tal mudança seja concluída.
Não existe regra de integridade referencial que possa impedir tal ação, também não há como
confiar no usuário programador que o mesmo garanta este controle em nível de aplicativo.
Agora imaginemos uma situação em que não haveria este controle seguro e um produto que
usualmente se estocava e controla por mililitro (ml) seja alterado inadvertidamente por litro (l).
Tais erros podem ocorrer em Bancos de Dados, cuja segurança de informações não é
corretamente administrada e como erro, neste caso, teríamos para este produto a informação da
quantidade de estoque mil vezes maior.
A evolução dos bancos de dados tende a assegurar sempre mais a integridade dos
mesmos, bem como, permitir que a evolução ou mudança no aplicativo não comprometa o
projeto inicial, com isso cada vez mais os projetistas e DBAs utilizam triggers de Banco de
Dados para garantir a aplicabilidade das regras de negócios. O correto uso e o melhor proveito
da tecnologia, no entanto, sempre ficará a cargo do conhecimento e aplicação correta desta
tecnologia pelo ser humano.
Referências Bibliográficas:
[1] DATE, C. J. Introdução a Sistemas de Bancos de Dados. Rio de Janeiro: Campus, 1991.
[2] BANCO DE DADOS I. 1997. Texto para Disciplina Código: INE 5323. Internet.
http://www.inf.ufsc.br/~ronaldo/ine5323/ine5323.html – 01 Maio 2000.
[3] SILBERSCHATZ, Abranham; KORTH, Henry F. Sistema de Banco de Dados. São Paulo:
MAKRON Books 1995.
[4] SILBERSCHATZ, Abranham; KORTH, Henry F. e SUDARSHAN, S. Sistema de Banco
de Dados. São Paulo: MAKRON Books, 1999.
[5] AMORIM, M. J. Ambiente de Desenvolvimento de Aplicações de Banco de Dados
Ativos, Tese de Mestrado, IME, Rio de Janeiro, 1998.
[6] COSTA, A. Engenharia Reversa de Regras Ativas em Banco de Dados Relacionais,
Tese de Mestrado, IME, Rio de Janeiro, 1997.
[7] APPLETON, D.S. Business Reengineering with Business Rules, in: V. Grover, W.J.
Kettinger(Eds.), Business Process Change – Reengineering Concepts, Methods and
Tecnologies, Londres, Harrisburg, 1995.
[8] MAYER & Bunge Informática S/C Ltda. Otimizando Banco de Dados Relacionais,
Internet, 2000.
[9] HERBEST, H. Business Rule-Oriented Conceptual Modeling, Physica-Verlag: A
Springer-Verlag Company, Switzerland, 1996.
[10] BELL, J. Et al. Re-Engineering Case Study – Analysis of Business Rules and
Recomendations for Treatment of Rules in a Relational Database Environment, Bellevue
Golden: US West Information Technologies Group, 1990.
Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 2003
83
[11] BOOCH, G.; RUMBAUGHR, J.; JACOBSON, I. The Unified Modeling Language for
Object-Oriented Development, Documentation Set Version, 1997.
[12] LOUCOPOULOS, P. Conceptual Modeling, in: P. Loucopoulos, Conceptual Modeling,
Databases, and CASE - New York et. al.: John Wiley & Sons, 1992.
[13] LONEY, K.; THERIAULT, M. Oracele 9i O Manual do DBA . Rio de Janeiro: Campus,
2002.
[14] URMAN, S. Oracle 9i Programação PL/SQL. Rio de Janeiro: Campus, 2002.