uma linguagem de gerÊncia de regras como … · 3.3.2.2 outros mecanismos associados ao modus...

1

SIDNEY DA SILVA VIANA

UMA LINGUAGEM DE GERNCIA DE REGRAS COMO EXTENSO DA LINGUAGEM SQL3

Trabalho apresentado Escola Politcnica da Universidade de So Paulo para a obteno do ttulo de Doutor em Engenharia Eltrica.

So Paulo

2007

2

SIDNEY DA SILVA VIANA

UMA LINGUAGEM DE GERNCIA DE REGRAS COMO EXTENSO DA LINGUAGEM SQL3

Trabalho apresentado Escola Politcnica da Universidade de So Paulo para a obteno do ttulo de Doutor em Engenharia Eltrica.

rea de Concentrao: Sistemas Digitais

Orientador: Prof. Dr. Jorge Rady de Almeida Junior

So Paulo

2007

3

Este exemplar foi revisado e alterado em relao verso original, sob responsabilidade nica

do autor e com anuncia de seu orientador.

So Paulo, 15 de Agosto de 2007

Assinatura do autor

Assinatura do orientador

FICHA CATALOGRFICA

Viana, Sidney da Silva

Uma linguagem de gerncia de regras como extenso da linguagem SQL3 / S. da S. Viana. -- So Paulo, 2007.

174 p.

Tese (Doutorado) - Escola Politcnica da Universidade de So Paulo. Departamento de Engenharia de Computao e Sis-temas Digitais.

1.Banco de dados ativos 2.Gerncia de regras 3.SQL3 I.Universidade de So Paulo. Escola Politcnica. Departamento de Engenharia de Computao e Sistemas Digitais II.t.

4

DEDICATRIA

Aos meus pais

5

AGRADECIMENTOS

Ao meu orientador, Prof. Dr. Jorge Rady Almeida Junior, pela orientao dedicada e pelos valiosos comentrios, crticas e sugestes.

A prof. Dra. Edit Grassiani Lino de Campos, que me ensinou o caminho a ser trilhado.

A minha famlia, pelo apoio e incentivo constantes, motivaes essenciais para que eu chegasse fase final.

Aos colegas pelo incentivo e colaborao.

A todos que colaboraram direta ou indiretamente para a concluso deste trabalho.

6

SUMRIO

Lista de Figuras

Lista de Tabelas

Lista de Abreviaturas

Resumo

Abstract

1 INTRODUO ............................................................................................ 1

1.1 MOTIVAO ........................................................................................... 1

1.2 OBJETIVO ................................................................................................ 8

1.3 ORGANIZAO DO TRABALHO ............................................................ 9

2 REGRAS EM BANCO DE DADOS ATIVOS............................................... 11

2.1 INTRODUO ....................................................................................... 11

2.2 REVISO DO ESTADO DA ARTE SOBRE REGRAS EM SGBDA .......... 11

2.3 REGRAS EM SISTEMAS DE BANCO DE DADOS ATIVOS ................... 14

2.3.1 RESTRIES DE INTEGRIDADE ................................................................15

2.3.2 DOMNIOS E ASSERES.........................................................................17

2.3.3 FUNES E PROCEDIMENTOS...................................................................17

2.3.4 TRIGGERS..............................................................................................18

2.4 MODELO DE REGRAS EM SBDAS ........................................................ 22

2.4.1 MODELO DE DEFINIO DE REGRAS ........................................................ 23

2.4.2 MODELO DE EXECUO DE REGRAS ........................................................ 26

2.5 ESTRUTURAS DE ARMAZENAMENTO DE REGRAS........................... 29

2.5.1 REPOSITRIO SUGERIDO PELA LINGUAGEM SQL3 .................................... 30

2.5.2 REPOSITRIO DE UM SBDA .................................................................... 33

2.6 GERNCIA DE GERNCIA .................................................................... 36

2.6.1 OPERAES DE GERNCIA PROPOSTA POR SQL3 ..................................... 36

2.6.2 OPERAES DE GERNCIA DOS SGBDAS ................................................ 36

2.7 CONCLUSES........................................................................................ 39

3 MODELO DE REGRAS .............................................................................. 40

7

3.1 INTRODUO ....................................................................................... 40

3.2 META-MODELO DE REGRAS ............................................................... 40

3.3 MODELO DE REGRAS ADOTADO ........................................................ 47

3.3.1 MODELO DE DEFINIO DE REGRAS ........................................................ 47

3.3.2 MODELO DE EXECUO DE REGRAS ........................................................ 57

3.3.2.1 DISPARO E EXECUO DE REGRAS ....................................................... 57

3.3.2.2 OUTROS MECANISMOS ASSOCIADOS AO MODUS OPERANDI ................... 59

3.4 OPERAES SOBRE REGRAS .............................................................. 60

3.5 CONCLUSES........................................................................................ 62

4 PROPOSTA DE UM REPOSITRIO DE REGRAS...................................... 63

4.1 INTRODUO ....................................................................................... 63

4.2 SNTESE DAS CARACTERSTICAS DAS REGRAS............................... 64

4.3 DESCRIO DO REPOSITRIO DE REGRAS ....................................... 68

4.3.1 TABELA REGRA ..................................................................................... 68

4.3.2 TABELA EVENTO.................................................................................... 70

4.3.3 TABELA REGRA-EVENTO ........................................................................ 71

4.3.4 TABELA CONDIO ................................................................................ 72

4.3.5 TABELA AO ....................................................................................... 73

4.3.6 TABELA AO-EV ................................................................................. 74

4.3.7 TABELA REGRA_COMPOSIO................................................................ 75

4.3.8 TABELAS USURIO_SISTEMA, COLUNA_SISTEMA E TABELA_SISTEMA...... 77

4.4 META-REGRAS DO REPOSITRIO DE REGRAS.................................. 81

4.5 UM EXEMPLO PRTICO DO USO DO REPOSITRIO .......................... 84

4.6 CONCLUSES........................................................................................ 91

5 OPERAES DE GERNCIA DE REGRAS ............................................... 93

5.1 INTRODUO ....................................................................................... 93

5.2 PROPOSTA DE UMA LINGUAGEM DE GERNCIA DE REGRAS......... 93

5.2.1 OPERAES SOBRE ELEMENTOS DE UMA REGRA ..................................... 94

5.2.1.1 ALTERAR O EVENTO DE UMA REGRA ..................................................... 95

5.2.1.2 ELIMINAR O EVENTO DE UMA REGRA .................................................... 99

5.2.1.3 ADICIONAR UM EVENTO A UMA REGRA ............................................... 102

5.2.1.4 ADICIONAR UMA CONDIO A UMA REGRA ......................................... 106

5.2.1.5 ELIMINAR A CONDIO DE UMA REGRA .............................................. 108

8

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

5.2.1.7 ADICIONAR UMA AO A UMA REGRA................................................. 111

5.2.1.8 MODIFICAR A AO DE UMA REGRA ................................................... 114

5.2.1.9 ELIMINAR A AO DE UMA REGRA...................................................... 116

5.2.1.10 ALTERNAR AS AES DE UMA REGRA ............................................... 118

5.2.2 OPERAES SOBRE REGRAS ................................................................. 119

5.2.2.1 HABILITAR OU DESABILITAR UMA REGRA ........................................... 119

5.2.2.2 AGRUPAMENTO DE REGRAS................................................................ 120

5.2.2.3 ELIMINAR GRUPO DE REGRAS ............................................................ 121

5.2.2.4 ELIMINAR UMA REGRA ...................................................................... 121

5.2.2.5 HABILITAR OU DESABILITAR UM CONJUNTO DE REGRAS ...................... 122

5.3 NAVEGADOR PARA A GERNCIA DE REGRAS ................................ 122

5.4 REALIZAO DA PROPOSTA EM UM SBDA GENRICO ................. 125

5.5 CONCLUSES...................................................................................... 128

6 ANLISE DA PROPOSTA ....................................................................... 129

6.1 INTRODUO ..................................................................................... 129

6.2 UM ESTUDO DE CASO ........................................................................ 129

6.2.1 O CONTEXTO DO NEGCIO .................................................................... 129

6.2.2 AS REGRAS DE NEGCIO ....................................................................... 133

6.2.3 AS OPERAES DE GERNCIA ................................................................ 146

6.3 CONCLUSES...................................................................................... 159

7 CONCLUSES E PESQUISAS FUTURAS ............................................... 160

7.1 PRINCIPAIS CONTRIBUIES ........................................................... 160

7.2 FUTURAS PESQUISAS ........................................................................ 162

REFERNCIAS BIBLIOGRFICAS ........................................................... 164

ANEXO A - RESUMO DAS SINTAXES PROPOSTA ............................................ 173

9

LISTA DE ILUSTRAES

Figura 1 Classificao de eventos nos SBDAs (CHAKRAVARTHY; MISHRA,

1993)................................................................................................24

Figura 2 - Passos envolvidos no processamento de regras (PATON; DIAZ,

1999; VADUVA, 1999)..................................................................27

Figura 3 - Repositrio de regras da linguagem SQL3 (ISOIEC 9075-2, 1999).30

Figura 4 Repositrio de Regras do Oracle....................................................33

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

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

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

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

Figura 9 Dois tipos de representao de disparos de regras. Na alnea a,

ilustrado um exemplo implcito no qual a regra R6 dispara a regra

R7, R8 e R9, e estas regras esto sujeitas a uma mudana

na ordem de execuo na alnea b eventos explcitos, sendo que a

regra R5 compe-se de trs regras: R2, R3

e R4..........................................................................................46

Figura 10 - Etapas do processamento de regras do tipo 1 e tipo 2

(PAVON, 2005)............................................................................58

Figura 11 Regra R1 especificada de duas formas diferentes.........................59

Figura 12 - Representao do relacionamento entre regra e evento..................71

10

Figura 13 - Representao do relacionamento entre regra e os demais

elementos condio e ao.........................................................72

Figura 14 - Representao do relacionamento entre ao e evento...................74

Figura 15 - Representao entidade-relacionamento de uma composio de

regras........................................................................................76

Figura 16 - Diagrama entidade-relacionamento da associao entre o evento

e os demais objetos do banco de dados.......................................78

