BANCOS DE DADOS ATIVOS

Mariano Cilia
Universidad Nacional del Centro de la Provincia de Buenos Aires Facultad de Ciencias Exactas - Instituto de Sistemas Tandil. San Martin 57, (7000) Tandil, Buenos Aires, Argentina e-mail: mcilia@dcc.unicamp.br

SUMRIO
Os bancos de dados ativos so sistemas de banco de dados estendidos com um sistema de regras. Este sistema capaz de reconhecer eventos, ativar as regras correspondentes e quando a condio verdadeira executa as aes que correspondam, segundo o paradigma E-C-A proposto em [DBM88]. Este sistemas podem ser usados para aplicaes financeiras (commodity trading, portfolio management, currency trading, etc.), aplicaes multimdia, controle da produo industrial (CIM, controle de inventario, etc.), monitoramento (controle de trfego areo, etc), entre outros [Buch94]. Tambm so usados para funes do prprio ncleo do banco de dados, como por exemplo, manuteno de consistncia, manuteno de vises, controle de acesso, gerenciamento de verses, entre outras. Neste artigo descrevem-se as principais caractersticas dos bancos de dados ativos que so classificadas em trs grupos: definio de regras, modelo de execuo e otimizao. Logo so descritos as caractersticas ativas dos principais prottipos desenvolvidos na rea.

1. INTRODUO
Um banco de dados passivo quando no oferece suporte para o gerenciamento automtico de condies definidas sobre o estado do banco de dados em resposta a estmulos externos. Os sistemas de gerenciamento de banco de dados (SGBDs) convencionais so passivos, s executando transaes quando so explicitamente requisitadas pelo usurio ou aplicao. Um banco de dados ativo quando eventos gerados interna ou externamente ao sistema provocam uma resposta do prprio banco de dados (BD), independente da solicitao do usurio. Neste caso, alguma ao tomada automaticamente dependendo das condies que foram especificadas sobre o estado do banco de dados. Este paradigma
Atualmente realizando estudos de posgraduao no Departamento de Cincias da Computao IMECC - UNICAMP, Campinas, S Paulo, Brasil.

 til para implementar vrias funes do prprio banco de dados ou mesmo para estendlas. Alguns exemplos de aplicaes so: controle de integridade, controle de acesso, polticas de segurana e atualizao.

Novos dados

consultas ????

Aes desencadeadas por respostas relevantes Monitoramento (aplicao 1)

BD Passivo
{} {} {} {} respostas

Respostas Irrelevantes

Figura 1. Polling [Buch94].

H diferentes formas de transformar um banco de dados passivo em ativo. Segundo [CN90], as mais tradicionais so: escrever no prprio programa de aplicao a condio que se deseja testar; e avaliar continuamente a condio, ou seja, polling (figura 1). Uma desvantagem da primeira alternativa que a avaliao da condio responsabilidade do programador. No segundo caso, o problema pode ser a baixa utilizao dos recursos se houver uma excessiva frequncia dos testes de condio. Estes problemas so resolvidos parcialmente com o uso de regras e gatilhos. Bancos de dados dedutivos fornecem um mecanismo para derivar dados que no esto explicitamente armazenados no banco de dados (conhecidos como dados virtuais ou dados derivados). So mais poderosos e expressivos que as vises, embora mais problemticos para serem suportados [LT92]. No existe uma diviso bvia entre os bancos de dados dedutivos e os ativos. A principal diferena est baseada no modelo de execuo. No primeiro tipo, geralmente a preocupao a derivao de informao, e as regras so executadas explicitamente pela aplicao. No segundo, as regras (ou gatilhos) so disparadas como efeito colateral das aes normais do banco de dados [Wid93]. As pesquisas em banco de dados ativos (BDA) podem ser divididas em trs categorias: i) a definio das regras ou gatilhos, ii) seu correspondente modelo de execuo, e iii) a sua otimizao. Na primeira categoria definem-se quais so os tipos de eventos, condies e aes. Uma questo muito importante a expressividade da linguagem de especificao. Na segunda categoria, a maioria dos artigos especifica com detalhe os modelos de execuo e alguns outros s esquematizam o sistema

implementado. Nesta categoria discute-se quando devem ser avaliadas as condies, ou como devem ser resolvidos os conflitos (quando mais de uma regra habilitada ao mesmo tempo). Por ltimo, existe o problema da otimizao da execuo, tendo em considerao estratgias eficientes para avaliao da condio. Na seo seguinte so descritas algumas das aplicaes dos sistemas de gerenciamento de BDA. A seguir so apresentadas as caractersticas dos BDA segundo as trs categorias descritas anteriormente (definio de regras, modelo de execuo, e otimizao da execuo). Finalmente, so descritas as caractersticas "ativas" dos principais prottipos desenvolvidos na rea.

2. USO DOS SISTEMAS ATIVOS

Os sistemas de bancos de dados ativos podem ser classificados em trs grupos segundo seu uso [VK93], a saber:
Suporte automtico ao usurio Notificao: Em algumas situaes o banco de dados precisa da interveno do usurio. As regras podem ser usadas para detectar automaticamente estas situaes e informar ao usurio. Execuo automtica de procedimentos: Ante a ocorrncia de um evento, um procedimento pode ser executado mediante o uso do sistema de regras.

Provimento de valores default: Uma operao comum nas aplicaes a atribuio de valores default, que pode ser feita diretamente com regras.
Funcionalidade do modelo de dados Manuteno da integridade: Uma restrio de integridade, num ambiente de BD, um predicado sobre estados do BD que deve ser mantida, para assegurar a consistncia dos dados. Num sistema ativo, as condies que violam a integridade so especificadas na parte da condio da regra e a ao corretora especificada na parte correspondente ao. Este esquema traz duas vantagens importantes: i) o BD suporta especificao e manuteno de restries, sem depender do cdigo da aplicao, ii) o BD serve para todas as aplicaes que tm a mesma viso do mundo. Maiores detalhes sobre manuteno de integridade podem ser encontrados em [MA92, CW90]. Proteo: O acesso ao banco de dados pode ser controlado usando regras. Com este esquema no s pode ser aceito ou rejeitado o acesso aos dados, como tambm o sistema pode fornecer dados fictcios nos campos protegidos. Gerenciamento dos recursos

As regras so usadas dentro do prprio ncleo do BD.

