Definições para Regras Ativas Escritas em SQL

Esta seção trata aspectos pertinentes a regras ativas escritas em SQL, para os quais não se encontrou definição explícita na literatura. São explorados os conceitos: evento, interface, estado de iniciação, caso de teste, seqüência e conjunto de casos de teste. As definições são realizadas no contexto de sistemas de banco de dados relacional, e delineiam o modelo de regras ativas para o padrão SQL3.

Definição: Evento de Regra Ativa

O evento (ou evento de disparo) de uma regra ativa r é descrito pela quádrupla E(r) = 〈 T, { ϕ1, ϕ2, ..., ϕn }, GT, TD 〉, onde: T é a identificação do esquema atribuído à relação t cuja

tipos de operação de mudança de estado, também denominada operação de disparo, onde a execução de uma operação de quaisquer desses tipos, aplicada à relação t, pode provocar o disparo de r; GT representa a propriedade granularidade de transição, que indica se a regra será disparada para cada tupla afetada por sua operação de disparo (row-level

trigger), ou se a regra será disparada uma única vez para o conjunto de dados afetados

pela operação de disparo (statement-level trigger); e TD representa a propriedade tempo

de disparo, que indica se a regra será disparada antes ou após a execução da operação de

disparo (before trigger e after trigger, respectivamente), ou se a regra será disparada em substituição à operação de disparo (instead of trigger).

Por exemplo, na declaração:

create trigger trigger_employee

before insert, update of salary, update of bonus on employee

for each row begin

... end;

o evento de disparo da regra trigger_employee, dado por E(trigger_employee) = 〈 employee, { insert, update of salary, update of bonus }, row-level trigger, before trigger 〉, é provocado quando qualquer operação do tipo insert, update of salary ou update of bonus for aplicada à relação employee; a propriedade granularidade de transição aponta que a regra será disparada para cada linha afetada pela operação de disparo; e a propriedade tempo de disparo indica que a regra será disparada antes que a mudança de estado, devido à execução da operação de disparo, seja aplicada à base de dados.

Definição: Interface de Regra Ativa

A interface de uma regra ativa r é representada pela descrição de evento e pela descrição de sua condição. De modo geral, é dada pela quíntupla I(r) = 〈 T, { ϕ1, ϕ2, ..., ϕn }, GT, TD, C 〉, onde C refere-se ao predicado associado à condição da regra; note que os quatro primeiros elementos da quíntupla descrevem o evento de regra: I(r) = 〈 E(r), C 〉. A

Interação entre Regras Baseada em Fluxo de Dados 77

inclusão da parte condição de regra na representação de interface ocorre para fins de teste em modo imediato para o acoplamento evento-condição. Estratégias de teste que buscam revelar defeitos na interface de regra devem requerer casos de teste que executem a ação de regra (a condição é avaliada como verdadeira) e que não executem a ação de regra (a condição é avaliada como falsa).

Definição: Variável de Regra Ativa

No contexto de regras ativas escritas em SQL, o termo variável de regra ativa refere-se aos seguintes tipos: (i) variáveis locais: são as variáveis explicitamente declaradas pela cláusula declare e possuem escopo limitado ao bloco b em que foram declaradas (e blocos internos a b); (ii) variáveis de sistema: são variáveis mantidas pelo sistema e disponíveis para uso pelos processos de bancos de dados; podem representar dados com escopo limitado ao processo em execução (por exemplo, estado de exceção da última manipulação de dados executada) ou denotar informação global a todos os processos (por exemplo, número de conexões correntes com o banco de dados); (iii) variáveis

persistentes (variáveis de banco de dados): são variáveis referentes a dados ou meta-

dados de um banco de dados; são ditas persistentes pois seus valores mantêm-se após o término do processo que as definiu; (iv) variáveis de transição: são variáveis relativas aos dados afetados pela operação que provocou o evento de disparo da regra, possuindo escopo limitado à regra; sua estrutura é do tipo tupla ou relação; no primeiro caso, a regra é disparada para cada linha afetada pela operação de disparo da regra; no segundo caso, o seu valor possui o conjunto de linhas afetadas pela operação de disparo da regra, quando a regra é disparada uma única vez independentemente da quantidade de linhas afetadas; e

(v) variáveis cursor: são variáveis associadas à facilidade de manipulação tupla-por-tupla

do conjunto resultante de uma consulta (operação de recuperação de dados persistentes); a exemplo das variáveis locais, variáveis do tipo cursor devem ser explicitamente declaradas pela cláusula declare.

A Seção 4.1 introduziu associações de fluxo de dados oriundas de variáveis persistentes referentes a dados (bases de dados). No contexto deste trabalho, a intenção é propor e avaliar a aplicação de técnicas de teste baseadas em tais associações para regras escritas em SQL;

especificamente, serão estudadas as interações baseadas em fluxo de dados entre regras ativas.

Variáveis locais e variáveis de transição possuem escopo local e são abordadas por Cardoso

(2004) em sua ferramenta para o teste de regras isoladas. Apesar de serem tipicamente locais às regras, variáveis cursor possuem manipulação persistente em tempo de iniciação do cursor; neste caso, a abertura do cursor representa um comando de manipulação do tipo select.

Definição: Estado de Iniciação de Regra Ativa

