Bancos de Dados Ativos

Conforme foi comentado no Capítulo 1, sistemas gerenciadores de bancos de dados ativos são hábeis para monitorar e para reagir a circunstâncias específicas de relevância para uma aplicação. O uso de bancos de dados ativos é comumente classificado em aplicações internas e

aplicações externas. Aplicações externas são responsáveis por tarefas de domínio específico

(Chandra e Segev, 1994; Dittrich e Jonscher, 1994; Knolmayer et al., 1994), tais como: administração financeira, controle de inventário, projeto e gerenciamento de distribuição de energia e administração de carga de trabalho. Em aplicações internas, regras ativas são usadas como se extensões da aplicação fizessem parte do sistema gerenciador de banco de dados. Algumas tarefas que podem ser delegadas a regras ativas são: manutenção de integridade (Ceri et al., 1994; Ceri e Widow, 1991), onde predicados de restrição de integridade representam transições não permissíveis entre estados da base de dados, tal que a ação da regra pode cancelar a transação da aplicação ou reparar a consistência da base de dados; manutenção de dados

derivados e de visões materializadas (Adelberg et al., 1996; Ceri e Widow, 1990; StoneBraker et

al., 1990), pela monitoração de eventos de atualizações na base de dados que resultem na ação de recomputar valores de dados derivados e de visões materializadas; suporte à integração de dados (Ceri e Widow, 1993; Madiraju e Sunderram, 2004), onde visões têm sido propostas como um

recurso de integração de dados de fontes múltiplas, distribuídas e heterogêneas, tal como o contexto de data warehousing (Hammer et al., 1995); gerenciamento de versão e replicação (Kotz-Dittrich e Simon, 1998), onde, usando o mesmo princípio para manter visões, uma modificação de esquema replica definições de uma versão anterior para uma nova versão, propagando alterações ocorridas entre versões; autorização de acesso a base de dados (Dittrich e Jonscher, 1994; Jonscher, 1992), para prevenir acessos não autorizados a entidades da base de dados e para gravar logs de tentativas de violação de segurança.

Embora o benefício de bancos de dados ativos seja reconhecido desde algum tempo atrás, o campo de pesquisa é relativamente recente (Dayal, 1988). Alguns sistemas gerenciadores de bancos de dados comerciais incorporam a facilidade de conduta reativa a eventos ocorridos (DB2, 2005; Informix, 2005; Oracle, 2005; SQL Server, 2005); padrões de programação incluem extensões a SQL voltadas ao uso de regras ativas (Bowman et al., 1997; Date e Darwen; 1997; Fortier, 1999; Kulkarni et al., 1998; Melton e Simon, 1993); regras ativas têm motivado a comunidade acadêmica à construção de protótipos de pesquisa (Ceri et al., 1996; Hanson, 1996; Stonebraker e Kemnitz, 1991; Widow, 1996).

Um sistema de banco de dados ativo é descrito por um modelo de conhecimento e por um

modelo de execução (Paton e Díaz, 1999; Widom e Ceri, 1996). O primeiro modelo descreve a

funcionalidade ativa, apresentando um conjunto de propriedades ligadas aos componentes de uma regra ativa; o segundo descreve o comportamento de um conjunto de regras em tempo de execução. Cada sistema de banco de dados ativo, protótipo ou produto, adota um subconjunto dos modelos de descrição (Chakravarthy, 1993). Algumas das propriedades de ambos os modelos são descritas abaixo; em seguida é determinado o suporte existente no padrão SQL3 a regras ativas; por fim, um exemplo de uma regra ativa escrita em SQL é coletado da literatura.

O modelo do conhecimento define propriedades para o evento, a condição e a ação de regra ativa. Para o evento de regra, algumas das propriedades deste modelo são: fonte do evento, que determina a natureza e o caminho no qual o evento pode ser detectado (operações na estrutura da base de dados: inserir uma tupla; ocorrências de comandos de transação: rollback e

commit; exceções produzidas: tentativa de acesso sem autorização apropriada; e periodicamente

ou em algum ponto no tempo); tipo do evento (primitivo: provocado por uma ocorrência simples da fonte do evento; e composto: provocado por combinações de eventos primitivos); e