Otimizao do armazenamento fsico: Podem ser usadas para aes de checkpoint, clustering, caminhos de acesso, ou tambm para adaptar as estruturas de armazenamento segundo estatsticas das consultas. Gerenciamento de vises: Vises materializadas complexas podem ser mantidas com regras [SJGP90].

3. REGRAS E GATILHOS
Bancos de dados ativos so via de regra implementados a partir de mecanismos de regras de produo. Regras so descries de comportamento a serem adotadas por um sistema. As regras esto geralmente baseadas em trs componentes: evento, condio e ao (E-C-A) [DBM88]. O evento um indicador da ocorrncia de uma determinada situao. Uma condio um predicado sobre o estado do banco de dados. Uma ao um conjunto de operaes a ser executado quando um determinado evento ocorre e a sua condio avaliada como verdadeira. Um evento pode disparar uma ou mais regras. O primeiro na formalizao de sistemas ativos foi Morgenstein. No trabalho descrito em [Mor84] utilizam-se os sistemas ativos para manter restries atravs das equaes de restries (Constraint Equation, CEs). As CEs permitem expressar restries semnticas que requerem consistncia entre muitas relaes, de forma similar manuteno de relaes. As CEs constituem uma forma mais concisa que a escrita de procedimentos para expressar e garantir restries, por possurem representao declarativa, e uma interpretao executvel, sendo compiladas em rotinas para garantir automaticamente as restries. De acordo com [SR88], os gatilhos so associaes de condies e aes. A execuo da ao ocorre quando o banco de dados evolui para um estado que leva o gatilho condio verdadeira. 3.1. REGRAS E-C-A A forma atualmente aceita para considerar un BDA a adoo de regras de produo E-C-A.
Evento. O evento um indicador da ocorrncia de uma determinada situao (quando avaliar). Como mostrado na figura 2 existem basicamente trs tipos de eventos: temporais (s 8:30, repetidas vezes toda sexta s 10:00), definidos pelo usurio (alta temperatura, user-login, etc.), e operaes prprias dos BD (insert, delete, update, select). Condio. Uma condio um predicado sobre o estado do banco de dados (o

que avaliar). Condies so comumente implementadas por consultas ou por procedimentos da aplicao. Ao. Uma ao um conjunto de operaes a ser executado quando um determinado evento ocorre e a condio associada avaliada como verdadeira (como

responder). Um evento pode disparar uma ou mais regras. As aes tpicas so: operaes de modificao ou consulta, comando do BD (commit, rollback), ou procedimentos da aplicao (podendo ou no acessar o BD). Existem dois aspectos importantes no projeto da linguagem de regras de produo: a sintaxe para a criao, modificao, e eliminao de regras; e a semntica do processamento das regras na execuo. A sintaxe da maioria das linguagens similar (baseadas na extenso da linguagem de consulta). No entanto, a semntica do processamento varia consideravelmente. 3.2. COMPONENTES Na figura 2 so mostrados os componentes de um BDA, que adiciona caractersticas ativas (que sero descritas a seguir) s funes caractersticas dos BD convencionais (controle de concorrncia, recuperao ante falhas, persistncia, otimizao de consultas, e outras [ABD+92]).

m os Te Event

s porai

surio ntos U Eve B os do Event D

cia orrn Conc de role Cont o er a ecup R ia ltas tnc onsu ersis o de C P iz a Otim s ento etc. e Ev

d s ie ao nitor de Cond Mo o es lia Ava o das A u Exec

AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA

Aes

Figura 2. Componentes de um Banco de Dados Ativo [Buch94].

So trs as componentes bsicas para a obteno de um sistema ativo:

Monitoramento de Eventos: o mdulo encarregado de detectar eventos e ativar as regras que dependam desse evento. Avaliao da Condio: Depois que o evento foi detectado o avaliador da

condio responsvel pela avaliao eficiente das condies. Aquelas regras cujas condies sejam verdadeiras so passadas para o Executor de aes.

 Execuo de Aes: Este componente coordena o sincronismo entre deteco de

eventos e execuo de aes. As aes podem ser executadas de imediato (antes do fim da transao que disparou a regra), ou depois (numa transao independente). A ligao entre a execuo de aes e regra denominada modo de acoplamento. Dependendo dos modos de acoplamento a serem adotados pelo sistema de regras, o gerenciador de transaes subjacente deve suporte transaes aninhadas. 3.3. LINGUAGENS PARA ESPECIFICAR EVENTOS Um BDA precisa detectar a ocorrncia de qualquer evento definido para poder iniciar a ativao das regras. Para que as situaes reais possam ser monitoradas, uma linguagem de definio de eventos deve ser empregada permitindo a modelagem de situaes complexas. Alguns exemplos deste tipo de linguagens so Ode [GSJ92b], Samos [GD93], Compose [GJS92a] e Snoop [CM93] entre outros. lgebras de eventos so incorporadas s linguagens de especificao de eventos para permitir a composio de eventos. Os principais operadores encontrados em lgebras de composio como as de Ode, Samos, Snoop, e Compose so: Seqncia. Indica que o evento composto acontece quando os eventos que constituem a seqncia tiverem ocorrido na ordem determinada. Conjuno. Indica que o evento composto acontece se todos eventos que formam a conjuno ocorreram, independente da ordem relativa entre eles.
Disjuno. Indica que o evento composto ocorre se pelo menos um dos eventos que formam a disjuno tiver acontecido.

Negao. Indica que o evento composto acontece se os eventos descritos na expresso de negao no tiverem acontecido num determinado intervalo de tempo. 3.4. LINGUAGENS PARA ESPECIFICAR CONDIES Condies so expressas por frmulas, s quais atribudo um valor booleano quando executadas. Uma classificao das possveis teorias da lgica para linguagens de especificao de condies descrita em [VK93]. Entre as teorias esto a lgica proposicional, lgica de primeira ordem, clusulas de Horn, e a lgica temporal. As linguagens de consulta so geralmente usadas para a especificao de condies. Segundo seu resultado quando avaliada (vazio ou no) a condio ser verdadeira dependendo da conveno adotada. 3.5. LINGUAGENS PARA ESPECIFICAR AES As linguagens para especificao de aes podem ser divididas em trs grupos: linguagens de consulta, linguagens de consulta estendidas, e acesso direto ao banco de dados.

