Exemplo de Versionamento de Esquemas em TSQL

As possibilidades de evolução de um esquema conceitual e as conseqüentes alterações que devem ser efetuadas na extensão do banco de dados dependem do modelo de dados que estiver sendo utilizado. A linguagem de consulta TSQL2 [Snodgrass 95] apresenta suporte a versionamento de esquemas de tempo de transação, sendo os esquemas prévios armazenados sob forma de versões. Somente o esquema atual pode ser modificado (versionamento parcial).

No modelo de dados do TSQL2 os fatos são representados por tuplas compostas de um número arbitrário de atributos explícitos e de um atributo temporal implícito (tempo de transação e/ou tempo de validade). A introdução de versionamento de esquemas neste modelo afeta a composição e os métodos de recuperação e atualização dos atributos explícitos.

Seja R = (A1, … , An) um esquema relacional bitemporal. Se não

existisse versionamento de esquema, a tupla x teria a forma (a1,…, an|t).

Com a introdução do versionamento de esquema, o esquema relacional R é considerado completo – R contém a união de todos os atributos que foram definidos durante a existência da tabela. O domínio de cada atributo desta tabela é tal que contenha todos os dados armazenados para cada esquema. Uma função de visualização V(t1) mapeia Rt1 a um subconjunto

dos atributos no esquema St1, ativo no momento t1. A função V’(t2) mapeia

de St2 para R. Deste modo, os dados armazenados em t1 podem ser

mapeados para o formato especificado em t2 através de função V(V’(t1), t2).

O exemplo a seguir, apresentado em [Snodgrass 95], ilustra como é feita a evolução de esquemas neste modelo.

Consideremos a seguinte história estrutural da tabela Empregado: 01/01/93 – tabela Empregado:

Id NUM(6), Nome CHAR(30), Salario NUM(5,2)

01/02/93 – acréscimo dos seguintes atributos: Sexo CHAR(1),

Estadocivil CHAR(1)

01/03/93 – removido o atributo Estadocivil 01/04/93 – o atributo Salario é redefinido:

Salario NUM(5)

02/04/93 – o atributo é novamente redefinido como: Salario NUM(5,2)

Após feitas todas estas modificações, o esquema completo para esta tabela é o seguinte:

Name CHAR(30), Estadocivil CHAR(1), Salario NUM(5,2).

As funções V e V’ estão disponíveis em todos os pontos de tempo, para converter do esquema armazenado para o esquema completo R, e depois do esquema R para o esquema que deve ser considerado na consulta. 6.6 Exemplo de Evolução de Esquemas em um Modelo Temporal

Orientado a Objetos

Considerando um modelo temporal orientado a objetos, a história de um objeto pode ser representada pela seqüência de valores assumidos por seus atributos durante sua existência. Na extensão de um banco de dados temporal são armazenados: (1) valores de propriedades estáticas, que não apresentam rótulos temporais, uma vez que são sempre válidas, e (2) valores de propriedades dinâmicas, rotuladas com os tempos de transação e/ou de validade.

Neste exemplo consideramos que as versões do esquema são armazenadas em um meta-banco de dados de tempo de validade - uma nova versão do esquema será, portanto, produto de um conjunto de alterações e lementares na versão anterior do esquema. Ao ser alcançado o tempo de início de validade de uma nova versão do esquema, esta deve ser validada, sendo verificado se está de acordo com as invariantes do modelo. No caso da versão ser válida, a extensão do banco de dados deve ser adaptada a ela.

6.6.1 As Invariantes de um Modelo Temporal Orientado a Objetos Um modelo temporal orientado a objetos genérico apresenta, pelo menos, as seguintes invariantes:

• unicidade de nomes:

♦ as classes devem apresentar nomes únicos;

♦ em uma classe, nomes de propriedades e de mensagens (representando os métodos) devem ser únicos;

• para toda propriedade deve ser definido um domínio;

• todos os nomes de classes e propriedades utilizados em condições (pré e pós- condições e regras de integridade ) devem estar definidos;

• toda superclasse referenciada em uma subclasse deve estar definida;

• todas as classes componentes de uma classe agregada devem estar definidas.

6.6.2 A Evolução do Esquema

Existem modificações elementares que não podem ocorrer sozinhas - modificações complementares são necessárias para garantir a corretude do

esquema. Este é o motivo pelo qual foi escolhido um meta-banco de dados de validade para armazenar o esquema.

As modificações elementares que podem ser efetuadas no modelo aqui utilizado são as seguintes:

• criação de uma nova classe, destruição de uma classe existente, renomeação de uma classe;

• criação de uma nova propriedade, destruição de uma propriedade, renomeação de uma propriedade, modificação do domínio de uma propriedade, alteração do tipo (estático - dinâmico) de uma propriedade;