Figura 17 - Diagrama entidade-relacionamento da associao entre a

TABELA_SISTEMA e as tabelas condio e ao ......................79

Figura 18 - Diagrama entidade-relacionamento relativo ao repositrio de

regras........................................................................................81

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

de regras.......................................................................................82

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

Figura 21 Especificao da Regra R8..........................................................86

Figura 22 Regra de negcio Atualiza-Salrio..............................................97

Figura 23 Regra ATUALIZA_CARGO. Na alnea a, a regra possui um

evento de banco de dados, e na alnea b, a mesma regra, teve o

seu evento modificado por um evento sistema..............................99

Figura 24 Barra de tarefas do prottipo.....................................................123

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

11

regras......................................................................................125

Figura 26 Arquitetura de um SBDA genrico (adaptao de

PAVON (2005)).......................................................................126

Figura 26 - Diagrama de atividades do processo de negcio solicitar

auxlio- evento..........................................................................131

Figura 27 - Diagrama de atividades do processo de negcio cancelar

Auxlio-evento.........................................................................132

Figura 28 Encadeamento entre a regra R5 e R10........................................135

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

Figura 30 Encadeamento de regras referente ao auxilio-evento...................140

Figura 31 Encadeamento entre a regra R30 e a regra R35...........................141

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

Figura 33 - Encadeamento de regras referente ao cancelamento auxilio

-evento....................................................................................144

Figura 34 - Encadeamento de regras do estudo de caso.................................146

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

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

no repositrio de regras...........................................................154

Figura 37 - Encadeamento de regras, aps as alterao na regra R35

e eliminao da regra R30......................................................158

12

LISTA DE TABELAS

Tabela 2.1 Operaes de gerncia sobre elementos associados a uma

tabela........................................................................................16

Tabela 2.2 Sintaxe das restries de integridade na linguagem SQL3...........16

Tabela 2.3 - Contedo da tabela TRIGGER TABLE USAGE............................31

Tabela 2.4 Contedo da tabela TRIGGER COLUMN USAGE..........................31

Tabela 2.5 - Contedo da tabela TRIGGERED UPDATE COLUMNS...............32

Tabela 2.6 - Contedo da tabela TRIGGERS...................................................32

Tabela 2.7 - Contedo da tabela DBA_TRIGGERS..........................................34

Tabela 2.8 - Contedo da tabela DBA_TRIGGERS_COLS...............................35

Tabela 2.9 - Operaes de Gerncia no SGBDA Oracle..................................37

Tabela 2.10. Comando para criar e alterar regras em Starburst........................37

Tabela 3.1 - Tipos de regras em diferentes nveis de abstrao........................41

Tabela 3.2 - Linguagem de regras SQL3 e sua Extenso (VIANA; PAVON;

ALMEIDA, 2006)........................................................................48

Tabela 4.1 Meta-regras associadas ao repositrio de regras..........................81

Tabela 4.2 Tabela REGRA..........................................................................86

Tabela 4.3 Tabela EVENTO........................................................................87

Tabela 4.4 Tabela REGRA_EVENTO..........................................................88

13

Tabela 4.5 Tabela EV_COL........................................................................88

Tabela 4.6 Tabela EVENTO........................................................................88

Tabela 4.7 Tabela REGRA_EVENTO..........................................................89

Tabela 4.8 Tabela CONDIO...................................................................89

Tabela 4.9 Tabela CONDIO_TAB..........................................................89

Tabela 4.10 Tabela AO..........................................................................89

Tabela 4.11 Tabela AO_TAB.................................................................90

Tabela 4.12 Tabela AO_EV...................................................................90

Tabela 4.13 Tabela REGRA_COMP............................................................91

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

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

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

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

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

14

LISTA DE ABREVIATURAS E SIGLAS

A - Ao

BD - Banco de Dados

CA Condio-Ao

CA1A2 Condio-AoPrimria-aoSecundria

ECA - Evento-Condio-Ao

ECA1A2 Evento-Condio-AoPrimria-aoSecundria

LDD Linguagem de Definio de DAdos

LMD Linguagem de Manipulao de Dados

SAMOS - Swiss Active Mechanism-Based Object-Oriented Database System

SBD Sistema de Banco de Dados

SBDA Sistema de Banco de Dados Ativo

SGBD - Sistema Gerenciador de Banco de Dados

SGBDA Sistema Gerenciador de Banco de Dados Ativo

SQL3 ou SQL99- Structure Query Language

15

RESUMO

Este trabalho adota um modelo de regras estendido, que melhora a expressividade da

linguagem SQL3, propondo o uso de novas variantes para o modelo de regras ECA (Evento

Condio Ao). Porm, este modelo estendido abrange somente a definio de regras,

faltando as outras operaes de gerncia, como eliminar ou modificar uma regra, entre outros

mecanismos necessrios para gerenciar estes novos tipos de regras. Neste trabalho, prope-se

uma linguagem de gerncia de regras composta de um conjunto de operaes para criar,

excluir e alterar as regras e suas partes, com a finalidade de obter maior reuso e

manutenibilidade das regras. Para tanto, analisa-se o modelo de regras estendido, para

identificar quais so as suas limitaes e as propriedades do modelo a serem consideradas na

especificao da linguagem de gerncia de regras proposta. O resultado desta anlise

utilizado para a elaborao de um repositrio de regras, necessrio para armazenar os tipos de

regras propostos. Este repositrio armazena um conjunto de regras que se deve manter

consistente, da mesma forma que os dados se mantm consistentes em um banco de dados.

Para tanto, foi definido um conjunto de regras de consistncia. Tambm, definido um

conjunto de operaes de gerncia de regras que auxiliam na manipulao de regras e de seus

elementos, armazenadas no repositrio de regras.

Palavras-chave: Banco de Dados Ativos. Gerncia de Regras. SQL3

16

ABSTRACT

This work uses an extended rule model which improves the expressiveness of SQL3

language, proposing the use of new variants for the ECA (Event-Condition-Action) rule

model. Nevertheless, the extended model considers only the rule definition and it lacks other

management operations, such as excluding or modifying rules, among others necessary

mechanisms for these new rule types. In this work, a rule management language made of a set

of operations for creating, eliminating and altering rules and its parts is proposed, in order to

obtain greater reuse and maintainability of rules. For this purpose, the extended rule model is

analyzed to identify its limitations and the properties that it supports to be considered in the

rule management language proposed. The result of this analysis is used to define a rule

repository, necessary for storing the rule types proposed. This repository stores a rules set

which must be consistent, as well as data must be consistent in the database. Hence, a

consistency rule set is defined. Besides, a rule management operations set is defined to help to

handle rules and their elements, stored in the rule repository.

Keywords: Active Database. Rule Management. SQL3

1

CAPTULO 1. INTRODUO

1.1 MOTIVAO

A relevncia da rea de Banco de Dados tem sido comprovada, por meio do grande

volume de aplicaes que utiliza Sistemas Gerenciadores de Banco de Dados (SGBD), como

um dos componentes principais, no desenvolvimento de sistemas computacionais. Este

sucesso se deve ao fato de que estes SGBD consolidam tarefas de armazenamento e

recuperao de grandes volumes de dados eficientemente, aliados segurana e a ambientes

centralizadores. Este sucesso tambm pode ser constatado, pela prpria indstria de software

(por exemplo, Oracle, Informix, DB2), que propicia ambientes complexos, que garantem, de

forma confivel e eficiente, mecanismos que manipulam, eficazmente, esta grande quantidade

de informaes.

A evoluo dos SGBDs, levou adoo de capacidades ativas, adotando a semntica

destas aplicaes (PATON, 1998). Esta semntica, representada por meio de regras, esta

refletida em comportamentos baseados em eventos. O evento algum acontecimento,

relevante, no tempo. A relevncia pode ser medida pelo fato de que alguma ao deve ser

tomada, em funo da ocorrncia deste acontecimento eventos so elementos essenciais na

elaborao de regras. Regras representam sentenas ou restries associadas aos estados ou

processos de um domnio, por exemplo, compra e venda de produtos via Web.

O comit de padronizao da linguagem SQL3, incluiu, em sua ltima verso

(ISO/IEC 9075-2, 1999), (linguagem SQL3 ou linguagem SQL99), a proposta de incluso de

regras ou triggers nos SGBDs, e que por sua vez foi seguida pela indstria de software. A

linguagem SQL3 um padro de fato, utilizado pelos Sistemas Gerenciadores de Banco de

Dados Ativos (SGBDAs) para a definio e manipulao de dados e regras em banco de

dados. Um SGBDA um SGBD, que alm de suas caractersticas prprias, permite a

definio, gerncia e execuo de regras Evento-Condio-Ao (ECA). As regras ECA

caracterizam-se por terem trs componentes: o evento, a condio, associada a um predicado

a ser avaliado, e a ao, que um conjunto de operaes a serem executadas, toda vez que o

predicado seja avaliado como verdadeiro.

A Incluso de regras dentro de um SGBDA leva a uma srie de vantagens, como por

exemplo:

2

A reutilizao de cdigos: regras computacionais derivadas de diferentes domnios de

aplicao podem ser especificadas por meio de uma linguagem de programao provida

pelo prprio SGBDA. Estes fragmentos de cdigos representam a semntica envolvida

nos processos de negcios e podem ser armazenados e utilizados por diversas aplicaes.

Por exemplo, em reas como Workflows no qual a automao de processos de negcio,

por meio de tarefas e/ou documentos so passadas de um participante a outro, de acordo

com regras procedimentais, eBusiness, no qual o foco a obteno de maior vantagem

competitiva, por meio da cadeia de valor da empresa, tais como seus fornecedores,

empregados, acionistas, consumidores e seus processos como conhecimento (obteno de

conhecimento de produtos por parte do cliente, treinamento de revendedores para vender

com maior eficcia), transao (compra eletrnica de produtos) e relacionamento

(intercmbio eletrnico de informaes, personalizao de clientes). O reuso do

conhecimento nestas reas gera economia de recursos e de tempo.

Facilidade nas manutenes preventiva, adaptativa e corretiva dos processos de

negcio: considerando que a semntica dos processos de negcio, por meio de regras,

