Versões e Configurações em Sistemas de Banco de Dados Orientado a
Objetos: um Tratamento Uniforme
Daniela Tereza Ascencio Russi, Francisco Assis da Silva
Faculdade de Informática de Pres. Prudente - UNOESTE
Rua: José Bongiovani, 700, Cidade Universitária
CEP: 19050-900, Presidente Prudente-SP
E-mail: {daniela,chico}@apec.unoeste.br
Resumo
No contexto de Banco de Dados Orientado a Objetos, uma das características
desejáveis, requerida por domínios de aplicação é a possibilidade de armazenar vários
estados de objetos. Uma versão é a descrição de um objeto em determinado momento de
tempo ou sob um certo ponto de vista, considerado relevante para a aplicação definida. A
possibilidade de ter versões em níveis diferentes de abstração provêm de um rico modelo e
permite uma representação mais natural da realidade. Conjunto de versões associados
com cada nível de uma hierarquia de objeto representam muitas vezes um conjunto amplo
de possíveis configurações para o objeto, o qual é difícil ser manipulado diretamente pelo
usuário, mas representa implicitamente um conjunto de possíveis combinações para
definição final de um objeto. Cada composição de um objeto onde todos os componentes
possuem versões especificadas constitui a configuração do objeto.
Neste contexto, mecanismos adequados são muito importantes para definir e
construir configurações de objeto por meio de seleções aplicadas ao conjunto de todas as
possíveis configurações, definidas pelas combinações de versões.
1 - Introdução
No contexto de banco de dados orientado a objetos, uma das características
desejáveis, requerida por domínios de aplicação é a possibilidade de armazenar vários
estados de objetos. Uma versão representa um estado identificável de um objeto,
considerado pelo usuário como semanticamente significativo, devendo ser tratada como um
objeto no modelo de dados.
Aplicações não comerciais, também ditas não convencionais, tem motivado nos
últimos tempos os pesquisadores da área de Banco de Dados pelos novos requisitos
impostos de algumas áreas de aplicação, principalmente aplicações de engenharia (CADComputer Aided Design), Software de engenharia (CASE-Computer Aided Software
Engineering), Manufaturação (CAM-Computer Aided Manufacturing), Automatização de
Escritório, Hiperdocumentos e Bancos de Dados Históricos. Muitas das novas aplicações
impõem a necessidade de guardar mais de um estado da base de dados, afastando-se,
portanto, do modelo tradicional.
1
Em aplicações de engenharia os problemas relacionados para representação de
objeto são baseados em modelos de dados semânticos como do Modelo de Entidade
Relacionamento, que é o mais freqüentemente usado.
Com bancos de dados históricos, a ênfase é posta no armazenamento da
informação sobre entidades, organizadas com respeito ao tempo.
Presentemente existe uma tendência para estender banco de dados orientado a
objetos e sistemas com conceitos de versão e mecanismos, visando a definição de uma
estrutura que pode ser refinada para apoiar muitas classes de aplicação [Bjö 89, Agr 91,
Kim 89a, Lam 91, Sci 91, Sci 94]. Alguns trabalhos aproximam o uso de versões para
apoiar evolução de esquema de banco de dados [Bjö 89, Zdo 90, Mon 92, Bye 93, Tal 93].
Modelos de banco de dados orientado a objetos normalmente permitem somente a
maioria de classe/tipo especializado em uma hierarquia de herança [Kim 89a, Bee 88, Agr
91]. A possibilidade de ter versões a níveis diferentes de abstração provêm de um rico
modelo e permite uma representação mais natural da realidade. Por outro lado, quando
versões podem ser associadas a objetos de banco de dados, o usuário precisa escolher de
um amplo conjunto de opções, a específica combinação de versões que comporão o objeto
em cada situação. Cada combinação de versões de componentes específicos de um objeto é
chamado de uma configuração.
Configurações são muito importantes no contexto de bancos de dados orientado a
objetos que apoiam versões, desde que eles são, de fato, os objetos manipulados pelas
aplicações. Eles correspondem às instâncias de objetos em bancos de dados de versões
anteriores. Neste contexto, mecanismos adequados são muito importantes para definir e
construir configurações de objeto por meio de seleções aplicadas ao jogo de todas as
possíveis configurações definido pelas combinações de versões [Gol 95].
Este trabalho enfoca um gerenciamento de versão do nível de aplicação, apoia a
representação de seqüência - ou informação de tempo dependente, como definido pelos
usuários. O usuário deve ser permitido editar a seqüência (ou grafo) de versões, definindo
quando e onde uma versão deve ser incluída ou deve ser removida.
Versões e configurações são tratadas comumente como conceitos diferentes na
maioria dos modelos que apoiam gerenciamento de versão. Esta separação de conceitos tem
algumas desvantagens, tal como a impossibilidade de combinar versões e configurações
livremente para construir alto nível de versões. Este tipo de distinção é particularmente
inconveniente no caso de bancos de dados orientados a objetos, onde o tratamento uniforme
de tudo como objeto aumenta significativamente a possibilidade de combinação de objetos
para formar outros objetos de nível mais altos.
A abordagem proposta neste documento não faz distinção significativa entre
versões e configurações que podem ser combinadas livremente. Especial atenção é
dedicada a sistemas de banco de dados orientado a objetos. A necessidade para incorporar
novos conceitos para o modelo de dados é discutido. É dada ênfase ao versionamento de
objetos que participam em hierarquias de herança, como também relações entre objetos e
versões localizadas a níveis diferentes da hierarquia.
Um modelo de versão é proposto, no qual o versionamento de objetos a todos os
níveis de uma hierarquia de herança é permitido e não restringe o versionamento para o
2
nível de folha. É mostrado como estas extensões para o paradigma orientado a objeto
permitem modelar muitas situações do mundo real, especialmente quando os objetos são
construídos em um processo de cima para baixo (top-down).
As próximas seções são organizadas como segue: Seção 2 apresenta o principal
conceito relacionado para versões em bancos de dados orientado a objeto. Os aspectos
relacionados para objeto e hierarquia de versão é discutido na Seção 3. Os principais efeitos
de versionamento de objeto a diferente níveis são apresentados numa hierarquia de herança.
As vantagens desta aproximação no modelo de aplicações são comparadas à aproximação
tradicional onde se concentram versões às folhas da hierarquia. Configurações são
discutidas na Seção 4. Seção 5 apresenta as operações definidas para manipulação de
objetos e versões na hierarquia de herança e Seção 6 apresenta as facilidades requeridas
para especificação de configuração. São apresentas as conclusões principais deste trabalho
na Seção 7.
2 - Base Conceitual
2.1 - Versão e Conceitos de Objeto Versionado
Uma versão é a descrição de um objeto em determinado momento de tempo ou sob
um certo ponto de vista que é considerado relevante para uma aplicação definida. Num
sistema orientado a objetos, uma versão é um objeto de primeira classe, possui seu próprio
identificador de objeto (OID), o que permite que seja diretamente manipulada e consultada.
Um objeto que possua versões é dito um objeto versionado [Gol 93], que mantém
informações sobre suas versões associadas.
Cada versão pertence a exatamente um objeto versionado. Aplicações não podem
sempre determinar se um objeto apresentará versões ou não, objetos podem dinamicamente
mudar de não versionado para versionado.
A característica de ser versionado pertence a um objeto e não a uma classe, uma
classe pode ter objetos como instâncias versionados e não versionados.
A figura 1 mostra que um automóvel sendo projetado pode ser um objeto
versionado tendo várias versões associadas, a qual representa os diferentes estágios ao
longo do projeto.
fiat-uno
mille
elx
Automóvel
cs
new
Classe
Objeto Versionado
Versão
Figura 1 Objeto versionado e suas versões
3
Cada objeto versionado tem uma versão considerada como sua versão atual,
também chamada versão padrão. A versão atual é usada sempre que uma operação é
aplicada a um objeto versionado, sem especificar uma de suas versões.
2.2 - Propriedades de Versão
Versões de um objeto versionado estão relacionadas através de um relacionamento
de derivação. Versões devem ser organizadas em uma estrutura que reflita este
relacionamento entre elas. A estrutura pode ser uma das três seguintes: 1 – lista, onde cada
versão só tem uma versão antecessora e uma sucessora, 2 – árvore, onde várias versões
podem ser derivadas de uma mesma versão, mas cada versão só tem uma antecessora e 3 –
grafo acíclico dirigido, onde cada versão pode ter várias antecessoras e sucessoras.
No caso de uma lista uma nova versão é sempre criada como sucessora da última
versão, e representa a evolução de um objeto no tempo. O relacionamento estabelecido
entre as versões é um relacionamento de derivação. Quando a estrutura é uma árvore ou um
grafo, ela traz mais informações, além da relação de derivação entre versões e é utilizado
para aplicações de projeto, quando diferentes estratégias de projeto devem ser exploradas
em paralelo. Se mais de uma versão é derivada da mesma versão, elas usualmente são
chamadas de alternativas [Zdo 87, Kat 90, Fau 91] pois representam diferentes tentativas
de solucionar um problema. Versões que estão no mesmo caminho até a raiz da árvore ou
grafo são chamadas de derivativas (Figura 2). A estrutura dá-se o nome de histórico de
versões [Kat 90].
v1
v11
v111
v12
v112
Alternativas
Derivativas
Figura 2 Histórico de versões estruturado como árvore
Quando uma versão é criada como uma sucessora de uma outra, uma cópia é feita
de sua antecessora. Quando uma versão é criada como uma sucessora de mais de uma
versão, somente a primeira versão indicada é copiada, e um relacionamento é estabelecido
com os outros indicados. A idéia é que a nova versão deve ser a combinação de seus
antecessores, mas é a responsabilidade do usuário extrair a informação necessária das
várias versões [Gol 95]. Operações em versões são restringidas, conforme seus estados.
Uma versão trabalhando é essencialmente uma versão temporária que tem que sofrer
modificações para alcançar um estado mais estável. Uma versão estável tem alcançado
mais estabilidade e pode ser compartilhada. Versões estáveis não podem ser modificadas,
mas podem ser removidas. Uma versão consolidada é uma versão final que não pode ser
modificada nem pode ser removida.
4
Quando uma versão é derivada de uma outra, seus antecessores são
automaticamente promovidos para estável e evitam modificações em versões que eram
importante de um ponto de vista histórico.
2.3 - Referências Estáticas e Dinâmicas
Quando um objeto tendo versões é usado como componente de um outro,
referências podem ser feitas para isto em um de dois modos: referência para uma versão
específica, chamada referência estática – se comporta como uma simples referência a um
objeto, e o objeto composto é ligado estaticamente a versão; ou referência para o objeto
versionado, chamado referência dinâmica – refere meios que uma versão específica será
escolhida em tempo de execução, e o objeto composto é ligado dinamicamente ao objeto
versionado.
Objetos compostos podem ser construídos recursivamente, resultando em uma
hierarquia de agregação [Gol 95]. Figura 3 mostra duas versões de um objeto composto da
classe Automóvel. A versão cs tem uma referência estática para a primeira versão do objeto
fiat-motor, o valor do atributo do motor é o OID da primeira versão do objeto fiat-motor.
A nova versão contém uma referência dinâmica para o objeto versionado fiat-motor, o
valor do atributo motor é o OID do objeto versionado.
A substituição de uma referência de objeto versionado por uma referência para
uma versão específica é chamada resolução de referência dinâmica.
fiat-uno
cs
new
fiat... motor
versão
... 1.5
Automóvel
fiat-motor
1.5
1.0
Motor
Figura 3 Referências estáticas e dinâmicas
3 - Objeto e Hierarquias de Versão
3.1 - Herança
Herança é um dos conceitos básicos em bancos de dados orientado a objetos [Ber
93] e um dos mecanismos de reusabilidade. Existem duas maneiras pelas quais a herança
pode ocorrer [Bil 90]: refinamento e extensão.
Refinamento modela o relacionamento IS-A entre uma classe e uma superclasse,
onde há uma migração de propriedades através de níveis de hierarquia.
5
Extensão está relacionada com a idéia de protótipos, cada propriedade se refere a
um nível específico da hierarquia, modelando algum aspecto pertinente do objeto do mundo
real.
3.2 - Objeto e Versão Mapeada
Quando a forma de herança utilizada é por refinamento, versões aparecem somente
nos níveis de hierarquias [Kim 89a, Bee 88, Bjö 89]. Num sistema orientado a objetos, uma
versão é um objeto de primeira classe, possui seu próprio identificador de objeto (OID), o
que permite que seja diretamente manipulada e consultada. Um objeto que possua versões é
dito um objeto versionado, que mantém informações sobre suas versões associadas.
Possuir versões é propriedade de objetos, significa que o objeto poderá estar
representado através de versões. Esta propriedade pode ser definida em tempo de projeto do
banco de dados, associada a uma classe ou tipo.
• motor
Considerando o esquema apresentado
Veículo • combustível
na Figura 4, o exemplo na Figura 5 mostra a
modelagem de versões em mais de um nível da
hierarquia de abstração. A entidade do mundo Automóvel
Caminhão
real fiat-uno é representado em dois níveis de • número de volumes
• capacidade da
caçamba
abstração: Veículo, com as propriedades motor • acessórios
Figura 4 Esquema exemplo
e combustível, e Automóvel, com a
propriedades número de volumes e acessórios.
Em cada um destes níveis, existem versões associadas a correspondentes objetos
versionados. Cada versão deve possuir pelo menos um ascendente correspondente para o
qual está ligado no momento de criação.
V3
1.0 G
v1
fiat-uno-v
1.5 G
V2
V4
1.5 A
1.0 A
cs
mille
elx
M x
M y
M z
Veículo
Automóvel
correspondência
fiat-uno-a
Figure 5 Versões representadas a mais de um nível da hierarquia de herança e suas correspondências
6
Em algumas situações, uma versão pode ter mais de um ascendente. No exemplo,
as mesmas características definidas para a versão cs (de fiat-uno-a, ao nível Automóvel),
pode ser ligada para diferentes versões de fiat-uno-v (no nível de Veículo), representando
as duas opções para o modelo fiat-uno cs, um usando gasolina e outro usando álcool. Por
outro lado, a mesma versão em uma superclasse pode corresponder a mais de uma versão
em uma subclasse. Esta situação acontece no exemplo de Figura 5, onde uma versão de
fiat-uno-v (ex: v4) corresponde a duas versões de fiat-uno-a (mille, elx).
Ficam assim estabelecidas correspondências (mapeamentos) entre versões de um
objeto em uma classe e versões de seu ascendente na superclasse. Na Figura 5, o
mapeamento é n:m, cada versão da classe Automóvel pode corresponder a n versões na
superclasse Veículo, e vice-versa. A correspondência define uma restrição de integridade,
que é especificada a definição do relacionamento de herança entre uma classe e sua
superclasse, no esquema de banco de dados. A correspondência definida entre as versões
podem ser n:m, 1:1, 1:n ou n:1.
Quando é necessário buscar um objeto e todos os atributos herdados, a busca inicia
na classe mais especializada, sendo escolhido um ascendente para cada superclasse
relacionada. O ascendente pode ser explicitamente indicado, através do seu OID, ou
especificado através de um dos critérios pré-definidos: recent (mais recente), first
(primeiro) ou current (corrente). O critério será usado sempre que houver mais de uma
versão ascendente associada à versão (ou objeto) desejada(o).
Objetos versionados e não versionados podem estar presentes na mesma
hierarquia. Objetos não versionados ou versionados que não apresentam versões são
considerados como uma versão, para efeitos de verificação de restrição de cardinalidade
imposta pela correspondência[San 97].
3.3 - Representação de Versões de Muitos Níveis de uma Hierarquia
Como mostrado na seção prévia, muitos níveis de hierarquia permite a modelagem
de entidades do mundo real em muitos níveis de abstração com a presença de versões, não
resulta em modelos adequados em muitas situações.
Uma alternativa seria começar criando uma versão de um objeto de Veículo que
seria refinado mais tarde pela adição das propriedades do Automóvel. Outra possibilidade é
a criação de versões diretamente da classe Automóvel, mas somente com as propriedades de
Veículo (as outras propriedades que recebem valores nulos, são redefinidos depois).
A Figura 6 apresenta as possíveis representações da situação modelada na Figura
5, mas com versões que aparecem somente em um nível.
7
Veículo
mille
cs g
g
elx
g
1.0 G M y
1.0 G M z
cs a
mille a
1.5 A M x
1.0 A M y
1.5 G M x
fiat-uno
elx
a
1.0 A M z
Automóvel
Figura 6 Versões somente como classe mais especializada
Na representação com muitos níveis, versões são agrupadas conforme os valores
de suas propriedades. Na Figura 5, por exemplo, pode-se obter todas as versões de fiat-uno
do nível Automóvel, que tem o motor 1.0 e combustível de gasolina, por aquisição dos
descendentes da versão v3 (nível Automóvel). Versões em um nível podem ser
considerados como alternativas, para as quais são criadas versões aos mais baixos níveis da
hierarquia.
4 - Configurações
4.1 - O Conceito de Configuração
Considerando um objeto composto, em que os componentes podem ser objetos
versionados, uma configuração associa exatamente uma versão para cada um de seus
componentes. Se o objeto é construído hierarquicamente, isto é, um de seus componentes é
novamente um objeto composto, a configuração deve, recursivamente, incluir definições de
versões para todos os componentes na hierarquia de agregação [San 97]. Referências
dinâmicas devem ser solucionadas e o sistema tem que escolher uma versão conforme
alguns critérios pré-definidos.
Diferentes escolhas de versões para componentes e/ou ascendentes geram
diferentes configurações para o mesmo objeto, o que permite considerar que uma
configuração é uma versão especial de um objeto, chamada de versão configurada.
Uma versão configurada é obtida aplicando-se a operação get_configuration a
uma versão. Esta operação define uma única versão para cada ascendente existente na
hierarquia de herança, como também uma única versão para cada componente na hierarquia
de agregação.
A Figura 7 mostra o cenário para construção de uma configuração para a versão b1
consistindo nos seguintes passos:
8
1) b1 tem dois ascendentes correspondentes na superclasse A, assim um deve ser
escolhido. Assuma que a2 é escolhido.
2) existe uma referência dinâmica de a2 para o objeto versionado y na classe Q
que deve ser solucionado. Assuma que q2 é escolhido.
3) q2 também têm dois ascendentes correspondentes na superclasse P, do qual p2 é
escolhido.
Cada escolha
x-a
y-p
define
“parte”
da
a1
a2
p1
p2
A
P
configuração. Quando
a
configuração
é
completamente
definida em um nível,
uma
versão
configurada
é
criada
b1
q1
q2
B
Q
como uma sucessora
x-b
y-q
de sua versão base.
Figura 8 mostra as
Figure 7 Cenário para configuração
versões
de
configurações criadas. Versão c1 é o ponto de partida; versões c2,c3 e c4 foram criadas
como o resultado de escolhas feito nos passos 1, 2 e 3, respectivamente.
x-a
a1
y-p
a2
b1
c2
c1
A
p1
p2
c4
P
B
q1
q2
c3
Q
x-b
y-q
versão configurada
Figura 8 Versões configuradas e seus relacionamentos
O processo de configuração é recursivo, consistindo dos seguintes passos para
cada versão:
1) resolução de referência dinâmica, escolhendo uma das versões associadas ao
objeto versionado de referência;
2) definição de versões ascendentes, para cada uma das superclasses.
Uma versão configurada pode referenciar outras versões configuradas, de forma
que o sistema pode assegurar que uma configuração é completamente especificada.
9
4.2 - Propriedades de Configuração
Uma versão configurada é sempre criada para uma versão existente, para a qual é
conectada como a sucessora. Desde uma configuração ser uma versão (e assim um objeto),
ela tem as seguintes propriedades:
• possui um identificador de objeto (OID);
• possui ascendentes e descendentes;
• é associada a um objeto versionado, da mesma maneira como sua versão básica;
• possui um estado, que pode estar trabalhando, estável ou consolidado;
• pode ser usada como componente de outras configurações, como também
outros objetos (versões, objetos versionados ou objetos não versionados);
• operações definidas por versões regulares podem ser aplicadas para versões
configuradas, trazendo uniformidade para o modelo.
Embora sendo uma versão, uma configuração tem algumas características
especiais:
• é uma especificação completa de um objeto, que não apresenta referências
dinâmicas ou múltiplo ascendentes na mesma superclasse. É um sucessor de sua versão
básica, mas pode diferir do posterior apresentando um único ascendente em cada
superclasse;
• sempre é uma folha no grafo de derivação. Esta característica assegura que uma
configuração sempre pode ser removida;
• modificações em uma versão configurada somente podem acontecer para
referências existentes;
5 - Operações na Hierarquia de Objetos, Versões e Configurações
As operações definidas para objetos e versões (também aplicada a versões
configuradas) podem ser classificadas em três grupos: operações para criação, operações
para navegação na hierarquia de herança e operações para recuperação de versões/objetos.
Os operadores para criação de versões são os seguintes:
create_versioned_object (class): OID;
derive_version (set(OID)
[, ascendant: [class1:] set(OID)...]
[, descendant: [class2:] set(OID)...]): OID;
get_configuration (OID [, configuration expression]): OID;
Criação de versão pode acontecer em um de quatro modos:
1) criação de um objeto versionado e posteriormente criação de versões para ele;
2) derivação de uma versão de um existente (ou mais que um). A versão nova é
uma cópia de seu predecessor;
3) uma versão pode ser derivada para um objeto que não era versionado até este
momento, também pode ser aplicada a versões configuradas;
10
4) uma versão configurada é criada com o operador get_configuration. Uma
expressão de configuração pode ser provida, baseado nas propriedades de objeto.
Operações para navegação na hierarquia de herança permitem a recuperação de
ascendentes e descendentes de um objeto, em determinadas classes. As operações são:
get_ascendant (OID, class[criterion/” * ”]): set (OID ascendant object);
get_descendant (OID, class[criterion/” * ”]): set (OID descendant object);
Se mais que uma versão ascendente existir para a versão desejada, todas as versões
podem ser retornadas (opção *) ou somente uma, de acordo com o critério especificado. O
critério poderia indicar uma seleção manual, quando o OID da versão de ascendente é
determinado, ou uma seleção automática, quando uma das opções pré-definidas é
determinada. O critério pré-definido são: recent, first, ou current (recent é usado como
padrão). A operação de get_descendant é semelhante ao get_ascendant, mas aplicada a
objetos descendentes na subclasse identificada.
Recuperação de objetos pode ser feitos pelas seguintes operações:
get_object (OID): list(attribute values);
get_complete_object (OID [, ascendant: class1 [: criterion]
[, class2 [: criterion]]...]): list(OID);
O operador get_object recupera valores do atributo de um objeto definidos à
classe especificada. Esta operação retorna somente os atributos definidos a um nível da
hierarquia de herança. Para recuperar todos os atributos de um modelo de entidade do
mundo real num banco de dados, navegação deve ocorrer na hierarquia, então todos os
objetos representando a entidade dada são recuperados. A operação get_complete_object
foi definida com este propósito e retorna os ascendentes de um objeto numa hierarquia de
herança, um para cada superclasse.
Além dessas operações, são providas operações para navegação no grafo de
derivação (get_first_version, get_last_version, get_sucessor, get_predecessor,
get_versioned_object).
Deve ser notado que todas estas operações também aplicam a objetos versionados
e dão uniformidade e ortogonalidade ao modelo proposto.
6 - Facilidades para Especificação de Configuração
A operação get_configuration pode ser aplicada a qualquer objeto que tem
componentes ou ascendentes que devem ser resolvidos, seguindo os critérios pré-definidos,
que são os seguintes: a) uma referência dinâmica é substituída por uma referência à versão
atual do objeto versionado; b) a versão de ascendente é a atual.
Construir versões configuradas com mais flexibilidade, tendo facilidades para o
usuário são necessárias. É desejável selecionar versões baseado em suas propriedades,
tendo as facilidades de uma linguagem de consulta.
11
As facilidades que devem ser adicionadas podem ser classificadas em três tipos:
facilidades por referenciamento de objetos, facilidades para navegação na hierarquia de
herança e instalações para navegação na hierarquia de derivação.
Considerando uma linguagem SQL-like (por exemplo como em [Del 88, Sci 94]),
as instalações mencionadas são exemplificadas como as seguintes:
1) Facilidades para referenciamento de objetos
Junto com as instalações existentes, facilidades são necessárias para referenciar
versões de objetos.
Exemplo:
select x.motor, x.fuel,
from Vehicle v, versions(v) x
where x.motor > 1.0 and
x.fuel = ' A';
2) Facilidades para navegação na hierarquia de herança
Com herança de extensão, navegação na hierarquia de herança, na direção
descendente-ascendente, é feita automaticamente para objetos não versionados, através da
herança de valor e delegação [Bil 90]. Quer dizer, sempre que um atributo ou método que
não foram definidos para um objeto a um nível específico são referenciados, o ascendentes
do objeto são recursivamente visitados até certo atributo ou operação é encontrada.
Os termos is_ascendant_of e is_descendant_of permite a navegação na
hierarquia de herança.
Exemplo:
select va.*
from Vehicle v, versions(v) vv, Automobile a, versions(a) va,
where vv.motor=1.0 and
va is_descendant_of vv;
Na Figura 5, esta expressão seleciona versões mille e elx, que são os descendentes
de versões que têm propriedade motor igual a 1.0 (v3 e v4).
3) Facilidades para navegação na hierarquia de derivação
Às vezes é necessário identificar versões de acordo com sua posição relativa ou
absoluta na hierarquia de derivação. Os termos is_first, is_last, is_sucessor_of,
is_predecessor_of permitem, respectivamente, a identificação da primeira ou versão mais
recente em um grafo de derivação, ou o sucessor ou versão antecessora.
O critério less_recent e more_recent aplica a um subconjunto de versões em um
nível que corresponde a uma determinada versão em outro nível da hierarquia de herança.
12
Exemplo:
select vv.*
from Automobile a, versions(a) va, Vehicle v, versions(v) vv
where va.acessories = 'y' and
vv is_ascendant_of va and
vv is_less_recent;
Esta expressão seleciona versão v3, que é a versão menos recente entre o
ascendentes da versão mille (com a propriedade acessórios = ’y’), assumindo que foi criado
antes de versão v4.
7 - Conclusões
Presentemente existem muitos tipos de aplicações para as quais o conceito de
versão é considerado essencial. Exemplos comuns dessas aplicações são Computer Aided
Design e Manufacturing (CAD, CASE, CAM), Automatização de Escritório e
Hiperdocumentos.
O conceito de versão foi discutido no contexto de modelos de banco de dados
orientado a objetos e sistemas. A possibilidade de ter versões a qualquer nível de uma
hierarquia de herança foi discutida, eliminando a necessidade para se concentrar todos os
aspectos relacionados ao versionamento de objetos ao nível de folha da hierarquia. Foi
mostrado como a liberação desta restrição permite uma modelagem mais natural de
situações do mundo real, especialmente aquelas na qual os objetos são construídos no
processo top-down. Neste caso, objetos a níveis mais altos da hierarquia podem ser
versionados antes da criação de objetos de mais baixo nível, sem a necessidade de valores
nulos ou construções semelhantes.
Versões que aparecem a níveis diferentes de uma hierarquia introduzem a idéia de
mapeamento entre versões com uma representação mais natural e concisa das alternativas
para configuração de objeto. Configurações são obtidas pela escolha da versão mais
adequada a cada nível, sem a necessidade para representar explicitamente o conjunto inteiro
de combinações permitidas, como nos modelos onde somente são permitidas versões ao
nível de folha das hierarquias. Neste contexto onde o (freqüentemente muito grande)
conjunto de todas as possíveis combinações de versões é implícita representadas nas
hierarquias de herança, a noção de configuração de objeto é muito importante, a qual
denota completamente uma instância de objeto resolvida, tendo somente referências
estáticas a seus componentes. Configurações correspondem ao conceito de instâncias num
banco de dados sem o conceito de versão.
A aproximação proposta neste documento trata configurações como versões,
melhorando a ortogonalidade do modelo e introduzindo uma possibilidade muito proveitosa
de combinar versões e configurações para construir outras versões, como também
derivando versões novas de configurações. Esta aproximação permite o uso de
configurações que representam o resultado final de um projeto como um componente em
13
outros objetos compostos de nível mais alto. Modularização pode ser aumentado e
reutilizado de objetos de banco de dados é provido. Este tratamento uniforme também
resulta em um modelo mais conciso, como o conjunto de operações definidas por
manipulação de versões é o mesmo usada para configurações.
Referências Bibliográficas
[Agr 91]
Agrawal, R.; Buroff, S.; Gehani, N.; Shasha, D. Object Versioning in Ode. In: Proc. Data
Engineering, 1991, Kobe, Japan. p. 446-455.
[Bee 88]
Beech, D.; Mahbod, B. Generalized Version Control in an Object-Oriented Database. In:
Proc. Data Engineering, 1988, Los Angeles-EUA. p.14-22.
[Bil 90]
Biliris, A. Modeling design object relationships in PEGASUS. In: Proc. Data
Engineering, 1990. Los Angeles-USA. p. 228-236.
[Bjö 89]
Björnerstedt, A. ; Hultén, C. Version Control in an Object-Oriented Architecture. In: Kim,
W.; Lochovsky, F.H. (eds.). Object-Oriented Concepts, Databases, and Applications. ACM Press,
chap. 18, p. 451-485, 1989.
[Bye 93]
Byeon, K.J.; McLeod, D. Towards the unification of views and versions for object
databases. In: Proc. Int. Symp. on Object Technologies for Advance Software, Nov. 1993,
Konazawa-Japan.
[Del 88]
Delobel, Claude; Lecluse, Christophe; Richard, Philippe. LOOQ: a query language for
object-oriented databases, informal presentation. Rapport Technique Altaïr 22-88, 8 Oct. 1988
[FAU 91] FAUVET, M.C. Modelling and managing versions and histories in an object-oriented
environment. Grenoble, IMAG/BULL, July 1991. (Rapport RAP015)
[Gol 93]
Golendziner, L.G.; Santos, C.S. Versões em Bancos de Dados Orientados a Objetos.
Campina Grande, PB, 8º Simpósio Brasileiro de Banco de Dados, 1993.
[Gol 95]
Golendziner, L.G.; Santos, C.S. Versions and configurations in object-oriented database
systems: a uniform treatment. Proceedings of the 7th International Conference on Management of
Data, December,1995.
[KAT 90] KATZ, R.H. Toward a unified framework for modeling in engineering databases. ACM
Computing Surveys, New York , v.22, n.4 , p. 375-408, .Dec 1990.
[Kim 89a] Kim, W.; Bertino, E.; Garza, J.F. Composite objects revisited. In: Proc. ACM SIGMOD
Conference, 1989, Oregon. p.337-347.
[Lam 91] Lamb, Charles W.; Landis, Gordon; Orenstein, Jack A.; Weinreb, Daniel L. ObjectStore.
Communications of the ACM, v.34, n.10, p.51-63, Oct. 1991.
[Mon 92] Monk, S.R.; Sommerville, I. A model for versioning of classes in object-oriented databases.
In: Proc. BNCOD, July 1992, Aberdeen, Scotland.
[San 97]
Santos, C.S. Versões: conceitos, modelos e aplicações. Projeto de Pesquisa. Departamento
de Informática Aplicada – Instituto de Informática da Universidade Federal do Rio Grande do Sul,
Porto Alegre-RS. Fevereiro, 1999.
[Sci 91]
Sciore, E. Using annotations to support multiple kinds of versioning in an object-oriented
database system. ACM Transactions on Database Systems, v.16, n.3, p.417-438, Sept. 1991.
[Sci 94]
Sciore, E. Versioning and configuration management in an object-oriented data model.
VLDB Journal, v.3, p. 77-106, Jan. 1994.
[Tal 93]
Talens, G.; Oussalah, C.; Colinas, M.F. Versions of simple and composite objects. In:
Proc. VLDB, Sept. 1993, Dublin, Ireland. p. 62-72.
[Zdo 87]
ZDONIK, S. Version Management in an Object-Oriented Database. In: INTERNATIONAL
WORKSHOP on ADVANCED PROGRAMMING ENVIRONMENTS, June 1986, TrondheimNoruega. Proceedings. Springer-Verlag, 1987. p.405-422. (Lecture Notes in Computer Science
244)
[Zdo 90]
Zdonik, S. Object-Oriented Type Evolution. In: Bancilhon, F; Buneman, P. (Eds).
Advances in Database Programming Languages. Addison-Wesley, p.277-288, 1990.
14