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

Transcrição

1 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,

2 Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 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.

3 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

4 Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 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

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

6 Rev. Cient. Fac. Lourenço Filho - v.3, n.1, Comparação dos metamodelos Metamodelo BROM RIM (ER) 2 Modelo de Componentes ativos Componente dados Evento Condição Ação Processo Entidade Simples e Compostos Condição Ação Especificado por Relacionamento Regra de Negócio 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 Entidade Relacionamento de Negócios Evento de Banco de Dados implícitas Condição e Ação são partes do componente Regra Ausente 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 Regra Dispara Causa Evento Entidade ou Relacionamento Evento Regra Dispara Figura 4 - Esquema do metamodelo (ER) 2

7 76 Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 2003 Modelo Evento-Condição-Ação-se-Ação-senão (ECA 2 ): Redes de Petri são modelos formais para especificar o fluxo de controle em um sistema. A rede ECA 2, 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 (ECA 2 ) 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 Resultado n Evento Evento Evento Figura 6 - Esquema do metamodelo CPM O Paradigma Evento-Condição-Ação-se-Ação-senão

8 Rev. Cient. Fac. Lourenço Filho - v.3, n.1, O Modelo Evento-Condição-Ação-se-Ação-senão (ECA 2 ) é 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.

9 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

10 Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 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 Valores Comentários Instrução INSERT, DELETE Ou UPDATE Define que tipo de instrução de DML faz com que o trigger seja acionado. Sincronização BEFORE ou AFTER Define se o trigger é acionado antes ou depois que a instrução executada. Nível Linha de Instrução 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 desencadeadora INSERT UPDATE DELETE Old New Indefinido, todos os campos são Valores que serão inseridos quando a instrução NULL for concluída. Valores originais da linha antes da Novos valores que serão atualizados quando a atualização instrução for concluída. Valores originais antes de a linha Indefinido todos os campos são NULL 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

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

12 Rev. Cient. Fac. Lourenço Filho - v.3, n.1, 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.

13 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, [2] BANCO DE DADOS I Texto para Disciplina Código: INE Internet Maio [3] SILBERSCHATZ, Abranham; KORTH, Henry F. Sistema de Banco de Dados. São Paulo: MAKRON Books [4] SILBERSCHATZ, Abranham; KORTH, Henry F. e SUDARSHAN, S. Sistema de Banco de Dados. São Paulo: MAKRON Books, [5] AMORIM, M. J. Ambiente de Desenvolvimento de Aplicações de Banco de Dados Ativos, Tese de Mestrado, IME, Rio de Janeiro, [6] COSTA, A. Engenharia Reversa de Regras Ativas em Banco de Dados Relacionais, Tese de Mestrado, IME, Rio de Janeiro, [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, [8] MAYER & Bunge Informática S/C Ltda. Otimizando Banco de Dados Relacionais, Internet, [9] HERBEST, H. Business Rule-Oriented Conceptual Modeling, Physica-Verlag: A Springer-Verlag Company, Switzerland, [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.

14 Rev. Cient. Fac. Lourenço Filho - v.3, n.1, [11] BOOCH, G.; RUMBAUGHR, J.; JACOBSON, I. The Unified Modeling Language for Object-Oriented Development, Documentation Set Version, [12] LOUCOPOULOS, P. Conceptual Modeling, in: P. Loucopoulos, Conceptual Modeling, Databases, and CASE - New York et. al.: John Wiley & Sons, [13] LONEY, K.; THERIAULT, M. Oracele 9i O Manual do DBA. Rio de Janeiro: Campus, [14] URMAN, S. Oracle 9i Programação PL/SQL. Rio de Janeiro: Campus, 2002.