geralmente espalhada em vrios ambientes, ento as regras armazenadas em um SGBDA

tendem a ser menos complexas, requerendo menor quantidade de recursos para

encaminhar uma soluo, e como conseqncia a manuteno tende a ser menos

complexa.

Centralizao do conhecimento: o intercmbio de informaes eletrnicas , para muitas

empresas, vantagem competitiva, visto que os processos de negcios esto automatizados.

Um exemplo deste intercmbio entre diferentes domnios so cadeias de supermercados e

seus fornecedores. Centralizar estes processos de negcio em poucas aplicaes, sob o

domnio de uma mesma linguagem, em um mesmo ambiente computacional torna o

processo de intercmbio de informao mais simples, pois, exige menos recursos como

reduo no nmero de especialistas em cada uma destas aplicaes, garantia de

padronizao de conceitos para a manuteno da lgica do negcio, alm de custo

financeiro e de tempo.

Entorno Cliente/Servidor: fato conhecido que os SGBDAs Relacionais so dominantes

no mercado e que os ambientes de programao oferecem aos desenvolvedores a

tecnologia Orientada a Objetos. Aglutinar estas duas tecnologias um desafio presente em

um ambiente de desenvolvimento, e que pode apresentar grandes dificuldades quando se

3

trata de manipular grandes quantidades de informao, quando as regras do negcio se

encontram na aplicao, e os dados, em bancos de dados. Considerando que em um

SBDA, dados e regras compartilham o mesmo ambiente, ento, possvel minimizar a

impedncia gerada pelos dois ambientes, aplicao e banco de dados, quando na aplicao

so especificadas as solicitaes e no banco de dados a execuo destas solicitaes. Alm

disso, descongestionam-se as redes quanto ao trfego de informaes, quando o

processamento realizado localmente.

Alm destes aspectos positivos, soma-se a versatilidade de um SGBDA em funo de que

existe um ambiente para o tratamento da segurana quanto ao acesso da informao nele

contida como tambm acesso ao prprio banco de dados, mecanismos disponveis para

gerenciamento e controle da integridade dos dados (restries de dados).

Apesar dos aspectos positivos, ainda muito freqente encontrar sistemas com

implementao de regras em meio a seu cdigo, fora do SGBDA. Esta deciso leva a

situaes nas quais regras se tornam redundantes, devido a vrios fatores, como por

exemplo, a falta de documentao atualizada, sobre a especificao da regra, e quando a

manuteno for realizada por diferentes projetistas pode levar a diferentes interpretaes do

processo de negcio. As regras podem ser quase inacessveis, visto que elas podem participar

de complexos fragmentos de cdigos, portanto ocultas no meio de milhares de linhas de

cdigo, em lgicas complexas, dificultando a sua identificao. As regras podem estar

perdidas, ou seja, sistemas so modificados por diferentes desenvolvedores, e muitas vezes,

ao no reaproveitar o cdigo, por razes de desconhecimento da linguagem ou falta de

conhecimento do processo de negcio, isola o fragmento de cdigo analisado e o refaz

segundo o seu entendimento.

Na literatura existem basicamente duas abordagens, desenvolvidas em paralelo, para a

gerncia de regras (CERI; WIDOM, 1990; CERI; MANTHEY, 1993; BERNDTSSON,

1994; MORIARTY, 1998; DIAZ; JAIME, 2000; CERI; COCHRANE; WIDOM, 2000;

ROSS, 2003). Uma delas sob a tica de anlise de negcios e a outra sob a tica de Banco

de Dados. Estas tcnicas so totalmente independentes e desconexas. A gerncia de regras

trata da criao, eliminao e alterao de regras em SGBDA.

Os trabalhos desenvolvidos sob tica de anlise de negcios tm como objetivo

facilitar a atividade de gerncia de regras para os analistas de negcios (VON HALLE, 2002;

VASILECAS; LEBEDYS, 2006) e, portanto, as ferramentas propostas so totalmente

4

orientadas para usurios no tcnicos, utilizando um vocabulrio apropriado para os mesmos.

Nesta abordagem prope-se o uso de um software front-end como sistema de regras de um

negcio (ROSS, 2003). Este sistema de regras composto por um repositrio central de

regras, que as armazena em uma linguagem acessvel pelos analistas de negcios (linguagem

quase-natural), e uma mquina de regras, que consiste em um conjunto de programas

especializados na gerncia de regras. Atualmente, existem vrios produtos comerciais que

implementam esta abordagem, tais como, ILOG (ILOG RULES, 2005), Rule Track

(BUSINESS RULE GROUP, 2000) e Business Rule Studio (RULEMACHINES, 2000). A

linguagem de definio de regras varia de acordo com o produto utilizado; a nica

semelhana est em que uma linguagem muito prxima linguagem natural. Uma das

vantagens desta abordagem que os profissionais da rea de negcio podem definir e

gerenciar as regras por meio de uma interface simples, melhorando assim a comunicao

entre analistas de negcio e profissionais tcnicos. Porm, estes sistemas somente abrangem

as regras mais simples, no considerando as regras mais complexas embutidas dentro do

cdigo dos programas de aplicao. Outra desvantagem destes sistemas a ineficincia na

gerncia de grandes quantidades de regras.

A outra abordagem, que analisa as regras sob a tica de Banco de Dados, sugere

aproveitar a infra-estrutura do prprio SGBDA para a gerncia de regras. As regras so

armazenadas em estruturas, assim como os dados, e o prprio SGBDA utilizado como

sistema gerenciador de regras. Esta abordagem adotada neste trabalho.

Uma das vantagens desta abordagem a possibilidade de gerenciar as regras e os

dados em um nico ambiente, simplificando assim a atividade de gerncia desses objetos do

banco de dados. As regras so definidas uma nica vez no banco de dados e podem ser

compartilhadas entre vrias aplicaes, existindo um controle centralizado das regras. Alm

disso, vrios trabalhos tm sido propostos na literatura para auxiliar o projeto de regras em

sistemas de informao, tais como navegadores de regras (LANG, 1998), depuradores de

regras (KAPPEL; KRAMLER; RETSCHITZEGGER, 2001; ELIZONDO, 1998),

analisadores de regras (VADUVA, 1999). Um navegador de regra permite a inspeo de um

conjunto de regras existentes em um repositrio de regras. Por meio deste navegador

possvel criar, eliminar e alterar regras, como tambm possvel saber quais regras foram

disparadas por uma determinada regra. Um depurador de regras uma ferramenta que permite

controlar a execuo das regras com a finalidade de verificar se o repositrio de regras

implementa o comportamento requerido, pelo usurio, adequadamente. Um analisador de

5

regras uma ferramenta que permite verificar se existe inconsistncia no conjunto de regras,

por exemplo, se no ocorrem ciclos infinitos quando um conjunto de regras disparado.

No entanto, a maioria das organizaes que opta por especificar as regras de negcio

nos bancos de dados, enfrenta grandes dificuldades para o gerenciamento dessas regras em

seus sistemas de informao, pois falta uma infra-estrutura apropriada para realizar as

atividades de gerncia de regras, de maneira gil e eficiente. Esta infra-estrutura representa

um conjunto de tabelas necessrias para armazenar as regras e um conjunto de mecanismos

para garantir que as regras armazenadas nestas tabelas mantenham a devida consistncia. Este

mecanismo representado por um conjunto de regras de consistncia e estruturas que atuam

de forma a garantir o emprego destas regras quando solicitadas. A atividade de gerncia tem

como objetivo fornecer recursos para definir, eliminar, alterar e consultar regras ou partes

destas.

Assim como os dados, as regras tambm necessitam contar com um mecanismo de

gerncia eficiente, pois na medida em que se apresentam mudanas no negcio, surge a

necessidade de mudanas tambm nas regras. Tais mudanas se refletem por meio da criao

de novas instncias de regras, eliminao de algumas regras j existentes ou a eliminao e

adio de determinadas partes delas. Atualmente, no possvel alterar partes das regras,

pois nos SGBDs atuais elas so tratadas como um elemento nico. Esta incapacidade ocorre

devido a dois fatores: o primeiro em decorrncia de que os repositrios de regras no esto

preparados para tratar alteraes de partes de regras, e o segundo fator est em que no

existem operaes de gerncia definidas para a alterao de partes de uma regra.

Devido evoluo dos processos de negcio, existe a necessidade de armazenar as

regras em estruturas apropriadas para facilitar o seu gerenciamento, assim como, existem

estruturas prprias para o armazenamento dos dados no banco de dados. Tecnicamente,

fazendo um comparativo com os dados, isso significa que os dados so definidos de forma

independente aos outros objetos de banco de dados, por meio de uma linguagem de definio

de dados, e podem ser consultados ou atualizados por meio de uma linguagem de

manipulao de dados. No entanto, uma regra, somente, pode ser criada ou eliminada, no

existindo a possibilidade de realizar operaes de alterao sobre ela. Alm disso, no

dicionrio de dados, so armazenados os relacionamentos das regras com os dados, deixando

de lado as informaes referentes aos relacionamentos entre as regras. Esta informao

sobre o relacionamento, entre regras, importante porque reflete a prpria lgica do negcio e

tambm, representa o prprio encadeamento entre elas. Portanto, uma lgica de negcio pode

6

ser representada por um encadeamento de regras, porm, nem todo encadeamento representa

uma lgica de negcio, como por exemplo, podem ser encadeamentos ad hoc que levam a

comportamentos indesejados.

Com estruturas apropriadas, atuando como repositrio de regras possvel armazenar

partes das regras, o relacionamento entre regras e delas com os demais objetos do banco de

dados. As regras de um sistema se relacionam entre si, da mesma forma em que os dados

esto inter-relacionados. Elas tambm se relacionam com os dados, visto que muitas regras

expressam restries sobre eles, gerando assim uma complexa rede de associaes, composta

de associaes entre regras e restries destas sobre os dados. Estes aspectos semnticos,

informaes sobre a estrutura de uma regra e seus relacionamentos so a base para elaborar

um ambiente que suporte operaes de gerncia de regras, e como conseqncia, dispor de

um sistema de regras mais flexvel em comparao com os sistemas atualmente oferecidos.

