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 R ESTRIES DE INTEGRIDADE ................................................................15
2.3.2 D OMNIOS E A SSERES .........................................................................17
2.3.3 F UNES E P ROCEDIMENTOS ...................................................................17
2.3.4 T RIGGERS ..............................................................................................18
2.4 MODELO DE REGRAS EM SBDAS ........................................................ 22
2.4.1 M ODELO DE D EFINIO DE R EGRAS ........................................................ 23
2.4.2 M ODELO DE E XECUO DE R EGRAS ........................................................ 26
2.5 ESTRUTURAS DE ARMAZENAMENTO DE REGRAS ........................... 29
2.5.1 R EPOSITRIO S UGERIDO PELA L INGUAGEM SQL3 .................................... 30
2.5.2 R EPOSITRIO DE UM SBDA .................................................................... 33
2.6 GERNCIA DE GERNCIA .................................................................... 36
2.6.1 O PERAES DE G ERNCIA P ROPOSTA POR SQL3 ..................................... 36
2.6.2 O PERAES DE G ERNCIA DOS SGBDA S ................................................ 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 M ODELO DE D EFINIO DE R EGRAS ........................................................ 47
3.3.2 M ODELO DE E XECUO DE R EGRAS ........................................................ 57
3.3.2.1 D ISPARO E E XECUO DE R EGRAS ....................................................... 57
3.3.2.2 O UTROS M ECANISMOS A SSOCIADOS AO M ODUS O PERANDI ................... 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 T ABELA R EGRA ..................................................................................... 68
4.3.2 T ABELA E VENTO .................................................................................... 70
4.3.3 T ABELA R EGRA -E VENTO ........................................................................ 71
4.3.4 T ABELA C ONDIO ................................................................................ 72
4.3.5 T ABELA A O ....................................................................................... 73
4.3.6 T ABELA A O -EV ................................................................................. 74
4.3.7 T ABELA R EGRA _C OMPOSIO ................................................................ 75
4.3.8 T ABELAS U SURIO _S ISTEMA , C OLUNA _S ISTEMA E T ABELA _S ISTEMA ...... 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 O PERAES S OBRE E LEMENTOS DE U MA R EGRA ..................................... 94
5.2.1.1 A LTERAR O EVENTO DE UMA REGRA ..................................................... 95
5.2.1.2 E LIMINAR O EVENTO DE UMA REGRA .................................................... 99
5.2.1.3 A DICIONAR UM EVENTO A UMA REGRA ............................................... 102
5.2.1.4 A DICIONAR UMA CONDIO A UMA REGRA ......................................... 106
5.2.1.5 E LIMINAR A CONDIO DE UMA REGRA .............................................. 108
 8

5.2.1.6 A LTERAR A CONDIO DE UMA REGRA ............................................... 109

5.2.1.7 A DICIONAR UMA AO A UMA REGRA ................................................. 111
5.2.1.8 M ODIFICAR A AO DE UMA REGRA ................................................... 114
5.2.1.9 E LIMINAR A AO DE UMA REGRA ...................................................... 116
5.2.1.10 A LTERNAR AS AES DE UMA REGRA ............................................... 118
5.2.2 O PERAES S OBRE R EGRAS ................................................................. 119
5.2.2.1 H ABILITAR OU D ESABILITAR UMA REGRA ........................................... 119
5.2.2.2 A GRUPAMENTO DE REGRAS ................................................................ 120
5.2.2.3 E LIMINAR G RUPO DE REGRAS ............................................................ 121
5.2.2.4 E LIMINAR UMA REGRA ...................................................................... 121
5.2.2.5 H ABILITAR OU D ESABILITAR 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 A S REGRAS DE NEGCIO ....................................................................... 133
6.2.3 A S 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 - R ESUMO DAS S INTAXES P ROPOSTA ............................................ 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

CA 1 A 2 Condio-AoPrimria-aoSecundria

ECA - Evento-Condio-Ao

ECA 1 A 2 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 - ao 1) 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 ACOOD 2, SAMOS 3
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 <nome-tabela>

(<elemento-da-tabela> [ {<elemento-da-tabela>}...])
elemento-da-tabela = <definio-da-coluna>
| <definio-da-restrio-da-tabela>
definio-da-coluna = <nome-da-coluna> <tipo-de-dados>
| [DEFAULT <valor-padro>]
definio-de-restrio-da-tabela = <restrio-de-valor-nico>
| <restrio-de-integridade-referencial>
| CHECK <expresso-condicional>
restrio-de-valor-nico = UNIQUE | PRIMARY KEY <nome-coluna>
[ {nome-coluna}...]
<restrio-de-integridade-referencial = FOREIGN KEY <nome-coluna>
(<colunas-referenciadas>) <especificao-de-referncias>
colunas-referenciadas = < nome-coluna > [ {nome-coluna}...]
especificao-de-referncias = REFERENCES <nome-tabela>
< 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 <nome-dominio> <tipo-de-dados>
[DEFAULT <valor-padro>]
[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 <nome-restrio>
CHECK <expresso-condicional>
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 <nome do procedimento>

({<argumento> <modo> <tipo-de-dados> <vrgula>} ... )
[AS]
<bloco SQL>

<nome do procedimento> : identifica o nome do procedimento

<argumento> : 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 <modo> 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 <nome-trigger>

{BEFORE|AFTER} <evento>
[REFERENCING <variveis de transio>]
[FOR EACH {ROW|STATEMENT}]
[when (<condio>)]
<ao>
 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:

<evento> ::= {INSERT | UPDATE | DELETE} [OF <lista de colunas>]

ON <nome da tabela>

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 <lista de colunas> 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 <nome da
tabela> 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 <variveis de transio>, da sintaxe do trigger, possvel especificar,
tambm, nomes alternativos <nome do alias> para as variveis de transio old e new,
segundo a notao:
<variveis de transio> ::= OLD [ROW] [AS] <nome do alias>
| OLD [TABLE] [AS] <nome do alias>
| NEW [ROW] [AS] <nome do alias>
| NEW [TABLE] [AS] <nome do alias>

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 <condio> 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)
<ao do trigger>

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 <ao do
trigger> executada, caso contrrio, nada acontece.
 21

Na <ao> de um trigger, possvel especificar uma sentena procedimental SQL ou

um bloco SQL, segundo a especificao:

<ao> ::= <sentena SQL procedimental>

<bloco SQL>
<bloco SQL> ::= BEGIN
{<sentena SQL procedimental> <ponto e vrgula>} ...
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 <nome_regra>

ON <evento>
IF <condio>
DO <ao>

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

Eventos

Eventos Eventos
Primitivos Compostos

Eventos
Explcitos Temporais
de BD

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

deteco
do evento

Evento
Detectado

disparo

Regras
Disparadas
encadeamento
de regras. escalonamento
Regras While conj. regras selecionadas. 0
Selecionadas Do
{ selecionar a regra
execuo avaliar a condio
executar a ao
Regras }
Executadas

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

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.

TRIGGERED TRIGGER
(0, N) (1, 1) TRIGGERS (1, 1) (1, N)
UPDATE TABLE
COLUMNS USAGE
(1, 1)
(0, N) (1, N)

(1, N)
(1, 1) (1, 1)
(1, 1) (0, N) TRIGGER (0, N) (1, 1)
COLUMNS COLUMN TABLES
USAGE
(1, N) (1, 1)

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 nesta
tabela so o nome do esquema do banco de dados ao qual pertence a tabela referenciada na
condio e ao e o respectivo trigger. Nesta tabela, inserido um registro para cada tabela
referenciada na condio ou na ao do trigger.

Tabela 2.3 - Contedo da tabela TRIGGER TABLE USAGE

Coluna Descrio da coluna

Trigger_name Nome do trigger
Table_name Nome da tabela referenciada na condio ou ao do trigger

A Tabela 2.4 apresenta as principais informaes sobre as colunas utilizadas na

condio e na ao do trigger Nesta tabela inserido um registro para cada coluna
referenciada na condio ou na ao do trigger. Alm disso, tambm armazenado o nome da
tabela qual pertence esta coluna e o nome do trigger correspondente. Assim como a tabela
anterior, outras informaes tambm fazem parte da tabela TRIGGER COLUMN USAGE,
como o nome do esquema ao qual pertence tabela e o trigger..
Tabela 2.4 Contedo da tabela TRIGGER COLUMN USAGE

Coluna Descrio da coluna

Trigger_name Nome do trigger
Table_name Nome da tabela que contm a coluna referenciada no trigger
Column_name Nome da coluna referenciada no trigger

Na Tabela 2.5 apresentam-se as principais informaes sobre a tabela TRIGGERED

UPDATE COLUMNS. Esta tabela armazena um registro para cada coluna contida na
definio do evento, considerando que este evento seja uma operao update. As tabelas
correspondentes a esta operao, tambm so armazenadas na tabela TRIGGERED UPDATE
COLUMNS.
 32

Tabela 2.5 - Contedo da tabela TRIGGERED UPDATE COLUMNS

Coluna Descrio da Coluna

Trigger_name Nome do trigger
Event_object_table Nome da tabela afetada pela operao definida como evento
Nome da coluna especificada na <lista-de-coluna> na definio
Event_object_column
do trigger (especificamente para operaes update)

Na Tabela 2.6 apresentam-se as informaes da tabela TRIGGERS. A tabela

TRIGGERS contm um registro correspondente a cada trigger instanciado ou criado. Para
cada um deles atribuda uma nica operao de banco de dados. O atributo action_order
contm o valor da posio do trigger dentro de uma lista de triggers definidos com o mesmo
evento sobre a mesma tabela, e portanto com o mesmo tempo de ativao e com a mesma
granularidade. Outros atributos que fazem parte da tabela, tais como o nome do esquema de
banco de dados a que pertence o trigger, os valores de transio (old e new) no foram
adicionados pelo fato de que no agrega valor a anlise que feita sobre o repositrio.

Tabela 2.6 - Contedo da tabela TRIGGERS

Coluna Descrio da Coluna

Trigger_name Nome do trigger
Event_manipulation Operao de BD definida como evento (insert, update e delete)
Event_object_table Nome da tabela afetada pela operao definida no evento
Action_order Posio do trigger dentro do conjunto de conflito
Condition Condio do trigger
Action Ao do trigger
Action_Orientation Granularidade de processamento do trigger (row ou statement)
Condition_time Tempo de ativao do trigger (before ou after)
Timestamp Data e hora de criao do trigger

As estruturas apresentadas no dicionrio de dados da linguagem SQL3, para

armazenar regras, apresentam dois grupos de informaes bem definidas. O primeiro grupo,
formado pelas tabelas TRIGGER TABLE USAGE, TRIGGERS COLUMN USAGE, e
TRIGGERED UPDATE COLUMNS, armazena informaes sobre as tabelas e colunas
utilizadas no trigger, e o segundo grupo, formado pela tabela TRIGGERS, armazena
 33

informaes sobre o evento, condio e ao do trigger. A limitao do repositrio ocorre em

funo do modelo de regras adotado. O modelo de regras da linguagem SQL3 no permite a
definio de regras com duas ou mais aes, ou a especificao de eventos compostos
(WIDOM, 1996; PAVON; VIANA; CAMPOS, 2006), portanto, estas diferenas entre
modelos no so contempladas na tabela TRIGGERS.
Apesar destas estruturas apresentadas pela linguagem SQL3 serem sugestes, os
SGBDAs comerciais (ORACLE CORPORATION, 2003; POSTGRESQL, 2005)
implementam algumas delas e adicionam outras com a finalidade de melhorar a gerncia
sobre as regras.

2.5.2 Repositrio de um SGBDA

Nesta seo so descritas as estruturas utilizadas por um SGBDA comercial. O critrio

utilizado na seleo do SGBDA Oracle (ORACLE CORPORATION, 2003) o fato de que
um dos mais utilizados, alm de que sua documentao, completa, est disponvel no site da
empresa (ORACLE CORPORATION, 2003). Alm disso, este SGBDA utilizado por vrias
empresas, em distintas reas. A verso analisada Oracle Database 10g Release 1.
A linguagem de regras deste SGDBA tem por base o modelo de regras sugerido pela
linguagem SQL3, porm apresenta algumas variaes. Na Figura 4, apresentado o
repositrio de regras do Oracle.

VIEWS TABLES

(1, 1) (1, 1) (1, N)

(1, N) (1, N) (1, N)

(1, N) (1, N)
DBA_TRIGGERS DBA_TRIGGERS_COLS

(1, N)

COLUMNS (1, N)

Figura 4 Repositrio de Regras do Oracle

 34

O dicionrio de dados do Oracle composto por duas tabelas principais,

DBA_TRIGGERS e DBA_TRIGGERS_COLS. A tabela DBA_TRIGGERS descreve todos os
triggers do banco de dados e a tabela DBA_TRIGGERS_COLS descreve as colunas dos
triggers do banco de dados. Existem outras tabelas para armazenar informaes sobre os
triggers tais como USER_TRIGGERS e USER_TRIGGERS_COLS, utilizadas para armazenar
as mesmas informaes das tabelas apresentadas na Figura 4, com a diferena de que o acesso
fica restrito ao usurio corrente. Portanto, no acrescentam quaisquer informaes anlise
do repositrio do Oracle, razo pela qual no so apresentadas na Figura 4.
A primeira tabela, DBA_TRIGERS, contm os principais elementos declarados na
sintaxe do trigger, tais como o seu tempo de ativao, a especificao do evento, da condio
e de sua ao, o estado em que se encontra o trigger (ativo ou inativo), entre outros. A
segunda tabela DBA_TRIGGERS_COLS contm informaes sobre as colunas utilizadas no
trigger. No repositrio da Figura 4, so apresentados alguns dos meta-dados referenciados
pelos triggers, representados pelos retngulos pontilhados e na Tabela 2.8 so apresentados os
principais elementos da tabela DBA_TRIGGERS.

Tabela 2.7 - Contedo da tabela DBA_TRIGGERS

Coluna Descrio da coluna
Owner Proprietrio do trigger
Trigger_name Nome do trigger
Especificao do tempo de ativao (before ou after) e da granularidade de
Trigger_type processamento (each row ou statement). Ex. before statement, after
statement, before each row, entre outros
Triggering_event Operao definida como evento (DDL, DML ou eventos de BD).
Base_objetct_type Tipo de objeto sobre o qual definido o evento (ex. table, view, etc.)
Table_name Nome da tabela ou view sobre o qual definido o evento
Referencing_names Nomes especificados para referenciar os valores de transio new e old
When_clause Condio do trigger
Status Indica o estado o trigger (habilitado ou desabilitado)
Indica se a ao um conjunto de sentenas SQL (PL/SQL) ou uma
Action_type
chamada a um procedimento armazenado (CALL).
Trigger_body Ao do trigger

A tabela DBA_TRIGGERS contm um registro para cada definio de trigger. Cada

um destes registros tem associado o proprietrio do trigger, o nome e o tipo do trigger,
 35

formado pelo tempo de ativao e sua granularidade de processamento. O evento pode ser
definido por meio das operaes de manipulao de dados (insert, update, delete), operaes
de definio de dados (create, alter, drop) ou operaes de banco de dados (logon, logoff,
startup, shutdown, servererror). O SGBDA Oracle permite especificar eventos compostos, os
quais representam uma combinao de eventos simples, por meio do operador booleano OR.
No permitido conjugar eventos de natureza distinta. Por exemplo, eventos que
correspondem a operaes de manipulao de dados podem ser combinados entre si com o
operador OR, o mesmo ocorre com operaes de definio de dados ou operaes de banco de
dados.
As informaes armazenadas no atributo trigger_type esto associadas s informaes
do atributo triggering_event, por exemplo, um trigger pode ser disparado mais de uma vez
(for each row) quando as operaes definidas no evento so operaes de manipulao de
dados. O atributo status armazena informaes sobre o estado do trigger, e por meio de
operaes de gerncia, um usurio pode habilitar ou desabilit-lo. A condio e a ao so
armazenadas integralmente nos atributos, when_clause e trigger_body, respectivamente,
limitado apenas pela capacidade do tipo de dado especificado para o atributo; a condio pode
ter no mximo 4kbytes e a ao um tamanho mximo de 32kbytes. A tabela 2.7 apresenta as
informaes sobre as colunas das tabelas utilizadas no trigger.

Tabela 2.8 - Contedo da tabela DBA_TRIGGERS_COLS

Coluna Descrio da coluna
Trigger_name Nome do trigger
Table_name Nome da tabela que contm a coluna referenciada no trigger
Column _name Nome da coluna referenciada no trigger
Column_list Indica se utilizado ou no no evento update (Y ou N)

Nesta tabela inserido um registro para cada atributo especificado no trigger. Quando
se trata de um evento definido com update, as colunas deste evento so identificadas por meio
do atributo column_list. A complexidade do repositrio funo do modelo de linguagem
definido para a especificao do trigger. Um exemplo de informao, que no contempla o
dicionrio de dados do Oracle, relacionamento entre regras. Ela importante para identificar
quais regras podem ser disparadas por outras regras, sem a necessidade de realizar uma
anlise aprofundada sobre as tabelas do dicionrio de dados.
 36

2.6 GERNCIA DE REGRAS

As linguagens de regras dos SGBDAs fornecem um conjunto de operaes sobre as

regras ou partes destas, de tal forma que permitam gerenciar as informaes armazenadas
sobre as mesmas no repositrio de dados (TURKER, 2001). Um repositrio de dados contm
informaes sobre as regras e por meio do SGBDA estas informaes esto disponveis, tanto
para os usurios quanto para as aplicaes. Desta forma, eles podem recuperar informaes
sobre as regras da mesma forma que o fazem com os dados. A linguagem SQL3 sugere um
conjunto de operaes de gerncia, que em sua maioria so implementadas pelos SGBDAs
comerciais. Nas sees seguintes so apresentadas as operaes de gerncia proposta pela
linguagem SQL3, e pelos SGBDAs Oracle e Starburst (WIDOM; 1996). A escolha destes
dois SGBDAs pelo fato de que implementam o modelo relacional e suas linguagens de regra
(sua sintaxe e seu modelo de execuo) serem uma verso estendida das operaes de
gerncia da linguagem SQL3.

2.6.1 Operaes de Gerncia Proposta pela Linguagem SQL3

A Linguagem SQL3 (TURKER, 2001) sugere um conjunto de operaes de gerncia

para a definio e excluso de uma regra, do dicionrio de dados:
Create Trigger Este comando cria uma regra no dicionrio de dados.
Drop Trigger este comando exclui uma regra do dicionrio de dados
Aps a definio de um trigger, o usurio pode, somente, elimin-lo, no existe a
possibilidade de alterar o trigger ou parte do mesmo. possvel consultar dados referentes a
um trigger, como por exemplo o seu evento ou o corpo do trigger, representado pela sua
condio e ao.

2.6.2 Operaes de Gerncia dos SGBDAs

As operaes de gerncia de regras oferecidas pelos SGBDAs tm como referncia as

operaes sugeridas pela linguagem SQL3. No SGBDA Oracle (ORACLE CORPORATION,
2003), as operaes para a gerncia de regras so definidas como operaes para criar,
excluir, habilitar e desabilitar uma regra. Na Tabela 2.9 so apresentadas as sintaxes destas
operaes.
 37

Tabela 2.9 - Operaes de Gerncia no SGBDA Oracle

Nome da operao Sintaxe da operao

Excluso de uma regra DROP TRIGGER <nome do trigger>;
Habilitar uma regra ALTER TRIGGER <nome do trigger> ENABLE;
Habilitar todos os triggers associados a
ALTER TABLE <nome tabela> ENABLE ALL TRIGGERS
uma tabela
Desabilitar uma regra ALTER TRIGGER <nome do trigger> DISABLE;

Estas operaes variam de um SGBDA para outro. No Starburst 4 (WIDOM, 1996;

PATON, 1998), a linguagem para definio e manipulao de regras consiste de cinco
comandos, a saber: create rule, alter rule, deactivate rule, activate rule e drop rule.
Considerando que neste SGBDA possvel a criao e manipulao de um conjunto de
regras, ento outras operaes so definidas para dar suporte a estes grupos, como create
ruleset, alter ruleset e drop ruleset. O comando alter rule usado para mudar os componentes
da regra aps ela ter sido definida.
A sintaxe para criao de uma regra e a sintaxe para a sua correspondente alterao
so apresentadas na Tabela 2.10.

Tabela 2.10. Comando para criar e alterar regras em Starburst

Sintaxe para criao Sintaxe para alterao

Create rule <nome da regra> on <nome da tabela>
When operao definida como evento
[if <condio>]
then <ao>
[precedes <lista de regras>]
[follows < lista de regras >]
Alter rule <nome da regra> on <nome da tabela>
[if <condio>]
[then <ao>]
[precedes <lista de regras>]
[follows < lista de regras >]
[nopriority < lista de regras >]

O comando create rule usado para definir uma nova regra. Cada regra definida
sobre uma tabela. Os colchetes indicam clusulas que so opcionais. A clusula when
especifica um ou mais eventos, que podem ser operaes de manipulaes de dados (insert,
update e delete). As clusulas precedes e follows so usadas para especificar ordem de
prioridade entre regras. O comando alter rule segue a mesma sintaxe para a criao de regra,
na qual a clusula nopriority usada para remover a prioridade da regra. Quando a clusula

4
Prottipo extensvel relacional SGBDA desenvolvido pela IBM
 38

when necessita ser alterada, na sintaxe de criao da regra, ento necessrio exclu-la e cri-
la novamente. Para excluir uma regra, usado o seguinte comando:
Drop rule <nome da regra> on <nome da tabela>

As regras podem ser ativadas e desativadas mediante os seguintes comandos:

Deactivate rule <nome da regra> on <nome da tabela>
activate rule <nome da regra> on <nome da tabela>

Os comandos para criao, adio e excluso de um conjunto de regras so

especificados pela sintaxe a seguir:
create ruleset <nome do conjunto de regras>
alter ruleset <nome do conjunto de regras>
[addrules <lista de regras>]
[delrules <lista de regras>]

Cada regra pode estar em qualquer grupo de regras e cada conjunto de regras pode
conter qualquer nmero de regras. Para excluir um conjunto de regras, necessrio utilizar o
seguinte comando:
Drop ruleset <nome do conjunto de regras>

O Starburst, alm das operaes apresentadas, dispe de um comando para o

processamento de regras. Este comando pode ser usado pelo usurio para processar uma regra
ou um conjunto delas. A sintaxe deste comando apresentada a seguir (PATON; DIAZ, 1999;
ELMASRI; NAVATHE, 2005).
Process rules
Process ruleset <nome do conjunto de regras>
Process rule <nome da regra>

Apesar de que a linguagem de regras proposta pelo Starburst apresenta mais opes
para o gerenciamento de regras, este SGBDA no implementa o conceito de granularidade de
regras por linha e nem por conjunto (WIDOM, 1996; PATON, 1998), conceito implementado
tanto na linguagem SQL3, quanto nos SGBDAs comerciais.
 39

2.7 CONCLUSES

Considerando a base apresentada neste captulo, conclui-se que os dicionrios de

dados disponveis para a representao de regras do tipo ECA e EA, utilizadas pela linguagem
SQL3 e pelos SGDBAs comerciais, no so suficientes para oferecerem a infra-estrutura
necessria para viabilizar outras operaes de gerncia, tais como operaes para alterao do
evento, alterao da condio alm das operaes atualmente disponveis: criar, excluir,
habilitar e desabilitar uma regra. Isto ocorre em funo de que as regras so armazenadas em
um ambiente utilizado para armazenar dados, com uma infra-estrutura dedicada a estes dados.
No existe uma concepo clara e direcionada, para regras, que corresponda ao
armazenamento de regras em um ambiente propcio para elas, da mesma forma como ocorre
para os dados. A elaborao de um repositrio de regras, vinculado a um modelo de regras,
capaz de oferecer um conjunto de operaes de gerncia, para definir e alterar regras,
fundamental. Este repositrio de regras teria as estruturas para o armazenamento das regras, e
um conjunto de meta-regras para garantir a consistncia das regras armazenadas no
repositrio e seria manipulado pelas operaes de gerncia, da mesma forma como os dados o
so, no dicionrio de dados. O objetivo oferecer outro ambiente para que o usurio possa
definir suas regras de negcio, alm do ambiente que comumente ele define. Bajec (2005)
apresenta um conjunto de questes, ainda pendentes, relacionadas com a especificao,
implementao, armazenamento e gerncia de regras de negcio. Esta tese est orientada a
estas duas ltimas questes, sendo o foco principal a gerncia de regras, de tal forma que seja
possvel minimizar a impedncia atualmente existente, por parte dos usurios, em gerenciar as
regras de negcio, definidas no banco de dados (BAJEC; KRISPER, 2005).
Existem outros tipos de regras sugeridos na literatura (PAVON, 2005) como um meio
para flexibilizar a representao de regras mais complexas, sendo que os repositrios
propostos no oferecem a infra-estrutura necessria para o armazenamento destas regras,
como tambm falta o suporte para definir um conjunto de operaes de gerncia de regras,
que atuem sobre estes novos tipos de regras.
No prximo captulo, apresentada uma anlise detalhada do meta-modelo e do
modelo de regras adotados, que foi sugerido como extenso do modelo de regras adotado pela
linguagem SQL3. Este modelo a base para a especificao de um repositrio de regras.
Sobre este repositrio so definidas as operaes de gerncia.
 40

CAPITULO 3. MODELO DE REGRAS

3.1 INTRODUO

Neste captulo, apresenta-se e analisa-se um modelo de definio de regras. Este

modelo a base para a elaborao da proposta de um repositrio de regras, apresentado no
captulo seguinte. O modelo de definio de regras o resultado da elaborao de um
conjunto de caractersticas que foram identificadas na linguagem SQL3, analisadas e depois
estendidas, e apresentadas em um meta-modelo de regras (PAVON, 2005).
Inicialmente descrito o meta-modelo de regras, com o objetivo de ilustrar as
caractersticas dos tipos de regras de negcio freqentemente utilizadas em sistemas de
informao. Logo a seguir descreve-se o modelo de definio de regras. Este modelo, em
conjunto com o modelo de execuo, formam o modelo de regras, elaborado por Pavn
(2005). O modelo de definio, ou sintaxe da regra, contribui para a identificao dos
componentes que sero armazenados no repositrio de regras. Alm deste modelo, descrito
o modelo de execuo com a finalidade de descrever o comportamento destas regras. Por
meio da anlise deste comportamento, possvel identificar algumas informaes que
auxiliam na elaborao das meta-regras, necessrias para garantir a consistncia do
repositrio.
Uma vez que meta-modelo e modelo sejam descritos, so realizadas ponderaes
sobre quais aspectos so efetivamente considerados na especificao do repositrio de regras.
O meta-modelo e o modelo de definio de regras so mencionados no texto como meta-
modelo de regras adotado e modelo de regras adotado. As consideraes sobre a
linguagem SQL3 que no foram consideradas no modelo proposto e podem ser teis para a
elaborao do repositrio de regras, sero descritas neste captulo.

3.2 META-MODELO DE REGRAS

O meta-modelo de regras adotado neste trabalho (PAVON, 2005) o resultado da

anlise de um conjunto de meta-modelos sugeridos na literatura (HERBST; MYRACH, 1995;
AMGHAR; MEZIANE; FLORY, 2000; TORRICO; TANAKA; MOURA, 2000). Neste
meta-modelo so considerados todos os tipos de regras necessrios para dar suporte s regras
de negcio expressas em linguagem natural, principalmente as regras de derivao, regras
 41

operacionais e regras estmulo-resposta (PAVON; VIANA; CAMPOS, 2006). As regras

conceituais (regras que so representadas por meio de modelos de dados como diagrama de
classe, diagrama entidade-relacionamento, tabelas) e regras de afirmao (representadas por
meio de restries de integridade, como check, domain e assertions) no so representadas
neste meta-modelo, visto que um sistema gerenciador de banco de dados ativo possui suporte
apropriado para a representao destes tipos de regras.
As regras de derivao caracterizam-se por permitir a tomada de decises, e portanto,
so mapeadas para procedimentos, contendo sentenas do tipo if-then-else. As regras
operacionais indicam uma seqncia de operaes que devem ser realizadas com um objetivo
especfico e, por conseguinte, so formadas somente por aes, e as regras estmulo-resposta
correspondem a regras ECA (evento-condio-ao). No nvel de implementao, estas regras
ECA na linguagem SQL3 correspondem aos triggers.
As regras estmulo resposta so definidas por meio de um evento implcito (E), uma
condio (C) (opcional), uma ao obrigatria (A1) e uma opcional (A2). Para as regras que
possuem somente uma ao (A), esta equivalente ao A1. A ao opcional executada
quando a condio avaliada como falsa. Neste grupo, os elementos obrigatrios so o evento
(E) e a ao (A) da regra. Estas regras so classificadas como regras tipo 1 para diferenciar do
outro grupo de tipos de regras, tipo 2, cujo evento definido explicitamente pelo usurio, por
meio da operao Fire. Esta operao foi criada para tratar o disparo de regras de derivao e
operacional, identificadas no modelo de regras adotado
Na Tabela 3.1, so apresentados os tipos de regras e suas correspondentes
representaes no nvel de negcio.

Tabela 3.1 - Tipos de regras em diferentes nveis de abstrao

Tipos de regras no nvel Tipos de regras no nvel Classificao em nvel

de domnio do negcio de especificao de tipos de regra
Estmulo Resposta ECA, EA, ECA1A2 Tipo 1
(evento implcito)
Derivao CA, CA1A2 Tipo 2
(evento explcito)
Operacional A

Como os elementos das regras de derivao e operacional so condio-ao e ao,

respectivamente, houve a necessidade de criar uma operao que fizesse o papel de gatilho,
disparando as regras no momento em que fossem solicitadas. Neste conjunto de regras o nico
 42

elemento obrigatrio a ao (A).

As regras do tipo 1, possuem eventos de banco de dados e os eventos temporais. Os
eventos de banco de dados so classificados segundo as seguintes operaes de banco de
dados:
select, update, insert ou delete sobre uma tabela.
alter, drop, rename de uma tabela.
logon ou logoff
Chamada a um procedimento
Chamada de uma funo

Os eventos temporais podem ser definidos como temporais absolutos ou relativos.

Neste meta-modelo assume-se que os eventos sejam temporais absolutos, ou seja, eventos que
correspondem a um ponto especfico no tempo, da mesma forma como especificado na
linguagem SQL3.
Na Figura 5 apresentam-se os elementos do meta-modelo, para as regras do tipo 1, por
meio de um diagrama entidade-relacionamento.

Disparo (1,N)
implcito Regras Tipo 1
(1,1) (1,1) (1,1)
(1,N)
Evento
(0,N) (0,N)

(0,1)
Condio
(1,1)
Evento Evento (0,N)
Temporal de BD contm Ao_Primria (A1)
(0,1)
(0,N)
contm Ao_Secundria (A2)