Revisão Bibliográfica 22

definidas as propriedades: obrigatoriedade da condição (nenhuma, opcional e mandatória); e

contexto da condição, que indica o estado da base de dados em que a condição é avaliada (início

da transação vigente, cenário em que ocorreu o evento; momento em que a condição é avaliada). A ação de regra possui as propriedades: opção da ação, que define a tarefa da regra (operações na estrutura da base de dados, tal como atualizar a estrutura do banco de dados; informar alguma situação de alerta; realizar um papel alternativo da ação – do instead; efetuar alguma chamada externa; cancelar uma transação); e contexto da ação, que indica o estado da base de dados disponível para a ação de regra.

Algumas das propriedades do modelo de execução são: acoplamento evento-condição, que determina quando a condição é avaliada em relação ao evento que disparou a regra (imediato: a condição é avaliada imediatamente após o evento; adiado: a condição é avaliada na mesma transação do evento; isolado: a condição é avaliada em uma transação distinta do evento);

acoplamento condição-ação, que indica quando a ação será executada em relação à avaliação da

condição (similar ao acoplamento evento-condição: imediato, adiado e isolado); granularidade

de transição, que sinaliza o relacionamento entre eventos e as regras disparadas (tupla: se uma

ocorrência de evento dispara uma regra; conjunto: se um conjunto de ocorrências de evento dispara uma regra); política de ciclo, que especifica a conduta quando eventos são provocados pela apreciação da condição ou pela execução da ação de regra (iterativa: não suspende a condição ou a ação da regra; recursiva: suspende a condição ou ação da regra e o controle é desviado para a regra disparada); e prioridade, que determina a próxima regra a ser disparada quando o evento de várias regras foi provocado (numérica: cada regra possui um valor de prioridade absoluto; relativo; explicita prioridades entre regras; dinâmica: baseado nas regras mais recentemente disparadas; nenhuma prioridade).

A noção de regras ativas é uma das principais extensões introduzidas no padrão SQL3. Uma regra ativa em SQL3, denominada trigger, é ativada por uma transição de estado na base de dados. A propriedade fonte do evento do modelo de conhecimento limita-se a operações na estrutura da base de dados, onde o evento consiste em mudanças de estado de uma relação particular, na forma de tipo de evento primitivo. A condição de regra pode ser constituída por qualquer predicado SQL arbitrário, incluindo subconsultas e funções definidas pelo usuário (Kulkarni et al., 1998). Baralis et al. (1998) apresentam o modelo evento-condição-ação em sintonia com a noção de triggers: o modelo ECA para regras ativas é uma tripla de componentes:

(i) o conjunto de eventos é o conjunto de operações de manipulação de dados sendo monitoradas; (ii) a condição é um predicado que referencia o estado corrente da base de dados e os valores de transição da regra; e (iii) a ação é uma seqüência de operações de manipulação de dados. Os valores de transição associados a uma dada execução de uma regra ativa são dados transientes

que estão sendo inseridos, modificados ou excluídos por uma operação monitorada pela regra. A Figura 2.1 apresenta a sintaxe SQL3 para a criação de uma trigger, conforme (Kulkarni et al., 1998).

Sobre a Figura 2.1, vale comentar algumas cláusulas e produções em relação às propriedades dos modelos de conhecimento e de execução. A produção <trigger action time> influencia as propriedades contexto da condição e contexto da ação, pois determina se a regra será disparada antes ou após a aplicação da operação de disparo na base de dados. A produção

<trigger event> define os tipos de operação de mudança de estado que provocam o disparo da

regra. A cláusula FOR EACH { ROW | STATEMENT } determina a propriedade granularidade de

transição. A produção <search condition> não inclui operações de mudança de estado,