A linguagem SQL3 sugere um conjunto de operaes de gerncia, tanto para dados

quanto para regras. No caso dos dados, existe um conjunto de operaes para a definio e

manipulao deles. A linguagem de definio de dados (LDD) especifica como criar as

estruturas que vo comportar os dados da aplicao (por exemplo, as tabelas) em conjunto

com mecanismos que auxiliam sua organizao interna (por exemplo, a criao de ndices). A

linguagem de manipulao de dados (LMD) especifica a maneira como manipul-los por

meio de operaes de gerncia, tais como insero, excluso, consulta e atualizao de dados

(FORTIER, 1999). Na linguagem SQL3, as operaes para definio e excluso de uma regra

esto embutidas com as operaes de definio dos dados e, alm disso, estas regras so

includas junto ao dicionrio de dados do banco de dados (ISO/IEC 9075-2, 1999). As

regras no tm um tratamento independente dos dados, pois, ao criar uma regra, necessrio

recorrer LDD para encontrar a sintaxe de criao de uma regra. Neste sentido, o SGBDA

no tem sido muito aproveitado para a implementao e gerncia de regras.

Para que as regras alcancem o mesmo grau de importncia que os dados em um

SGBDA, necessrio que elas tenham um tratamento independente dos dados, apoiado por

uma linguagem de gerncia de regras e um repositrio de regras. Entretanto, existem poucos

trabalhos que tratam sobre a gerncia de regras em SGBDAs (DIAZ; PATON; GRAY, 1991;

CERI; MANTHEY, 1993; BERNDTSSON, 1994; MORIARTY, 1998; CERI; COCHRANE;

WIDOM, 2000; ROSS, 2003) apesar da relevncia desta tarefa.

Apesar das vantagens em implementar regras em um SGBDAs, ainda existe a

necessidade de estender o modelo de regras da SQL3, pois este modelo de regras no

7

suficiente para representar a grande maioria dos tipos de regras utilizada para especificar

regras de negcio (PAVON; VIANA; CAMPOS, 2006). Um modelo de regras compreende

um modelo de definio e um modelo de execuo de regras. O modelo de definio

apresentado pela SQL3 a prpria sintaxe da regra ECA, e o modelo de execuo definido

pelo modo como este tipo de regra executado. Para se estender um modelo de regras, por

exemplo, o modelo apresentado pela linguagem SQL3, necessrio identificar e especificar

as caractersticas das regras que se pretende estender. Isto pode ser feito por meio de um

meta-modelo de regras. Existem vrios trabalhos que propem meta-modelos de regras como

extenso da linguagem SQL3 (AMGHAR; MEZIANE; FLORY, 2000; TORRICO;

TANAKA; MOURA, 2000), porm nem todos apresentam uma soluo mais abrangente, que

envolve tanto o meta-modelo quanto o modelo de regras (PAVON, 2005).

O modelo proposto em Pavn estende o modelo de regras apresentado pela SQL3.

Este modelo composto por um conjunto, mais amplo, de tipos de regras que os tipos

apresentados pela linguagem SQL3. Nesta linguagem SQL3, pode-se representar regras do

tipo ECA (evento condio - ao) e, na omisso da condio, do tipo EA (evento - ao).

No modelo proposto, o conjunto de tipos de regras envolve, alm de ECA e EA, os tipos

ECAA (evento - condio - ao primria - ao secundaria), CAA (condio - ao primria

- ao secundria), CA (condio - ao1) e A (ao). Cada tipo de regra representa uma

semntica diferente. Esta melhora na expressividade da regra implica que possvel expressar

um conjunto de informaes, mais amplo.

Alm de ampliar o conjunto de tipos de regras, a linguagem proposta define um

conjunto mais significativo de informaes que podem ser especificados para cada elemento

da regra. Por exemplo, o evento na linguagem SQL3 pode ser definido em funo de trs

operaes de manipulao de dados, a saber: uma insero, uma atualizao e uma excluso

de dados. Na linguagem proposta, este conjunto ampliado, e considera alm das operaes

descritas, outros tipos de operaes que envolvem a seleo de dados, acesso ao banco de

dados, entre outras. No modelo de regras proposto, portanto, semanticamente mais rico que

o modelo de regra da linguagem SQL3 e, portanto considerado como ponto de partida para a

proposta de um conjunto de operaes de gerncia de regras.

Considerando as desvantagens da linguagem SQL3, e os esforos em melhorar a

expressividade desta linguagem, especificamente no que se refere s operaes de gerncia de

1 O termo ao e ao primria tm o mesmo significado. Usa-se ao primria somente em presena de uma ao secundria.

8

regras, possvel concluir que ainda existe a necessidade de contar com uma infra-estrutura

propcia para armazenar e gerenciar os principais tipos de regras encontrados nos sistemas de

informao. Portanto, esta infra-estrutura tem como premissa a extenso proposta de tal forma

que nela seja possvel armazenar os relacionamentos existentes entre os diferentes tipos de

regras e delas com os demais objetos do banco de dados. Esta infra-estrutura deve contar com

um repositrio de regras, para armazenar estes novos tipos de regras, com operaes de

gerncia para atuar sobre as regras armazenadas neste repositrio e um conjunto de regras de

consistncia para garantir a consistncia do repositrio de regras. Este trabalho de tese tem

como finalidade de estender a linguagem de gerncia de regras sugerida pelo modelo adotado,

ou seja, oferecer um conjunto de operaes de gerncia, alm das operaes que so sugeridas

neste modelo.

1.2 OBJETIVO

Considerando que as regras so to importantes quanto os dados, existe a necessidade

de contar com um tratamento para regras, da mesma forma que existe para os dados em um

SGBDA, atribuindo-se o mesmo grau de importncia a ambos. Para isto necessrio definir

estruturas apropriadas para o armazenamento e organizao dos tipos de regras sugeridos pela

linguagem SQL3 e os tipos de regras apresentadas na literatura, como extenso desta

linguagem. Estas estruturas devem prover um contexto que facilite a definio e a alterao de

regras, e de suas partes. Como conseqncia, o ambiente apresentado deve ser propcio para a

gerncia de regras, similar ao ambiente existente nos sistemas de bancos de dados, para a

definio e manipulao de dados.

Este trabalho tem por objetivo geral especificar uma Linguagem de Gerncia de

Regras para Sistemas de Banco de Dados Ativos que permita gerenciar um sistema de regras,

tendo como referncia as operaes de gerncia sugeridas pela linguagem SQL3. Essa

Linguagem de Gerncia de Regras proposta a partir de um modelo j proposto na literatura

(PAVON, 2005) que estende a expressividade da linguagem de regras da SQL3, quanto ao

seu modelo de definio de regras. Tal modelo de definio adotado como referncia para a

elaborao de um conjunto de operaes de gerncia de regras. Neste trabalho no so

considerados nem analisados aspectos relativos ao desempenho da linguagem, mas sim, a

expressividade da linguagem proposta frente a linguagem de regras sugerida pela linguagem

SQL3.

9

Os objetivos especficos, utilizados como marcos para se chegar ao objetivo geral so

os seguintes.

Fazer uma anlise descritiva do modelo de regras adotado. Esta anlise visa

identificar as caractersticas dos tipos de regras que sero utilizados, sendo que

estas caractersticas servem de base para a elaborao do repositrio de regras.

Estabelecer um repositrio de regras capaz de armazenar os diferentes tipos de

regras. Este repositrio deve contemplar estruturas para o armazenamento das

partes das regras e as associaes entre elas.

Identificar e descrever as meta-regras que devem ser adotadas para garantir a

integridade do repositrio de regras.

Estabelecer as operaes de gerncia de regras. Para cada operao

necessrio avaliar a sua conseqncia perante o repositrio de regras.

Identificar e descrever as meta-regras que devem ser adotadas para garantir o

correto uso das operaes de gerncia.

Elaborar um estudo de caso que servir como ambiente de teste para as

operaes de gerncia.

1.3 ORGANIZAO DO TRABALHO

No captulo 2 apresenta-se uma reviso da literatura, descrevendo-se os principais

conceitos sobre banco de dados ativos, destacando-se os mecanismos utilizados por estes

sistemas gerenciadores para a representao de regras, em especial, o modelo de regra ECA.

No captulo 3 descrito o meta-modelo de regras, que sintetiza as propriedades das regras que

formam a base para a proposta de extenso da linguagem de regras, proposta para a

linguagem SQL3. Esta extenso inclui um modelo de regras, composto pelo modelo de

definio e o modelo de execuo de regras. Neste captulo, descrito o modelo de definio

de regras, visto que este forma a base para a elaborao das operaes de gerncia de regras.

Alm disso, so apresentadas algumas operaes de gerncia de regras disponveis na

literatura e tambm as operaes de gerncia sugeridas no modelo adotado.

No captulo 4, so apresentadas as estruturas utilizadas para o armazenamento dos

tipos de regras que foram propostas no meta-modelo. Tambm elaborado um conjunto de

regras necessrias para garantir a consistncia do repositrio de regras. Este captulo

concludo com um exemplo da aplicabilidade deste repositrio.

10

No captulo 5 especificado um conjunto de operaes de gerncia de regras. Esta

proposta inclui um conjunto de operaes para a criao, excluso e alterao de regas e de

suas partes. Esta proposta, de uma linguagem de gerncia, considera os mecanismos

atualmente existentes na linguagem SQL3 e aproveita a extenso proposta para a linguagem

de definio de regras. apresentado um comparativo entre a linguagem de regras SQL3 para

a gerncia de regras e o conjunto de operaes de gerncia sugerido neste trabalho.

No captulo 6 apresentado um estudo de caso para avaliar a proposta do repositrio

de regras e dos mecanismos de gerncia utilizados. So elaborados dois processos de negcio,

que por sua vez so armazenados no repositrio de regras e logo a seguir so utilizadas

operaes de gerncia de regras sobre eles, segundo critrios previamente estabelecidos.

Por ltimo, no captulo 7, apresentam-se as concluses finais deste trabalho, as

principais contribuies e algumas sugestes para pesquisas futuras.

11

CAPITULO 2. REGRAS EM BANCO DE DADOS ATIVOS

2.1 INTRODUO

Neste captulo so apresentadas, uma reviso do estado da arte sobre regras em