Figura 5 - Representao de regras do tipo 1(adaptado de PAVON, 2005)

Uma caracterstica deste tipo 1 de regra que o diferencia das regras do tipo 2 o fato
de que um evento pode disparar uma ou mais regras e que uma regra pode conter mais de um
evento de manipulao de dados. Uma regra do tipo 1 no pode disparar a si mesma, ou seja,
considerando que uma regra deste tipo tenha em sua definio um evento de banco de dados e
da mesma forma, em sua ao contenha uma operao idntica operao de banco de dados,
 43

definida em seu evento, ento o auto disparo no permitido pelo SGBDA.

Na Figura 6 so apresentadas as caractersticas de regras do tipo 2. Estas regras so

constitudas de uma condio (opcional), uma ao primria (A1), obrigatria, e uma ao
secundria (A2), opcional. As regras do tipo 2, so executadas por um evento explcito,
definido pelo usurio. A ao secundria especificada para regras do tipo CA1A2, sendo que
a ao A2 executada quando a condio desta regra for avaliada como falsa. As regras deste
tipo tm uma relao de um para um com o evento que a dispara, assim, uma regra
disparada por um evento e um evento pode disparar somente uma regra. As aes destas
regras podem conter outras regras do mesmo tipo ou regras do tipo 1 e vice-versa. Alm
disso, permitido o uso de procedimentos e funes.

Disparo (1,1)
explcito Regras Tipo 2
(1,1) (1,1) (1,1)
(1,1)
Evento definido pelo
usurio

(0,N) (0,N)
(0,1)
Condio
(1,1)
contm
(0,N)
Ao Primria (A1)
(0,1)
(0,N)
contm Ao Secundria (A2)

Figura 6 - Representao de regras do tipo 2 (adaptado de PAVON, 2005).

Na Figura 7 ilustrado o meta-modelo de regras contendo os tipos 1 e 2 de regras,

unificados em um nico meta-modelo. Nele, a entidade Entidade representa o conjunto de
tabelas do banco de dados sobre as quais a regra atua, e a entidade Regra representa os tipos
1 e 2, de regras.
As regras que esto diretamente relacionadas com as entidades do banco de dados, so
representadas pelo relacionamento referencia. Desta forma, cada regra pode referenciar uma
ou mais tabelas do banco de dados, seja no evento ou na ao da regra, como tambm existem
regras que no tm vnculo com estas entidades. O fato de que exista regra sem vnculo com
objetos do banco de dados, torna a regra independente dos dados, o que por sua vez, eleva as
 44

regras ao mesmo nvel dos dados, no banco de dados.

Toda regra est associada, obrigatoriamente, definio de um evento, seja ele, um
evento de banco de dados, um evento temporal ou um evento definido pelo usurio. Porm,
somente os eventos de banco de dados podem disparar mais de uma regra. Com relao aos
eventos temporais, estes so especificados somente na clusula evento, das regras do tipo 1.

idRegra
formada_por
Entidade (0,N) referencia
ordem

(0,N) (0,N)
(0,N)
Disparo
(1,N)
Regras
(1,1) (1,1) (1,1)
(1,N)
Evento
(0,N) (0,N)

(0,1)

Evento Condio
(1,1)
de BD (0,N)
Evento contm Ao_Primria (A1)
Temporal (0,1)
(0,N)
contm Ao_Secundria (A2)
Evento definido
pelo usurio

Figura 7 - Meta-modelo de regras (PAVON, 2005)

Regras podem conter, em sua ao, operaes de banco de dados que podem
desencadear o disparo de outras regras, promovendo um encadeamento de regras. Um
encadeamento de regras implica que uma regra pode disparar outras regras automaticamente,
sem a interveno do usurio. Para isto, basta que um evento, sob a forma de uma operao de
banco de dados ou a operao Fire seja detectado pelo SGBDA. O relacionamento contm
indica a possibilidade de existncia destas operaes de banco de dados ou Fire, na ao,
primria ou secundria, da regra. Quando um destes eventos dispara um conjunto de regras,
simultaneamente, necessria uma poltica para identificar qual destas regras deve ser
disparada em primeiro lugar. Doravante, este conjunto de regras ser chamado de conjunto de
regras simultneas. No final desta seo apresentado um exemplo sobre este conjunto de
regras simultneas.
 45

Uma regra pode ser formada por outras regras e este relacionamento representado
pela associao formada_por, cujos atributos so: idRegra e ordem. Estes atributos so
utilizados para armazenar informaes sobre a ordem de precedncia das regras, conforme
exemplificado na regra R1 da Figura 8, na qual a regra R1 do tipo estmulo-resposta e as
demais regras, R2, R3 e R4 so do tipo operacional ou derivao..

Regra R1
Fire R2
Fire R3
Fire R4

Figura 8 Regra R1 composta de trs regras: R2, R3 e R4

As regras R2, R3 e R4 so disparadas por meio da operao Fire. No meta-modelo,

esta operao representada pelo evento definido pelo usurio.
Considerando que a regra R1 foi disparada por meio de um evento de banco de dados,
ento, a seqncia de execuo das regras internas regra R1, ocorre de cima para baixo,
primeiro a regra R2, logo a seguir R3, e depois a regra R4. Esta ordem define a seqncia de
execuo das regras, independente do momento no tempo (timestamp) em que estas regras
foram criadas. Esta caracterstica uma contribuio do modelo adotado e que foi estendida,
em relao ao tratamento de regras que so disparadas ao mesmo tempo, da linguagem SQL3.
Na linguagem SQL3, a definio de data e hora de criao da regra dita a ordem de
execuo das regras simultneas. Caracterizar o disparo de uma regra em funo da data e
hora torna o processo de manuteno destas regras difcil. Esta dificuldade est relacionada
com dois aspectos. O primeiro aspecto, o fato de que no existem operaes de gerncia que
auxiliem na manuteno das regras. As operaes oferecidas so utilizadas para criar ou
eliminar uma regra. O segundo aspecto, est relacionado com a data de criao da regra, pois,
toda vez que uma regra criada no dicionrio de dados, ela recebe uma nova data e hora,
geradas pelo sistema. Como no existem operaes para alterao de uma regra ou parte dela,
necessrio recriar a regra, e desta forma, ela deve ser novamente e integralmente processada.
Por exemplo, considerando o contexto da regra R6, ilustrado na Figura 9, e que esta
possui uma operao de banco de dados definida em sua ao, e supondo que o negcio exija
 46

que as regras R7, R8, e R9 sejam disparadas em funo desta operao de banco de dados,
ento, as regras sero disparadas simultaneamente. Portanto, a regra que contiver a data mais
antiga ser dispara em primeiro lugar, e assim sucessivamente. Levando em conta que a regra
R8 seja modificada, isto , criada novamente, e novamente compilada, como parte do
requisito de negcio, ento, esta regra, recebe um novo valor de tempo de criao, fazendo
com que a ordem de execuo das regras varie (R8, R7 e R9), levando a uma seqncia de
execuo diferente em comparao com a seqncia anterior (R7, R8 e R9). A ordem de
execuo assume que a datahora mais antiga executada em primeiro lugar.
Esta nova seqncia deixa de corresponder ao contexto do negcio, para o qual foi
especificado. Quando o conjunto de regras tende a ser grande, a manuteno da lgica do
negcio torna-se uma tarefa mais complexa de ser mantida. Uma forma de minimizar esta
complexidade empregar a operao Fire. O uso desta operao facilita a gerncia destas
regras, porque elas so executadas, explicitamente, pela operao de disparo, desvinculando o
timestamp de sua execuo e, como conseqncia, facilitando a manuteno destas regras. Ao
mesmo tempo possvel especificar contextos de negcios diferentes, para um mesmo
conjunto de regras. Por exemplo, seja o contexto da regra R5 a seguir:

E Regra R7
Regra R6
C Regra R5
E
A Fire R3
C
Fire R2
A E Regra R8
Fire R4
A

E Regra R9
b)
A

a)

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: R3, R2 e R4

A regra R5 contm as mesmas regras especificadas na regra R1, da Figura 8, porm a

ordem de execuo destas regras diferente, apresentando contextos de negcio diferentes. A
 47

diferena da regra R5 para a regra R6 est em que a regra R5 contm um conjunto de regras
(R3, R2 e R4) e a R6 contm um evento que dispara um conjunto de regras (regras
simultneas) nos quais seus eventos so iguais ao evento definido na ao de R6.

3.3 MODELO DE REGRAS ADOTADO

Um modelo de regras compreende o modelo de definio e o modelo de execuo de

regras. O modelo de definio representado pela sintaxe da regra, e define os elementos que
so utilizados para a especificao das regras, do tipo 1 e do tipo 2, e o modelo de execuo
determina as caractersticas comportamentais destes tipos de regras.
O modelo de regras utilizado neste trabalho uma proposta de extenso e adaptao
do modelo de regras sugerido pela linguagem SQL3 para a definio e execuo de regras em
um sistema de banco de dados ativos. Este modelo de regras apresenta dois tipos de operaes
de gerncia de regras: Uma operao para a definio da regra e uma operao para disparar
explicitamente uma regra do tipo 2. A operao para eliminao de regras sugerida pelo
modelo adotado a mesma apresentada pela linguagem SQL3.

3.3.1 Modelo de Definio de Regras

A sintaxe para a representao da definio de regras do modelo adotado emprega os

conceitos sugeridos pela linguagem SQL3 e adequa novos conceitos aos j existentes, de tal
forma que seu poder de expressividade melhora, em funo dos novos elementos que so
adicionados sua estrutura, e que so representados pelas regras do tipo 1 e do tipo 2. Neste
sentido, a expressividade da linguagem SQL3 para a definio de regras um subconjunto
dos tipos de regras oferecidos pelas regras do tipo 1, visto que a SQL3 sugere os tipos de
regras ECA e EA e os tipos 1, de regras, so representados por regras ECA, EA e ECA1A2.
 48

Na Tabela 3.2 apresentada a sintaxe da linguagem SQL3 e de sua extenso, definidas

segundo a notao da meta-linguagem BNF. O que est em negrito representa a extenso
linguagem de regras SQL3.
Tabela 3.2 - Linguagem de regras SQL3 e sua Extenso (VIANA; PAVON; ALMEIDA, 2006)

SQL3 SQL3 Estendida

CREATE RULE <nome-trigger> CREATE RULE <nome da regra>

{before|after} <evento> [<tempo de ativao> <evento>]
[REFERENCING <variveis de transio>] [REFERENCING <variveis-transio>]
[for each {row|statement}] [<granularidade>]
[when (<condio>)] [WHEN <condio>]
<ao> DO <ao primria>
[ELSEDO <ao secundria>]

A linguagem de regras, quando processada pelo SGBDA, resulta em um conjunto de

objetos que so armazenados no dicionrio de regras. Estes objetos so os elementos das
regras e podem ser manipulados por meio de operaes de gerncia de regras e, como
conseqncia, podem ser reutilizados. Esta reutilizao est diretamente relacionada com o
repositrio de regras utilizado para armazenar os elementos das regras (objetos).

No captulo 4, apresentado um repositrio de regras para armazenar os tipos de

regras sugeridos na extenso proposta e os respectivos elementos destas regras.

A seguir, apresentada a linguagem de regras utilizada neste trabalho, seguido de uma

explicao de seus elementos.

A sintaxe para definir uma regra a seguinte:

<Definio-da-Regra> ::= CREATE RULE <nome da regra>

[<tempo de ativao> <evento>]
[REFERENCING <variveis-transio>]
[<granularidade>]
[WHEN <condio>]
DO <ao primria>
[ELSEDO <ao secundria>]
 49

<tempo de ativao> ::= ON | BEFORE | AFTER

<evento> ::= <evento-BD> |

<evento-temporal>

<evento-BD> ::= <evento-dados> |

<evento-meta-dados> |
<evento-sistema> |
<evento-procedimento>
<evento-dados> ::= <operao-dados> [{OR <operao-dados>}...]
ON <nome da tabela>

<operao-dados> ::= SELECT [OF <lista de colunas>}]

| INSERT
| DELETE
| UPDATE [OF <lista de colunas> ]

<lista de colunas> ::= <nome da coluna>

[{<vrgula> <nome da coluna>}...]

<evento-meta-dados> ::= <operao-meta-dados>

[{OR <operao-meta-dados>}...]
TABLE <nome da tabela>
<operao-meta-dados> ::= ALTER |
DROP |
RENAME

<evento-sistema> ::= LOGON | LOGOFF

[{OR LOGON | LOGOFF}]
OF <nome do usurio>

<evento-procedimento> :: = PROCEDURE <nome do procedimento> |

FUNCTION <nome da funo>

[{OR PROCEDURE
<nome do procedimento> |
FUNCTION <nome da funo>}...]
 50

<evento-temporal> ::= (<hora>)<data>

<hora> ::= hh:mm:ss

<data> ::= dd/mm/yyyy | */*/*

<variveis de transio> ::=

OLD [ROW] [AS] <nome alternativo>
| NEW [ROW] [AS] <nome alternativo>
| OLD TABLE [AS] <nome alternativo >
| NEW TABLE [AS] <nome alternativo >
| CURRENT [ROW] [AS] <nome alternativo>

<granularidade> ::= FOR EACH {ROW | STATEMENT}

<condio> ::= [<operador unrio>] <elemento-condio>

[{<conector> <elemento-condio>}]...

<operador unrio> ::= NOT

<conector> ::= AND | OR

<elemento-condio> ::= <condio-SQL3> |
<predicado-varivel-de-transio>|

<ao primria> ::= <sentena procedimental SQL> |

CALL <nome do procedimento> |
<bloco SQL> |
<operao-regra> <nome da regra>

<ao secundria> ::= <sentena procedimental SQL> |

CALL <nome do procedimento> |
<bloco SQL> |
<operao-regra> <nome da regra>

<bloco SQL> ::= BEGIN

{<sentena procedimental SQL>
<ponto e vrgula> }...
END;
 51

A linguagem de regras adotada possui quatro componentes, a saber: um evento, uma

condio, duas aes (primria e secundria). O nico elemento obrigatrio a ao primria,
os demais so opcionais.

a) Criao de Regras
Toda regra armazenada no dicionrio de dados nica. Seu nome definido por meio
da expresso:

CREATE RULE <nome da regra>.

b) Eventos
A regra, uma vez que definida e armazenada no banco de dados, disparada em
funo da ocorrncia de seu evento. Este evento tem associado um tempo de ativao que por
sua vez atribudo apenas s regras do tipo 1, visto que, elas exigem a especificao deste
evento em sua definio.
Na linguagem SQL3, este tempo de ativao definido pelas palavras-chave BEFORE
e AFTER, e so utilizadas conforme o tipo de evento definido em sua sintaxe. O uso de
BEFORE ocorre quando desejado que a regra seja disparada antes da execuo da operao
definida como evento. O uso de AFTER significa que a regra foi disparada depois da
execuo da operao definida como evento. Na linguagem proposta, foi adicionada uma
outra palavra-chave ON, em funo da adio de eventos de sistemas (evento-sistema). Estes
eventos fazem parte dos eventos de banco de dados (evento-BD) e so:

<evento> ::= <evento-BD> | <evento-temporal>

Os eventos de banco de dados referem-se s operaes de banco de dados que podem

ser executadas por um sistema de banco de dados ativos. A proposta inclui quatro grupos de
eventos de banco de dados:
 52

<evento-BD> ::= <evento-dados> |

<evento-meta-dados> |
<evento-procedimento>
<evento-sistema> |

Os <evento-dados> so compostos pelas operaes de banco de dados insert, update,

delete e select. Esta ltima operao foi adicionada em funo da necessidade de que
aplicaes de software necessitam monitorar o acesso s informaes armazenadas no banco
de dados. Desta forma ela elevada ao mesmo nvel de importncia das demais operaes
utilizadas para a manipulao das informaes do banco de dados.
Os <evento-meta-dados> so compostos por operaes definidas na linguagem de
definio de dados da SQL3, utilizadas para definir os meta-dados. As operaes que so
possveis de serem especificadas na definio de uma regra so: alter, drop e rename. Estas
operaes devem ser utilizadas em conjunto com a definio de uma tabela de banco de
dados.
Os <evento-procedimento> so compostos por procedimentos ou funes.
Os eventos <evento-dados>, <evento-meta-dados> e <evento-procedimento>
podem utilizar o tempo de ativao BEFORE ou AFTER.
Por exemplo:
CREATE RULE Pedido_Emprestimo
AFTER UPDATE OR INSERT ON PEDIDO
FOR EACH ROW
DO

No exemplo anterior, as operaes de banco de dados UPDATE OR INSERT indicam

que a regra contm dois eventos especificados pelo conector OR. A regra que contm esta
definio pode ser disparada por um destes dois eventos. O tempo de ativao AFTER
implica que a regra disparada depois que o evento da regra for instanciado (ocorrer). As
regras com os eventos <evento-dados> podem combinar as operaes insert, update ou
delete, por meio do conector OR, formando um evento composto. Para os eventos <evento-
meta-dados>, possvel combinar os eventos alter, drop ou rename e por ltimo, os eventos
<evento-procedimento> podem combinar os eventos relacionados a procedimentos e
funes. No permitido combinar eventos de grupos diferentes, ou seja, um <evento-
 53

dados> com <evento-meta-dados> ou evento <evento-procedimento>.

Os <evento-sistema> so compostos pelas operaes logon ou logoff. A operao
logon utilizada para conectar um usurio ao banco de dados e a operao logoff a operao
inversa, para desconect-lo do banco de dados. Estas operaes so utilizadas com o tempo de
ativao ON, e podem ser combinadas por meio do operador lgico OR, conforme o seguinte
exemplo:

CREATE RULE Conexao_BD

ON LOGON OR LOGOFF OF usuario
DO

O <evento-temporal> representa uma instncia na linha do tempo, definida por uma

hora e/ou data. O tempo definido para este evento absoluto. A granularidade da hora
definida em termos de horas, minutos e segundos. A granularidade da data definida em dia,
ms e ano. Portanto o tempo absoluto constitudo de dia, ms, ano, hora, minuto e segundo,
conforme apresentado a seguir:

<evento-temporal> ::= (<hora>)<data>

<hora> ::= hh:mm:ss

<data> ::= dd/mm/yyyy | */*/*

Na sintaxe da especificao de evento temporal, o * (asterisco) representa qualquer

hora dentro da data estipulada pelo usurio. O tempo de ativao de uma regra com evento
temporal definido por meio da clusula ON, conforme o seguinte exemplo:

CREATE RULE Auditoria_BD

ON (10:00:00) 10/10/2004 ON Empregado
DO
BEGIN
CALL PROCEDURE Verificar_Status_Funcionario( )
END;

A regra Auditoria_BD foi especificada para disparar s 10 horas da manh do dia 10

de outubro de 2004. A presena da data no obrigatria e sua ausncia indica que a regra
disparada todos os dias. Desta forma possvel definir um evento temporal somente com a
 54

hora em que a regra deve ser disparada.

c) Variveis de Transio
A especificao de um evento pode incluir tambm o conceito de variveis de
transio e granularidade da regra. As variveis de transio so utilizadas para se ter acesso
aos valores de cada tupla que so afetados pelas operaes de manipulao de dados. As
variveis de transio utilizadas pela linguagem SQL3 so old e new. A varivel old
utilizada para ter acesso ao valor prvio do atributo antes de sua atualizao no registro. A
varivel new utilizada para o acesso ao valor futuro do atributo antes de sua atualizao no
registro. A extenso proposta sugere uma nova varivel de transio, definida como current.
Esta varivel de transio utilizada para se ter acesso ao valor atual do atributo. A varivel
current utilizada em conjunto com a operao de seleo, e as demais variveis de transio
(new, old) so utilizadas com as operaes de atualizao, excluso e insero. O exemplo a
seguir utiliza a varivel de transio current.

CREATE RULE Acesso_Sal_Chefe

BEFORE SELECT OF salario ON EMP
FOR EACH ROW
WHEN (current.cargo = Chefe)
DO .

Neste exemplo, a regra "Acesso_Sal_Chefe" tem acesso aos salrios dos empregados,
e na condio desta regra verificado se este salrio pertence aos empregados que tenham o
cargo de chefe.
A granularidade da regra especificada para as operaes de manipulao de dados.
Esta granularidade indica o grau de relacionamento entre a ocorrncia do evento e o disparo
da regra. Na linguagem de regras proposta, assume-se a mesma granularidade sugerida pela
linguagem SQL3.

d) Condies
A condio da regra especificada pela clusula WHEN, dentro da sintaxe geral de
definio de regra. A condio um componente opcional para os dois padres de regras. A
avaliao da condio, pelo SGBDA, expressa por um valor booleano (verdadeiro ou falso),
 55

independente da quantidade de elementos associados por operadores AND ou OR. Nesta

linguagem estendida, foi sugerido o uso do operador unrio NOT s informaes propostas
pela linguagem SQL3. O <elemento-condio> um predicado na linguagem SQL3, que
pode ser uma condio na linguagem SQL3 ou um predicado utilizando variveis de
transio, sendo que neste caso, exige-se que o evento seja um <evento-dados>.
A seguir, um apresentado um exemplo de condio envolvendo um predicado com
variveis de transio. Neste exemplo, especificamente na condio da regra (When), a
varivel de transio new est associada ao atributo qtd_estoque. A ao executada se e
somente se a nova quantidade em estoque for menor ou igual ao estoque mnimo.

CREATE RULE Controle_estoque

AFTER INSERT OR UPDATE OF qtd_estoque ON PRODUTO
FOR EACH ROW
WHEN new.qtd_estoque <= estoque_min
DO ...

e) Aes
Na linguagem de regras proposta, existem dois tipos de aes, a saber: uma ao
primria, obrigatria e uma ao secundria, condicionada existncia da clusula WHEN da
regra, ou seja, uma regra que no possui condio, ento possui somente uma ao, definida
como primria. Isto vlido para os dois padres de regras. A ao primria definida pela
clusula DO e a ao secundria pela clusula ELSEDO.
A ao primria executada toda vez que a condio avaliada como verdadeira, caso
contrrio, executa-se a ao secundria. Para os tipos de regras constitudos de uma nica
ao, ou ao primria, o resultado da avaliao da condio, quando falso, no muda o
estado do banco de dados.
Os elementos permitidos na especificao de uma ao so: uma sentena
procedimental SQL, uma chamada a procedimentos, um bloco SQL ou uma operao de
gerencia de regra.
 56

Seja a seguinte regra:

CREATE RULE Regra_Estoque

AFTER UPDATE ON PRODUTO
FOR EACH ROW
DO CALL PROCEDURE Verificar_Quant_min(new.cod_prod, new.quant );

A regra acima, do tipo EA (evento-ao) disparada toda vez que uma operao de
banco de dados update sobre a tabela PRODUTO ocorrer. Aps a atualizao do produto no
estoque, disparada a sua ao, cuja finalidade chamar o procedimento
Verificar_Quant_min. Este procedimento recebe como parmetro o cdigo do produto e sua
quantidade. Quando o estoque menor ou igual ao estoque mnimo, alguma ao deve ser
tomada.
No exemplo a seguir, apresenta-se a regra R33 (PAVON, 2005), do tipo CAA2.

CREATE RULE R33 /* Avaliar valor solicitado de emprstimo*/

WHEN ( (SELECT valor_max_empr FROM PEDIDO_EMPRESTIMO
WHERE codcli = :V_Pedido_Empr.codcli) >=
:V_Pedido_Empr.valorsolicitado)
DO
BEGIN
UPDATE EMPRESTIMO
SET aprovado = S /* indica que o emprstimo foi aprovado */
WHERE codcli = : :V_Pedido_Empr.codcli
AND codpedido = :V_Pedido_Empr.codpedido;
FIRE R34;
CALL PROCEDURE Comunica_Cliente(S);
END;
ELSEDO
BEGIN
UPDATE PEDIDO_EMPRESTIMO
SET aprovado = N /* indica que o emprstimo no foi aprovado */
WHERE codcli = :V_Pedido_Empr.codcli
AND codpedido = :V_Pedido_Empr.codpedido;
CALL PROCEDURE Comunica_Cliente(N);
END;
 57

Esta regra apresenta uma condio, uma ao primria e uma ao secundria. Na

condio da regra avaliado o seguinte predicado: O valor mximo definido para
emprstimo maior que o valor mximo solicitado pelo cliente. Caso este predicado seja
verdadeiro, ento se dispara a ao primria, especificada pela palavra-chave DO, caso
contrrio, disparada a ao secundria, definida por ELSEDO.
Nesta sentena, a ao primria contm uma outra regra, conforme apresentado na
Figura 9, definida por R34, cuja finalidade definir o valor de emprstimo a ser dado para o
cliente. Este valor proporcional ao perfil apresentado por ele, um dos atributos deste perfil
o seu salrio.
Quando uma ou mais regras so definidas a partir de outra regra (regras embutidas em
outras regras), considera-se que as regras embutidas herdam os valores ou variveis definidas
na regra hospedeira. Este procedimento minimiza a repetio de variveis e facilita a escrita
das regras.

3.3.2 Modelo de Execuo de Regras

O modelo de execuo de regras determina as caractersticas comportamentais das

regras, ou seja, as caractersticas envolvidas durante o processamento de regras. Estas
caractersticas esto associadas ao seu modus operandi, que incluem o seu disparo
(instanciao do evento) e sua execuo (avaliao da condio execuo da ao), o
mecanismo adotado para a resoluo de conflito de regras, modo de acoplamento e
granularidade de processamento.

3.3.2.1 Disparo e Execuo de Regras

Os disparos das regras do tipo 1 e do tipo 2 apresentam caractersticas diferentes, no

primeiro caso, as regras so disparadas conforme a especificao do evento em sua sintaxe,
enquanto que no segundo caso, as regras so disparadas por um evento definido pelo usurio,
por meio da operao Fire. Na Figura 10 so apresentadas as etapas do processamento de
regras do tipo 1 e do tipo 2.
 58

Deteco do evento Modelo de execuo

de regras da
linguagem SQL3

Evento definido Disparo das regras

Evento de BD que contm a
pelo usurio Verificar
especificao desse
o tipo de
evento.
evento
(Tipo 1)

Evento temporal
Execuo das regras
Disparo da regra Disparo das regras com tempo de
indicada no que contm a ativao
evento.definido pelo especificao desse
usurio (Tipo 2) evento.
(Tipo 1)
Execuo da operao
de BD, definida como
evento
Execuo das regras.
(Tipo 2) Execuo da regra.
(Tipo 1)
Execuo das regras
com tempo de
ativao AFTER.

Figura 10 - Etapas do processamento de regras do t ipo 1 e t ipo 2 (PAVON, 2005).

Uma vez que a regra disparada, ou seja, o evento detectado e devidamente

identificado, a regra correspondente executada, da seguinte forma, se o evento do tipo
definido pelo usurio, executa-se uma regra do tipo 2, se o evento temporal ou evento de
banco de dados, executa-se uma regra do tipo 1. O passo seguinte a avaliao da condio e,
de acordo com o resultado desta avaliao, executa-se a ao correspondente. Regras que no
possuem a clusula condio executam diretamente sua ao.
Uma vez que as regras do tipo 2 foram disparadas, ento elas so imediatamente
executadas. Neste tipo, somente uma regra disparada por vez (ex. Fire R3). As regras do
tipo 2 apresentam um outro tipo de comportamento, que difere do sugerido pela linguagem
SQL3, e que pode ser usado para o tratamento de um conjunto de regras que apresente disparo
simultneo. No item 3.3.2.2 discutida a resoluo de disparos simultneos de regras, entre
outros mecanismos associados ao modelo de execuo de regras.
Quando se trata de eventos de banco de dados, as regras que contm o evento
identificado pelo SGBDA so disparadas. Em se tratando do disparo de apenas uma regra,
ento sua execuo ocorre de forma imediata, caso contrrio, o SGBDA agrupa as regras em
dois conjuntos, as regras com tempo de ativao BEFORE e com tempo de ativao AFTER
 59

(FORTIER, 1999; ISO/IEC 9075-2, 1999; TURKER; GERTZ, 2001);. Logo a seguir, so
executadas as regras do primeiro grupo, seguindo o critrio de antiguidade destas regras, dado
pelo seu tempo de criao, ou seja, data e hora em que foram criadas. Logo a seguir,
executam-se as regras do segundo grupo, seguindo o mesmo critrio apresentado
anteriormente. Esta caracterstica de resoluo de conflito implementada nos SGBDA
comerciais, como Oracle e PostgreSQL.

3.3.2.2 Outros Mecanismos Associados ao Modus Operandi

Na Figura 11 ilustrado uma regra definida como R6, do tipo EA, que possui em sua
ao uma operao de insero sobre uma tabela do banco de dados. Esta operao a mesma
operao definida no evento das regras R7, R8 e R9.

CREATE RULE R6 CREATE RULE R7

AFTER INSERT ON EMP
AFTER UPDATE quant ON Produto
...
DO
BEGIN CREATE RULE R8
AFTER INSERT ON EMP; AFTER INSERT ON EMP
END; ...
CREATE RULE R9
AFTER INSERT ON EMP
a) ...
CREATE RULE R6
AFTER UPDATE quant ON Produto
DO
BEGIN
Fire R7;
Fire R8;
Fire R9;

b) END;

Figura 11 Regra R1 especificada de duas formas diferentes.

As regras R7, R8 e R9, so especificadas por meio de um evento AFTER INSERT ON

 60

EMP (alnea a). Quando este evento ocorre, todas estas regras so disparadas ao mesmo
tempo. A execuo destas regras, dentro do conjunto de regras disparadas simultaneamente,
depende do critrio de execuo adotado. Para a linguagem SQL3 a referncia o timestamp.
Para solucionar este problema, estas trs regras so transformadas em uma nica regra
R6, na qual a ao desta regra o conjunto formado pelas trs regras. Desta forma, mantm-se
a mesma caracterstica do evento e tempo de ativao para todo o conjunto, e define-se uma
ordem de execuo para elas, de forma explcita, independente do tempo de criao das
mesmas. Esta mesma soluo pode ser aplicada para eventos temporais.
Alm do conflito de regras, existem outros conceitos sobre o processamento de regras,
a saber: o acoplamento de regras e a granularidade de regras. Quando uma regra disparada, e
o seu evento instanciado, ento, imediatamente a sua condio avaliada e logo que esta
atividade terminada, inicia-se a execuo da ao da regra. A este comportamento, em que
as atividades de instanciao do evento e avaliao da condio (quando existir) ocorre de
forma imediata, ou at mesmo, entre a avaliao da condio e execuo da regra tambm
ocorre de forma imediata, d-se o nome de acoplamento imediato. O acoplamento de regras
pode ocorrer para os pares de componentes da regra (evento-condio e condio-ao). Na
linguagem SQL3, tambm sugerido este tipo de modo de acoplamento.
A granularidade de processamento das regras pode ocorrer em nvel de instncia ou
em nvel de conjunto. Quando em nvel de instncia, a condio verificada para cada
registro da tabela afetada e a ao disparada para cada registro. Quando em nvel de
conjunto, a condio verificada uma nica vez e a ao disparada uma nica vez, tambm.
A linguagem SQL3 assume as duas propostas anteriores.