Linguagens de consulta: As aes so especificadas com a mesma linguagem de consulta dos sistemas de bancos de dados, como por exemplo SQL. A vantagem que o acesso ao banco de dados fica sob controle do prprio sistema, e a desvantagem que limita a funcionalidade. Por exemplo, no podem ser executadas aes externas ao ambiente do banco de dados.
Linguagens de consulta estendidas: Para que as regras possam interagir com o ambiente externo, a linguagem de consulta precisa ser estendida. Assim a linguagem de especificao de aes pode basear-se em duas partes, a linguagem de consulta e a linguagem de comunicao. Esta ltima baseada em chamadas a procedimentos convencionais ou em primitivas send e receive.

Acesso direto ao banco de dados: Uma linguagem algortmica aumenta a expressividade das aes, quando no podem ser expressas com uma linguagem de consulta estendida. A desvantagem deste tipo de linguagem a reduo das possibilidades de otimizao, que de vital importncia para obter uma performance aceitvel.

4. MODELOS DE EXECUO
Os sistemas de banco de dados tradicionais so passivos. A incluso de gatilhos (ou regras) os convertem em sistemas ativos, com a caraterstica de executar automaticamente tais gatilhos (ou regras). Esta incluso afeta significativamente o modelo de execuo. Segundo [VK93] os conceitos mais importantes envolvidos so: Granularidade da ativao: o nvel onde a ativao do gatilho detectada. Existem quatro opes para a escolha da granularidade: a sesso do prprio banco de dados (A1), a transao (A2), o comando (A3) e a operao (ou primitiva) do banco de dados (A4). Isto significa que a ativao dos gatilhos ou regras s pode ser feita respectivamente entre sesses, transaes, comandos e operaes.
Granularidade dos gatilhos (ou regras): Representa a atomicidade de execuo do gatilho (ou regra), a saber: a prpria regra a unidade de execuo (T1); evento, condio e ao so individualmente atmicos (T2); ou nvel das operaes (T3) que compem o evento, a condio e a ao. Escalonamento da Transao/Aplicao: Depende da unidade de execuo estabelecida pela granularidade do gatilho e pela granularidade da aplicao.

O uso de gatilhos ou regras para notificao, comunicao, e otimizao suportado por todos os modelos de execuo. No entanto, uma granularidade de aplicao mais fina leva a maiores possibilidades no uso de regras. Por exemplo, se a granularidade da ativao no nvel de comando (A3), ento podem-se definir regras para a interao com

o usurio, o que seria impossvel com a granularidade de ativao a nvel de primitivas (A4). No caso da manuteno de integridade, necessrio que a integridade seja verificada (ou at corrigida) antes do commit da transao. Para isto necessrio ter o controle a nvel de comando (A3), para que as regras possam ser executadas imediatamente antes do commit. 4.1. ESCALONAMENTO DA ATIVAO DAS REGRAS Mltiplos gatilhos ou regras podem estar habilitados ao mesmo tempo. Esta situao, conhecida como conjunto prontos para executar, pode levar o sistema a um comportamento inconsistente. Vrios algoritmos so propostos para resolver este problema, a saber:
Execuo em paralelo: Todos os gatilhos ou regras so executados em paralelo. Isto s pode ser feito se as regras no interferem entre si.

Ordem seqencial de execuo: Todos os gatilhos ou regras so executados seqencialmente, a ordem podendo ser tanto aleatria, por prioridade, ou outras.
Execuo simples de uma regra: S uma regra escolhida, com as mesmas opes que no caso anterior.

A execuo de uma regra pode tambm ativar outras regras, o que conhecido como ativao em cascata. Uma vantagem o tratamento uniforme de todas as transaes, mas a desvantagem que possivelmente pode levar a situaes de "livelock".

5. OTIMIZAO
Existem vrias tcnicas de otimizao para execuo de regras que variam segundo os diferentes objetivos dos sistemas ativos e das arquiteturas subjacentes. As caractersticas principais destas estratgias so classificadas em trs grupos: otimizao na execuo das consultas, reduo na execuo de consultas, e otimizao no armazenamento. As estratgias do primeiro grupo so as mesmas que as otimizaes de ordenao de operaes usadas nos sistemas de bancos de dados convencionais e so descritas com detalhe em [Ull82]. No segundo grupo esto os algoritmos para a reduo da quantidade de clculo. Neste caso o objetivo tentar excluir cdigo redundante de subexpresses comuns e evitar execuo de regras ou gatilhos que no so necessrios. H duas estratgias relevantes dentro deste grupo. A primeira a otimizao da avaliao da condio, como, por exemplo, avaliao incremental das condies. A segunda a reduo do tempo de computao das aes. Isto pode ser feito executando as regras o mais cedo possvel, ou deixando-as para depois, quando talvez seja possvel otimizar a execuo atravs de abandono de regras suprfluas ou avaliao em conjunto [VK93].

O ltimo grupo consiste em estratgias para a otimizao no armazenamento de dados e regras. A indexao dos dados neste caso feita tendo em considerao os predicados das regras, reduzindo assim a quantidade de objetos considerados no momento da avaliao da condio. 5.1. DETECO DE EVENTOS obvio que a implementao de um detector de eventos eficiente crucial para ter um bom desempenho num BDA. Existem vrias formas de detectar eventos, alguma das quais so descritas a seguir:
Centralizada. Quando um evento gerado, todas as regras so verificadas. o mais fcil de implementar, mas tambm o de pior desempenho.

ndices. Regras podem ser indexadas segundo os eventos que as ativaram. Assim, quando o evento ocorre, as regras que podem ser disparadas so encontradas rapidamente.
Subscrio. Associao de regras a objetos geradores de eventos. Quando um evento gerado, este enviado a todas as regras que subscreveram aquele evento. No Sentinel usado este mecanismo, mas existe um detector de eventos local cada regra.

Rede de Eventos. Para cada evento composto construda uma rede. O sistema trabalha com uma combinao de redes que inclui todas as redes de todos os eventos compostos. Um evento pode participar em mais de uma composio, enquanto na combinao das redes s existe um estado para cada evento. A vantagem do uso destas regras que os eventos compostos podem ser detectados passo a passo, dada a ocorrncia de um evento primitivo, e no preciso inspecionar um grande nmero de eventos primrios armazenados no registro de eventos. Este mecanismo de deteco implementado em alguns dos prottipos (que sero detalhados a seguir) usando autmatos finitos [GJS92b], redes de Petri [GD94] e grafos [CBB+89, Ber94].