Sistemas Gerenciadores de Banco de Dados Ativos (SGBDAs) e os mecanismos utilizados

nestes sistemas para a representao de regras. So apresentados os modelos de regras

sugeridos pela linguagem SQL3, os modelos utilizados pelos SGBDAs comerciais para a

especificao de regras, e as estruturas utilizadas por esses gerenciadores para armazenamento

dessas regras. Alm disso, apresentam-se as limitaes dos repositrios destes SGBDAs para

o armazenamento de regras. Da mesma forma, so apresentadas as operaes de gerncia,

sugeridas pela linguagem SQL3 e utilizadas pelos SGBDAs, com a finalidade de identificar as

suas limitaes, em decorrncia destes repositrios. Por ltimo, conclui-se com uma breve

discusso sobre os problemas atuais referentes ao armazenamento e gerncia de regras em

SGBDAs.

2.2 REVISO DO ESTADO DA ARTE SOBRE REGRAS EM SGBDA

No inicio da dcada de oitenta surgiu expresso sistemas de banco de dados ativos

(MORGENSTERN, 1983; STONEBRAKER; WOODFILL; ANDERSEN, 1983), cuja idia

central era de que SBD, deveriam responder de maneira inteligente e no trivial s

solicitaes dos usurios, por meio de suas diversas interaes, e de forma inteligente tratar as

conseqncias e implicaes dessas interaes. Estes sistemas constitudos de diferentes

ambientes de trabalho tinham, em comum, a necessidade de organizar e manter enormes

quantidades de informaes inter-relacionadas. Estas informaes eram constitudas de

mensagens, arquivos, dados estruturados e programas. A este novo paradigma, atribua-se o

nome de Banco de Dados Ativos.

Foi a partir da dcada de noventa que os trabalhos cientficos, na rea de Banco de

Dados Ativos, tornaram-se mais freqentes. O contexto de ativo na tecnologia de banco de

dados engloba tanto regras dedutivas, quanto regras ativas. No primeiro caso, a tecnologia

de banco de dados dedutiva (GUERRINI, 1998) foi influenciada por trabalhos em

programao lgica, sendo que neste caso, as regras dedutivas expressam conhecimento

declarativo e tm sido utilizadas em aplicaes como anlises financeiras, suporte deciso e

12

modelagem cientfica. No segundo caso, a tecnologia de banco de dados ativos foi

influenciada pela inteligncia artificial e implementa reaes computacionais automticas em

resposta a eventos que ocorrem tanto interna, quanto externamente ao banco de dados (CERI;

RAMAKRISHNAN, 1996). Neste trabalho, dada nfase ao segundo caso, em funo de que

a grande maioria das aplicaes comerciais usa regras ativas.

As regras em bancos de dados ativos passaram a serem reconhecidas como elementos

fundamentais que devem ser considerados, tanto pela comunidade cientfica, quanto para o

entorno comercial, como um meio para a busca de solues de problemas reais. Para a

comunidade cientfica, os Bancos de Dados Ativos receberam ateno em vrios segmentos

como a especificao de diversas arquiteturas e o desenvolvimento de sistemas e de

linguagens (PATON; DIAZ, 1999). No meio comercial, fabricantes de Sistemas

Gerenciadores de Banco de Dados procuraram incorporar regras (triggers) e a linguagem

SQL3, sugerida pela ISO ANSI (ISO/IEC 9075-2, 1999) passou a adotar um modelo de

regras (PATON, 1998; FORTIER, 1999; TRKER, 2001). Um modelo de regras compreende

um modelo de definio (sintaxe da regra) e seu modelo de execuo de regras. O modelo de

execuo especifica como um conjunto de regras se comporta em tempo de execuo, como

por exemplo, sua poltica de prioridade de execuo ou sua granularidade, entre outros.

Devido riqueza de informaes associadas a um Sistema Gerenciador de Banco de

Dados Ativo (SGBDA), em 1996, Dittrich et al (ACT-NET CONSORTIUM, 1996)

apresentaram um manifesto sobre os principais conceitos associados a esta rea, sugerindo a

uniformizao de sua terminologia e apresentando as caractersticas obrigatrias e desejveis

que um SGBDA devesse conter. Alguns destes conceitos (PATON, 1998) so implementados

em diversas arquiteturas de sistemas de banco de dados ativos, como NAOS (COLLET;

COUPAYE; SVENSEN, 1994), SAMOS (GEPPERT et al., 1995a; GATZIU, 1997), ACOOD

(ENGSTRM; BERNDTSSON; LINGS, 1997), ARIEL (HANSON, 1996), STARBURST

(WIDON, 1996), ORACLE (ORACLE CORPORATION, 2003).

Existem diferentes abordagens para a especificao de uma arquitetura baseada em

regras em um SGBDA. A primeira abordagem a construo de um SGBDA a partir de sua

concepo. A segunda abordagem utilizar um SGBD passivo, modific-lo e estend-lo

internamente. Os SGBDs convencionais so considerados passivos, porque executam

operaes de consulta ou transaes sobre o Banco de Dados somente por solicitao explcita

do usurio ou programa de aplicao. No entanto, os SGBDAs estendem os SGBDs passivos

(PATON, 1999), incorporando a capacidade de executar automaticamente aes em resposta a

13

eventos gerados dentro ou fora do SGBDA, o que possvel por meio da especificao de

regras ativas. Nesta segunda abordagem, o cdigo fonte do SGBD deve estar disponvel para

que modificaes possam ser realizadas, como por exemplo, SENTINEL

(CHAKRAVARTHY et al., 1994), POSTGRES (STONEBRAKER; HEARST;

POTAMIANOS, 1989; STONEBRAKER, 1992;), STARBURST (WIDON, 1996). A terceira

abordagem implementar, externamente, as funcionalidades ativas sobre um SGBD passivo.

Estas funcionalidades fazem parte de um framework que utiliza as funcionalidades

disponveis do SGBD passivo. Esta estratgia utilizada pelos Sistemas ACOOD2, SAMOS3

e TriGS (KAPPEL; RETSCHITZEGGER, 1998).

As duas ltimas abordagens, aproveitam o dicionrio de dados como um meio para o

armazenamento de regras e o fazem, estendendo-o, ou seja, especificando e incorporando

novas estruturas para o armazenamento de regras, junto ao dicionrio de dados. Este mesmo

conceito apresentado pela norma que define a linguagem SQL3 (ISO/IEC 9075-2, 1999),

pela qual o dicionrio de dados contm as estruturas utilizadas para o armazenamento de

triggers. A linguagem SQL3 no define claramente uma infra-estrutura voltada para regras,

tendo como base um repositrio de regras, da mesma forma que existe tal infra-estrutura para

os dados, em um dicionrio de dados. Com uma infra-estrutura para regras, seria possvel

promover as regras ao mesmo nvel dos dados, assim como os dados o so em um SGBDA.

Existem propostas de repositrio de regras voltadas para o modelo relacional (HERBST;

MYRACH, 1995; BUTLERIS; KAPOCIUS, 2002), e para o modelo orientado a objetos

(GEPPERT et al., 1995a; DITTRICH et al., 2000). As propostas para o modelo relacional

sugerem um repositrio de regras externo ao SGBDA. Este trabalho segue a abordagem

relacional porque um modelo consolidado e amplamente utilizado na indstria.

Os repositrios de regras so a base para a especificao das operaes de gerncia de

regras, pois sobre estas estruturas so realizadas inseres, modificaes, excluses e

consultas s regras. Existem poucos estudos, apesar de sua importncia, especificamente

sobre a gerncia de regras em SGBDA (CERI; MANTHEY, 1993; BERNDTSSON, 1994;

WIDOM, 1996; CERI; COCHRANE; WIDOM, 2000; BONATTI et al., 2004), apesar de que,

h preocupaes sobre o comportamento das regras e como prover assistncia a elas. Neste

sentido, existem propostas de ferramentas para a assistncia s bases de regras, como

analisadores de regras (GUISHENG et al., 1996; BARALIS; CERI; PARABOSCHI, 1998; 2 Active Object-Oriented Database System 2 Swiss Active Mechanism-Based Object-Oriented Database System

14

VADUVA, 1999; BAILEY; POULOVASSILIS; NEWSON, 2000), depuradores de regras

(CHAKRAVARTHY; TAMIZUDDIN; ZHOU, 1995; DIAZ; JAIME, 2000; KAPPEL;

KRAMLER; RETSCHITZEGGER, 2001) e editores de regras (FORS, 1995; LANG, 1998).

Existem produtos comerciais dedicados ao armazenamento e gerncia de regras, cada

qual com sua prpria linguagem de regras, como ILOG (ILOG RULES, 2006) e Rule Track

(BUSINESS RULE GROUP, 2000) acompanhados de suas prprias estruturas de

armazenamento. As regras especificadas nestes sistemas so muito prximas linguagem

natural. A desvantagem destes sistemas reside em que, consideram regras simples, omitindo

regras complexas como cadeias de regras If ... Then ou sentenas do tipo case,

freqentemente utilizadas em linguagens de programao. Alm disso, estes sistemas so

ineficientes no gerenciamento de grandes quantidades de regras.

Nos ltimos anos, repositrios para armazenamento de dados XML, implementados

como framework, externos aos SGBDA, tm sido utilizados para armazenar processos de

negcios (RODRIGUES; CORREIA, 2005; VANHATALO; KOEHLER; LEYMANN,

2006), como conseqncia dos trabalhos cientficos direcionados rea de Internet,

discutindo assuntos sobre a necessidade de regras ECA (Evento-Condio-Ao) na Web e

como especificar, formalmente, eventos compostos no contexto de linguagens Web

(BONATTI et al, 2004; BRY; ECKERT, 2006), alm de tratar, formalmente, regras no

contexto da linguagem XML (eXtended Markup Language) (BONIFATI; CERI;

PARABOSCHI, 2001; ABITEBUL; BENJELLOUN; MILO, 2004), utilizadas para construir

aplicaes Web.

2.3 REGRAS EM SISTEMAS DE BANCOS DE DADOS ATIVOS

Nesta tese, considera-se um Sistema de Banco de Dados Ativo (SBDA) como um

