uma linguagem de gerÊncia de regras como … · 3.3.2.2 outros mecanismos associados ao modus...
TRANSCRIPT
-
1
SIDNEY DA SILVA VIANA
UMA LINGUAGEM DE GERNCIA DE REGRAS COMO EXTENSO DA LINGUAGEM SQL3
Trabalho apresentado Escola Politcnica da Universidade de So Paulo para a obteno do ttulo de Doutor em Engenharia Eltrica.
So Paulo
2007
-
2
SIDNEY DA SILVA VIANA
UMA LINGUAGEM DE GERNCIA DE REGRAS COMO EXTENSO DA LINGUAGEM SQL3
Trabalho apresentado Escola Politcnica da Universidade de So Paulo para a obteno do ttulo de Doutor em Engenharia Eltrica.
rea de Concentrao: Sistemas Digitais
Orientador: Prof. Dr. Jorge Rady de Almeida Junior
So Paulo
2007
-
3
Este exemplar foi revisado e alterado em relao verso original, sob responsabilidade nica
do autor e com anuncia de seu orientador.
So Paulo, 15 de Agosto de 2007
Assinatura do autor
Assinatura do orientador
FICHA CATALOGRFICA
Viana, Sidney da Silva
Uma linguagem de gerncia de regras como extenso da linguagem SQL3 / S. da S. Viana. -- So Paulo, 2007.
174 p.
Tese (Doutorado) - Escola Politcnica da Universidade de So Paulo. Departamento de Engenharia de Computao e Sis-temas Digitais.
1.Banco de dados ativos 2.Gerncia de regras 3.SQL3 I.Universidade de So Paulo. Escola Politcnica. Departamento de Engenharia de Computao e Sistemas Digitais II.t.
-
4
DEDICATRIA
Aos meus pais
-
5
AGRADECIMENTOS
Ao meu orientador, Prof. Dr. Jorge Rady Almeida Junior, pela orientao dedicada e pelos valiosos comentrios, crticas e sugestes.
A prof. Dra. Edit Grassiani Lino de Campos, que me ensinou o caminho a ser trilhado.
A minha famlia, pelo apoio e incentivo constantes, motivaes essenciais para que eu chegasse fase final.
Aos colegas pelo incentivo e colaborao.
A todos que colaboraram direta ou indiretamente para a concluso deste trabalho.
-
6
SUMRIO
Lista de Figuras
Lista de Tabelas
Lista de Abreviaturas
Resumo
Abstract
1 INTRODUO ............................................................................................ 1
1.1 MOTIVAO ........................................................................................... 1
1.2 OBJETIVO ................................................................................................ 8
1.3 ORGANIZAO DO TRABALHO ............................................................ 9
2 REGRAS EM BANCO DE DADOS ATIVOS............................................... 11
2.1 INTRODUO ....................................................................................... 11
2.2 REVISO DO ESTADO DA ARTE SOBRE REGRAS EM SGBDA .......... 11
2.3 REGRAS EM SISTEMAS DE BANCO DE DADOS ATIVOS ................... 14
2.3.1 RESTRIES DE INTEGRIDADE ................................................................15
2.3.2 DOMNIOS E ASSERES.........................................................................17
2.3.3 FUNES E PROCEDIMENTOS...................................................................17
2.3.4 TRIGGERS..............................................................................................18
2.4 MODELO DE REGRAS EM SBDAS ........................................................ 22
2.4.1 MODELO DE DEFINIO DE REGRAS ........................................................ 23
2.4.2 MODELO DE EXECUO DE REGRAS ........................................................ 26
2.5 ESTRUTURAS DE ARMAZENAMENTO DE REGRAS........................... 29
2.5.1 REPOSITRIO SUGERIDO PELA LINGUAGEM SQL3 .................................... 30
2.5.2 REPOSITRIO DE UM SBDA .................................................................... 33
2.6 GERNCIA DE GERNCIA .................................................................... 36
2.6.1 OPERAES DE GERNCIA PROPOSTA POR SQL3 ..................................... 36
2.6.2 OPERAES DE GERNCIA DOS SGBDAS ................................................ 36
2.7 CONCLUSES........................................................................................ 39
3 MODELO DE REGRAS .............................................................................. 40
-
7
3.1 INTRODUO ....................................................................................... 40
3.2 META-MODELO DE REGRAS ............................................................... 40
3.3 MODELO DE REGRAS ADOTADO ........................................................ 47
3.3.1 MODELO DE DEFINIO DE REGRAS ........................................................ 47
3.3.2 MODELO DE EXECUO DE REGRAS ........................................................ 57
3.3.2.1 DISPARO E EXECUO DE REGRAS ....................................................... 57
3.3.2.2 OUTROS MECANISMOS ASSOCIADOS AO MODUS OPERANDI ................... 59
3.4 OPERAES SOBRE REGRAS .............................................................. 60
3.5 CONCLUSES........................................................................................ 62
4 PROPOSTA DE UM REPOSITRIO DE REGRAS...................................... 63
4.1 INTRODUO ....................................................................................... 63
4.2 SNTESE DAS CARACTERSTICAS DAS REGRAS............................... 64
4.3 DESCRIO DO REPOSITRIO DE REGRAS ....................................... 68
4.3.1 TABELA REGRA ..................................................................................... 68
4.3.2 TABELA EVENTO.................................................................................... 70
4.3.3 TABELA REGRA-EVENTO ........................................................................ 71
4.3.4 TABELA CONDIO ................................................................................ 72
4.3.5 TABELA AO ....................................................................................... 73
4.3.6 TABELA AO-EV ................................................................................. 74
4.3.7 TABELA REGRA_COMPOSIO................................................................ 75
4.3.8 TABELAS USURIO_SISTEMA, COLUNA_SISTEMA E TABELA_SISTEMA...... 77
4.4 META-REGRAS DO REPOSITRIO DE REGRAS.................................. 81
4.5 UM EXEMPLO PRTICO DO USO DO REPOSITRIO .......................... 84
4.6 CONCLUSES........................................................................................ 91
5 OPERAES DE GERNCIA DE REGRAS ............................................... 93
5.1 INTRODUO ....................................................................................... 93
5.2 PROPOSTA DE UMA LINGUAGEM DE GERNCIA DE REGRAS......... 93
5.2.1 OPERAES SOBRE ELEMENTOS DE UMA REGRA ..................................... 94
5.2.1.1 ALTERAR O EVENTO DE UMA REGRA ..................................................... 95
5.2.1.2 ELIMINAR O EVENTO DE UMA REGRA .................................................... 99
5.2.1.3 ADICIONAR UM EVENTO A UMA REGRA ............................................... 102
5.2.1.4 ADICIONAR UMA CONDIO A UMA REGRA ......................................... 106
5.2.1.5 ELIMINAR A CONDIO DE UMA REGRA .............................................. 108
-
8
5.2.1.6 ALTERAR A CONDIO DE UMA REGRA ............................................... 109
5.2.1.7 ADICIONAR UMA AO A UMA REGRA................................................. 111
5.2.1.8 MODIFICAR A AO DE UMA REGRA ................................................... 114
5.2.1.9 ELIMINAR A AO DE UMA REGRA...................................................... 116
5.2.1.10 ALTERNAR AS AES DE UMA REGRA ............................................... 118
5.2.2 OPERAES SOBRE REGRAS ................................................................. 119
5.2.2.1 HABILITAR OU DESABILITAR UMA REGRA ........................................... 119
5.2.2.2 AGRUPAMENTO DE REGRAS................................................................ 120
5.2.2.3 ELIMINAR GRUPO DE REGRAS ............................................................ 121
5.2.2.4 ELIMINAR UMA REGRA ...................................................................... 121
5.2.2.5 HABILITAR OU DESABILITAR UM CONJUNTO DE REGRAS ...................... 122
5.3 NAVEGADOR PARA A GERNCIA DE REGRAS ................................ 122
5.4 REALIZAO DA PROPOSTA EM UM SBDA GENRICO ................. 125
5.5 CONCLUSES...................................................................................... 128
6 ANLISE DA PROPOSTA ....................................................................... 129
6.1 INTRODUO ..................................................................................... 129
6.2 UM ESTUDO DE CASO ........................................................................ 129
6.2.1 O CONTEXTO DO NEGCIO .................................................................... 129
6.2.2 AS REGRAS DE NEGCIO ....................................................................... 133
6.2.3 AS OPERAES DE GERNCIA ................................................................ 146
6.3 CONCLUSES...................................................................................... 159
7 CONCLUSES E PESQUISAS FUTURAS ............................................... 160
7.1 PRINCIPAIS CONTRIBUIES ........................................................... 160
7.2 FUTURAS PESQUISAS ........................................................................ 162
REFERNCIAS BIBLIOGRFICAS ........................................................... 164
ANEXO A - RESUMO DAS SINTAXES PROPOSTA ............................................ 173
-
9
LISTA DE ILUSTRAES
Figura 1 Classificao de eventos nos SBDAs (CHAKRAVARTHY; MISHRA,
1993)................................................................................................24
Figura 2 - Passos envolvidos no processamento de regras (PATON; DIAZ,
1999; VADUVA, 1999)..................................................................27
Figura 3 - Repositrio de regras da linguagem SQL3 (ISOIEC 9075-2, 1999).30
Figura 4 Repositrio de Regras do Oracle....................................................33
Figura 5 - Representao de regras do tipo 1(adaptado de PAVON, 2005).......42
Figura 6 - Representao de regras do tipo 2 (adaptado de PAVON, 2005)......43
Figura 7 - Meta-modelo de regras (PAVON, 2005).........................................44
Figura 8 Regra R1 composta de trs regras: R2, R3 e R4.............................45
Figura 9 Dois tipos de representao de disparos de regras. Na alnea a,
ilustrado um exemplo implcito no qual a regra R6 dispara a regra
R7, R8 e R9, e estas regras esto sujeitas a uma mudana
na ordem de execuo na alnea b eventos explcitos, sendo que a
regra R5 compe-se de trs regras: R2, R3
e R4..........................................................................................46
Figura 10 - Etapas do processamento de regras do tipo 1 e tipo 2
(PAVON, 2005)............................................................................58
Figura 11 Regra R1 especificada de duas formas diferentes.........................59
Figura 12 - Representao do relacionamento entre regra e evento..................71
-
10
Figura 13 - Representao do relacionamento entre regra e os demais
elementos condio e ao.........................................................72
Figura 14 - Representao do relacionamento entre ao e evento...................74
Figura 15 - Representao entidade-relacionamento de uma composio de
regras........................................................................................76
Figura 16 - Diagrama entidade-relacionamento da associao entre o evento
e os demais objetos do banco de dados.......................................78
Figura 17 - Diagrama entidade-relacionamento da associao entre a
TABELA_SISTEMA e as tabelas condio e ao ......................79
Figura 18 - Diagrama entidade-relacionamento relativo ao repositrio de
regras........................................................................................81
Figura 19 - Diagrama de atividade para a insero de uma regra no repositrio
de regras.......................................................................................82
Figura 20 Regra composta (R1, R2, R3, R5)................................................85
Figura 21 Especificao da Regra R8..........................................................86
Figura 22 Regra de negcio Atualiza-Salrio..............................................97
Figura 23 Regra ATUALIZA_CARGO. Na alnea a, a regra possui um
evento de banco de dados, e na alnea b, a mesma regra, teve o
seu evento modificado por um evento sistema..............................99
Figura 24 Barra de tarefas do prottipo.....................................................123
Figura 25 - Prottipo de um navegador de regras para o repositrio de
-
11
regras......................................................................................125
Figura 26 Arquitetura de um SBDA genrico (adaptao de
PAVON (2005)).......................................................................126
Figura 26 - Diagrama de atividades do processo de negcio solicitar
auxlio- evento..........................................................................131
Figura 27 - Diagrama de atividades do processo de negcio cancelar
Auxlio-evento.........................................................................132
Figura 28 Encadeamento entre a regra R5 e R10........................................135
Figura 29 Encadeamento entre a regra R10 e as regras R15, R20, R25........137
Figura 30 Encadeamento de regras referente ao auxilio-evento...................140
Figura 31 Encadeamento entre a regra R30 e a regra R35...........................141
Figura 32 - Encadeamento entre a regra R35 e as regras R40 e R45...............143
Figura 33 - Encadeamento de regras referente ao cancelamento auxilio
-evento....................................................................................144
Figura 34 - Encadeamento de regras do estudo de caso.................................146
Figura 35 - Encadeamento de regras considerando a incluso da regra R27...150
Figura 36 - Encadeamento de regras, considerando a incluso da regra R27
no repositrio de regras...........................................................154
Figura 37 - Encadeamento de regras, aps as alterao na regra R35
e eliminao da regra R30......................................................158
-
12
LISTA DE TABELAS
Tabela 2.1 Operaes de gerncia sobre elementos associados a uma
tabela........................................................................................16
Tabela 2.2 Sintaxe das restries de integridade na linguagem SQL3...........16
Tabela 2.3 - Contedo da tabela TRIGGER TABLE USAGE............................31
Tabela 2.4 Contedo da tabela TRIGGER COLUMN USAGE..........................31
Tabela 2.5 - Contedo da tabela TRIGGERED UPDATE COLUMNS...............32
Tabela 2.6 - Contedo da tabela TRIGGERS...................................................32
Tabela 2.7 - Contedo da tabela DBA_TRIGGERS..........................................34
Tabela 2.8 - Contedo da tabela DBA_TRIGGERS_COLS...............................35
Tabela 2.9 - Operaes de Gerncia no SGBDA Oracle..................................37
Tabela 2.10. Comando para criar e alterar regras em Starburst........................37
Tabela 3.1 - Tipos de regras em diferentes nveis de abstrao........................41
Tabela 3.2 - Linguagem de regras SQL3 e sua Extenso (VIANA; PAVON;
ALMEIDA, 2006)........................................................................48
Tabela 4.1 Meta-regras associadas ao repositrio de regras..........................81
Tabela 4.2 Tabela REGRA..........................................................................86
Tabela 4.3 Tabela EVENTO........................................................................87
Tabela 4.4 Tabela REGRA_EVENTO..........................................................88
-
13
Tabela 4.5 Tabela EV_COL........................................................................88
Tabela 4.6 Tabela EVENTO........................................................................88
Tabela 4.7 Tabela REGRA_EVENTO..........................................................89
Tabela 4.8 Tabela CONDIO...................................................................89
Tabela 4.9 Tabela CONDIO_TAB..........................................................89
Tabela 4.10 Tabela AO..........................................................................89
Tabela 4.11 Tabela AO_TAB.................................................................90
Tabela 4.12 Tabela AO_EV...................................................................90
Tabela 4.13 Tabela REGRA_COMP............................................................91
Tabela 5.1 Meta-regra relacionada uma condio de uma regra...............106
Tabela 5.2 Meta-regra relacionada eliminao da condio de uma regra.108
Tabela 5.3 Meta-regra relacionada alterao da condio de uma regra....110
Tabela 5.4 Meta-regras relacionadas alterao da ao de uma regra.......113
Tabela 5.5 Meta-regra relacionada eliminao da ao de uma regra .......117
-
14
LISTA DE ABREVIATURAS E SIGLAS
A - Ao
BD - Banco de Dados
CA Condio-Ao
CA1A2 Condio-AoPrimria-aoSecundria
ECA - Evento-Condio-Ao
ECA1A2 Evento-Condio-AoPrimria-aoSecundria
LDD Linguagem de Definio de DAdos
LMD Linguagem de Manipulao de Dados
SAMOS - Swiss Active Mechanism-Based Object-Oriented Database System
SBD Sistema de Banco de Dados
SBDA Sistema de Banco de Dados Ativo
SGBD - Sistema Gerenciador de Banco de Dados
SGBDA Sistema Gerenciador de Banco de Dados Ativo
SQL3 ou SQL99- Structure Query Language
-
15
RESUMO
Este trabalho adota um modelo de regras estendido, que melhora a expressividade da
linguagem SQL3, propondo o uso de novas variantes para o modelo de regras ECA (Evento
Condio Ao). Porm, este modelo estendido abrange somente a definio de regras,
faltando as outras operaes de gerncia, como eliminar ou modificar uma regra, entre outros
mecanismos necessrios para gerenciar estes novos tipos de regras. Neste trabalho, prope-se
uma linguagem de gerncia de regras composta de um conjunto de operaes para criar,
excluir e alterar as regras e suas partes, com a finalidade de obter maior reuso e
manutenibilidade das regras. Para tanto, analisa-se o modelo de regras estendido, para
identificar quais so as suas limitaes e as propriedades do modelo a serem consideradas na
especificao da linguagem de gerncia de regras proposta. O resultado desta anlise
utilizado para a elaborao de um repositrio de regras, necessrio para armazenar os tipos de
regras propostos. Este repositrio armazena um conjunto de regras que se deve manter
consistente, da mesma forma que os dados se mantm consistentes em um banco de dados.
Para tanto, foi definido um conjunto de regras de consistncia. Tambm, definido um
conjunto de operaes de gerncia de regras que auxiliam na manipulao de regras e de seus
elementos, armazenadas no repositrio de regras.
Palavras-chave: Banco de Dados Ativos. Gerncia de Regras. SQL3
-
16
ABSTRACT
This work uses an extended rule model which improves the expressiveness of SQL3
language, proposing the use of new variants for the ECA (Event-Condition-Action) rule
model. Nevertheless, the extended model considers only the rule definition and it lacks other
management operations, such as excluding or modifying rules, among others necessary
mechanisms for these new rule types. In this work, a rule management language made of a set
of operations for creating, eliminating and altering rules and its parts is proposed, in order to
obtain greater reuse and maintainability of rules. For this purpose, the extended rule model is
analyzed to identify its limitations and the properties that it supports to be considered in the
rule management language proposed. The result of this analysis is used to define a rule
repository, necessary for storing the rule types proposed. This repository stores a rules set
which must be consistent, as well as data must be consistent in the database. Hence, a
consistency rule set is defined. Besides, a rule management operations set is defined to help to
handle rules and their elements, stored in the rule repository.
Keywords: Active Database. Rule Management. SQL3
-
1
CAPTULO 1. INTRODUO
1.1 MOTIVAO
A relevncia da rea de Banco de Dados tem sido comprovada, por meio do grande
volume de aplicaes que utiliza Sistemas Gerenciadores de Banco de Dados (SGBD), como
um dos componentes principais, no desenvolvimento de sistemas computacionais. Este
sucesso se deve ao fato de que estes SGBD consolidam tarefas de armazenamento e
recuperao de grandes volumes de dados eficientemente, aliados segurana e a ambientes
centralizadores. Este sucesso tambm pode ser constatado, pela prpria indstria de software
(por exemplo, Oracle, Informix, DB2), que propicia ambientes complexos, que garantem, de
forma confivel e eficiente, mecanismos que manipulam, eficazmente, esta grande quantidade
de informaes.
A evoluo dos SGBDs, levou adoo de capacidades ativas, adotando a semntica
destas aplicaes (PATON, 1998). Esta semntica, representada por meio de regras, esta
refletida em comportamentos baseados em eventos. O evento algum acontecimento,
relevante, no tempo. A relevncia pode ser medida pelo fato de que alguma ao deve ser
tomada, em funo da ocorrncia deste acontecimento eventos so elementos essenciais na
elaborao de regras. Regras representam sentenas ou restries associadas aos estados ou
processos de um domnio, por exemplo, compra e venda de produtos via Web.
O comit de padronizao da linguagem SQL3, incluiu, em sua ltima verso
(ISO/IEC 9075-2, 1999), (linguagem SQL3 ou linguagem SQL99), a proposta de incluso de
regras ou triggers nos SGBDs, e que por sua vez foi seguida pela indstria de software. A
linguagem SQL3 um padro de fato, utilizado pelos Sistemas Gerenciadores de Banco de
Dados Ativos (SGBDAs) para a definio e manipulao de dados e regras em banco de
dados. Um SGBDA um SGBD, que alm de suas caractersticas prprias, permite a
definio, gerncia e execuo de regras Evento-Condio-Ao (ECA). As regras ECA
caracterizam-se por terem trs componentes: o evento, a condio, associada a um predicado
a ser avaliado, e a ao, que um conjunto de operaes a serem executadas, toda vez que o
predicado seja avaliado como verdadeiro.
A Incluso de regras dentro de um SGBDA leva a uma srie de vantagens, como por
exemplo:
-
2
A reutilizao de cdigos: regras computacionais derivadas de diferentes domnios de
aplicao podem ser especificadas por meio de uma linguagem de programao provida
pelo prprio SGBDA. Estes fragmentos de cdigos representam a semntica envolvida
nos processos de negcios e podem ser armazenados e utilizados por diversas aplicaes.
Por exemplo, em reas como Workflows no qual a automao de processos de negcio,
por meio de tarefas e/ou documentos so passadas de um participante a outro, de acordo
com regras procedimentais, eBusiness, no qual o foco a obteno de maior vantagem
competitiva, por meio da cadeia de valor da empresa, tais como seus fornecedores,
empregados, acionistas, consumidores e seus processos como conhecimento (obteno de
conhecimento de produtos por parte do cliente, treinamento de revendedores para vender
com maior eficcia), transao (compra eletrnica de produtos) e relacionamento
(intercmbio eletrnico de informaes, personalizao de clientes). O reuso do
conhecimento nestas reas gera economia de recursos e de tempo.
Facilidade nas manutenes preventiva, adaptativa e corretiva dos processos de
negcio: considerando que a semntica dos processos de negcio, por meio de regras,
geralmente espalhada em vrios ambientes, ento as regras armazenadas em um SGBDA
tendem a ser menos complexas, requerendo menor quantidade de recursos para
encaminhar uma soluo, e como conseqncia a manuteno tende a ser menos
complexa.
Centralizao do conhecimento: o intercmbio de informaes eletrnicas , para muitas
empresas, vantagem competitiva, visto que os processos de negcios esto automatizados.
Um exemplo deste intercmbio entre diferentes domnios so cadeias de supermercados e
seus fornecedores. Centralizar estes processos de negcio em poucas aplicaes, sob o
domnio de uma mesma linguagem, em um mesmo ambiente computacional torna o
processo de intercmbio de informao mais simples, pois, exige menos recursos como
reduo no nmero de especialistas em cada uma destas aplicaes, garantia de
padronizao de conceitos para a manuteno da lgica do negcio, alm de custo
financeiro e de tempo.
Entorno Cliente/Servidor: fato conhecido que os SGBDAs Relacionais so dominantes
no mercado e que os ambientes de programao oferecem aos desenvolvedores a
tecnologia Orientada a Objetos. Aglutinar estas duas tecnologias um desafio presente em
um ambiente de desenvolvimento, e que pode apresentar grandes dificuldades quando se
-
3
trata de manipular grandes quantidades de informao, quando as regras do negcio se
encontram na aplicao, e os dados, em bancos de dados. Considerando que em um
SBDA, dados e regras compartilham o mesmo ambiente, ento, possvel minimizar a
impedncia gerada pelos dois ambientes, aplicao e banco de dados, quando na aplicao
so especificadas as solicitaes e no banco de dados a execuo destas solicitaes. Alm
disso, descongestionam-se as redes quanto ao trfego de informaes, quando o
processamento realizado localmente.
Alm destes aspectos positivos, soma-se a versatilidade de um SGBDA em funo de que
existe um ambiente para o tratamento da segurana quanto ao acesso da informao nele
contida como tambm acesso ao prprio banco de dados, mecanismos disponveis para
gerenciamento e controle da integridade dos dados (restries de dados).
Apesar dos aspectos positivos, ainda muito freqente encontrar sistemas com
implementao de regras em meio a seu cdigo, fora do SGBDA. Esta deciso leva a
situaes nas quais regras se tornam redundantes, devido a vrios fatores, como por
exemplo, a falta de documentao atualizada, sobre a especificao da regra, e quando a
manuteno for realizada por diferentes projetistas pode levar a diferentes interpretaes do
processo de negcio. As regras podem ser quase inacessveis, visto que elas podem participar
de complexos fragmentos de cdigos, portanto ocultas no meio de milhares de linhas de
cdigo, em lgicas complexas, dificultando a sua identificao. As regras podem estar
perdidas, ou seja, sistemas so modificados por diferentes desenvolvedores, e muitas vezes,
ao no reaproveitar o cdigo, por razes de desconhecimento da linguagem ou falta de
conhecimento do processo de negcio, isola o fragmento de cdigo analisado e o refaz
segundo o seu entendimento.
Na literatura existem basicamente duas abordagens, desenvolvidas em paralelo, para a
gerncia de regras (CERI; WIDOM, 1990; CERI; MANTHEY, 1993; BERNDTSSON,
1994; MORIARTY, 1998; DIAZ; JAIME, 2000; CERI; COCHRANE; WIDOM, 2000;
ROSS, 2003). Uma delas sob a tica de anlise de negcios e a outra sob a tica de Banco
de Dados. Estas tcnicas so totalmente independentes e desconexas. A gerncia de regras
trata da criao, eliminao e alterao de regras em SGBDA.
Os trabalhos desenvolvidos sob tica de anlise de negcios tm como objetivo
facilitar a atividade de gerncia de regras para os analistas de negcios (VON HALLE, 2002;
VASILECAS; LEBEDYS, 2006) e, portanto, as ferramentas propostas so totalmente
-
4
orientadas para usurios no tcnicos, utilizando um vocabulrio apropriado para os mesmos.
Nesta abordagem prope-se o uso de um software front-end como sistema de regras de um
negcio (ROSS, 2003). Este sistema de regras composto por um repositrio central de
regras, que as armazena em uma linguagem acessvel pelos analistas de negcios (linguagem
quase-natural), e uma mquina de regras, que consiste em um conjunto de programas
especializados na gerncia de regras. Atualmente, existem vrios produtos comerciais que
implementam esta abordagem, tais como, ILOG (ILOG RULES, 2005), Rule Track
(BUSINESS RULE GROUP, 2000) e Business Rule Studio (RULEMACHINES, 2000). A
linguagem de definio de regras varia de acordo com o produto utilizado; a nica
semelhana est em que uma linguagem muito prxima linguagem natural. Uma das
vantagens desta abordagem que os profissionais da rea de negcio podem definir e
gerenciar as regras por meio de uma interface simples, melhorando assim a comunicao
entre analistas de negcio e profissionais tcnicos. Porm, estes sistemas somente abrangem
as regras mais simples, no considerando as regras mais complexas embutidas dentro do
cdigo dos programas de aplicao. Outra desvantagem destes sistemas a ineficincia na
gerncia de grandes quantidades de regras.
A outra abordagem, que analisa as regras sob a tica de Banco de Dados, sugere
aproveitar a infra-estrutura do prprio SGBDA para a gerncia de regras. As regras so
armazenadas em estruturas, assim como os dados, e o prprio SGBDA utilizado como
sistema gerenciador de regras. Esta abordagem adotada neste trabalho.
Uma das vantagens desta abordagem a possibilidade de gerenciar as regras e os
dados em um nico ambiente, simplificando assim a atividade de gerncia desses objetos do
banco de dados. As regras so definidas uma nica vez no banco de dados e podem ser
compartilhadas entre vrias aplicaes, existindo um controle centralizado das regras. Alm
disso, vrios trabalhos tm sido propostos na literatura para auxiliar o projeto de regras em
sistemas de informao, tais como navegadores de regras (LANG, 1998), depuradores de
regras (KAPPEL; KRAMLER; RETSCHITZEGGER, 2001; ELIZONDO, 1998),
analisadores de regras (VADUVA, 1999). Um navegador de regra permite a inspeo de um
conjunto de regras existentes em um repositrio de regras. Por meio deste navegador
possvel criar, eliminar e alterar regras, como tambm possvel saber quais regras foram
disparadas por uma determinada regra. Um depurador de regras uma ferramenta que permite
controlar a execuo das regras com a finalidade de verificar se o repositrio de regras
implementa o comportamento requerido, pelo usurio, adequadamente. Um analisador de
-
5
regras uma ferramenta que permite verificar se existe inconsistncia no conjunto de regras,
por exemplo, se no ocorrem ciclos infinitos quando um conjunto de regras disparado.
No entanto, a maioria das organizaes que opta por especificar as regras de negcio
nos bancos de dados, enfrenta grandes dificuldades para o gerenciamento dessas regras em
seus sistemas de informao, pois falta uma infra-estrutura apropriada para realizar as
atividades de gerncia de regras, de maneira gil e eficiente. Esta infra-estrutura representa
um conjunto de tabelas necessrias para armazenar as regras e um conjunto de mecanismos
para garantir que as regras armazenadas nestas tabelas mantenham a devida consistncia. Este
mecanismo representado por um conjunto de regras de consistncia e estruturas que atuam
de forma a garantir o emprego destas regras quando solicitadas. A atividade de gerncia tem
como objetivo fornecer recursos para definir, eliminar, alterar e consultar regras ou partes
destas.
Assim como os dados, as regras tambm necessitam contar com um mecanismo de
gerncia eficiente, pois na medida em que se apresentam mudanas no negcio, surge a
necessidade de mudanas tambm nas regras. Tais mudanas se refletem por meio da criao
de novas instncias de regras, eliminao de algumas regras j existentes ou a eliminao e
adio de determinadas partes delas. Atualmente, no possvel alterar partes das regras,
pois nos SGBDs atuais elas so tratadas como um elemento nico. Esta incapacidade ocorre
devido a dois fatores: o primeiro em decorrncia de que os repositrios de regras no esto
preparados para tratar alteraes de partes de regras, e o segundo fator est em que no
existem operaes de gerncia definidas para a alterao de partes de uma regra.
Devido evoluo dos processos de negcio, existe a necessidade de armazenar as
regras em estruturas apropriadas para facilitar o seu gerenciamento, assim como, existem
estruturas prprias para o armazenamento dos dados no banco de dados. Tecnicamente,
fazendo um comparativo com os dados, isso significa que os dados so definidos de forma
independente aos outros objetos de banco de dados, por meio de uma linguagem de definio
de dados, e podem ser consultados ou atualizados por meio de uma linguagem de
manipulao de dados. No entanto, uma regra, somente, pode ser criada ou eliminada, no
existindo a possibilidade de realizar operaes de alterao sobre ela. Alm disso, no
dicionrio de dados, so armazenados os relacionamentos das regras com os dados, deixando
de lado as informaes referentes aos relacionamentos entre as regras. Esta informao
sobre o relacionamento, entre regras, importante porque reflete a prpria lgica do negcio e
tambm, representa o prprio encadeamento entre elas. Portanto, uma lgica de negcio pode
-
6
ser representada por um encadeamento de regras, porm, nem todo encadeamento representa
uma lgica de negcio, como por exemplo, podem ser encadeamentos ad hoc que levam a
comportamentos indesejados.
Com estruturas apropriadas, atuando como repositrio de regras possvel armazenar
partes das regras, o relacionamento entre regras e delas com os demais objetos do banco de
dados. As regras de um sistema se relacionam entre si, da mesma forma em que os dados
esto inter-relacionados. Elas tambm se relacionam com os dados, visto que muitas regras
expressam restries sobre eles, gerando assim uma complexa rede de associaes, composta
de associaes entre regras e restries destas sobre os dados. Estes aspectos semnticos,
informaes sobre a estrutura de uma regra e seus relacionamentos so a base para elaborar
um ambiente que suporte operaes de gerncia de regras, e como conseqncia, dispor de
um sistema de regras mais flexvel em comparao com os sistemas atualmente oferecidos.
A linguagem SQL3 sugere um conjunto de operaes de gerncia, tanto para dados
quanto para regras. No caso dos dados, existe um conjunto de operaes para a definio e
manipulao deles. A linguagem de definio de dados (LDD) especifica como criar as
estruturas que vo comportar os dados da aplicao (por exemplo, as tabelas) em conjunto
com mecanismos que auxiliam sua organizao interna (por exemplo, a criao de ndices). A
linguagem de manipulao de dados (LMD) especifica a maneira como manipul-los por
meio de operaes de gerncia, tais como insero, excluso, consulta e atualizao de dados
(FORTIER, 1999). Na linguagem SQL3, as operaes para definio e excluso de uma regra
esto embutidas com as operaes de definio dos dados e, alm disso, estas regras so
includas junto ao dicionrio de dados do banco de dados (ISO/IEC 9075-2, 1999). As
regras no tm um tratamento independente dos dados, pois, ao criar uma regra, necessrio
recorrer LDD para encontrar a sintaxe de criao de uma regra. Neste sentido, o SGBDA
no tem sido muito aproveitado para a implementao e gerncia de regras.
Para que as regras alcancem o mesmo grau de importncia que os dados em um
SGBDA, necessrio que elas tenham um tratamento independente dos dados, apoiado por
uma linguagem de gerncia de regras e um repositrio de regras. Entretanto, existem poucos
trabalhos que tratam sobre a gerncia de regras em SGBDAs (DIAZ; PATON; GRAY, 1991;
CERI; MANTHEY, 1993; BERNDTSSON, 1994; MORIARTY, 1998; CERI; COCHRANE;
WIDOM, 2000; ROSS, 2003) apesar da relevncia desta tarefa.
Apesar das vantagens em implementar regras em um SGBDAs, ainda existe a
necessidade de estender o modelo de regras da SQL3, pois este modelo de regras no
-
7
suficiente para representar a grande maioria dos tipos de regras utilizada para especificar
regras de negcio (PAVON; VIANA; CAMPOS, 2006). Um modelo de regras compreende
um modelo de definio e um modelo de execuo de regras. O modelo de definio
apresentado pela SQL3 a prpria sintaxe da regra ECA, e o modelo de execuo definido
pelo modo como este tipo de regra executado. Para se estender um modelo de regras, por
exemplo, o modelo apresentado pela linguagem SQL3, necessrio identificar e especificar
as caractersticas das regras que se pretende estender. Isto pode ser feito por meio de um
meta-modelo de regras. Existem vrios trabalhos que propem meta-modelos de regras como
extenso da linguagem SQL3 (AMGHAR; MEZIANE; FLORY, 2000; TORRICO;
TANAKA; MOURA, 2000), porm nem todos apresentam uma soluo mais abrangente, que
envolve tanto o meta-modelo quanto o modelo de regras (PAVON, 2005).
O modelo proposto em Pavn estende o modelo de regras apresentado pela SQL3.
Este modelo composto por um conjunto, mais amplo, de tipos de regras que os tipos
apresentados pela linguagem SQL3. Nesta linguagem SQL3, pode-se representar regras do
tipo ECA (evento condio - ao) e, na omisso da condio, do tipo EA (evento - ao).
No modelo proposto, o conjunto de tipos de regras envolve, alm de ECA e EA, os tipos
ECAA (evento - condio - ao primria - ao secundaria), CAA (condio - ao primria
- ao secundria), CA (condio - ao1) e A (ao). Cada tipo de regra representa uma
semntica diferente. Esta melhora na expressividade da regra implica que possvel expressar
um conjunto de informaes, mais amplo.
Alm de ampliar o conjunto de tipos de regras, a linguagem proposta define um
conjunto mais significativo de informaes que podem ser especificados para cada elemento
da regra. Por exemplo, o evento na linguagem SQL3 pode ser definido em funo de trs
operaes de manipulao de dados, a saber: uma insero, uma atualizao e uma excluso
de dados. Na linguagem proposta, este conjunto ampliado, e considera alm das operaes
descritas, outros tipos de operaes que envolvem a seleo de dados, acesso ao banco de
dados, entre outras. No modelo de regras proposto, portanto, semanticamente mais rico que
o modelo de regra da linguagem SQL3 e, portanto considerado como ponto de partida para a
proposta de um conjunto de operaes de gerncia de regras.
Considerando as desvantagens da linguagem SQL3, e os esforos em melhorar a
expressividade desta linguagem, especificamente no que se refere s operaes de gerncia de
1 O termo ao e ao primria tm o mesmo significado. Usa-se ao primria somente em presena de uma ao secundria.
-
8
regras, possvel concluir que ainda existe a necessidade de contar com uma infra-estrutura
propcia para armazenar e gerenciar os principais tipos de regras encontrados nos sistemas de
informao. Portanto, esta infra-estrutura tem como premissa a extenso proposta de tal forma
que nela seja possvel armazenar os relacionamentos existentes entre os diferentes tipos de
regras e delas com os demais objetos do banco de dados. Esta infra-estrutura deve contar com
um repositrio de regras, para armazenar estes novos tipos de regras, com operaes de
gerncia para atuar sobre as regras armazenadas neste repositrio e um conjunto de regras de
consistncia para garantir a consistncia do repositrio de regras. Este trabalho de tese tem
como finalidade de estender a linguagem de gerncia de regras sugerida pelo modelo adotado,
ou seja, oferecer um conjunto de operaes de gerncia, alm das operaes que so sugeridas
neste modelo.
1.2 OBJETIVO
Considerando que as regras so to importantes quanto os dados, existe a necessidade
de contar com um tratamento para regras, da mesma forma que existe para os dados em um
SGBDA, atribuindo-se o mesmo grau de importncia a ambos. Para isto necessrio definir
estruturas apropriadas para o armazenamento e organizao dos tipos de regras sugeridos pela
linguagem SQL3 e os tipos de regras apresentadas na literatura, como extenso desta
linguagem. Estas estruturas devem prover um contexto que facilite a definio e a alterao de
regras, e de suas partes. Como conseqncia, o ambiente apresentado deve ser propcio para a
gerncia de regras, similar ao ambiente existente nos sistemas de bancos de dados, para a
definio e manipulao de dados.
Este trabalho tem por objetivo geral especificar uma Linguagem de Gerncia de
Regras para Sistemas de Banco de Dados Ativos que permita gerenciar um sistema de regras,
tendo como referncia as operaes de gerncia sugeridas pela linguagem SQL3. Essa
Linguagem de Gerncia de Regras proposta a partir de um modelo j proposto na literatura
(PAVON, 2005) que estende a expressividade da linguagem de regras da SQL3, quanto ao
seu modelo de definio de regras. Tal modelo de definio adotado como referncia para a
elaborao de um conjunto de operaes de gerncia de regras. Neste trabalho no so
considerados nem analisados aspectos relativos ao desempenho da linguagem, mas sim, a
expressividade da linguagem proposta frente a linguagem de regras sugerida pela linguagem
SQL3.
-
9
Os objetivos especficos, utilizados como marcos para se chegar ao objetivo geral so
os seguintes.
Fazer uma anlise descritiva do modelo de regras adotado. Esta anlise visa
identificar as caractersticas dos tipos de regras que sero utilizados, sendo que
estas caractersticas servem de base para a elaborao do repositrio de regras.
Estabelecer um repositrio de regras capaz de armazenar os diferentes tipos de
regras. Este repositrio deve contemplar estruturas para o armazenamento das
partes das regras e as associaes entre elas.
Identificar e descrever as meta-regras que devem ser adotadas para garantir a
integridade do repositrio de regras.
Estabelecer as operaes de gerncia de regras. Para cada operao
necessrio avaliar a sua conseqncia perante o repositrio de regras.
Identificar e descrever as meta-regras que devem ser adotadas para garantir o
correto uso das operaes de gerncia.
Elaborar um estudo de caso que servir como ambiente de teste para as
operaes de gerncia.
1.3 ORGANIZAO DO TRABALHO
No captulo 2 apresenta-se uma reviso da literatura, descrevendo-se os principais
conceitos sobre banco de dados ativos, destacando-se os mecanismos utilizados por estes
sistemas gerenciadores para a representao de regras, em especial, o modelo de regra ECA.
No captulo 3 descrito o meta-modelo de regras, que sintetiza as propriedades das regras que
formam a base para a proposta de extenso da linguagem de regras, proposta para a
linguagem SQL3. Esta extenso inclui um modelo de regras, composto pelo modelo de
definio e o modelo de execuo de regras. Neste captulo, descrito o modelo de definio
de regras, visto que este forma a base para a elaborao das operaes de gerncia de regras.
Alm disso, so apresentadas algumas operaes de gerncia de regras disponveis na
literatura e tambm as operaes de gerncia sugeridas no modelo adotado.
No captulo 4, so apresentadas as estruturas utilizadas para o armazenamento dos
tipos de regras que foram propostas no meta-modelo. Tambm elaborado um conjunto de
regras necessrias para garantir a consistncia do repositrio de regras. Este captulo
concludo com um exemplo da aplicabilidade deste repositrio.
-
10
No captulo 5 especificado um conjunto de operaes de gerncia de regras. Esta
proposta inclui um conjunto de operaes para a criao, excluso e alterao de regas e de
suas partes. Esta proposta, de uma linguagem de gerncia, considera os mecanismos
atualmente existentes na linguagem SQL3 e aproveita a extenso proposta para a linguagem
de definio de regras. apresentado um comparativo entre a linguagem de regras SQL3 para
a gerncia de regras e o conjunto de operaes de gerncia sugerido neste trabalho.
No captulo 6 apresentado um estudo de caso para avaliar a proposta do repositrio
de regras e dos mecanismos de gerncia utilizados. So elaborados dois processos de negcio,
que por sua vez so armazenados no repositrio de regras e logo a seguir so utilizadas
operaes de gerncia de regras sobre eles, segundo critrios previamente estabelecidos.
Por ltimo, no captulo 7, apresentam-se as concluses finais deste trabalho, as
principais contribuies e algumas sugestes para pesquisas futuras.
-
11
CAPITULO 2. REGRAS EM BANCO DE DADOS ATIVOS
2.1 INTRODUO
Neste captulo so apresentadas, uma reviso do estado da arte sobre regras em
Sistemas Gerenciadores de Banco de Dados Ativos (SGBDAs) e os mecanismos utilizados
nestes sistemas para a representao de regras. So apresentados os modelos de regras
sugeridos pela linguagem SQL3, os modelos utilizados pelos SGBDAs comerciais para a
especificao de regras, e as estruturas utilizadas por esses gerenciadores para armazenamento
dessas regras. Alm disso, apresentam-se as limitaes dos repositrios destes SGBDAs para
o armazenamento de regras. Da mesma forma, so apresentadas as operaes de gerncia,
sugeridas pela linguagem SQL3 e utilizadas pelos SGBDAs, com a finalidade de identificar as
suas limitaes, em decorrncia destes repositrios. Por ltimo, conclui-se com uma breve
discusso sobre os problemas atuais referentes ao armazenamento e gerncia de regras em
SGBDAs.
2.2 REVISO DO ESTADO DA ARTE SOBRE REGRAS EM SGBDA
No inicio da dcada de oitenta surgiu expresso sistemas de banco de dados ativos
(MORGENSTERN, 1983; STONEBRAKER; WOODFILL; ANDERSEN, 1983), cuja idia
central era de que SBD, deveriam responder de maneira inteligente e no trivial s
solicitaes dos usurios, por meio de suas diversas interaes, e de forma inteligente tratar as
conseqncias e implicaes dessas interaes. Estes sistemas constitudos de diferentes
ambientes de trabalho tinham, em comum, a necessidade de organizar e manter enormes
quantidades de informaes inter-relacionadas. Estas informaes eram constitudas de
mensagens, arquivos, dados estruturados e programas. A este novo paradigma, atribua-se o
nome de Banco de Dados Ativos.
Foi a partir da dcada de noventa que os trabalhos cientficos, na rea de Banco de
Dados Ativos, tornaram-se mais freqentes. O contexto de ativo na tecnologia de banco de
dados engloba tanto regras dedutivas, quanto regras ativas. No primeiro caso, a tecnologia
de banco de dados dedutiva (GUERRINI, 1998) foi influenciada por trabalhos em
programao lgica, sendo que neste caso, as regras dedutivas expressam conhecimento
declarativo e tm sido utilizadas em aplicaes como anlises financeiras, suporte deciso e
-
12
modelagem cientfica. No segundo caso, a tecnologia de banco de dados ativos foi
influenciada pela inteligncia artificial e implementa reaes computacionais automticas em
resposta a eventos que ocorrem tanto interna, quanto externamente ao banco de dados (CERI;
RAMAKRISHNAN, 1996). Neste trabalho, dada nfase ao segundo caso, em funo de que
a grande maioria das aplicaes comerciais usa regras ativas.
As regras em bancos de dados ativos passaram a serem reconhecidas como elementos
fundamentais que devem ser considerados, tanto pela comunidade cientfica, quanto para o
entorno comercial, como um meio para a busca de solues de problemas reais. Para a
comunidade cientfica, os Bancos de Dados Ativos receberam ateno em vrios segmentos
como a especificao de diversas arquiteturas e o desenvolvimento de sistemas e de
linguagens (PATON; DIAZ, 1999). No meio comercial, fabricantes de Sistemas
Gerenciadores de Banco de Dados procuraram incorporar regras (triggers) e a linguagem
SQL3, sugerida pela ISO ANSI (ISO/IEC 9075-2, 1999) passou a adotar um modelo de
regras (PATON, 1998; FORTIER, 1999; TRKER, 2001). Um modelo de regras compreende
um modelo de definio (sintaxe da regra) e seu modelo de execuo de regras. O modelo de
execuo especifica como um conjunto de regras se comporta em tempo de execuo, como
por exemplo, sua poltica de prioridade de execuo ou sua granularidade, entre outros.
Devido riqueza de informaes associadas a um Sistema Gerenciador de Banco de
Dados Ativo (SGBDA), em 1996, Dittrich et al (ACT-NET CONSORTIUM, 1996)
apresentaram um manifesto sobre os principais conceitos associados a esta rea, sugerindo a
uniformizao de sua terminologia e apresentando as caractersticas obrigatrias e desejveis
que um SGBDA devesse conter. Alguns destes conceitos (PATON, 1998) so implementados
em diversas arquiteturas de sistemas de banco de dados ativos, como NAOS (COLLET;
COUPAYE; SVENSEN, 1994), SAMOS (GEPPERT et al., 1995a; GATZIU, 1997), ACOOD
(ENGSTRM; BERNDTSSON; LINGS, 1997), ARIEL (HANSON, 1996), STARBURST
(WIDON, 1996), ORACLE (ORACLE CORPORATION, 2003).
Existem diferentes abordagens para a especificao de uma arquitetura baseada em
regras em um SGBDA. A primeira abordagem a construo de um SGBDA a partir de sua
concepo. A segunda abordagem utilizar um SGBD passivo, modific-lo e estend-lo
internamente. Os SGBDs convencionais so considerados passivos, porque executam
operaes de consulta ou transaes sobre o Banco de Dados somente por solicitao explcita
do usurio ou programa de aplicao. No entanto, os SGBDAs estendem os SGBDs passivos
(PATON, 1999), incorporando a capacidade de executar automaticamente aes em resposta a
-
13
eventos gerados dentro ou fora do SGBDA, o que possvel por meio da especificao de
regras ativas. Nesta segunda abordagem, o cdigo fonte do SGBD deve estar disponvel para
que modificaes possam ser realizadas, como por exemplo, SENTINEL
(CHAKRAVARTHY et al., 1994), POSTGRES (STONEBRAKER; HEARST;
POTAMIANOS, 1989; STONEBRAKER, 1992;), STARBURST (WIDON, 1996). A terceira
abordagem implementar, externamente, as funcionalidades ativas sobre um SGBD passivo.
Estas funcionalidades fazem parte de um framework que utiliza as funcionalidades
disponveis do SGBD passivo. Esta estratgia utilizada pelos Sistemas ACOOD2, SAMOS3
e TriGS (KAPPEL; RETSCHITZEGGER, 1998).
As duas ltimas abordagens, aproveitam o dicionrio de dados como um meio para o
armazenamento de regras e o fazem, estendendo-o, ou seja, especificando e incorporando
novas estruturas para o armazenamento de regras, junto ao dicionrio de dados. Este mesmo
conceito apresentado pela norma que define a linguagem SQL3 (ISO/IEC 9075-2, 1999),
pela qual o dicionrio de dados contm as estruturas utilizadas para o armazenamento de
triggers. A linguagem SQL3 no define claramente uma infra-estrutura voltada para regras,
tendo como base um repositrio de regras, da mesma forma que existe tal infra-estrutura para
os dados, em um dicionrio de dados. Com uma infra-estrutura para regras, seria possvel
promover as regras ao mesmo nvel dos dados, assim como os dados o so em um SGBDA.
Existem propostas de repositrio de regras voltadas para o modelo relacional (HERBST;
MYRACH, 1995; BUTLERIS; KAPOCIUS, 2002), e para o modelo orientado a objetos
(GEPPERT et al., 1995a; DITTRICH et al., 2000). As propostas para o modelo relacional
sugerem um repositrio de regras externo ao SGBDA. Este trabalho segue a abordagem
relacional porque um modelo consolidado e amplamente utilizado na indstria.
Os repositrios de regras so a base para a especificao das operaes de gerncia de
regras, pois sobre estas estruturas so realizadas inseres, modificaes, excluses e
consultas s regras. Existem poucos estudos, apesar de sua importncia, especificamente
sobre a gerncia de regras em SGBDA (CERI; MANTHEY, 1993; BERNDTSSON, 1994;
WIDOM, 1996; CERI; COCHRANE; WIDOM, 2000; BONATTI et al., 2004), apesar de que,
h preocupaes sobre o comportamento das regras e como prover assistncia a elas. Neste
sentido, existem propostas de ferramentas para a assistncia s bases de regras, como
analisadores de regras (GUISHENG et al., 1996; BARALIS; CERI; PARABOSCHI, 1998; 2 Active Object-Oriented Database System 2 Swiss Active Mechanism-Based Object-Oriented Database System
-
14
VADUVA, 1999; BAILEY; POULOVASSILIS; NEWSON, 2000), depuradores de regras
(CHAKRAVARTHY; TAMIZUDDIN; ZHOU, 1995; DIAZ; JAIME, 2000; KAPPEL;
KRAMLER; RETSCHITZEGGER, 2001) e editores de regras (FORS, 1995; LANG, 1998).
Existem produtos comerciais dedicados ao armazenamento e gerncia de regras, cada
qual com sua prpria linguagem de regras, como ILOG (ILOG RULES, 2006) e Rule Track
(BUSINESS RULE GROUP, 2000) acompanhados de suas prprias estruturas de
armazenamento. As regras especificadas nestes sistemas so muito prximas linguagem
natural. A desvantagem destes sistemas reside em que, consideram regras simples, omitindo
regras complexas como cadeias de regras If ... Then ou sentenas do tipo case,
freqentemente utilizadas em linguagens de programao. Alm disso, estes sistemas so
ineficientes no gerenciamento de grandes quantidades de regras.
Nos ltimos anos, repositrios para armazenamento de dados XML, implementados
como framework, externos aos SGBDA, tm sido utilizados para armazenar processos de
negcios (RODRIGUES; CORREIA, 2005; VANHATALO; KOEHLER; LEYMANN,
2006), como conseqncia dos trabalhos cientficos direcionados rea de Internet,
discutindo assuntos sobre a necessidade de regras ECA (Evento-Condio-Ao) na Web e
como especificar, formalmente, eventos compostos no contexto de linguagens Web
(BONATTI et al, 2004; BRY; ECKERT, 2006), alm de tratar, formalmente, regras no
contexto da linguagem XML (eXtended Markup Language) (BONIFATI; CERI;
PARABOSCHI, 2001; ABITEBUL; BENJELLOUN; MILO, 2004), utilizadas para construir
aplicaes Web.
2.3 REGRAS EM SISTEMAS DE BANCOS DE DADOS ATIVOS
Nesta tese, considera-se um Sistema de Banco de Dados Ativo (SBDA) como um
sistema que se constitui de um Sistema Gerenciador de Banco de Dados Convencional
(SGBD) adicionado de um componente ativo e um banco de dados. Este componente ativo
representado por um conjunto de funcionalidades do SGBDA que garantem a reao deste
sistema, quando submetido a eventos. Tal componente ativo permite a especificao e
execuo de regras do tipo Evento Condio Ao (ECA). Estas regras so armazenadas
em estruturas prprias no banco de dados, denominadas repositrio de regras, que formam
parte do dicionrio de dados. A linguagem SQL3 possui um modelo de regras que permite a
especificao de regras ECA, tambm denominado de triggers (ISO/IEC 9075-2, 1999). Alm
-
15
das regras ECA, existem outros mecanismos para especificao de regras que tambm so
armazenadas no dicionrio de dados. Estes mecanismos so restries de integridade, tambm
conhecidas como constraints, definidas sobre tabelas especificadas no banco de dados. Estes
constraints so verificados toda vez que um objeto do tipo tabela definido ou um registro
inserido no banco de dados, e fazem parte da infra-estrutura definida para manipulao e
definio de dados no banco de dados.
2.3.1 Restries de Integridade
A linguagem SQL3 oferece os seguintes mecanismos para definir as restries de
integridade (PAVON, 1996; FORTIER, 1999; TRQUER, 2001).
- PRIMARY KEY: define uma restrio de chave primria em uma tabela.
- UNIQUE: no permite que uma coluna de uma tabela contenha valores
repetidos.
- FOREIGN KEY: define uma restrio de integridade referencial.
- DEFAULT: especifica um valor padro.
- NOT NULL: no permite que uma coluna de uma tabela deixe de conter
valores.
- CHECK: define uma restrio sobre os possveis valores que podem ocorrer em
uma coluna especfica.
Uma restrio identificada por um nome e uma expresso condicional, utilizada para
especificar a restrio de integridade a ser verificada. A violao a esta restrio representa
uma rejeio atualizao do banco de dados que ativou a restrio.
Estas restries so freqentemente utilizadas na especificao de um esquema de
banco de dados, e possuem uma infra-estrutura consolidada para o seu armazenamento e
gerncia.
Basicamente, as operaes de gerncia para a especificao de uma tabela so: criao
(create), alterao (alter) e excluso (drop). Com relao aos elementos da tabela, possvel
alterar, adicionar e excluir uma coluna e seus respectivos tipos de dados, atribuir (set) e
excluir o seu valor default. As restries de valor nico e de integridade referencial podem ser
adicionadas ou excludas da estrutura de uma tabela. Estas operaes de gerncia so
-
16
agrupadas na Tabela 2.1.
Tabela 2.1 Operaes de gerncia sobre elementos associados a uma tabela.
Objetos do Banco de Dados Operaes de Gerncia
Tabela Criar, Alterar, Excluir.
Elementos da Tabela Alterar, Adicionar, Excluir.
Restries de valor nico, valor default Atribuir, Excluir.
Integridade Referencial Adicionar, Excluir.
Expresso condiciona (check) Adicionar, Excluir.
Na Tabela 2.2 apresentada a sintaxe das restries de integridade permitidas pela
linguagem SQL3 Tabela 2.2 Sintaxe das restries de integridade na linguagem SQL3
Restries de Banco de Dados
CREATE TABLE
( [ {}...])
elemento-da-tabela =
|
definio-da-coluna =
| [DEFAULT ]
definio-de-restrio-da-tabela =
|
| CHECK restrio-de-valor-nico = UNIQUE | PRIMARY KEY
[ {nome-coluna}...]
[ {nome-coluna}...] especificao-de-referncias = REFERENCES
< nome-coluna > [ {nome-coluna}...]
-
17
2.3.2 Domnios e Asseres
Alm destas restries, existem restries de domnio (domain) e restries
afirmativas (assertion):
- DOMAIN: define os possveis valores que pode conter um atributo.
- ASSERTION: define restries de integridade sobre os valores de uma tabela com
base em consideraes de busca.
A sintaxe para a especificao de um Domain a seguinte:
CREATE DOMAIN
[DEFAULT ]
[lista-de-restries-do-domnio]
As operaes de gerncia associadas a esta sintaxe so: criao, alterao e excluso
de um domnio.
A sintaxe para a criao de uma assertion a seguinte:
CREATE ASSERTION
CHECK
As operaes de gerncia associadas a esta sintaxe so: criao e excluso de uma
afirmao.
2.3.3 Funes e Procedimentos
Existem tambm rotinas na linguagem SQL3, que podem ser utilizadas para a
especificao de regras, estas rotinas so procedimentos ou funes armazenadas. Uma rotina
um bloco SQL nomeado e, uma vez criado, armazenado no banco de dados. A diferena
na especificao de uma funo com relao a um procedimento est na adio da clusula
Return diante do nome da Funo. A sintaxe utilizada para a especificao de um
procedimento na linguagem SQL3 (ISO/IEC 9075-2, 1999; TRQUER; GERTZ, 2001):
-
18
CREATE PROCEDURE
({ } ... )
[AS]
: identifica o nome do procedimento
: especifica se uma ou mais variveis so passadas como parmetros
para o procedimento. Para cada varivel, deve ser especificado um tipo de argumento (IN,
OUT ou IN OUT), especificado em seguido do seu tipo de dado. Por exemplo,
nome_usurio IN varchar(20) (varivel IN tipo-de-dado). O tipo de argumento IN passa um
valor externo ao procedimento para o procedimento, OUT realiza a operao inversa e IN
OUT combina as duas operaes.
As rotinas so armazenadas em tabelas prprias, e as operaes de gerncia associadas
a elas so: criao, alterao e excluso.
2.3.4 Triggers
Um outro objeto empregado para a representao de regras em sistemas de informao
so os triggers. Estes mecanismos, ao contrrio das rotinas e das restries de integridade,
tm a capacidade de reagir a diferentes eventos, internos ou externos ao banco de dados, da
mesma forma que so utilizados para monitorar situaes de interesse no banco de dados, e
uma vez detectadas, executam-se aes previamente definidas. Uma caracterstica dos
triggers, quando comparados com as rotinas, o fato de serem disparados, automaticamente,
sem o recebimento ou retorno de parmetros (ELMASRI; NAVATHE, 2005; FORTIER,
1999). A sintaxe de definio de um trigger, segundo a notao BNF, a seguinte (ISO/IEC
9075-2, 1999).
CREATE TRIGGER
{BEFORE|AFTER}
[REFERENCING ]
[FOR EACH {ROW|STATEMENT}]
[when ()]
-
19
Cada trigger tem um nome que o identifica, um evento, uma condio e uma ao.
Alm destes trs elementos, fazem parte do trigger informaes sobre seu tempo de ativao e
variveis de transio. O tempo de ativao representa uma relao entre o momento de
ocorrncia do evento e o momento de execuo da regra. A execuo de uma regra representa
a avaliao de sua condio e execuo de sua ao. Existem dois tipos de ativao, antes
(before) ou depois (after). Assim, uma regra pode ser executada antes da execuo da
operao definida como evento ou aps a execuo desta operao. A sintaxe da clusula
evento a seguinte:
::= {INSERT | UPDATE | DELETE} [OF ]
ON
As operaes de manipulao de dados (insert, update e delete) so utilizadas como
evento em um trigger. Considerando a clusula do evento, possvel especificar as colunas de
interesse sempre que o evento for uma operao de atualizao de dados
(update) sobre alguma tabela. Desta forma, o trigger ser disparado quando ocorrer alguma
operao de atualizao sobre as colunas listadas em sua definio. A clusula refere-se tabela sobre a qual realizada a operao de atualizao.
Na especificao do trigger, possvel fazer referncia a valores passados e valores
futuros que so atribudos a um atributo, por meio de variveis de transio. Os valores que
so referenciados na varivel old referem-se aos valores anteriores modificao da tabela e
os valores referenciados na varivel new so os valores posteriores modificao dela.
Na expresso , da sintaxe do trigger, possvel especificar,
tambm, nomes alternativos para as variveis de transio old e new,
segundo a notao:
::= OLD [ROW] [AS]
| OLD [TABLE] [AS]
| NEW [ROW] [AS]
| NEW [TABLE] [AS]
Os elementos da sintaxe utilizada para especificar os valores de transio so
descritos, a seguir, por meio de um exemplo ilustrativo:
Considerando a seguinte expresso: REFERENCING OLD as valor_antigo. O
-
20
valor_antigo utilizado para acessar os valores de referencia varivel old,
independentemente que seja utilizada no elemento condio ou na ao do trigger. A varivel
guarda uma relao direta com a operao definida no evento do trigger. Quando a operao
de insero pode-se utilizar somente a varivel new, quando a operao de atualizao, as
variveis podem ser old ou new e para ocaso de que a operao seja uma excluso ento a
varivel deve ser old.
Na definio do trigger, tambm especificada a granularidade de processamento da
regra. A granularidade de processamento representa o nmero de vezes que o trigger
disparado em relao ao evento. Ela pode ser ao nvel de tupla (FOR EACH ROW) ou ao nvel
de conjunto (FOR EACH STATEMENT). Quando no especificada a granularidade da regra,
assume-se a granularidade de conjunto.
Na do trigger pode ser especificado um predicado sobre o estado do
banco de dados, na forma de uma expresso simples ou uma consulta SQL. A condio pode
apresentar operadores booleanos binrios (OR ou AND) com a finalidade de combinar outros
predicados.
No seguinte exemplo, so empregadas variveis de transio, granularidade da regra e
uma condio simples.
CREATE TRIGGER atualizar_salario
AFTER UPDATE ON EMPREGADO
REFERENCING OLD as salario_antigo
NEW as salario_atual
FOR EACH ROW
WHEN (salario_antigo.salario < salario_atual.salario)
Neste exemplo, o trigger denominado atualizar_salario, e tem especificada na
clusula de evento a definio de uma operao de banco de dados UPDATE, sobre a tabela
EMPREGADO. Definem-se duas variveis de transio, salario_antigo e salrio_atual,
como tambm especificada a granularidade de processamento da regra (FOR EACH ROW).
Portanto, para cada registro da tabela EMPREGADO em que o salrio atualizado, verifica-
se a condio da regra (WHEN). No caso que seja verdadeira, a ao especificada na executada, caso contrrio, nada acontece.
-
21
Na de um trigger, possvel especificar uma sentena procedimental SQL ou
um bloco SQL, segundo a especificao:
::=
::= BEGIN
{ } ...
END;
Uma sentena SQL procedimental um conjunto de operaes ou sentenas vlidas na
linguagem SQL3 que incorpora recursos de programao, como por exemplo,
IF...THEN...ELSE, REPEAT, WHILE, sentenas de linguagem de manipulao de dados,
sentenas de controle de fluxo, variveis e cursores, entre outros.
Um bloco SQL um conjunto destas sentenas, delimitado pelas clusulas BEGIN e
END. O exemplo a seguir apresenta um exemplo de bloco SQL especificado na ao de um
trigger.
CREATE TRIGGER valor_max_emprestimo
AFTER INSERT ON CLIENTE
FOR EACH ROW
WHEN (new.categoria = A)
DECLARE
V_codpedido PEDIDO_EMPR.codpedido %TYPE;
BEGIN
SELECT codpedido INTO V_codpedido
FROM PEDIDO_EMPR
WHERE codcli = :new.codcli;
UPDATE PEDIDO_EMPR
SET valor_max_empr = new.salario_anual * 0,5
WHERE codcli = :new.codcli
AND codpedido = V_codpedido;
END;
Neste exemplo, o trigger valor_max_emprestimo possui um evento definido pela
operao de banco de dados INSERT sobre a tabela CLIENTE, com um tempo de ativao
-
22
AFTER. Portanto, este trigger disparado toda vez que houver a insero de um registro
nesta tabela.
Na condio do trigger avaliado o valor do atributo categoria, se o valor do
atributo em questo A, ento, a ao executada. A ao compreende o cdigo definido
entre os delimitadores BEGIN e END. A ao composta de um bloco SQL, contendo duas
operaes de banco de dados. A primeira operao consiste em uma consulta sobre a tabela
PEDIDO_EMPR, com a finalidade de identificar o cdigo do pedido associado ao cliente que
foi inserido na referida tabela, por meio do evento que disparou esta regra. A segunda
operao composta por uma atualizao de dados sobre a tabela PEDIDO_EMPR. Esta
operao reajusta o valor do emprstimo do cliente em funo de seu salrio anual. As
operaes do tipo insero, excluso e atualizao podem ser o marco inicial para o disparo
de outras regras. No trigger apresentado, existe uma operao de atualizao que ao ser
executada, pode disparar qualquer outro trigger que possua um evento definido com esta
mesma operao de banco de dados sobre a mesma tabela a qual incide o evento. A este
evento define-se como evento de ativao. A este disparo de regras implcito, d-se o nome de
encadeamento de regras ou encadeamento de triggers. Um aspecto no permitido a
existncia de um auto-trigger, ou seja, um trigger que possui, em sua ao, o seu evento de
ativao. Todas as informaes sobre os triggers so armazenadas no dicionrio de dados dos
SGBDAs.
As operaes de gerncia sobre a definio de um trigger, segundo a linguagem
SQL3, so CREATE TRIGGER e DROP TRIGGER. A primeira operao tem a funo de
criar um trigger e armazen-lo no dicionrio de dados, enquanto que a segunda operao
exclui o trigger do dicionrio de dados (TRQUER, 2001). Os triggers so armazenados em
tabelas que formam parte do dicionrio de dados junto com os meta-dados e as tabelas
utilizadas para armazenar dados da aplicao. Na linguagem SQL3 no existe o conceito de
repositrio de regras, ou seja, um conjunto de tabelas utilizadas para armazenar os triggers,
sob o domnio de uma infra-estrutura dedicada ao gerenciamento destas regras.
2.4 MODELO DE REGRAS EM SBDAS
Um Sistema de Banco de Dados Ativos possui um modelo de regras (PATON; DAZ,
1999), composto por um modelo de definio e um modelo de execuo de regras. O modelo
de definio determina o que deve ser especificado na regra (sintaxe da regra), enquanto que o
-
23
modelo de execuo determina como ser o processamento das regras. O modelo de regras
varia de um SGBDA comercial para outro, no entanto os conceitos bsicos adotados por eles
esto presentes no modelo de regras da linguagem SQL3. A finalidade de descrever o modelo
de regras da linguagem SQL3 reside no fato de que este modelo guarda uma relao direta
com o repositrio de regras, pois o repositrio armazena as caractersticas ou propriedades das
regras. O repositrio de regras conseqncia do modelo de regras adotado. A seguir, so
detalhados os modelos de definio e execuo utilizados pela linguagem SQL3.
2.4.1 Modelo de Definio de Regras
O modelo de definio de regras de um SGBDA compreende um conjunto de
sentenas representadas por meio de uma linguagem de definio de regras, cuja finalidade
a especificao de regras ECA (Evento-Condio-Ao). A sintaxe genrica para a definio
de uma regra ECA a seguinte.
DEFINE RULE
ON
IF
DO
Este padro de regra tem sido seguido por vrios SGBDAs comerciais, com a
denominao de triggers, e cada sintaxe definida em um SGBDA comercial pode sofrer
pequenas modificaes, e isto depende diretamente das caractersticas que foram adotadas
pelo SGBDA para a especificao de uma regra. (PATON; DIAZ, 1999; VADUVA, 1999;
ELMASRI; NAVATHE, 2005).
Cada regra deve ser definida com um nome nico. O evento da regra especifica um
acontecimento que dispara a regra. A condio da regra representa um predicado que deve ser
avaliado. Quando o resultado desta avaliao verdadeiro, ento a ao executada. Quando
este resultado falso, a regra no executada.
- Evento
Um evento definido como uma ocorrncia atmica sobre o banco de dados (DIAZ,
1991). O evento produzido por uma fonte, a saber, um sistema informtico externo ao
SGBDA, o prprio SGBDA, um hardware ou interao do prprio usurio com o banco de
-
24
dados. Um SGBDA detecta a ocorrncia dos eventos e d continuidade ao processo com o
disparo das regras que pode por ele serem disparadas. Uma regra disparada por um evento,
mas um evento pode disparar mais de uma regra.
Os eventos podem ser primitivos ou compostos. Um evento primitivo ou simples,
ocorre quando se est diante de uma nica ocorrncia, como por exemplo, uma operao de
banco de dados ou um fato temporal (ACT-NET CONSORTIUM, 1996; JAIME, 1998). A
combinao de eventos primitivos com operadores (AND, OR, SEQUENCE) deriva os
eventos compostos, que por sua vez podem conter outros eventos compostos
(BERNDTSSON; MELLIN; HOGBERG, 1999). Na Figura 1, so apresentados estes
conceitos (CHAKRAVARTHY; MISHRA, 1993).
Figura 1 - Classificao de eventos nos SBDAs (CHAKRAVARTHY; MISHRA, 1993).
Esta classificao tem sido adotada por vrios outros trabalhos (ACT-NET
CONSORTIUM, 1996; GUERRINI, 1998; KANGSABANIK, 1998; VADUVA, 1999;
BERNDTSSON; MELLIN; HOGBERG, 1999; TORRICO; TANAKA; MOURA, 2000;
BONATTI et al., 2004; PAVON, 2005;), e apresenta os eventos primitivos como eventos de
banco de dados, explcitos e temporais. Os eventos de banco de dados so operaes de
manipulao de dados (CHAKRAVARTHY; MISHRA, 1993) como insert, update e delete,
considerando o modelo relacional. Quando o modelo orientado a objetos, ento as operaes
de eventos so mensagens ou chamadas a mtodos (GEPPERT et al., 1995; GATZIU, 1997).
Os eventos explcitos fazem parte da lgica do negcio que so especificadas na aplicao.
Eventos temporais podem ser definidos dentro de dois domnios, absolutos ou relativos. O
primeiro, evento temporal absoluto, diz respeito definio de um momento especfico no
tempo, como por exemplo, 21 de Maro de 2006 s 16 horas. O segundo, evento temporal
relativo, define uma ocorrncia em relao outra. Uma hora aps a ocorrncia do primeiro
Eventos
Eventos Primitivos
Eventos Compostos
Eventos de BD Explcitos Temporais
-
25
evento ou um evento composto da unio de dois eventos primitivos por um conector
booleano.
Uma vez que o evento detectado, ele armazenado no repositrio de dados, em uma
tabela especfica para armazenamento de suas informaes, tais como o seu nome, o nome da
tabela referenciada por ele e as colunas especificadas na sintaxe do evento. A existncia de
um repositrio de regras a base para que seja possvel manipular as informaes nele
armazenadas. Porm, no existem operaes de gerncia sobre eventos. As operaes de
gerncia de regras se limitam sua criao e excluso. Desta forma, para especificar um
evento diferente para uma regra, necessrio eliminar e criar novamente a regra com o novo
evento.
A regra pode ser disparada em funo de dois momentos no tempo. O primeiro
momento pode ser especificado por meio da sentena antes (before), sendo que a regra
disparada antes da ocorrncia da operao do evento. O segundo momento indicado por
meio da sentena depois (after), no qual a regra disparada depois da ocorrncia da
operao definida no evento. O evento um componente obrigatrio na especificao da
linguagem de regras ECA (ACT-NET CONSORTIUM, 1996; TORRICO; TANAKA;
MOURA, 2000).
- Condio
A condio o componente que expressa o que deve ser avaliado para que a ao da
regra seja executada. semelhana do evento, a condio pode ser simples ou composta
(HERBST; MYRACH, 1995). Uma condio simples representa um predicado atmico,
definida por meio de uma expresso simples (por exemplo: maior que 18 anos) ou uma
consulta SQL. Tambm permitido o uso de variveis de transio, old e new, nas consultas
SQL, para referir-se aos valores antigos ou novos de um atributo. Quando a condio se
compe de vrios predicados simples unidos por operadores booleanos do tipo AND ou OR,
dita composta.
As regras Evento-Ao (EA) so uma variao das regras ECA, tendo como
caracterstica a omisso da condio da regra (PATON; DIAZ, 1999). Desta forma, quando
um evento detectado, sua ao imediatamente executada.
-
26
- Ao
A ao um conjunto de operaes que expressa a reao ao evento detectado. Na
ao de um trigger, pode-se especificar um conjunto de sentenas procedimentais SQL ou um
bloco SQL. Uma sentena procedimental pode ser uma sentena SQL ou uma sentena SQL
estendida, que permite o uso de comandos de controle de fluxo, inclusive, o uso de variveis
de transio para acessar valores antigos ou valores novos de uma instncia da tabela. Quando
estas sentenas SQL envolvem operaes de banco de dados, do tipo insert, update e delete,
sobre algum objeto do banco de dados, e so tambm definidas em outras regras como
eventos, ento, este contexto forma um encadeamento de regras.
Problemas associados ao encadeamento de regras so amplamente discutidos na
literatura (AIKEN; HELLERSTEIN; WIDOM, 1992; AIKEN; WIDOM; HELLERSTEIN;
1995; ZIMMER; UNLAND; MECKENSTOCK, 1996; VADUVA; GATZIU; DITTRICH,
1997; VADUVA, 1999; BARALIS; WIDOM, 2000; COUCHOT, 2001) no sendo, portanto,
abordadas neste trabalho.
possvel utilizar, na ao, combinaes de operaes de banco de dado em uma
sentena SQL, por meio de operadores booleanos, o que caracteriza uma ao composta.
(TORRICO; TANAKA; MOURA, 2000)
2.4.2 Modelo de Execuo de Regras
O modelo de execuo de regras define como ser o processamento de uma regra ou
de um conjunto de regras (PATON; DIAZ, 1999; TURKER, 2001; VADUVA, 1999) e
determina as propriedades da execuo de regras, como granularidade de processamento e
modo de acoplamento, entre outras. Com a finalidade de descrever melhor o alcance do
modelo de execuo, na Figura 2 so apresentados os principais passos realizados durante o
processamento de um conjunto de regras (PATON; DIAZ, 1999).
-
27
Figura 2 - Passos envolvidos no processamento de regras (PATON; DIAZ, 1999; VADUVA, 1999).
Sistemas de informao, freqentemente, acessam bancos de dados para realizar
modificao nos dados. Estas modificaes so conseqncia do uso de operaes de bancos
de dados. Estas operaes so detectadas pelo SGBDA, que por sua vez, dispara todas as
regras que possuem como evento estas operaes. O processamento de regra se inicia com a
deteco do evento. Quando se trata de evento composto, um sistema de deteco de evento
composto analisa as diversas ocorrncias de eventos simples que contribuem para o evento
composto desejado, e dispara as regras a ele associadas. Berndtsson apresenta uma anlise de
diversas tcnicas para a deteco de eventos (BERNDTSSON; MELLIN; HOGNERG, 1999)
que so utilizadas em diversos SGBDA, como SENTINEL (CHAKRAVARTHY et al., 1994)
e SAMOS (DITTRICH et al., 2000).
Quando uma nica regra disparada, assume-se a deteco de um evento, avalia-se a
condio e executa-se a ao, desde que a condio seja verdadeira. No entanto, em um
sistema de regras, geralmente mais de uma regra disparada, pelo mesmo evento, gerando um
conjunto de disparo simultneo de regras. Uma regra disparada quando o seu evento
detectado pelo SGBDA, e a regra passa ao estado de execuo quando a condio da regra
Evento Detectado
Regras Selecionadas
Regras Executadas
deteco do evento
disparo
escalonamento
execuo
While conj. regras selecionadas. 0 Do { selecionar a regra avaliar a condio executar a ao }
encadeamento de regras.
Regras Disparadas
-
28
avaliada e sua ao pode ser executada (PATON; DIAZ, 1999; PAVON, 2005). O
processamento de consulta adotado considera a execuo serial de regras, ou seja, uma regra
por vez disparada e executada. Porm existe outra viso, no qual regras so disparadas
simultaneamente. Neste caso, a condio e a ao das regras so avaliadas e executadas
concorrentemente, o que demanda um controle de concorrncia de regras para que a execuo
de uma regra no interfira na execuo da outra (KANGSABANIK, 1998; CERI; WIDOM,
1992).
Quando ocorre um conjunto de conflito de regras, est-se diante de um conflito quanto
ordem de execuo das regras. Antes de aplicar um critrio de seleo para a execuo das
regras, o SGBDA classifica as regras em dois grupos. As regras com tempo de ativao before
e as regras com tempo de ativao after. O passo seguinte executar as regras do primeiro
grupo, e depois do segundo grupo. Considerando que existem vrias regras, tanto do primeiro
quanto do segundo grupo, ento a fase de escalonamento, no processamento de regras, utiliza
estratgias para solucionar este impasse por meio de critrios de prioridade ou precedncia,
com a finalidade de determinar a ordem de execuo de tais regras.
Para alguns SGBDAs, o critrio de prioridade definido pela datahora de criao da
regra, como o caso do SAMOS (PATON, 1998) e ORACLE (ORACLE CORPORATION,
2003). Existem outros SGBDAs que adotam pesos, definidos pelo usurio, e quando o peso
o mesmo para duas ou mais regras, ento, o critrio passa a ser aleatrio. O processamento de
regras pode se repetir quando uma regra possui, em sua ao, algum evento de ativao, que
leve ao disparo de outras regras, reiniciando este processo. Um modelo para a resoluo de
conflitos uma caracterstica marcante dos SGBDAs, visto que, esta propriedade varia entre
cada um deles. Portanto, um sistema de regras, ao ser especificado em um SGBDA, deve
considerar esta propriedade.
No manifesto, ou documento de intenes, sobre regras em SGBDA (ACT-NET
CONSORTIUM, 1996) apresentado um conjunto de propriedades desejveis que um
modelo de execuo de regras deve possuir, dentre estas, as principais so:
a) o SGBDA deveria implementar um modelo de resoluo de conflito, por exemplo os
que foram apresentados anteriormente;
b) Um SGBDA deveria atender ao conceito de granularidade de processamento de
regras. Esta granularidade refere-se ao grau de relacionamento entre a ocorrncia do
evento e o disparo da regra. Existem basicamente duas dimenses para este
relacionamento, a primeira a granularidade de tupla, na qual a regra disparada para
-
29
cada tupla afetada pelo evento, e a segunda, a granularidade de conjunto, na qual a
regra disparada uma nica vez para todo o conjunto de tuplas afetadas pelo evento;
c) Um SGBDA deveria oferecer um modo de acoplamento. O acoplamento ocorre entre
os componentes evento-condio e os componentes condio-ao da regra. As regras
so definidas dentro de transaes, e os eventos fazem parte de transaes tambm. No
entanto, tambm existem modos de acoplamento que fazem referncia a transaes
diferentes, para o mesmo processamento de regra. Estes acoplamentos so definidos
como desacoplados, pois a condio avaliada dentro de uma transao diferente da
transao no qual o evento ocorreu. Da mesma forma, a ao executada dentro de
uma transao diferente da transao na qual a condio ocorreu. Os acoplamentos
referentes mesma transao so definidos como: imediato e atrasado. O primeiro
ocorre quando a condio avaliada imediatamente depois que ocorreu o evento, ou a
ao avaliada imediatamente depois que a condio foi avaliada.
O segundo caso, atrasado, acontece quando a condio avaliada dentro da mesma
transao que o evento da regra, porm no necessariamente na primeira oportunidade,
geralmente o processamento adiado para o final da transao, ou a ao executada dentro
da mesma transao que a condio da regra, mas no necessariamente na primeira
oportunidade. Em Paton (PATON; DIAZ, 1999) apresentado um resumo dos principais
SGBDAs com os seus tipos de acoplamento. A maioria deles opta pelo processamento da
regra dentro da mesma transao.
2.5 ESTRUTURAS DE ARMAZENAMENTO DE REGRAS
O modelo de regras contm informaes que devem ser atendidas pelo repositrio de
regras. Por exemplo, no repositrio so armazenadas a data e hora de criao do trigger, os
eventos definidos na sua sintaxe, o tempo de ativao deste evento, entre outros. Todo
SGBDA possui um repositrio de regras, para armazenar informaes advindas do modelo de
regras. Nesta seo, so analisados diferentes repositrios de dados: o recomendado pela
linguagem SQL3 e um repositrio comercial.
-
30
TRIGGERS TRIGGER
TABLE USAGE
COLUMNS TABLES
TRIGGERED UPDATE
COLUMNS
TRIGGER COLUMN USAGE
(0, N)
(0, N)
(0, N) (0, N)
(1, 1)
(1, 1)
(1, 1)
(1, 1)
(1, 1)(1, 1) (1, 1)
(1, N)
(1, N)
(1, N)
(1, N) (1, 1)
2.5.1 Repositrio Sugerido pela Linguagem SQL3
O dicionrio de dados proposto pela linguagem SQL3 (ISOIEC 9075-2, 1999)
armazena informaes sobre definio das regras e o relacionamento delas com os meta-
dados (tabelas e colunas). Na Figura 3 so apresentadas as estruturas sugeridas pela
linguagem SQL3.
Figura 3 - Repositrio de regras da linguagem SQL3 (ISOIEC 9075-2, 1999)
A tabela TRIGGER TABLE USAGE armazena informaes sobre tabelas utilizadas na
condio ou na ao de um trigger. A tabela TRIGGERS COLUMN USAGE armazena
informaes sobre as colunas utilizadas no evento, na condio ou na ao do trigger, com
exceo da operao de atualizao que especificada na tabela TRIGGERED UPDATE
COLUMNS. A tabela TRIGGERS contm, efetivamente, todas as informaes especificadas
na definio do trigger como a definio da operao definida no evento, tempo de ativao,
entre outros. Cada trigger deve estar associado a uma tabela, e pode estar associado, implcita
ou explicitamente, a colunas desta tabela. Os meta-dados TABLES e COLUMNS,
representados por retngulos pontilhados, tm por finalidade representar estas associaes.
A Tabela 2.3 apresenta as informaes mais relevantes sobre as tabelas que so
-
31
utilizadas em um trigger para efeito de anlise neste trabalho. Por exemplo, as demais
informaes que constam da tabela TRIGGER TABLE USAGE e que no esto presentes