6. ALGUNS EXEMPLOS DE SISTEMAS ATIVOS

O gerenciamento de regras e/ou gatilhos pode ser implementado separadamente do sistema de banco de dados, constituindo uma camada adicional que no est integrada ao ncleo do SGBD [BL92, SKM92]. Outros sistemas de bancos de dados ativos, tanto relacionais como orientado a objetos, foram projetados ou estendidos para tal fim. Ariel [Han89], HiPAC [CBB+89], Ode [GJ92], Postgres [SJGP90], Samos [GD92], Starburst [Wid92] e Sentinel [CHS92] so os projetos mais destacados na rea. A seguir so descritas as caractersticas ativas destes projetos.

6.1. ARIEL [HAN89] Ariel um sistema de gerenciamento de banco de dados implementado sobre Exodus [CFM+86] com um sistema de regras integrado. As principais questes de projeto so a integrao do sistema de regras com o processamento de transaes e a eficincia do sistema todo. O resultado um sistema convencional de gerenciamento de banco de dados relacional estendido com um sistema de regras [Han89]. 6.1.1. Regras Ariel est baseado no modelo relacional. Usa um subconjunto da linguagem de consulta POSTQUEL [SHH88]. A linguagem de especificao de regras de Ariel uma linguagem projetada para ambientes de banco de dados. A condio de uma regra pode basear-se numa combinao de eventos do banco de dados e/ou em um casamento sobre sequncias de eventos. A sintaxe das regras a seguinte: [ priority prioridade ] [ on evento ] [ if condio ] [ then ao ]

prioridade: fornece um controle sobre a ordem de execuo das regras.

evento: permite a especificao do evento que vai ativar a regra. Existem dois tipos de eventos: eventos temporais e eventos prprios dos bancos de dados, tais como append, delete, replace e retrieve. condio: pode se basear numa combinao de eventos de bancos de dados ou casamento de padres sobre uma seqncia de eventos. As condies tambm podem testar condies de transio (baseado no estado prvio e atual). ao: especifica as aes a serem executadas quando a regra disparada. A ao uma seqncia de comandos do banco de dados.

6.1.2. Modelo de execuo As regras podem ser definidas para reagir a simples comandos do banco de dados, tal como delete ou replace. Portanto os eventos so detectados a um nvel de comando, ou seja, granularidade de ativao A3. A ao executada no fim do comando de mais alto nvel onde aconteceu o evento. Ariel define um comando composto como um bloco ou lista de comandos. Um comando chamado de top-level se no est aninhado dentro de um comando composto. O tipo de granularidade de regra T2, dado que o evento e a avaliao da condio esto separados da execuo da ao. A ao executada uma vez para cada um dos objetos no conjunto prontos para executar, e a execuo da regra parte da transao

onde a prpria regra foi ativada, portanto se a ao da regra falhar, a transao abortada. A seleo da regra a ser executada est baseada em prioridades e tempo de ativao. As regras podem acessar tanto o estado do banco de dados, como o conjunto de variveis do evento que causou sua execuo. 6.1.3. Otimizao A avaliao do evento e a condio esto baseadas no algoritmo de Treat [HC+90], chamado A-Treat (Ariel-TREAT). Este algoritmo mantm incrementalmente conjuntos de objetos que satisfazem as condies. No caso em que um evento ativa uma regra, todos os objetos que satisfazem a condio da regra podem ser achados no conjunto. 6.2. HIPAC [CBB+89] O nome HiPAC vem de High Performance ACtive database system. Este projeto considera dois problemas no gerenciamento de restries de dados: a manipulao de restries temporais em banco de dados, e evitar o desperdcio do polling das aplicaes que usam regras. Este projeto trabalha sobre um modelo de dados estendido prprio [DBB+88], e inclui construtores para representar suas regras. Estes construtores utilizam o mecanismo de regras ECA, conseguindo transformar o HiPAC num sistema de banco de dados orientado a objetos ativo. 6.2.1. Regras No HiPAC as regras so tratadas como objetos. Existe uma classe de objetos do tipo regra e toda regra uma ocorrncia desta classe. O tratamento de regras como objetos permite que sejam relacionadas com outros objetos e possuam atributos. Alm disso, podem ser criadas, modificadas ou excludas da mesma forma que outros objetos [DBM88]. A sintaxe das regras a seguinte: identificador-da_regra event evento condition: coupling: modo query: consulta action: coupling: modo operation: operao [ timing-constraints lista-de-restries-temporais ] [ contingency-plans exees ] evento: O evento uma entidade que possui um identificador e uma lista de argumentos formais tipados. Os eventos podem ser: operaes sobre o

banco de dados; temporais (por exemplo, o evento ocorre sempre s cinco da tarde); abstratos (eventos gerados pelas aplicaes); compostos (por exemplo, preciso que ocorram dois eventos em seqncia).
condio: A condio de uma regra um objeto. A condio est baseada na lgica de Horn. Sua estrutura descrita por duas funes: modo de acoplamento e uma coleo de consultas.

O modo de acoplamento do objeto regra descreve a ligao entre a ocorrncia do evento, a avaliao da condio e a execuo da ao. Existem quatro possibilidades:
Imediato: a condio avaliada quando o evento ocorre. Diferido: a condio testada no fim da transao. Acoplado-dependente: a condio testada numa transao

separada, aps o fim da transao que gerou o evento. Se a transao geradora aborta, ento a condio no testada. Acoplado-independente: a condio avaliada em uma transao separada, aps o fim da transao que gerou o evento. A condio sempre testada. As consultas que formam uma regra devem ser todas satisfeitas para que a condio seja verdadeira. ao: um objeto complexo. Sua estrutura definida por duas funes: modo de acoplamento (similar definio da condio) e uma operao (que pode ser por exemplo uma mensagem para algum processo ou algum programa escrito na linguagem de manipulao de dados do sistema).
lista-de-restries-temporais: Corresponde a deadlines, prioridades, urgncias ou funes de valores. No so propriedades exclusivas de regras, mas podem ser acopladas a qualquer tarefa no sistema HiPAC. excees: So aes alternativas que podem ser invocadas sempre que a ao especificada numa regra no possa ser executada.