sistema que se constitui de um Sistema Gerenciador de Banco de Dados Convencional

(SGBD) adicionado de um componente ativo e um banco de dados. Este componente ativo

representado por um conjunto de funcionalidades do SGBDA que garantem a reao deste

sistema, quando submetido a eventos. Tal componente ativo permite a especificao e

execuo de regras do tipo Evento Condio Ao (ECA). Estas regras so armazenadas

em estruturas prprias no banco de dados, denominadas repositrio de regras, que formam

parte do dicionrio de dados. A linguagem SQL3 possui um modelo de regras que permite a

especificao de regras ECA, tambm denominado de triggers (ISO/IEC 9075-2, 1999). Alm

15

das regras ECA, existem outros mecanismos para especificao de regras que tambm so

armazenadas no dicionrio de dados. Estes mecanismos so restries de integridade, tambm

conhecidas como constraints, definidas sobre tabelas especificadas no banco de dados. Estes

constraints so verificados toda vez que um objeto do tipo tabela definido ou um registro

inserido no banco de dados, e fazem parte da infra-estrutura definida para manipulao e

definio de dados no banco de dados.

2.3.1 Restries de Integridade

A linguagem SQL3 oferece os seguintes mecanismos para definir as restries de

integridade (PAVON, 1996; FORTIER, 1999; TRQUER, 2001).

- PRIMARY KEY: define uma restrio de chave primria em uma tabela.

- UNIQUE: no permite que uma coluna de uma tabela contenha valores

repetidos.

- FOREIGN KEY: define uma restrio de integridade referencial.

- DEFAULT: especifica um valor padro.

- NOT NULL: no permite que uma coluna de uma tabela deixe de conter

valores.

- CHECK: define uma restrio sobre os possveis valores que podem ocorrer em

uma coluna especfica.

Uma restrio identificada por um nome e uma expresso condicional, utilizada para

especificar a restrio de integridade a ser verificada. A violao a esta restrio representa

uma rejeio atualizao do banco de dados que ativou a restrio.

Estas restries so freqentemente utilizadas na especificao de um esquema de

banco de dados, e possuem uma infra-estrutura consolidada para o seu armazenamento e

gerncia.

Basicamente, as operaes de gerncia para a especificao de uma tabela so: criao

(create), alterao (alter) e excluso (drop). Com relao aos elementos da tabela, possvel

alterar, adicionar e excluir uma coluna e seus respectivos tipos de dados, atribuir (set) e

excluir o seu valor default. As restries de valor nico e de integridade referencial podem ser

adicionadas ou excludas da estrutura de uma tabela. Estas operaes de gerncia so

16

agrupadas na Tabela 2.1.

Tabela 2.1 Operaes de gerncia sobre elementos associados a uma tabela.

Objetos do Banco de Dados Operaes de Gerncia

Tabela Criar, Alterar, Excluir.

Elementos da Tabela Alterar, Adicionar, Excluir.

Restries de valor nico, valor default Atribuir, Excluir.

Integridade Referencial Adicionar, Excluir.

Expresso condiciona (check) Adicionar, Excluir.

Na Tabela 2.2 apresentada a sintaxe das restries de integridade permitidas pela

linguagem SQL3 Tabela 2.2 Sintaxe das restries de integridade na linguagem SQL3

Restries de Banco de Dados

CREATE TABLE

( [ {}...])

elemento-da-tabela =

|

definio-da-coluna =

| [DEFAULT ]

definio-de-restrio-da-tabela =

|

| CHECK restrio-de-valor-nico = UNIQUE | PRIMARY KEY

[ {nome-coluna}...]

[ {nome-coluna}...] especificao-de-referncias = REFERENCES

< nome-coluna > [ {nome-coluna}...]

17

2.3.2 Domnios e Asseres

Alm destas restries, existem restries de domnio (domain) e restries

afirmativas (assertion):

- DOMAIN: define os possveis valores que pode conter um atributo.

- ASSERTION: define restries de integridade sobre os valores de uma tabela com

base em consideraes de busca.

A sintaxe para a especificao de um Domain a seguinte:

CREATE DOMAIN

[DEFAULT ]

[lista-de-restries-do-domnio]

As operaes de gerncia associadas a esta sintaxe so: criao, alterao e excluso

de um domnio.

A sintaxe para a criao de uma assertion a seguinte:

CREATE ASSERTION

CHECK

As operaes de gerncia associadas a esta sintaxe so: criao e excluso de uma

afirmao.

2.3.3 Funes e Procedimentos

Existem tambm rotinas na linguagem SQL3, que podem ser utilizadas para a

especificao de regras, estas rotinas so procedimentos ou funes armazenadas. Uma rotina

um bloco SQL nomeado e, uma vez criado, armazenado no banco de dados. A diferena

na especificao de uma funo com relao a um procedimento est na adio da clusula

Return diante do nome da Funo. A sintaxe utilizada para a especificao de um

procedimento na linguagem SQL3 (ISO/IEC 9075-2, 1999; TRQUER; GERTZ, 2001):

18

CREATE PROCEDURE

({ } ... )

[AS]

: identifica o nome do procedimento

: especifica se uma ou mais variveis so passadas como parmetros

para o procedimento. Para cada varivel, deve ser especificado um tipo de argumento (IN,

OUT ou IN OUT), especificado em seguido do seu tipo de dado. Por exemplo,

nome_usurio IN varchar(20) (varivel IN tipo-de-dado). O tipo de argumento IN passa um

valor externo ao procedimento para o procedimento, OUT realiza a operao inversa e IN

OUT combina as duas operaes.

As rotinas so armazenadas em tabelas prprias, e as operaes de gerncia associadas

a elas so: criao, alterao e excluso.

2.3.4 Triggers

Um outro objeto empregado para a representao de regras em sistemas de informao

so os triggers. Estes mecanismos, ao contrrio das rotinas e das restries de integridade,

tm a capacidade de reagir a diferentes eventos, internos ou externos ao banco de dados, da

mesma forma que so utilizados para monitorar situaes de interesse no banco de dados, e

uma vez detectadas, executam-se aes previamente definidas. Uma caracterstica dos

triggers, quando comparados com as rotinas, o fato de serem disparados, automaticamente,

sem o recebimento ou retorno de parmetros (ELMASRI; NAVATHE, 2005; FORTIER,

1999). A sintaxe de definio de um trigger, segundo a notao BNF, a seguinte (ISO/IEC

9075-2, 1999).

CREATE TRIGGER

{BEFORE|AFTER}

[REFERENCING ]

[FOR EACH {ROW|STATEMENT}]

[when ()]

19

Cada trigger tem um nome que o identifica, um evento, uma condio e uma ao.

Alm destes trs elementos, fazem parte do trigger informaes sobre seu tempo de ativao e

variveis de transio. O tempo de ativao representa uma relao entre o momento de

ocorrncia do evento e o momento de execuo da regra. A execuo de uma regra representa

a avaliao de sua condio e execuo de sua ao. Existem dois tipos de ativao, antes

(before) ou depois (after). Assim, uma regra pode ser executada antes da execuo da

operao definida como evento ou aps a execuo desta operao. A sintaxe da clusula

evento a seguinte:

::= {INSERT | UPDATE | DELETE} [OF ]

ON

As operaes de manipulao de dados (insert, update e delete) so utilizadas como

evento em um trigger. Considerando a clusula do evento, possvel especificar as colunas de

interesse sempre que o evento for uma operao de atualizao de dados

(update) sobre alguma tabela. Desta forma, o trigger ser disparado quando ocorrer alguma

operao de atualizao sobre as colunas listadas em sua definio. A clusula refere-se tabela sobre a qual realizada a operao de atualizao.

Na especificao do trigger, possvel fazer referncia a valores passados e valores

futuros que so atribudos a um atributo, por meio de variveis de transio. Os valores que

so referenciados na varivel old referem-se aos valores anteriores modificao da tabela e

os valores referenciados na varivel new so os valores posteriores modificao dela.

Na expresso , da sintaxe do trigger, possvel especificar,

tambm, nomes alternativos para as variveis de transio old e new,

segundo a notao:

::= OLD [ROW] [AS]

| OLD [TABLE] [AS]

| NEW [ROW] [AS]

| NEW [TABLE] [AS]

Os elementos da sintaxe utilizada para especificar os valores de transio so

descritos, a seguir, por meio de um exemplo ilustrativo:

Considerando a seguinte expresso: REFERENCING OLD as valor_antigo. O

20

valor_antigo utilizado para acessar os valores de referencia varivel old,

independentemente que seja utilizada no elemento condio ou na ao do trigger. A varivel

guarda uma relao direta com a operao definida no evento do trigger. Quando a operao

de insero pode-se utilizar somente a varivel new, quando a operao de atualizao, as

variveis podem ser old ou new e para ocaso de que a operao seja uma excluso ento a

varivel deve ser old.

Na definio do trigger, tambm especificada a granularidade de processamento da

regra. A granularidade de processamento representa o nmero de vezes que o trigger

disparado em relao ao evento. Ela pode ser ao nvel de tupla (FOR EACH ROW) ou ao nvel

de conjunto (FOR EACH STATEMENT). Quando no especificada a granularidade da regra,

assume-se a granularidade de conjunto.

Na do trigger pode ser especificado um predicado sobre o estado do

banco de dados, na forma de uma expresso simples ou uma consulta SQL. A condio pode

apresentar operadores booleanos binrios (OR ou AND) com a finalidade de combinar outros

predicados.

No seguinte exemplo, so empregadas variveis de transio, granularidade da regra e

uma condio simples.

CREATE TRIGGER atualizar_salario

AFTER UPDATE ON EMPREGADO

REFERENCING OLD as salario_antigo

NEW as salario_atual

FOR EACH ROW

WHEN (salario_antigo.salario < salario_atual.salario)

Neste exemplo, o trigger denominado atualizar_salario, e tem especificada na

clusula de evento a definio de uma operao de banco de dados UPDATE, sobre a tabela

EMPREGADO. Definem-se duas variveis de transio, salario_antigo e salrio_atual,

como tambm especificada a granularidade de processamento da regra (FOR EACH ROW).

Portanto, para cada registro da tabela EMPREGADO em que o salrio atualizado, verifica-

