Fluxo de Dados em Comandos de Manipulação

Na análise de fluxo de dados para variáveis persistentes, é mandatório basear-se em alguma granularidade para a determinação dos dados definidos e usados em conseqüência de execuções dos comandos de manipulação. A Tabela 4.1 apresenta uma análise das ocorrências de definição e de uso para tais comandos, com inspiração nas proposições de Leitão et al. (2002). A primeira coluna indica o comando de manipulação; as colunas segunda e terceira determinam, de acordo com a granularidade, os dados definidos no nó de ocorrência do comando e os dados usados nos arcos de saída do nó de ocorrência do comando, respectivamente. O termo relação

consultada denota uma relação usada como fonte de dados em uma operação de consulta; o termo relação definida refere-se à relação que possivelmente será atualizada por uma operação de

mudança de estado. São referenciados conjuntos de dados, seguindo a nomenclatura Bg, onde: B

assume a notação D e U para os conjuntos de dados definidos e usados, respectivamente; e g assume a notação b, r, a, t e va para as granularidades banco de dados, relação, atributo, tupla e

valor de atributo, respectivamente.

O conteúdo da Tabela 4.1 possui diferenças em comparação a trabalhos anteriores. Spoto (2000) considera suas análises em nível relação e determina que todos comandos de mudança de estado – insert, delete e update – possuem definição e usos persistentes, de forma independente do predicado de seleção de tuplas; também inclui o comando create view, o qual não constitui um comando de manipulação, como ocorrência de definição persistente. No modelo de fluxo de dados persistentes de Kapfhammer e Soffa (2003), os tipos de ocorrências de variáveis persistentes nos comandos delete e update são dependentes da granularidade de fluxo de dados;

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

por exemplo, se a cláusula where att_1 > 200 for utilizada em um comando update, definição e uso persistentes ocorrem na granularidade atributo, mas na granularidade relação existe somente definição persistente.

Tabela 4.1: Análise das ocorrências de definição e de uso para os comandos SQL de manipulação.

Comando Definição Persistente Uso Persistente

Select (Ub) Bases de dados que possuem as relações

consultadas

(Ur) Relações consultadas

(Ut) Tuplas manipuladas nas relações consultadas

(Ua) Atributos das relações consultadas referenciados, implicitamente ou explicitamente, no comando de manipulação

(Uva) Dados dos atributos em Ua pertencentes às tuplas em Ut

Insert (Db) Base de dados que possui a relação definida

(Dr) Relação definida

(Dt) Tuplas inseridas na relação definida

(Da) Atributos da relação definida

(Dva) Dados dos atributos em Da pertencentes às tuplas em Dt

Update (Db) Base de dados que possui a relação definida

(Dr) Relação definida

(Dt) Tuplas modificadas na relação definida

(Da) Atributos da relação definida que são referenciados no lado esquerdo de uma atribuição na lista de atribuições de valores a atributos

(Dva) Dados dos atributos em Da pertencentes às tuplas em Dt

(Ub) Base de dados que possui a relação definida

(Ur) Relação definida

(Ut) Tuplas modificadas na relação definida

(Ua) Atributos da relação definida que são referenciados, implicitamente ou explicitamente, no comando de manipulação

(Uva) Dados dos atributos em Ua pertencentes às tuplas em Ut

Delete (Db) Base de dados que possui a relação definida

(Dr) Relação definida

(Dt) Tuplas excluídas da relação definida

(Da) Atributos da relação definida

(Dva) Dados dos atributos em Da pertencentes às tuplas em Dt

(Ub) Base de dados que possui a relação definida

(Ur) Relação definida

(Ut) Tuplas excluídas da relação definida

(Ua) Atributos da relação definida que são referenciados, implicitamente ou explicitamente, no comando de manipulação

(Uva) Dados dos atributos em Ua pertencentes às tuplas em Ut

Sobre a cobertura de associações persistentes em uma dada granularidade, considere a Figura 4.1, que ilustra um hipotético fluxo de controle para um fragmento de código em SQL

para manipular a relação empl do banco de dados company, a qual é descrita pelo esquema empl

(id, name, salary, bonus). Neste exemplo, são abstraídas as associações persistentes α1, α2 e α3,

especificadas, respectivamente, como [k, (m, n), empl], [k, (n, succ(n)), empl] e [m, (n, succ(n)),

empl], onde succ(n) representa um nó sucessor do nó n. Pode-se afirmar: as associações α1 e α2

somente poderão ser cobertas nas precisões tupla e valor de atributo se, quando o controle alcançar o nó k, existirem tuplas na relação empl que atendam aos requisitos dessas granularidades; contudo, não existem bases de dados de entrada que ocasionem a cobertura da associação α3 em tais granularidades.

k

m

n

(k) update empl

set salary = salary * 1.1 where salary < 1000

(m) update empl

set bonus = salary * 1.1 where salary >= 1000

(n) select * from empl

where salary < 1000

Figura 4.1: Exemplo de fluxo de controle de um fragmento de código com comandos SQL.

Para complementar a análise de fluxo de dados persistentes, vale considerar um tipo especial de uso persistente, denominado de uso persistente implícito ou simplesmente uso

implícito. Esta categoria de uso existe na execução de qualquer operação de mudança de estado,

pois em geral o sistema gerenciador de banco de dados realiza uma verificação para determinar se restrições de entidade podem estar sendo violadas; por exemplo, se foi realizada uma tentativa para a inserção de valores duplicados da chave primária. Nesse sentido, todo o conteúdo da relação é usado, visto que restrições são verificadas para o conjunto de entidades da relação. Como conseqüência, associações de fluxo de dados podem ser abstraídas para esta classe de uso: se uma operação mudança de estado efetua uso implícito do conjunto de dados de uma relação, então este uso pode ser afetado por qualquer definição anterior desta relação; tais associações são mencionadas como associações persistentes implícitas, associações implícitas ou dduas

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

implícitas. Duas ocorrências de operação de mudança de estado, não necessariamente distintas,

podem estabelecer uma relação persistente implícita, caracterizando uma associação de fluxo de dados devido ao uso implícito de dados persistentes.

Usos implícitos não estão no foco desta pesquisa, não sendo, portanto, considerados na abstração de associações persistentes introduzidas na Seção 4.4. A despeito disso, abaixo é apresentada uma estratégia para a aplicação de associações implícitas, ressaltando suas limitações:

a cobertura de associações implícitas é alcançada nos níveis de granularidade banco de dados e relação, podendo-se determinar estaticamente os caminhos para cobrir as associações; a cobertura em níveis de granularidade mais precisos é indiferente, pois se todas as tuplas são usadas, então qualquer tupla definida anteriormente será suficiente para o exercício da associação;

se a aplicação do caso de teste λ exercita os caminhos determinados estaticamente para cobrir a associação α, e a execução da operação do nó de definição não afeta qualquer

tupla (ou seja, nenhuma tupla é definida), α será coberta por λ, pois é considerado que as

tuplas sendo implicitamente usadas são as mesmas que persistiram após a execução da

operação de mudança de estado.