• alterações de interfaces de comunicação entre classes - criação de uma nova mensagem (método), remoção ou renomeação de uma mensagem existente, modificação nos parâmetros de uma mensagem.

Nas figuras 6.5 e 6.6 é apresentado um exemplo de evolução de um esquema (2 versões), utilizando um DDL genérica. Na primeira versão (figura 6.5) é definida apenas uma classe de empregados de uma empresa (Employee), que apresenta duas propriedades - uma propriedade considerada inicialmente como estática, o nome do empregado (name) e uma propriedade dinâmica para representar seu salário (salary). Na segunda versão deste esquema (figura 6.6) o tipo da propriedade que representa o nome foi trocado para dinâmica pois foi constatado que o nome de uma pessoa pode mudar (casamento, separação). Além disso, na segunda versão foi acrescentada outra classe para modelar os departamentos da empresa (Department), apresentando as propriedades dinâmicas nome do departamento (dept_name) e o gerente do departamento (dept_manager). O gerente do departamento é um empregado, sendo representado por uma instância desta classe. Na classe dos empregados foi, ainda, acrescentada um propriedade dinâmica para indicar qual o departamento em que este empregado está trabalhando (dept).

(Class Employee

static properties = {(name, string)} dynamic properties = {(salary, real)}

messages = { reg(Name: string, Salary: real) from Outer_World, new_sal (Salary: real) from Outer_World,

end_employment from Outer_World } )

Figura 6.6: Segunda versão do esquema

6.6.3 Adaptação da Extensão do Banco de Dados como Conseqüência da Evolução do Esquema

As seguintes adaptações são necessárias na extensão do banco de dados temporal que implementa um modelo orientado a objetos:

• criação de uma nova classe – não implica em adaptação da extensão;

• remoção de uma classe existente – terminar a validade de todas as propriedade s dos objetos desta classe e fechar o intervalo de existência dos objetos desta classe;

• renomeação de uma classe – como os objetos da extensão são identificados pelos seus identificadores próprios (oId), não será necessária nenhuma adaptação da extensão. Deverá, entretanto, existir uma forma de identificar os nomes das duas classes como correspondendo à mesma classe (por ex., um dicionário de sinônimos);

• definição de nova propriedade estática – a definição desta propriedade deve ser feita na extensão para todas as instâncias desta classe, com o valor inicial null;

• definição de nova propriedade dinâmica – não implica em adaptação, uma vez que valores para esta propriedade somente serão definidos a partir deste momento;

• remoção de uma propriedade estática – não implica em adaptação, uma vez que não será definido nenhum valor para esta propriedade segundo o novo esquema;

• remoção de uma propriedade dinâmica – terminar a validade dos valores definidos para esta propriedade;

(Class Employee

dynamic properties = { (name, string), (salary, real), (dept, DEPARTMENT)}

messages = { reg(Name: string, Salary: real, Dept: DEPARTMENT) from Outer_World,

new_sal(Salary: real) from Outer_World,

new_dept(Dept: DEPARTMENT) from Outer_World, end_employment from Outer_World } )

(Class Department

dynamic properties = {(dept_name, string), dept_manager, EMPLOYEE)}

messages = { dept_name(Name: string) from Outer_World, new_mgr(Mgr: EMPLOYEE) from Outer_World, dismiss_mgr from Outer_World } )

• renomeação de uma propriedade – neste caso também deverá ser introduzida a correspondência entre os dois nomes em um dicionário de sinônimos;

• alteração no tipo (domínio) de uma propriedade – adaptações devem ser feitas em todos os valores armazenados para esta propriedade, para adaptá-los ao novo domínio. Os valores válidos de propriedades dinâmicas devem ter sua validade encerrada quando terminar a validade do esquema anterior. Se o valor que a propriedade apresentar puder ser adaptado ao novo tipo (ex., inteiro para real), deverá ser feita esta adaptação e o valor adaptado tem seu início de validade coincidente com o início da validade do novo esquema. Se, no entanto, isto não for possível (ex., inteiro para string), um novo valor deverá ser definido pelo usuário, juntamente com o início de sua validade. A mesma adaptação de tipos de valores deve ser feita para as propriedades estáticas;

• modificação de propriedade estática para dinâmica – todas as instâncias da classe deverão receber a definição desta propriedade com o novo tipo, com o valor que a propriedade estática apresentava e com o tempo de validade igual ao do início da validade da nova versão do esquema;

• quando uma propriedade dinâmica tem seu tipo alterado para estático é necessária a definição da propriedade estática para todas as instâncias da classe, com o último valor válido da propriedade dinâmica;

• alterações em mensagens – não se refletem na extensão da base de dados.