se a condio da regra (WHEN). No caso que seja verdadeira, a ao especificada na executada, caso contrrio, nada acontece.

21

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

um bloco SQL, segundo a especificao:

::=

::= BEGIN

{ } ...

END;

Uma sentena SQL procedimental um conjunto de operaes ou sentenas vlidas na

linguagem SQL3 que incorpora recursos de programao, como por exemplo,

IF...THEN...ELSE, REPEAT, WHILE, sentenas de linguagem de manipulao de dados,

sentenas de controle de fluxo, variveis e cursores, entre outros.

Um bloco SQL um conjunto destas sentenas, delimitado pelas clusulas BEGIN e

END. O exemplo a seguir apresenta um exemplo de bloco SQL especificado na ao de um

trigger.

CREATE TRIGGER valor_max_emprestimo

AFTER INSERT ON CLIENTE

FOR EACH ROW

WHEN (new.categoria = A)

DECLARE

V_codpedido PEDIDO_EMPR.codpedido %TYPE;

BEGIN

SELECT codpedido INTO V_codpedido

FROM PEDIDO_EMPR

WHERE codcli = :new.codcli;

UPDATE PEDIDO_EMPR

SET valor_max_empr = new.salario_anual * 0,5

WHERE codcli = :new.codcli

AND codpedido = V_codpedido;

END;

Neste exemplo, o trigger valor_max_emprestimo possui um evento definido pela

operao de banco de dados INSERT sobre a tabela CLIENTE, com um tempo de ativao

22

AFTER. Portanto, este trigger disparado toda vez que houver a insero de um registro

nesta tabela.

Na condio do trigger avaliado o valor do atributo categoria, se o valor do

atributo em questo A, ento, a ao executada. A ao compreende o cdigo definido

entre os delimitadores BEGIN e END. A ao composta de um bloco SQL, contendo duas

operaes de banco de dados. A primeira operao consiste em uma consulta sobre a tabela

PEDIDO_EMPR, com a finalidade de identificar o cdigo do pedido associado ao cliente que

foi inserido na referida tabela, por meio do evento que disparou esta regra. A segunda

operao composta por uma atualizao de dados sobre a tabela PEDIDO_EMPR. Esta

operao reajusta o valor do emprstimo do cliente em funo de seu salrio anual. As

operaes do tipo insero, excluso e atualizao podem ser o marco inicial para o disparo

de outras regras. No trigger apresentado, existe uma operao de atualizao que ao ser

executada, pode disparar qualquer outro trigger que possua um evento definido com esta

mesma operao de banco de dados sobre a mesma tabela a qual incide o evento. A este

evento define-se como evento de ativao. A este disparo de regras implcito, d-se o nome de

encadeamento de regras ou encadeamento de triggers. Um aspecto no permitido a

existncia de um auto-trigger, ou seja, um trigger que possui, em sua ao, o seu evento de

ativao. Todas as informaes sobre os triggers so armazenadas no dicionrio de dados dos

SGBDAs.

As operaes de gerncia sobre a definio de um trigger, segundo a linguagem

SQL3, so CREATE TRIGGER e DROP TRIGGER. A primeira operao tem a funo de

criar um trigger e armazen-lo no dicionrio de dados, enquanto que a segunda operao

exclui o trigger do dicionrio de dados (TRQUER, 2001). Os triggers so armazenados em

tabelas que formam parte do dicionrio de dados junto com os meta-dados e as tabelas

utilizadas para armazenar dados da aplicao. Na linguagem SQL3 no existe o conceito de

repositrio de regras, ou seja, um conjunto de tabelas utilizadas para armazenar os triggers,

sob o domnio de uma infra-estrutura dedicada ao gerenciamento destas regras.

2.4 MODELO DE REGRAS EM SBDAS

Um Sistema de Banco de Dados Ativos possui um modelo de regras (PATON; DAZ,

1999), composto por um modelo de definio e um modelo de execuo de regras. O modelo

de definio determina o que deve ser especificado na regra (sintaxe da regra), enquanto que o

23

modelo de execuo determina como ser o processamento das regras. O modelo de regras

varia de um SGBDA comercial para outro, no entanto os conceitos bsicos adotados por eles

esto presentes no modelo de regras da linguagem SQL3. A finalidade de descrever o modelo

de regras da linguagem SQL3 reside no fato de que este modelo guarda uma relao direta

com o repositrio de regras, pois o repositrio armazena as caractersticas ou propriedades das

regras. O repositrio de regras conseqncia do modelo de regras adotado. A seguir, so

detalhados os modelos de definio e execuo utilizados pela linguagem SQL3.

2.4.1 Modelo de Definio de Regras

O modelo de definio de regras de um SGBDA compreende um conjunto de

sentenas representadas por meio de uma linguagem de definio de regras, cuja finalidade

a especificao de regras ECA (Evento-Condio-Ao). A sintaxe genrica para a definio

de uma regra ECA a seguinte.

DEFINE RULE

ON

IF

DO

Este padro de regra tem sido seguido por vrios SGBDAs comerciais, com a

denominao de triggers, e cada sintaxe definida em um SGBDA comercial pode sofrer

pequenas modificaes, e isto depende diretamente das caractersticas que foram adotadas

pelo SGBDA para a especificao de uma regra. (PATON; DIAZ, 1999; VADUVA, 1999;

ELMASRI; NAVATHE, 2005).

Cada regra deve ser definida com um nome nico. O evento da regra especifica um

acontecimento que dispara a regra. A condio da regra representa um predicado que deve ser

avaliado. Quando o resultado desta avaliao verdadeiro, ento a ao executada. Quando

este resultado falso, a regra no executada.

- Evento

Um evento definido como uma ocorrncia atmica sobre o banco de dados (DIAZ,

1991). O evento produzido por uma fonte, a saber, um sistema informtico externo ao

SGBDA, o prprio SGBDA, um hardware ou interao do prprio usurio com o banco de

24

dados. Um SGBDA detecta a ocorrncia dos eventos e d continuidade ao processo com o

disparo das regras que pode por ele serem disparadas. Uma regra disparada por um evento,

mas um evento pode disparar mais de uma regra.

Os eventos podem ser primitivos ou compostos. Um evento primitivo ou simples,

ocorre quando se est diante de uma nica ocorrncia, como por exemplo, uma operao de

banco de dados ou um fato temporal (ACT-NET CONSORTIUM, 1996; JAIME, 1998). A

combinao de eventos primitivos com operadores (AND, OR, SEQUENCE) deriva os

eventos compostos, que por sua vez podem conter outros eventos compostos

(BERNDTSSON; MELLIN; HOGBERG, 1999). Na Figura 1, so apresentados estes

conceitos (CHAKRAVARTHY; MISHRA, 1993).

Figura 1 - Classificao de eventos nos SBDAs (CHAKRAVARTHY; MISHRA, 1993).

Esta classificao tem sido adotada por vrios outros trabalhos (ACT-NET

CONSORTIUM, 1996; GUERRINI, 1998; KANGSABANIK, 1998; VADUVA, 1999;

BERNDTSSON; MELLIN; HOGBERG, 1999; TORRICO; TANAKA; MOURA, 2000;

BONATTI et al., 2004; PAVON, 2005;), e apresenta os eventos primitivos como eventos de

banco de dados, explcitos e temporais. Os eventos de banco de dados so operaes de

manipulao de dados (CHAKRAVARTHY; MISHRA, 1993) como insert, update e delete,

considerando o modelo relacional. Quando o modelo orientado a objetos, ento as operaes

de eventos so mensagens ou chamadas a mtodos (GEPPERT et al., 1995; GATZIU, 1997).

Os eventos explcitos fazem parte da lgica do negcio que so especificadas na aplicao.

Eventos temporais podem ser definidos dentro de dois domnios, absolutos ou relativos. O

primeiro, evento temporal absoluto, diz respeito definio de um momento especfico no

tempo, como por exemplo, 21 de Maro de 2006 s 16 horas. O segundo, evento temporal

relativo, define uma ocorrncia em relao outra. Uma hora aps a ocorrncia do primeiro

Eventos

Eventos Primitivos

Eventos Compostos

Eventos de BD Explcitos Temporais

25

evento ou um evento composto da unio de dois eventos primitivos por um conector

booleano.

Uma vez que o evento detectado, ele armazenado no repositrio de dados, em uma

tabela especfica para armazenamento de suas informaes, tais como o seu nome, o nome da

tabela referenciada por ele e as colunas especificadas na sintaxe do evento. A existncia de

um repositrio de regras a base para que seja possvel manipular as informaes nele

armazenadas. Porm, no existem operaes de gerncia sobre eventos. As operaes de

gerncia de regras se limitam sua criao e excluso. Desta forma, para especificar um

evento diferente para uma regra, necessrio eliminar e criar novamente a regra com o novo

evento.

A regra pode ser disparada em funo de dois momentos no tempo. O primeiro

momento pode ser especificado por meio da sentena antes (before), sendo que a regra

disparada antes da ocorrncia da operao do evento. O segundo momento indicado por

meio da sentena depois (after), no qual a regra disparada depois da ocorrncia da

operao definida no evento. O evento um componente obrigatrio na especificao da

linguagem de regras ECA (ACT-NET CONSORTIUM, 1996; TORRICO; TANAKA;

MOURA, 2000).

- Condio

A condio o componente que expressa o que deve ser avaliado para que a ao da

regra seja executada. semelhana do evento, a condio pode ser simples ou composta

(HERBST; MYRACH, 1995). Uma condio simples representa um predicado atmico,

definida por meio de uma expresso simples (por exemplo: maior que 18 anos) ou uma

consulta SQL. Tambm permitido o uso de variveis de transio, old e new, nas consultas

SQL, para referir-se aos valores antigos ou novos de um atributo. Quando a condio se

compe de vrios predicados simples unidos por operadores booleanos do tipo AND ou OR,

dita composta.

As regras Evento-Ao (EA) so uma variao das regras ECA, tendo como

caracterstica a omisso da condio da regra (PATON; DIAZ, 1999). Desta forma, quando

um evento detectado, sua ao imediatamente executada.

26

- Ao