diferentemente da produção <triggered SQL statement>; nesse sentido, o disparo entre triggers, não necessariamente distintas, pode ocorrer somente a partir da ação de regra, não podendo a consideração da condição de regra provocar eventos de disparo. O disparo entre regras em conjunto com a política de ciclo dificulta o entendimento da interação entre regras e a previsão do estado final após sua execução (Ramakrishnan, 1998). Segundo Kulkarni et al. (1998), SQL3 define como imediatos os acoplamentos evento-condição e condição-ação e a propriedade

política de ciclo é recursiva. Quando múltiplas regras são elegíveis para disparo, a ordem de

execução é baseada na ordem ascendente do tempo de criação de triggers.

Sob a ótica dos componentes de regra, a notação ri (ei, ci, ai) indica que a regra ri é

descrita pelo evento ei, pela condição ci e pela ação ai. No contexto de fluxo de controle,

similarmente a programas convencionais, uma regra ativa r é representada por um grafo dirigido, dado por G(r) = (N, A, e, x), onde: N representa o conjunto de nós da regra; A denota o conjunto de arcos; o nó de entrada (evento da regra) é identificado por e; e x representa o nó de saída; diz- se ainda que Na(r) é o conjunto de nós que representam a ação da regra r (Leitão et al.; 2002). A

Figura 2.2 mostra um exemplo de regra ativa escrita em SQL; no início de cada linha está a indicação do número de nó correspondente no grafo de fluxo de controle, o qual é ilustrado na Figura 2.3. A apresentação dessas figuras visa a ilustrar a representação de regras ativas escritas

Revisão Bibliográfica 24

em SQL por grafos de fluxo de controle; não se tem a intenção de especificar neste ponto como esta representação é alcançada (a Subseção 6.1 especifica o modelo de fluxo de controle para regras escritas em SQL). Sobre a Figura 2.3, os nós 1, 2 e 7 representam, respectivamente, o evento da regra , a condição da regra e o nó de saída do grafo; os nós 3 a 7 representam a ação da regras; e as linhas tracejadas representam transferências de controle para o nó de saída do grafo ocasionadas por exceção na execução de comandos de manipulação da SQL.

<trigger definition> ::=

CREATE TRIGGER <trigger name> <trigger action time>

<trigger event> ON <table name>

[ REFERENCING <old or new values alias list> ]

<trigger action>

<trigger action time> ::= BEFORE | AFTER

<trigger event> ::= INSERT | DELETE | UPDATE [ OF <column name list> ]

<old or new values alias list> ::= <old or new values alias> ……

<old or new values alias> ::= OLD [AS] <identifier> | NEW [AS] <identifier | OLD_TABLE [AS] <identifier> | NEW_TABLE [AS] <identifier>

<trigger action> ::=

[ FOR EACH { ROW | STATEMENT } ] [ <trigger condition> ]

<triggered SQL statement>

<trigger condition> ::=

WHEN <left paren> <search condition> <right paren>

<triggered SQL statement> ::= <SQL procedure statement> |

BEGIN ATOMIC

{ <SQL procedure statement> <semicolon> } …… END

*01* CREATE TRIGGER Reorder

*01* AFTER UPDATE OF PartOnHand ON Inventory *02* WHEN (:New.PartOnHand < :New.ReorderPoint) *01* FOR EACH ROW

*01* DECLARE NUMBER X; *01* BEGIN

*03* SELECT COUNT(*) INTO X *03* FROM PendingOrders *03* WHERE Part = :New.Part; *04* IF X = 0 THEN

*05* INSERT INTO PendingOrders

*05* VALUES (:New.Part, :New.OrderQuantity, SYSDATE); *06* END IF;

*07* END;

Figura 2.2 – Exemplo de regra ativa escrita em SQL (Zaniolo et al., 1997).

2 3 5 4 6 7 1

Figura 2.3 – Grafo de fluxo de controle obtido da regra da Figura 2.2.