A execução de regras ativas é realizada pelo sistema gerenciador de bases de dados, de acordo com o seu mecanismo próprio de detecção de eventos ocorridos e de escalonamento de regras disparadas. Ao ser executada uma regra, é atribuído um estado inicial para a regra, denominado de estado de iniciação. Dentre os fatores associados ao estado de iniciação, são ressaltados: (i) os dados afetados pela operação que provocou o

disparo da regra, denominados de dados de transição; tais dados representam a mudança

de estado que provocou o disparo da regra e estão disponíveis localmente à regra em tempo de sua execução; podem ser explicitamente referenciados no código da condição e da ação da regra; por exemplo, na instrução IF (:new.salary > :old.salary), o predicado avalia se a operação de disparo elevou o valor do atributo salary; (ii) o tipo de operação

que provocou o evento de disparo da regra; este dado pode compor um predicado no

código da condição e da ação da regra; por exemplo, se { insert, update(salary) ,

update(bonus) } descreve os tipos de operação de disparo de uma regra, então a instrução IF UPDATING(SALARY) poderia ser usada para determinar precisamente o tipo de

operação que provocou o disparo da regra; e (iii) a base de dados no momento de

consideração do evento, da condição e da ação da regra; representa o contexto de

pertinência para cada componente de regra; por exemplo, a base de dados disponível durante a avaliação da condição da regra representa um estado anterior à operação que provocou o evento de disparo da regra (neste caso, a mudança de estado atribuída à operação de disparo ainda não foi aplicada à base de dados).

Os dados mencionados em (i) dependem do estado da base de dados no momento da operação de disparo, da semântica da operação de disparo e da propriedade granularidade de

Interação entre Regras Baseada em Fluxo de Dados 79

no componente (iii) dependem do estado da base de dados no momento de execução da operação de disparo, da semântica da operação de disparo e da propriedade tempo de disparo da regra.

Os espaços de entrada e de saída no teste de programas de aplicação de banco de dados incluem os estados da base de dados, em adição aos parâmetros de entrada e de saída da aplicação. Isto tem um substancial impacto na noção do que é um caso de teste, de como gerar casos de teste e de como verificar os resultados produzidos pela execução dos casos de teste (Chays et al., 2000).

Definição: Caso de Teste de Regra Ativa

Um caso de teste λ para uma regra ativa r é dado pela quádrupla 〈θ, ∆0, ∆1, M 〉, onde: θ é

a operação que provocou o evento de disparo de r; ∆0 é o estado da(s) base(s) de dado(s)

antes da execução de θ (e de r); ∆1 é o estado da(s) base(s) de dado(s) após a execução de r; e M é a seqüência 〈 m1, m2, ..., mk〉, k ≥ 0, de mensagens emitidas durante a execução de r. Assim, pode-se dizer que a entrada de um caso de teste é dada por 〈θ, ∆0〉 e a sua saída

é dada por 〈∆1, M 〉. Se a execução de r resultar no disparo de outras regras (ou da mesma

regra), então ∆1 e M referem-se ao obtido pela seqüência de regras executadas a partir de r.

Em regras cuja propriedade tempo de disparo indicar que a regra será disparada após a aplicação da operação de disparo à base de dados, é esperado que os estados anterior e posterior à aplicação de um caso de teste sejam distintos (∆0≠∆1), devido à natureza de mudança de estado

da operação de disparo. Em adição, a execução das operações de manipulação de dados persistentes, que estão presentes na ação da regra, podem também realizar mudança de estado na base de dados. Se ∆0 = ∆1, a execução da regra foi possivelmente abortada, cancelando as

operações de mudança de estado aplicadas à base de dados ocorridas na transação de execução da regra.

Definição: Seqüência de Casos de Teste

Uma seqüência de casos de teste para uma regra ativa r, denotada por <λ1, ..., λt>, é

é a seqüência de operações de disparo de r, tal que θk representa a operação de disparo de r em λk; ∆0 é o estado inicial da(s) base(s) de dados antes da aplicação da seqüência de

casos de teste; <∆1, ..., ∆t> é a seqüência de estados da(s) base(s) de dados, tal que ∆k

representa o estado da(s) base(s) de dados imediatamente após a aplicação de λk e ∆k-1

representa o estado da(s) base(s) de dados imediatamente antes da execução de λk; e <M1,..., Mt> é a seqüência de seqüências de mensagens emitidas, tal que Mk representa a

seqüência de mensagens em λk.

Definição: Conjunto de Casos de Teste

Um conjunto de casos de teste, denotado por { λ1, ..., λt }, denota a aplicação de casos de

teste de forma independente, onde o estado de entrada da(s) base(s) de dados para um caso de teste é independente do estado obtido pela aplicação de qualquer caso de teste anterior. A distinção entre seqüência e conjunto de casos de teste ressalta o papel da base de dados no teste de regras ativas. Se a base de dados resultante da aplicação de um caso de teste é utilizada no caso de teste seguinte, então a ordem de aplicação de casos de teste pode afetar os dados de saída.

As definições de conjunto e de seqüência de casos de teste são pertinentes ao teste de aplicações de bancos de dados. A persistência de dados possui duas implicações: a atividade de teste pode corromper a base de dados e, portanto, seqüências de casos de teste não são indicadas para a utilização de bases de produção; a restauração da base de dados de entrada após a aplicação de um caso de teste é requerida quando se aplica um conjunto de casos de teste. Chays et al. (2000) advogam a utilização de bases de dados sintéticos, com o intuito de preservar a consistência da base de dados e de selecionar dados de teste direcionados ao exercício de elementos requeridos.