A ao um conjunto de operaes que expressa a reao ao evento detectado. Na

ao de um trigger, pode-se especificar um conjunto de sentenas procedimentais SQL ou um

bloco SQL. Uma sentena procedimental pode ser uma sentena SQL ou uma sentena SQL

estendida, que permite o uso de comandos de controle de fluxo, inclusive, o uso de variveis

de transio para acessar valores antigos ou valores novos de uma instncia da tabela. Quando

estas sentenas SQL envolvem operaes de banco de dados, do tipo insert, update e delete,

sobre algum objeto do banco de dados, e so tambm definidas em outras regras como

eventos, ento, este contexto forma um encadeamento de regras.

Problemas associados ao encadeamento de regras so amplamente discutidos na

literatura (AIKEN; HELLERSTEIN; WIDOM, 1992; AIKEN; WIDOM; HELLERSTEIN;

1995; ZIMMER; UNLAND; MECKENSTOCK, 1996; VADUVA; GATZIU; DITTRICH,

1997; VADUVA, 1999; BARALIS; WIDOM, 2000; COUCHOT, 2001) no sendo, portanto,

abordadas neste trabalho.

possvel utilizar, na ao, combinaes de operaes de banco de dado em uma

sentena SQL, por meio de operadores booleanos, o que caracteriza uma ao composta.

(TORRICO; TANAKA; MOURA, 2000)

2.4.2 Modelo de Execuo de Regras

O modelo de execuo de regras define como ser o processamento de uma regra ou

de um conjunto de regras (PATON; DIAZ, 1999; TURKER, 2001; VADUVA, 1999) e

determina as propriedades da execuo de regras, como granularidade de processamento e

modo de acoplamento, entre outras. Com a finalidade de descrever melhor o alcance do

modelo de execuo, na Figura 2 so apresentados os principais passos realizados durante o

processamento de um conjunto de regras (PATON; DIAZ, 1999).

27

Figura 2 - Passos envolvidos no processamento de regras (PATON; DIAZ, 1999; VADUVA, 1999).

Sistemas de informao, freqentemente, acessam bancos de dados para realizar

modificao nos dados. Estas modificaes so conseqncia do uso de operaes de bancos

de dados. Estas operaes so detectadas pelo SGBDA, que por sua vez, dispara todas as

regras que possuem como evento estas operaes. O processamento de regra se inicia com a

deteco do evento. Quando se trata de evento composto, um sistema de deteco de evento

composto analisa as diversas ocorrncias de eventos simples que contribuem para o evento

composto desejado, e dispara as regras a ele associadas. Berndtsson apresenta uma anlise de

diversas tcnicas para a deteco de eventos (BERNDTSSON; MELLIN; HOGNERG, 1999)

que so utilizadas em diversos SGBDA, como SENTINEL (CHAKRAVARTHY et al., 1994)

e SAMOS (DITTRICH et al., 2000).

Quando uma nica regra disparada, assume-se a deteco de um evento, avalia-se a

condio e executa-se a ao, desde que a condio seja verdadeira. No entanto, em um

sistema de regras, geralmente mais de uma regra disparada, pelo mesmo evento, gerando um

conjunto de disparo simultneo de regras. Uma regra disparada quando o seu evento

detectado pelo SGBDA, e a regra passa ao estado de execuo quando a condio da regra

Evento Detectado

Regras Selecionadas

Regras Executadas

deteco do evento

disparo

escalonamento

execuo

While conj. regras selecionadas. 0 Do { selecionar a regra avaliar a condio executar a ao }

encadeamento de regras.

Regras Disparadas

28

avaliada e sua ao pode ser executada (PATON; DIAZ, 1999; PAVON, 2005). O

processamento de consulta adotado considera a execuo serial de regras, ou seja, uma regra

por vez disparada e executada. Porm existe outra viso, no qual regras so disparadas

simultaneamente. Neste caso, a condio e a ao das regras so avaliadas e executadas

concorrentemente, o que demanda um controle de concorrncia de regras para que a execuo

de uma regra no interfira na execuo da outra (KANGSABANIK, 1998; CERI; WIDOM,

1992).

Quando ocorre um conjunto de conflito de regras, est-se diante de um conflito quanto

ordem de execuo das regras. Antes de aplicar um critrio de seleo para a execuo das

regras, o SGBDA classifica as regras em dois grupos. As regras com tempo de ativao before

e as regras com tempo de ativao after. O passo seguinte executar as regras do primeiro

grupo, e depois do segundo grupo. Considerando que existem vrias regras, tanto do primeiro

quanto do segundo grupo, ento a fase de escalonamento, no processamento de regras, utiliza

estratgias para solucionar este impasse por meio de critrios de prioridade ou precedncia,

com a finalidade de determinar a ordem de execuo de tais regras.

Para alguns SGBDAs, o critrio de prioridade definido pela datahora de criao da

regra, como o caso do SAMOS (PATON, 1998) e ORACLE (ORACLE CORPORATION,

2003). Existem outros SGBDAs que adotam pesos, definidos pelo usurio, e quando o peso

o mesmo para duas ou mais regras, ento, o critrio passa a ser aleatrio. O processamento de

regras pode se repetir quando uma regra possui, em sua ao, algum evento de ativao, que

leve ao disparo de outras regras, reiniciando este processo. Um modelo para a resoluo de

conflitos uma caracterstica marcante dos SGBDAs, visto que, esta propriedade varia entre

cada um deles. Portanto, um sistema de regras, ao ser especificado em um SGBDA, deve

considerar esta propriedade.

No manifesto, ou documento de intenes, sobre regras em SGBDA (ACT-NET

CONSORTIUM, 1996) apresentado um conjunto de propriedades desejveis que um

modelo de execuo de regras deve possuir, dentre estas, as principais so:

a) o SGBDA deveria implementar um modelo de resoluo de conflito, por exemplo os

que foram apresentados anteriormente;

b) Um SGBDA deveria atender ao conceito de granularidade de processamento de

regras. Esta granularidade refere-se ao grau de relacionamento entre a ocorrncia do

evento e o disparo da regra. Existem basicamente duas dimenses para este

relacionamento, a primeira a granularidade de tupla, na qual a regra disparada para

29

cada tupla afetada pelo evento, e a segunda, a granularidade de conjunto, na qual a

regra disparada uma nica vez para todo o conjunto de tuplas afetadas pelo evento;

c) Um SGBDA deveria oferecer um modo de acoplamento. O acoplamento ocorre entre

os componentes evento-condio e os componentes condio-ao da regra. As regras

so definidas dentro de transaes, e os eventos fazem parte de transaes tambm. No

entanto, tambm existem modos de acoplamento que fazem referncia a transaes

diferentes, para o mesmo processamento de regra. Estes acoplamentos so definidos

como desacoplados, pois a condio avaliada dentro de uma transao diferente da

transao no qual o evento ocorreu. Da mesma forma, a ao executada dentro de

uma transao diferente da transao na qual a condio ocorreu. Os acoplamentos

referentes mesma transao so definidos como: imediato e atrasado. O primeiro

ocorre quando a condio avaliada imediatamente depois que ocorreu o evento, ou a

ao avaliada imediatamente depois que a condio foi avaliada.

O segundo caso, atrasado, acontece quando a condio avaliada dentro da mesma

transao que o evento da regra, porm no necessariamente na primeira oportunidade,

geralmente o processamento adiado para o final da transao, ou a ao executada dentro

da mesma transao que a condio da regra, mas no necessariamente na primeira

oportunidade. Em Paton (PATON; DIAZ, 1999) apresentado um resumo dos principais

SGBDAs com os seus tipos de acoplamento. A maioria deles opta pelo processamento da

regra dentro da mesma transao.

2.5 ESTRUTURAS DE ARMAZENAMENTO DE REGRAS

O modelo de regras contm informaes que devem ser atendidas pelo repositrio de

regras. Por exemplo, no repositrio so armazenadas a data e hora de criao do trigger, os

eventos definidos na sua sintaxe, o tempo de ativao deste evento, entre outros. Todo

SGBDA possui um repositrio de regras, para armazenar informaes advindas do modelo de

regras. Nesta seo, so analisados diferentes repositrios de dados: o recomendado pela

linguagem SQL3 e um repositrio comercial.

30

TRIGGERS TRIGGER

TABLE USAGE

COLUMNS TABLES

TRIGGERED UPDATE

COLUMNS

TRIGGER COLUMN USAGE

(0, N)

(0, N)

(0, N) (0, N)

(1, 1)

(1, 1)

(1, 1)

(1, 1)

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

(1, N)

(1, N)

(1, N)

(1, N) (1, 1)

2.5.1 Repositrio Sugerido pela Linguagem SQL3

O dicionrio de dados proposto pela linguagem SQL3 (ISOIEC 9075-2, 1999)

armazena informaes sobre definio das regras e o relacionamento delas com os meta-

dados (tabelas e colunas). Na Figura 3 so apresentadas as estruturas sugeridas pela

linguagem SQL3.

Figura 3 - Repositrio de regras da linguagem SQL3 (ISOIEC 9075-2, 1999)

A tabela TRIGGER TABLE USAGE armazena informaes sobre tabelas utilizadas na

condio ou na ao de um trigger. A tabela TRIGGERS COLUMN USAGE armazena

informaes sobre as colunas utilizadas no evento, na condio ou na ao do trigger, com

exceo da operao de atualizao que especificada na tabela TRIGGERED UPDATE

COLUMNS. A tabela TRIGGERS contm, efetivamente, todas as informaes especificadas

na definio do trigger como a definio da operao definida no evento, tempo de ativao,

entre outros. Cada trigger deve estar associado a uma tabela, e pode estar associado, implcita

ou explicitamente, a colunas desta tabela. Os meta-dados TABLES e COLUMNS,

representados por retngulos pontilhados, tm por finalidade representar estas associaes.

A Tabela 2.3 apresenta as informaes mais relevantes sobre as tabelas que so

31

utilizadas em um trigger para efeito de anlise neste trabalho. Por exemplo, as demais

informaes que constam da tabela TRIGGER TABLE USAGE e que no esto presentes

uma linguagem de gerÊncia de regras como … · 3.3.2.2 outros mecanismos associados ao modus...

Documents