As operaes sobre os objetos regras so: create (cria uma regra), delete (elimina uma regra), enable (ativa uma regra para que possa ser usada), disable (desativa uma regra) e fire (faz com que a regra seja executada). 6.2.2. Modelo de execuo Um dos objetivos no projeto HiPAC fornecer um bom tempo de resposta aos eventos crticos. assim importante avaliar a condio logo aps que acontea o evento, e executar a seguir a ao. Para cumprir estes objetivos, as regras foram estendidas com os tipos de modo de acoplamento descritos. A granularidade da regra determinada pelo modo de acoplamento e, pode ser tanto T1, como T2 ou T3 [HLM88].

Se um evento ativa mais de uma regra, ento para cada par condio-ao criada uma sub-transao. Uma ao executada uma vez para cada um dos objetos no conjunto prontos para executar. Estes objetos so passados para a ao por meio dos argumentos. As variveis livres so ligadas ao conjunto de objetos que satisfaam ao evento e condio, sendo a ao executada uma vez para o conjunto. 6.2.3. Otimizao Como um dos objetivos de HiPAC o desempenho, foram identificadas vrias tcnicas para a avaliao de condies complexas. Algumas so: otimizao de condies mltiplas, gerenciamento de dados derivados, e avaliao incremental da condio. usada uma estrutura de rede tipo Rete [For82] para o processamento das condies (indexao de dados). Para otimizar a deteco de eventos utilizado o mecanismo de rede utilizando um grafo orientado acclico, chamado signal graph. 6.3. ODE [GJ91] O banco de dados orientado a objetos Ode suporta o paradigma de objetos de C++. A interface com o usurio a linguagem O++, que estende C++ fornecendo facilidades para a criao de objetos persistentes. 6.3.1. Restries e Gatilhos Ode fornece dois tipos de facilidades de regras: restries para a manuteno da integridade do banco de dados, e gatilhos para a execuo automtica de aes dependendo do estado do banco de dados. As restries so usadas para manter a noo de consistncia, o que geralmente expresso com o sistema de tipos. Estas restries, que so condies booleanas, so associadas s definies das classes, como mostrado no exemplo seguinte. As restries podem ser herdadas como qualquer outra propriedade dos objetos. Se uma restrio violada e no corrigida, a transao abortada. class exemplo{ ... public: ... [soft] constraints: condio : ao } O teste da condio pode ser feito logo depois de acessar o objeto (conhecido como hard), ou diferido (chamado soft). Este ltimo tipo permite violaes temporais de restries que so corrigidas com aes antes que o commit da transao seja executado. Os gatilhos, como as restries, monitoram o banco de dados verificando algumas condies, exceto que estas ultimas no representam violaes de consistncia. Um

gatilho especificado na definio da classe e consiste de duas partes: o predicado do evento e a ao. Os gatilhos s podem ser aplicveis queles objetos especificados. trigger: [perpetual] nome-do-trigger (params) : [within expresso ?] condio => ao [: ao-do-timeout] Os gatilhos podem ser once-only (desativados logo aps a primeira execuo, usados por default) ou perpetual (reativados automaticamente depois de cada execuo). Gatilhos podem ter parmetros, e podem tambm ser ativados vrias vezes com distintos valores como parmetros. A ao associada a um gatilho executada quando a condio (e expresso) verdadeira, sempre e quando o gatilho esteja ativado. Aps o time-out especificado, a ao-do-time-out executada. 6.3.2. Modelo de Execuo Os gatilhos so associados a objetos, e so ativados explicitamente depois que o objeto foi criado. A ao executada numa sub-transao separada, dependendo do commit da transao original. A palavra chave independent faz com que a execuo da sub-transao seja executada de forma independente. Outros modos de acoplamento podem ser imediato, ou no fim da transao. 6.4. POSTGRES [SJGP90] uma extenso de um sistema de gerenciamento de bancos de dados relacional que inclui um sistema de gatilhos de propsito geral. O sistema de gatilhos pretende ser usado como uma linguagem para implementao de vises, vises materializadas, vises parciais, e procedimentos. O projeto fundamental do sistema de regras do Postgres descrito em [SR86, SHH88, SJGP90, SHP89]. 6.4.1. Regras A primeira verso do Postgres usa um paradigma de ativao de regras, onde cada comando Postquel pode ter associado os modificadores: always, refuse ou one-time. A segunda verso do sistema de regras usa um enfoque de sistemas de produo mais tradicional. define rule nome-da-regra [ as exception to nome-da-regra ] on evento to objeto [[ from clausula ] where clausula ] then do [ instead ] ao O evento um dos seguintes: retrieve, replace, delete, append, new e old. New usado com replace ou append, e old quando usa-se delete ou replace. A clausula where igual s condies das consultas padro dos sistemas de banco de dados (frmulas em lgica de Horn). A ao uma coleo de comandos Postquel mais as variveis predefinidas new e current. Estas variveis contm os valores do objeto a modificar.

6.4.2. Modelo de Execuo O modelo de execuo do sistema de regras de Postgres definido a nvel de tupla. Quando uma tupla acessada, atualizada, inserida ou eliminada, existe uma tupla atual (current) (para os casos de retrieve, replace e delete), e uma tupla nova (new) (no caso de replace e append). Se o evento e a condio especificada so verdadeiras para a tupla atual, ento a ao executada. A granularidade da aplicao a nvel de operao (A4) e a granularidade a nvel de regra completa (T1). O cascateamento de regras no descrito. 6.4.3. Otimizao So usadas duas diferentes estratgias de implementao para a otimizao da execuo das regras: execuo a nvel de tupla e re-escrita da consulta. A implementao a nvel de tupla mantm trancas de eventos (event locks) nas tuplas. Estas trancas so colocadas em campos apropriados em todas as tuplas envolvidas na condio e segundo a especificao do evento da regra. Quando um evento acontece num campo marcado com um "event lock", a condio testada. Se for verdadeira, a ao executada. No processamento da consulta, pode-se saber logo quais so as regras a serem executadas. A re-escrita feita entre as etapas de parsing e otimizao. A componente que reescreve a consulta compila os comandos junto com as regras que esto ligadas aos comandos, evitando assim buscas dinmicas de regras. Dependendo da regra, uma das implementaes de otimizao escolhida; ver [SJGP90] para maiores detalhes. 6.5. SAMOS [GD92] Fornece as mesmas propriedades que todos os gerenciadores de banco de dados orientados a objetos (SGBDOO) como herana, tipos e operaes definveis pelo usurio, encapsulamento, dentre outros. O prottipo foi implementado baseado no SGBDOO comercial ObjectStore. Samos fornece, como Snoop [CM91] e ODE [GJ92], uma linguagem de eventos que inclui vrios construtores para a especificao de eventos. Os eventos podem ser divididos em duas categorias: eventos primitivos (eventos de mtodos, de valor, temporais ou abstratos) ou compostos (usando disjuno, conjuno, seqncia, vezes ou negao). 6.5.1. Regras As regras so representadas como objetos, o que d uma flexibilidade maior, podendo ser classificadas segundo seu relacionamento com as classes (ou objetos). Existem dois tipos de relaes entre as regras e as classes. Regras internas classe, que permitem operar ou acessar os valores dos objetos, ou externas. As internas formam parte da definio da classe, e esto encapsuladas dentro das instncias. Condies e aes das regras internas podem operar diretamente com os valores. As regras externas classe podem ser definidas por qualquer usurio ou aplicao independente da definio da