3.4 OPERAO SOBRE REGRAS

As operaes de gerncia sugeridas pelo modelo de regras adotado so cinco, a saber:

Fire, Habilitar, Desabilitar, Excluir e Criar uma regra. Toda regra criada em um banco de
dados est em um de dois estados, habilitado ou desabilitado. Uma regra est no estado
desabilitado quando est armazenada no dicionrio de dados e no pode ser disparada, sob
hiptese alguma. O estado habilitado o inverso do estado desabilitado. Estas operaes
podem ser definidas tanto na ao primria quanto na ao secundria. Uma regra pode
habilitar ou desabilitar outras regras, porm uma regra no pode habilitar ou desabilitar a si
mesma.
 61

As sintaxes destas duas operaes de gerncia so apresentadas a seguir:

ENABLE <nome da regra>;

DISABLE <nome da regra>;

Estas duas operaes so mantidas na abordagem adotada, em conjunto com a

operao de gerncia, definida como Fire. Esta operao tem a funo de disparar
explicitamente uma regra que especificada pelo tipo 2. Portanto, esta operao o evento
que dispara as regras CA, CA1A2 e A.
A sintaxe desta operao definida a seguir:

FIRE <nome da regra>;

Esta operao pode ser definida na ao primria ou ao secundria de uma regra.

Quando se necessita executar uma regra definida no repositrio de dados explicitamente,
necessrio que se disponha de um mecanismo que o faa explicitamente, por meio de uma
ferramenta que seja construda com este propsito, de auxiliar a execuo destas operaes de
gerncia. Quando a regra possui eventos definidos por meio de operaes de banco de dados,
esto existe uma dependncia da ocorrncia (implcita) destas operaes, para que a regra seja
disparada, ou por meio de uma ferramenta, provida pelo prprio SGBDA, executar alguma
consulta de banco de dados que gere o disparo da regra.
O modelo de definio de regras adotado, promove novas variaes de tipos de regras,
porm faltam definir operaes de gerncia que auxiliem a manuteno e evoluo do
dicionrio de dados.
Na linguagem adotada, so identificadas cinco operaes de gerncia, sendo que a
contribuio da linguagem SQL3 nestas operaes se limitam a criao e excluso de regras.
Nesta proposta adotada, foi importante incorporar outras operaes, porm estas
consideraes devem e so analisadas com mais detalhes em captulos posteriores.
 62

3.5 CONCLUSES

O modelo de definio de regras adotado, melhorou a expressividade da definio de

regras da linguagem SQL3 e, alm disso, ampliou o conjunto de operaes de gerncia de
regras, com outras operaes. Estas operaes de gerncia formam uma linguagem de
gerncia de regras. Esta linguagem de gerncia no flexvel o suficiente para propiciar ao
usurio a manuteno necessria das regras armazenadas no banco de dados. Esta
flexibilidade est relacionada com a facilidade em alterar as regras ou manipular suas partes
constituintes, da mesma forma em que seja necessrio eliminar regras ou parte delas. Por
exemplo, regras ECA1A2 poderiam ser modificadas para regras ECA, por meio de uma
operao de alterao da regra, na qual a ao secundria seria eliminada. O objetivo desta
manuteno propiciar a evoluo do dicionrio de regras, de tal forma que ele tenha mais
uma opo para o armazenamento das regras de negcio de sua aplicao, alm da prpria
aplicao.
Para que seja possvel prover esta linguagem de gerncia de regras com outras
operaes de gerncia, necessrio analisar e definir um ambiente que suporte estas
operaes, o que no sugerido no modelo adotado. Este ambiente compreende um
repositrio de regras especfico para armazenar as regras, desvinculando-as do dicionrio de
regras. Esta separao entre regras e dados deve ser analisada e discutida. Alm do
repositrio, necessrio analisar e especificar as necessidades de meta-regras para manter a
consistncia das regras armazenadas neste repositrio de regras.
Este trabalho tem como objetivo estender as operaes de gerncia de regras e,
portanto, propor um repositrio de regras para armazenar os tipos 1 e 2, de regras, oferecidos
na linguagem adotada, neste trabalho. Este repositrio de regras a base para que sejam
sugeridas as operaes de gerncia de regras. No captulo seguinte analisado e proposto este
repositrio.
 63

CAPITULO 4. PROPOSTA DE UM REPOSITRIO DE REGRAS

4.1 INTRODUO

Um repositrio de regras consiste de um conjunto de estruturas inter-relacionadas para

armazenar regras e um conjunto de meta-regras para que garantam a consistncia das regras
armazenadas nesse repositrio. O principal objetivo de um repositrio de regras dar suporte
ao armazenamento das regras, considerando os diferentes tipos descritos no meta-modelo,
como tambm as informaes semnticas associadas a cada regra, com a finalidade de
facilitar a gerncia de regras. Neste captulo, apresenta-se o repositrio de regras e os
mecanismos utilizados para manter a consistncia das regras nele armazenadas. Estes
mecanismos so meta-regras que atuam quando regras so manipuladas por meio de
operaes de gerncia, sendo que estas meta-regras cumprem o mesmo papel que as restries
de dados, gerenciadas pelo SGBDA para manter a consistncia dos dados, no dicionrio de
dados.
Inicialmente so identificados os elementos das regras que sero especificados no
repositrio. Estes elementos so definidos a partir dos tipos de regras, de seus inter-
relacionamentos e relacionamento destes tipos com os objetos do banco de dados.
Uma vez que os elementos estejam identificados, so apresentados os elementos da
Linguagem SQL3 que so reutilizados nesta proposta. O conjunto resultante tomado como
referncia para a elaborao do repositrio de regras aqui proposto.
A seguir especifica-se o repositrio de regras. Este repositrio representado por meio
de um diagrama entidade-relacionamento, nas quais as entidades correspondem s partes
constituintes das regras e tambm objetos do dicionrio de dados, tais como tabelas e
atributos. Os relacionamentos entre entidades representam o relacionamento das regras. Um
exemplo deste relacionamento a associao entre a ao de uma regra com o evento de outra
regra, por meio de operaes de manipulao de dados. A associao representa uma ou mais
operaes de banco de dados que so especificadas na ao da regra e que tambm
especificada no elemento evento de outras regras, para o mesmo repositrio de regras.
Por ltimo, so definidas regras que representam os dois tipos de regras adotados neste
trabalho. Estas regras so armazenadas no repositrio de regras obedecendo a determinados
critrios de insero. Estes critrios so apoiados pelas meta-regras, cujo resultado final, aps
 64

a insero de todas as regras, um repositrio de regras consistente.

4.2 SNTESE DAS CARACTERSTICAS DAS REGRAS

As caractersticas das regras relevantes para este trabalho e que so consideradas para
elaborao do repositrio de regras so identificadas por meio de uma anlise realizada sobre
o modelo de regras adotado, e que foi descrito no captulo anterior. Estas caractersticas so
agrupadas em funo de cada elemento da regra. Portanto, so apresentadas as caractersticas
relativas ao evento, depois as caractersticas associadas condio e finalmente as
caractersticas relacionadas ao da regra. Alm das caractersticas associadas a cada
elemento da regra, possvel identificar caractersticas que dizem respeito regra, tais como
o tempo de ativao e as variveis de transio.
Alm de apresentar tais caractersticas, tambm so identificadas as caractersticas
pertencentes ao modelo de regras da linguagem SQL3, com a finalidade de ilustrar a evoluo
destas caractersticas no modelo de regras adotado. Esta evoluo importante porque a
proposta deste trabalho dar seguimento a esta evoluo, propondo uma extenso da
linguagem de gerncia de regras. O ponto de partida o modelo de definio de regras
adotado. Para evidenciar as diferenas apresentadas pela linguagem SQL3 e a proposta
adotada, realiza-se uma anlise pontual de cada elemento da regra e, para cada um deles, so
tomadas como base as caractersticas da linguagem SQL3 e, em negrito, so adicionadas as
caractersticas da linguagem proposta. Portanto, o que est em negrito so extenses propostas
sobre a linguagem SQL3. Por exemplo, o tempo de ativao (BEFORE e AFTER) est
presente em ambas as linguagens e no deve aparece em negrito, porm o tempo de ativao
(ON), que foi sugerido na linguagem proposta, apresentado em negrito.

Regra
A regra constituda das seguintes informaes:

9 Tempo de ativao:{ON, BEFORE ou AFTER}

A linguagem SQL3 apresenta dois tipos de tempo de ativao (BEFORE ou
AFTER). Estes elementos so utilizados em conjunto com os eventos
permitidos pela linguagem SQL3, que so as operaes de manipulao de
dados, insert, update e delete. O primeiro tempo de ativao BEFORE
 65

utilizado com as trs operaes de manipulao de dados e o segundo tempo de

ativao, AFTER, utilizado somente com as operaes insert, update.
Na extenso adotada, sugere-se a adio de outro tipo de tempo de ativao,
ON, em virtude de outros tipos de eventos que so sugeridos. Este tempo de
ativao utilizado para as operaes select e para eventos de tempo. A seguir
apresentado um exemplo de criao de regras adotando o tempo de ativao
ON.

CREATE RULE Auditoria

ON SELECT OF salario ON PROF
FOR EACH ROW
WHEN (current.status = Doutor)
DO

9 Variveis de Transio {current, Old, New}

As variveis de transio old e new so utilizadas para acessar os dados antigos e
novos que so afetados pelos eventos, cujas operaes so Insert, Delete e Update. Com a
adio da operao select, adicionada a varivel de transio current, cuja finalidade
acessar os dados atuais que so consultados, conforme apresentado na regra anterior.
Alm destas informaes, variveis de transio e tempo de ativao, uma regra
possui tambm outros atributos, a saber: um identificador nico para a regra, data de
criao, status e definio da regra. Estes atributos so comuns s duas linguagens e so
apresentados e analisados na seo 4.3, que trata sobre a descrio do repositrio de
regras.

Evento
O metamodelo de regras, especificado para as regras do tipo 1, apresentado na Figura
6, considera que um evento, obrigatoriamente, deve estar associado a uma ou mais regras, e
que uma regra deve, obrigatoriamente, estar associada a um ou mais eventos. Esta
obrigatoriedade justificada pelo fato de que, na linguagem SQL3, o evento definido em
conjunto com a definio da regra. Este evento representa uma operao de banco de dados,
seja ela uma operao de update ou delete, insert ou select. Da mesma forma, incluem-se
 66

tambm as operaes logon, logoff, e eventos de tempo, caracterizados por uma ocorrncia
absoluta em um determinado momento no tempo, definido pela data/hora do sistema.
Um evento pode ser definido em funo de outros eventos, de tal forma que, em uma
mesma sentena possvel descrever mais de uma operao, seja ela de banco de dados e
meta-dados. A este evento, composto por dois ou mais eventos, definido como evento
composto. Este conceito foi apresentado e discutido amplamente em Chakravarthy e Mishra
(1993), Chakravarthy et al. (1994), Geppert, Gatziu e Dittrich (1995), Paton (1998) e Vaduva
(1999).
As regras do tipo 2, cuja base constituda pelos elementos condio e ao, conforme
apresentado na Figura 6, so disparadas em funo da operao Fire. Esta operao tem a
responsabilidade de disparar a regra, a ela associada, sempre que for solicitada. A diferena
entre esta operao, Fire, e as demais operaes, utilizadas no evento de banco de dados,
que, para o primeiro caso, a regra disparada por meio de uma declarao explcita, e para o
segundo caso, o disparo ocorre de forma implcita, ou seja, existe disparo toda vez que duas
situaes acontecerem, a primeira situao a ocorrncia do evento, em uma regra hospedeira
(regra que possui a definio da operao de banco de dados em uma de suas aes), e a
segunda situao a existncia de uma regra que possua um evento especificado por meio da
mesma operao. Neste sentido, o SGBDA deve contar com um mecanismo que detecte a
presena do evento e dispare as regras que possuam o evento ocorrido.

9 So considerados nas operaes de gerncia da linguagem proposta, descritas no

captulo 5, os eventos de banco de dados e eventos temporais, apresentados a
seguir.
Os eventos de banco de dados possuem um conjunto de operaes que so
subdivididas em trs grupos: operaes de banco de dados, operaes sobre meta-
dados e operaes de sistema.

Eventos de Banco de Dados:

- Operaes de Banco de Dados {Select, Insert, Delete e Update};
- Operaes Meta-Dados {Alter, Drop, Rename};
- Operaes Sistema {Logon, Logoff};

Eventos Temporais
 67

- Hora/Data { dd/mm/aaaa ::hh:mm:ss}

Condio
A condio composta de sentenas SQL conectadas por operadores {AND e OR}.
Alm dos operadores apresentados, considerado tambm o operador unrio {NOT}. Este
operador utilizado como forma de negao da sentena que definida na condio.

Ao
A ao pode conter sentenas procedimentais SQL que incluem operaes de banco de
dados, operaes para chamadas a procedimentos (CALL (nome_procedimentos) e funes,
operaes para chamadas a outras regras (Fire (nome_regra)) e blocos SQL).

Relacionamento entre regras

O relacionamento entre regras ocorre de duas maneiras. A primeira, em funo da
ocorrncia de eventos, e a segunda em funo da definio declarativa de uma operao
de gerncia. No primeiro caso, necessrio que exista a definio de uma operao de
banco de dados, na ao de uma regra, chamada de regra hospedeira. Da mesma forma,
necessrio que uma ou mais regras contenha em seu evento, o mesmo tipo de operao
sobre o mesmo objeto de banco de dados, outrora definido na ao da regra hospedeira.
Quando a operao, especificada na ao da regra hospedeira, for solicitada, seja por uma
aplicao ou explicitamente por um usurio, esta regra desencadeia o disparo de outras
regras. Para que este encadeamento ocorra, necessrio que o SGBDA identifique, para
cada operao de banco de dados executada, quais so as regras que possuem um evento
com estas caractersticas.
Este encadeamento pode ocorrer com um conjunto constitudo de um nmero elevado de
regras, produzindo mudanas no estado do banco de dados, que nem sempre so
desejveis. Considerando que no existem erros associados execuo deste
encadeamento de regras, ento fica difcil identificar o resultado de um processo de
negcios de resultados que so anmalos, sem um devido rastreamento da execuo destas
regras.
O segundo caso difere do primeiro, no sentido de que a regra hospedeira contm a
definio explicita da chamada a outra regra, por meio de uma operao definida pelo
 68

usurio. Neste segundo caso, o encadeamento tambm esta presente.

Composio de Regras
A composio de regras ocorre quando uma regra contm, explicitamente, outras regras.
A composio de regras tem a finalidade de solucionar o problema gerado pelo disparo de
mltiplas regras, disparadas pelo mesmo evento. Quando regras so disparadas pelo
mesmo evento, gera-se um conjunto de regras que deve ser executado em funo de algum
critrio. A linguagem SQL3 sugere, como critrio para a ordem de execuo destas regras,
o uso da funo data/hora de criao delas. O conceito de composio de regras sugere o
uso de uma operao de gerncia, Fire, para disparar as regras definidas sob o mesmo
evento. Desta forma o resultado uma execuo controlada de regras.

Considerando as informaes apresentadas anteriormente, possvel identificar um

conjunto de caractersticas que estendem o modelo de regras da linguagem SQL3.
A linguagem de regras adotada utiliza informaes sobre os objetos que esto
armazenados no dicionrio de dados do banco de dados, da mesma forma que a linguagem
SQL3. A diferena reside no fato de que o modelo de regras adotado possui mais recursos que
a linguagem SQL3, e como conseqncia, exige mais informaes do dicionrio de dados.
Estes objetos so meta-dados que armazenam informaes sobre tabelas, atributos, usurios,
procedimentos e funes.

4.3 DESCRIO DO REPOSITRIO DE REGRAS

O repositrio de regras formado por um conjunto de estruturas que so utilizadas

para armazenar as informaes pertinentes s regras. O modelo de dados adotado para
projetar o repositrio de regras o modelo relacional e como conseqncia, todas as
estruturas so tabelas.

4.3.1 Tabela Regra

A principal tabela, denominada REGRA, armazena as caractersticas de todos os tipos

de regras definidas no meta-modelo de regras. Estas caractersticas so:
 69

Cdigo da regra ou Id_regra

Nome da regra
Autor
Data de criao
Status {habilitado / desabilitado}
Tipo de regra {ECA, EA, ECAA, CA, CAA, A}
Tempo de ativao da regra {on, before, after}
Granularidade da regra {row, statement}

O <cdigo da regra> ou <Id_regra> utilizado para identificar uma nica regra dentre
todas as regras armazenadas na tabela Regras. O <nome da regra> contm uma descrio que
representa a regra no contexto do negcio, do ponto de vista do usurio. Este nome,
geralmente, o mesmo utilizado quando de sua especificao no negcio. O <autor> uma
informao adicional que pode ser utilizada para armazenar informaes sobre a pessoa
responsvel pela regra, seja este, quem a especificou no sistema ou o idealizador da mesma. A
<data de criao> o momento, no tempo, em que esta regra criada, ou seja, seu
dia/ms/ano::hora/min/seg. O <status> representa um estado, habilitada ou desabilitada. O
status habilitado representa um estado em que a regra pode se encontrar no repositrio de
regras, ou seja, este status habilita a regra ser disparada, uma vez que ocorra um evento. O
status Desabilitado representa um estado em que a regra pode assumir em um dado
momento, no repositrio de regras, sendo que este status implica que a regra no pode ser
disparada, a no ser que ela mude de status.
O <tipo de regra> identifica o tipo de regra que foi armazenada no repositrio. Este
atributo recebe somente valores que pertencem ao seu domnio, definido pelos valores
(ECAA, ECA; EA; CAA; CA; A). O <tempo de ativao> representa o momento em que a
regra ser executada, em funo da ocorrncia do evento. O atributo <tempo_ativ> recebe
somente valores definidos em seu domnio. Neste caso, os valores so (ON, BEFORE,
AFTER). Quando no for especificado na definio da regra, o tempo de ativao atribudo
 70

de forma automtica. O termo automtico implica que o sistema gerenciador assume um valor
previamente definido como valor padro. A granularidade da regra representa o nmero de
vezes que a regra disparada em funo do evento. Os valores pertencentes ao domnio do
atributo <granularidade> so (ROW, STATEMENT).

4.3.2 Tabela Evento

As informaes sobre os elementos da regra so armazenadas nas seguintes tabelas:

tabela EVENTO, tabela CONDIO e tabela AO. A relao entre evento e regra ocorre
da seguinte maneira: cada regra pode ser disparada por um ou mais eventos e um evento pode
disparar uma ou mais regras. As informaes que devem ser armazenadas sobre este
relacionamento constam na tabela REGRA-EVENTO (Regra_ev). Os atributos da tabela
EVENTO so.

Cdigo do evento ou Id_evento

Tipo_evento (banco de dados, temporal, sistema, meta-dados, evento_usr)
Operao {insert, update, delete, select, data_hora, logon, logoff, alter, drop,
rename, fire}
Identificao de usurio ou Id_usuario
Identificao de data_hora ou Id_data_hora
Identificao da tabela ou Id_tabela

O <cdigo do evento> armazena a identificao de cada evento. Cada evento nico.