classe. Na definio da classe especifica-se quando precisa ser avaliada a condio, ou quando a ao deve ser executada (modo de acoplamento) imediato (logo aps o evento), diferido (antes do commit), ou independente (numa transao independente). 6.5.2. Modelo de Execuo A avaliao da condio e a execuo da ao so implementadas como subtransaes. A ordem de execuo das regras disparadas ao mesmo tempo usa um mecanismo de prioridades. O projeto Samos estende a arquitetura de um sistema de banco de dados (passivo) orientado a objetos (ObjectStore) com novas componentes, a saber: analisador, gerenciador de regras e eventos, detector de eventos, e executor das aes. O analisador responsvel pela passagem das regras e eventos ao gerenciador correspondente (estes manipulam a base de regras e a histria dos eventos, respectivamente). O detector de eventos precisa manter a estrutura de dados necessria para a deteco dos eventos. Logo aps o evento ser detectado, inserido no registro de eventos. Baseado nesse registro, o gerenciador de regras determina quais regras precisam ser executadas, e o executor encarregado de avaliar as condies e executar a aes. 6.5.3. Otimizao A implementao de Samos esta construda sobre ObjectStore como uma caixa preta, havendo portanto uma perda de desempenho. obvio que a implementao de um detector de eventos eficiente crucial para ter uma boa performance num sistema de bancos de dados ativos. As Redes de Petri foram usadas para modelagem e deteco de eventos. Para cada construtor h um padro de Rede de Petri. O sistema trabalha com uma combinao de redes de Petri que inclui todas as redes de todos os eventos compostos. Um evento pode participar em mais de uma composio, enquanto na combinao das Redes s existe um estado para cada evento. A vantagem do uso destas regras que os eventos compostos podem ser detectados passo a passo, dada a ocorrncia de um evento primitivo, e no preciso inspecionar um grande nmero de eventos primrios armazenados no registro de eventos [GD94]. 6.6. STARBURST [WF90] O Starburst um sistema de gerenciamento de banco de dados relacional estendido. H duas formas de extenso, conhecidos como mtodos de armazenamento e attachments. Os mtodos de armazenamento provem mtodos alternativos para implementao de tabelas. Os attachments provem caminhos de acesso, restries de integridade e extenses de gatilhos. 6.6.1. Regras A sintaxe da linguagem para expressar regras em Starburst descrita a seguir:

create rule nome on tabela when operaes [if condio] then ao [precedes lista-de-regras] [follows lista-de-regras] As operaes so uma ou mais dentre inserted, deleted, ou updated(c1,...,cn), onde c1,...,cn so atributos de relaes. A condio um predicado SQL sobre o banco de dados. A ao uma seqncia de operaes do banco de dados, incluindo comandos de manipulao SQL, comandos de definio, e o comando rollback. Os comandos podem ser tambm alter, drop, deactivate, e activate sobre as regras. As sees precedes e follows so usadas para ordenar parcialmente o conjunto de regras [Wid92]. 6.6.2. Mecanismo de Execuo As regras so processadas logo aps a finalizao das transaes, sendo tambm possvel adicionar outros pontos de processamento dentro das transaes. A semntica est baseada em transies, que so mudanas de estado do banco de dados que resultam da execuo de comandos SQL. A execuo da transao a primeira transio relevante, e algumas regras podem ser disparadas por essa transao. Quando as aes de uma regra so executadas, outras transies so criadas. Estas podem disparar regras adicionais, ou as mesmas regras vrias vezes. O processamento das regras um algoritmo interativo com as seguintes passos: 1. Uma regra R que foi disparada selecionada para examinar a sua prioridade com respeito a outras regras nas mesmas condies. 2. A condio da regra R avaliada. 3. Se a condio de R verdadeira, a ao correspondente executada. O processamento termina quando a operao rollback executada, ou quando no h mais regras para disparar. As condies e aes fazem referncia ao estado atual do banco de dados, atravs de operaes de seleo de SQL. Alm disso, as condies e aes das regras fazem referncia a tabelas de transio, que so tabelas lgicas que refletem as mudanas que aconteceram durante a transio do disparo das regras. O sistema de regras inclui mecanismos de controle de concorrncia que asseguram a consistncia com respeito aos dados e regras, e na ordenao das regras. Tambm inclui mecanismos para a recuperao ante rollbacks das estruturas de dados do prprio sistema de regras. 6.7. SENTINEL [CAM93] Este projeto integra as regras de tipo ECA, introduzidas em HiPAC [CBB+89], a um sistema de banco de dados orientado a objeto, estendendo tambm a linguagem de especificao de eventos. Os objetivos so: usar o sistema resultante para monitoramento

do prprio banco de dados, fornecer suporte cooperativo na resoluo de problemas, e suportar SGBDs ativos multimdia para aplicaes cientficas [CHS92]. 6.7.1. Regras Os objetos C++ convencionais foram estendidos com uma interface de eventos. Com isto, possvel gerar eventos quando os mtodos so invocados, e propaga-los a outros objetos. Os eventos podem ser gerados antes ou depois da execuo do mtodo. As classes reativas so aquelas que, alm da definio tradicional, tm a especificao da interface de eventos. Os eventos so definidos pelo usurio na prpria definio da classe. A especificao de eventos est baseada na linguagem Snoop [CM91]. Esta linguagem prope uma hierarquia de eventos constituda por eventos primrios (primitivos) e compostos. So definidos operadores para eventos, como seqncia, disjuno, etc. A noo de parmetros usada para computar os parmetros dos eventos complexos. A especificao de eventos e regras pode ser feita em qualquer uma das classes. So suportados os modos de acoplamento imediato ou diferido. As regras, que so do tipo ECA, so criadas, modificadas e eliminadas da mesma forma que os outros objetos, tendo assim um tratamento uniforme. As regras so tambm entidades separadas que existem independentemente de outros objetos no sistema. Cada regra tem: uma identificao (para poder associa-la a outros objetos), uma associao a um objeto de tipo evento, e dois mtodos pblicos: condio e ao. As regras so ser associadas a outros objetos utilizando o mecanismo de subscrio [CAM93], que descrito a seguir. 6.7.2. Modelo de Execuo O sistema Sentinel desenvolvido usando o gerenciador de banco de dados orientado a objetos Zeitgest. Para incorporar as regras no sistema foram includas as classes: Reativa, Notificvel, Evento, Regra. A hierarquia tem a classe persistente zg-pos (predefinida no sistema), como super classe de Reativa e Notificvel, e as classes Evento e Regra so subclasses desta ltima. Assim, Eventos e Regras podem receber eventos propagados pelos objetos reativos. Para associar Regras a objetos introduzido o mecanismo de subscrio. Isto permite aos objetos notificveis (neste caso as Regras) subscrever dinamicamente aos eventos gerados por objetos reativos. 6.7.3. Otimizao O esquema da subscrio tem a vantagem que uma mesma regra pode ser aplicada a objetos de tipos diferentes, o que mais eficiente que definir a mesma regra mltiplas vezes para cada tipo de objeto. Outra vantagem deste esquema que as regras que esto subscritas a um objeto reativo s so testadas quando este objeto gera eventos. Isto tem um ganho em desempenho em relao ao esquema centralizado, onde todas as regras definidas no sistema so testadas quando um evento gerado.

7. CONCLUSES
Foram discutidas as principais caractersticas dos bancos de dados ativos utilizando como marco para sua descrio as seguintes categorias: definio das regras, o modelo de execuo e a otimizao da execuo. Tambm foram descritos, utilizando este marco, os principais prottipos que foram desenvolvidos na rea. Na tabela 1 so resumidas caractersticas destes prottipos.