O evento criado em funo da criao de uma regra. Quando uma regra criada, o SGBDA
identifica o evento que foi definido na especificao da regra e armazena este evento na tabela
EVENTO. O <tipo_evento> contm informaes sobre o tipo de evento que armazenado na
tabela EVENTO, este pode ser do tipo evento de banco de dados (insert, update, delete,
select), evento temporal (data_hora), evento de sistema (logon, logoff), evento meta-dados
(alter, drop,rename) e evento definido pelo usurio (Fire). O <Id_usuario> identifica o
cdigo do usurio definido em conjunto com o evento de sistema (exemplo: logon Maria). O
<Id_data_hora> identifica a data e/ou hora definida para o evento temporal. Este dois
atributos, Id_usuario e Id_data_hora, podem receber valores null`s.
O atributo <Id_tabela> identifica a tabela que sofre a ao da operao definida no
 71

evento.

4.3.3 Tabela Regra-Evento

A tabela REGRA-EVENTO, representada pelo relacionamento Regra_Ev, existe

em funo do tipo de associao entre a ocorrncia de regra e ocorrncia de evento. Uma
regra est relacionada, obrigatoriamente, com um ou mais eventos, portanto para cada regra,
definida na tabela REGRA, deve existir o seu correspondente valor na tabela REGRA-
EVENTO. Um evento definido na tabela EVENTO, necessariamente deve existir na tabela
REGRA-EVENTO e pode estar associada a mais de uma regra. Para as regras que possuem
evento composto, para cada evento existente na regra, existe uma ocorrncia na tabela
EVENTO. A regra que possui correlao com este evento composto, apresenta tantas
ocorrncias na tabela REGRA-EVENTO, quanto o nmero de eventos definidos no evento
composto. Os atributos da tabela REGRA-EVENTO so:

Cdigo da regra ou Id_regra

Cdigo do evento ou Id_evento

Estes dois atributos, em conjunto, definem uma ocorrncia de uma regra com seu
respectivo evento. Na Figura 12 apresentado o diagrama entidade-relacionamento referente
ao relacionamento entre a entidade REGRA e a entidade EVENTO.

(1,N)
regra_ev
EVENTO

(1,N)

REGRA

Figura 12 - Representao do relacionamento entre regra e evento.

 72

4.3.4 Tabela Condio

Os elementos condio e ao da regra tm sua existncia condicionada existncia

da regra. A condio e a ao devem ser definidas a partir da definio da regra. Na Figura 13
apresentado o diagrama entidade-relacionamento referente ao relacionamento da regra com
os elementos condio e ao.

(1,N) REGRA
(1,N)

inclui inclui

(0,1) (1,2)

CONDIO AO

Figura 13 - Representao do relacionamento entre regra e os demais elementos

condio e ao.

As informaes que so consideradas na tabela CONDIO so:

Cdigo da regra ou Id_regra

Cdigo da condio ou Id_ condio
Definio da condio
Data_ltima_modificao

O <cdigo da regra> um atributo que possui os mesmos valores anteriormente

definidos para a identificao de uma regra, na tabela REGRA. O <cdigo da condio>
identifica uma nica condio. Ambos os atributos identificam a relao de pertinncia da
condio na regra. Quando uma regra disparada, possvel identificar qual a condio que
deve ser avaliada. Uma condio pode ser reutilizada e ser atribuda a uma outra regra. Esta
tarefa possvel por meio de uma operao de gerncia que realize esta atribuio. Existem
situaes que devem ser analisadas, pelo analista, com a finalidade de garantir a correta
 73

atribuio de uma condio a uma regra. A primeira situao ocorre quando a regra apresenta
variveis de transio, e estas variveis devem ser especificadas na condio, sejam elas,
variveis locais ou globais. A segunda situao ocorre quando da atribuio de uma condio,
que possui variveis locais ou globais, a uma regra. Em ambos os casos, fica a cargo do
analista efetuar os devidos ajustes. A Data_ltima_modificao um atributo utilizado para
armazenar informaes sobre o momento em que a condio foi modificada por alguma
operao de gerncia associada modificao da condio da regra.

4.3.5 Tabela Ao

Uma regra possui obrigatoriamente uma ao, porm existe a possibilidade de que
uma outra ao seja definida em funo do tipo de regra especificado. A ao primria
obrigatria, a outra ao, definida como ao secundria opcional. Ambas as aes so
armazenadas na tabela AO. Os atributos desta tabela, AO, so:

Cdigo da regra ou Id_regra

Cdigo da ao ou Id_ ao
Categoria {primaria, secundaria}
Data_ultima_modif
Definio da ao
O <cdigo da regra> um atributo que contm os mesmos valores armazenados no
atributo <cdigo da regra> da tabela REGRA. O <cdigo da ao> representa uma ao.
Ambos os atributos so utilizados para identificar a relao de pertinncia da ao na regra.
Nesta tabela, o cdigo da regra pode ser repetido, no mximo, duas vezes. Uma vez para cada
tipo de ao. A <categoria> identifica o tipo de ao que foi armazenada. Neste sentido uma
ao pode receber o valor secundria, se e somente se, a mesma regra est associada a uma
ao cuja categoria primria. A <definio da ao> contm a especificao da ao da
regra, ou seja, o corpo da ao, composto de cdigo. Uma ao pode ser eliminada ou
adicionada, em funo do tipo de regra especificado na tabela, por meio de operaes de
gerncia. funo do analista garantir que as variveis de transio e variveis locais e
globais sejam adequadas ao contexto da regra, sempre que for necessrio. A
Data_ltima_modificao um atributo utilizado para armazenar informaes sobre o
momento em que a ao foi modificada por alguma operao de gerncia, associada
modificao da ao da regra
 74

Na ao de uma regra, possvel definir operaes de banco de dados, chamadas a

procedimentos e execuo de regras por meio da operao Fire.

4.3.6 Tabela Ao_EV

Regras que apresentam operaes de banco de dados podem disparar outras regras,
sempre que exista alguma regra cuja operao definida no evento a mesma operao
definida na ao da regra. Identificar a existncia destas operaes na ao, por meio de
operaes de gerncia, um meio eficaz de identificar encadeamentos de regras.
Existem dois tipos de encadeamentos: encadeamentos controlados e encadeamentos
no controlados. Os primeiros ocorrem em funo da especificao do negcio, na qual o
analista define um conjunto de regras de negcio por meio de um encadeamento. O resultado
final da execuo deste conjunto de regras encadeadas um resultado significativo e
observvel.
O segundo tipo de encadeamento ocorre em funo de regras que so armazenadas no
repositrio de regras e que so disparadas em funo da execuo de outras regras, este
encadeamento no est associado aos processos de negcio, mas sim a execues que
ocorrem, em funo de outros processos. Este tipo de encadeamento de regras pode levar
execuo infinita de um conjunto de regras. Para identificar o encadeamento de regras,
criada uma tabela AO_EV que armazena as operaes de banco de dados existentes na
ao de uma regra e tambm armazena a identificao dos eventos que possuem estas mesmas
operaes.
Na Figura 14 ilustrada a tabela AO_EV

(0,N) (0,N)
AO Ao_Ev EVENTO

Figura 14 - Representao do relacionamento entre ao e evento.

Os atributos da tabela AO_EV so:

Cdigo da regra ou Id_regra

 75

Cdigo da ao ou Id_ ao
Id_evento

O <cdigo da regra> e o <cdigo da ao> identificam uma ocorrncia do elemento

ao. Nesta ao, existem operaes de banco de dados que podem gerar um encadeamento
de regras. Estas operaes fazem parte de eventos que so definidos na tabela EVENTO. Da
mesma forma, este encadeamento pode ocorrer por meio da operao Fire. A tabela
AO_EV tem a finalidade de rastrear este encadeamento, identificando quais so as regras
que podem disparar outras regras, porm o disparo destas regras ocorre em funo de algum
critrio previamente estabelecido. O critrio adotado o mesmo apresentado pela linguagem
SQL3.
A linguagem SQL3 sugere uma operao de gerncia para criar e para eliminar regras,
porm, na prtica, os SGDBA comerciais implementam a operao de criao ou atualizao
de regras em um mesmo comando, a saber: create or replace trigger. Quando este comando
utilizado para atualizar regras, gerada uma nova data de criao para a regra modificada, e
como conseqncia, estabelece uma nova seqncia de execuo de regras. Para o analista, o
fato de modificar a ordem de execuo, pode comprometer a execuo de um processo de
negcio.

4.3.7 Tabela Regra_Composio

O elemento ao de uma regra pode conter operaes do tipo Fire. Esta operao
tem a funo de executar, explicitamente, regras do tipo condio-ao. Isto implica que
uma ao pode ser composta por uma ou mais definies explcitas de disparo de regras. O
fato de que, uma operao de disparo definida explicitamente sobre uma regra, na ao de
uma regra, considera-se, ento, que existe uma composio de regras. Assim, uma regra pode
ser composta por mais de uma regra e cada uma destas regras pode fazer parte de mais de uma
ao de uma regra. Alm disso, cada composio, por sua vez, pode conter outras regras do
tipo 1.
Este encadeamento de regras materializado por meio de uma tabela que contm
atributos que identificam as regras e suas respectivas prioridades de execuo. Esta tabela
definida como REGRA_COMP ou REGRA-COMPOSIO. Os atributos desta tabela so:
Cdigo da regra ou Id_regra
 76

Cdigo da ao ou Id_ ao
Composta_de
Prioridade

O atributo <cdigo da regra> identifica a existncia de uma regra. O <cdigo da ao>

identifica a ao, primria ou secundria, que possui um conjunto de regras. O atributo
<composta_de> armazena todas as regras do tipo condio-ao definidas na ao. Estes trs
atributos <cdigo da regra> <cdigo da ao> e <composta-de> identificam uma nica
ocorrncia de regra definida na ao de uma regra. O atributo <prioridade> armazena a
prioridade de execuo das regras. Estes valores de prioridade so nmeros inteiros
ascendentes (1,2,3...,n) que representam a ordem de execuo da regra. Quanto menor o
nmero, maior o grau de prioridade. Quando ocorre a modificao de uma das regras
definidas na ao, por meio de uma operao de gerncia, a ordem de execuo de regras
acompanha esta mudana. Na Figura 15 apresentado o diagrama entidade-relacionamento
para a representao da relao entre a tabela REGRA e a tabela REGRA-COMPOSIO.

Regra_composio

est contida contm

(0,N) (0,N)

REGRA

Figura 15 - Representao entidade-relacionamento de uma composio de regras.

A caracterstica principal do modelo de regras adotado que as regras so

representadas de forma independente do conjunto de tabelas do banco de dados. Esta
independncia implica em que uma regra pode ser dotada de um evento que no esteja
relacionado com os objetos de banco de dados, como tabelas e colunas. De forma oposta, na
linguagem SQL3, uma regra, ao ser especificada, deve, obrigatoriamente, estar associada a
alguma tabela do banco de dados, haja vista pelo tipo de evento de banco de dados permitido
(insert, update ou delete).
Quando a especificao do evento de uma regra contempla a existncia de um meta-
dado, ento necessrio que se verifique a existncia deste meta-dado, no dicionrio de
dados, antes de armazenar a regra no repositrio de regras. A seguir apresentada a
 77

associao entre os elementos da regra: evento, condio e ao com os objetos do banco de

dados.

4.3.8 Tabelas Usurio_Sistema, Coluna_Sistema e Tabela_Sistema

A tabela EVENTO est associada com as tabelas COLUNA_SISTEMA,

TABELA_SISTEMA e USUARIO_SISTEMA que fazem parte do dicionrio de dados. A
tabela COLUNA_SISTEMA representa as colunas da tabelas que podem ser definidas em
um evento, quando o evento for um evento-dado. O relacionamento EV_COL entre a tabela
COLUNA_SISTEMA e a tabela EVENTO ocorre por meio do relacionamento
REGRA_EV. Este relacionamento contm informaes sobre as colunas utilizadas no evento
de uma regra. A TABELA_SISTEMA representa as tabelas do banco de dados, que tambm
podem ser utilizadas no evento-dados, relativas ao conjunto de eventos de banco de dados,
conforme descrito no item 3.3.1. A tabela USUARIO_SISTEMA armazena informaes
sobre os usurios do banco de dados e estes dados so utilizados no evento sistema.
A associao entre o evento e as tabelas do sistema (coluna, tabela e usurio) do tipo
no obrigatria, por esta razo possvel definir um evento-temporal ou evento-sistema de
forma que se mantenha a independncia de dados. Na Figura 16 so apresentadas as
associaes entre o evento e os demais objetos do banco de dados. A entidade regra_ev uma
entidade associativa (HEUSER, 2004). Sendo regra_ev uma entidade, esta pode ser associada
a COLUNA_SISTEMA, por meio do relacionamento ev_col.
 78

Coluna_Sistema
(0,N) (1,N)

ev_col

tem

(0,N)

(1,N)
regra_ev (0,N)
EVENTO referncia

(0,N)

(0,1) (1,1)

Tabela_Sistema
REGRA

referncia

(0,1)

Usuario_Sistema

Figura 16 - Diagrama entidade-relacionamento da associao entre o evento e os demais objetos do

banco de dados.

Os elementos da tabela EV_COL so:

Cdigo do evento ou Id_evento

Cdigo da coluna ou Id_coluna
Esta tabela, EV_COL, armazena as informaes sobre as colunas utilizadas no evento.
Um evento pode fazer referncia a uma tabela e cada tabela pode ser referenciada por mais de
um evento.
O elemento condio e o elemento ao tambm utilizam as informaes contidas na
tabela TABELA_SISTEMA. Na Figura 17 so apresentados os relacionamentos pertinentes
ao e condio com TABELA_SISTEMA.
 79

Tabela_Sistema

(0, N) (0, N)

(0,N)
ao_tab
AO

(0,N)
CONDIO condio_tab

Figura 17 - Diagrama entidade-relacionamento da associao entre a TABELA_SISTEMA e as

tabelas condio e a ao.

A tabela AO_TAB armazena informaes sobre as tabela utilizadas na ao da

regra. Seus atributos so:

Cdigo do regra ou Id_regra

Cdigo da ao ou Id_ao
Cdigo da tabela ou Id_tabela

A tabela CONDIO_TAB armazena informaes sobre as tabelas que so

utilizadas na condio da regra. Os elementos desta tabela so:

Cdigo do regra ou Id_regra

Cdigo da ao ou Id_condio
Cdigo da tabela ou Id_tabela

O repositrio de regras compreende um conjunto de tabelas e um conjunto de meta-

regras. As tabelas so utilizadas para armazenar as regras, seus inter-relacionamentos e
composio de regras. As meta-regras tm a funo de garantir a consistncia do repositrio
de regras. Elas so exigidas sempre que so utilizadas operaes de gerncia para definir,
excluir ou alteradas as regras.
Para validar o repositrio de regras proposto, primeiro so apresentadas as estruturas
 80

deste repositrio e logo a seguir, um conjunto de meta-regras, utilizadas para manter sua
consistncia. As tabelas do repositrio de regras so apresentadas a seguir. So descritas
apenas as tabelas relevantes para o estudo de validao do repositrio, no esquema lgico a
seguir, visto que as demais tabelas que fazem parte do dicionrio de dados, do banco de
dados, no fazem parte da anlise deste trabalho. A chave primria est sublinhada e chaves
estrangeiras esto em itlico
REGRA (Id_regra, nome, autor, dataHora_criao, status, tipo_regra,
tempo_ativao, granularidade)
EVENTO (Id_evento, operao, tipo_evento, Id_usuario, datahora, Id_tabela)
REGRA_EVENTO (Id_Regra, Id_evento)
EV_COL (Id_Regra, Id_evento, Id_coluna)
CONDIO (Id_regra, Id_condio, definio_condio, data_ultima_modif)
CONDIO_TAB (Id_regra, Id_condio, Id_tabela)
AO (Id_regra, Id_ao, categoria, data_ultima_modif, definio_ao)
AO_TAB (Id_regra, Id_ao, Id_tabela)
AO_EV (Id_regra, Id_ao, Id_evento)
REGRA_COMP (Id_regra, Id_ao, composta_de, prioridade)

O esquema lgico descreve os atributos associados ao conjunto de tabelas do

repositrio de regras. A rea delimitada pelo pontilhado, na Figura 18, representa o conjunto
de tabelas que fazem parte do repositrio de regras. As tabelas COLUNA_SISTEMA,
TABELA_SISTEMA e USURIO_SISTEMA fazem parte do dicionrio de dados.
 81

Coluna_Sistema
(0,N) (1,N)

ev_col

tem

(0,N)

(1,N)
regra_ev (0,N)
EVENTO referncia

(0,N) (0,N)

contm (1,N) (0,1) (1,1)

(0,N)
REGRA_COMP ao_ev Tabela_Sistema
(0,N) REGRA
est contida (0,N) (0,N)
(1,1) (1,1) referncia

inclui inclui
(0,1)

Usuario_Sistema
(0,1) (1,2)
(0,N)
CONDIO AO
(0,N) (0,N)
ao_tab

condio_tab

Figura 18 - Diagrama entidade-relacionamento relativo ao repositrio de regras.

4.4 META-REGRAS DO DICIONRIO DE REGRAS

Um repositrio de regras contm um conjunto de estruturas para armazenar regras, ao

serem inseridas neste repositrio, a execuo das regras seguem uma ordem previamente
definida. Esta ordem descrita por meio de um conjunto de atividades apresentadas no
diagrama de atividades ilustradas na Figura 19.
 82

Inserir dados na
tabela REGRA

No Inserir dados na
Existe evento
cadastrado? tabela EVENTO

Sim

Inserir dados em
REGRA_EV

Evento Sim Inserir dados na

possui tabela EV_COL
atributo?

No

Regra possui Sim Inserir dados na

CONDIO? tabela CONDIO

No

No
CONDIO Sim Inserir dados na
Inserir dados na possui tabelas? tabela
tabela AO CONDIO TAB

Sim
AO possui Inserir dados na Inserir dados em
operao BD? tabela AO_TAB AO_EV

No

Sim
AO possui Inserir dados na
FIRE? tabela
REGRA COMP

No

Figura 19 - Diagrama de atividade para a insero de uma regra no repositrio de regras.

 83

Todas as atividades de incluso de uma regra no repositrio de regras partem do

mesmo ponto inicial, a insero de dados na tabela REGRA. Portanto, para a insero das
informaes referentes aos elementos de uma regra, no repositrio de regras, primeiro insere-
se dados na tabela REGRA, logo a seguir, verifica-se a existncia do evento, pertencente
regra, na tabela EVENTO. Caso o evento a ser inserido, j exista na tabela EVENTO,
armazena-se apenas a associao deste evento ocorrncia da nova regra, caso contrrio,
armazenam-se tanto dados de evento quanto dados da associao deste evento com a regra.
O passo seguinte verificar se o evento inserido possui atributos, caso afirmativo,
inserem-se os dados na tabela EV_COL, caso negativo, verifica-se a existncia do elemento
condio na regra.
Quando a regra possui condio, os dados sobre a condio so armazenados na tabela
CONDIO, e se por ventura, esta ao referncia tabelas do banco de dados, armazena-se
esta referncia na tabela CONDIO_TAB.
A atividade seguinte inserir dados sobre a ao da regra. Verifica-se a existncia de
tabelas na ao da regra, caso exista, inserir dados na tabela AO_TAB, e logo a seguir na
tabela AO_EV. Os dados desta tabela so conseqncia da anlise realizada sobre dois
elementos da regra, a ao e o evento. Quando operaes de banco de dados definidas na ao
da regra so iguais as operaes de banco de dados definidas no evento, ento, armazena-se
esta informao da tabela AO_EV.
Por ltimo, verifica-se a existncia da operao Fire na ao da regra. Caso existam,
armazenam-se as regras que so disparadas por esta operao.
As meta-regras relacionadas com as atividades apresentadas no diagrama de
atividades, da Figura 19, so apresentadas na Tabela 4.1. Nesta tabela so descritas sete meta-
regras, que auxiliam a manter a consistncia do repositrio de regras. Estas meta-regras sero
utilizadas pelo SGBDA toda vez que uma regra inserida no repositrio de regras.
 84

Tabela 4.1 Meta-regras associadas ao repositrio de regras

Regra Descrio

Meta-Regra 1 As Regras do tipo CA, CAA e A no devem possuir granularidade nem

tempo de ativao
Meta-Regra 2 As Regras do tipo CA, CAA e A no podem utilizar variveis de
transio.
Meta-Regra 3 Somente as regras do tipo CA, CAA e A devem ter como evento a
operao Fire

Meta-Regra 4 Somente as regras que tm como evento as operaes UPDATE,

DELETE e/ou INSERT possuem granularidade.

Meta-Regra 5 Somente as regras que possuem o elemento condio podem ter uma
ao secundria.
Meta-Regra 6 Somente as regras que tem por evento a operao SELECT podem
utilizar a varivel de transio CURRENT
Meta-Regra 7 Toda vez que uma regra for disparada por mais de um evento, estes
eventos devem ser do mesmo tipo.

A Meta-Regra 1 responsvel por verificar se o tipo de regra, derivao ou

operacional, a ser inserida na tabela REGRA, possui granularidade e tempo de ativao. Da
mesma forma, a Meta-Regra 2 verifica se estes tipos no possuem variveis de transio. A
Meta-Regra 3 verifica se o evento definido na regra tipo 2, a ser inserida na tabela REGRA
Fire. A Meta-Regra 4 verifica a existncia de granularidade para regras que possuem as
operaes UPDATE, DELETE e/ou INSERT, definidas no evento. A Meta-Regra 5 verifica a
existncia do elemento condio na definio das regras que possuem duas aes, primria e
secundria. A Meta-Regra 6 verifica se a varivel de transio CURRENT compatvel com a
operao de banco de dados definida no evento da regra. A Meta-Regra 7 verifica se os
eventos compostos por mais de uma operao, so do mesmo tipo.

4.5 UM EXEMPLO PRTICO DO USO DO REPOSITRIO

Nesta seo, so apresentadas as tabelas do repositrio de regras, e um exemplo

prtico de insero de regra, neste repositrio. Para isto, utilizada, a ttulo de exemplo, uma
regra cujo evento, composto, tem a finalidade de disparar a regra em caso de uma insero ou
 85

atualizao de uma reserva de equipamento. Esta regra do tipo ECAA e representa a

solicitao de um emprstimo de equipamento para uso em sala de aula. Parte-se da premissa
de que o professor j efetuou uma reserva, e por necessidades de negcio, necessita atualiz-
la. Seja uma solicitao de reserva ou atualizao da mesma, o sistema deve verificar vrias
situaes, que foram traduzidas para regras computacionais e implementadas na regra R12: a
primeira regra verifica se o produto est disponvel, logo depois, na segunda regra, se o
professor est habilitado para realizar o emprstimo, a seguir, na terceira regra, se o professor
obedece aos prazos mnimos para realizar a atualizao e se tudo estiver aprovado, na quarta
regra, verificado o estoque, se este foi atualizado, em funo desta nova reserva. Portanto, a
regra R12 compe-se de outras regras, que implementam estas verificaes. A regra 12
ilustrada na Figura 20. Esta regra do tipo ao (A), e composta de quatro regras disparadas
pela operao Fire.

CREATE RULE R12

DO
BEGIN
FIRE R1; /* VERIFICA A DISPONIBILIDADE DO PRODUTO. */
FIRE R2; /* VERIFICA SE O PROF. ESTA HAB/DESAB. */
FIRE R3; /* vERIFICA PRAZO DE 24 HORAS E DE 15 DIAS */
FIRE R5; /* ATUALIZA ESTOQUE */
END;

Figura 20 Regra composta (R1, R2, R3, R5)

Uma vez que o professor realizou a atualizao da reserva, uma mensagem enviada a
este, sinalizando que est tudo ok. Caso contrrio, o professor notificado de que a reserva
no foi possvel e um histrico gravado deixando constncia de que o professor foi
notificado da inviabilidade de atualizao da atualizao de reserva.
Na Figura 21 ilustrada a regra R8. Esta regra apresenta um conjunto de variveis
globais definidas pelos comandos DECLARE. Estas variveis so utilizadas pela regra R12,
contida na ao primria de R8.
 86

/*variveis globais*/
DECLARE v_codprof numeric;
DECLARE v_codReserva numeric;
DECLARE v_codEquip varchar2(10); /* Estas variveis so utilizadas tambm
DECLARE v_quant numeric; dentro da regra R12 */
DECLARE v_dataRes date;
DECLARE v_horaIni date;
DECLARE v_horaFim date;

CREATE RULE R8
AFTER INSERT OR UPDATE OF cod_reserva ON RESERVA
FOR EACH ROW
WHEN ((SELECT statusRes
FROM RESERVA
WHERE codReserva = :v_codReserva) = 'ATIVA')
DO
BEGIN

FIRE R12; /* VERIFICA se o emprstimo do equip. possvel */

CALL PROCEDURE COMUNICA_CLIENTE('INSERO OU ATUALIZAO _OK_');

END;

ELSEDO
BEGIN

UPDATE CLIENTE
SET notificao = 'Sim'
WHERE codprof = v_codProf;

CALL PROCEDURE COMUNICA_CLIENTE('INSERO OU ATUALIZAO

NO PERMITIDA');

END;

Figura 21 Especificao da Regra R8

Para inserir uma regra no repositrio de regras, segue-se os passos apresentados no

diagrama de atividades, ilustrado na Figura 19.
Considerando as regras R8 e R12, e assumindo que o usurio utiliza uma operao de
gerncia para inseri-las no repositrio de regras, ento a seqncia de insero dos dados das
regras a seguinte: (antes do inicio do processo de insero de uma regra, assume-se que
foram realizadas anlises sinttica e semntica)
Parte-se da premissa que o repositrio de regras est vazio. Os dados da regra R8,
referentes ao nome da regra, tipo de regra, granularidade, tempo de ativao da regra so
 87

inseridos no primeiro registro, da tabela REGRA, ilustrada na Tabela 4.2. Alm destes dados,
o SGBDA identifica o autor da regra, assume o tempo de criao da regra e atribui o status de
habilitada. O mesmo ocorrendo com a regra R12, por meio da qual inserido o segundo
registro. Como a regra R12 to tipo ao, ela no possui granularidade e tempo de ativao.

Tabela 4.2 - Tabela REGRA

ID_ REGRA NOME AUTOR DATA_CRIACAO STATU TIPO_ GRANULA_ TEMPO_
S REGRA RIDADE ATIVAO
R8 Insero ou Joo 4/3/06 11:00 H ECAA ROW AFTER
Atualizao Silva
Reserva

R12 Pr-requisito Joo 4/3/06 10:50 H A

Emprstimo Silva

A prxima etapa a insero dos eventos, das regras R8 e R12. Na Tabela 4.3 so
especificados os atributos da Tabela EVENTO. O atributo <Id_usuario> utilizado para
armazenar a identificao do usurio, definido em um evento do tipo evento sistema. O
atributo <Data_hora> utilizado para armazenar a data e/ou hora para os eventos do tipo
evento temporal. A regra R8 possui dois eventos do tipo evento dados, a saber: update reserva
e insert reserva. Cada evento armazenado em um registro. Alm destes eventos, na ao
primria desta regra, definido um evento do tipo Fire. Este evento armazenado em outro
registro da tabela EVENTO.
Tabela 4.3 - Tabela EVENTO
ID_EVENTO OPERACAO TIPO_EVENTO ID_USUARIO DATA_HORA ID_TABELA
EV_8 UPDATE BANCO DADOS RESERVA
EV_8a INSERT BANCO DADOS RESERVA
EV_12 FIRE DEF_USUARIO

O passo seguinte correlacionar estes eventos a suas respectivas regras, armazenadas

na tabela REGRA. Para tanto, utiliza-se a tabela REGRA-EVENTO, descrita na Tabela 4.4.
Cada registro desta tabela representa uma associao entre uma regra e seu evento. Nesta
tabela representado o relacionamento de uma regra, R8, com mais de um evento, EV_8 e
EV_8a.
 88

Tabela 4.4 Tabela REGRA_EVENTO

ID_REGRA ID_EVENTO
R8 EV_8
R8 EV_8a
R12 EV_12

Quando o evento possui uma operao do tipo update ou select, que envolva atributos,
ento armazena-se estes atributos, associados a esse evento, na tabela EV_COL, conforme
ilustrado na Tabela 4.5.

Tabela 4.5 Tabela EV_COL

ID_REGRA ID_EVENTO ID_COLUNA
R8 EV_8 cod_reserva

Um evento pode estar associado a mais de um atributo e um atributo pode fazer parte
em mais de um evento.

Considere que exista uma outra regra, R99, do tipo EA, cujo evento insert reserva.
Esta regra ao ser armazenada no repositrio de regra, constituiria mais um registro na tabela
REGRA, conforme ilustrado na Tabela 4.6.

Tabela 4.6 - Tabela EVENTO

ID_ REGRA NOME AUTOR DATA_CRIACAO STATU TIPO_ GRANULA_ TEMPO_
S REGRA RIDADE ATIVAO
R8 Insero ou Joo 4/3/06 11:00 H ECAA ROW AFTER
Atualizao Silva
Reserva

R12 Pr-requisito Joo 4/3/06 10:50 H A

Emprstimo Silva

R99 Insero Pedro 4/4/06 12:50 H EA ROW BEFORE

Reserva Silva

Este evento igual a um dos eventos, definidos na tabela EVENTO. Neste caso, por
um lado, no necessrio inserir outro registro na tabela EVENTO, visto que esta informao
j existe, por outro lado, um evento pode fazer referncia a mais de uma regra da mesma
forma que uma regra pode estar associada a mais de um evento. O relacionamento da regra
R99 com o evento inserir reserva, ilustrado na tabela 4.7, por meio da adio de outro
registro.
 89

Tabela 4.7 Tabela REGRA_EVENTO

ID_REGRA ID_EVENTO
R8 EV_8
R8 EV_8a
R12 EV_12
R99 EV_8a

O passo seguinte a insero da condio da regra. Este elemento inserido na tabela

CONDIO, ilustrado na Tabela 4.8

Tabela 4.8 - Tabela CONDIO

ID_REGRA ID_CONDICAO DATA_ULT_MODIF DEF_CONDICAO
R8 COND8 Cdigo

O atributo def_condio possui o cdigo referente condio da regra. Quando a

condio alterada, por meio de uma operao de gerncia, por exemplo, o momento em que
houve esta modificao, portanto a data de modificao, armazenada no atributo
data_ult_modif. Considerando que a condio contenha referncias a tabelas do banco de
dados, ento, estas informaes so armazenadas na tabela CONDIO_TAB, ilustrada na
Tabela 4.9.
Tabela 4.9 - Tabela CONDIO_TAB
ID_REGRA ID_CONDICAO ID_TABELA
R8 COND8 RESERVA

O passo seguinte o armazenamento das informaes referentes ao da regra. Na

tabela 4.10 apresentada a tabela AO, utilizada para armazenar as informaes
referenciadas na ao da regra.
Tabela 4.10 - Tabela AO
ID_REGRA ID_ACAO CATEGORIA DATA_ULT_ DEFINIO_ACAO
MODIF
R8 A8P PRIMARIA Cdigo
R8 A8S SECUNDARIA Cdigo
R12 A12P PRIMARIA Cdigo

A tabela AO possui dois registros relacionados ao da regra R8. Esta regra

possui duas aes, uma primria e uma secundria. A regra R12 possui somente uma ao
 90

primria. O atributo definio_ao possui o cdigo pertinente ao da regra. Quando a ao

da regra possui, em sua especificao, referncias a tabelas do banco de dados, ento, esta
informao armazenada na tabela AO_TAB, conforme ilustrado na tabela 4.11.

Tabela 4.11 - Tabela AO_TAB

ID_REGRA ID_AO ID_TABELA
R8 A8S CLIENTE

Existem situaes nas quais a ao de uma regra contm operaes de banco de dados
que so as mesmas utilizadas em eventos de outras tabelas. Para identificar a ocorrncia
destes casos, estas informaes so armazenadas na tabela AO_EV. A finalidade desta
tabela identificar as regras que podem disparar outras regras, por meio de operaes de
banco de dados. Considere que a regra R99, do tipo EA, possui em sua ao uma operao de
banco de dados do tipo:
UPDATE RESERVA
SET cod_reserva = :v_cod_reserva;

Esta operao a mesma operao definida na ao da regra R8. Portanto a regra R99,
a ser executada, dispara a regra R8. Este rastreamento apresentado na Tabela 4.12.

Tabela 4.12 - Tabela AO_EV

ID_REGRA ID_AO ID_EVENTO
R99 A99P EV8

A ltima etapa o armazenamento da composio de regras. A regra R12 possui em

sua ao um conjunto de regras disparadas pela operao Fire. A composio de regras
armazenada na tabela REGRA_COMP, ilustrada na Tabela 4.13. O atributo prioridade
identifica a prioridade de execuo das regras, disparadas pela operao Fire. Esta prioridade
indica a ordem em que estas regras, R1, R2, R3 e R5, esto dispostas na ao da regra.
Quando duas regras so trocadas de ordem, ento a prioridade trocada automaticamente.
Esta deveria ser uma operao automatizada pelo sistema.
 91

Tabela 4.13 - Tabela REGRA_COMP

ID_REGRA ID_AO COMPOSTA_DE PRIORIDADE
R8 A8P R12 1
R12 A12P R1 1
R12 A12P R2 2
R12 A12P R3 3
R12 A12P R5 4

As regras, R1, R2, R3 e R5, deveriam ser armazenadas da mesma forma que as regras
R8, R12 e R99 nas tabelas do repositrio de regras. Elas no foram armazenadas porque o
objetivo utiliz-las, apenas, como referncia, dentro da regra R12. Portanto, quando o
repositrio estiver em operao, a tabela REGRA deveria conter sete regras, a saber: R1, R2,
R3, R5, R8, R12 e R99.

4.6 CONCLUSES

Neste captulo foram identificadas as caractersticas dos tipos de regras que sero
adotados na linguagem de gerncia de regras. Estas caractersticas formam a base do modelo
de definio de regras adotado. Alm desta base, so reutilizados os conceitos sugeridos na
prpria linguagem SQL3 de regras. Este conjunto de caractersticas resultante, o ponto
inicial para a elaborao de um repositrio de regras. Este repositrio composto de um
conjunto de estruturas inter-relacionadas que so utilizadas para armazenar as regras, o
relacionamento entre elas e o relacionamento delas com os demais objetos do banco de dados,
com tabelas e atributos.
Neste trabalho so apresentadas e discutidas associaes implcitas e explicitas entre
regras. As associaes explcitas ocorrem em funo da composio de regras. Esta
composio representada por meio da declarao da operao Fire na ao da regra. A
associao implcita, representada por meio da definio de operaes de banco de dados,
na ao da regra. Quando estas operaes so executadas pelo SGBDA, elas podem inicializar
um encadeamento de regras. A implementao de regras em um SGBDA, pode levar a
estados no controlveis, como por exemplo, conjunto de regras que se disparam entre si,
gerando um ciclo infinito de execuo de regras. Tambm pode levar a estados inconsistentes
do banco de dados. Esta inconsistncia fruto de execues de conjuntos de regras, no
 92

desejveis do ponto de vista do negcio, que foram executadas implicitamente, e no

representam os processos de negcio desejados. Nos SGBDAs comerciais, existe um
tratamento, pouco eficiente, para deter este ciclo de execuo de regras, por meio de um corte
abrupto na execuo do ciclo de execuo. Neste repositrio, este problema tratado por
meio de uma tabela que armazena o relacionamento entre regras, seja este relacionamento
implcito ou explcito. Desta forma, este relacionamento contm a as informaes necessrias
para rastrear encadeamentos de regras.
Considerando que regras so compostas de vrios elementos, ento a alterao destes
elementos pode gerar inconsistncias no repositrio de regras. Surge ento a necessidade de
elaborar um conjunto de meta-regras, cuja finalidade verificar se as regras a serem alteradas
ou excludas obedecem aos critrios definidas pelas meta-regras. No captulo seguinte so
sugeridas, descritas e exemplificadas outras operaes de gerncia, alm das operaes
apresentadas pela linguagem adotada neste trabalho, com a finalidade de prover meios para
que o usurio tenha condies de alterar as regras e tambm as suas partes.
 93

CAPITULO 5. OPERAES DE GERNCIA DE REGRAS

5.1 INTRODUO

Uma linguagem de gerncia de regras composta de operaes para a definio,

excluso e alterao de regras. A linguagem de Definio de regras adotada, define uma
operao para a criao de regras.
Neste trabalho so apresentadas operaes sobre regras. Estas operaes estendem a
linguagem de regras adotada e definem um novo conjunto de operaes que caracterizam a
linguagem de gerncia de regras. Esta linguagem de gerncia tem por base o repositrio de
regras. As operaes da linguagem de gerncia incidem sobre uma regra ou parte desta, a fim
de alter-la, consult-la, elimin-la, habilit-la ou desabilit-la.
As alteraes das regras, sem os devidos mecanismos que garantam que tais alteraes
mantenham a consistncia do repositrio de regras, tal como se encontrava antes de inicializar
tais modificaes, pode levar este repositrio a um estado inconsistente. Estes mecanismos
so meta-regras cuja finalidade garantir a consistncia do repositrio de regras. Neste
trabalho, so elaboradas e analisadas meta-regras para dar suporte gerncia de regras. Cada
operao de gerncia acompanhada de sua devida discusso, e quando necessrio apresenta-
se as meta-regras associada ao emprego da respectiva operao, e um exemplo ilustrativo.

5.2 PROPOSTA DE UMA LINGUAGEM DE GERNCIA DE REGRAS

Uma Linguagem de Gerncia de Regras (LGR) composta de um conjunto de

operaes que incidem sobre uma ou mais regras, de um repositrio de regras. A linguagem
SQL3 possui um conjunto de operaes de gerncia voltado para a definio e excluso de
regras, porm ainda no possui suporte adequado para a manipulao de regras. Isto se deve a
que as regras so armazenadas no repositrio de dados e faltam estruturas adequadas neste
repositrio para armazenar, independentemente, os elementos das regras. Estas estruturas
incluem tabelas e mecanismos para auxiliar as operaes de gerncia sobre os elementos
destas regras, como as meta-regras. Atualmente, na linguagem SQL3 e nos SGBDAs
(comerciais), as informaes sobre os elementos do trigger, a saber: evento, condio e ao
so armazenados em uma nica tabela, e os demais objetos do banco de dados, tais como
tabelas e atributos, utilizados pelo trigger, so armazenados em tabelas diferentes.
 94

Segundo a viso da linguagem SQL3, o dicionrio de dados compe-se de estruturas

para armazenar dados e regras. O repositrio de regras proposto, tem um conjunto de
estruturas, especialmente criado, para o armazenamento das regras e considera que os dados
so armazenados de forma separada a estas estruturas. Portanto, esta separao promove a
independncia das regras com relao aos dados, e da mesma forma que os dados dispem de
operaes para sua manipulao e definio, tambm so atribudas s regras operaes para
alterao e definio delas e de suas partes. Estes dois conjuntos, regras e dados, esto
associados por meio dos objetos de banco de dados, utilizados pela regra, como tabelas,
colunas e informaes sobre usurios, entre outros. As operaes para a alterao das regras
so apresentadas a seguir.

5.2.1 Operaes Sobre Elementos de uma Regra

O evento um elemento criado em conjunto com a definio de uma regra. Desta

forma, para cada evento no repositrio de regras, deve haver pelo menos uma ocorrncia de
regra associada a ele. O evento um elemento fortemente acoplado a regra. Portanto
alterao, adio ou eliminao dele, influencia o restante dos elementos da regra. Este
acoplamento se d em funo do seu tempo de execuo, variveis de transio e
granularidade. Esta viso sustentada pela linguagem SQL3. Um evento um acontecimento
que ocorre em um determinado momento. A eleio deste acontecimento, tais como insero
de dados, atualizao de dados, conexo ao sistema, est associada s necessidades impostas
pelo negcio ou pelo usurio, portanto existe uma semntica agregada a este evento, que se
reflete ao longo dos demais elementos da regra.
Considerando que um dos objetivos deste trabalho estender a Linguagem SQL3 no
que tange s operaes de gerncia, so sugeridas algumas operaes de gerncia,
especificamente para o elemento evento, tais como: alterar o evento de uma regra, adicionar
um evento a uma regra, eliminar um evento de uma regra. Nem todas estas operaes so
aplicadas ao evento definido pelo usurio, por exemplo, a operao alterar evento aplicada
sobre as regras do tipo derivao e operacional. A operao Fire um mecanismo de
execuo de regras especfico para este tipo de regra, derivao e operacional. Esta operao
tem a finalidade de executar estes tipos de regras e, portanto, difere do evento de regras
utilizado para disparar as regras estmulo-resposta.
As operaes de gerncia so mecanismos providos ao usurio para a gerncia das
 95

regras que esto armazenadas no repositrio de regras. Sendo assim, fortemente encorajador
oferecer ao usurio um conjunto de mecanismos que no altere a complexidade ou adicione
maior grau de complexidade do que ele est acostumado a lidar. Esta complexidade inerente
ao modelo de regras adotado pelos SGBDAs. Esta uma das razes para estender a
Linguagem SQL3, visto que amplamente utilizada, tanto na indstria quanto no meio
acadmico, em detrimento a sugerir novas formas de operaes de gerncia de regras. O
conjunto de operaes de gerncia sugerido leva em considerao esta necessidade, a saber:
um conjunto de operaes para a manipulao de regras e suas partes, que esteja em
conformidade com a proposta da Linguagem SQL3 e que tenha aderncia s sintaxes
atualmente apresentadas pelo modelo de regras desta Linguagem.

5.2.1.1 Alterar o evento de uma regra

A semntica associada ao termo alterar o evento representa a mudana de alguma

operao definida na especificao do evento, e esta alterao deve ser acompanhada do
objeto que sofre a ao, por exemplo, mudar a sentena de INSERT ON Funcionrio para
UPDATE ON Funcionrio. Esta ltima sentena composta da operao UPDATE e do
objeto que sofre a ao, a tabela Funcionrio. O mesmo procedimento, alterar, vlido para
os eventos de sistema, meta dados e evento temporal. A alterao de um evento somente tem
sentido para as regras do tipo estmulo/resposta, cujo evento pode assumir diversos tipos de
operaes. As regras do tipo derivao e operacionais possuem um nico tipo de evento,
definido como Fire.
A sintaxe definida para a modificao do evento de uma regra composta de duas
partes. A primeira parte da operao ALTER RULE <nome-regra> identifica a regra que ter
o seu evento alterado. A segunda parte, MODIFY EVENT TO <identificao da operao> >
[{<OR identificao da operao> <objeto que sofre a ao>}] | <data_hora> identifica o
novo evento que substituir o evento anteriormente definido na regra. Este evento pode ser
simples ou composto. Da mesma forma que os demais eventos, o evento temporal
(especificado pela data e hora), tambm pode ser modificado. A seguir, apresentada a
sintaxe da operao de modificao do evento de uma regra.
 96

Sintaxe:
ALTER RULE <nome-regra>
MODIFY EVENT TO <identificao da operao> [{<OR identificao da
operao> <objeto que sofre a ao>}] |
<identificao da data_hora>;

<identificao da operao> ::= <evento dados> |

<evento sistema> |
<evento meta-dados> |
<identificao da data_hora> ::= <evento temporal>

< evento dados > ::= <INSERT> [{OR <UPDATE> | <DELETE> | <SELECT>}]
Objeto que sofre a ao ::= [OF {<lista de colunas> <virgula>} OR ON <nome
tabela>]
< evento sistema > ::= <LOGON> [{OR <LOGOFF >}]
Objeto que sofre a ao ::= [OF <nome do usurio>]
< evento meta-dados > ::= <ALTER> [{OR <DROP> | <RENAME >}]
Objeto que sofre a ao ::= [TABLE <nome da tabela>]
< evento temporal > ::= <data_hora>

Os eventos dado, sistema e meta-dados, so compostos por um conjunto de operaes,

que representam os tipos de operaes que podem ser utilizadas na sintaxe acima. Operaes,
especficas, de um tipo de evento no podem ser utilizadas em conjunto com operaes de
outros eventos, visto que, cada um deles tem associado uma semntica. O evento dado utiliza
sentenas para a manipulao de dados, e estas sentenas auxiliam na manuteno das regras
de negcio e na manuteno da integridade dos dados do banco de dados. O evento sistema
est associado com acessos, por usurios, em nvel de banco de dados, e o evento meta-dados,
da mesma forma que o evento sistema, usado para tarefas administrativas como auditoria e
manuteno das tabelas do banco de dados. As operaes definidas nos eventos, sistema e
meta-dados, so utilizadas quando necessrio realizar tarefas de segurana, como por
exemplo, evitar que modificaes sejam realizadas no esquema de banco de dados ou registrar
eventos ou mudanas que ocorreram neste esquema.
Na Figura 22 ilustrado um exemplo de aplicao desta operao de modificao de
 97

evento. Seja a regra Atualiza_salario e deseja-se modificar o evento UPDATE ON

Funcionario para o evento INSERT ON Funcionario

CREATE RULE ATUALIZA_SALARIO

AFTER UPDATE ON Funcionario
FOR EACH ROW
DO
BEGIN
UPDATE Salario
SET Sal_Func = Sal_Func + Sal_Func * :NEW.Indice
WHERE Cod_Func = :NEW.Cod_Func;
END;

Figura 22 Regra de negcio Atualiza_Salario

ALTER RULE ATUALIZA_SALARIO

MODIFY EVENT TO INSERT ON Funcionario;

A regra Atualiza_salario modificada e assume o novo evento.

CREATE RULE ATUALIZA_SALARIO

AFTER INSERT ON Funcionario
FOR EACH ROW
DO
BEGIN
UPDATE Salario
SET Sal_Func = Sal_Func + Sal_Func * :NEW.Indice
WHERE Cod_Func = :NEW.Cod_Func;
END;

Considerando o exemplo acima, tanto o evento INSERT ON Funcionario quanto o

evento UPDATE ON Funcionrio so compatveis com o tipo de variveis de transio
 98

(NEW) utilizadas na ao da regra.

A alterao da regra, especificamente o evento <UPDATE ON Funcionrio> pelo
evento <INSERT ON Funcionario> gera uma mudana de estado no repositrio de regras.
Esta alterao implica que um novo registro adicionado tabela EVENTO e o evento
anterior eliminado desta tabela. Porm, se o evento <UPDATE ON Funcionrio> est
associado outra regra, ento a eliminao da referncia entre este evento e a regra
ATUALIZA_SALARIO ocorre somente na tabela REGRA_EVENTO. Na tabela EVENTO, o
atributo <operao> assume a nova operao, INSERT, definida na sintaxe acima.
Se, ao invs de INSERT ON Funcionrio fosse SELECT OF <lista de atributos>, a
varivel de transio no seria NEW, mas sim, CURRENT, adaptando-se ao contexto
apresentado. Tambm, importante considerar que o tempo de ativao no seria o mais
indicado para a operao apresentada, pois para a operao INSERT utiliza-se o tempo de
ativao ON. Estas inconsistncias seriam observadas quando a regra fosse compilada.
funo do usurio corrigir estas inconvenincias, visto que um alerta seria gerado pelo
sistema.
A abrangncia de um trigger depende de seu evento. Quando o usurio especifica uma
regra, geralmente o corpo da regra (condio e ao) est correlacionado com este evento.
Portanto, substituir as operaes de um evento, por outras operaes pertencentes a outro tipo
de evento, diferente, sem analisar e/ou redefinir o corpo da regra, pode gerar inconsistncias.
Por exemplo, um evento composto por mais de uma operao do tipo UPDATE OR LOGON
no apresenta qualquer tipo de correlao entre elas, visto que so operaes de domnios
diferentes. Para evitar tais inconvenincias, elaborada uma meta-regra (Meta-Regra 7), que
verifica as operaes que so definidas na sintaxe de modificao de evento. No exemplo a
seguir, ilustrada esta inconsistncia.
Seja a regra ATUALIZA_CARGO, cuja finalidade atualizar o salrio do
funcionrio, sempre que seu cargo atualizado. O salrio aumentado em funo de um
ndice especfico.
A regra ATUALIZA_CARGO, apresentada na Figura 23a, possui um evento do tipo
UPDATE ON Cargo e na ao desta regra so definidas variveis de transio associadas a
este evento. Ao modificar o evento para LOGON OF Usurio_1, apresentada na Figura 23b,
estas variveis perdem o sentido. Isto ocorre porque a operao LOGON OF Usurio_1 atua
em nvel de banco de dados, com a finalidade de acesso, pelo Usurio_1, ao banco de dados.
Alm da modificao do evento, necessrio ajustar a varivel de transio, de AFTER para
 99

ON. A granularidade da regra perde seu sentido, uma vez que o evento sistema no atua em
nvel de registros.

CREATE RULE ATUALIZA_CARGO CREATE RULE ATUALIZA_CARGO

AFTER UPDATE ON Cargo ON LOGON OF Usurio_1
FOR EACH ROW
DO DO
BEGIN BEGIN
UPDATE Salario UPDATE Salario
SET Sal_Func = :Sal_Func + Sal_Func * SET Sal_Func = :Sal_Func + Sal_Func *
:NEW.Indice :NEW.Indice
WHERE Cod_Func = :NEW.Cod_Func; WHERE Cod_Func = :NEW.Cod_Func;
END; END;

a) b)

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.

5.2.1.2 Eliminar o evento de uma regra

A semntica associada ao termo eliminar o evento , de uma regra, tem o sentido de

duas aes a serem tomadas pelo SGBDA. A primeira ao a prpria eliminao do evento,
e a segunda ao a atribuio da operao Fire a regra. Portanto, a regra que tinha um perfil
do tipo ECA, ECAA ou EA, caracterstica das regras do tipo estmulo-resposta, para ter o
perfil de uma regra do tipo CA, CAA ou A, caractersticas das regras do tipo operacional e
derivao.
As regras estmulo-resposta podem ser definidas em funo de diversos tipos de
eventos, tais como: evento dados, evento meta-dados, evento sistema, e evento temporal.
Todos estes eventos podem ser substitudos pela operao Fire.
Quando a operao para eliminao de um evento aplicada sobre uma regra, o
SGBDA executa os seguintes passos:
1) Elimina os registros da tabela REGRA_EVENTO que fazem referncia regra e
aos eventos desta regra, e se no existe mais nenhuma ocorrncia deste evento
outra regra, ento se elimina a definio do evento da tabela EVENTO;
 100

2) Adiciona um novo registro tabela EVENTO, caso no haja nenhuma ocorrncia

deste evento nesta tabela, e uma ocorrncia deste evento tabela, na tabela
REGRA_EVENTO;
3) Modifica-se as informaes da regra, na tabela REGRA, de forma a adequar-se ao
novo evento. Especificamente, os atributos <tipo-regra>, <granularidade>, <tempo
de ativao> so alterados em funo do novo evento;

A sintaxe para a eliminao de um evento, a seguinte:

Sintaxe:
ALTER RULE <nome-regra>
DROP EVENT <identificao da operao> [{<OR identificao da
operao> <objeto que sofre a ao>}] |
<identificao da data_hora>;

<identificao da operao> ::= <evento dados> |

<evento sistema> |
<evento meta-dados> |
<identificao da data_hora> ::= <evento temporal>

< evento dados > ::= <INSERT> [{OR <UPDATE> | <DELETE> | <SELECT>}]
Objeto que sofre a ao ::= [OF {<lista de colunas> <virgula>} OR ON <nome
tabela>]
< evento sistema > ::= <LOGON> [{OR <LOGOFF >}]
Objeto que sofre a ao ::= [OF <nome do usurio>]
< evento meta-dados > ::= <ALTER> [{OR <DROP> | <RENAME >}]
Objeto que sofre a ao ::= [TABLE <nome da tabela>]
< evento temporal > ::= <data_hora>;

No exemplo a seguir apresentada uma regra com tempo de ativao AFTER e um

evento dados com a operao UPDATE sobre o atributo salrio da tabela EMP
(empregado). A regra do tipo ECA. A granularidade da regra FOR STATEMENT, e a
condio uma consulta SQL, elementar, cuja finalidade identificar se existe algum
funcionrio que recebe menos de 1500 reais, para os funcionrios que foram admitidos at o
 101

ano de 1990.

CREATE RULE SALARIO_FUNC

AFTER UPDATE OF salario ON EMP
FOR EACH STATEMENT
WHEN ((SELECT MIN(salario)
FROM EMP
WHERE data_admissao <= 01/12/1990) < 1500)
DO
BEGIN
CALL PROCEDURE lista_empregado (nomes);
END;

ALTER RULE SALARIO_FUNC

DROP EVENT < UPDATE >< OF salario ON EMP >;

A regra Atualiza_salario modificada e assume o novo evento.

CREATE RULE SALARIO_FUNC
WHEN ((SELECT MIN(salario)
FROM EMP
WHERE data_admissao < 01/01/1990) < 1500)
DO
BEGIN
CALL PROCEDURE lista_empregado (nomes);
END;

No exemplo acima, o evento foi eliminado da especificao da regra, porm a

operao Fire responsvel pelo disparo da regra SALARIO_FUNC. Com relao condio
e a ao, estas se mantm sem alteraes. responsabilidade do usurio ajustar a regra de
modo que estes dois elementos da regra no apresentem variveis de transio, nem
granularidade. Uma vez que a regra seja compilada, erros podem ser apresentados.
 102

5.2.1.3 Adicionar um evento a uma regra

A semntica associada operao de adio, de um evento, est associada s regras de

derivao e operacional. Adicionar um evento implica eliminar o evento definido atualmente
como FIRE e substitu-lo por um evento dados, evento sistema, meta-dados ou temporal. A
evoluo de uma regra do tipo derivao ou operacional para uma regra estmulo-resposta
apresenta menor impedncia que o seu processo inverso, isto porque no necessrio
preocupar-se com os ajustes das variveis de transio.
Com relao granularidade da regra, importante considerar que a condio da regra
seja compatvel com a granularidade definida para a regra. Por exemplo, a granularidade
orientada a conjunto utilizada quando a condio considerar consultas orientadas a conjunto
de linhas. Por exemplo, existncia de sentena em linguagem SQL, com funes de grupo
como mdia, somas, entre outras.
O impacto de uma operao de adio de um evento no repositrio de regras descrito
a seguir:
1) Eliminar os registros da tabela REGRA-EVENTO que fazem referncia regra e
eliminar as ocorrncias da tabela EVENTO, caso no existam ocorrncias deste
evento na tabela REGRA-EVENTO.
2) Adiciona um novo registro tabela EVENTO, caso no existam ocorrncias deste
evento nesta tabela, e adequar os atributos <tipo-regra>, <granularidade>, <tempo
de ativao>. Esta alterao implica na identificao da granularidade e do tempo
de ativao da nova regra, que so definidos pelo usurio. O tipo da regra
identificado automaticamente.
3) Logo a seguir, adicionar as devidas ocorrncias na tabela REGRA-EVENTO;

A sintaxe para a adio de um evento a uma regra a seguinte:

 103

Sintaxe:
ALTER RULE <nome-regra>
ADD EVENT <<identificao da operao> [{<OR identificao da
operao> <objeto que sofre a ao>}] |
<identificao da data_hora>;
[ACTIVATION TIME <identificao do tempo de ativao>]
[GRANULARITY <identificao da granularidade>];

<identificao da operao> ::= <evento dados> |

<evento sistema> |
<evento meta-dados> |
<identificao da data_hora> ::= <evento temporal>

< evento dados > ::= <INSERT> [{OR <UPDATE> | <DELETE> | <SELECT>}]
Objeto que sofre a ao ::= [OF {<lista de colunas> <virgula>} OR ON <nome
tabela>]
< evento sistema > ::= <LOGON> [{OR <LOGOFF >}]
Objeto que sofre a ao ::= [OF <nome do usurio>]
< evento meta-dados > ::= <ALTER> [{OR <DROP> | <RENAME >}]
Objeto que sofre a ao ::= [TABLE <nome da tabela>]
< evento temporal > ::= <data_hora>;
identificao do tempo de ativao ::= BEFORE [{OR <AFTER> | <ON>}]
identificao da granularidade ::= <FOR EACH ROW> [{OR <FOR STATEMENT>]

O tempo de ativao e a granularidade da regra so informaes opcionais. Quando o

usurio no especifica estes valores, o SGBDA assume os valores padro. Para o tempo de
ativao, o valor padro BEFORE e para a granularidade o valor padro FOR
STATEMENT. Estes valores esto em conformidade com a linguagem SQL3.

A seguir apresentada uma regra denominada CATEGORIA_CLIENTE que recebe

alguns valores por meio de variveis globais. A regra do tipo Ao, cuja finalidade
identificar a categoria do cliente em funo de seu salrio.
 104

VARIAVEIS GLOBAIS
(V_CodCli Cliente.Cod_Cli%TYPE)
V_TipVelho Cliente.Tip_Cli%TYPE;
V_TipNovo Cliente.Tip_Cli%TYPE;
V_SalCli Cliente.Sal_Cli%TYPE;
CREATE RULE CATEGORIA_CLIENTE
DO
BEGIN
SELECT Sal_Cli, Tip_Cli INTO V_SalCli, V_TipVelho
FROM Cliente
WHERE Cod_Cli = V_CodCli;
IF V_SalCli >= 5000 THEN
V_TipNovo:= 'A';
ELSIF V_SalCli < 5000 AND V_SalCli >= 3000 THEN
V_TipNovo:= 'B';
ELSE
V_TipNovo:= 'C';
END IF;
IF V_TipNovo <> V_TipVelho THEN
UPDATE Cliente
SET Tip_Cli = V_TipNovo
WHERE Cod_Cli = V_CodCli;
END IF;
END;

ALTER RULE CATEGORIA_CLIENTE

ADD EVENT <UPDATE> <OF salario ON CLIENTE>
[ACTIVATION TIME <AFTER>]
[GRANULARITY <FOR EACH ROW>];
 105

CREATE RULE CATEGORIA_CLIENTE

AFTER UPDATE OF salario ON CLIENTE
FOR EACH ROW
DO
BEGIN
SELECT Sal_Cli, Tip_Cli INTO V_SalCli, V_TipVelho
FROM Cliente
WHERE Cod_Cli = V_CodCli;
IF V_SalCli >= 5000 THEN
V_TipNovo:= 'A';
ELSIF V_SalCli < 5000 AND V_SalCli >= 3000 THEN
V_TipNovo:= 'B';
ELSE
V_TipNovo:= 'C';
END IF;
IF V_TipNovo <> V_TipVelho THEN
UPDATE Cliente
SET Tip_Cli = V_TipNovo
WHERE Cod_Cli = V_CodCli;
END IF;
END;

A regra CATEGORIA_CLIENTE que era do tipo operacional passou a ser do tipo

evento-ao. O evento desta regra uma operao de atualizao sobre ao atributo salrio da
tabela cliente. Alm disso, tambm foi atribudo o tempo de ativao AFTER e uma
granularidade em nvel de registro. Uma vez que a atribuio do novo evento foi definida na
regra, nenhuma outra modificao necessita ser feita. O usurio tem a opo de ajustar a ao
da regra e utilizar variveis de transio, compatveis com o evento que foi definido, por
exemplo, ao invs de utilizar a varivel V_CodCli, possvel utilizar NEW.CodCli.
 106

5.2.1.4 Adicionar uma condio a uma regra

A semntica associada ao termo adicionar uma condio a uma regra, representa

inserir uma condio a uma regra. As regras as quais esta operao pode ser aplicada so do
tipo operacional e estmulo-resposta. A adio da condio implica em inserir um registro na
tabela CONDIO do repositrio de regras. A tabela CONDIO apresenta um
identificador da condio, <id_condio> definido pelo prprio SGBDA e um identificador
da regra, <id_regra>, a qual a condio pertence. O atributo <data_ltima_modificao>
armazena a data da ltima operao realizada sobre a regra.
Para utilizar a operao de adio de uma condio a uma regra, necessrio que o
usurio esteja a par de que a condio da regra est diretamente correlacionada com a
granularidade da regra. A sintaxe de adio do elemento condio, a seguinte:

Sintaxe:
ALTER RULE <nome-regra>
ADD CONDITION [<operador unrio>] <elemento - condio>
[<conector> <elemento - condio>] ...

<operador unrio> ::= NOT

<conector> ::= AND | OR
< elemento - condio > ::= <condio - SQL3> | <predicado-varivel-de-transio>

A primeira parte da sentena ALTER RULE <nome-regra> identifica a regra. A

segunda parte ADD CONDITION identifica o tipo de expresso que pode ser adotada na
condio. Nesta operao, possvel adotar o operador NOT.
Para controlar a aplicao desta operao de gerncia sobre uma regra, necessrio
atribuir uma meta-regra, conforme apresentado na Tabela 5.1

Tabela 5.1 Meta-regra relacionada adio de uma condio de uma regra..

Regra Descrio
Meta-Regra 8 Somente as regras do tipo EA, A podem receber o elemento
condio.
 107

A regra anterior CATEGORIA_CLIENTE no possui uma clusula condio, visto

que uma regra do tipo EA. A esta regra ser atribuda uma condio por meio da operao
apresentada acima. Primeiro apresentada a sintaxe e depois o resultado desta atribuio.

ALTER RULE < CATEGORIA_CLIENTE>

ADD CONDITION (( SELECT saldo_medio
FROM cliente
WHERE cod_cli = NEW.Codcli ) < 10000,00 )

Esta condio retorna verdadeiro se existem registros cujo salrio do cliente maior
que mil reais. Considerando a condio verdadeira, ento o cliente pode assumir uma
categoria (A, B ou C). Clientes sem categoria no podem solicitar emprstimos ao banco. Esta
regra de negcio valida para todos os clientes. A regra CATEGORIA_CLIENTE
apresentada a seguir:

CREATE RULE CATEGORIA_CLIENTE

AFTER UPDATE OF salario ON CLIENTE
FOR EACH ROW
WHEN (( SELECT salario
FROM cliente
WHERE cod_cli = NEW.Codcli ) > 1000,00 )
DO
BEGIN
A ao a mesma definida anteriormente na regra
END;

Na condio desta regra, adicionada uma varivel de transio que se adequa ao

evento definido previamente na regra. responsabilidade do usurio garantir que estas
variveis sejam aplicadas de forma adequada na condio. Da mesma forma, importante
garantir que a condio seja adequada para o emprego da granularidade definida na regra.
 108

5.2.1.5 Eliminar a condio de uma regra

Uma regra pode ser alterada em funo da eliminao de sua condio. A eliminao
de uma condio possvel para os tipos de regras estmulo-resposta que sejam definidas com
uma nica ao e para os tipos de regras derivao que possuam tambm uma nica ao.
Quando estes tipos de regras possuem aes primria e secundria, ento a eliminao da
condio no permitida pelo SGBDA, visto que no existe uma regra somente com duas
aes, sem o elemento condio. Para controlar a aplicao desta operao de gerncia sobre
uma regra, necessrio atribuir uma meta-regra, conforme apresentado na Tabela 5.2.

Tabela 5.2 Meta-regra relacionada eliminao de condio de uma regra.

Regra Descrio
Meta-Regra 9 Somente as regras do tipo ECA, CA podem ser alteradas para
regras do tipo EA e A.

A sintaxe para eliminao da condio de uma regra a seguinte:

Sintaxe:
ALTER RULE <nome-regra>
DROP CONDITION;

O efeito desta regra sobre o repositrio de regras a eliminao de um registro da

tabela CONDIO. No necessrio fazer referncia a que condio est sendo eliminada,
porque ela nica e pode ser identificada por meio do nome da regra.
Seja a regra a seguir utilizada para guardar o histrico dos salrios dos funcionrios de
uma empresa. A informao sobre os salrios mantida em um histrico, toda vez que um
salrio atualizado. Alm disso, o usurio avisado de que a mdia salarial maior que R$
10.000, 00.
 109

Exemplo:
CREATE RULE SALARIO_FUNC
AFTER UPDATE OF salario ON FUNCIONARIO
WHEN ((Select AVG(salario)
FROM FUNCIONARIO) > 10.000)
DO
BEGIN
INSERT INTO HISTORICO_SALARIO_FUNCIONARIO
( SELECT * FROM OLD_TABLE);
SIGNAL (- 500, A media salarial dos funcionrios no pode ser maior que
R$ 10.000,00).
END;

ALTER RULE < SALARIO_FUNC >

DROP CONDITION;

CREATE RULE SALARIO_FUNC

AFTER UPDATE OF salario ON FUNCIONARIO
DO
BEGIN
INSERT INTO HISTORICO_SALARIO_FUNCIONARIO
( SELECT * FROM OLD_TABLE);
SIGNAL (- 500, A media salarial dos funcionrios no pode ser maior que
R$ 10.000,00).
END;

5.2.1.6 Alterar a condio de uma regra

As regras que podem ter sua condio alterada so regras do tipo estmulo-resposta e
derivao. Alterar uma condio implica em modificar um registro na tabela CONDIO do
repositrio de regras: Isto implica em modificar o atributo definio_condio e atualizar o
atributo data_ltima_modificao. Para aplicar esta operao de gerncia, necessrio que
a regra seja do tipo estmulo-resposta e derivao. Uma meta-regra deve ser utilizada para
garantir a correta aplicao da operao sobre um tipo de regra previamente definido,
 110

conforme apresentado na Tabela 5.3:

Tabela 5.3 Meta-regra relacionada alterao da condio de uma regra

Regra Descrio
Meta-Regra 10 Somente regras do tipo ECA, ECAA, CA, CAA podem ter sua
condio alterada.

A sintaxe de alterao apresentada a seguir:

ALTER RULE <nome-regra>

MODIFY CONDITION TO [<operador unrio>] <elemento - condio>
[<conector> <elemento - condio>] ...

<operador unrio> ::= NOT

<conector> ::= AND | OR
< elemento - condio > ::= <condio - SQL3> | <predicado-varivel-de-transio>

Seja a seguinte regra:

CREATE RULE SALARIO_FUNC

AFTER UPDATE OF salario ON EMP
FOR EACH STATEMENT
WHEN ((SELECT MIN(salario)
FROM EMP
WHERE data_admissao <= 01/12/1990) < 1500)
DO
BEGIN
CALL PROCEDURE lista_empregado (nomes);
END;

Esta regra tem a finalidade de identificar os funcionrios que foram admitidos antes de
dezembro de 1990 e que recebem um salrio menor que R$ 1500,00.
Considerando que na empresa no trabalham mais os funcionrios que foram
admitidos antes da data de dezembro de 1990, esta regra perdeu o sentido para a empresa. O
 111

usurio voltou-se para uma lei que prev que os funcionrios que trabalham pelo menos 6
horas dirias no podem receber menos de um salrio mnimo. Assim, aplica-se a operao de
gerncia para modificao da condio conforme especificado abaixo:

ALTER RULE < SALARIO_FUNC >

MODIFY CONDITION TO ((SELECT MIN(salario)
FROM EMP ) < (350)

CREATE RULE SALARIO_FUNC

AFTER UPDATE OF salario ON EMP
WHEN ((SELECT MIN(salario)
FROM EMP ) < (350)
DO
BEGIN
CALL PROCEDURE lista_empregado (nomes);
END;

Para aplicar esta operao, necessrio que o usurio considere a granularidade da

regra e o tempo de ativao da mesma.

5.2.1.7 Adicionar uma ao a uma regra

Uma regra deve apresentar pelo menos uma ao. A adio de uma ao a uma regra
representa a adio de uma ao secundria. Para que seja possvel atribuir mais uma ao, a
regra deve possuir uma condio associada a ela. O reflexo no repositrio de regras, em
funo desta adio, um registro associado a uma regra. O SGBDA atribui um cdigo para
esta ao, adicionando um valor ao atributo <id_ao> e atribui o valor secundrio ao atributo
<categoria>. A sintaxe para a adio de uma ao a uma regra a seguinte:
Sintaxe:
ALTER RULE <nome_regra>
ADD SECONDARY ACTION <ao secundria>

<ao secundria> ::= <sentena procedimental SQL> |

 112

CALL <nome procedimento> |

<bloco SQL>
<operao -regra> <nome -regra>

<bloco SQL> ::= BEGIN

{<sentena procedimental SQL> <ponto e vrgula>} ...
END;
A primeira parte desta sintaxe ALTER RULE <nome_regra> identifica a regra que
ser alterada. A segunda parte da operao de gerncia, ADD SECONDARY ACTION
identifica a ao a ser inserida na regra. Esta ao composta de uma sentena denominada
ao secundria. Esta sentena pode ser uma operao vlida dentro da linguagem
procedimental SQL3. Quando um conjunto de sentenas deve ser especificado, ento se
utiliza um bloco SQL, <bloco SQL>, ou uma chamada a procedimento, <CALL nome
procedimento>. Alm disso, permitido definir uma operao - regra, <operao-regra>,
definida pelas operaes habilitar, desabilitar ou disparar uma regra, por meio de um evento
Fire. Para garantir a consistncia do repositrio de regras, necessrio que algumas meta-
regras atuem quando o usurio utilizar esta operao de gerncia. Estas regras so
apresentadas na Tabela 5.5:
apresentado um exemplo de aplicao desta operao de gerncia. Considere a regra
CATEGORIA CLIENTE, apresentada anteriormente. Quando a condio for verdadeira, a
ao executada. Caso contrrio, nada acontece. Porm, o gerente pode ser notificado de que
o usurio no foi aprovado, no que se refere ao seu saldo mdio, para possveis emprstimos.
Ao adicionar uma ao secundria, possvel incorporar esta informao, necessria para o
gerente.

ALTER RULE < CATEGORIA_CLIENTE >

ADD SECONDARY ACTION <CALL PROCEDURE Saldo_Mdio (NEW.Codcli)>;
 113

CREATE RULE CATEGORIA_CLIENTE

AFTER UPDATE OF salario ON CLIENTE
FOR EACH ROW
WHEN (( SELECT saldo_medio
FROM cliente
WHERE cod_cli = NEW.Codcli ) < 1000,00 )
DO
BEGIN
A ao a mesma definida anteriormente na regra
END;
ELSEDO
BEGIN
CALL PROCEDURE Saldo_Mdio (NEW.Codcli)
END;

O usurio tem a responsabilidade de evitar que as variveis de transio, na ao

secundria, no sejam compatveis com o evento da regra.
Uma vez que a operao executada, o SGBDA atualiza a informao referente ao
registro da regra afetada na tabela REGRA. O atributo <tipo_regra> atualizado e deixa de
assumir o valor ECA para assumir o valor ECAA. Esta atualizao ocorre em funo de uma
meta-regra, conforme a Tabela 5.4.

Tabela 5.4 Meta-regras relacionadas alterao da ao de uma regra

Regra Descrio
Meta-Regra 11 Somente permitido adicionar uma ao a regras do tipo ECA e
CA

Meta-Regra 12 As regras do tipo ECAA, CAA no podem receber outra

ocorrncia de ao
 114

5.2.1.8 Modificar a ao de uma regra

A operao de gerncia para modificar a ao de uma regra pode ser utilizada em

todos os tipos de regras, derivao, operacional, e estmulo-resposta. No repositrio de regras,
modificar a ao implica em eliminar o registro da regra em questo e adicionar um novo
registro, na tabela AO.
O usurio, ao atribuir uma nova ao, deve considerar o tipo de evento da regra. Desta
forma eliminam-se possveis problemas com variveis de transio que no so compatveis
com este evento. Da mesma forma, em uma ao, possvel que existam outras regras,
disparadas pela operao Fire. O SGBDA ao compilar a ao, verifica a existncia desta
composio de regras e armazena na tabela REGRA-COMPOSIO esta nova seqncia
especificada. Quando forem definidas operaes de banco de dados na ao, verifica se
existem outras regras que podem ser disparadas em funo destas operaes, esta informao
armazenada na tabela AO_EV.

A sintaxe para modificao da ao .

Sintaxe:

ALTER RULE <nome_regra>

MODIFY [PRIMARY | SECONDARY] ACTION <ao primaria | secundria >;

<ao primaria | secundria> ::= <sentena procedimental SQL> |

CALL <nome procedimento> |
<bloco SQL>
<operao -regra>

<bloco SQL> ::= BEGIN

{<sentena procedimental SQL> <ponto e vrgula>} ...
END;

Seja a regra Publicacao_Prof apresentada a seguir: Um usurio deseja saber a titulao

de um professor, com a finalidade de identificar se ele atingiu a quantidade de publicaes
 115

(somente artigos) para o ano corrente. Esta regra pode ser disparada toda vez que ele, o
professor, entra em frias. A regra pode ser alterada para que o usurio possa verificar se o
professor possui tambm publicaes em livros.

CREATE RULE Publicacao_Prof

ON SELECT OF titulacao ON PROFESSOR
FOR EACH ROW
WHEN (current.status = Ferias)
DO
BEGIN
SELECT COUNT (publicacao) INTO V_quantidade
FROM PROFESSOR
WHERE codProf = CURRENT.codProf
AND ano = current_year;

CALL PROCEDURE nro_publicacao (codProf, V_quantidade)

END;

ALTER RULE < Publicacao_Prof >

MODIFY [PRIMARY] ACTION
< BEGIN
SELECT COUNT (publicacao) INTO V_quantidade
FROM PROFESSOR
WHERE codProf = CURRENT.codProf
AND ano = current_year;
SELECT COUNT (livros) INTO V_livros
FROM LIVROS
WHERE codProf = CURRENT.codProf
AND ano = current_year;
CALL PROCEDURE nro_publicacao (codProf, V_quantidade)
CALL PROCEDURE livro_publicacao (codProf, V_livros)
END;
>;

A nova ao inclui uma consulta SQL e uma nova chamada a procedimentos.

 116

Portanto, aps a aplicao desta operao de modificao do elemento ao, a regra fica da
seguinte maneira:
CREATE RULE Publicacao_Prof
ON SELECT OF titulacao ON PROFESSOR
FOR EACH ROW
WHEN (current.status = Ferias)
DO
BEGIN
SELECT COUNT (publicacao) INTO V_quantidade
FROM PROFESSOR
WHERE codProf = CURRENT.codProf
AND ano = current_year;
SELECT COUNT (livros) INTO V_livros
FROM LIVROS
WHERE codProf = CURRENT.codProf
AND ano = current_year;
CALL PROCEDURE nro_publicacao (codProf, V_quantidade)
CALL PROCEDURE livro_publicacao (codProf, V_livros)
END;
O usurio deve garantir que a nova ao deve se adaptar ao novo contexto
apresentado, em funo do evento da regra. Para a nova ao, foi adicionada uma nova
consulta SQL com a mesma varivel de transio e uma chamada a procedimentos.

5.2.1.9 Eliminar a ao de uma regra

A eliminao de uma ao pode ocorrer somente em regras do tipo estmulo-resposta e

derivao, sempre que as regras forem portadoras de uma ao primria e uma ao
secundria. Eliminar implica em excluir um registro da tabela AO. Tambm devem ser
eliminados registros, quando houver alguma ocorrncia que envolva esta regra, da tabela
AO_TAB e AO_EV. possvel eliminar uma ao primria ou uma ao secundria.
Em ambos os casos, o reflexo desta modificao no repositrio de regras so as eliminaes
dos registros referentes as tabelas mencionadas anteriormente. Na tabela REGRA, o atributo
<tipo_regra> modificado para assumir o novo valor. Para manter a consistncia do
repositrio de regras, necessrio que o SGBDA realize os devidos ajustes, sobre os dados da
 117

ao resultante. Por exemplo, ao eliminar uma ao primria, a regra fica com uma ao
secundria. Uma regra no pode ter uma ao secundria sem a presena de uma ao
primria. Assim, ao eliminar uma ao primria, a ao secundria assume, automaticamente,
o papel de ao primria. O atributo <categoria>, na tabela AO, muda o valor armazenado
de secundrio para primrio. A seguir apresenta-se na Tabela 5.5, a regra de consistncia
relacionada com a eliminao de uma ao de uma regra.

Tabela 5.5 Meta-regra relacionada eliminao da ao de uma regra

Regra Descrio
Meta-Regra 13 Somente as regras do tipo ECAA e CAA podem eliminar a ao
da regra.

A seguir apresentada a sintaxe da operao de gerncia para a eliminao da ao de

uma regra.

ALTER RULE <nome_regra>

DROP [PRIMARY | SECONDARY] ACTION;

Seja a regra CATEGORIA_CLIENTE definida a seguir, com duas aes, primria e

secundria. Ao aplicar a operao acima, a regra deve resultar somente em uma ao.

CREATE RULE CATEGORIA_CLIENTE

AFTER UPDATE OF salario ON CLIENTE
FOR EACH ROW
WHEN (( SELECT saldo_medio
FROM cliente
WHERE cod_cli = NEW.Codcli ) < 1000,00 )
DO
BEGIN
A ao a mesma definida anteriormente na regra CATEGORIA_CLIENTE
END;
ELSEDO
CALL PROCEDURE Saldo_Mdio (NEW.Codcli)
END;
 118

ALTER RULE < CATEGORIA_CLIENTE >

DROP [PRIMARY] ACTION;

CREATE RULE CATEGORIA_CLIENTE

AFTER UPDATE OF salario ON CLIENTE
FOR EACH ROW
WHEN (( SELECT saldo_medio
FROM cliente
WHERE cod_cli = NEW.Codcli ) < 1000,00 )
DO
BEGIN
CALL PROCEDURE Saldo_Mdio (NEW.Codcli)
END;
Ao executar esta regra, verifica-se o valor resultante da avaliao da condio, caso
seja verdadeira, a ao executada, caso contrrio, nada acontece. O SGBDA conhece o tipo
de execuo que deve ser realizada, devido informao armazenada no atributo
<tipo_regra>. Portanto fundamental que aps a eliminao da ao, este atributo deve ser
ajustado a sua nova configurao.
A regra passa a ter uma nova semntica, aps a eliminao de sua ao primria.
responsabilidade do usurio garantir que a regra resultante satisfaa os requisitos no negcio.

5.2.1.10 Alternar as aes de uma regra

A operao de gerncia alternar as aes de uma regra tem a finalidade de trocar a

categoria, de primria para secundria e vice-versa, de uma ao. Esta operao aplicada em
regras estmulo-resposta e derivao, que possuem duas aes.
O impacto gerado por esta operao no repositrio de regras ocorre somente na tabela
AO. O atributo <categoria> inverte os valores, de primria para secundria e vice-versa.
Esta operao tem a finalidade de evitar que o usurio elimine uma ao, segundo o processo
explicado na operao de eliminao de uma ao, e depois volte a defin-la.
A sintaxe desta operao a seguinte:

ALTER RULE < nome_regra >

CHANGE ACTION FROM [PRIMARY] TO [SECONDARY];
 119

A primeira parte da sintaxe identifica a regra e a segunda parte tem a finalidade de

alternar a ao primria para que assuma o papel de ao secundria e a ao secundria
assuma o papel de ao primria.
Considerando a regra CATEGORIA_CLIENTE, apresentada anteriormente, aps a
aplicao da regra acima, o resultado apresentado a seguir:

ALTER RULE < CATEGORIA_CLIENTE >

CHANGE ACTION FROM [PRIMARY] TO [SECONDARY];

CREATE RULE CATEGORIA_CLIENTE

AFTER UPDATE OF salario ON CLIENTE
FOR EACH ROW
WHEN (( SELECT saldo_medio
FROM cliente
WHERE cod_cli = NEW.Codcli ) < 1000,00 )
DO
CALL PROCEDURE Saldo_Mdio (NEW.Codcli)
ELSEDO
BEGIN
A ao a mesma definida anteriormente na regra CATEGORIA_CLIENTE
END;

5.2.2 Operaes Sobre Regras

As operaes relacionadas s propriedades de uma regra dizem respeito regra como

um todo, tratando a regra de forma unssona. Estas operaes podem habilitar ou desabilitar
uma regra, ou um conjunto de regras, agrupar regras e eliminar este agrupamento.
As operaes de gerncia foram definidas em dois grupos, um grupo que trata da
gerncia de seus elementos e outro grupo que trata da gerncia das propriedades da regra.

5.2.2.1. Habilitar ou Desabilitar uma regra

Uma regra pode ser habilitada ou desabilitada por uma operao de gerncia ou,
automaticamente, por meio de outra regra. Toda regra quando especificada no repositrio de
regras assume o valor padro Habilitada. Para habilitar ou desabilitar uma regra usa-se a
seguinte operao de gerncia.
 120

ENABLE [OR DISABLE] RULE < nome_regra >;

O impacto desta operao no repositrio de regras a alterao do valor do atributo

<status> na tabela REGRA. Quando <status> possui o valor H, a regra est habilitada, e
quando este atributo possui o valor D, a regra est desabilitada.

Supondo que a regra CATEGORIA_CLIENTE esteja habilitada, no repositrio de

regras. Para desabilit-la basta aplicar a seguinte operao.

DISABLE RULE < CATEGORIA_CLIENTE>;

Uma vez que a operao sucedeu de forma satisfatria, a regra passa a ser desabilitada.

5.2.2.2 Agrupamento de regras

Um conjunto de regras pode ser agrupado com a finalidade de realizar operaes de

gerncia sobre este grupo. Ao invs de aplicar, repetidamente, a mesma operao para cada
regra, possvel faz-lo uma nica vez por meio da definio de grupo de regras.
A sintaxe de agrupamento de regras a seguinte:

CREATE RULESET < nome_grupo_regra >

ADD RULE [lista de regras]
[OR DELETE RULE [lista de regras]]

A primeira parte desta sintaxe identifica o nome do grupo que constitui o conjunto de
regras. A segunda parte tem a finalidade de adicionar regras a este grupo e a terceira parte a
finalidade de eliminar regras do grupo de regras. A seguir apresentado um agrupamento de
regras.
CREATE RULESET < universidade >
ADD RULE Publicacao_Prof; Salrio_Func

O conjunto de regras denominado Universidade contm as duas regras

Publicacao_Prof e Salrio_Func.
 121

5.2.2.3 Eliminar Grupo de Regras

A operao de gerncia utilizada para eliminar um agrupamento de regras apresenta a

funcionalidade oposta da operao CREATE RULESET. Portanto, para eliminar um
agrupamento de regras necessrio que elas estejam agrupadas. A sentena utilizada para
eliminao de um grupo de regas a seguinte:
DROP RULESET <nome_grupo_regra>;

Para eliminar o agrupamento de regras universidade, utiliza-se a seguinte operao:

DROP RULESET universidade ;

5.2.2.4 Eliminar uma regra

A eliminao de uma regra do repositrio de regras representa a excluso de todos os

elementos associados regra, destes elementos com os objetos do banco de dados e s
informaes da regra. Na tabela CONDIO, so eliminadas todas as condies que
possuem referncia regra a ser eliminada e as informaes contidas na tabela
CONDIO_TAB. Este procedimento realizado tambm na tabela AO e suas
informaes contidas nas tabelas AO_TAB e AO_EV. Com relao tabela EVENTO,
estes tambm devem ser eliminados, assim como as informaes das tabelas REGRA_EV,
EV_COL.
Quando uma regra a ser eliminada composta de outras regras, ento no existem
restries para esta eliminao, e o registro referente regra a ser eliminada excludo da
tabela REGRA_COMPOSIO. O processo inverso deve ser reavaliado, visto que a regra a
ser eliminada pode fazer parte de outra regra, neste caso, a eliminao no trivial, pelo fato
de que estas regras fazem parte de um processo de negcio, e necessita da interveno do
usurio. O usurio deve estar ciente de que existe uma dependncia entre a regra a ser
eliminada e a regra que composta de vrias regras. Para manter a consistncia do repositrio
de regras, necessrio avisar o usurio da existncia desta dependncia e solicitar a sua
aprovao, no que se refere eliminao da regra. Esta aprovao pode ser realizada por meio
de uma autorizao ou notificao: por exemplo:- A regra a ser eliminada faz parte de outra
regra. Deseja seguir com o procedimento de eliminao da regra? ou A regra a ser
 122

eliminada faz parte de outra regra..

A sintaxe da operao de gerncia para a eliminao de uma regra :

DROP RULE <nome_regra>;

Para eliminar a regra CATEGORIA_CLIENTE utiliza-se a sentena acima:

DROP RULE CATEGORIA_CLIENTE;

5.2.2.5 Habilitar ou Desabilitar um Conjunto de Regras

Habilitar e Desabilitar um conjunto de regras possvel somente quando as regras

pertenam a um determinado grupo. O efeito desta operao no repositrio de regras o
mesmo que para uma nica operao, habilitar ou desabilitar regras. A sintaxe da operao de
gerncia para habilitar ou desabilitar um conjunto de regras a seguinte:

ENABLE [OR DISABLE] RULESET< nome_grupo_regra >;

Para habilitar um conjunto de regras, necessrio aplicar a operao acima, conforme

apresentado no exemplo a seguir, para o agrupamento de regras denominado universidade.

ENABLE RULESET universidade;

5.3 NAVEGADOR PARA A GERNCIA DE REGRAS

Vrios esforos tm sido realizados, e apresentados na literatura, para oferecer ao

usurio um ambiente no qual seja possvel realizar manutenes em regras e ao mesmo tempo
visualizar o comportamento e a interatividade entre elas (CHAKRAVARTHY;
TAMIZUDDIN; ZHOU, 1995; FORS, 1995; LEMKE; MANTHEY, 1997; MENS, 1998;
BERNDTSSON; MELLIN; HGBERG, 1999; DIAZ; JAIME, 2000; DITTRICH, et al.,
2000). Estes esforos, traduzidos por meio de ferramentas, ocorre em funo da natureza das
 123

regras, estmulo-resposta, derivao e operacionais, que tm a caracterstica de dispararem

outras regras, implicitamente ou explicitamente. Tratando-se de regras estmulo-resposta, o
encadeamento acontece de forma implcita, o que torna difcil a sua visualizao. Esta
situao torna-se mais complexa quando os projetistas das regras no so os mesmo que
desenvolveram a aplicao. As ferramentas existentes consideram um modelo de regras mais
simples, apenas os tipos ECA e EA de regras, sugerido pela linguagem SQL3. Como
conseqncia, um modelo significativamente mais rico em semntica, exige novos esforos
para a visualizao destes encadeamentos.
Foi proposto um repositrio de regras que suporte estes novos tipos de regras, e neste
repositrio foram elaboradas estruturas que armazenam informaes sobre o encadeamento de
regras, seja este encadeamento disparado implicitamente quando explicitamente.
Neste trabalho, apresentado um prottipo de uma ferramenta para auxiliar o usurio,
a consultar informaes sobre as regras, contidas no repositrio de regras, os elementos destas
regras e seus relacionamentos. De posse destas informaes, possvel tomar deciso sobre os
processos de negcio especificados por meio destas regras. Este prottipo se diferencia dos
demais porque tem, a seu favor, um repositrio de regras que trata o armazenamento de
regras, de suas partes, e de seus relacionamentos.
Na Figura 24 apresenta-se a barra de tarefas do prottipo de navegao de regras. O
prottipo possui algumas palavras reservadas (Arquivo, Editar, Operaes, Relatrios e
Ajuda) e figuras de atalho. O Arquivo tem a finalidade gravar, importar, exportar, e ver as
propriedades das regras. Editar tem a finalidade de editar um texto, desfazer operao
realizada, refazer esta operao. Operaes possui todas as operaes de gerncia de regras
possveis de serem realizadas sobre o repositrio de regras, inclusive solicitar informaes
sobre o encadeamento de regras, a partir de uma regra. Relatrios possui alguns padres de
relatrios e Ajuda possui informaes de como utilizar o navegador de regras.

a) b) c) d) e) f) g) h)

Figura 24 Barra de tarefas do prottipo

 124

Na Figura 24 alnea a, apresenta-se um atalho, cuja finalidade estabelecer conexo a

um determinado repositrio de regras. Na alnea b, as duas setas representam uma ao para
atualizar a tela do aplicativo (refresh). Na alnea c, o conjunto de folhinhas amarelas, tem a
finalidade de apresentar as caractersticas da regra selecionada. Na alnea d, a seta em azul
representa o encadeamento de regras, a partir de uma regra assinalada. A cesta de lixo, na
alnea e, uma metfora indicando as regras, grupos ou partes destas que foram eliminadas
pelas operaes responsveis por eliminar uma regra (seo 5.2.2.4), um grupo de regras
(seo 5.2.2.3), eliminar um evento (seo 5.2.1.2), condio (seo 5.2.1.5) ou ao (seo
5.2.1.9). O conjunto de folhas representa os relatrios que podem ser gerados, conforme a
necessidade do usurio. Na alnea g, ilustrado um smbolo de agrupao de regras, com a
finalidade de apresentar os grupos de regras existentes. O sinal de interrogao, na alnea h,
serve para chamar a ajuda on-line, e buscas por palavra-chave.
Na Figura 25 ilustrado o prottipo de um navegador de regras. Uma vez conectado
ao SGBDA, possvel obter uma imagem do repositrio de regras.
Neste repositrio so definidos dois grupos de regras, definidos como alocao de
recursos e emprstimos. Estes grupos so identificados pela seta seguida do nmero 1.
Neste navegador, so apresentadas as informaes sobre os eventos, indicados pela
seta de nmero 2, e os tipos de regras armazenadas no repositrio, indicado pela seta de
nmero 3. Estas regras fazem parte do grupo de regras RegrasEmprstimo que possui
diversos tipos de regras (ECA, ECAA, EA, CAA, CA, A). Para cada tipo de regra, so
identificados seus respectivos nomes, conforme apresentado pela seta 4. As informaes
referentes ao encadeamento implcito de regras so identificadas pela seta 5. Neste item, so
apresentadas as regras responsveis pelo disparo de outra regra e a regras a serem disparadas,
como tambm o evento responsvel pelo encadeamento. A composio de regras
identificada pela seta 6. Neste item, so ilustradas as regras que fazem parte de uma
composio de regras, e sua conseqente prioridade (por exemplo, Nome_Regra(1)). A seta 7
apresenta as permisses que foram dadas para o grupo de regras, da mesma forma, apresenta-
se o responsvel pelo grupo de regra gerado. A sete 8 indica as propriedades da regra.
 125

1
2

Figura 25 - Prottipo de um navegador de regras para o repositrio de regras

5.4 REALIZAO DA PROPOSTA EM UM SBDA GENRICO

As funcionalidades de um SGBDA so representadas um conjunto de capacidades

ativas tais como, deteco de eventos, execuo de regras, compilao de regras, plano de
execuo de regras, entre outros. Estas capacidades podem ser identificadas por meio de uma
arquitetura, de um SGBDA, conforme ilustrado na Figura 26. Uma arquitetura de um SGBDA
determina a funcionalidade e os componentes necessrios para garantir a realizao delas
 126

(PATON, 1998).
Este trabalho prope uma linguagem de Gerncia de Regras, como extenso da
linguagem de regras adotada neste trabalho e descrita no captulo 3. Para adequar a arquitetura
do SGBDA a esta proposta, necessrio estender alguns de seus componentes.

Compilador de
Detector de Eventos
Linguagem de
Gerncia de
Regras

Gerenciador
de Regras

Componentes de
Execuo de Regras Plano de Execuo
de Regras

Repositrio de
Dicionrio de Regras
Dados

Figura 26 Arquitetura de um SBDA genrico (adaptao de PAVON(2005))

Os componentes da arquitetura de um subsistema de execuo de regras foram

estendidos para se adequar linguagem de regras adotada neste trabalho. Portanto, a descrio
a seguir considera que cada componente, da arquitetura apresentada, incorpora as
caractersticas do modelo adotado.
O componente Detector de Eventos tem a finalidade de identificar e notificar as
ocorrncias de eventos ao Gerenciador de Regras. Os eventos detectados so todos os eventos
de banco de dados e evento temporal, sugeridos no modelo adotado. O Gerenciador de Regras
tem a finalidade de armazenar e recuperar as regras do Repositrio de Regras. Ele recupera as
regras do Repositrio sempre que existe uma notificao do Detector de Eventos, e armazena
 127

as regras, uma vez que as regras sejam compiladas pelo Compilador de Linguagem de
Gerncia de Regras. Este Compilador tem a finalidade de compilar os tipos de regras que
foram sugeridos na linguagem adotada. Considerando que a sintaxe adotada similar
sintaxe da linguagem SQL3, ento, este componente precisa ser adaptado para incorporar
estas inovaes. Alm disso, precisa compilar as sintaxes das operaes de gerncia de regras
sugeridas neste trabalho, uma vez que, estas operaes mantm a mesma concepo adotada
na sintaxe da linguagem SQL3..
O Componente de Execuo de Regras tem a finalidade de implementar o modelo de
execuo de regras adotado pela linguagem usada como referncia neste trabalho. Este
componente interage com o componente responsvel pelo Plano de Execuo de Regras,
quando um conjunto de regras disparado pelo mesmo evento.
O Dicionrio de Dados de um SBDA possui estruturas para armazenar regras do tipo
ECA e EA e seus respectivos relacionamentos, porm necessita ser adaptado para os novos
tipos de regras sugeridos pela linguagem adotada neste trabalho. Este trabalho, por sua vez,
sugere uma adaptao do dicionrio de dados redefinindo-o em dois conjuntos de estruturas, a
saber: um conjunto para armazenar dados e outro conjunto para armazenar regras. O primeiro
conjunto mantm o mesmo conceito de dicionrio de dados, e o segundo conjunto, definido
como repositrio de regras, com estruturas propcias para o armazenamento dos tipos de
regras que so sugeridas na linguagem de gerncia de regras. Alm disso, estas estruturas
contemplam informaes sobre o relacionamento entre regras. Estes dois conjuntos coexistem
dentro do banco de dados de um SBDA. Portanto, o banco de dados necessita ser adaptado
para tratar as estruturas oferecidas neste trabalho, sugeridas como extenso do dicionrio de
dados. Na Figura 26, so apresentados dois repositrios separados logicamente, porm
fisicamente fazem parte da mesma estrutura, que refere-se ao banco de dados do SGBDA.
Na Figura 26, os retngulos em negrito so extenses que fazem parte da proposta
desta tese.
 128

5.5 CONCLUSES

Uma caracterstica importante que deve estar presente em um repositrio de regras de

um SGBDA sua capacidade de adaptar-se a mudanas ao longo do tempo. Para que isto
ocorra necessrio o suporte de um modelo de regras que oferea uma linguagem de regras
semanticamente mais rica que o modelo de regras da linguagem SQL3. Isto porque a
linguagem SQL3 limitada, pois a partir dela possvel derivar somente dois tipo de regras
(ECA e EA) e possui somente dois tipos de operaes de gerncia (criar e eliminar uma regra.
Porm, o modelo adotado carece de uma infra-estrutura dotada de operaes de gerncia de
regras e um conjunto de regras de consistncia que garantam a utilizao destas operaes.
Este trabalho prope esta infra-estrutura, sugerindo um conjunto de operaes de
gerncia e um conjunto de regras de consistncia, e desta forma estendendo a linguagem
adotada aqui. Com estas operaes de gerncia, aliadas a este novo modelo de definio de
regras, possvel dar suporte evoluo do repositrio de regras.
No Manifesto de Banco de Dados Ativo proposto por um grupo de pesquisadores da
rea de Banco de Dados Ativos, (ACT-NET CONSORTIUM, 1996), sugerido que o
repositrio de regras suporte modificaes de regras, da mesma forma que os dados assumem
modificaes ao longo do tempo, assim como um SGBDA deve adotar um ambiente que
contenha ferramentas para facilitar a inspeo do conjunto de regras armazenadas no
repositrio de regras, por parte do usurio, por exemplo, por meio de um navegar de regras.
Este captulo contribui para que estas sugestes descritas no manifesto se materializem,
oferecendo um conjunto de operaes de gerncia de regras e um navegador para facilitar a
gerncia destas regras, por parte do usurio.
No captulo 6 apresentado um estudo de caso para validar a proposta deste trabalho.
 129

CAPITULO 6. ANLISE DA PROPOSTA

6.1 INTRODUO

Neste captulo, apresenta-se um estudo de caso de uma aplicao de negcio. Esta

aplicao envolve dois processos de negcio que abrangem a solicitao de auxilio financeiro
para participao em uma feira, denominado auxilio-evento, e o cancelamento deste auxilio-
evento. Os dois processos de negcio so especificados na linguagem de gerncia de regras
proposta. Ambos processos de negcio envolvem regras do tipo 1 e do tipo 2.
Uma vez que os processos foram especificados, uma anlise feita sobre as regras
resultantes, com a finalidade de atender a novos requisitos. Para tal finalidade, so utilizadas
operaes de gerncia de regras.
No final do captulo realizada uma anlise comparativa entre a linguagem de
gerncia de regras e a linguagem SQL3 considerando as diferentes operaes de gerncia de
regras apresentadas neste estudo de caso.

6.2 ESTUDO DE CASO

O estudo de caso apresentado est dividido em trs partes. A primeira parte descreve o
contexto do negcio, a segunda parte especifica as regras de negcio na linguagem de regras
adotada neste trabalho e a terceira parte a avaliao e melhorias adotadas sobre o conjunto de
regras especificado, por meio de operaes de gerncia.

6.2.1 O Contexto do Negcio

Considere uma empresa que possui vrios departamentos. Um destes departamentos

tem a finalidade de realizar pesquisas sobre novos produtos e materiais. medida que os
resultados vo sendo obtidos, estes podem ser apresentados em eventos, ou os funcionrios
podem participar de eventos para conhecer o estado da arte sobre os temas que estiverem
investigando.
A empresa oferece aos funcionrios a possibilidade de participar de eventos. Para
tanto, basta que o funcionrio solicite recurso financeiro para seus gastos pessoais e com o
translado at o evento. Este recurso financeiro necessrio para a participao em eventos
 130

chamado de auxlio-evento. Uma vez que este auxlio foi solicitado, so verificados os pr-
requisitos para esta solicitao, os quais so: o tempo que este funcionrio pertence
empresa, grau de compatibilidade da rea de atuao do funcionrio com o foco do evento e
verificar se a data de solicitao para a participao no evento ocorre antes dos trinta dias da
data de incio do evento. Alm disso, o funcionrio pode pedir um auxlio-evento para um
evento, por ano, desde que o departamento ao qual ele pertence no tenha acumulado
qualquer tipo de penalidade, no mesmo ano de solicitao da solicitao do auxlio. Estas
penalidades ocorrem em funo da desistncia de funcionrios, que obtiveram o auxlio, no
solicitaram cancelamento dele e, tambm no compareceram ao evento.
Uma vez que o funcionrio preencha os requisitos necessrios para a solicitao do
auxlio-evento, necessrio calcular o valor deste auxlio a ser atribudo a ele. O valor do
auxlio calculado em funo do valor da inscrio no evento, translado at o evento e o valor
do recurso outorgado pela empresa (quinze por cento do seu salrio) para custeio de hotel e
alimentao. Estes valores fazem parte de uma cota destinada ao departamento, e ao
ultrapassar o valor desta cota, previamente estabelecida, pela empresa, para o departamento, o
pedido negado.
O funcionrio, aps ter solicitado o auxlio evento, deve esperar para a receber a
notificao de aceitao ou rejeio deste pedido, visto que, existem cotaes de preos a
serem realizadas, em funo dos dados da viagem.
O resultado desta solicitao de auxlio financeiro uma mensagem do tipo O Pedido
de auxlio evento de cdigo P na data dd/mm/aaaa foi APROVADO ou a negao da frase.
Os funcionrios que acumulam participaes em eventos internacionais e eventos nacionais,
recebem gratificaes, como incentivo.
No diagrama de atividades da Figura 26 so apresentados todos os passos do processo
de negcio, relativo a solicitao de auxlio-evento.
 131

Solicitar auxlio
financeiro para evento

Verificar pr-requisitos

no satisfaz

satisfaz

Calcular Data limite de

cancelamento

Calcular valor do auxlio

Verificar se o valor do
auxlio ultrapassa cota
permitida

Comunicar ao cliente que

no ultrapassa ultrapassa o pedido de auxlio no foi
aprovado

Comunicar ao cliente que

o pedido de auxlio foi
aprovado

Figura 26 - Diagrama de atividades do processo de negcio Solicitar auxlio-evento

Considerando que um funcionrio pode se deparar com eventuais problemas, sejam

eles de natureza pessoal ou profissional, que podem levar um funcionrio no viajar a um
determinado evento, ento existe um processo de cancelamento de solicitao de auxlio-
evento, chamado de cancelamento-auxlio-evento, que pode ser solicitado pelo funcionrio.
Este pedido pode ser solicitado somente depois que o processo de solicitao de auxlio-
evento para este funcionrio foi aprovado. Alm disso, existem outros critrios que devem ser
verificados para que o cancelamento seja efetivado. Estes critrios podem ser observados na
Figura 27, e sero detalhados a seguir.
 132

Solicitar cancelamento do
auxlio financeiro para
evento

Verificar pr-requisitos

no satisfaz

satisfaz

Calcular valor da multa

que incide sobre o
funcionrio.

Comunicar ao cliente que

Aplicar penalidade ao o pedido de cancelamento
departamento do auxlio no foi
aprovado

Comunicar ao cliente que

o pedido de cancelamento
do auxlio foi aprovado

Figura 27 - Diagrama de atividades do processo de negcio Cancelar auxlio evento

Os critrios para o pedido de cancelamento-auxlio-evento so: verificar se o pedido

deste cancelamento est dentro dos prazos estabelecidos pela empresa e calcular as multas
associadas a este cancelamento, que devem ser aplicadas ao funcionrio. O perodo de tempo
para o cancelamento-auxlio-evento est entre o final da solicitao do pedido de auxlio-
evento (com aprovao) e uma semana antes da data de participao neste evento. Na Figura
27 so apresentados todos os passos do processo de negcio relativo ao cancelamento de
auxlio evento
Estes dois pr-requisitos, prazo e aceitao da solicitao de auxlio-evento, so
necessrios para que se possa calcular a multa a ser atribuda ao funcionrio. A multa quando
houver, deve-se a dois fatores: multa da companhia area pela devoluo de passagens e
multa por cancelamento de inscrio no evento, alm da devoluo do recurso financeiro para
 133

gastos com alimentao hotel, empresa. Alm da multa, aplicada uma penalidade ao
funcionrio, e ao departamento, que no podero participar de outro evento internacional no
ano corrente..
O resultado da solicitao de cancelamento-auxilio-evento uma mensagem do tipo
O Pedido de cancelamento do auxlio evento de cdigo C na data dd/mm/aaaa foi
APROVADO e o valor da multa M reais ou a negao do pedido de cancelamento-
auxilio-evento

6.2.2 As Regras de Negcio

As regras de negcio associadas aos processos de negcio de solicitao de auxlio

para participao em eventos e de cancelamento desta solicitao de auxlio so descritas a
seguir, de acordo com a seguinte lgica: em primeiro lugar apresentado o esquema de dados
sobre o qual os processos de negcio foram especificados. Logo a seguir, em segundo lugar,
apresentada uma breve descrio em linguagem natural da regra de negcio, para depois, ser
apresentada a sua correspondente representao, na linguagem proposta.
As tabelas utilizadas para o caso prtico so as seguintes:
EVENTO (codEvento, nome, entidadePromotora, dataInicio, dataFim, cidade, pais,
focoEvento, valorInscricao, tipoEvento)
FUNCIONARIO (codFunc, nome, cpf, end, cep, cidade, salario, dataAdmissao,
codCategoria, areaAtuacao, coddepto)
PEDIDO_AUXILIO (numPed, codFunc, codEvento, tipoPedido, dataSolicitaAuxilio,
status, participa, valorAuxilio, dataLimCancelamento,
dataSolicitaCancelamento, solicitaCancelamento)
PARTICIPA_EVENTO (codFunc, codEvento, dataParticipacao)
DEPARTAMENTO (codDepto, nome, cotaAuxilioEvento, quantPenalidades)

Obs: As chaves-primrias esto sublinhadas e as chaves-estrangeiras esto em itlico.

 134

Os atributos abaixo possuem um domnio constitudo dos seguintes valores:

status = {Cancelado, Aprovado, NaoAprovado, Pendente}

tipoEvento = {Nacional, internacional}
participa = {0=no participou, 1=participou}
penalidade = {N=no, S=sim}
solicitaCancelamento = {N=no, S=sim}
tipoPedido = {S= solicitao, C = cancelamento}

Descrio da regra R5:

QUANDO o funcionrio solicita auxilio financeiro para um evento
ENTO deve-se verificar se os pr-requisitos so satisfeitos.

CREATE RULE R5 /*avalia pedido de auxilio financeiro

(estimulo-resposta / ea) */
AFTER INSERT ON PEDIDO-AUXILIO
FOR EACH ROW
DO
BEGIN
:V_codFunc = :new.codFunc;
:V_codEvento = :new.codEvento;
:V_numPed = :new.numPed;

FIRE R10; /* verifica requisitos para pedido de auxilio-evento */

END;
 135

Na Figura 28 ilustrado o encadeamento de regras entre R5 e R10. A regra R5 dispara

a regra R10 por meio de uma operao Fire.

R10
R5 C
E
A
A
A

Figura 28 Encadeamento entre a regra R5 e R10

Descrio da regra R10

SE o funcionrio
- possui 24 meses de casa;
- o foco do evento compatvel com a rea de atuao do funcionrio;
- fez a solicitao do auxilio-evento 1 ms antes do inicio do evento;
- no haja solicitado um auxilio-evento nesse ano;
- pertence a um departamento que no apresente penalidades.
ENTO
- satisfaz os requisitos necessrios para a solicitao de auxilio e
- portanto deve-se :
- calcular a data limite de solicitao de cancelamento evento
- calcular o valor do auxilio a ser atribudo ao funcionrio
- validar a viabilidade de conceder o valor do auxlio.
SENO
- ele no satisfaz os requisitos e deve ser comunicado desta deciso.

CREATE RULE R10 /* verificar os pr-requisitos para

auxilio-evento (Derivao - CAA)*/
WHEN ( (SELECT MONTHS_BETWEEN (SYSDATE, data_admissao)
FROM FUNCIONARIO
WHERE codFunc = :V_codFunc) >= 24)
AND
(EXISTS (SELECT *
 136

FROM EVENTO E, FUNCIONARIO F

WHERE F.codFunc = :V_codFunc
AND E.codEvento = :V_codEvento
AND E.focoEvento = F.areaAtuacao) )
AND
( (SELECT MONTHS_BETWEEN (SYSDATE, data_inicio)
FROM EVENTO
WHERE codEvento = :V_codEvento) >= 1)

AND
(NOT EXISTS (SELECT *
FROM PEDIDO_AUXILIO
WHERE codFunc = :V_codFunc
AND status = 'Aprovado') )
AND
(EXITS (SELECT *
FROM DEPARTAMENTO D, FUNCIONARIO F
WHERE F.codFunc = V_codFunc
AND D.codDepto = F.codDepto
AND D.penalidade = 'N') )
DO

BEGIN
UPDATE PEDIDO_AUXILIO
SET status = 'PENDENTE', tipoPedido = 'S'
WHERE numPed = :V_numPed;

FIRE R15 /*calcular a data limite de solicitao de cancelamento do

auxilio-evento */
FIRE R20; /* calcular o valor do auxilio a ser atribudo ao funcionrio */
FIRE R25 /*validar a viabilidade de conceder o valor do auxlio*/

END;
ELSEDO
BEGIN
UPDATE PEDIDO_AUXILIO
 137

SET status = 'NO APROVADO', tipoPedido = 'S'

WHERE numPed = :V_numPed;

callProcedure ComunicaCliente ('Auxilio Nao Aprovado');

END;

Na Figura 29 ilustrado o encadeamento de regras entre R10 e as regras R15, R20 e

R25. A ao primria de R10 dispara explicitamente trs regras, por meio da operao Fire.

R15 A
R10 C
R20 A
A
A R25 C
A
A

Figura 29 Encadeamento entre a regra R10 e as regras R15, R20 e R25

Descrio da regra R15

CALCULAR a data limite para solicitar o cancelamento do pedido de auxilio ao evento. A
data deve ser uma semana antes da data de inicio do evento.

CREATE RULE R15 /* (operacional - A) */

DECLARE
V_dataLimite EVENTO.dataInicio%type;

DO
BEGIN
 138

SELECT (7 - dataInicio) INTO V_dataLimite

FROM EVENTO
WHERE codEvento = :V_codEvento;

UPDATE PEDIDO_AUXILIO
SET dataLimCancelamento = V_dataLimite
WHERE numPed = :V_numPed;
END;
Descrio da regra R20
CALCULAR o valor auxlio evento atribudo a um funcionrio. O clculo realizado da
seguinte maneira:
- Soma-se o valor da inscrio no evento com o valor do auxilio financeiro que
corresponde a 15 por cento de seu salrio, para custeio de hotel e alimentao.
CREATE RULE R20 /* (operacional - A) */
DECLARE
V_valorInscricao EVENTO.valorInscricao%type;
V_viatico FUNCIONARIO.salario%type;
V_valorAuxilioEvento PEDIDO_AUXILIO.valorAuxilio%type;
DO
BEGIN

SELECT valorInscricao INTO V_valorInscricao

FROM EVENTO
WHERE codEvento = :V_codEvento;

SELECT (salario * 0,15) INTO V_auxilio

FROM FUNCIONARIO
WHERE codFunc = :V_codFunc;

V_valorAuxilioEvento = V_valorInscricao + V_auxilio;

UPDATE PEDIDO_AUXILIO
SET valorAuxilio = V_valorAuxilioEvento
WHERE numPed = :V_numPed;
END;
 139

Descrio da regra R25

SE auxilio financeiro para deslocar-se ao evento no ultrapassar a cota financeira destinada ao
departamento.
ENTO atualizar status e comunicar cliente que pedido aprovado.
SENO atualizar status e comunicar cliente que pedido no aprovado.

CREATE RULE 25 /* avaliar a viabilidade de conceder o valor do auxlio

(Derivao - CAA) */
DECLARE
V_codDepto DEPARTAMENTO.codDepto%type;
WHEN ( (SELECT SUM(valorAuxilio)
FROM PEDIDO_AUXILIO
WHERE dataSolicitaAuxilio >= (SELECT TRUNC (SYSDATE, 'YEAR')
FROM DUAL) ) >=
( SELECT cotaAuxilioEvento
FROM DEPARTAMENTO
WHERE codDepto = :V_codDepto) );
DO
BEGIN
UPDATE PEDIDO_AUXILIO
SET status = 'APROVADO', tipoPedido = 'S'
WHERE numPed = :V_numPed;

callProcedure ComunicaCliente ('Auxilio Aprovado');

END;
ELSEDO
BEGIN
UPDATE PEDIDO_AUXILIO
SET status = 'NO APROVADO', tipoPedido = 'S'
WHERE numPed = :V_numPed;
callProcedure ComunicaCliente ('Auxilio Nao Aprovado');
END;

Obs: SELECT TRUNC (SYSDATE, 'YEAR') FROM DUAL esta sentena considera a data a
partir de primeiro de janeiro do ano corrente.
 140

Na Figura 30 ilustrado o encadeamento de regras pertinentes ao processo de

solicitao auxilio-evento

R10
R5 C
E
A
A
A
R15 A

R20 A

R25 C
A
A

Figura 30 Encadeamento de regras referente ao auxilio-evento

A seguir so apresentadas as regras referentes ao segundo processo de negcio:

cancelamento-auxilio-evento.

Descrio da regra R30

QUANDO um funcionrio solicita cancelamento de um auxilio-evento
SE solicitao do auxilio-evento foi aprovada,
ENTO: verificar se o funcionrio satisfaz, obrigatoriamente, os pr-requisitos para
este cancelamento,
SENO: notific-lo de que o pedido de cancelamento foi negado.

CREATE RULE R30 /* (regra tipo ECAA)*/

AFTER UPDATE OF solicitaCancelamento ON PEDIDO_AUXILIO
FOR EACH ROW
WHEN ( old.status = 'Aprovado'
AND new.solicitaCancelamento = S )
DO
 141

BEGIN
:V_codFunc = :new.codFunc;
:V_codEvento = :new.codEvento;
:V_numPed = :new.numPed;
FIRE R35; /* verifica requisitos para cancelamento-auxilio-evento */
END;
ELSEDO
BEGIN
CallProcedure ComunicaCliente ('No pode ser solicitado');
END;
Na Figura 31 ilustrado o encadeamento de regras entre R30 e a regra R35. A ao primria
de R30 dispara, por meio de uma operao Fire a regra R35.

R30 R35
E C
C A
A A
A

Figura 31 Encadeamento entre a regra R30 e a regra R35

Descrio da regra R35

Esta regra verifica os pr-requisitos de cancelamento-auxilio-evento,
SE as condies dadas a seguir ocorrerem:
- data de cancelamento esta dentro do perodo que compreende uma semana antes do
inicio do evento e depois do encerramento de solicitaes d auxlio-evento.
- status para cancelamento com valor N ( indica que no houve outra solicitao neste
mesmo perodo, para o mesmo evento).
ENTO calcula-se a MULTA a ser atribuda ao funcionrio, como tambm
- atribui-se uma penalidade ao departamento
SENO: notificar que a solicitao no foi aprovada.
 142

CREATE RULE R35 /* verificar os pre-requisitos para

cancelamento-evento (Derivao - CAA)*/
WHEN (( SELECT PA.codEvento
FROM PEDIDO_AUXILIO PA, EVENTO E
WHERE PA.solicitaCancelamento = 'N'
AND PA.dataSolicitaCancelamento > PA.dataSolicitaAuxilio
AND PA. dataSolicitaCancelamento < (7 - E.dataInicio)
AND PA.numPed = :V_numPed);
DO
BEGIN
UPDATE PEDIDO_AUXILIO
SET status = 'Cancelado', tipoPedido = 'C'
WHERE codEvento = :current.codEvento
AND codFunc = :current.codFunc;

FIRE R40 /* calcular multa a ser atribuda ao funcionrio */

FIRE R45 /* atribuir penalidade ao departamento */
ELSEDO
BEGIN
CallProcedure ComunicaCliente ('Cancelamento no aprovado');
END;

Na Figura 32 ilustrado o encadeamento de regras entre a regra R35 e as regras R40 e

R45. A regra R35 possui duas aes, primria e secundria. Na ao primria, so disparadas
por meio da operao Fire, duas regras, e uma regra por meio de uma operao de banco de
dados.
 143

R40 A

R35
C
A R45 A
A

Figura 32 - Encadeamento entre a regra R35 e as regras R40 e R45

Descrio da regra R40

O valor da Multa a ser atribuda (repassado) a um funcionrio calculado da seguinte
maneira:
CALCULAR:
- calculo da multa por devoluo de passagem aplicada pela companhia area;
- calculo da multa por cancelamento de inscrio no evento; e
- devoluo dos 15% do salrio atribudos a auxilio financeiros.

CREATE RULE R40 /*(clculo do valor da multa (Operacional - A)*/

DO
BEGIN
CallProcedure calculaMultaFuncionario( );
END;

Obs: O procedimento calculaMultaFuncionrio representa o clculo da multa a ser

atribuda ao funcionrio. Esta multa a somatria dos valores cobrados pela devoluo da
passagem ao evento, do cancelamento ao evento e devoluo dos recursos financeiros
utilizados para gastos com hospedagem e alimentao.

Descrio da regra R45

ATRIBUIR penalidade ao departamento em funo da desistncia de algum funcionrio
deste departamento (Esta penalidade implica que o departamento no poder participar de
nenhum evento internacional no ano seguinte aplicao da pena).
 144

CREATE RULE R45 /*(Atribuir penalidade (Operacional - A)*/

DO
BEGIN

CallProcedure penalidadeDepartamento( );

UPDATE DEPARTAMENTO
SET penalidade = 'S'
WHERE codFunc = :V.codFunc;

END;
Na Figura 33 apresentado o encadeamento de regras relacionado com o processo de
negcio para cancelar um auxilio evento.

R40 A
R35
R30 C
E
A R45 A
C
A
A
A

Figura 33 - Encadeamento de regras referente ao cancelamento-auxilio-evento

Descrio da regra R50

QUANDO um funcionrio acumula um numero de participaes em eventos,
ENTO recebe gratificaes em seu salrio.
 145

DECLARE
V_quantidade numeric;
CREATE RULE R50 /* Gratificaes regra tipo EA */
AFTER INSERT ON PARTICIPA-EVENTO
FOR EACH ROW
DO
BEGIN

SELECT COUNT(dataParticipacao) INTO :V_quantidade

FROM PARTICIPA_EVENTO
WHERE codFunc = :new.codFunc;

IF V_quantidade > 10 THEN

UPDATE FUNCIONARIO
SET salario = salario + (salario * 0,05)
WHERE codFunc = :new.codFunc;
ENDIF;
END;

Os processos de negcio solicitao e cancelamento de auxilio-evento resultam em

dois conjuntos de regras, encadeadas, e armazenadas no repositrio de regras. Neste
repositrio de regras, possvel observar que existem regras encadeadas por meio de
operaes Fire e por meio de operaes de banco de dados. Da mesma forma, existe uma
regra que no faz parte de nenhum encadeamento, regra R50. O encadeamento de regras,
referente ao primeiro processo de negcio representado pelas flechas vermelhas e o segundo
encadeamento de regra formado pelas flechas azuis. As regras R5, R30 e R50 so regras do
tipo estmulo-resposta e seus eventos, assim como o encadeamento de regras referentes aos
dois processos de negcio so ilustrados na Figura 34
 146

R10
R5 C
E
A
A
A
R15 A

R20 A

R25 C
A
R40 A
A
R35
R30 C
E
A R45 A
C
A
A
R50 E
A
A

Solicitar auxlio evento

Cancelar auxlio evento

Figura 34 - Encadeamento de regras do estudo de caso

6.2.3 As Operaes de Gerncia

O estudo de caso apresentado na seo anterior composto por dois conjuntos de

regras. Um conjunto para solicitar auxilio-evento e outro conjunto para cancelamento desta
solicitao. Considerando que as regras refletem o comportamento dinmico do negcio,
ento mudanas nas especificaes deste negcio, conseqentemente, levam a mudanas nas
regras. O impacto destas mudanas, no repositrio de regras, analisado neste estudo de caso.
Primeiro em funo das operaes de gerncia e, segundo, em funo das operaes de
gerncia sugeridas pela linguagem SQL3. Estas mudanas se apresentam como conseqncia
de novas especificaes no processo de negcio e tambm em funo das melhorias que se
pode dar ao conjunto de regras armazenadas no repositrio de regras, sem mudar a semntica
apresentada pelos processos de negcio, que elas representam. Este processo chamado de
 147

refatorao de regras.
Uma situao possvel de acontecer, referente s modificaes no negcio, ocorre quando
a empresa no tem mais interesse em automatizar o processo de cancelamento de auxilio-
evento. Este controle ser feito manualmente, com a funcionria da empresa, visto que a
empresa passa a valorizar a entrevista, do funcionrio que solicitou o auxilio-evento, com
a funcionria responsvel pelo processo de cancelamento deste auxilio. Para evitar que
sejam eliminadas as regras que representam o cancelamento, optou-se por desabilit-las. A
vantagem de desabilitar estas regras que no futuro, a empresa pode solicitar a reativao
do processo de cancelamento, e desta forma, estas regras j esto disponveis para a
funo desejada.
Para evitar que se desabilite uma regra por vez, optou-se por agrup-las e depois
desabilit-las. Portanto, primeiro as regras so agrupadas e depois desabilitadas.

Seja a seguinte operao de gerncia:

DEFINE RULESET cancelamento-auxilio-evento

ADD RULE R30, R35, R40, R45;

Esta operao agrupa as regras R30, R35, R40 e R45. O seguinte passo desabilitar
este grupo de regras.
Seja a seguinte operao:

DISABLE RULESET cancelamento-auxilio-evento;

Esta operao desabilita o conjunto de regras definido como cancelamento-auxilio-
evento

Anlise da linguagem SQL3

O repositrio de regras contm regras que representam dois processos de negcio,
auxlio-evento e cancelamento-auxilio-evento. O segundo processo sofreu modificaes,
devido s mudanas nas especificaes. Foi solicitado que as regras pertinentes ao segundo
processo de negcio fossem eliminadas. A soluo inicial foi desativ-las, visto que
futuramente poderiam ser reaproveitadas, de forma independente, ou o processo de
 148

cancelamento-auxilio-evento ser utilizado novamente. Esta soluo foi possvel com o auxilio
das operaes de gerncia.
Considerando uma soluo com as operaes disponveis na linguagem SQL3,
somente possvel eliminar as regras relacionadas ao cancelamento-auxilio-evento. Da
mesma forma, estas regras no podem ser reaproveitadas. Para voltar a usar o processo de
cancelamento-auxilio-evento, necessrio criar novamente essas regras. Como a linguagem
SQL3 no possui outros tipos de regras, alm de ECA e EA, todas as regras a serem definidas
so do tipo estmulo-resposta, como conseqncia, estas regras ao serem criadas, novamente,
so associadas a um valor de tempo de criao, utilizado como critrio para executar as
regras que so disparadas pelo mesmo evento. Portanto a ordem de criao das regras deve ser
considerada pelo usurio. Quanto maior o nmero de regras a serem criadas, maior a
complexidade inerente a este processo de criao.

Uma outra situao que deve ser tratada neste repositrio a refatorao das regras, que
foram definidas no repositrio de regras, e que possuem parte do cdigo, repetido. As
regras R10 e R25 possuem parte do cdigo repetido e que por sua vez, podem ser
refatoradas em uma nica regra, que contenha estes cdigos, sem perder a semntica
relativa ao processo de negcio auxilio-evento. A regra R10 possui em sua ao
secundria uma chamada a uma funo, cuja finalidade alertar o usurio que o processo
de solicitao-evento foi cancelado. Este mesmo procedimento existe na regra R25, em
sua ao secundria. Na ao primria desta regra, existe uma chamada a procedimento
que alerta o usurio de que o processo de solicitao auxilio-evento, foi aceito.
Considerando as duas regras, R10 e R25, possvel converter esta lgica em uma
nica regra, definida como regra R27, conforme apresentado a seguir:

Descrio da regra R27

Esta regra tem a finalidade de notificar ao funcionrio que o seu processo de
solicitao de auxilio-evento, ou cancelamento-evento foi aprovado ou cancelado, pela
empresa. Quando o processo do tipo auxlio-evento, ento a regra R27 dispara a regra R28,
que avalia se o processo iniciado pelo funcionrio foi aprovado ou reprovado. Quando o
 149

processo do tipo cancelamento-evento, a regra R27 dispara a regra R29, que avalia o pedido
de cancelamento foi aprovado.

QUANDO o funcionrio, solicita auxilio-evento.

SE: tipo de pedido est relacionado com a solicitao auxilio-evento
ENTO: verificar se solicitao foi aprovada ou reprovada
SENO: verificar se cancelamento foi aprovado.

CREATE RULE R27 /*notificao do pedido de auxilio-evento e

cancelamento (estimulo-resposta / ECAA) */
AFTER INSERT OR UPDATE OF tipoPedido ON PEDIDO-AUXILIO
FOR EACH ROW
WHEN ( :new.tipoPedido = 'S') /*S = solicitao*/
DO
BEGIN
FIRE R28 */notifica o status de auxilio pedido
Aprovado ou Reprovado(CAA)*/
END;
ELSEDO
BEGIN
FIRE R29 */notifica o status de cancelamento pedido
Aprovado(CA)*/
END;

Esta regra R27 do tipo ECAA e compe-se de duas regras R28 e R29. O evento
acontece quando o usurio solicita auxilio-evento, ou cancelamento do auxilio-evento.
A condio da regra verifica se o tipo de pedido Auxilio-evento. Caso afirmativos,
a regra R28 disparada, caso contrrio, a regra R29 disparada.
Na Figura 35 apresentado o encadeamento de regras, incluindo a regra R27, R28 e
R29.
 150

R10
R5 C R28 C
E R29 C
A A
A A
A A
R15 A

R20 A
R27 E
R25 C
A C
A A
A

Figura 35 - Encadeamento de regras considerando a incluso da regra R27.

As definies das regras R28 e R29 so:

Descrio da regra R28

Esta regra tem a finalidade de notificar ao funcionrio que o seu processo de
solicitao de auxilio evento foi aprovado.
Cada vez que um funcionrio solicita auxilio financeiro para um evento, este
funcionrio deve ser alertado automaticamente, pelo sistema, de que o processo de avaliao
foi concludo.

QUANDO o funcionrio, solicita auxilio-evento.

SE: status do pedido de solicitao for aprovado
ENTO: avisar que solicitao foi aprovada
SENO: avisar que solicitao no foi aprovada.

CREATE RULE R28 */notifica o status de auxilio pedido

Aprovado ou Reprovado(CAA)*/
WHEN ( :current.status = 'APROVADO')
DO
BEGIN
 151

callProcedure ComunicaCliente ('Auxilio Aprovado');

END;

ELSEDO
BEGIN
callProcedure ComunicaCliente ('Auxilio Nao Aprovado');
END;

Descrio da regra R29

Esta regra tem a finalidade de notificar ao funcionrio que o seu processo de
cancelamento-auxilio-evento foi aprovado.
Cada vez que um funcionrio solicita o cancelamento do auxilio-evento, este
funcionrio deve ser alertado automaticamente, pelo sistema, de que o processo foi concludo.

QUANDO o funcionrio, solicita cancelamento-auxilio-evento.

SE: status do pedido de cancelamento-auxilio-evento for aprovado
ENTO: avisar que cancelamento foi aprovado

CREATE RULE R29 */notifica o status de cancelamento auxilio pedido

Aprovado ou Reprovado(CA)*/
WHEN ( :current.status = 'CANCELADO')
DO
BEGIN
callProcedure ComunicaCliente ('Solicitao cancelada');
END;

Para inserir a regra R27 no contexto do auxilio-evento, necessrio definir as regras

R27, R28 e R29, alterar a ao secundria da regra R10 e alterar a ao primria e secundria
da regra R25. Estas operaes so apresentadas a seguir:
A operao para a definio da regra R27, R28 e R29 foram apresentadas
anteriormente. Restam apenas as alteraes na regra R10 e R25. Para alterar a regra R10,
utiliza-se a seguinte operao:
 152

ALTER RULE <R10>

MODIFY SECONDARY ACTION ELSEDO
< BEGIN
UPDATE PEDIDO_AUXILIO
SET status = 'NO APROVADO'
WHERE numPed = :V_numPed , tipoPedido = 'S';

END;
>;
As alteraes na regra R25 so as seguintes:
ALTER RULE R25
MODIFY PRIMARY ACTION TO
BEGIN
UPDATE PEDIDO_AUXILIO
SET status = 'APROVADO', tipoPedido = 'S'
WHERE numPed = :V_numPed;
END;

ALTER RULE R25

MODIFY SECONDARY ACTION TO
BEGIN
UPDATE PEDIDO_AUXILIO
SET status = 'NO APROVADO', tipoPedido = 'S'
WHERE numPed = :V_numPed;
END;

Estas operaes modificam, primeiro a ao secundria da regra R10, depois a ao

primria da regra R25 e logo a seguir a ao secundria da regra R25. Uma vez que estas
aes, primria e secundria, foram modificadas, necessrio compilar e lincar com suas
respectivas regras, que esto armazenadas no repositrio de regras.
O impacto desta mudana, no repositrio de regras pode ser analisado em funo do
encadeamento ilustrado na Figura 36. A regra R35, do tipo derivao, possui uma ao
primria e uma ao secundria. Na ao primria definida uma operao de banco de
dados, que leva ao disparo da regra R27. Considerando que a regra R27 utilizada para
notificaes, ento a mesma foi estendida para o processo de cancelamento-auxilio-evento.
 153

Esta organizao auxilia a manuteno destas regras.

Anlise da linguagem SQL3

A refatorao destas regras com a finalidade de melhorar a legibilidade e compreenso
do cdigo, torna-se mais difcil de ser aplicada quando a abordagem envolve somente as
operaes sugeridas pela linguagem SQL3. Isto porque, esta limitao est associada ao
conjunto de operaes oferecidas, criao e eliminao de regras. Portanto, para o caso
apresentado, seria necessrio eliminar e voltar a definir as regras R10, R25 e R35. Da mesma
forma, deveriam ser definidas as regras R27, R28 e R29. Considerando que os tipos de regras
em questo so ECA e EA, e que ao defini-las lhes atribudo um tempo de criao, e que
este tempo de criao utilizado para o critrio de seleo de regras do conjunto de regras
disparadas simultaneamente, ento a quantidade de regras em questo, dificulta a manuteno
do repositrio de regras, no que tange a refatorao de regras.
 154

R10
R40 A
R5 C R35
E R30 C
A E
A A R45 A
A C
R15 A A
A

R20 A A

R50 E
R25 C
A
A R27 E R28 C
A
C A
A A
A
Solicitar auxlio evento
R29 C
Cancelar auxlio evento A

Figura 36 - Encadeamento de regras, considerando a incluso da regra R27 no repositrio de regras.

 155

Para minimizar o nmero de regras ilustrado no encadeamento de regras da

Figura 36, e tambm, para melhorar a legibilidade destas regras, realizada a fuso
das regras R30 e R35. A seqncia de operaes que devem ser seguidas, para a
regra R35, so: adicionar um evento, modificar a condio e modificar a ao
primria. Quanto regra R30, esta deve ser excluda.
Para adicionar um evento utiliza-se a seguinte operao:

ALTER RULE R35

ADD EVENT UPDATE OF solicitaCancelamento ON PEDIDO_AUXILIO
ACTIVATION TIME AFTER
GRANULARITY FOR EACH ROW;

Quando a granularidade e o tempo de ativao no forem especificados, estes

valores so atribudos automaticamente, pelo SGBDA. Para o tempo de ativao, o
valor padro AFTER e para a granularidade, o valor padro FOR EACH ROW.
O resultado desta operao a seguinte sentena:

AFTER UPDATE OF solicitaCancelamento ON PEDIDO_AUXILIO

FOR EACH ROW
Para modificar a condio da regra, utiliza-se a seguinte operao:
ALTER RULE R35
MODIFY CONDITION TO
(SELECT PA.codEvento
FROM PEDIDO_AUXILIO PA, EVENTO E
WHERE PA.solicitaCancelamento = 'N'
AND PA.dataSolicitaCancelamento > PA.dataSolicitaAuxilio
AND PA. dataSolicitaCancelamento < (7 - E.dataInicio)
AND PA.numPed = :V_numPed)
AND
( old.status = 'Aprovado' AND new.solicitaCancelamento = S)
);
Para modificar a ao primria da regra, utiliza-se a seguinte sentena:
 156

ALTER RULE R35

MODIFY PRIMARY ACTION TO
BEGIN
:V_codFunc = :new.codFunc;
:V_codEvento = :new.codEvento;
:V_numPed = :new.numPed;

UPDATE PEDIDO_AUXILIO
SET status = 'Cancelado', tipoPedido = 'C'
WHERE codEvento = :current.codEvento
AND codFunc = :current.codFunc;

FIRE R40 /* calcular multa a ser atribuda ao funcionrio */

FIRE R45 /* atribuir penalidade ao departamento */
END;

A regra R35 passa a ter a seguinte definio:

CREATE RULE R35 /* verificar os pre-requisitos para
cancelamento-evento (Derivao - CAA)*/
AFTER UPDATE OF solicitaCancelamento ON PEDIDO_AUXILIO
FOR EACH ROW

WHEN (( SELECT PA.codEvento

FROM PEDIDO_AUXILIO PA, EVENTO E
WHERE PA.solicitaCancelamento = 'N'
AND PA.dataSolicitaCancelamento > PA.dataSolicitaAuxilio
AND PA. dataSolicitaCancelamento < (7 - E.dataInicio)
AND PA.numPed = :V_numPed)
AND
( old.status = 'Aprovado' AND new.solicitaCancelamento = S)
)

DO
BEGIN
:V_codFunc = :new.codFunc;
 157

:V_codEvento = :new.codEvento;
:V_numPed = :new.numPed;

UPDATE PEDIDO_AUXILIO
SET status = 'Cancelado', tipoPedido = 'C'
WHERE codEvento = :current.codEvento
AND codFunc = :current.codFunc;

FIRE R40 /* calcular multa a ser atribuda ao funcionrio */

FIRE R45 /* atribuir penalidade ao departamento */
END
ELSEDO
BEGIN
CallProcedure ComunicaCliente ('Cancelamento no Aprovado');
END;
A operao para eliminao da regra R30 apresentada abaixo.

DROP RULE R30;

Anlise da linguagem SQL3

As operaes aplicadas regra R35 foram pontuais, ou seja, alterou-se apenas
o necessrio. As operaes de gerncia disponveis na linguagem SQL3, permitem
apenas a definio e excluso das regras. O fato de definir a regra R35, implica que
necessrio avaliar se no existem outras regras com o mesmo evento, pelo fato de
que ela pode ser disparada em conjunto com outras regras.
O repositrio de regras resultante, aps as modificaes realizadas, com a
finalidade de melhorar a legibilidade das regras, ilustrado na Figura 37.
 158

R10 R40 A
R5 C R35
E E
A
A C R45 A
A
R15 A A
A
R20 A
R50 E
R25 C
A
A R27 E R28 C
A
C A
A A
A

R29 C
Solicitar auxlio evento A

Cancelar auxlio evento

Figura 37 - Encadeamento de regras, aps as alterao na regra R35 e eliminao da regra R30.
 159

6.3 CONCLUSES

A finalidade deste captulo foi apresentar um estudo de caso por meio do qual foi
possvel aplicar as operaes de gerncia sugeridas neste trabalho. Considerando que as regras
definidas no repositrio de regras necessitavam adaptar-se a um requisito de negcio, foram
utilizadas operaes que suprissem estas mudanas, sem a necessidade de elimin-las do
repositrio. Da mesma forma, houve a necessidade de realizar manuteno nas regras,
refatorando-as. Nesta refatorao foi reutilizado cdigo de outras regras, e estenderam-se
algumas regras que faziam parte do repositrio.
Este processo de modificao do repositrio de regras para adaptar-se a dinmica de
processos de negcio, por meio da adio de regras, excluso de regras, alterao de regras, e
de suas partes constitui-se na evoluo do repositrio de regras. Esta evoluo, de forma gil,
foi possvel de ser realizada com a linguagem de gerncia de regras proposta.
No captulo seguinte so apresentadas a concluso do trabalho e futuras pesquisas que
podem ser realizadas em funo da linguagem apresentada.
 160

CAPITULO 7. CONCLUSES E PESQUISAS FUTURAS

7.1 PRINCIPAIS CONTRIBUIES

Os SBDAs possuem um dicionrio de dados para armazenar informaes sobre o

esquema de banco de dados e regras. Alm destas estruturas, eles possuem uma linguagem de
gerncia de regras composta por operaes para criao de regras e eliminao das mesmas.
Estas operaes, e as estruturas utilizadas nestes SGBDAs seguem o modelo sugerido pela
SQL3. O conjunto de operaes no flexvel o suficiente para facilitar a evoluo do
dicionrio de dados, da mesma forma que o prprio dicionrio de dados no oferece
flexibilidade para o armazenamento de regras e seus relacionamentos. Esta flexibilidade
fundamental para prover o usurio de mais um ambiente em que ele pode armazenar e
gerenciar suas regras computacionais.
As atuais aplicaes, que manipulam grandes quantidades de dados e regras,
necessitam de um ambiente que suporte o gerenciamento de dados e regras. Os dados j
dispem de uma infra-estrutura adequada para o seu armazenamento e gerenciamento, o que
no ocorre com as regras. Com relao s regras, necessrio um ambiente que garanta, de
forma consistente, a evoluo do repositrio que as mantm.
Esta evoluo somente possvel com um conjunto de operaes de gerncia de regras
tendo como base um repositrio de regras e uma linguagem de gerncia de regras estendida,
visto que o atual dicionrio de dados da linguagem SQL3 no oferece os recursos necessrios
para armazenar, eficientemente, informaes sobre regras. Portanto, uma das contribuies
desta proposta, dentro da rea de regras em banco de dados, a identificao das limitaes
da linguagem SQL3 em relao s operaes de gerncia de regras. Tendo conhecimento
destas limitaes, possvel compreender quais so as operaes que podem ser aproveitadas
e quais devem ser estendidas para permitir uma representao mais apropriada das operaes
de gerncia.
Este trabalho, ao propor uma adequao do paradigma de linguagem de gerncia de
regras, da linguagem SQL3, estendeu-o e adaptou-o com o propsito de adequ-lo s
necessidades atuais das aplicaes. Esta proposta de adequao representa uma mudana no
conceito de armazenamento de regras, sugerido pela linguagem SQL3. Os dados e regras
coexistiro em um mesmo ambiente, tal como era antes, porm cada um deles dispe de um
conjunto de estruturas adequadas sua realidade. Neste sentido, o dicionrio de dados auxilia
 161

o armazenamento dos dados, tendo um conjunto de estruturas para garantir a consistncia dos
dados, por meio das restries. As regras tambm passam a contar com uma infra-estrutura,
denominada repositrio de regras, cuja finalidade armazenar as regras, e dispe de um
conjunto de regras de consistncia para manter a corretude do repositrio de regras.
Os dicionrios de dados que compunham tanto dados quanto regras foram analisados
com a finalidade de identificar seus aspectos positivos e suas respectivas deficincias. At
esta etapa do trabalho, dados e regras coexistem em um mesmo ambiente, sob o domnio de
uma linguagem de definio de dados. Esta linguagem utilizada para definir tabelas, regras
entre outros objetos do banco de dados.
Na busca por oferecer uma linguagem de gerncia de regras com maior expressividade
que a linguagem SQL3, e que pudesse oferecer recursos para as necessidades das atuais
aplicaes, foi analisado o modelo de definio de regras da linguagem proposta por Pavn
(2005). Esta linguagem teve como premissa estender o modelo de regras da linguagem SQL3,
definindo um conjunto de tipos de regras, com maior expressividade, que os tipos sugeridos
pela linguagem SQL3.
Uma outra contribuio deste trabalho a realizao de uma avaliao crtica do
modelo de definio de regras, com a finalidade de identificar questes que no foram
tratadas pelo modelo adotado, tais como: operaes para a alterao de regras, operaes para
alterar partes de uma regra e anlise de um repositrio de regras para armazenar os diferentes
tipos de regras propostos.
A partir desta anlise, identificaram-se as caractersticas dos tipos de regras oriundos
do modelo adotado. Estas caractersticas serviram de base para a elaborao do repositrio de
regras, alm disso, as informaes sobre as operaes de gerenciamento de regras
completaram a anlise necessria para identificar as estruturas iniciais, que servem para
armazenar as regras.
Alm destas estruturas, foi identificado um conjunto de meta-regras que deveriam
existir para garantir a consistncia das informaes que eram manipuladas no repositrio de
regras. Estas situaes inconsistentes poderiam ocorrer em funo do uso das operaes de
gerncia, como por exemplo, adicionar uma ao secundria a uma regra que no possui
condio (EA). As estruturas so tabelas que armazenam informaes sobre as regras, suas
partes e o relacionamento entre elas. Este relacionamento representa o mapeamento
correspondente ao encadeamento de regras, que surge em funo de um conjunto de regras
 162

caracterizadas pelas regras do tipo estmulo-resposta. Alm disso, so armazenadas

informaes sobre a composio de regras e a conseqente prioridade definida entre elas.
Portanto, uma das contribuies deste trabalho consiste na extenso do repositrio de
regras da linguagem SQL3. Estender o repositrio de regras representa especificar um
conjunto de estruturas adicionais para armazenar os tipos de regras adotados neste trabalho.
Estas estruturas adicionais, focadas nas regras, contemplam um outro conjunto de regras,
necessrias para manter a sua consistncia.
A partir da concepo do repositrio de regras, foram elaboradas operaes de
gerncia de regras. Estas operaes so utilizadas para criar uma regra, eliminar uma regra,
alterar parte de uma regra. A extenso das operaes de gerncia de regras passa a ser outra
contribuio valiosa. Estender as operaes de gerncia de regras implica em prover a
linguagem de regras adotada neste trabalho de um conjunto significativo de operaes para
criao, alteraes e excluses de regras, com a finalidade de facilitar a manuteno de regras,
e de suas partes. Esta extenso aliada extenso do repositrio de regras, habilita este
repositrio a garantir a evoluo do mesmo. Esta evoluo acompanhada de mecanismos
que garantem a sua consistncia.
Considerando que nem todo usurio domina ou conhece a linguagem de gerncia de
regras, foi sugerido um navegador de regras, cuja finalidade permitir a edio de um
conjunto de regras existente no repositrio de regras. Desta forma, o navegador prov
assistncia ao usurio, de modo que este possa se beneficiar das funcionalidades de uma
ferramenta que serve para navegar sobre o repositrio de regras. Esta proposta de um
prottipo para navegao sobre o repositrio de regras mais uma contribuio da tese,
pois a evoluo do repositrio de regras deve vir acompanhada de ferramentas que dem
suporte ao usurio, facilitando-lhe o uso do repositrio de regras por meio de uma interface
apoiada com usabilidade.

7.2 FUTURAS PESQUISAS

A especificao de uma linguagem de gerncia de regras em SBDA uma

contribuio importante para que o usurio tenha outra opo, flexvel, em se tratando de
armazenamento e gerncia de regras de negcio. Para que esta proposta se materialize,
necessrio que seja completado um conjunto de tarefas. Estas tarefas incluem aspectos
 163

relacionados execuo, e armazenamento de regras, bem como ferramentas de apoio ao

usurio.
Este trabalho abordou os aspectos relativos especificao de um repositrio de regras
e uma linguagem de gerncia de regras, porm necessrio que outros aspectos sejam
considerados, gerando assim outras linhas de pesquisas. Dentre as pesquisas futuras sugere-se
a adaptao do repositrio de regras a um SGBDA comercial ou acadmico. Esta
adaptao implica na elaborao de um conjunto de estruturas para armazenar regras. Estas
estruturas podem ser estendidas a qualquer outro ambiente que suporte o gerenciamento de
regras, como por exemplo, ambiente para workflows. Alm desta adaptao, importante que
o SGBDA interprete a operaes de gerncia, realizadas pelo usurio ou por uma ferramenta,
portanto um outro trabalho que pode ser realizado o desenvolvimento de um compilador
da linguagem de gerncia de regras, considerando as meta-regras sugeridas. Uma vez que o
compilador esteja implementado, anlises de desempenho da linguagem poderiam ser
verificadas.
A elaborao de uma ferramenta para auxiliar ao usurio no gerenciamento de regras,
armazenadas no repositrio de regras, tal como um navegador de regras, alinhado aos
conceitos de usabilidade, uma linha de pesquisa que pode ser desenvolvida como mais um
trabalho futuro, principalmente porque a expressividade da linguagem de regras melhorou,
quando comparada com a linguagem SQL3, e os trabalhos sugeridos nesta linha, considera
somente o modelo de regras da linguagem SQL3.
Tendo em vista que o repositrio de regras conter inmeras regras, importante
verificar se existem ciclos indesejados no repositrio. Estes ciclos ocorrem em funo de
disparos implcitos e disparos explcitos. Uma outra linha de pesquisa desenvolver um
analisador de regras, identificar as propriedades de terminao e confluncia de regras em
conjunto de regras, ou seja, verificar a existncia destes ciclos infinitos de regras e tambm
verificar se determinados grupos de regras so confluentes. Ciclos infinitos so tratados na
literatura como terminao de regras. Um conjunto de regras dito confluente se a partir de
um estado inicial, existem vrios caminhos que levam a um mesmo estado final de execuo.
Considerando que existem regras no formato XML, ento o repositrio pode ser
estendido e propor outras operaes de gerncia para este tipo de regras, assim possvel
armazenar e gerenciar estes tipos de regras de negcio, usado em intercambio eletrnico de
informaes, por meio de documentos XML.
 164

REFERNCIAS BIBLIOGRFICAS

ABITEBUL, S.; BENJELLOUN, O.; MILO,T. Positive active XML. In: ACM
SIGMOD-SIGACT-SIGART SYMPOSIUM ON PRINCIPLES OF DATABASE
SYSTEMS (PODS), 23, Paris, 2004. Proceedings. ACM Press, New York, 2004,
p.14-16.

ACT-NET CONSORTIUM. The active database management system manifesto: a

rulebase of ADBMS features. ACM SIGMOD Record, v.25, n.3, p.40-49, Sept.
1996.

AIKEN, A.; WIDOM, J.; HELLERSTEIN, J. M. Static analysis techniques for

predicting the behavior of database production rules. ACM Transactions on
Database Systems (TODS), v.20, n.1, p.3-41 1995

AIKEN, A.; HELLERSTEIN, J. M ;WIDOM, J. Behavior of database production

rules: termination, confluence and observable determinism. In: ACM SIGMOD
INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA, San Diego,
1992. Proceedings. New York: ACM Press, 1992. p.59-68.

AMGHAR, Y.; MEZIANE, M.; FLORY, A. Using business rules within a design
process of active databases. Journal of Database Management, v.11, n.3, p.3-15,
2000.

BAJEC, M.; KRISPER, M. Issues and challenges in business rule-based information

systems development In: EUROPEAN CONFERENCE ON INFORMATION
SYSTEMS, 30, Regensburg, Germany Proceedings (Bartmann D, Rajola F,
Kallinikos J, Avison D, Winter R, Ein-Dor P, Becker J, Bodendorf F, Weinhardt C
eds.) (cpia eletrnica ), Regensburg, Germany, 12p. 2005.

BAILEY, J.; POULOVASSILIS, A.; NEWSON, P. A dynamic approach to

termination analysis for active database rules. In: INTERNATIONAL
CONFERENCE ON COMPUTATIONAL LOGIC, 1, London, 2000. Proceedings.
London: Springer-Verlag, 2000. p. 1106-1120.

BARALIS, E.; CERI, S.; PARABOSCHI, S.; Compile-time and runtime analysis of
active behaviors. IEEE Transactions on Knowledge and Data Engineering, v.10,
n.3, p.353-370, May, 1998.
 165

BARALIS, E.; WIDOM, J.; An algebraic approach to static analysis of active

database rules, ACM Transactions on Database Systems, v.25, n.3, p.269-332,
Sept, 2000.

BERNDTSSON, M. Management of rules in object-oriented databases. In: BALTIC

WORKSHOP ON NATIONAL INFRASTRUCTURE DATABASES: PROBLEMS,
METHODS AND EXPERIENCES. Vilnius, Lithuania. 1994. Proceedings. Vilvius,
v.1, May, 1994, p.78-85.

BERNDTSSON, M.;MELLIN, J.; HGBERG, U.; Visualization of the composite

event detection process. In: USER INTERFACES TO DATA INTENSIVE
SYSTEMS, Edinburgh, Scotland. Proceedings. Washington, IEEE Computer Society
Press, 1999. p. 118-128

BONATTI, P.A.; SHAHMEHRI, N.; DUMA, C.; et al. Rule-based policy

specification: state of the art and future work, Project deliverable D1, Working
Group I2, EU n.E REWERSE. 2004. (Technical Report - IST-2004-506779 ).
Disponvel em: http://rewerse.net/deliverables/i2-d1.pdf. Acesso em: 15 abr. 2007.

BONIFATI, A.; CERI, S.; PARABOSCHI, S. Active rules for XML: a new paradigm
for E-services The VLDB Journal v.10, p.3947, Aug. 2001.

BUSINESS RULES GROUP. GUIDE Business rules project. Final Report, Revision
1.3. Business Rules Community. 2000. Disponvel em
<http:www.dbpd.comvault9809darc.html> Acesso em: 12 fev. 2005.

BUTLERIS, R.; KAPOCIUS, K. The business rules repository for information

systems design. In: CONFERENCE ON ADVANCES IN DATABASES AND
INFORMATION SYSTEMS (ADBIS 2002), 6. Bratislava, Proceedings, Darmstadt,
Digital Library Forum , 2002. p.64-77.

BRY, F.; ECKERT, M.; Twelve theses on reactive rules for the web. In.
PROCEEDINGS OF THE WORKSHOP ON REACTIVITY ON THE WEB (EDBT
Workshop 2006). Munich, Germany, Proceedings. Springer, Munich 2006. p-842-
854

CERI, S.; COCHRANE, R.J.; WIDOM, J. Practical applications of triggers and

constraints: successes and lingering issues. In: INTERNATIONAL CONFERENCE
ON VERY LARGE DATA BASE, 26., Cairo, 2000. Proceedings. San Francisco:
Morgan Kaufmann, 2000. p.254- 262.
 166

CERI, S.; MANTHEY, R; Consolidated specification of chimera. Dipartamento di

Elettronica e Informazione, Politecnico di Milana, Milano, Technical Report. 84p,
[IDEA.DE.2P.006.01, ESPRIT Project 6333], Nov. 1993.

CERI, S.; RAMAKRISHNAN, R.; Rules in database systems. ACM Computing

Surveys, v.28, n.1, p.109-111, Mar. 1996.

CERI, S.; WIDOM, S.; Deriving production rules for constraint maintenance In:
INTERNATIONAL CONFERENCE ON VERY LARGE DATA BASES, 16,
Brisbane. Australia Proceedings Morgan Kaufmann Publishers, San Francisco. 1990.
p.566-577.

CERI, S.; WIDOM, S.; Production rules in parallel and distributed database
environments. In: INTERNATIONAL CONFERENCE ON VERY LARGE DATA
BASE (VLDB), 18, Vancouver, Canada Proceedings, Morgan Kaufman pubs. (Los
Altos CA), Vancouver, 1992, p.339-351.

CHAKRAVARTHY, S. et al. Composite events for active databases: semantics,

contexts and detection. In: INTERNATIONAL CONFERENCE ON VERY LARGE
DATA BASE(VLDB), 20, Santiago, Chile Proceedings, Morgan Kaufmann
Publishers, San Francisco, 1994. p.606-617.

CHAKRAVARTHY, S.; MISHRA, D. Snoop: an expressive event specification

language for active databases. Gainesville, Florida: Department of Computer and
Information Sciences, University of Florida, 34p. [Technical Report UF-CIS-TR-93-
007]. Mar. 1993

CHAKRAVARTHY, S.; TAMIZUDDIN, Z.; ZHOU, J. A visualization and

explanation tool for debugging ECA rules in active databases. In:
INTERNATIONAL WORKSHOP ON RULES IN DATABASE SYSTEMS, 2,
Athens, Greece. Proceedings, Springer-Verlag, London, 1995. p.197-212.

COLLET, C.; COUPAYE, T.; SVENSEN T.; NAOS: efficient and modular reactive
capabilities in an object-oriented database system. In: INTERNATIONAL
CONFERENCE ON VERY LARGE DATA BASE(VLDB), 20, Santiago, Chile
Proceedings, Morgan Kaufmann Publishers, San Francisco, 1994. p.132-143.
 167

COUCHOT, A.; Improving active rules termination analysis by graphs splitting, In:
EAST - EUROPEAN CONFERENCE ON ADVANCES IN DATABASE AND
INFORMATION SYSTEMS (ADBIS), 5., Vilnius, Lithuania, 2001. Proceedings.
London: Spring- Verlag. 2001. p.64-77.

DIAZ, O.; JAIME, A.; Depuracin de disparadores en bases de datos activas. In:
JORNADAS DE INGENIERA DEL SOFTWARE Y BASES DE DATOS (JISBD), 4.
Cceres Proceedings Escuela Politecnica, Universidad de Extremadura. 2000. p.151-
162

DIAZ, O.; PATON, N.; GRAY, P.; Rule management in object oriented database: a
uniform approach. In: INTERNATIONAL CONFERENCE ON VERY LARGE
DATA BASE (VLDB), 17, Barcelona. Proceedings. Morgan Kaufmann, 1991. p.317-
326.

DITTRICH, K. R. et al. SAMOS in hindsight: experiences in building an active

object-oriented DBMS. 31p. Department of Computer Science, University of
Zurich, [Technical Report]. May. 2000.

ELIZONDO, A. J.; Reglas activas: soporte y manejo en las bases de datos

orientadas a objetos. 1998, 193p. Tese (Doutorado) Departamento de Lenguajes y
Sistemas informticos. Universidad del Pas Basco, San Sebastin. 2005.

ELMASRI, R.; NAVATHE, S.B. Sistemas de banco de Dados. 4.ed. So Paulo,

Pearson-Addison Wesley, 2005. 724p.

ENGSTRM, H; BERNDTSSON, M.; LINGS, B. ACOOD essentials, Department of

Computer Science, University of Skvde, 26p. [technical Report HS-IDA-TR-97-
010]. Oct.1997.

FORS, T.; Visualization of rules behavior in active databases. In: WORKING

CONFERENCE ON VISUAL DATABSE SYSTEMS (VDB-3) IFIP2.6, 3, Skvde,
Sweden Procedings. Chapman & Hall, London 1995. p.215-231.

FORTIER, P. SQL3:Implementing the SQL Foundation Standard. Ed. McGrow-Hill,

1999. 414p.

GATZIU, S. The SAMOS active DBMS prototype. In: HELLENIC CONFERENCE

IN INFORMATICS, 6, Atenas, Grecia, Procedings. Atenas: Greek Computer
Society, 1997.
 168

GEPPERT, A.; GATZIU, S.; DITTRICH, K. R. Rulebase evolution in active object-

oriented database systems: adapting the past to future needs. Zurich: Department
of Computer Science, University of Zurich, 23p. 1995. [Technical Report 95.13].
1995.

GEPPERT, A.; GATZIU, S.; DITTRICH, K.R.; FRITSCHI, H.; VADUVA, A.;
Architecture and Implementation of the active object-oriented database
management system SAMOS. Zrich, Institut fr Informatik, 39p. 1995a.
[Technical Report 95.29 a].1995a

GUERRINI, G. An active and deductive object-oriented data model. 1998. 280p.

Tese (Doutorado) Dipartimento di Informatica e Scienze dell'Informazione,
University of Genova. Genova. 1998

GUISHENG, Y.;QUN, L.; JIANPEI, Z.; JIE, L.; DAXIN, L.; Petri based analysis
method for active database rules. IEEE International Conference on Systems,
Man, and Cybernetics, v.2, p.858-863, Oct. 1996

HANSON, E.N. The design and implementation of the ARIEL active database rule
system. IEEE Transaction on Knowledge and Data Engineering, v.8, n.1, p.167-
172, Fev. 1996.

HERBST, H.; MYRACH. T. A repository system for business rules. In: IFIP TC-2
WORKING CONFERENCE ON DATA SEMANTICS: DATABASE
APPLICATIONS SEMANTICS, 6, London. Procedings, Chapman & Hall London,
1995. p.119-139.

HEUSER, C. A. Projeto de banco de dados.4 ed. Porto Alegre, Sagra Luzzatto.

2004. 236.

ILOG RULES. Business Rules. 2005. Disponvel em: <http://www.ilog.com/> Acesso

em: 12 May. 2007.

ISO/IEC 9075-2:1999. Information technology database languages SQL Part

2: foundation (SQL/Foundation). 1151p. 1999. New York: American National
Standards Institute - NASI, 1999.

JAIME, A.E. Regras activas: soporte y manejo en las bases de datos orientadas a
objetos. 1998. 193p. Tese (Doutorado) Departamento de Lenguajes y Sistemas
Informticos. Universidad del Pas Vasco. 1998
 169

KANGSABANIK, P. On transaction modeling and concurrency control in active

DBMS, 1998. 180p. Tese (doutorado) Department of Computer Science &
Engineering, Indian Institute of Technology. Kharagpur. 1998.

KAPPEL, G.; KRAMLER, G.; RETSCHITZEGGER, W.; TriGS debugger a toll for
debugging active database behavior. In: INTERNATIONAL CONFERENCE ON
DATABASE AND EXPERT SYSTEMS APPLICATIONS. Proceedings LNCS,
Springer, Munich, Germany, 2001. p-410-421.

KAPPEL, G.; RETSCHITZEGGER, W.; The TriGS active object-oriented database

system an overview; ACM SIGMOD Record, v.27, n.3, Sept. 1998. p.36-41.

LANG, P. A. et al. Graphical editor for the conceptual design of business rules. In:
INTERNATIONAL CONFERENCE ON DATA ENGINEERING, 14, Orlando,
Proceedings IEEE Computer Society, Washington. 1998. p.599.

LEMKE, T.; MANTHEY, R.; The passive rule design tool: tool documentation.
26p. 1997. University of Bonn, Department of Computer Science III. [Technical
Report. IDEA.DE.22.O.010]. Mar. 1997.

MENS, K et al. Tools and environments for business rules In: EUROPEAN
CONFERENCE ON OBJECT-ORIENTED PROGRAMMING (ECOOP - Workshop
Report), 12. Belgium. Proceedings. Programming Technology Lab, Belgium, 1998.
p.189-196.

MORGENSTERN, M.; Active database as a paradigm for enhanced computing

environments. In: INTERNATIONAL CONFERENCE ON VERY LARGE DATA
BASE (VLDB), 9, Florence, Italy Proceedings Morgan Kaufmann Publishers San
Francisco. 1983. p. 34-42.

MORIARTY, T.; Business rule management facility, Database Programming &

Design, Sept. 1998. Disponvel em <http:www.dbpd.comvault9809darc.html> Acesso em:
12 Fev. 2005.

ORACLE CORPORATION. Oracle10g database reference, Release 1 Disponvel em

<http://www.oracle.com/technology/documentation/index.html> Acesso em: 12 May. 2007.

PATON, N. W.; DAZ, O.; Active database systems. University of Manchester

ACM Computing Surveys. V.31, n.1, p.63-103. Mar. 1999.
 170

PATON, N. W. Active rules in database systems, Ed. Springer Verlag, New York,
USA. 1998, p.439.

PAVON, J.; Representao de estruturas de conhecimento em sistemas de bancos

de dados, 1996. 119p. Dissertao (Mestrado). Escola Politcnica da Universidade
de So Paulo, So Paulo. 1996.

PAVON, J.; VIANA, S.; CAMPOS, E.G.L.; Anlise da linguagem SQL3 com
relao especificao de regras de negcio, In: CONFERNCIA LATINO
AMERICANA DE INFORMTICA, 2006, Santiago do Chile. CLEI06, Santiago do
Chile, 2006. p.1-10. 1 CD-ROM.

PAVON, J.; Um modelo de regras para sistemas de banco de dados ativos. 2005.
126p. Tese (Doutorado) Departamento de Engenharia de Computao e Sistemas
Digitais. Escola Politcnica da Universidade de So Paulo. So Paulo. 2005.

POSTGRESQL. Postgresql documentation, Version 8.0.1. 2005 Disponvel em

http://www.postgresql.org/docs/8.0/static/index.html. Acesso em: 04 jan. 2005.

RODRIGUES, J. P.; CORREIA, J. O repositrio XML do SIGDiC. In:

CONFERENCIA NACIONAL SOBRE XML: APLICAES E TECNOLOGIAS
ASSOCIADAS, 3, Casa da Torre, Vila Verde, Braga. (XATA2005).Acta da
Conferncia, s/n, Fev, 2005.

ROSS, R. G.; Principles of the rules business approach. 1ed. New York. Ed.
Addison Wesley, 2003. 400p.

RULEMACHINES. Business rule studio, 2000. Disponvel em

<http:www.rulemachines.com>. Acesso em: 12 Fev. 2005.

STONEBRAKER, M. The Integration of rule systems and database systems. IEEE

Transaction on Knowledge and Data Engineering, v.4, n.5, p.415-423, Oct. 1992.

STONEBRAKER, M.; HEARST, M.; POTAMIANOS, S. A commentary on the

POSTGRES rules system. ACM SIGMOD Record v.18, n.3, p.5-11, Sept.1989.

STONEBRAKER, M.; WOODFILL, J.; ANDERSEN, E. Implementation of Rules

in Relational Database Systems EECS Department, University of California,
Berkeley, 10p. 1983. [Technical Report UCB/ERL M83/54]. 1983.
 171

TORRICO, F.N.; TANAKA, A. K.; MOURA, A.M.C. Especificao de regras de

negcio para banco de dados relacional-objeto. In: CONFERNCIA
LATINOAMERICANA DE INFORMATICA (CLEI), 26. Cidade de Mxico, 2000.
Anais. Monterrey - Mexico. (meio eletronico), 2000. 13p.

TRKER, C. Schema evolution in SQL-99 and commercial (Object-) relational

DBMS. In: WORKSHOP ON FOUNDATIONS OF MODELS AND LANGUAGES
FOR DATA AND OBJECTS, Dagstuhl Castle, Germany, Sept. 2000. Proceedings.
Springer-Verlag Berlin, 2001. p.163-181.

TRKER, C.; GERTZ, M., Semantic integrity support in SQL:1999 and Commercial
(Object-) Relational Database Management System. VLDB Journal, v.10, p.241-
269, Jun. 2001.

VADUVA, A. Rule Development for active database ystem. 1999. 163p. Tese
(Doutorado) - Department of Informatics at the University of Zurich, University of
Zurich. Zurich, 1999

VADUVA, A.; GATZIU, S.; DITTRICH, K. R. Investigating termination in active

database systems with expressive rule languages. In: INTERNATIONAL
WORKSHOP ON RULES IN DATABASE SYSTEMS, 3, Skovde, Sweden
Proceedings. Springer-Verlag London, 1997. p.149-164.

VANHATALO, J.; KOEHLER, J.; LEYMANN, F. Repository for business processes

and arbitrary associated metadata, In: INTERNATIONAL CONFERENCE ON
BUSINESS PROCESS MANAGEMENT (BPM2006), 4, Vienna,. Proceedings.
Lucius & Lucius, UTB, Vienna, 2006. p.25-31.

VASILECAS, O.; LEBEDYS, E. Moving business rules from system models to

business rules repository, INFOCOMP-Journal of Computer Science.v.5, n.2,
p.11-17, Jun. 2006.

VIANA, S.; PAVON, J.;ALMEIDA JR., J.R. Rule management in database systems.
In: INTERNATIONAL CONFERENCE ON COMPUTING (CIC06), 15, Mxico,
2006. Proceedings. Cidade do Mxico, IEEE Computer Society Press, 2006. p.315-
322.

VON HALLE, B.; Business rules applied. New York. Ed. John Wiley & Sons, 2002.
546p.
 172

WIDOM, J. The Starburst active database rule system, IEEE Transaction on

Knowledge and Data Engineering. v.8, n.4, p.583-595, Aug. 1996.

ZIMMER, D.; UNLAND, R.; MECKENSTOCK, A. Rule termination analysis based

on petri nets. In: WORKSHOP ON ON DATABASES: ACTIVE AND REAL-TIME,
Maryland Proceedings ACM Press,New York, 1996. p.29-32.
 173

ANEXO A Resumo das Sintaxes Proposta.

1. Alterar o evento de uma regra

ALTER RULE <nome-regra>

MODIFY EVENT TO <identificao da operao> [{<OR identificao da
operao> <objeto que sofre a ao>}] |
<identificao da data_hora>;
2. Eliminar o evento de uma regra

ALTER RULE <nome-regra>

DROP EVENT <identificao da operao> [{<OR identificao da
operao> <objeto que sofre a ao>}] |
<identificao da data_hora>;
3. Adicionar um evento a uma regra

ALTER RULE <nome-regra>

ADD EVENT <<identificao da operao> [{<OR identificao da
operao> <objeto que sofre a ao>}] |
<identificao da data_hora>;
[ACTIVATION TIME <identificao do tempo de ativao>]
[GRANULARITY <identificao da granularidade>];
4. Adicionar uma condio a uma regra

ALTER RULE <nome-regra>

ADD CONDITION [<operador unrio>] <elemento - condio>
[<conector> <elemento - condio>] ...
5. Eliminar a condio de uma regra

ALTER RULE <nome-regra>

DROP CONDITION;
6. Alterar a condio de uma regra

ALTER RULE <nome-regra>

MODIFY CONDITION TO [<operador unrio>] <elemento - condio>
[<conector> <elemento - condio>] ...
 174

7. Adicionar uma ao a uma regra

ALTER RULE <nome_regra>

ADD SECONDARY ACTION <ao secundria>

8. Modificar a ao de uma regra

ALTER RULE <nome_regra>

MODIFY [PRIMARY | SECONDARY] ACTION <ao primaria | secundria >;
9. Eliminar a ao de uma regra

ALTER RULE <nome_regra>

DROP [PRIMARY | SECONDARY] ACTION;
10. Alternar as aes de uma regra

ALTER RULE < nome_regra >

CHANGE ACTION FROM [PRIMARY] TO [SECONDARY];
11. Habilitar ou Desabilitar uma regra

ENABLE [OR DISABLE] RULE < nome_regra >;

DISABLE RULE < CATEGORIA_CLIENTE>;

12. Agrupamento de regras

CREATE RULESET < nome_grupo_regra >

ADD RULE [lista de regras]
[OR DELETE RULE [lista de regras]]
13. Eliminar Grupo de Regras

DROP RULESET <nome_grupo_regra>;

14. Eliminar uma regra

DROP RULE <nome_regra>;

15. Habilitar ou Desabilitar um Conjunto de Regras

ENABLE [OR DISABLE] RULESET< nome_grupo_regra >;