8. REFERNCIAS
[ABD+92] Atkinson, Bancilhon, DeWitt, Dittrich, Maier and Zdonik: The ObjectOriented Database System Manifesto. Building an Object-Oriented Database System, F. Bancilhon, C. Delobel and P. Kandellakis (editors), Morgan Kaufmann, 1992. Berndtsson, M.: Reactive Object-Oriented Databases and CIM. In Proceedings of the 5th International Conference on Database and Expert Systems Applications (DEXA '94), pages 769-728, Athens, Greece, September 1994. Berndtsson, M; Lings, B.: On Developing Reactive Object-Oriented Databases. IEEE Bulletin of the Technical Committee on Data Engineering, Vol. 15, No. 1-4, pages 31-34, December 1992. Buchmann, A.: Active Databases. Tutorial. IX School of Computing, Recife, Brazil, July 1994. Chakravarthy, S.; Anwar, E. and Maugis, L.: Design and Implementation of Active Capability for an Object-Oriented Database. Technical Report UF-CIS TR-93-1, CIS Department, University of Florida, September 1993. Chakravarthy, S.; Blaustein, B.; Buchman, A.: Carey, M.; et. al.: HiPAC: A Research Project in Active, Time-Constrained Database Management. Final Technical Report XAIT-89-02 (187), July 1989. Carey, M.J.; Frank, D; Muralkrisna, M., DeWitt, D.J.; Graefe, G.; Richardson, J.E.; Shekita, E.J.: The Architecture of the EXODUS Extensible DBMS. Readings in Database Systems, M. Stonebraker (editor), pages 488-502, Morgarn-Kaufmann Publishers, San Mateo, California, 1988.

[Ber94]

[BL92]

[Buch94] [CAM93]

[CBB+89]

[CFM+86]

Ariel
Modelo Relacional estendido (Exodus)

HiPAC
Orientado a Objeto

Ode
O++ (C++ persist.)

Postgres
Relacional estendido

Samos
Orientado a Objeto (ObjectStore)

Starburst
Relacional estendido

Sentinel
Orientado a Objeto (Zeitgest)

Especificao das Regras E-C-A

Condio Subconj. de Postquel append/ delete/ replace/ temporais Subconj. de Postquel Subconj. das consultas BD / relgio / notifica es externas DML/ Procedim. Externos Expresso C++ update Postquel Linguage m de consulta BD / temporais/ mtodos / abstratos/ transaes DML SQL C++ / Zeitgest BD / transaes / temporais / mtodos C++ / Zeitgest

Evento

retrieve/ replace/ delete/ append/ new / old Postquel

insert / update / delete

Ao

O++

DML

Regras
Herana No Sim No Sim No Sim

Eventos
Mecanismo de Deteco baseado em TREAT [HC+90] No signal graphs autmato de estado finitos Sim ndices Redes de Petri ndices (Rule catalogs) No Subscri o(Detec o local regra) Sim

Composio

Sim

No

Sim

Condio
Otimizao Re-escrita da consulta Avaliao increment al / Subexpresses comuns / Rete [For82] duas avaliaes re-escrita consulta / a nvel de tupla Depende de ObjectStore Depende de Zeitgest

Modelo de Execuo
Resoluo de conflitos Modos Acoplament o prioridade concorrn cia Imediato/ Diferido/ Separado (dependen /indepen.) (concorr.) Imediato / Diferido Imediato Imediato / Diferidoindepend. Diferido prioridade prioridade concorrn cia Imediato / Diferido

Imediato

Tabela 1. Resumo das caractersticas dos principais prottipos.

[CHS92]

Chakravarthy, S.; Hanson, E.; Su, S.Y.W.: Active Database/Knowledge Base Research at the University of Florida. IEEE Bulletin of the Technical Committee on Data Engineering, Vol. 15, No. 1-4, pages 35-39, December 1992. Chakravarthy, S.; Mishra, D.: An Event Specification Language (Snoop) for Active Databases and its Detection. Technical Report UF-CIS TR-9123, CIS Department, University of Florida, September 1991. Chakravarthy, S. and Mishra, D.: Snoop: an Expressive Event Specification Language for Active Databases. Technical Report UF-CISTR-93-007, University of Florida, March 1993. Chakravarthy, S.; Nesson, S.: Making an Object-Oriented DBMS Active: Design, Implementation and Evaluation of a Prototype. In Proceedings of the International Conference on Extending Database Technology, Venice, March 1990. Ceri, S.; Widom, J.: Deriving Production Rules for Constraint Maintenance. In Proceedings of 16th International Conference on Very Large Data Bases (VLDB '90), pages 566-577, Brisbane, Australia, August 1990. Dayal, U.; Blaustein, B.; Buchmann, A.; Chakravarthy, S. et al.: The HiPAC Project: Combining Active Databases and Timing Constraints. ACM SIGMOD Record, Vol. 17, No. 1, pages 51-70, March 1988. Dayal, U.; Buchmann, A.; McCarthy, D.: Rules are objects too: a knowledge model for an active, object-oriented database system. In Proceedings of the 2nd International Workshop on Object-Oriented Database Systems, Lecture Notes in Computer Science 334, Springer 1988. Forgy, C.L.: Rete A Fast Algorithm for the many Pattern/many Object Pattern Match Problem. Artificial Intelligence, Vol. 19, pages 17-37, 1982. Gatziu, S; Dittrich, K.R.: SAMOS: an Active Object-Oriented Database System. IEEE Bulletin of the Technical Committee on Data Engineering, Vol. 15, No. 1-4, pages 23-26, December 1992. Gatziu, S. and Dittrich, K.: Events in an Active Object Oriented Database System. In Proceedings of the International Workshop on Rules in Database Systems, pages 23-29, August 1993.

[CM91]

[CM93]

[CN90]

[CW90]

[DBB+88]

[DBM88]

[For82] [GD92]

[GD93]

[GD94]

Gatziu, S. and Dittrich, K.: Detecting Composite Events in Active Database Systems Using Petri Nets. In Proceedings of the 4th International Workshop on Research Issues in Data Engineering: Active Database Systems (RIDE '94), Huston, Texas, February 1994. Gehani, N.; Jagadish, H.V.: Ode as an Active Database: Constraints and Triggers. in Proceedings of the 17th International Conference on Very Large Data Bases (VLDB '91), pages 327-336, 1991. Gehani, N.; Jagadish, H.V.: Active Database Facilities in Ode. IEEE Bulletin of the Technical Committee on Data Engineering, Vol. 15, No. 14, pages 19-22, December 1992. Gehani, N.; Jagadish, H. and Shmueli, O.: Compose: a System for Composite Event Specification and Detection. Technical report AT&T Bell Laboratories, December 1992. Gehani, N.; Jagadish, H. and Shmueli, O.: Event Specification in an active object oriented database. In Proceedings of the International Conference of Maganement of Data (SIGMOD '92), pages 81-90, 1992. Hanson, E.N.: An Initial Report on the Design of Ariel: A DBMS With an Integrated Production Rule System. ACM SIGMOD Record, Vol. 18, No. 3, pages 12-19, September 1989. Hanson, E.; Chaabouni, M.; Kim, C. and Wang,Y.: A Predicate Matching Algorithm for Database Rule Systems. In Proceedings of the International Conference on Management of Data (SIGMOD '90), May 1990. Hsu, M; Ladin, R.; McCarthy, D.R.: An Execution Model for Active Data Base Management Systems. In Proceedings of the 3rd International Conference on Data and Knowledge Bases, Jerusalem, June 1988. Ling, T.W.; Teo, P.K.: On Rules and Integrity Constraints in Database Systems. Information and Software Technology, Vol. 34, No. 3, March 1992. Medeiros, C.B.; Andrade, M. J.: Implementing Integrity Control in Active Databases. Relatrio Tcnico DCC, UNICAMP, July 1992. Morgestein, M.: Constraint Equations: Declarative Expression of Constraints with Automatics Enforcement. In Proceedings of the Tenth International Conference on Very Large Data Base (VLDB '84), pages 291-300, Singapore, August 1984.

[GJ91]

[GJ92]

[GJS92a]

[GJS92b]

[Han89]

[HC+90]

[HLM88]

[LT92]

[MA92] [Mor84]

[SHH88]

Stonebraker, M.; Hanson, E.; Hong, C.H.: The Design of the Postgres Rule System. Readings in Database Systems, M. Stonebraker (ed.), Morgan-Kaufmann, 1988. Stonebraker, M.; Hearst, M.; Potamianos, S.: A Commentary on the Postgres Rule Manager. SIGMOD Record, Vol. 18, No. 3, September 1989. Stonebraker, M.; Jhingran, A.; Goh, J.; Potamianos, S.: On Rules, Procedures, Caching and Views in Data Base Systems. In Proceedings of the International Conference on Management of Data (SIGMOD '90), pages 281-290, Atlantic City, May 1990. Stonebraker, M.; Rowe, L.: The Design of POSTGRES. In Proceedings of the International Conference on Management of Data (SIGMOD '86), Washington, D.C., June 1986. Sellis, T.; Raschid, L.: Implementing Large Production Rules System in a DBMS Enviroment: Concepts and Algorithms. In Proceedings of the International Conference on Management of Data (SIGMOD '88), pages 281-290, Chicago, June 88. Ullman, J.D.: Principles of Database Systems. Computer Science Press, 1982. Van der Voort, M.H.; Kersten, M.L.: Facets of Database Triggers. Internal Report of CWI, 1009 AB Amsterdam, Netherlands, April 1993. Widom, J. and Finkelstein, S.: Set Oriented Production Rules in Relational Database Systems. In Proceedings of the International Conference on Management of Data (SIGMOD '90), pages 259-270, May 1990. Widom, J.: The Starburst Rule System: Language Design, Implementation, and Applications. IEEE Bulletin of the Technical Committee on Data Engineering, Vol. 15, No. 1-4, pages 15-18, December 1992. Widom, J.: Deductive and Active Databases: Two Paradigns or Ends of a Spectrum?. IBM Alamden Research Report, RJ9268 (81832), March 1993.

[SHP89]

[SJGP90]

[SR86]

[SR88]

[Ull82] [VK93] [WF90]

[Wid92]

[Wid93]