Dissertação de Mestrado de Ricardo Oliveira Barros - SE/8

Transcrição

INSTITUTO MILITAR DE ENGENHARIA
USO DE REGRAS ATIVAS NO TRATAMENTO DE EVOLUÇÃO DE ESQUEMAS EM
UM SISTEMA DE GERENCIADOR DE OBJETOS
POR
RICARDO OLIVEIRA BARROS
TESE SUBMETIDA
COMO REQUISITO PARCIAL
PARA A OBTENÇÃO DO GRAU DE
MESTRE EM CIÊNCIAS EM SISTEMAS E COMPUTAÇÃO
Assinatura do Orientador da Tese
_________________________________________
ANA MARIA DE CARVALHO MOURA - D. Ing.
Rio de Janeiro
Maio 1996
Tese apresentada por
___________________________________________
RICARDO OLIVEIRA BARROS
e aprovada por:
___________________________________________
ANA MARIA DE CARVALHO MOURA - Dr. Ing.
___________________________________________
ASTÉRIO KIYOSHI TANAKA - PhD.
___________________________________________
MARTA LIMA DE QUEIRÓS MATTOSO - D.Sc.
___________________________________________
GUSTAVO MIRANDA ARAÚJO - M.Sc.
IME, RIO DE JANEIRO - RJ, 03 de Maio de 1996.
ii
RESUMO
Evolução de esquemas é um importante requisito para aplicações OO (Orientadas a
Objeto). Esta funcionalidade está associada à habilidade de executar dinamicamente uma
larga variedade de modificações sobre o esquema do BD, minimizando a necessidade de uma
reorganização em prol de um melhor desempenho do sistema.
Modificações em esquemas de SGBDOOs tendem a ser mais freqüentes do que em
SGBDs convencionais, devido ao fato de que um esquema de BDOO é extensível, ou seja,
suporta a criação de novos tipos e operações. Portanto, a existência de muitos interrelacionamentos no esquema e a necessidade de alterações cada vez mais freqüentes, fazem
com que o suporte à evolução de esquemas em SGBDOOs seja necessário e muito mais
complexo que nos SGBDs convencionais. Muitos dos SGBDOOs comercialmente disponíveis
tratam apenas da integridade estrutural do esquema, não permitindo modificações depois da
base instanciada. Neste trabalho, são tratados os efeitos das modificações do esquema sobre
os métodos e objetos instanciados no SIGO - Sistema Gerenciador de Objetos. O principal
objetivo é garantir, além da integridade estrutural, a integridade comportamental e de
instanciação do esquema da aplicação. Este resultado é obtido pelo armazenamento das
efetivas modificações sobre o esquema numa hierarquia de classes e pela conseqüente
propagação destas modificações aos objetos instanciados. A propagação é feita através de
métodos definidos como regras ativas associados às classes. Estas regras são automaticamente
ativadas por métodos que referenciam os objetos durante a manipulação do esquema.
iii
ABSTRACT
Schema evolution is an important requirement to OO (Object Oriented) applications.
This functionality is associated to the ability to dynamically execute a wide variety of
modifications on the DB (Database) schema, minimizing the need to reorganize it, in order to
have a better performance. Schema changes in an OODBMS (Object Oriented Database
Management System) happen to be more frequent than in conventional DBMS, as the schema
is extensible, that is, it provides the creation of new types and operations. So, the existence of
many relationships in the schema and its need for frequent changes, turns out to require an
OODBMS schema evolution support, naturally much more complex than in conventional
DBMS. Most of the commercial OODBMS available in the market keep only the schema
structural integrity, not allowing modifications after the database has been instantiated. This
work describes the schema modification effects over objects and methods stored in SIGO - an
Object Manager System. Its main purpose is to maintain, besides its structural integrity, the
behavioral and the instantiation integrity of the application schema. This aim is obtained by
storing the real schema modification in a class hierarchy and by propagating these
modifications to the objects instantiated in the DB. This propagation is executed by methods
defined as active rules, associated to the classes. These rules are automatically activated by
application methods that reference objects during the schema manipulation.
iv
SUMÁRIO
RESUMO
iii
ABSTRACT
iv
LISTA DE ILUSTRAÇÕES
viii
LISTA DE TABELAS
xi
LISTA DE ABREVIATURAS E SÍMBOLOS
xii
1 - INTRODUÇÃO
1
1.1 - Posicionamento
1
1.2 - Justificativa para o trabalho
3
1.3 - Objetivo do trabalho
8
1.4 - Organização do trabalho
9
2 - EVOLUÇÃO DE ESQUEMAS EM SGBDOOs
2.1 - Evolução de esquemas sobre um esquema único
11
11
2.1.1 - Evolução de esquemas no O2
15
2.1.2 - Evolução de esquemas no ORION
19
2.1.3 - Evolução de esquemas no GEMSTONE
25
2.1.4 - Evolução de esquemas no OBJECTSTORE
27
2.1.5 - Quadro resumo dos aspectos de correção nos SGBDOOs
estudados
31
2.2 - Evolução de esquemas utilizando Versionamento
v
32
3 - SIGO
38
3.1 - Uma visão geral
38
3.2 - O modelo de objetos e o esquema conceitual
40
3.3 - Evolução de esquemas
45
3.4 - Persistência de objetos
47
3.5 - Ambiente de programação
50
4 - USO DE REGRAS ATIVAS NO TRATAMENTO DE EVOLUÇÃO
DE ESQUEMAS NO SIGO
53
4.1 - Aspectos de Regras Ativas
53
4.1.1 - Uma visão geral
53
4.1.2 - Semântica de regras ativas
57
4.1.3 - Seleção da regra e o modo de acoplamento
58
4.1.4 - Granularidade do processamento de regras ativas
59
4.1.5 - Arquiteturas e técnicas para monitoramento de condições
60
4.2 - Efeito das modificações do esquema sobre os objetos e métodos
63
4.2.1 - Modificações de atributos
65
4.2.2 - Modificações de classes
74
4.2.3 - Modificações de objetos
79
4.2.4 - Modificações de métodos
80
4.3 - Especificação das alternativas e mecanismos utilizados para evolução da
vi
base de objetos
82
4.3.1 - Semântica de regras ativas no SIGO
83
4.3.2 - Aderência Conceitual ao modelo de execução de regras em BDs
Ativos
85
4.3.3 - O Repositório de Regras Ativas Orientado a Objetos (R2O2)
86
5 - DESCRIÇÃO FUNCIONAL DE MÉTODOS E FUNÇÕES
91
5.1 - Operações de modificação sobre objetos e métodos
91
5.2 - Operações específicas de manipulação do R2O2
108
5.3 - Tabelas de Conversão para modificações de atributos
110
6 - AMBIENTE DO PROTÓTIPO DE IMPLEMENTAÇÃO
114
6.1 - Contexto da aplicação
114
6.2 - Operações de evolução da base de objetos no SHC
115
7 - CONCLUSÃO
132
7.1 - Contribuições
132
7.2 - Sugestões para trabalhos futuros
133
7.3 - Considerações finais
135
REFERÊNCIAS BIBLIOGRÁFICAS
137
APÊNDICE A - ESTRUTURA DO ARQUIVO DE MODIFICAÇÕES DO
ESQUEMA ALT.DAT
142
vii
LISTA DE ILUSTRAÇÕES
FIGURA 2.1 - Arquitetura ORION
19
FIGURA 2.2 - Uma hierarquia de classes com conflito de nomes
23
FIGURA 2.3 - Classe VEÍCULOS
24
FIGURA 2.4 - Categorias e subcategorias de modificações de esquema
30
FIGURA 2.5 - Histórico de versões para três objetos X, Y e Z em um BD
34
FIGURA 3.1 - Arquitetura do SIGO
38
FIGURA 3.2 - Definição de Objeto no SIGO
41
FIGURA 3.3 - Exemplo de uma aplicação SIGO
43
FIGURA 3.4 - Seleção da Classe EMPREG e criação do atributo PROJETOS
44
FIGURA 3.5 - Seleção da Classe PROJETO como elemento da Lista PROJETOS
44
FIGURA 3.6 - Definição da Lista PROJETOS para o máximo de sete elementos
45
FIGURA 3.7 - Tabelas representando um esquema conceitual
48
FIGURA 3.8 - Ambiente de desenvolvimento de aplicações
51
FIGURA 4.1 - Algoritmo para o processamento de regras
57
FIGURA 4.2 - Arquitetura Integrada para BDs Ativos
61
FIGURA 4.3 - Arquitetura de Camadas para BDs Ativos
62
FIGURA 4.4 - Inclusão do atributo dt_nasc para a classe Pessoa
66
FIGURA 4.5 - Exclusão do atributo dt_nasc da classe Pessoa
67
FIGURA 4.6 - Modificação do domínio do atributo projeto da classe Funcionário
69
FIGURA 4.7 - Modificação de restrição sobre atributo salário da classe Funcionário
71
FIGURA 4.8 - Modificação de característica sobre o atributo endereço da classe Pessoa 72
FIGURA 4.9 - Inclusão da classe Pessoa como superclasse da classe Professor
viii
75
FIGURA 4.10 - Retirada da classe Pessoa da lista de superclasses da classe Professor
76
FIGURA 4.11 - Retirada da classe Funcionário do esquema do BD
78
FIGURA 4.12 - Migração do objeto 04 da classe Funcionário para a classe Aluno
80
FIGURA 4.13 - Arquitetura do SIGO com suporte à evolução da base de objetos
82
FIGURA 4.14 - Algoritmo para processamento de regras no SIGO
84
FIGURA 4.15 - Hierarquia de classes do R2O2 para operações sobre objetos
87
FIGURA 4.16 - Hierarquia de classes do R2O2 para operações sobre métodos
90
FIGURA 6.1 - Esquema conceitual e tabelas da aplicação SCH
115
FIGURA 6.2 - Objetos instanciados na classe MÉDICO (Exemplo no 1)
122
122
FIGURA 6.4 - Objetos instanciados na classe EXAME (Exemplo no 2)
123
123
FIGURA 6.6- Objetos instanciados na classe MÉDICO (Exemplo no 3)
124
124
FIGURA 6.8 - Objetos instanciados na classe PACIENTE (Exemplo no 4)
125
125
126
126
FIGURA 6.12 - Objetos instanciados na classe PESSOA (Exemplo no 6)
127
127
128
128
128
129
ix
FIGURA 6.18 - Objetos instanciados na classe RESIDENTE (Exemplo no 10)
129
129
130
130
131
131
x
LISTA DE TABELAS
TABELA 2.1 - Aspectos de correção do esquema nos SGBDOOs: O2, ORION,
OBJECTSTORE e GEMSTONE
31
TABELA 5.1 - Conversões possíveis de domínio
111
TABELA 5.1 - Modificações possíveis de restrições
111
TABELA 5.3 - Modificações possíveis de características
111
xi
LISTA DE ABREVIATURAS E SÍMBOLOS
ADB
-
Administrador do Banco de Dados
API
-
Application programming interface
BD
-
Banco de Dados
BDOO
-
Banco de Dados Orientado a Objeto
BLOB
-
Binary Large Objects
CAD
-
Computer-aided Design
CAM
-
Computer-aided Manufacturing
CASE
-
Computer-aided Software Engineering
C/S
-
Cliente/Servidor
ECA
-
Evento / Condição / Ação
GSI
-
GemStone Smalltalk Interface
IA
-
Inteligência Artificial
ID_OBJ
-
Identificadores de Objetos
IME/RJ
-
Instituto Militar de Engenharia no Rio de Janeiro
LIDAS
-
Linguagem para o Desenvolvimento de Aplicações
LIMOS
-
Linguagem Interativa para Manipulação de Objetos
MACRO
-
Módulo de Armazenamento, Criação e Recuperação de Objetos
MAME
-
Módulo de Aquisição e Modelagem de Esquema
MCC
-
Microelectronics and Computer Technology Corporation
MORSO
-
Modelo em Rede Semântica Orientada a Objetos
OIS
-
Office Information System
OO
-
Orientação a Objetos / Orientado a Objetos
xii
R2O2
-
Repositório de Regras Ativas Orientado a Objetos
SCH
-
Sistema de Controle Hospitalar
SGBD
-
Sistema Gerenciador de Banco de Dados
SGBDOO
-
Sistema Gerenciador de Banco de Dados Orientado a Objeto
SGBDR
-
Sistema Gerenciador de Banco de Dados Relacional
SIGO
-
Sistema Gerenciador de Objetos
SQL
-
Structured Query Language
TAO
-
Tipos Abstratos de Objetos
xiii
CAPÍTULO 1
INTRODUÇÃO
1.1 - POSICIONAMENTO
Ao contrário dos SGBDs relacionais (SGBDRs) (CODD,1970) que armazenam apenas
dados, os SGBDs Orientados a Objetos (SGBDOOs) armazenam também processos, sob a
forma de métodos, aplicações e/ou funções, aumentando a complexidade para manutenção da
consistência do esquema do Banco de Dados (BD) em um ambiente dinâmico (MORSI,1992).
Além disso, as classes de um esquema Orientado a Objetos (OO) podem estar interrelacionadas, através de composição ou herança, possibilitando a geração de esquemas
extensíveis. Por estes motivos, alterações em esquemas de Bancos de Dados Orientados a
Objetos (BDOOs) podem causar efeitos colaterais em várias definições, além de afetar objetos
instanciados e a execução de métodos a eles associados (PREVOT,1994).
O paradigma da Orientação a Objetos tem sido o mais adequado para modelar
estruturas complexas no domínio de aplicações não convencionais, tais como: CAD/CAM,
CASE, IA, sistemas baseados em conhecimento e OIS (Office Information Systems) com
documentos multimídia (BANERJEE,1987). Aplicações de BDs Não Convencionais
requerem funcionalidades adicionais, também para ambientes de desenvolvimento, visto que
o projeto de aplicações em geral, vem a ser naturalmente interativo, onde a completeza destes
projetos pode requerer a investigação de algumas alternativas (KIM,1995). Porém, a
importância da flexibilidade de modificar esquemas durante a fase de especificação em
ambientes de desenvolvimento, pode não ser a mesma em ambientes de produção onde o
desempenho seja fundamental (KIM,1990).
1
Assim, além da persistência e compartilhamento - dentre outras características,
advindas dos SGBDs Convencionais e incorporadas ao ambiente OO (ATKINSON,1989)
(KHOSHAFIAN,1993) (CATTELL,1994) - outro importante requisito para estas aplicações é
a evolução de esquemas, ou seja, a habilidade de executar dinamicamente uma larga
variedade de modificações sobre o esquema do BD, minimizando a necessidade de uma
reorganização em prol de um melhor desempenho do sistema (CATTELL,1991).
Alguns SGBDOOs permitem ao usuário modificar a definição de classes, muito
embora variando consideravelmente o nível de assistência oferecido para o manuseio destas
modificações (LÈCLUSE,1989) (DEUX,1991) (FERRANDINA,1995) (ZICARI,1991)
(KIM,1990) (XIDAK,1990) (OBJECTIVITY,1990) (PENNEY,1987) (GEMSTONE,1995)
(OBJECTDESIGN,1990). Por exemplo, se um novo atributo é incluído para uma classe de
objetos:
“É necessário ao usuário corrigir, explicitamente, todos os objetos existentes daquela
classe para que tenham o novo atributo ?”;
“É possível incluir uma nova superclasse quando existem instâncias de uma classe ?”;
“O que acontece aos programas existentes que usam o antigo esquema ?”.
Existem, portanto, três implicações decorrentes de modificações em um esquema de
dados:
(1) Modificações de programas que usam o antigo esquema;
(2) Modificações das instâncias existentes das classes modificadas;
(3) Efeitos das modificações no restante do esquema.
A implicação (1) é extremamente substancial, porém, se for usado encapsulamento
restrito, em modificações feitas somente para atributos, os únicos programas que necessitam
2
ser
modificados
são
aqueles
associados
às
classes
de
objetos
modificadas
(KHOSHAFIAN,1993).
Outrossim, a exclusão ou modificação da interface de um método pode invalidar tanto
o código existente em outra classe de objetos, como também modificar atributos não
protegidos por encapsulamento, ou por algum outro mecanismo de independência de dados.
A maioria dos SGBDOOs não oferece, até então, ferramentas de assistência às
modificações de programas existentes quando ocorrem atualizações no esquema. Contudo, a
capacidade para renomear, incluir e excluir propriedades de tipos de objetos, bem como
incluir e excluir os próprios tipos de objetos em tempo de execução (“run-time types”) são
importantes requisitos, que visam prover ferramentas e programas “Ad hoc” para executar
transformações no esquema. Sem estas capacidades de “run-time types” seria necessário
definir estaticamente o novo e o antigo esquema através de um programa genérico de
transformação (CATTELL,1991).
1.2 - JUSTIFICATIVA PARA O TRABALHO
Como foi visto anteriormente, as aplicações não convencionais necessitam de aspectos
relacionados a um maior dinamismo e que, por enquanto, somente a OO é capaz de satisfazer
a estes requisitos de forma mais simples e natural. Assim, modificações em esquemas de
SGBDOOs tendem a ser mais freqüentes do que em esquemas de BDs Convencionais, pelo
fato dos esquemas gerados por um SGBDOO serem extensíveis, isto é, por suportarem a
criação de novos tipos e operações (CATTELL,1991).
Portanto, a existência de muitos inter-relacionamentos em um esquema e a
necessidade de modificações cada vez mais freqüentes fazem com que o suporte à evolução
3
de esquemas em SGBDOOs seja necessário e muito mais complexo do que nos SGBDs
Convencionais:
relacionais,
redes
e
hierárquicos
(NAVATHE,1994)
(SILBERSCHATZ,1994) (ULLMAN, 1989) (DATE, 1987).
O processo de evolução de esquemas inclui dois importantes aspectos relativos à
consistência intencional e extensional dos componentes do BD. Estes aspectos são
controlados por mecanismos que garantem a integridade do BD como um todo. A parte
intencional é composta pelo esquema, onde está traduzida a semântica da aplicação para o
contexto do modelo de dados utilizado, e a parte extensional é composta pela base de dados,
informações do mundo real captadas de acordo com a perspectiva do esquema
(GUIMARÃES,1995).
Ao serem confrontadas aplicações tradicionais com as não convencionais, é possível
perceber que as primeiras apóiam-se num esquema praticamente fixo, enquanto as outras,
implicitamente, supõem uma dinamicidade da modelagem da realidade, isto é, o possível
surgimento de novos relacionamentos, novas composições etc., ao longo da construção do
esquema, assim tornando, freqüentes as alterações.
Verificada a necessidade de evolução da modelagem e, por conseguinte, do esquema é
preciso garantir sua correção ao longo do processo evolutivo. Em (BANERJEE,1987) estas
modificações são definidas como o mapeamento que leva um esquema de um estado
consistente S a outro S', igualmente consistente. Assim, após cada modificação introduzida,
deve ser verificada a correção do esquema.
Ainda em (BANERJEE,1987) são identificados três aspectos a serem examinados: o
relacionado com a estrutura do esquema frente ao modelo que o sustenta; o relacionado com
as aplicações sobre ele construídas; e o que envolve as instâncias obtidas a partir das classes
que as compõem. Deste modo são observados os seguintes aspectos de correção:
4
(1) Integridade Estrutural
Refere-se à correção do grafo que representa o esquema, onde as classes estão
representadas por arcos de especialização / generalização. Este aspecto é mantido através do
estabelecimento de pré-condições, denominadas invariantes do esquema. Estas invariantes são
verificadas após cada alteração, e quando satisfeitas, asseguram este aspecto de correção.
(2) Integridade Comportamental
Refere-se à correção dos aspectos comportamentais (métodos) associados às classes,
assegurando que suas assinaturas possuem parâmetros com tipos existentes e corretos e que o
valor de retorno tem o tipo certo. De uma forma mais ampla, um BDOO é
comportamentalmente correto se todos seus métodos produzirem o resultado esperado.
Este aspecto é de difícil controle, pois a atuação do método tem um sentido semântico
amplo. No entanto, mantendo-se uma lista de atributos e outra de métodos, é possível
detectar, por exemplo, na oportunidade de redefinição de um atributo, quais métodos serão
afetados e alertar o projetista (detentor do completo domínio da semântica que se desejou
traduzir no código).
(3) Integridade de Instanciação
Aqui a preocupação é que todas as instâncias, ao menos quando consultadas, estejam
de acordo com a definição atual da classe que tomam como base. Neste caso pode não ser
necessário manter as instâncias constantemente atualizadas, bastando que sejam "vistas" como
atualizadas.
5
Outra abordagem semelhante encontrada em (PREVOT,1994), ainda sobre os aspectos
de consistência, apresenta interessantes definições. Nesta abordagem um esquema modela
ambas as partes: estrutural e comportamental do BD. Seus principais componentes são a
hierarquia de classes e as assinaturas de métodos, que descrevem a interface de programação
das instâncias das classes. As classes são os pontos de entrada no BD. Funções, aplicações e
tipos são também partes do esquema.
Uma base é uma coleção de instâncias (objetos e valores) cujas estruturas e
comportamentos estão definidos em um esquema. Ela está sempre relacionada a um único
esquema, que a descreve, podendo servir como definição estrutural e comportamental de
várias bases.
Modificações de esquema podem implicar em alterações nos objetos que estiverem
relacionados com a parte do esquema onde foi feita a mudança. Já modificações de objetos
não implicam em mudanças no esquema. O desejado é que mudanças na parte estrutural e
comportamental não provoquem erros de execução, ou comportamentos anômalos de um
método e/ou função e/ou programa, ou outros tipos de situações imprevisíveis.
A consistência do esquema e da base é estabelecida a partir de uma classificação em
dois tipos: consistência estrutural, que se refere à parte estática do BD; e consistência
comportamental, que se referem aos métodos, aplicações ou funções.
Um esquema é estruturalmente consistente se e somente se:
(1) a hierarquia de classes é consistente;
(2) o conjunto de métodos é consistente;
(3) cada nome dentro do esquema tem uma regra de escopo bem definida.
Uma base é estruturalmente consistente se e somente se:
(1) os valores dos objetos forem consistentes com o tipo da classe a que pertencem;
6
(2) os valores de cada propriedade especificada forem consistentes com o tipo definido
na classe à qual estão associados.
Informalmente, um SGBDOO é comportamentalmente consistente se cada método,
função e programa, através de suas assinaturas e códigos, produzirem o resultado esperado. A
assinatura de um método é utilizada para verificar a compatibilidade de tipo dos argumentos
do método dentro da hierarquia. Portanto, este tipo de verificação também é parte do processo
para assegurar a consistência estrutural. No entanto, a verificação de assinaturas não é
suficiente para assegurar a consistência comportamental de métodos, de funções e de
programas. Existem referências dentro de seus códigos que podem se tornar inválidas após
uma alteração no esquema. Com isto, tais alterações podem resultar em comportamentos
anômalos de algumas funções, programas e métodos no tocante à dependência entre os
mesmos. Por exemplo, remover um método pode tornar outros métodos inconsistentes, por
estes referirem-se a um método não mais existente, ou ainda, porque o método que substituiu,
por herança, o método excluído, tem uma assinatura incompatível com a chamada ao método.
Inconsistências comportamentais nem sempre resultam em erros de execução. Podem
existir métodos que, em conseqüência de uma alteração, tenham um comportamento diferente
do anterior à mudança. É preciso ressaltar que os conceitos de falha em um método (métodos
com erros de execução) e de mudança de comportamento de um método (métodos com
resultado diferente do esperado) são distintos, no entanto, o termo geral “consistência
comportamental” é utilizado em ambos os casos.
Para que o esquema e a base continuem estruturalmente consistentes, deverá ser
garantido que:
(1) não ocorrerão conflitos de herança;
(2) a hierarquia de classes deverá permanecer consistente;
7
(3) o conjunto de assinaturas de métodos deverá permanecer consistente;
(4) a base de dados deverá permanecer consistente com o esquema que a descreve.
Em (KIM,1990) as modificações dinâmicas de esquemas de BDs integrados são
divididas em duas dimensões: evolução sobre um esquema único, onde as modificações são
diretamente executadas sobre um único esquema lógico de BD, e evolução de esquemas
utilizando versionamento, onde são criadas versões do esquema referentes às modificações.
1.3 - OBJETIVO DO TRABALHO
A maioria dos SGBDOOs comercialmente disponíveis trata apenas da integridade
estrutural do esquema, não permitindo modificações depois da base instanciada.
Neste trabalho, são tratados os efeitos destas modificações sobre os objetos
instanciados em uma base definida no ambiente do Sistema Gerenciador de Objetos - SIGO
(MOURAa,1995) (MOURAb,1995) (BARROS,1996). Este tratamento tem como objetivo
garantir a integridade de instanciação do esquema da aplicação, além de sua integridade
estrutural e comportamental, através do uso de regras ativas.
Para obtenção deste resultado, as efetivas modificações sobre o esquema da aplicação
são armazenadas numa hierarquia de classes e, conseqüentemente, propagadas aos objetos
instanciados, podendo resultar na criação, retirada ou modificação destes objetos. Esta
propagação é feita através de métodos associados às classes e definidos como regras ativas,
estruturas capazes de reconhecer
eventos específicos que, sob determinadas condições,
executam algumas ações, seguindo o paradigma (ECA) EVENTO/CONDIÇÃO/AÇÃO
(WIDOM,1996) (CERI,1994) (TANAKA,1995). Estas regras são automaticamente ativadas
8
por métodos de aplicações que referenciem objetos e classes durante a manipulação do
esquema.
Em resumo, a partir da determinação da necessidade de suporte à evolução de
esquemas em SGBDOOs e do estudo de alguns aspectos associados, este trabalho tem por
objetivo, usando regras ativas, estender a garantia de consistência aos objetos instanciados em
uma base definida no sistema SIGO, durante o processo de evolução de esquemas.
1.4 - ORGANIZAÇÃO DO TRABALHO
O restante deste trabalho está organizado da seguinte maneira: no capítulo 2 é
apresentado um estudo sobre evolução de esquemas em SGBDOOs no tocante aos aspectos
específicos: evolução de esquemas sobre um esquema único, e evolução de esquemas
utilizando versionamento. Também são apresentados mecanismos de evolução de esquemas
desenvolvidos nos seguintes SGBDOOs: O2, ORION, GEMSTONE e OBJECTSTORE.
No capítulo 3 é descrito o Sistema Gerenciador de Objetos - SIGO, através de uma
visão geral de sua arquitetura, bem como características específicas de modelagem,
persistência de objetos e ambiente de programação.
O capítulo 4 apresenta a proposta deste trabalho, ou seja, as alternativas e mecanismos
adotados para manutenção da integridade de instanciação, a partir das efetivas modificações
sobre o esquema da aplicação, numa hierarquia de classes definida no SIGO.
No capítulo 5 é descrita a funcionalidade de métodos e funções, especificadas no
capítulo 4.
9
No capítulo 6, os efeitos da propagação das operações de evolução de esquemas são
apresentados através de alguns exemplos implementados sobre o protótipo da aplicação SCH
- Sistema de Controle Hospitalar definida no ambiente SIGO.
No Capítulo 7 são finalmente apresentadas as conclusões do presente trabalho, com
suas principais contribuições e propostas de pesquisas futuras.
10
CAPÍTULO 2
EVOLUÇÃO DE ESQUEMAS EM SGBDOOs
2.1 - EVOLUÇÃO DE ESQUEMAS SOBRE UM ESQUEMA ÚNICO
A independência lógica de dados em SGBDs sugere que o problema de modificação
de esquemas pareça extremamente simplificado. Porém esta ainda é a maior questão, apesar
da antigüidade dos BD. Este problema não surgiu com as linguagens de programação, onde
tipos criam dados, em vez de dados criarem tipos.
Os SGBDOOs são suportados por um modelo complexo e destinam-se às aplicações
nas quais mudanças no esquema podem ser freqüentes, fruto de modificações na modelagem
realizadas pelo projetista e que implicarão em operações de correção sobre a definição do
esquema. Este processo necessita de meios que, integrados ao BD, possibilitem a prototipação
do comportamento do esquema frente às modificações.
Em (BANERJEE,1987) é definida uma taxonomia para modificação de esquemas,
bem como (ABITEBOUL,1988), (PENNEY,1987), (ZICARI,1991), também definem
taxonomias similares. Podemos usar cada taxonomia para classificar sistemas de BDs
conforme o tipo de modificação de esquema permitido, isto é, se as modificações permitidas
são em tempo de execução e se o sistema modifica automaticamente instâncias ou programas
existentes. Embora pudessem ser facilmente incluídas como outra modificação, as definições
de relacionamentos não constam destas taxonomias, visto que nos sistemas de BD os
relacionamentos são representados como atributos.
Alguns sistemas permitem simplesmente modificar nomes, incluir e excluir
propriedades. O nome modificado, bem como a inclusão e a exclusão de métodos tipicamente,
11
envolvem modificações apenas para o próprio esquema, já que em vez de nomes,
identificadores são usados para referenciar os tipos das próprias instâncias. A inclusão ou
exclusão de atributos ou relacionamentos, muitas vezes requer técnicas mais sofisticadas,
porque normalmente espaços são reservados para esses dados em cada instância.
As modificações podem ter efeito sobre objetos existentes,
alterando-os
imediatamente no momento em que o esquema é modificado, ou pelo uso de uma
representação de tipo, que permita a coexistência de instâncias de objetos com diferentes
conjuntos de atributos, ou relacionamentos, quer dizer, evolução de esquemas utilizando
versionamento vista no item 2.2 deste capítulo.
Uma alternativa, denominada “lazy update”, representa uma forma postergada de
propagação dos efeitos sobre os objetos. Esta alternativa é mais difícil de implementar, mas
útil por evitar uma sobrecarga no tempo de modificação do esquema. Mais adiante, estas
alternativas serão discutidas como uma questão de implementação.
ORION e seu sucessor ITASCA (ITASCA,1990), bem como o O2 provavelmente
possuem o mais sofisticado tratamento de evolução de esquemas dentre os SGBDOOs
estudados, suportando a maior parte das modificações contidas na taxonomia definida em
(BANERJEE,1987).
Outrossim, uma vez que modificações relativamente complexas podem ocorrer em
muitas aplicações, outra alternativa seria o sistema propiciar boas ferramentas para auxiliar o
usuário final na transformação do esquema, dos objetos, e dos programas, ao invés de prover,
incrementalmente, uma evolução de esquemas mais automática para modificações contidas na
taxonomia sugerida (CATTELL,1991).
Conforme visto anteriormente, alguns autores sustentam que o esquema modifica-se
mais freqüentemente para aquelas aplicações em que os SGBDOOs são mais indicados,
12
embora existam aplicações em SGBDs Relacionais (SGBDRs) onde modificações de
esquema sejam igualmente freqüentes.
Em qualquer caso, a evolução de esquemas é um problema importante e mais
complexo em modelos de dados avançados, por causa do número de características e das
possibilidades de transformações de esquema nestes modelos.
Em (CATTELL,1991) são definidas quatro principais alternativas de manutenção de
instâncias para evolução de esquemas:
(1) “Write-once type” (tipos criados uma vez): a alternativa mais simples, que
consiste em proibir as modificações no esquema, uma vez que instâncias tenham sido criadas.
Se um usuário desejar definir um novo atributo ou modificar a classe, uma nova classe deve
ser definida e as instâncias antigas copiadas para esta. Esta alternativa era adotada pelo SIGO,
anteriormente a este trabalho;
(2) “Immediate Update” (atualização imediata): como o nome sugere nesta
alternativa a mudança do esquema afeta imediatamente as instâncias existentes da classe. Por
exemplo, se um novo atributo é adicionado para uma classe de objetos, todos os objetos
daquela classe são automaticamente atualizados, recebendo um valor “null” para o atributo
adicionado. Esta alternativa, adotada pelo OBJECTSTORE (OBJECTDESIGN,1990) e
GEMSTONE (GEMSTONE,1995) é considerada a mais comum entre os SGBDOOs.
(3) “Lazy Update” (atualização postergada): esta alternativa, adotada pelo ORION
(XIDAK,1990) e pelo O2 (FERRANDINA,1995), consiste em retardar as atualizações para
objetos de uma classe até que estes sejam referenciados. Quando os objetos são recuperados
na memória, uma associação acrescentada ao objeto indica se este foi atualizado pela última
definição. Se o esquema mudou - por exemplo, um atributo foi incluído - a atualização é feita,
então, neste momento. Nesta alternativa, a informação do histórico do esquema e conversão
13
de procedimentos deve ser mantida pelo SGBDOO, até que todas as instâncias da classe
modificada tenham sido convertidas para a nova representação.
Em (HARRUS,1990) é apresentado um estudo sobre o desempenho “lazy update”
versus “immediate update”.
(4) “Schema Mapping” (mapeamento de esquemas): a alternativa mais extrema,
que consiste em manter um mapeamento entre a representação corrente das classes e todas as
versões anteriores, retardando, indefinidamente, as atualizações para objetos existentes, ou até
que uma reorganização seja explicitamente requisitada. Este mapeamento requer a
manutenção de múltiplas versões de um esquema, o que permite aos usuários diferentes
visões de um mesmo objeto. Sistemas como ORION e GEMSTONE provêem esta
funcionalidade. Haja vista a sua complexidade, esta alternativa é de difícil implementação
para os SGBDOOs.
Geralmente, para modificações de esquemas suficientemente complexas, todos os
SGBDOOs tendem a utilizar a primeira alternativa, definindo novas classes e copiando as
instâncias existentes. Alguns sistemas podem manipular diretamente modificações simples,
tais como inclusão ou exclusão de um atributo, de um relacionamento ou de um método e
inclusão ou remoção de subclasses. Embora, de modo direto, em sistemas como o ORION que pode manipular todas as modificações da taxonomia anteriormente apresentada - a vasta
maioria das modificações não coberta pela mesma taxonomia, requer que o usuário
desenvolva programas para criar novas classes e executar transformações de dados do
esquema antigo para o esquema novo.
Provavelmente, a maioria das modificações de esquema do mundo real irá requerer
programação nos SGBDOOs e pesquisas dentre os mais sofisticados algoritmos de
transformação de esquemas.
14
Apesar de academicamente interessante, esta situação, muito provavelmente, não será
mudada. Entretanto, esforços podem ser futuramente alocados em pesquisas de ferramentas
mais sofisticadas, para assistir ao usuário na modificação do esquema. Por exemplo,
ferramentas de transformações gráficas, ou linguagens com o objetivo de simplificar uma
larga classe de transformações, no lugar de fazer melhorias incrementais para facilitar a
modificação de esquemas executadas pelo próprio SGBDOO.
No mínimo, a introdução de linguagens de consulta mais poderosas e de linguagens de
programação mais amigáveis para BD, proporcionam certo grau de simplificação às
atualizações para as instâncias existentes. Esta é a alternativa adotada na maioria dos SGBDs
convencionais.
Qualquer que seja a opção, os usuários também devem tratar da
compatibilidade de programas existentes que usem o antigo esquema. A linguagem de
consulta declarativa pode tomar um longo caminho no sentido de satisfazer esta exigência.
Ferramentas gráficas ou linguagens especificamente orientadas no sentido de
descreverem transformações também podem ser úteis. Existem, portanto, muitos trabalhos e
pesquisas sendo desenvolvidos em busca de soluções, cada vez mais adequadas, para o
tratamento de modificação de esquemas (CATTELL,1991).
2.1.1 - Evolução de Esquemas no O2
O sistema O2 (LÈCLUSE,1989) (DEUX,1991) (SOLOIEV,1992) (ZICARI,1991)
(FERRANDINA,1995) é um SGBDOO comercializado pela O2 Technology. A estrutura
principal de um esquema O2 é constituída por um conjunto de classes relacionadas por
herança e/ou composição. O esquema O2 contém a definição de tipos, funções e aplicações,
15
enquanto a base O2 agrupa, de forma conjunta, objetos e valores que são criados segundo a
definição do esquema.
Um objeto possui uma identidade, um valor e um comportamento definidos pelos
seus métodos. Objetos são instâncias de classes e valores são instâncias de tipos. Um objeto
pode ser compartilhado ou referenciado por diferentes entidades, na qual uma entidade pode
ser um objeto, ou um valor. Por definição, objetos e valores criados em tempo de execução de
programas não são persistentes. Para uma entidade tornar-se persistente, deverá ser direta ou
indiretamente, vinculada a um nome, isto é, uma raiz persistente pertencente ao esquema.
A definição de classe consiste de uma definição de tipo e um conjunto de métodos.
Um tipo é uma descrição genérica de uma estrutura de dados, definido recursivamente como
um dos tipos: atômicos (“integer, boolean, char, string, real, ...”), classes e construtores
(“tuple, set, list...”). Métodos são codificados usando o O2C ou a linguagem C++, as quais
habilitam a manipulação de entidades persistentes e não persistentes.
O encapsulamento no O2 é provido em diferentes níveis. Primeiramente, propriedades
por definição são privadas para suas classes. Os programas são encapsulados em aplicações.
Finalmente, no nível do esquema, o encapsulamento existe, uma vez que elementos de um
esquema não podem ser usados por outro esquema. Visando a melhora do critério de
reusabilidade, O2 provê um mecanismo de importação e exportação de esquemas.
O O2 permite herança múltipla. Quando uma subclasse herda propriedades com um
mesmo nome (de duas ou mais de suas superclasses), mas com definições conflitantes, ocorre
o que chamamos de conflito de herança. Existem duas categorias de conflito. No caso simples
as propriedades têm o mesmo nome, mas suas origens são distintas, neste caso, o O2,
automaticamente, atribui diferentes nomes para as propriedades, de modo que a classe onde
ocorre o conflito herde todas as propriedades, isto é chamado de renomeação. No caso mais
16
complicado, as propriedades com o mesmo nome têm uma mesma origem, mas foram
herdadas por diferentes caminhos na hierarquia, isto é chamado de herança repetida. No caso
das propriedades não terem sido redefinidas ao longo de seus caminhos, nenhum problema
ocorre, pois a classe herdará somente uma cópia da propriedade. O problema existe quando as
propriedades são redefinidas ao longo dos diferentes caminhos.
As modificações de esquema em O2 podem ser executadas tanto de forma incremental,
usando primitivas específicas, como por exemplo, incluindo ou excluindo atributos de uma
classe, como também pela redefinição da estrutura de classes como um todo. As primitivas de
manipulação de esquemas disponíveis, são as seguintes:
(1) Criação de uma nova classe;
(2) Modificação de uma classe existente;
(3) Exclusão de uma classe existente;
(4) Renomeação de uma classe existente;
(5) Criação de uma relação de herança entre duas classes;
(6) Exclusão de uma relação de herança entre duas classes;
(7) Criação de um novo atributo;
(8) Modificação de um atributo existente;
(9) Exclusão de um atributo existente;
(10) Renomeação de um atributo existente;
Independentemente de como a classe é modificada, o O2 executa somente aquelas
modificações que mantêm o esquema consistente.
A integridade comportamental no O2 é tratada da seguinte forma: no caso de haver
referências inválidas a métodos, às funções e/ou a programas, estes não serão alterados. As
17
referências inválidas serão apenas informadas, ficando a avaliação e alteração do código fonte
sob responsabilidade do usuário.
No atual estágio de implementação, o O2 garante a integridade de instanciação pelas
alternativas “immediate update” e “lazy update”, proporcionando ao projetista a possibilidade
de selecionar a que for mais apropriada ao domínio de sua aplicação, a partir de funções de
conversão disponibilizadas pelo sistema.
As atualizações semânticas para manutenção da integridade da base de dados ocorrem
após a modificação do esquema, de acordo com o que tenha sido definido para a aplicação.
Este mecanismo básico é muito simples: o projetista programa funções de conversão, que são
associadas às classes do esquema e que definem como os objetos devem ser reestruturados. Se
nenhuma conversão for especificada pelo projetista, o sistema provê funções de conversão
padrão para as quais não é requerido qualquer tipo de programação. Nesse caso, quando uma
classe do esquema é modificada, o sistema compara cada atributo da classe antes e depois da
modificação e transforma os valores dos objetos de acordo com as seguintes regras padrão:
•
Se um atributo definido em uma classe não estiver presente após sua modificação,
o mesmo foi excluído e será ignorado;
•
Se um atributo aparecer em uma classe após sua modificação, este foi incluído e
será inicializado com valores pré-estabelecidos, por exemplo, zero para inteiros,
nulo para atributos que referenciem classes, etc.;
•
Se um atributo aparecer em uma classe antes e após sua modificação, será
inicializado a partir de valores de conversão pré-estabelecidos, de acordo com a
alteração de tipo.
O projetista poderá sobrepor as funções padrão de transformação, pela definição
explícita de funções de conversão para as classes, após suas modificações no esquema. Neste
18
caso, estas modificações ocorrerão em duas fases. Primeiramente, as classes serão atualizadas,
usando primitivas de atualização do esquema. A segunda fase, denominada fase de conversão
por funções definidas, as inicializações ocorrerão de acordo com o que foi especificado pelo
usuário (FERRANDINA,1995).
2.1.2 - Evolução de Esquemas no ORION
ORION (KIM,1987) (KIM,1990) (XIDAK,1990) é um SGBDOO desenvolvido pela
MCC - Microelectronics and Computer Technology Corporation sob o paradigma da
programação OO. É um sistema multiusuário, multitarefa, destinado as aplicações em IA,
documentos multimídia e CAD/CAM. Foi implementado em Common Lisp e portado para
workstation Sun /UNIX (VELEZ,1989). A Figura 2.1 apresenta uma visão de alto nível da
arquitetura ORION.
Gerenciador de
Mensagens
Subsistema de
Objetos
Subsistema de
Transações
Subsistema de
Armazenamento
FIGURA 2.1 - Arquitetura ORION
O gerenciador de mensagens recebe todas as mensagens enviadas ao sistema ORION,
incluindo mensagens para métodos definidos pelo usuário, mensagens de acesso e funções
19
definidas pelo sistema. Uma mensagem de acesso recupera ou atualiza o valor de um atributo
de classe. Funções definidas pelo sistema incluem: funções para definição de esquemas,
criação e exclusão de instâncias, gerenciamento de transações e outras.
O subsistema de objetos provê funções de alto nível, tais como evolução de esquemas,
controle de versões, otimização de consultas e gerenciamento de informações multimídia.
O subsistema de armazenamento provê acesso aos objetos em disco. Gerencia a
alocação e liberação de segmentos de páginas no disco, recupera e armazena objetos nas
páginas e move páginas do disco e para o disco. Ele ainda gerencia índices criados sobre
atributos de uma classe, para acelerar a avaliação de consultas associativas.
O subsistema de transações provê um controle de concorrência e um mecanismo de
proteção da integridade do BD, enquanto permite a execução intercalada de múltiplas
transações concorrentes. O controle de concorrência usa um protocolo de bloqueio (“locking
protocol”), e um mecanismo de replicação (“logging mechanism”) para recuperar falhas do
sistema e términos anormais de transações geradas pelos usuários.
Aplicações ORION têm considerável flexibilidade para definir e modificar
dinamicamente o esquema do BD, isto é, as definições de classe e a estrutura hierárquica do
diagrama de classes (“class lattice”).
Foi desenvolvida uma taxonomia de operações de modificações de esquemas no
ORION, que consiste de um conjunto de propriedades do esquema chamada invariantes e de
um conjunto de regras para preservar as invariantes (KIM,1990). As invariantes detêm todo o
estado consistente do esquema (“quiescent state”), antes e depois de uma operação de
modificação de esquema. Além disto, provêem fundamento à definição da semântica de toda
modificação significativa de esquema, garantindo que estas não deixarão o esquema em um
estado inconsistente, ou seja, não violarão nenhuma invariante.
20
O conjunto de regras estabelece a seleção das invariantes de uma maneira mais
expressiva.
O ORION suporta dois tipos de modificação de esquemas: modificações para
definições de uma classe em um diagrama de classes (“classe lattice”) e modificações para
estrutura de um diagrama de classes. O primeiro tipo inclui a criação e exclusão de uma
classe, bem como alteração do relacionamento É-UM (IS-A) entre classes. A taxonomia
adotada
para
modificação
de
esquemas
é
uma
versão
daquela
proposta
por
(BANERJEE,1987).
Serão vistas a seguir, as definições semânticas para algumas operações, envolvendo
maior complexidade, a exemplo de modificação de esquema, quando a base já está
instanciada:
(1) Modificações para os componentes de um tipo:
(1.1) Modificações para atributos
(1.1.2) Excluir um atributo V de uma classe C.
Se V for excluído de C, deve também ser excluído recursivamente de outras
subclasses de C. Se C ou qualquer de suas subclasses possuírem outras superclasses que
possuem atributos de mesmo nome V, C herda um dos atributos. Neste caso, V deve ser
excluído de C, ou de qualquer de suas subclasses sem uma reposição. Instâncias existentes
destas classes perdem seus valores para V.
(2) Modificações na hierarquia de classes:
(2.1) Tornar uma classe S uma superclasse de uma classe C.
A inclusão de uma nova classe não pode resultar em um ciclo no diagrama de
classes C e suas subclasses herdam atributos e métodos de S, supondo-se que não ocorra
conflito de nomes. A instância de C e suas subclasses recebem valor nulo para os novos
21
atributos herdados. As operações 1.1.1 e 1.2.1 são aplicadas, respectivamente, para incluir
atributos e métodos de S para C.
(2.2) Remover a classe S de uma superclasse Lista, onde S é superclasse de C.
A exclusão de uma superclasse S de uma classe C não pode resultar num
diagrama de classes desconectado. Neste caso, S seria a única superclasse de C. A superclasse
imediata de S, tornar-se-á a superclasse imediata de C. Portanto, C não perde nenhum atributo
ou métodos que eram herdados das superclasses de S. C perderá somente os atributos ou
métodos que havia herdado diretamente de S. As operações para exclusão de atributos (1.1.2)
e de métodos (1.2.2) são aplicadas, respectivamente, para cada atributo e método que forem
excluídos de C.
(3) Modificações das classes:
(3.2) Excluir uma classe C existente.
Todas as ligações de C para suas subclasses serão excluídas, usando a operação 2.2.
Posteriormente, todas as ligações de C para suas superclasses serão excluídas. Finalmente, a
definição de C é excluída e C é removido do diagrama. As subclasses de C continuam
existindo. Se a classe C era o domínio de um atributo V1 de outra classe C1, então V1 é
referenciado para a primeira superclasse da classe C excluída.
Existem duas maneiras pelas quais um método que contém uma referência para um
atributo, ou para outro método, pode tornar-se inválido. Uma, obviamente, ocorre quando o
método ou o atributo referenciado foi removido. Por exemplo, na Figura 2.2, se o atributo Vx
for removido da classe A, o método Ma que referencia Vx torna-se inválido. O problema pode
ser solucionado pela identificação e invalidação dos métodos afetados pela remoção. Esta
verificação é feita a partir de uma lista que mostra a associação dos parâmetros a cada método
22
das classes e suas subclasses. A invalidação de um método pode por sua vez causar a
invalidação de outros métodos.
O segundo tipo, uma forma mais complexa, ocorre apenas para sistemas que suportam
herança múltipla e pode ser ilustrado pela mesma Figura 2.2. A classe C possui duas
superclasses A e B. A classe A possui o atributo Vx e o método Ma localmente definidos e
Ma referencia Vx. Similarmente, a classe B possui o atributo Vx e o método Mb localmente
definidos e Mb referencia Vx. Vx de A e Vx de B, apesar de possuírem o mesmo nome, são
atributos diferentes. Quando a classe C é criada, ela herda Ma e Mb; mas Vx é herdado apenas
da primeira superclasse A. Então Mb em C vai referenciar Vx que C herdou de A.
Este problema ocorre quando uma classe herda, separadamente, o método e os
atributos referenciados pelo método. Portanto, uma forma simples de resolver o problema é
requerer que ambos sejam herdados conjuntamente, tratando as modificações necessárias aos
atributos referenciados e os métodos que apresentem conflitos de nomes.
A
B
Atributos
Vx
Métodos
Ma-referencia Vx
Atributos
Vx
M étodos
Mb-referencia Vx
C
Atributos
Vx herdado de A
Métodos
Ma- herdado de A
Mb- herdado de B
FIGURA 2.2 - Uma hierarquia de classes com conflito de nomes
23
Para manutenção da integridade de instanciação, o ORION adota a alternativa “lazy
update”. Se as modificações afetarem logicamente as instâncias, o sistema remove as
informações desatualizadas, ou ainda, atribui valores nulos, quando as instâncias são
apresentadas ao usuário. Esta situação pode ser ilustrada a partir do exemplo mostrado na
Figura 2.3. Se o atributo Peso é removido da classe Veículos, o sistema remove os valores
deste atributo para as instâncias O1, O2 e O3. Em outro caso, se o atributo Cor for inserido
para a classe Veículos, o sistema insere o atributo Cor com valor nulo para as instâncias O1,
O2 e O3. Tanto a retirada quanto a inserção de valores somente ocorrem quando as instâncias
forem referenciadas.
VEÍCULOS
Cor
Atributos
Identificação
Peso
Fabricante
O1 O2 O3
FIGURA 2.3 - Classe VEÍCULOS
A alternativa “lazy update” garante um melhor desempenho às operações de
modificações de esquema, embora com a desvantagem das informações desatualizadas
permanecerem no BD até sua efetiva propagação. Além disso, esta alternativa não é viável
para algumas operações significativas, como é o caso da intercalação de mais de uma classe
em uma classe única. Todas as instâncias das classes irão pertencer à nova classe, como
também seus identificadores de classe serão atualizados (KIM,1990).
24
2.1.3 - Evolução de Esquemas no GEMSTONE
O
sistema
GEMSTONE
(BUTTERWORTH,1991)
(GEMSTONE,1995)
(PENNEY,1987) é um produto comercial desenvolvido pela Servio Logic Corporation,
atualmente GemStone Systems Inc., com o objetivo inicial de dar persistência à linguagem
Smalltalk, tornando-a um SGBDOO. O GemStone está disponível para uma extensa faixa de
sistemas baseados em UNIX, dentre eles: Sun SPARC, HP 9000, 700 e 800, e IBM RS/6000.
Está disponível também para plataformas INTEL com sistemas operacionais Windows NT.
Além disso, o sistema provê as seguintes funcionalidades:
•
Ambiente heterogêneo, distribuído, multiusuário, cliente / servidor, com
mecanismo para diversos níveis de segurança e controle de concorrência;
•
Estruturação de dados em diversos níveis;
•
Modificação do esquema sem necessidade de reestruturação do BD;
•
Capacidade de armazenar os diferentes estados do BD, possibilitando assim a
consulta a estados anteriores;
•
Ambiente para desenvolvimento de aplicações, gerenciamento e administração de
classes e métodos através de ferramentas visuais, providas pelo (GSI) GemStone
Smalltalk Interface;
•
A linguagem GemStone Smalltalk, para definição e manipulação de dados, e para
a facilitação de consulta numa linguagem computacionalmente simples.
Apesar de possuir sua própria linguagem, GemStone Smalltalk, os usuários podem
desenvolver suas aplicações em: C++, ParcPlace\Smalltalk (Visual Works), IBM Smalltalk
(VisualAge), Smalltalk V (Visual Smalltalk Enterprise) e C, ou qualquer linguagem que faça
25
chamadas C, tais como COBOL ou FORTRAN. Além disso, é garantida a interoperabilidade
entre os objetos gerados, independentemente da linguagem utilizada (GEMSTONE,1995).
A arquitetura básica do GEMSTONE consiste de um repositório para armazenamento
de objetos e um conjunto de processos. Os dois processos chave são Gem e Stone.
O Gem é um servidor primário e provê o processamento multiusuário em Smalltalk, o
armazenamento e a recuperação de objetos para aplicações e programas desenvolvidos por
qualquer das interfaces, além disso, provê, igualmente, visões consistentes do repositório de
objetos, o gerenciamento de sessões de usuário, o histórico e a paginação de memória para os
objetos acessados quando necessários. Conforme o caso, as aplicações de usuários estarão
conectadas a no mínimo um ou a muitos processos Gem.
O Stone é um coordenador de recursos para o repositório de objetos. É responsável
pelo sincronismo de atividades e garantia de consistência. Como gerenciador de dados provê
o I/O de disco, o controle de concorrência, de autorização, de transações e serviços de
recuperação.
O modelo de dados do sistema é resultante da extensão dos conceitos da linguagem
Smalltalk, ele baseia-se em conjuntos rotulados de valores heterogêneos. Cada elemento de
um conjunto possui um nome único no conjunto e um valor, que pode ser um conjunto ou um
tipo simples.
O desenvolvimento ou manutenção de uma aplicação pode necessitar de modificações
das classes do esquema, o que implica em dois problemas. Primeiro como modificar as
classes sem afetar outros usuários que estejam dependendo de uma versão estável daquela
classe? E segundo, como modificar as instâncias existentes, como reflexo das modificações
na estrutura de classes?
26
Para solucionar estes problemas, o GEMSTONE possui as funcionalidades de
versionamento de esquemas e migração de instâncias.
O versionamento de esquemas permite que os usuários e projetistas trabalhem sobre
diferentes versões do esquema no mesmo repositório, ou seja, projetistas podem modificar e
testar uma versão, enquanto usuários trabalham sobre uma versão estável em uma aplicação
desenvolvida.
A migração de instâncias permite aos projetistas atualizarem automaticamente
algumas, ou todas as instâncias existentes numa classe modificada. Para isto, uma nova
versão da classe pode ser criada de forma que se possa trabalhar com as instâncias existentes
(GEMSTONE,1995).
2.1.4 - Evolução de Esquemas no OBJECTSTORE
OBJECTSTORE
(OBJECTDESIGN,1990)
(LAMB,1991)
é
um
SGBDOO
desenvolvido pela Object Design Inc., especificamente para atender à demanda dos requisitos
C/S (Cliente/Servidor).
É um sistema de gerenciamento completo, provendo compartilhamento flexível e
escalonável de dados num ambiente C/S heterogêneo, além de gerenciar dados sofisticados de
uma maneira natural, diferentemente das soluções de armazenamento com tabelas ou arquivos
hierárquicos. Pode ser caracterizado como um BD baseado em objetos, completamente
distribuído, multi-cliente, com linguagens C, C++, e Smalltalk. O sistema foi projetado para
armazenar
todos
os
tipos
de
dados
para
independentemente de suas complexidades.
27
aplicações
comerciais
e
científicas,
O OBJECTSTORE permite o gerenciamento de transações e o acesso concorrente a
objetos por múltiplos usuários da rede, oferecendo funções de BD, tais como “two-phasecommit”, controle de versões, suporte a evolução de esquemas, recuperação e uma arquitetura
completa multi-cliente / multi-servidor.
No módulo cliente, encontra-se a API “Application programming interface” para
gerenciamento de memória e de memória cache, o serviço para tratamento de esquemas e
transações e mais um módulo de comunicação com o servidor.
No módulo servidor, encontra-se o gerenciador de diretórios, o armazenamento de
dados, o controle de “deadlock”, “backup/restore”, a recuperação de erros e controle de
transações e mais um módulo de comunicação com o cliente.
O OBJECTSTORE está disponível para os sistemas Solaris, AIX, Microsoft
WINDOWS, 0S/2, Netware e as plataformas UNIX mais comuns.
Para definição e manipulação dos modelos de dados, o sistema provê a identidade de
objetos, os atributos inversos, a herança múltipla, os objetos extensos (BLOBs), um
“browser”
interativo
e
uma
ferramenta
interativa
para
projeto
de
esquemas
(OBJECTDESIGN,1990). Além disso, o OBJECTSTORE suporta todos os tipos de dados:
básicos, estruturas e arrays construídos com os tipos básicos, as classes coleções e os
relacionamentos de nível mais alto.
O sistema também oferece facilidades para trabalho cooperativo através de transações
longas e aninhadas. É possível copiar um grupo de objetos para um espaço privado, fazer as
alterações desejadas e, então, devolvê-los à área comum de desenvolvimento, tornando suas
modificações visíveis ao restante da equipe de usuários (LAMB,1991).
Na fase de desenvolvimento de aplicações, o utilitário “ObjectStore Schema
Generator” realiza a compilação, linkedição e armazenamento do esquema num BD especial.
28
Quando a definição da classe muda, o esquema também muda e todos os objetos persistentes
têm de ser migrados. Esta evolução de esquemas é implementada em duas fases: modificação
do esquema e migração das instâncias (fase que, por sua, vez divide-se em: inicialização das
instâncias e transformação das instâncias).
A primeira fase envolve modificações no próprio esquema, por exemplo, incluir ou
corrigir um atributo de uma classe. Esta é a parte trivial do processo, a partir do momento em
que as modificações forem realizadas e as aplicações recompiladas, qualquer nova instância
de objeto será representada de acordo com o novo esquema.
A fase de migração das instâncias envolve modificação na representação dos objetos
persistentes existentes, em princípio, pela inicialização das instâncias existentes nas classes
modificadas, bem como pela modificação de suas representações conforme as definições da
nova classe. Esta atividade pode envolver: inclusão ou exclusão de campos ou sub-objetos,
modificação do tipo de um campo ou exclusão de todos os objetos. Esta fase da migração
também inicializa quaisquer componentes armazenados que tenham sido incluídos e cujo tipo
tenha sido modificado. Na maioria dos casos os novos campos são inicializados com zeros.
Para algumas modificações apenas a fase de inicialização é suficiente. Mas em outros
casos, modificações adicionais de instâncias e estruturas são requeridas para completar a
evolução de esquemas. A Figura 2.4 ilustra as categorias e subcategorias de modificações de
esquema. Estas modificações adicionais são geralmente dependentes de aplicações. Para esta
tarefa, o OBJECTSTORE permite ao usuário definir suas próprias funções de transformação.
Nestas funções, o usuário associa um procedimento “transformador” a cada classe que deseja
transformar. Na fase de migração, para cada instância, são chamadas as funções de
transformação associadas às classes. Este tratamento inclui também as instâncias das
subclasses.
29
Modificações
de
Esquemas
Criação
de
Classes
Redefinição
de
Classes
Redefinição
de
Atributo
Redefinição
de
Herança
Inclusão
de
Atributo
Exclusão
de
Classes
Exclusão
de
Atributo
Redefinição
de
Função
Reordenação
Modificação
de
Domínio
FIGURA 2.4 - Categorias e subcategorias de modificações de esquema.
Funções de transformação são particularmente úteis quando o usuário deseja
determinar o valor de um atributo de uma instância migrada, a partir de valores de um ou mais
campos pertencentes à antiga instância. Para isto, é provida uma função que permite ao
usuário recuperar a antiga instância correspondente à nova instância.
Estas funções também são úteis para ajustar referências locais e estruturas de dados
dependentes dos endereços das instâncias migradas. Por exemplo, uma tabela “hash” pode ser
reconstruída a partir de um procedimento transformador.
Terminada a fase de transformação, todas as instâncias antigas serão excluídas. Se as
instâncias antigas da classe modificada não forem necessárias à fase de transformação, elas
podem ser previamente excluídas na fase de inicialização.
30
Além disso, a funcionalidade de evolução de esquemas permite a “reclassificação”,
uma forma especial de migração de instâncias, onde instâncias de uma classe são
reclassificadas para uma de suas subclasses. Esta reclassificação ocorre durante a fase de
transformação, juntamente com as instâncias migradas.
Para que o usuário tenha uma visão geral das operações envolvidas na inicialização de
instâncias dentro de uma evolução em particular, o relatório “lista de tarefas” descreve os
processos. A lista de tarefas consiste da definição das funções, indicando como as instâncias
migradas de cada classe serão inicializadas. Este relatório pode ser gerado sem que a evolução
seja efetivamente executada, permitindo ao usuário uma simulação dos efeitos de uma
modificação, antes mesmo da migração de dados (OBJECTDESIGN,1990).
2.1.5 - Quadro Resumo dos Aspectos de Correção nos SGBDOOs Estudados
A tabela 2.1 mostra, de forma resumida, os aspectos de correção do esquema, no que
se refere à integridade estrutural, à comportamental e a de instanciação adotadas pelos
SGBDOOs apresentados.
TABELA 2.1 - Aspectos
de correção do esquema nos SGBDOOs: O2, ORION, OBJECTSTORE
e GEMSTONE
O2
ORION
OBJECTSTORE
GEMSTONE
Integridade Estrutural
sim1
sim1
sim1
sim1
Integridade Comportamental
sim2
sim4
sim6
sim2
Integridade de Instanciação
sim3
sim5
sim7
sim8
31
(1)
A partir de primitivas de manipulação do esquema, baseadas na proposta de
(BANERJEE,1987);
(2)
As referências inválidas serão apenas informadas, ficando a avaliação e
alteração do código fonte sob a responsabilidade do usuário;
(3)
A partir de funções de conversão, assumidas pelo sistema ou definidas pelo
usuário, ambas disponibilizadas pelo sistema. O projetista pode selecionar a alternativa “lazy”
ou “immediate update”, conforme a mais adequada para aplicação;
(4)
Os métodos afetados pela modificação são invalidados. A herança conjunta
para métodos e atributos referenciados pelos métodos é condicionada nos casos de herança
múltipla;
(5)
A propagação das modificações é feita diretamente aos objetos instanciados
pela alternativa “lazy update”;
(6)
A avaliação e alteração do código fonte é responsabilidade do usuário. O
relatório “lista de tarefas” informa os efeitos da modificação;
(7)
A partir de funções de transformação responsáveis pela migração de instâncias
ocorrida em duas fases: inicialização e transformação. A alternativa é “immediate update”;
(8)
A alternativa é “immediate update”, a partir da migração automática
de
instâncias ou versionamento.
2.2 - EVOLUÇÃO DE ESQUEMAS UTILIZANDO VERSIONAMENTO
Existem dois aspectos a serem observados para modificações sobre um esquema
único. O primeiro é que o histórico dos objetos modificados não é preservado. Por exemplo,
se o atributo de uma classe é removido, os valores do atributo para as instâncias existentes são
32
irreversivelmente perdidos. Mesmo se este mesmo atributo for novamente adicionado será
tratado como um atributo novo e seus antigos valores não poderão ser mais vistos.
O outro aspecto é que em num ambiente multi-usuário, o impacto das modificações
efetuadas por um usuário afetam as outras visões do BD. Por exemplo, se um usuário
qualquer excluir um atributo de uma classe, ou modificar o relacionamento classe /
superclasse entre duas classes, todos os outros usuários verão estas modificações. Este
problema não é específico dos SGBDOOs, ocorrendo também para os SGBDRs. A solução
tradicional tem sido limitar o privilégio de fazer modificações de esquema ao ADB Administrador do BD, ou suportar visões sobre as relações armazenadas.
Versões de esquema solucionam estas limitações, através do versionamento dos
objetos e do esquema. O sistema gerencia mais de um esquema lógico para um único BD,
apresentando diferentes visões, através de diferentes versões do esquema. Por exemplo, para
remover um atributo de uma classe em uma versão do esquema, um usuário pode criar uma
nova versão que irá refletir esta modificação. Sob esta versão, o usuário não terá acesso aos
valores das instâncias existentes nas classes. Porém, se posteriormente o usuário alterar o
acesso à classe, através da versão prévia, disponibilizará todos os valores dos atributos para
todas as instâncias existentes, antes da criação da nova versão do esquema (KIM,1990).
Assim, o tratamento de evolução de esquemas por versionamento é utilizado para
compor objetos, retornar às situações anteriores e armazenar o histórico do desenvolvimento
do esquema, sem que seja necessário uma reorganização completa do BD e a interrupção do
funcionamento do sistema (CATTELL,1991) (FORNARI,1993) (GOLENDZINER,1993)
(GOLENDZINER,1995).
33
Versionamento em SGBDOOs podem grandemente simplificar aplicações que tenham
de manter múltiplas versões de dados. Sem esta funcionalidade, a própria aplicação teria de
implementar a semântica e manter explicitamente informações sobre as versões no BD.
A Figura 2.5 ilustra o histórico de versões para objetos hipotéticos X, Y e Z. A
configuração C representa um grupo de versões de objeto que são visões mutuamente
consistentes de um BD, outras tantas configurações podem ser definidas.
X3a
X1
X2
X4
X3b
Configuração C
Y1
Y2
Y3
Z3a
Z1
Z2a
Z3a
Z2b
FIGURA 2.5 - Histórico de versões para três objetos X, Y e Z em um BD
As novas versões de um objeto não precisam ser criadas estritamente em seqüência
linear. Podem-se criar novas versões de um objeto X1, X2, X3 e X4 seqüencialmente
modificando a última versão do objeto X, como também criar um ramo de versões X3a e X3b,
ambos derivados de X2. Essas versões podem, mais tarde, ser submetidas a uma versão
intercalada X4. Ramos de versões, isto é, duas ou mais novas versões, independentes de um
34
objeto, podem ser úteis em um ambiente de projeto, quando dois ou mais usuários devem,
independentemente, trabalhar em revisões que envolvam alguns dos mesmos objetos.
Eventualmente, os usuários devem intercalar seus trabalhos, isto é, criar uma versão
nova de um objeto que se sobreponha a esta separação de versões ramificadas, com o objetivo
de construir um projeto consistente. Portanto, o histórico de versões conterá pontos de
ramificação e de intercalação.
Todos os SGBDOOs com versionamento provêem mecanismos para examinar o
histórico das versões e devem permitir histórico de versões com ramificações e intercalação.
Em alguns sistemas, versões podem ser classificadas como transiente, de trabalho e
liberada. A versão transiente é promovida para versão de trabalho e torna-se visível para
outros usuários no final da sessão. E uma versão de trabalho é promovida a uma versão
liberada quando objetos são congelados para uso (GOLENDZINER,1993).
Versões podem também ser aplicadas para compor objetos, a partir da criação de
novas versões de um grupo de objetos. O SGBDOO deve também permitir versionamento do
próprio esquema, simplificando deste modo o tratamento de evolução de esquemas.
Configuração, uma facilidade adicional, é uma coleção de versões de objetos
mutuamente consistentes em um BD. Por exemplo, se atualizações são feitas para 20 módulos
de software para criar uma nova versão de um sistema operacional, então essas 20 novas
versões de objeto, mais as versões existentes de todos os outros módulos do sistema
operacional, representam uma configuração.
Existem duas alternativas para configurações em um SGBDOO:
(1)
O SGBDOO pode prover um mecanismo, mas não uma política para
gerenciamento de configurações, deixando o problema de gerenciamento de configurações ser
35
resolvido pelo usuário. Essa alternativa, por exemplo, é adotada pelo OBJECTIVITY/DB
(OBJECTIVITY,1990);
(2)
O SGBDOO pode implementar configurações automaticamente, com uma
política de opções especificadas pelo usuário. Essa alternativa é adotada pelo
OBJECTSTORE.
No primeiro caso, o SGBDOO deve prover um mecanismo suficiente para
implementar configurações em uma aplicação convenientemente. Por exemplo, em
OBJECTIVITY/DB, objetos compostos podem ser usados para representar configurações.
OBJECTIVITY/DB provê três opções de manutenção de versões para relacionamentos
entre objetos: “move, drop e copy”. Um atributo inverso, representando um relacionamento
em um objeto versionado, é acrescentado com uma das opções, quando uma nova versão do
objeto é criada, a ação correspondente é tomada.
(1) Move: a referência tem de ser movida para a nova versão do objeto, e deve ser
alterada para “nil” na versão antiga;
(2) Drop: a referência tem de permanecer com a versão antiga, e tem de ser alterada
para “nil” na nova versão; e
(3) Copy: as versões nova e antiga devem possuir a mesma referência.
Existem diferenças na funcionalidade provida pelos SGBDOOs. Por exemplo, ORION
provê somente “move e drop” semânticos para referência e VERSANT (VERSANT,1990)
não tem objetos compostos. No entanto, a filosofia geral destes sistemas é a mesma: usuários
definem seus próprios gerenciamentos de configurações sobre primitivas providas.
Uma alternativa para configurações é construir o gerenciamento dentro do SGBDOO.
Existem algumas formas pelas quais isto pode ser feito, dependendo da política de tratamento
36
para versões, referência ou “queries”. Provavelmente, a alternativa adotada pelo
OBJECTSTORE é a mais simples.
Configurações podem também ter outros usos, elas podem, por exemplo, ser usadas
como uma base para autorizar acessos às diferentes versões de dados, sem a preocupação de
serem providas pelo próprio SGBDOO ou de serem construídas pelo usuário
(CATTELL,1991).
Versões têm sido implementadas em produtos e protótipos, apesar de
diferirem largamente em suas semânticas. ORION, ITASCA, VERSANT, OBJECTSTORE,
OBJECTIVITY/DB, GEMSTONE e outros provêem esta funcionalidade.
Provavelmente, o controle de transações continuará a ser útil em seu objetivo de
recuperação, porém, a utilização de versões com propósito de controle de concorrência está
ganhando popularidade como uma alternativa para transações aninhadas e conversacionais. O
uso de múltiplas versões de objeto, permitindo coordenação entre múltiplos usuários e
diferentes cópias de objetos, tem recebido considerável atenção na literatura (PREVOT,1994)
(FORNARI,1993) (GOLENDZINER,1993) (GOLENDZINER,1995) (KIM,1990) (KATZ,
1990). Com o tempo, possivelmente, um conjunto de características para versões será
definido (CATTELL,1991).
37
CAPÍTULO 3
SIGO
3.1 - UMA VISÃO GERAL
SIGO (Sistema Gerenciador de Objetos) é um protótipo em desenvolvimento no
Instituto Militar de Engenharia - IME/RJ, concebido para suportar aplicações não
convencionais de BDs, provendo um conjunto de ferramentas, em um ambiente amigável e
integrado, para o usuário desenvolver suas aplicações (MOURAa,1995) (MOURAb,1995)
(BARROS,1996).
A Figura 3.1 representa a configuração do sistema em módulos cujas funcionalidades
serão descritas a seguir.
IN T E R F A C E
M A M E
L ID A S
L IM O S
M A CRO
E squ em a
G e re n c ia m e n to d e
O b je to s C o m p le x o s
O b je to s M u ltim íd ia
BD
S is te m a d e
H ip e rd o c u m e n to s
FIGURA 3.1 - Arquitetura do SIGO
38
C am pos
Longos
MAME (Módulo de Aquisição e Modelagem de Esquemas) (GUIMARÃES,1995) é o
módulo responsável pelo processo de modelagem de objetos do mundo real, a partir de uma
interface OO amigável. As classes e seus inter-relacionamentos são representados por um
modelo de rede semântica OO (XAVIER,1989) (ROSSETI,1991). Os usuários definem os
componentes estáticos a partir da composição dos tipos disponíveis no sistema, tais como:
classes, atributos de classes, restrições e índices; e os componentes dinâmicos: tais como
métodos e regras.
As instâncias são obtidas a partir das aplicações desenvolvidas. Anteriormente a este
trabalho, a manutenção de integridade à parte extensional ainda não era suportada, isto é, após
a criação da primeira instância para uma das classes da base, não havia mais possibilidade de
modificação do esquema definido. A manutenção de integridade do esquema conceitual é
mantida, dinamicamente, pelo sistema durante as operações de evolução.
Uma vez construído, o esquema é traduzido em código na linguagem C++, gerando,
automaticamente, métodos genéricos para a construção de classes, a recuperação e
manipulação dos objetos das classes, além de outros. Esta funcionalidade é atribuição do
módulo LIDAS (Linguagem para o Desenvolvimento de Aplicações), também responsável em
prover ao usuário um ambiente para o desenvolvimento de aplicações (ARAÚJO,1993).
MACRO (Módulo de Armazenamento, Criação e Recuperação de Objetos complexos)
corresponde ao gerenciador de objetos no sistema (FREITAS,1991). Ele trata do acesso e do
armazenamento dos objetos, mapeando-os para estruturas em disco e recuperando-os, quando
necessário, para memória principal. O MACRO inclui o Gerenciador de Objetos Multimídia,
que implementa estratégias de armazenamento específicas para campos longos (imagens,
vídeos, sons e textos) (LIMA,1993).
39
De modo a oferecer meios de consulta à base de objetos, o SIGO oferece, através do
módulo LIMOS (Linguagem Interativa para Manipulação de Objetos), uma linguagem de
consulta declarativa, do padrão SQL (COSTA,1992) (COLLYER,1996).
Finalmente, o sistema de hiperdocumentos (QUADROS,1996) é um módulo que
provê a habilidade de produzir hiperdocumentos construídos a partir de componentes do
esquema conceitual ou de componentes multimídia externos.
A interface apresentada na Figura 3.1 possui, de fato, um propósito bem mais amplo
do que a simples modelagem de esquemas realizada pelo MAME. Além da modelagem, são
agregadas as possibilidades de geração das definições em C++, através da chamada à LIDAS,
e acesso ao módulo de consultas interativas (LIMOS) estabelecendo, deste modo, um acesso
único às funcionalidades do sistema.
3.2 - MODELO DE OBJETOS E O ESQUEMA CONCEITUAL
O modelo de objetos no SIGO está fundamentado especificamente na rede semântica
MORSO (Modelo em Rede Semântica Orientada a Objetos) (ROSSETI,1991). Esta
representação é graficamente traduzida por um grafo acíclico orientado, constituído de nós
interligados por arcos. Este grafo expressa em uma parte a classificação e identificação
precisa destes nós e arcos (e eventualmente pelas suas restrições); e em outra parte a definição
de funções de manipulação associadas à rede. A quádrupla - (CN) categoria de nós; (CA)
categoria dos arcos (CR) categoria de restrições e (CO) categoria de operações - define o
modelo.
A Figura 3.2 mostra os componentes de um modelo de objetos através de um esquema
hierárquico, onde o arco g representa uma generalização, o arco a uma agregação e o arco c
40
uma classificação. Objetos no SIGO são tipados e associados a uma classe, sendo
representados por um par (identidade, valor). A classe agrupa objetos com as mesmas
propriedades (estrutura e operações), encapsulando dados e comportamento. Todas as classes
de usuários, definidas em um esquema conceitual, são uma subclasse da metaclasse
CLASSES, que agrupam toda a estrutura de classes no sistema. Cada classe criada no SIGO
possui um único nome e um único identificador “tipo surrogate” gerado pelo sistema.
O modelo prevê a possibilidade de criação de índices sobre os atributos e de restrições
de especialização, definidas obrigatoriamente em uma subclasse. Estas últimas associam uma
condição para um atributo, expressando que o objeto não pode ser criado, durante a
instanciação da subclasse, a menos que a condição seja satisfeita por um dos atributos
herdados.
a
arcos
a: agregação
g: generalização
c: classificação
mandatório
a
não mandatório
nome
restrições
único
não nulo
ambos
nenhuma
c
valor
intervalo
estado
a
a
a
a
tipo basico
g
a
c
valor
classe
a
restrições
características
a
a
a
operações
id
OBJETO
a
a
índices
a
g
c
imagem
som
texto
vídeo
int, real
data
bool
char
operações
construtor
primitivo
c
nome
c
tupla
lista
conj
FIGURA 3.2 - Definição de Objeto no SIGO
41
Similarmente, tipos primitivos e construtores são tipos básicos e representam o
principal componente das classes; além disso, são recursivamente usados para formar os
TAOs (Tipos Abstratos de Objetos). Cada tipo primitivo e construtor (conjunto, lista e tupla)
possui seu próprio grupo de operações. Tipos primitivos (inteiro, real, booleano e data)
possibilitam a inclusão de duas propriedades: características para definir se o atributo é
único (valores iguais não são permitidos), não nulo, ambos ou nenhum (sem características)
e restrições, que são diretamente aplicadas sobre o atributo e, quando necessário, são
concatenadas pelo operador “OU”. O usuário pode definir para um atributo um dos três tipos
de restrições: valor, intervalo e estado.
Os tipos longos também estão disponíveis no sistema e possuem uma lista de funções
intrínsecas, que possibilitam a captura e recuperação de objetos multimídia relativos à
imagem, ao som e ao texto.
A herança no SIGO é total, isto é, as subclasses herdam todas as propriedades de sua
susperclasses. O sistema suporta herança múltipla a partir de regras que resolvem o problema
de conflitos. Além disto, não é disponibilizada qualquer linguagem de definição de dados
específica, de forma que o esquema conceitual é construído a partir do MAME. Este módulo
provê uma valiosa interface que permite ao usuário especificar, explícita e interativamente, as
classes com seus respectivos atributos, métodos, restrições, índices e chaves.
A Figura 3.3 descreve uma aplicação simples - incluindo objetos multimídia representada no modelo de dados do SIGO e traduzida de acordo com a semântica específica.
PESSOA é a generalização de ESTUDANTE e de EMPREGADO (arco g). PESSOA é o
resultado da agregação de nome, foto (tipo imagem) e idade (arco a). Da mesma forma,
EMPREGADO é a agregação de matrícula, de salário, de categoria e de projetos (arco a) que,
42
por sua vez, é formado por uma lista de PROJETO (arco l). Os demais objetos seguem a
mesma semântica.
As Figuras 3.4, Figura 3.5 e Figura 3.6 apresentam alguns detalhes capturados pela
interface, referentes ao exemplo mostrado na Figura 3.3.
A classe EMPREG é selecionada e o atributo PROJETOS é criado. A classe
PROJETO é selecionada como elemento da lista PROJETOS, definida para o máximo de sete
elementos.
a
Categoria
Salário a
a
a
Matrícula
Foto
a
Nome
Idade
PESSOA
g
a
g
EMPREGADO Curso
a
g
Projetos
ESTUDANTE
a
ESTAGIÁRIO
l
PROJETO
Currículo
Categoria
a
a
a
g
Descrição
FIGURA 3.3 - Exemplo de uma aplicação SIGO
Observa-se, no entanto, que os atributos definidos na classe aparecem em letras
maiúsculas e aqueles que foram herdados de uma superclasse em letras minúsculas.
43
FIGURA 3.4 - Seleção da Classe EMPREG e criação do atributo PROJETOS
FIGURA 3.5 - Seleção da Classe PROJETO como elemento da Lista PROJETOS
44
FIGURA 3.6 - Definição da Lista PROJETOS para o máximo de 7 elementos
A manipulação de objetos pode ser feita de duas formas. Primeiro, pela linguagem de
consulta LIMOS e, nesse caso, o encapsulamento de objetos não é preservado e, segundo,
pelo ambiente de programação LIDAS, descrito no item 3.5, que preserva o encapsulamento
(MOURAb,1995).
3.3 - EVOLUÇÃO DE ESQUEMAS
O processo de evolução de esquemas está intimamente ligado ao modelo conceitual de
objetos e inclui alguns aspectos importantes referentes à consistência intencional e extensional
do BD, bem como aos mecanismos que garantem sua integridade. O capítulo 1 descreve de
forma mais detalhada todos estes aspectos e outros conceitos utilizados adiante.
45
Para garantia da integridade estrutural foram definidas algumas invariantes
determinadas de acordo com o modelo de dados do sistema (GUIMARÃES,1995), seguindo a
taxonomia proposta em (BANERJEE,1987). As invariantes, descritas a seguir, determinam as
condições que devem ser satisfeitas para que o esquema seja considerado correto. Deste
modo, constituem parâmetros de comparação que devem ser verificados durante a realização
de cada modificação:
(1)
O grafo que representa o esquema é composto por nós (classes) nomeados e
arcos (conjunto, lista, generalização, etc.) rotulados; ele é acíclico, direcionado, e conexo, isto
é, todas as classes são obrigatoriamente descendentes da metaclasse oferecida pelo sistema;
(2)
Dentro do esquema, todas as classes possuem nomes distintos e, dentro de
cada classe, os nomes das propriedades herdadas ou definidas são necessariamente distintos;
(3)
Todas as propriedades de uma classe possuem origem conhecida, de maneira a
evitar a replicação de propriedades, caso estas sejam herdadas a partir de uma mesma origem
e através de diferentes caminhos;
(4)
Em qualquer caso, uma subclasse herda todas as propriedades de suas
superclasses. Caso se contrarie a propriedade invariante número 2, é observado o previsto na
propriedade número 3, onde ocorrerão conflitos de herança.
O sistema prevê também, para garantir a correção do esquema ao longo da ocorrência
de alterações, um conjunto de regras de manutenção do esquema.
Com base nestas regras foi definido um conjunto de operações para modificação do
esquema. Em (GUIMARÃES,1995) estas operações são descritas detalhadamente, juntamente
com as regras a serem aplicadas para manutenção da integridade estrutural e comportamental
do BD.
46
A integridade comportamental é mantida para os métodos gerados automaticamente
pelo sistema, visto que todos aqueles pertencentes às classes cujas propriedades sofreram
modificação são regerados pela LIDAS (ARAÚJO,1993). Quanto aos demais métodos, cabe
ao usuário a responsabilidade de modificação.
A exemplo de outros SGBDs e anteriormente a este trabalho o SIGO não permitia, até
então, que o esquema fosse modificado uma vez que a base houvesse sido instanciada. Os
capítulos 4 e 5 descrevem as alternativas e mecanismos utilizados para manutenção da
integridade de instanciação, principal objetivo deste trabalho.
3.4 - PERSISTÊNCIA DE OBJETOS
A arquitetura SIGO está baseada no modelo relacional estendido para armazenamento
de objetos. Neste modelo classes e tipos construtores são vistos como objetos, possuem um
identificador tipo “surrogate” e são mapeadas diretamente como relações (ou tabelas). As
ligações entre as classes e as suas superclasses são fisicamente implementadas por seus
identificadores, isto é, o identificador da superclasse é repetido em suas subclasses. Junções
são requeridas para agrupar partes de uma instância oriunda de várias classes. Os atributos
herdados das superclasses são armazenados nas tabelas correspondentes às classes onde foram
definidos. Os subobjetos ou objetos compostos são representados no objeto principal por seus
identificadores e, conseqüentemente, são armazenados na classe tabela a qual pertencem.
A Figura 3.7 mostra um exemplo de tabelas geradas a partir de um esquema conceitual
de uma aplicação. PESSOA é superclasse de EMPREGADO, que é uma agregação dos
atributos: nome, identidade, foto (tipo imagem) e uma lista de dependentes (tipo PESSOA).
47
EMPREGADO é uma agregação de: nível, salário e departamento. DEPARTAMENTO é
constituído por: número e nome do departamento e uma lista de empregados.
Ident
Foto
a
a
Nome
a
Depend
PESSOA
a
g
Nível
a
Salário
a
EMPREGADO
NumDepto
l
a
a
DEPARTAMENTO
NomeDepto
a
PESSOA (Id_Pessoa, Ident, Nome, Id_Foto, Id_Lista_Depend)
DEPARTAMENTO (Id_Depto, NumDepto, NomeDepto, Id_Lista_Emp)
EMPREGADO (Id_Empregado, Nível, Salário)
LISTA_DEPENDENTES (Id_Lista_Depend, Id_Pessoa)
LISTA_EMPREGADOS (Id_Lista_Emp, Id_Empregado)
FIGURA 3.7 - Tabelas representando um esquema conceitual
É importante observar que apesar do atributo “Departamento” ter sido definido no
projeto conceitual, ele não é fisicamente implementado na relação EMPREGADO. Isto
acontece para evitar redundância, como também é o caso da lista de empregados definida na
classe DEPARTAMENTO. O esquema gerou cinco tabelas, conforme as classes descritas no
modelo. Listas e conjuntos também possuem identificadores do tipo surrogate, e são
48
representados de forma similar às classes. Cada tabela de tuplas corresponde a uma lista ou
conjunto de elementos, seguido do identificador de objeto de cada classe ao qual pertencem.
A ordem em uma
lista é definida por um índice secundário, cuja chave é o
identificador da lista. Elementos da mesma lista possuem o mesmo identificador na tupla.
Armazenamento de conjuntos acontece de forma similar, exceto pela ordenação por índice
que não existe.
Os atributos multimídia são representados por seus identificadores de objetos, criados
por uma classe associada a cada mídia. Lista e conjuntos de campos longos (imagem, som,
vídeo e texto) são construídos da mesma forma acima descrita. No exemplo da Figura 3.7 o
Id_Foto é criado pela classe IMAGEM, sempre que um objeto PESSOA é criado.
Além disso, um objeto no SIGO pode ser representado de duas formas: na memória
principal, no mesmo formato de objetos em C++, e na memória secundária, mapeado em
tabelas de acordo com o exemplo mostrado na Figura 3.7. As operações de mapeamento de
objetos entre a memória principal e a memória secundária são feitas através da técnica
“swizzling” (MOSS,1992), que transforma cada identificador em um ponteiro e vice-versa.
As rotinas de acesso as tabelas são feitas através de chamadas para uma camada intermediária
do sistema de armazenamento, que interage diretamente com as funções do PARADOX
ENGINE (BORLAND,1992).
Outro aspecto importante a ser ressaltado é que a persistência de objetos é totalmente
transparente aos usuários. Suas aplicações enxergam os objetos apenas em seu formato C++
(MOURAb,1995).
O processo de mapeamento do esquema conceitual para o C++, bem como seu uso
será descrito a seguir no item 3.5.
49
3.5 - AMBIENTE DE PROGRAMAÇÃO
A Figura 3.8 representa o ambiente de desenvolvimento de aplicações.
Após a definição do esquema conceitual pelo usuário através do módulo MAME, o
módulo LIDAS gera um conjunto de métodos em C++. Estes constituem o conjunto de
operadores à disposição do usuário, provendo a possibilidade de criação e manipulação de
objetos através de programas C++. O arquivo DEFS.H contém, não somente a definição do
esquema da classe em C++, mas também os métodos básicos associados que são
automaticamente gerados para criação, recuperação, exclusão, manipulação e persistência de
objetos. Desta forma, os usuários podem desenvolver suas aplicações através da ativação
destes métodos, sem se preocuparem com suas implementações. Na realidade, estas
definições representam o mapeamento do esquema em estruturas de classes que expressam o
ambiente de aplicações no SIGO.
Adicionalmente, existe uma classe COLEÇÃO para cada classe criada no esquema,
com o propósito de gerenciar as instâncias das classes. Os objetos criados e aqueles existentes
na memória principal são grupados na classe OBJETO. A classe OBJETO é transparente para
o usuário e é superclasse de todas as instâncias da classe no sistema SIGO. Através desta
classe, todos os identificadores são criados e associados aos objetos correspondentes. Os
atributos do tipo conjunto e lista não são incluídos no construtor da classe. Os objetos são
criados com suas listas e conjuntos inicialmente vazios. O processo de instanciação de listas e
conjuntos é feito após a criação do objeto principal. Todo objeto - do tipo lista ou conjunto possui as classes genéricas LISTA ou CONJUNTO, respectivamente, como superclasse. Estas
classes são intrínsecas à estrutura de classes do SIGO e possuem seus próprios métodos
(operações básicas de listas e conjuntos).
50
Quando ocorre o acesso às funções MACRO no processo de persistência, os índices
definidos pelo usuário são atualizados automaticamente com seus novos valores.
MAME
USUÁRIO
LIDAS
MACRO
DEFS.H
(classes e métodos
em C++)
APLICAÇÃO
FIGURA 3.8 - Ambiente de desenvolvimento de aplicações
Durante a especificação do processo de instanciação e recuperação, o principal
problema é a necessidade de fragmentação do objeto C++ em vários registros para serem
mapeados nas respectivas tabelas. Conseqüentemente, no processo de recuperação o problema
é o oposto, ou seja, recuperar o registro físico e construir um objeto C++. Isto é resolvido
porque um objeto C++ possui suas implementações de dados encapsuladas. Assim alguns
métodos foram criados pelo módulo LIDAS buscando acessar individualmente, para cada
classe do esquema conceitual, os valores dos atributos. O usuário necessita apenas dos
métodos de manipulação das classes e suas coleções.
Uma classe específica contém os métodos básicos para instanciar e recuperar objetos
multimídia (som, imagem, texto e vídeo). Estes métodos podem ser utilizados no
51
desenvolvimento de aplicações e são armazenados em estrutura separada no módulo MACRO
como mostrado na Figura 3.1.
52
CAPÍTULO 4
USO DE REGRAS ATIVAS NO TRATAMENTO DE EVOLUÇÃO DE ESQUEMAS
NO SIGO
4.1 - ASPECTOS DE REGRAS ATIVAS
Com o objetivo de garantir a integridade de instanciação do esquema da aplicação no
SIGO, buscou-se aproveitar os conceitos de regras nos BDs Ativos (WIDOM,1996)
(TANAKA,1995) (CERI,1994). Para isto, as efetivas modificações sobre o esquema são
armazenadas numa hierarquia de classes, juntamente com métodos definidos como regras
ativas, responsáveis pela propagação destas modificações aos objetos instanciados. Estas
regras, por sua vez, são automaticamente ativadas por métodos das aplicações que
referenciam objetos e classes durante a manipulação do esquema.
4.1.1 - Uma Visão Geral
BDs Ativos são sistemas com toda a funcionalidade dos BDs convencionais,
estendidos para incluir regras ativas. Regras ativas são estruturas capazes de detectar a
ocorrência de eventos, monitorar condições especificadas sobre o estado do BD e executar
algumas ações, independentemente, de qualquer solicitação externa ao sistema.
Recentemente, sua utilização tem sido estendida além das funcionalidades internas dos
BDs, e aplicadas a uma variedade de problemas, tais como: controle de tráfego aéreo,
planejamento de operações militares, controle de processos e de produção, gerência de redes,
monitoração em hospitais, bolsa de valores, monitoração de objetos móveis, monitoração do
53
meio ambiente, engenharia de software, automação de escritórios, trabalho cooperativo e
outros. Além disso, constituem um mecanismo natural para reforçar a restrição de integridade,
verificação de autorização, manutenção de dados derivados, e etc.
Na realidade, regras de BDs Ativos são estruturas definidas pelos usuários e
aplicações para especificação de um comportamento ativo desejado. Em sua forma mais geral,
estas regras, são constituídas de três partes (EVENTO / CONDIÇÃO / AÇÃO (ECA)) e
suas semânticas de execução são as seguintes:
(1) EVENTO
Especifica o que causa o disparo da regra (“triggered”). Os eventos de disparos
podem ser dos seguintes tipos:
•
Modificação de dados: um evento de modificação de dados pode ser especificado
como uma criação, exclusão ou modificação de um objeto particular, ou qualquer
objeto em uma classe particular. Também pode ser especificado como uma
chamada a um método particular que modifica objetos;
•
Recuperação de dados: um evento de recuperação de dados pode ser especificado
como uma busca a um objeto, ou como chamada a um método particular que
recupera objetos;
•
Tempo: um evento temporal pode especificar que uma regra deve ser disparada em
um tempo absoluto (ex: “26 abr 96 às 09:00h”), em um tempo repetido (ex: “todo
dia às 12:00h”), ou em intervalos periódicos (ex: “a cada dez minutos”); e
•
Definido por aplicação: eventos definidos por aplicações podem ser especificados,
permitindo que uma aplicação declare seus próprios eventos (ex: “temperatura
muito alta” ou “motor principal parou”). Portanto, uma aplicação pode notificar ao
54
sistema de BD a ocorrência de um evento, disparando deste modo todas as regras
associadas.
Estes exemplos são de eventos simples. Eventos também podem ser compostos, isto é,
combinações de eventos simples ou outros eventos compostos. Para combinação de eventos
são usados operadores lógicos, seqüência ou composições temporais. Eventos compostos
muito complexos são possíveis se uma linguagem de especificação de eventos for baseada em
expressões regulares, ou numa gramática livre de contexto.
(2) CONDIÇÃO
Especifica uma condição adicional a ser verificada, uma vez que uma regra é
disparada antes da ação ser executada. As condições podem ser dos seguintes tipos:
•
Predicados do BD: a condição pode especificar um predicado simples ou
composto por operações lógicas, relativo ao estado do BD (ex: “quantidade de
estoque menor que 10”);
•
Consultas do BD: a condição pode especificar uma consulta a partir de uma
linguagem de consulta do SGBD. Por exemplo, uma condição especificada como
uma consulta para recuperar todos os dados, cujos valores estão abaixo de certo
limite, expressando a condição verdadeira para execução da ação. Como
predicados, as condições, que são consultas, podem usar uma linguagem restrita
para garantir uma avaliação eficiente; e
•
Procedimentos de aplicações: a condição pode ser especificada como uma
chamada a um procedimento escrito, em uma linguagem de programação de
aplicação (ex: “máximo_excedido ( )”), onde o procedimento pode ou não acessar
o BD. Este procedimento retorna uma condição “verdadeira” ou “falsa”
determinando as ações a serem executadas sobre o BD.
55
Em todos esses casos, se a linguagem de regras permite eventos parametrizados, então
a linguagem de condição, provavelmente, incluirá um mecanismo para referenciar o valor
ligado aos parâmetros dos eventos.
(3) AÇÃO
Em uma regra de BD Ativo, a ação é executada quando a regra é disparada e o
resultado de sua condição é verdadeiro. As ações podem ser dos seguintes tipos:
•
Operações de modificações de dados: são ações que especificam a criação ou
exclusão de objetos;
•
Operações de recuperação de dados: são ações que especificam a busca de objetos;
•
Outros comandos de BD: adicionalmente para operações de recuperação e
modificação de dados. Muitos sistemas de BD suportam operações para definição
de dados, operações para controle de transações (ex: “commit”, “roolback”) e
operações para conceder e revogar privilégios, etc.;
•
Procedimentos de aplicações: a ação da regra pode ser especificada como uma
chamada a um procedimento escrito em uma linguagem de programação de
aplicação, onde o procedimento pode ou não acessar o BD.
Se a linguagem de regras permitir valores a serem passados da condição para ação,
então a linguagem de ação, provavelmente, incluirá um mecanismo para referenciar estes
valores. Algumas linguagens de regras de BDs Ativos permitem que uma regra especifique
um conjunto de ações, usualmente com uma ordenação, de forma que múltiplas ações sejam
seqüencialmente executadas (CERI,1994) (WIDOM,1996).
As pesquisas na área de BDs Ativos estão divididas em tecnologias baseadas em BDs
Relacionais e em BDOOs. Estes últimos também estão sendo estendidos com a capacidade de
56
regras ativas. Além disso, estas pesquisas têm caminhado no sentido de prover métodos e
ferramentas de projeto que facilitem o uso efetivo desta tecnologia (CERI,1994).
4.1.2 - Semântica de Regras Ativas
O paradigma geral usado por todos os SGBDs Ativos é o seguinte:
Uma vez que um conjunto de regras é definido, o SGBD Ativo monitora os eventos
relevantes e, para cada evento ocorrido, armazena a(s) regra(s) correspondente(s) num “pool”
de regras disparadas. Há um processo de escolha da regra a ser tratada e, uma vez escolhida a
regra, o SGBD avalia a condição da regra. Se sua condição for verdadeira, a ação da regra é
executada. Este algoritmo é mostrado na Figura 4.1.
ENQUANTO existirem regras disparadas FAÇA
1. Encontre uma regra disparada R
2. Avalie a condição de R
3. SE a condição de R é verdadeira
ENTÃO execute a ação de R
FIGURA 4.1 - Algoritmo para o processamento de regras
O algoritmo para o processamento de regras mostrado na Figura 4.1 caracteriza um
simples modelo de execução iterativo de regras, no qual estas são selecionadas e processadas
uma de cada vez. Este modelo não considera:
57
(1) O processamento recursivo das regras, em que a ação de uma regra pode causar um
evento que dispara outra regra; e
(2) A interação entre as transações “ordinárias” do BD e aquelas geradas pela ação das
regras.
Estes dois aspectos do processamento de regras são problemas importantes a serem
cobertos pela pesquisa de BDs Ativos, já que tanto o processamento recursivo, quanto à
interação transações/regras, podem levar a um comportamento consideravelmente diferente
do simples processamento iterativo (TANAKA,1995).
4.1.3 - Seleção da Regra e o Modo de Acoplamento
A maioria do BDs Ativos permite que várias regras sejam disparadas ao mesmo
tempo. Conseqüentemente, um processo de seleção sobre o conjunto de regras disparadas,
pode tornar-se necessário. Este processo é similar à resolução de conflitos utilizada em
linguagens de IA. Existem numerosas possibilidades para resolução de conflitos; a mais
simples consiste em deixar a escolha aleatória para o próprio sistema, o que introduz um grau
não determinístico total no processo. Geralmente, a regra é escolhida com base em prioridades
especificadas na definição da regra, no caso de regras com igual prioridade, o sistema utiliza a
seleção aleatória.
O controle sobre a execução das regras disparadas acomoda o conceito de modos
distintos de acoplamento, que especificam o relacionamento entre o evento disparador da
regra e a avaliação da condição, ou entre esta e a execução da ação. Os seguintes modos de
acoplamento são possíveis:
•
Imediato
58
A avaliação da condição (ou a execução da ação) ocorre imediatamente quando,
dentro da transação, o evento é sinalizado (ou a condição é avaliada como verdadeira);
•
Retardado
A avaliação da condição (ou a execução da ação) é adiada até o ponto de término da
transação, mas antes que a transação termine (“commit”);
•
Desacoplado, mas dependente da causa
A avaliação da condição (ou a execução da ação) ocorre depois do ponto de término
da transação (“commit”). Se o término da transação não ocorre, a condição não é avaliada (ou
a ação não é executada);
•
Desacoplado, mas independente da causa
A avaliação da condição (ou a execução da ação) é feita numa transação separada. Ela
é realizada, independentemente, do término ou não da transação original.
Os modos de acoplamento dependem de outro aspecto importante do processamento
de regras: a granularidade da mudança de estado do BD, que deve ser considerada na
execução das regras (TANAKA,1995) (CERI,1994). Este aspecto será visto a seguir.
4.1.4 - Granularidade do Processamento de Regras Ativas
A granularidade do processamento de regras especifica com que freqüência ocorrem
pontos nos quais as regras podem ser processadas, isto é, com que freqüência o algoritmo da
Figura 4.1 é chamado. Três níveis úteis de granularidade são os seguintes:
Cada ocorrência de uma operação trivial do BD (ex: em um SGBDR Ativo, pode
corresponder às operações de inserção, exclusão, ou alteração de uma tupla);
59
Começo ou fim de uma operação coletiva do BD (ex: o fim de todas as sentenças SQL
para inserção, exclusão ou alteração de várias tuplas); e
•
Fim de uma transação.
A execução de regras em BD Ativos é dita “orientada à instâncias” se a regra é
executada uma vez para cada instância do BD que dispara a regra, ou que satisfaça às suas
condições. Por outro lado, a execução é “orientada a conjunto”, se a regra é executada uma
vez para todas as instâncias que disparam a regra, ou que satisfaçam às suas condições.
É possível observar que as questões de execução orientada à instância, versus
orientada a conjunto podem ser relacionadas com a granularidade para o processamento de
regras (WIDOM,1996).
4.1.5 - Arquiteturas e Técnicas para Monitoramento de Condições
Existem basicamente duas abordagens para lidar com regras e tornar ativo um BD
passivo. A primeira é executar, através de um programa de aplicação especial, uma sondagem
(“polling”) periódica do BD para determinar a ocorrência de uma situação monitorada e, em
caso positivo, desencadear a ação correspondente. A principal deficiência desta abordagem é
que o programa de aplicação não sabe quando, exatamente, deve realizar a sondagem, porque
desconhece as mudanças de estado do BD. Em conseqüência, ele tem de sondar em intervalos
regulares, se os intervalos são muito longos, o programa pode perder algumas situações
críticas em que deveria reagir, se são muito curtos, ele pode inundar o sistema com consultas
que, invariavelmente, retornam respostas negativas, causando degradação do sistema. A outra
abordagem é inserir, nos programas de aplicação normais que modificam o BD, o código
específico para verificar a condição monitorada e desencadear a ação correspondente, no caso
60
da situação ser verdadeira. A deficiência desta abordagem é a falta de modularidade de
software, isto é, quando a situação, ou regra, precisa ser alterada por alguma razão, todas as
aplicações que modificam o BD terão de ser também alteradas.
A P L IC A Ç Ã O
U S U Á R IO / A P L IC A Ç Ã O
O O / R e la c io n a l (p a s s iv o )
+
G e re n cia m e n to d e T ra n sa çõ e s E s te n d id o
G e re n cia m e n to d e R e g ra s (E C A ):
• D e te c çã o e p ro c e ss a m e n to d e E V E N T O S
• M o n ito ra m e n to d e C O N D IÇ Õ E S
S u p o rte à c o m u n ic a ç ã o e n tre a p lic a ç õ e s
BD
BD
FIGURA 4.2 - Arquitetura Integrada para BDs Ativos
O objetivo principal da pesquisa em BDs Ativos tem sido obter respostas apropriadas
a situações pré-especificadas sem sacrificar a modularidade do software. Os BDs Ativos
tendem a realizar isto através de um modelo de conhecimento, em que as regras ECA são
especificadas num nível de abstração, com uma semântica bem definida e dentro de um
modelo de execução em que a monitoração de situações, isto é, os eventos, as condições, e o
desencadeamento das ações decorrentes, sejam feitos sem a intervenção dos usuários ou das
aplicações.
61
Outro aspecto a considerar é a arquitetura dos sistemas de BDs Ativos. Embora, seja
compreensível que a maioria dos esforços de pesquisa e de desenvolvimento nesta área
tenham optado por uma arquitetura integrada, em que uma funcionalidade ativa plena é
incorporada ao núcleo de um SGBD. A Figura 4.2 ilustra esta arquitetura.
A P L IC A Ç Ã O
C A M A D A D A A P L IC A Ç Ã O
In te rfa ce d o U s u á rio
A rm a z e n a m e n to , A n á lise , T ra d u çã o
M o n ito r / In te rfa ce co m S G B D
In te rfa ce d o
U su á rio
(O p cio n a l)
C a m a d a d o M o n ito r d e S itu a ç ã o
SG BD
(N ã o -A tiv o )
BD
FIGURA 4.3 - Arquitetura de Camadas para BDs Ativos
Do ponto de vista prático, é improvável que SGBDs não ativos atualmente usados
sejam substituídos por sistemas ativos num futuro próximo. Com o objetivo de atender a
necessidade da funcionalidade ativa nas novas aplicações, uma arquitetura em camadas como
mostra a Figura 4.3 pode exercer um papel significativo na migração entre os SGBDs atuais e
os sistemas que têm, ou terão, alguma funcionalidade ativa. O acesso ao sistema pode ser feito
através de uma ferramenta que transforma o projeto de BD Ativo em construções de
62
linguagens, ou através de uma interface acoplada à camada ativa. Todas as aplicações que
requeiram capacidade ativa têm de interagir com o sistema através desta camada
(CHAKRAVARTHY,1992) (TANAKA,1995).
O presente trabalho, implementa uma arquitetura integrada para incorporação e
emprego de regras ativas no processo de evolução dinâmica de esquemas. A propagação dos
efeitos das modificações sobre métodos e instâncias são descritos no item 4.2 a seguir.
4.2 - EFEITOS DAS MODIFICAÇÕES DO ESQUEMA SOBRE OS OBJETOS E
MÉTODOS
As modificações dinâmicas nos esquemas são capturadas através de um conjunto de
operações que atuam sobre o esquema, caracterizando assim sua evolução. Além das
operações executadas diretamente sobre os objetos instanciados, esse conjunto de operações
pode ser classificado basicamente em duas categorias: operações sobre os atributos e métodos
e operações sobre as classes (MORSI,1992).
As operações de evolução de esquemas sobre os atributos, métodos e classes
modificam o conjunto de características a estes associadas.
Para cada esquema de BD criado, o SIGO mantém identificadores de objetos (Id_Obj)
associados às suas classes e aos objetos correspondentes. Estes objetos são manipulados,
conseqüentemente, à propagação das operações sobre o esquema.
As operações de evolução de esquema habilitam o usuário a modificar o esquema do
BD, podendo resultar na criação, na retirada ou na modificação dos objetos instanciados.
Estas operações podem ainda tornar inconsistentes os métodos existentes, ou por erros de
63
execução, ou por estados indesejados para os objetos, haja vista a ocorrência de uma das
seguintes condições:
(1) Referência a uma classe inexistente;
(2) Referência a um objeto inexistente;
(3) Referência a um método inexistente;
(4) Referência a um método existente com parâmetros incompatíveis;
Para o tratamento destas inconsistências, três alternativas podem ser adotadas: a
primeira seria rejeitar todas as modificações que invalidassem as assinaturas dos métodos ou
suas implementações. A segunda alternativa seria propagar, automaticamente, os efeitos das
modificações sobre as referências aos atributos, às classes, aos objetos e aos métodos nas
assinaturas, ou nas implementações dos métodos inconsistentes. Para isto, deve ser mantida
uma estrutura de gerenciamento em todas as referências às definições implementadas no
esquema do BD. Na terceira alternativa, todas as operações são aceitas e as inconsistências,
temporariamente, admitidas. Neste caso, a responsabilidade de manipulação dos métodos
inconsistentes recai sobre o usuário, embora o sistema possa fornecer algum tipo de
ferramenta de auxílio para este tratamento. Esta alternativa é mais flexível que as outras,
tendo em vista
que o objetivo das operações de evolução de esquemas é suportar as
modificações sobre uma hierarquia de classes (MORSI,1992).
Neste trabalho são adotadas, basicamente, a segunda e terceira alternativas. No
conjunto de métodos inconsistentes, aqueles que são gerados automaticamente pelo sistema
são regerados pela LIDAS. A responsabilidade de reavaliar e corrigir os outros métodos
específicos, definidos no contexto de uma aplicação, cabe ao usuário. Neste caso, o mesmo
recebe, como forma de auxílio, todas as informações sobre as modificações ocorridas para a
classe na qual o método foi definido.
64
Portanto, a consistência do BD não pode ser garantida apenas pelos seus componentes
estruturais, mas também pelos seus componentes comportamentais (métodos).
Em (GUIMARÃES,1995) foram tratados os aspectos dinâmicos de um esquema no
SIGO, inerentes à integridade estrutural. Estes foram definidos de forma coerente com a ótica
do modelo utilizado (XAVIER,1989). Para isto, foram especificadas algumas propriedades
invariantes, e a maneira como é feita a manutenção da integridade da parte intencional do
esquema, frente a ocorrência de alterações em suas definições.
Porém, a capacidade de evolução envolve tanto a manutenção das instâncias, quanto à
manutenção dos métodos criados sobre as classes, a despeito das alterações introduzidas na
definição do esquema.
Reiterando a descrição do capítulo 3, anteriormente a este trabalho e a exemplo de
outros SGBDOOs, o SIGO ainda não suportava a manutenção de integridade da parte
extensional, isto é, após a criação da primeira instância de uma das classes da base não era
mais possível modificar o esquema definido.
Os efeitos das modificações previstas sobre os métodos e objetos instanciados no
SIGO serão descritos adiante.
4.2.1 - Modificações de Atributos
As operações de evolução de esquemas sobre atributos habilitam o usuário a modificar
quaisquer propriedades de um atributo. As propriedades de um atributo incluem:
1.
Nome
2.
Classe de origem
3.
Tipo de domínio (primitivo, construtor, classe ou longo)
65
4.
Atributo de relacionamento
5.
Mecanismo de indexação
6.
Contador de referências
7.
Restrições de acesso
8.
Restrições e características sobre o atributo
As características de um atributo são estendidas para incluir propriedades e restrições
físicas, tais como: índices, relacionamentos, restrições e contadores de referências.
As operações de evolução de esquemas sobre os atributos suportam o acréscimo, e a
remoção, bem como habilitam o usuário a modificar as características acima mencionadas:
1.
Acrescentar um atributo à classe
Esta operação habilita o usuário a definir um atributo adicional em uma classe. Este
será incluído no conjunto de atributos da classe especificada, bem como em suas subclasses.
nom e
a
d t_ n a sc
a
a
P e ss o a
g
F u n c io n á rio
a
se x o
e n d e re ç o
g
(0 1 0 2 )
a
a
d a ta _ a d m issã o
m a tr_ fu n c
A lu n o
a
m a tr_ a lu n o
a
d a ta _ m a tr
(0 5 )
(0 3 0 4 )
FIGURA 4.4 - Inclusão do atributo dt_nasc para a classe Pessoa
Efeitos sobre os objetos
66
Cada objeto na extensão da classe e respectivas subclasses será acrescido de um valor
para o atributo recentemente especificado. O valor inicial deste atributo pode ser constante ou
nulo, se nenhum valor for especificado. O exemplo mostrado na Figura 4.4 ilustra o efeito
desta operação. O esquema do BD mostra a inclusão do atributo dt_nasc para a classe Pessoa.
Este atributo é incluído para objetos 01 e 02 da classe Pessoa, bem como para os objetos 03 e
04 da classe Funcionário e 05 da classe Aluno.
Efeitos sobre os métodos
Podem ocorrer inconsistências temporárias, ou erros de execução para os métodos
definidos nas aplicações dos usuários, caso o atributo acrescido, ou métodos correspondentes,
ainda não tenham sido gerados automaticamente pela LIDAS (item 3.5). O usuário será
informado desta situação.
2.
Remover um atributo da classe
Esta operação resulta em remover o atributo especificado de sua classe de origem e
suas subclasses.
a
a
a
dt_nasc
nome
Pessoa
g
(0 1 0 2)
a
Funcionário
a
a
sexo
endereço
g
data_admissão
matr_func
Aluno
a
matr_aluno
a
data_matr
(0 5 )
(0 3 0 4 )
FIGURA 4.5 - Exclusão do atributo dt_nasc da classe Pessoa
67
Cada objeto, na extensão da classe e respectivas subclasses, perde o valor associado ao
atributo removido. O exemplo mostrado na Figura 4.5 ilustra o efeito desta operação. O
esquema do BD mostra a exclusão do atributo dt_nasc da classe Pessoa. Este atributo é
excluído dos objetos 01 e 02 da classe Pessoa, bem como dos objetos 03 e 04 da classe
Funcionário e 05 da classe Aluno.
Os métodos existentes que referenciem os atributos removidos tornam-se inválidos, a
exemplo dos métodos construtores e destrutores de classe. O usuário será informado desta
situação.
3.
Renomear um atributo da classe
Esta operação habilita o usuário a modificar o nome de um atributo.
Esta operação não tem efeito sobre os objetos na extensão da classe e subclasses. No
entanto, em conseqüência das limitações impostas pelo modelo de armazenamento utilizado
no sistema (BORLAND,1992), a classe do atributo modificado é recriada com o atributo
renomeado.
O resultado desta operação é similar ao resultado da operação (2) para os métodos que
referenciem os atributos renomeados. O usuário será informado desta situação.
4.
Modificar o domínio de um atributo da classe
Esta operação habilita o usuário a modificar o domínio de um atributo.
68
a
d t_ n asc
n om e
sexo
end ereço
a
a
a
P esso a
g
a
F uncion ário
(0 3 0 4 )
g
(0 1 0 2 )
d ata_ adm issão
m atr_ fu nc
a
a p rojeto (ch ar)
A lu no
a
m atr_alu no
a
data_ m atr
(0 5 )
l
a
P ro jeto
a
cod _ projeto
n o m e_ projeto
(0 6 0 7 )
FIGURA 4.6 - Modificação do domínio do atributo projeto da classe Funcionário
Como resultado desta operação, os objetos na extensão da classe e subclasses são
acrescidos dos valores correspondentes ao novo domínio do atributo especificado. No caso de
atributos que referenciem objetos, através do seu identificador (Id_Obj do tipo “surrogate”),
cada objeto na extensão da classe recebe um valor nulo para o atributo modificado, cabendo
ao usuário, a atualização destes valores pela aplicação. Caso a modificação de domínio seja de
uma classe para outra e se a classe correspondente ao novo domínio for subclasse ou
superclasse da classe domínio de origem, os objetos mantêm seus valores. Para um atributo
baseado-em-valor, a conversão precisa ser explicitamente especificada. Similarmente à
operação (1), se um valor não for especificado, os objetos na extensão da classe recebem um
valor nulo para o atributo modificado. Estas modificações obedecem aos critérios
69
estabelecidos na Tabela de Conversões Possíveis de Domínio apresentada na Tabela 5.1 do
capítulo 5.
O exemplo mostrado na Figura 4.6 ilustra o efeito desta operação. O esquema do BD
mostra a modificação do domínio do atributo projeto da classe Funcionário de caractere para
lista, permitindo que um funcionário participe de vários projetos. Os objetos 03 e 04 recebem
valores nulos e serão modificados pela aplicação.
O resultado desta operação é similar ao resultado da operação (2) para os métodos que
referenciem os atributos que tiveram seus domínios modificados. O usuário será informado
desta situação.
5.
Modificar a restrição de um atributo da classe
Esta operação permite que o usuário modifique uma das restrições que tenha sido
definida para um atributo da classe. Estas restrições foram descritas no item 3.2.
Como resultado desta operação, os objetos na extensão da classe e subclasses obtêm
um novo valor para o atributo especificado. Os objetos mantêm seus valores se estes
satisfizerem a nova restrição, caso contrário, um novo valor para conversão precisa ser
explicitamente especificado pelo usuário. Similarmente à operação (1), se um valor não for
especificado, os objetos na extensão da classe recebem um valor nulo para o atributo, cuja
restrição foi modificada. Estas modificações obedecem aos critérios estabelecidos na Tabela
de Modificações Possíveis de Restrições apresentada na Tabela 5.2 do capítulo 5. O exemplo
mostrado na Figura 4.7 ilustra o efeito desta operação. O esquema do BD mostra uma
modificação de restrição de valor sobre atributo salário da classe Funcionário, onde todos os
70
salários devem ser maiores que 100 (salário > 100). Esses valores são modificados para os
objetos 03 e 04, quando estes forem referenciados por algum método da aplicação, caso não
satisfaçam a nova restrição.
Esta operação não tem efeito sobre os métodos definidos para as classes.
a
dt_nasc
no m e
a
a
Pessoa
g
Funcionário
sexo
en dereço
a
g
(0 1 0 2 )
a
a
a
(0 3 0 4 )
data_adm issão
A luno
m atr_func
a
m atr_ alu no
a
data_m atr
sa lário
R estrição:
salário > 100
(0 5 )
FIGURA 4.7 - Modificação de restrição sobre atributo salário da classe Funcionário
6.
Modificar a característica de um atributo da classe
Esta operação permite que o usuário modifique uma das características que tenha sido
definida para um atributo da classe. Estas características foram descritas no item 3.2.
Como resultado desta operação, os objetos na extensão da classe e subclasses têm seus
valores atualizados conforme a característica modificada. Os objetos mantêm seus valores se
estes valores satisfizerem a nova característica, caso contrário, um novo valor para conversão
precisa ser explicitamente especificado pelo usuário. Estas modificações obedecem aos
critérios estabelecidos na Tabela de Modificações Possíveis de Características apresentada
71
na Tabela 5.3 do capítulo 5. O exemplo mostrado na Figura 4.8 ilustra o efeito desta operação.
O esquema do BD mostra uma modificação de característica para não nulo, sobre o atributo
endereço da classe Pessoa. Os objetos 01 e 02 se forem nulos, recebem estes valores quando
forem referenciados por algum método da aplicação.
a
dt_ nasc
no m e
a
a
a
P esso a
g
F u ncio nário
g
(0 1 0 2 )
a
a
a
se xo
en dere ço
C aracterístic a:
n ão n u lo
da ta _ad m issão
A lun o
m atr_fu nc
a
m a tr_ aluno
a
da ta _m atr
sa lá rio
(0 5 )
(0 3 0 4 )
FIGURA 4.8 - Modificação de característica sobre o atributo endereço da classe Pessoa
7.
Acrescentar um índice à classe
Esta operação habilita o usuário a criar um índice para a classe especificada. Como
resultado desta operação, é criada uma estrutura de índice sobre os objetos na extensão da
classe e suas subclasses especificadas, conforme o(s) atributo(s) definidos como índice.
Esta operação não tem efeito sobre os objetos na extensão da classe e subclasses.
72
8.
Retirar um índice da classe
Esta operação habilita o usuário a remover a estrutura de índice criada para a classe
especificada.
9.
Modificar o nome do índice de uma classe
Esta operação habilita o usuário a modificar o nome de um índice da classe
especificada. Como resultado desta operação, devido as estruturas de acesso e armazenamento
utilizadas no sistema (BORLAND,1992), o índice modificado é removido. Em seguida, é
criado um índice com o novo nome, para o(s) mesmo(s) atributo(s) definido(s) no índice
removido, sobre os objetos na extensão da classe especificada e suas subclasses. Este
resultado é similar à conjunção das operações (7) e (8), respectivamente.
10.
Acrescentar um atributo ao índice de uma classe
Esta operação habilita o usuário a acrescentar um atributo à estrutura de um índice
existente, para classe especificada. O resultado desta operação é similar ao resultado da
operação (9).
73
11.
Retirar um atributo do índice de uma classe
Esta operação habilita o usuário a remover um atributo da estrutura de um índice
existente, referente a uma classe especificada. O resultado desta operação é similar ao
resultado da operação (9).
4.2.2 - Modificações de Classes
As operações de evolução de esquemas sobre uma classe habilitam o usuário a
modificar qualquer propriedade de uma classe. As propriedades de uma classe incluem:
1.
Nome
2.
Conjunto de superclasses
3.
Conjunto de subclasses
4.
Um conjunto ordenado de atributos
5.
Restrições e características sobre os atributos
6.
Indexadores de classes
74
Algumas características foram mencionadas apenas porque são referenciadas nos
métodos de modificação de classe. Além disso, as operações de modificação habilitam o
usuário a modificar uma ou mais propriedades de uma classe:
12.
Tornar uma classe S superclasse de uma classe S1
Esta operação permite ao usuário tornar uma classe S em superclasse de uma classe
S1, podendo resultar em atributos e métodos adicionais, herdados da classe S pela classe S1.
nom e
a
dt_nasc
a
a
Pessoa
g
a
sexo
endereço
g
(0 1 0 2 )
a
Funcionário
(0 3 0 4 )
data_adm issão g
a m atr_func
a departam ento
dt_nasc
a
nom e a
a
sexo
endereço
A luno
m atr_aluno
a
data_m atr
(0 5 )
a
Professor
a
a
titulação
(0 6 0 7 )
FIGURA 4.9 - Inclusão da classe Pessoa como superclasse da classe Professor
Os objetos na extensão da classe S1 recebem um valor nulo para cada atributo herdado
da classe S. Os valores para estes atributos herdados serão definidos similarmente a operação
(1).
75
O exemplo mostrado na Figura 4.9 ilustra o efeito desta operação. O esquema do BD
mostra a inclusão da classe Pessoa como superclasse da classe Professor. Os atributos
dt_nasc, nome, sexo, endereço da classe Pessoa são incluídos para os objetos 06 e 07 da
classe Professor.
Esta operação não tem efeito sobre os métodos definidos para as classes S e S1.
13.
Remover uma classe S da lista de superclasses de uma classe S1
Esta operação permite ao usuário remover uma classe S da lista de superclasses de
uma classe S1, podendo resultar em atributos ou métodos perdidos pela classe S1. O efeito é
inverso ao da operação (12) descrita anteriormente.
nom e
a
a
dt_nasc
a
Pessoa
g
g
(0 1 0 2 )
a
Funcionário
(0 3 0 4 )
sexo
a endereço
data_adm issão g
a m atr_func
a departam ento
Aluno
a
m atr_aluno
a
data_m atr
(0 5 )
dt_nasc
a
nom e a
sexo a
endereço
a
Professor
a
titulação
(0 6 0 7 )
FIGURA 4.10 - Retirada da classe Pessoa da lista de superclasses da classe Professor
76
O efeito desta operação sobre os objetos na extensão da classe S1 é similar ao da
operação (2), para os atributos herdados da classe S. O exemplo mostrado na Figura 4.10
ilustra o efeito desta operação. O esquema do BD mostra a retirada da classe Pessoa da lista
de superclasses da classe Professor. Os atributos dt_nasc, nome, sexo, endereço da classe
Pessoa são removidos dos objetos 06 e 07 da classe Professor.
Podem ocorrer inconsistências temporárias, ou erros de execução, para os métodos
definidos nas aplicações dos usuários que referenciem os métodos, ou atributos herdados da
classe S e foram perdidos pela classe S1. O usuário será informado desta situação.
14.
Criar uma nova classe no esquema
Esta operação habilita o usuário a definir novas classes para o esquema do BD na
hierarquia de classes.
15.
Retirar uma classe no esquema
Esta operação habilita o usuário a retirar uma classe do esquema do BD na hierarquia
de classes. O efeito é inverso ao da operação (14). Convém lembrar que, de acordo com as
regras associadas aos métodos para manutenção das invariantes do esquema (item 3.3), uma
classe somente é removida se estiver desconectada do esquema.
77
Esta operação resulta na exclusão dos objetos existentes na extensão da classe retirada.
O exemplo mostrado na Figura 4.11 ilustra o efeito desta operação. O exemplo mostra a
retirada da classe Funcionário do esquema do BD. Os objetos 03 e 04 são excluídos.
O resultado desta operação é similar ao resultado da operação (13) para os métodos
que referenciem os atributos ou métodos da classe removida. O usuário será informado desta
situação.
nome
a
dt_nasc
a
a
Pessoa
g
(0 1 0 2)
g
a
Funcionário
sexo
a endereço
data_admissão
a matr_func
a departamento
Aluno
a
matr_aluno
a
data_matr
(0 5)
(0 3 0 4)
FIGURA 4.11 - Retirada da classe Funcionário do esquema do BD
16.
Modificar o nome de uma classe
Esta operação permite que o usuário modifique o nome de uma classe no esquema do
BD.
78
Esta operação não tem efeito sobre os objetos na extensão da classe e subclasses. No
entanto, em conseqüência das limitações impostas pelo modelo de armazenamento utilizado
no sistema (BORLAND,1992), a classe renomeada é recriada.
4.2.3 - Modificações de Objetos
A modificação dinâmica de objetos abrange a exclusão de um objeto, inclusão de um
novo objeto e modificação de um objeto instanciado. Com este propósito, algumas operações
foram definidas nos módulos MACRO e LIDAS (MOURAa,1995) (MOURAb,1995).
A operação descrita a seguir modifica a classe de origem de um objeto.
17. Migrar um objeto de uma classe origem O para uma classe destino D
Esta operação habilita o usuário a modificar a classe origem de um objeto
especificado, com as seguintes restrições: nenhum objeto que esteja sendo referenciado
poderá migrar para outra classe; a classe destino deverá ser uma subclasse da classe origem
independentemente de seu nível na hierarquia de classes; e a classe destino deverá possuir, no
mínimo, uma superclasse em comum com a classe origem.
O efeito desta operação é similar à exclusão e inclusão de um objeto, embora os
objetos afetados mantenham seus Id_Obj. Os objetos migrados retêm seus valores, recebem
um valor inicial constante, ou podem ser nulos se nenhum valor for especificado. O mesmo
tratamento é dado aos novos atributos oriundos da classe destino, herdados pelo efeito da
79
migração. Outrossim, os objetos perdem todos aqueles atributos, anteriormente herdados na
classe de origem, e que não pertençam à hierarquia da classe destino. O exemplo mostrado na
Figura 4.12 ilustra o efeito desta operação. O esquema do BD mostra a migração do objeto 04
da classe Funcionário para a classe Aluno. Serão perdidos os valores dos atributos
data_admissão, matr_func e salário da classe origem Funcionário e acrescidos valores para
os atributos matr_aluno e data_matr da classe destino Aluno. O objeto 04 mantém seu
Id_Obj.
a
dt_nasc
a
a
Pessoa
g
Funcionário
nom e
a
g
(0 1 0 2 )
a
a
a
sexo
endereço
data_admissão
matr_func
Aluno
a
m atr_aluno
a
data_matr
salário
(0 4 ) (0 5 )
(0 3 0 4 )
FIGURA 4.12 - Migração do objeto 04 da classe Funcionário para a classe Aluno
4.2.4 - Modificações de Métodos
As operações de evolução de esquemas sobre os métodos suportam o acréscimo, a
remoção, bem como habilitam o usuário a modificar o nome de um método:
80
18. Acrescentar um método à classe
Esta operação habilita o usuário a definir um método adicional para uma classe, que é
incluído no conjunto de métodos da classe especificada, bem como em suas subclasses.
19. Remover um método da classe
Esta operação resulta em remover um método especificado de sua classe de origem e
suas subclasses.
Efeitos sobre os Métodos
que referenciem o método removido. O usuário será informado desta situação.
20. Renomear um método da classe
Esta operação resulta em renomear um método especificado de sua classe de origem e
de suas subclasses.
Efeitos sobre os Métodos
81
que referenciem o método renomeado. O usuário será informado desta situação.
4.3 - ESPECIFICAÇÃO DAS ALTERNATIVAS E MECANISMOS UTILIZADOS
PARA EVOLUÇÃO DA BASE DE OBJETOS
O principal objetivo deste trabalho é garantir a integridade de instanciação do esquema
da aplicação, através da utilização de regras de BDs Ativos. Observa-se, no entanto, que esta
especificação trata objetos complexos não contemplando os objetos multimídia. Estes últimos
possuem armazenamento, acesso e gerenciamento próprios (QUADROS,1996), como pode
ser visto na Figura 4.13. As alternativas e mecanismos utilizados para obtenção deste
resultado serão descritos a seguir.
IN T E R F A C E
M AM E
L ID A S
L IM O S
E v o lu çã o d in â m ica d e
E s q u e m a s e O b je to s
M ACRO
E sq u em a
O b je to s C o m p le x o s
O b je to s M u ltim íd ia
R e g ra s
A tiv a s
BD
S is te m a d e
H ip e rd o c u m e n to s
C am pos
Longos
FIGURA 4.13 - Arquitetura do SIGO com suporte à evolução da base de objetos
82
As efetivas modificações sobre o esquema da aplicação são armazenadas numa
hierarquia de classes denominada Repositório de Regras Ativas Orientado a Objetos (R2O2),
e, conseqüentemente, propagadas aos objetos instanciados, podendo resultar na criação,
retirada ou modificação destes objetos. O R2O2 é descrito adiante no item 4.3.3.
A propagação aos objetos instanciados é feita através de métodos associados às classes
do R2O2. Estes métodos são definidos como regras ativas, automaticamente disparadas por
outros métodos pertencentes às aplicações, que referenciem objetos e classes durante a
manipulação do esquema. A Figura 4.13 representa a arquitetura do SIGO, acrescida dos
módulos de suporte à evolução da base de objetos, estes são responsáveis por tornar o sistema
ativo para esta funcionalidade.
4.3.1 - Semântica de Regras Ativas no SIGO
A partir do paradigma ECA, o suporte à evolução da base de objetos no SIGO é
viabilizado mediante o seguinte desenvolvimento:
•
Especificação das regras ativas referentes às modificações de objetos;
•
Associação das regras ativas criadas com suas classes no R2O2 ;
•
Armazenamento das efetivas modificações sobre o esquema da aplicação no
R2O2, a partir de um arquivo gerado pelo MAME, com todas as modificações
sobre o esquema da aplicação efetuadas pelo usuário. A estrutura e todas as
características do arquivo com as modificações estão descritas no Apêndice A;
•
Geração dos métodos básicos de atualização, ou recuperação dos objetos das
classes da aplicação pela LIDAS, com chamada ao método de varredura do R2O2,
para verificação da existência de modificações não propagadas;
83
•
A manutenção de instâncias executada no momento da propagação é feita de
forma “immediate update” ou “lazy update”, conforme foram descritas no capítulo
2. Estas são acionadas conforme a operação de modificação executada. Quando as
operações afetam diretamente a estrutura de armazenamento do objeto em disco,
as efetivas atualizações de objetos de uma classe são propagadas imediatamente a
todos os objetos. Caso contrário, cada objeto será posteriormente atualizado, no
momento em que forem referenciados pela ativação de qualquer método de
atualização, ou de recuperação, pertencentes às classes da aplicação. Esta diferença
de tratamento deve-se às limitações do modelo relacional disponibilizado pelo
PARADOX ENGINE (BORLAND,1992), que é adotado pelo SIGO como
estrutura de armazenamento.
A Figura 4.14 ilustra a semântica de execução de regras ativas, através do algoritmo
para processamento de regras, adaptado ao contexto do SIGO.
ENQUANTO existirem chamadas a métodos de atualização ou recuperação de objetos
FAÇA
1. Encontre uma regra disparada R (chamada a um método de atualização ou
recuperação de objetos);
2. Avalie a condição de R (objeto referenciado pertence ao conjunto de classes que
possuem modificações ainda não propagadas);
3. SE a condição de R é verdadeira
ENTÃO execute a ação de R (modificar efetivamente o objeto, conforme ação
definida);
FIGURA 4.14 - Algoritmo para processamento de regras no SIGO
84
4.3.2 - Aderência Conceitual ao Modelo de Execução de Regras em BDs Ativos
O item 4.1 descreve as diferentes alternativas para implementação dos principais
aspectos de regras ativas. Serão descritas a seguir aquelas que foram consideradas mais
adequadas e adotadas para o SIGO, no tratamento de evolução de esquemas pelo uso desta
tecnologia:
•
O item 4.3.1 mostra a semântica de execução de regras ativas no contexto do
SIGO, pelo paradigma ECA. De acordo com o algoritmo mostrado na Figura 4.14,
o modelo de execução para o processamento das regras ativas é iterativo e sem
recursividade;
•
A modificação e recuperação de dados foram escolhidas dentre os tipos de
eventos de disparos, isto é, a ativação de um dos métodos de atualização, ou de
recuperação pertencentes às classes de aplicação é, de fato, o EVENTO que
dispara as REGRAS DE AÇÃO armazenadas no R2O2;
•
A consulta do BD foi adotada como tipo de condição especificada, isto é, pela
ativação do método de varredura do R2O2, são avaliadas as CONDIÇÕES da
regra disparada, ou seja, se aquele objeto referenciado pertence ao conjunto de
classes que possuem modificações ainda não propagadas. Além disso, a chamada
ao método de varredura do R2O2 foi inserida nos programas de aplicação que
manipulam o BD para sondagem da situação monitorada. Esta inserção é feita
automaticamente pela LIDAS;
•
Se a CONDIÇÃO for verdadeira, o objeto é efetivamente modificado conforme a
AÇÃO definida pela regra disparada, caracterizando a execução da regra pelo tipo
operações de modificações de dados;
85
•
Visto que as regras são disparadas e executadas seqüencialmente, não é necessário
o tratamento para seleção e resolução de conflitos;
•
O modo de acoplamento imediato é adotado para o controle de execução das
regras disparadas;
•
As regras são executadas a cada ocorrência de uma operação trivial do BD
(chamada a um método de atualização ou recuperação de objetos), caracterizando
o nível de granularidade utilizado. Esta execução é orientada à instâncias ou a
conjunto, dependendo do tipo de operação de modificação que incorpora a regra
disparada, conforme o efeito sobre a estrutura de armazenamento do objeto
descrito no item 4.3.1.
4.3.3 - O Repositório de Regras Ativas Orientado a Objetos (R2O2)
As Figuras 4.15 e 4.16 mostram, conceitualmente, a estrutura de classes referente ao
Repositório de Regras Ativas Orientado a Objetos (R2O2). Estas classes possuem como
propriedades: as regras de ação definidas como métodos; e os atributos referentes às
modificações executadas sobre o esquema da aplicação. Estas modificações correspondem às
instâncias das classes na estrutura e serão propagadas sobre os métodos e objetos. As regras
de ação, quando disparadas, propagarão os efeitos das modificações ocorridas aos objetos do
esquema. Para cada uma das operações de modificação especificadas no item 4.2, existe uma
classe com seus respectivos atributos e métodos.
Além disso, o R2O2 é extensível, isto é, novas subclasses podem ser criadas. Esta
extensibilidade permite incorporar à estrutura outras operações de modificação, ou mesmo
outras regras de ação que venham a ser definidas (SILVA,1996).
86
As classes e atributos do R2O2 são descritos a seguir:
REPREGRAS: classe Repositório de Regras Ativas Orientado
a Objetos cujos
atributos são herdados por suas subclasses para propagação dos efeitos das operações aos
objetos instanciados;
REPREGRAS
Base (char)
Tipo_Evolução (char)
Operação (char)
Classe (char)
Lidas (bool)
Propagação (bool)
Objetos (set)
int Instancia Rep_Regras (alt.txt)
int Condição Rep_Regras (base, classe, id_obj, tipo_evol, operação)
RR1OBJ
Valor (char)
Atributo (char)
Domínio (char)
Tamanho (int)
Característica (char)
Restrição (char)
int Insere_Atributo (valor,
atributo, domínio, tamanho,
caracteristica, restrição )
RR2OBJ
RR4OBJ
Valor (char)
Atributo (char)
Novo_Domínio(char)
Novo_Tamanho_Atrib (int)
int Modifica_Dom(atributo,
valor, novo_dom, novo_tam)
RR7OBJ
Nome_Índice (char)
Atributos (set)
Nome_Índice (char)
Atributos (set)
int Insere_Indice
(nome_ind, atributos)
int Insere_Atributo_Indice
(nome_ind, atributo)
RR8OBJ
RR5OBJ
Atributo (char)
Nova_Restrição (char)
Nome_Índice (char)
int Retira_Indice (nome_ind )
RR3OBJ
int Modifica_Rest (atributo,
nova_rest)
RR6OBJ
Atributo (char )
Novo_Nome_Atrib (char )
Atributo (char)
Nova_Característica (char)
int Renomeia_Atributo
(atributo, novo_nome )
int Modifica_Carac (atributo,
nova_carac)
RR9OBJ
Nome_Índice (char)
Nome_Índice _Atual (char)
Atributos (set)
int Modifica_Nome_Indice
(nome_ind, nome_ind_atual,
atributos)
RR13OBJ
Superclasse (char)
int Remove_Superclasse
(superclasse)
RR15OBJ
RR11OBJ
Nome_Índice (char)
Atributos (set)
int Retira_Atributo_Indice
(nome_ind, atributo)
Atributo (char)
int Exclui_Atributo (atributo )
RR10OBJ
RR12OBJ
Superclasse (char)
int Insere_Superclasse
(superclasse)
int Retira_Classe (classe)
RR16OBJ
Novo_Nome_Classe (char)
int Modifica_Nome_Classe
(classe, novo_nome_classe)
RR17OBJ
Classe_Destino (char)
Id_Obj (double)
int Migrar_Objeto (id_obj)
FIGURA 4.15 - Hierarquia de classes do R2O2 para operações sobre objetos
Base (char): base modificada;
Tipo_Evolução (char): determina se a operação propaga efeitos sobre métodos, objetos
ou ambos (m/o/a);
87
Operação (char): operação de modificação (1 a 20);
Classe (char): classe sobre a qual foi operada a modificação;
Lidas (bool): atributo lógico que determina se o código C++ foi gerado pela LIDAS
após a modificação;
Propagação (bool): atributo lógico que determina se houve propagação para todos os
objetos da classe;
Objetos (set): conjunto de identificadores de objetos (id_obj) instanciados no
momento da modificação. Tem por finalidade controlar a propagação das operações “lazy
update”. Os objetos que ainda não foram atualizados permanecem no conjunto, enquanto que
os outros são retirados após suas atualizações.
RR1OBJ: subclasse para tratamento dos efeitos da operação (1) sobre objetos;
88
RR1MET: subclasse para tratamento dos efeitos da operação (1) sobre métodos;
RR20MET: subclasse para tratamento dos efeitos da operação (20) sobre métodos.
As classes referentes às operações (14) e (18) não foram definidas visto que, nestes
casos, não existem efeitos à serem propagados tanto para objetos, quanto para métodos.
A seguir serão descritos os atributos pertencentes a uma classe ou a um conjunto de
classes:
Atributo (char): atributo modificado, inserido ou excluído da classe;
Atributos (set): conjunto de atributos pertencentes ao índice inserido ou modificado;
Característica_Atributo (char): característica do atributo inserido na classe;
Classe_Destino (char): classe destino do objeto migrado;
Domínio_Atributo (char): domínio do atributo inserido;
Id_Obj (double): identificador do objeto migrado de classe;
Método (char): método removido ou renomeado;
Nome_Índice
(char) : nome do índice inserido, excluído ou modificado;
Nome_Índice_Atual (char) : novo nome do índice renomeado;
Nova_Característica (char): nova característica para o atributo modificado na classe;
89
Nova_Restrição (char): nova restrição para o atributo modificado na classe;
Novo_domínio (char): novo domínio para o atributo modificado na classe;
Novo_Nome_Atributo (char): novo nome do atributo renomeado;
Novo_Nome_Classe (char): novo nome da classe renomeada;
Novo_Nome_Método (char): novo nome do método renomeado;
Novo_Tamanho_Atributo (int): novo tamanho para o atributo modificado na classe;
Restrições_Atributo (char): restrições do atributo inserido na classe;
Superclasse (char): superclasse inserida ou removida da classe;
Tamanho_Atributo (int): tamanho do atributo inserido na classe;
Valor (char): valor constante definido pelo usuário, assumido para todos os objetos
quando o atributo é inserido, ou nos casos necessários da modificação;
REPREGRAS
Base (char)
Tipo_Evolução (char)
Operação (char)
Classe (char)
Lidas (bool)
Propagação (bool)
Objetos (set)
int Instancia Rep_Regras (alt.txt)
int Condição Rep_Regras (base, classe, id_obj, tipo_evol, operação)
RR1MET
Atributo (char)
int Insere_Atributo (classe )
int Exclui_Atributo (classe)
int Retira_Classe (classe)
Valor (char)
Atributo (char)
Novo_Domínio (char)
Atributo (char)
Novo_Nome_Atributo (char)
Atributo (char)
RR15MET
RR4MET
RR3MET
RR2MET
int Renomeia_Atributo (classe)
RR19MET
int Modifica_Dom (classe)
RR13MET
Superclasse (char)
int Remove_Superclasse
(classe)
RR20MET
Método (char)
Novo_Nome_Método (char)
Método (char)
int Remove_Método (classe)
int Renomeia_Método (classe )
FIGURA 4.16 - Hierarquia de classes do R2O2 para operações sobre métodos
90
CAPÍTULO 5
DESCRIÇÃO FUNCIONAL DOS MÉTODOS E FUNÇÕES
5.1 - OPERAÇÕES DE MODIFICAÇÃO SOBRE OBJETOS E MÉTODOS
A seguir, serão descritas as funcionalidades de métodos e funções utilizadas para
propagar os efeitos das modificações, sobre os objetos instanciados num esquema SIGO.
1.
Acrescentar um atributo à classe
Int Insere_atributo (classe, atributo, domínio, valor)
Descrição: insere um atributo na classe informada como parâmetro e em todos os seus
objetos, com valor especificado, ou nulo, conforme o caso.
Entradas:
classe: classe do atributo inserido;
Atributo: atributo inserido;
domínio: domínio do atributo inserido;
valor: valor para atualização do objeto, que pode ser nulo;
Saída:
retorna o inteiro 1, caso a operação tenha sido efetuada com sucesso e
0 (zero), caso algum erro tenha ocorrido.
Especificação Funcional:
INÍCIO (Int Insere_atributo)
ENQUANTO existirem acréscimos de atributos para a classe no R2O2 FAÇA
INSERIR o atributo na classe
ENQUANTO existirem objetos na classe FAÇA
91
INSERIR um valor do atributo acrescentado para cada objeto da
classe
FIM-ENQUANTO
ATUALIZAR o controle de objetos modificados na lista de Id_Obj
ATUALIZAR o atributo propagação na classe REPREGRAS
FIM-ENQUANTO
FIM (Int Insere_atributo)
2.
Remover um atributo da classe
Int Exclui_atributo (classe, atributo)
Descrição: remove um atributo da classe informada como parâmetro, bem como de
todos os seus objetos.
Entrada:
classe: classe do atributo excluído;
atributo: atributo excluído;
Saída:
INÍCIO (Int Exclui_atributo)
ENQUANTO existirem exclusões de atributos para a classe no R2O2 FAÇA
EXCLUIR o atributo da classe
EXCLUIR o valor do atributo removido para cada objeto da classe
FIM-ENQUANTO
92
FIM-ENQUANTO
FIM (Int Exclui_atributo)
3.
Renomear um atributo da classe
Int Renomeia_atributo (classe, atributo, novo_nome_atributo)
Descrição: renomeia um atributo na classe informada como parâmetro. Esta operação
não tem efeito sobre os objetos na extensão da classe e subclasses. No entanto, em
conseqüência das limitações impostas pelo modelo de armazenamento, conforme foi descrito
no subitem 4.3.1, a classe modificada é recriada com o atributo renomeado.
Entradas:
classe: classe do atributo renomeado;
atributo: atributo renomeado;
novo_nome_atributo: novo nome atributo do atributo renomeado;
Saída:
INÍCIO (Int Renomeia_atributo)
ENQUANTO existirem renomeações de atributos para a classe no R2O2 FAÇA
RENOMEAR o atributo na classe
FIM-ENQUANTO
FIM (Int Renomeia_atributo)
93
4.
Modificar o domínio de um atributo da classe
Int Modifica_dom_atributo (classe, atributo, novo_dom, valor)
Descrição: modifica o domínio de um atributo na classe informada como parâmetro e
em todos os seus objetos, convertendo o valor existente, assumindo o valor especificado, ou
nulo, conforme o caso.
Entradas:
classe: classe do atributo modificado;
atributo: atributo modificado;
novo_dom: novo domínio para conversão;
valor: valor para modificação de domínio de objeto, que pode ser nulo;
Saída:
INÍCIO (Modifica_dom_atributo)
ENQUANTO existirem modificações de domínio de atributos da classe no R2O2
FAÇA
SE o atributo for baseado-em-objeto (Id_Obj) e os valores existentes
satisfazem o novo domínio previsto em novo_dom ENTÃO
CASO
(1):
SE a modificação for de classe para classe E a classe novo
domínio for subclasse ou superclasse da classe domínio
ENTÃO: manter o valores existentes FIM-SE
(2):
SE a modificação for de lista para conjunto ENTÃO: manter
os valores existentes e remover as instâncias repetidas FIM-SE
94
(3):
SE a modificação for de conjunto para lista ENTÃO: manter
e ordenar os valores existentes FIM-SE
OUTROS:
ATRIBUIR valor nulo para o atributo
modificado em cada objeto da classe
FIM-ENQUANTO
FIM-CASO
SENÃO {atributo for baseado-em-valor}
VERIFICAR conversões permitidas conforme Tabela de conversões
possíveis de domínio (Tabela 5.1)
MODIFICAR o domínio do atributo para novo_dom
CONVERTER para o novo domínio o valor do atributo
modificado de cada objeto da classe, usando o próprio
valor existente no objeto, ou valor, conforme o caso
FIM-ENQUANTO
FIM-SE
FIM-ENQUANTO
FIM (Modifica_dom_atributo)
5.
Modificar a restrição de um atributo da classe
Int Modifica_rest_atributo (classe, atributo, Id_Obj, nova_rest)
95
Descrição: modifica as restrições de um atributo da classe informada como parâmetro,
assumindo o valor, especificado pelo usuário, para cada objeto existente que for referenciado
por algum método da aplicação e que não satisfaça a nova restrição.
Entradas:
classe: classe do atributo cuja restrição foi modificada;
atributo: atributo cuja restrição foi modificada;
Id_Obj: identificador do objeto referenciado;
nova_rest: nova restrição para conversão;
Saída:
INÍCIO (Modifica_rest_atributo)
OBTER o objeto Id_Obj da classe classe
ENQUANTO existirem modificações de restrição da classe no R2O2 FAÇA
SE o valor do objeto (Id_Obj) satisfaz a nova_rest ENTÃO
manter o valor existente
SENÃO
VERIFICAR conversões permitidas conforme Tabela de modificações
possíveis de restrições (Tabela 5.2)
EXIBIR ao usuário “O VALOR DO OBJETO (Id_Obj) ESTÁ
INCONSISTENTE COM A NOVA RESTRIÇÃO ESTABELECIDA.
INFORME O NOVO VALOR PARA MODIFICAÇÃO “
OBTER o novo valor
96
MODIFICAR valor do objeto (Id_Obj)
FIM-SE
FIM-ENQUANTO
FIM (Modifica_rest_atributo)
6.
Modificar a característica de um atributo da classe
Int Modifica_carac_atributo (classe, atributo, Id_Obj, nova_carac)
Descrição: modifica a característica de um atributo da classe informada como
parâmetro, assumindo o valor, especificado pelo usuário, para cada objeto existente que for
referenciado por algum método da aplicação e que não satisfaça a nova característica.
Entradas:
classe: classe do atributo cuja característica foi modificada;
atributo: atributo cuja característica foi modificada;
Id_Obj: identificador do objeto referenciado;
nova_carac: nova restrição para conversão;
Saída:
INÍCIO (Modifica_carac_atributo)
OBTER o objeto Id_Obj da classe classe
ENQUANTO existirem modificações de características da classe no R2O2 FAÇA
97
SE o valor do objeto (Id_Obj) satisfaz a nova_carac ENTÃO
manter o valor existente
SENÃO
VERIFICAR conversões permitidas conforme Tabela de modificações
possíveis de características (Tabela 5.3)
EXIBIR ao usuário “O VALOR DO OBJETO (Id_Obj) ESTÁ
INCONSISTENTE COM A NOVA CARACTERÍSTICA
ESTABELECIDA. INFORME O NOVO VALOR PARA
MODIFICAÇÃO ”
OBTER o novo valor
MODIFICAR valor do objeto (Id_Obj)
FIM-SE
FIM-ENQUANTO
FIM (Modifica_carac_atributo)
7.
Acrescentar um índice numa classe
Int Insere_indice (classe, nome_indice, *atributos)
Descrição: cria um índice para a classe informada como parâmetro. Esta operação não
tem efeito sobre os objetos na extensão da classe e subclasses.
Entradas:
classe: classe do índice inserido;
nome_indice: nome do índice inserido;
*atributos: lista de atributos componentes do índice;
98
Saída:
INÍCIO (Insere_indice)
ENQUANTO existirem inserções de índices para classe no R2O2 FAÇA
CRIAR índice para classe com atributos especificados
CARREGAR estrutura de ordenação com objetos existentes
FIM-ENQUANTO
FIM (Insere_indice)
8.
Retirar um índice da classe
Int Retira_indice (classe, nome_indice)
Descrição: retira um índice da classe informada como parâmetro. Esta operação não
tem efeito sobre os objetos na extensão da classe e subclasses.
Entradas:
classe: classe do índice retirado;
nome_indice: nome do índice retirado;
Saída:
INÍCIO (Retira_indice)
ENQUANTO existirem retiradas de índices para classe no R2O2 FAÇA
REMOVER índice para classe
99
FIM-ENQUANTO
FIM (Retira_indice)
9.
Modificar o nome de um índice de uma classe
Int Modifica_nome_indice (classe, nome_indice, nome_indice_atual)
Descrição: modifica o nome de um índice da classe informada como parâmetro. Esta
operação não tem efeito sobre os objetos na extensão da classe e subclasses. No entanto, em
conseqüência das limitações impostas pelas estruturas de acesso e armazenamento utilizadas
no sistema (BORLAND,1992), o índice modificado é removido. Em seguida, é criado um
índice com o novo nome, para o(s) mesmo(s) o(s) atributo(s) definido(s) no índice removido,
sobre os objetos na extensão da classe especificada e suas subclasses.
Entradas:
classe: classe do índice modificado;
nome_indice: nome do índice modificado;
nome_indice_atual: novo nome do índice modificado;
Saída:
INÍCIO (Modifica_nome_indice)
ENQUANTO existirem modificações de nomes de índices para classe no R2O2
FAÇA
OBTER a lista de atributos do indice_atual
Retira_indice (classe, nome_indice)
Insere_indice (classe, nome_indice_atual, *atributos)
100
FIM-ENQUANTO
FIM (Modifica_nome_indice)
10.
Acrescentar um atributo a um índice de uma classe
Int Insere_atributo_indice (classe, nome_indice, atributo)
Descrição: insere um atributo no índice da classe informada como parâmetro. Esta
operação não tem efeito sobre os objetos na extensão da classe e subclasses. De forma similar
a operação (9) o índice modificado é removido. Em seguida, é criado um novo índice, com o
novo atributo e o(s) atributo(s) definido(s) no índice removido, sobre os objetos na extensão
da classe especificada e suas subclasses.
Entradas:
atributo: atributo inserido no índice;
Saída:
INÍCIO (Insere_atributo_indice)
ENQUANTO existirem inserções de atributos em índices para classe no R2O2 FAÇA
OBTER a lista de atributos do índice
INCLUIR o novo atributo na lista
Insere_indice (classe, nome_indice, *atributos)
FIM-ENQUANTO
101
FIM (Insere_atributo_indice)
11.
Retirar um atributo do índice de uma classe
Int Retira_atributo_indice (classe, nome_indice, atributo)
Descrição: retira um atributo no índice da classe informada como parâmetro. Esta
operação não tem efeito sobre os objetos na extensão da classe e subclasses. De forma similar
a operação (9) o índice modificado é removido. Em seguida, é criado um novo índice, para
o(s) atributo(s) definido(s) no índice removido, menos o atributo retirado, sobre os objetos na
extensão da classe especificada e suas subclasses.
Entradas:
atributo: atributo retirado do índice;
Saída:
INÍCIO (Retira_atributo_indice)
ENQUANTO existirem retiradas de atributos de índices para classe no R2O2 FAÇA
OBTER a lista atributos do índice
RETIRAR o atributo na lista
Insere_indice (classe, nome_indice, *atributos)
FIM (Retira_atributo_indice)
102
12.
Tornar uma classe S superclasse de uma classe S1
Int Insere_superclasse (classe, superclasse)
Descrição: insere valor(es) para os objetos da classe informada como parâmetro
referente(s) ao(s) atributo(s) herdado(s) da superclasse S.
Entradas:
superclasse: superclasse S;
classe: classe S1;
Saída:
INÍCIO (Insere_superclasse)
ENQUANTO existirem modificações para tornar a classe S superclasse de uma classe
S1 no R2O2 FAÇA
ENQUANTO existirem atributos da superclasse para inserção na
classe FAÇA
Insere_atributo (classe, atributo, domínio, valor)
FIM-ENQUANTO
FIM-ENQUANTO
FIM (Insere_superclasse)
13.
Remover uma classe S da lista de superclasses da classe S1
Int Remove_superclasse (superclasse, classe)
Descrição: remove os valor(es), referente(s) ao(s) atributo(s) herdado(s) da
superclasse S, para os objetos da classe informada como parâmetro.
103
Entradas:
superclasse: superclasse S;
classe: classe S1;
Saída:
INÍCIO (Remove_superclasse)
ENQUANTO existirem modificações para remover a classe S da lista de
superclasses de uma classe S1 no R2O2 FAÇA
ENQUANTO existirem atributos da classe superclasse para serem
retirados da classe no R2O2 FAÇA
Exclui_atributo (classe, atributo)
FIM-ENQUANTO
FIM-ENQUANTO
FIM-SE
FIM (Remove_superclasse)
14.
Criar uma nova classe no esquema
Int Cria_classe (classe, *atributos, *domínios)
Descrição: cria uma classe. Esta operação não tem efeito sobre os objetos das classes e
das subclasses existentes.
Entradas:
classe: nome da classe criada;
*atributos: lista de atributos da classe criada;
*domínios: lista de domínios de atributos da classe criada;
104
Saída:
INÍCIO (Int Cria_classe)
Cria_classe (classe, *atributos, *domínios)
FIM (Int Cria_classe)
15.
Retirar uma classe no esquema
Int Retira_classe (classe)
Descrição: exclui uma classe informada como parâmetro. Esta operação resulta na
exclusão dos objetos existentes na extensão da classe retirada.
Entradas:
classe: classe retirada;
Saída:
INÍCIO (Retira_classe)
OBTER número_referência dos objetos da classe
SE número_referência for zero ENTÃO
Retira_classe (classe)
FIM-SE
FIM (Retira_classe)
105
16.
Modificar o nome de uma classe
Int Modifica_nome_classe (classe, novo_nome_classe)
Descrição: modifica o nome da classe informada como parâmetro. Esta operação não
tem efeito sobre os objetos na extensão da classe e das subclasses. No entanto, em
conseqüência das limitações impostas pelo modelo de armazenamento, conforme foi descrito
no subitem 4.3.1, a classe modificada é recriada com o novo nome.
Entradas:
classe: nome da classe modificada;
novo_nome_classe: novo nome da classe modificada;
Saída:
INÍCIO (Modifica_nome_classe)
OBTER número_referência dos objetos da classe
OBTER as listas de atributos e domínios da classe modificada
Cria_classe (novo_nome_classe, *atributos, *domínios)
Migrar_objeto (classe, novo_nome_classe, Id_Obj)
FIM-ENQUANTO
Retira_classe (classe)
FIM-SE
FIM (Modifica_nome_classe)
106
17. Migrar um objeto de uma classe origem O para uma classe destino D
Int Migrar_objeto (classe_origem, classe_destino, Id_Obj)
Descrição: exclui da extensão da classe classe_origem o objeto (Id_Obj) informado
como parâmetro e o inclui na classe classe_destino, mantendo o mesmo identificador.
Entradas:
classe_origem: classe origem do objeto migrado;
classe_destino: classe destino do objeto migrado;
Id_Obj: identificador do objeto referenciado; e
Saída:
INÍCIO (Migrar_objeto)
OBTER número_referência do objeto (Id_Obj) da classe
SE a classe classe_destino for superclasse da classe classe_origem ENTÃO
ENQUANTO o objeto Id_Obj possuir atributo específico da classe_origem
FAÇA
Exclui_atributo (classe, atributo) para o objeto referenciado
(Id_Obj)
FIM-ENQUANTO
SENÃO
SE a classe classe_destino for subclasse da classe classe_origem OU a
classe classe_destino possua no mínimo uma superclasse em
comum com a classe classe_origem ENTÃO
107
ENQUANTO houver atributo específico da classe_destino FAÇA
Insere_atributo (classe, atributo, domínio, valor) para o
objeto referenciado (Id_Obj)
FIM-ENQUANTO
FIM-SE
FIM-SE
FIM-SE
FIM (Migrar_objeto)
As atualizações dos códigos C++ provenientes das operações: (18) Acrescentar um
método à classe, (19) Remover um método da classe e (20) Renomear um método da
classe são de responsabilidade do usuário que, auxiliado pelo sistema, tem acesso a estas
modificações realizadas sobre os métodos.
5.2 - OPERAÇÕES ESPECÍFICAS DE MANIPULAÇÃO DO R2O2
A seguir serão descritas as funcionalidades de métodos e funções específicas para
instanciação e varredura do R2O2.
21. Instanciar o R2O2
Int Intancia_R2O2 (arq: alt.dat)
108
Descrição: instancia o R2O2, a partir do arquivo alt.dat, gerado pelo MAME e
informado como parâmetro. Cada ocorrência do arquivo corresponde a uma operação de
modificação, executada sobre o esquema da aplicação. Estas ocorrências são instanciadas
como objetos nas classes do R2O2 e, posteriormente, propagadas aos objetos das classes da
aplicação, conforme descrito no item 4.3.
Entradas:
arq: alt.dat: arquivo gerado pelo MAME com as operações de
modificação executadas sobre o esquema da aplicação;
Saída:
INÍCIO (Int Intancia_R2O2)
ENQUANTO existirem ocorrências no arquivo alt.dat FAÇA
OBTER tipo de operação
INSTANCIAR a classe do R2O2 conforme o tipo de operação
FIM-ENQUANTO
FIM (Int Intancia_R2O2)
22. Verificar a existência de modificações para uma classe no R2O2
Int Condição_R2O2 (classe, Id_Obj)
Descrição: conforme a descrição apresentada no item 4.3, este método é ativado por
quaisquer métodos básicos de atualização, ou de recuperação dos objetos das classes da
aplicação, gerados pela LIDAS. Varre o R2O2 e verifica se existem modificações não
109
propagadas para a classe informada como parâmetro; em seguida ativa o método de
propagação sobre o objeto (Id_Obj) ou objetos, de acordo com o tipo correspondente de
operação obtida.
Entradas:
classe: classe do atributo inserido; e
Id_Obj: identificador do objeto referenciado
Saída:
INÍCIO (Int Condição_R2O2)
VARRER R2O2
ENQUANTO existirem modificações para a classe no R2O2 FAÇA
OBTER tipo de operação
PROPAGAR modificação aos objetos da classe conforme o tipo de
operação obtido
FIM-ENQUANTO
FIM-ENQUANTO
FIM (Int Condição_R2O2)
5.3 - TABELAS DE CONVERSÃO PARA MODIFICAÇÕES DE ATRIBUTOS
As tabelas mostradas a seguir têm por objetivo estabelecer as possíveis conversões de
domínios, de restrições e de características definidas para os atributos das classes,
provenientes destes tipos de operação.
110
TABELA 5.1 - Conversões possíveis de domínio
DOMÍNIO
NOVO
DOMÍNIO
INT
REAL
BOOL
CHAR
DATA
LISTA
TUPLA
CONJ
CLASSE
INT
REAL
//////
SIM
NÃO
SIM
SIM 1
SIM 2
SIM 2
SIM 2
SIM 2
SIM
//////
NÃO
SIM 1
SIM 1
SIM 2
SIM 2
SIM 2
SIM 2
PRIMITIVOS
BOOL CHAR
SIM
SIM
//////
SIM
NÃO
NÃO
NÃO
NÃO
NÃO
SIM
SIM
NÃO
//////
SIM 1
SIM 2
SIM 2
SIM 2
SIM 2
DATA
CONSTRUTORES
LISTA TUPLA
CONJ
SIM 1
SIM 1
NÃO
SIM
//////
SIM 2
SIM 2
SIM 2
SIM 2
NÃO
NÃO
NÃO
NÃO
NÃO
SIM 2
SIM 2
SIM 3
SIM 2
NÃO
NÃO
NÃO
NÃO
NÃO
SIM 2
SIM 2
SIM 2
SIM 2
NÃO
NÃO
NÃO
NÃO
NÃO
SIM 4
SIM 2
SIM 2
SIM 2
TABELA 5.2 - Modificações possíveis de restrições
RESTRIÇÃO
NOVA
RESTRIÇÃO
NENHUMA
VALOR
INTERVALO
ESTADO
NENHUMA
VALOR
INTERVALO
ESTADO
//////
SIM 7
SIM 7
SIM 7
SIM 6
SIM 7
SIM 5
SIM 5
SIM 6
SIM 7
SIM 7
SIM 7
SIM 6
SIM 7
SIM 7
SIM 7
TABELA 5.3 - Modificações possíveis de características
CARACTERÍSTICA
NOVA
CARACTERÍSTICA
NÃO NULO
ÚNICO
AMBAS
NENHUMA
NÃO NULO
ÚNICO
AMBAS
NENHUMA
//////
NÃO
NÃO
SIM 6
SIM
//////
SIM
SIM 6
SIM
SIM
//////
SIM 6
SIM 8
NÃO
NÃO
//////
111
CLASSE
NÃO
NÃO
NÃO
NÃO
NÃO
SIM 2
SIM 2
SIM 2
SIM 5
Os detalhes de implementação e mecanismos de tratamentos diferenciados para os
objetos pertencentes à extensão das classes em alguns casos específicos de conversão, são
descritos a seguir:
(1)
Nestas conversões de domínio, os valores assumidos para atualizar os atributos
dos objetos da classe serão aqueles informados como parâmetro nas chamadas às operações
de modificação. Caso contrário, os objetos assumirão valores nulos;
(2)
Nestas conversões de domínio, os objetos instanciados são inicializados com
valores nulos e, posteriormente, especificados pelo usuário a partir das aplicações. As
estruturas correspondentes aos novos domínios, que não existirem por ocasião da
modificação, serão criadas pela LIDAS;
(3)
Nas conversões de domínio de lista para conjunto, os objetos duplicados são
removidos da classe, a critério do usuário;
(4)
Nas conversões de domínio de conjunto para lista, os objetos instanciados são
ordenados, caso contrário, a lista será inicializada com valores nulos e, posteriormente,
especificados pelo usuário a partir das aplicações;
(5)
Nestas conversões de domínio, se a classe correspondente ao novo domínio for
subclasse ou superclasse da classe domínio atual, os objetos instanciados mantêm seus
valores. Caso contrário, valores nulos serão assumidos e, posteriormente, especificados pelo
usuário a partir das aplicações;
(6)
Nestas modificações, os objetos existentes mantêm seus valores para os
atributos modificados;
112
(7)
A tabela mostra que todas modificações são possíveis, porém, se os valores
dos objetos instanciados não satisfizerem as novas restrições, o usuário informará os novos
valores a partir das aplicações;
(8)
Para esta modificação de característica, o usuário deverá informar os novos
valores para os objetos que possuírem valor nulo.
113
CAPÍTULO 6
AMBIENTE DO PROTÓTIPO DE IMPLEMENTAÇÃO
6.1 - CONTEXTO DA APLICAÇÃO
Neste capítulo, os efeitos de propagação das operações de evolução de esquemas sobre
uma base de objetos são apresentados através de alguns exemplos implementados sobre o
protótipo da aplicação SCH - Sistema de Controle Hospitalar definida no ambiente SIGO.
A Figura 6.1 mostra as classes e as tabelas geradas a partir do esquema conceitual da
aplicação SCH. Este esquema é representado seguindo as seguintes definições:
•
PESSOA - superclasse de MÉDICO e PACIENTE e uma agregação dos atributos:
Foto (tipo imagem), Sexo (char), Idade (int), Nome (char) e Endereço (char);
•
MÉDICO - subclasse de PESSOA e uma agregação dos atributos: CRM (char) e
Escala (char);
•
PACIENTE - subclasse de PESSOA e uma agregação de: Prontuário (char),
Anamnese (tipo texto) e Consulta (lista de CONSULTA);
•
CONSULTA - é uma agregação dos atributos: Médico (classe de MÉDICO),
Data_Hora (char), Diagnóstico (tipo texto), Queixa (tipo voz) e Exame (conjunto
de EXAME); e
•
EXAME - é uma agregação de: Nome_Exame (char), Preço (Real) e Requisitos
(tipo texto).
114
Endereço
Idade Foto a
a
a
a
Diagnóstico
Médico Data_Hora
a
Nome
a
Queixa
a
a
Sexo
a
CONSULTA
l
PESSOA
g
CRM
a
MÉDICO
g
Consulta
a
Escala
a
a
Prontuário
a
PACIENTE
Exame
Anamnese
a
s
Nome_Exame
a Preço
EXAME
a
Requisitos
a
PESSOA (Id_Pessoa, Id_Foto, Sexo, Idade, Nome, Endereço)
MÉDICO (Id_Médico, CRM, Escala)
PACIENTE (Id_Paciente, Prontuário, Id_Anamnese, Id_Lista_Consulta)
CONSULTA
(Id_Consulta,
Id_Médico,
Data_Hora,
Id_Diagnóstico,
Id_Queixa,
Id_Conjunto_Exame)
EXAME (Id_Exame, Nome_Exame, Preço, Id_Requisitos)
LISTA_CONSULTA (Id_Lista_Consulta, Id_Consulta)
CONJUNTO_EXAME (Id_Conj_Exame, Id_Exame)
FIGURA 6.1 - Esquema conceitual e tabelas da aplicação SCH
6.2 - OPERAÇÕES DE EVOLUÇÃO DA BASE DE OBJETOS NO SCH
Um subconjunto de operações de evolução de esquemas foi selecionado como base
para criação de alguns exemplos de propagação dos efeitos destas modificações às instâncias
das classes. Estes exemplos serão descritos a seguir:
•
Exemplo no 1
115
Operação: Insere_atributo (MÉDICO, Especialidade, A20, “clínica”), inclusão do
atributo “Especialidade” do tipo alfanumérico, com 20 posições para classe MÉDICO, o valor
“clínica” será assumido na inclusão do atributo para os objetos instanciados;
Estrutura da tabela antes da operação: MÉDICO (Id_Médico, CRM, Escala);
A Figura 6.2 mostra os objetos instanciados antes da operação;
Estrutura da tabela após a operação: MÉDICO (Id_Médico, CRM, Escala,
Especialidade);
A Figura 6.3 mostra os objetos instanciados após a operação.
•
Exemplo no 2
Operação: Exclui_atributo (EXAME, Preço), exclusão do atributo “Preço” da classe
EXAME;
Estrutura da tabela antes da operação: EXAME (Id_Exame, Nome_Exame, Preço,
Id_Requisitos);
Estrutura da tabela após a operação: EXAME (Id_Exame,
Nome_Exame,
Id_Requisitos);
A Figura 6.5 mostra que após a operação, os objetos instanciados perderam os valores
do atributo excluído.
•
Exemplo no 3
Operação: Renomeia_atributo (MÉDICO, Escala, Plantão), renomeação para
“Plantão” do atributo “Escala” da classe MÉDICO;
Estrutura da tabela antes da operação: MÉDICO (Id_Médico, CRM, Escala);
116
Estrutura da tabela após a operação: MÉDICO (Id_Médico, CRM, Plantão);
A Figura 6.7 mostra que após a operação, os objetos instanciados não sofreram
qualquer modificação. No entanto, em conseqüência das limitações impostas pelo modelo de
armazenamento, conforme foi descrito no subitem 4.3.1, a classe modificada foi recriada com
o atributo renomeado.
•
Exemplo no 4
Operação: Modifica_dom_atributo (PACIENTE, Prontuário, “inteiro”), modificação
de domínio do atributo “Prontuário” da classe PACIENTE, de caracter para inteiro;
Estrutura da tabela antes da operação: PACIENTE (Id_Paciente, Prontuário,
Id_Anamnese, Id_Lista_Consulta);
Estrutura da tabela após a operação: PACIENTE (Id_Paciente, Prontuário,
A Figura 6.9 mostra que após a operação os objetos instanciados tiveram o domínio
dos valores do atributo “Prontuário” modificado de caracter para inteiro.
•
Exemplo no 5
Operação: Modifica_dom_atributo (PACIENTE, Consulta, “conjunto”), modificação
de domínio do atributo “Consulta” da classe PACIENTE, de lista para conjunto;
Estrutura da tabela antes da operação: PACIENTE (Id_Paciente, Prontuário,
117
Estrutura da tabela após a operação: PACIENTE (Id_Paciente, Prontuário,
Id_Anamnese, Id_Conjunto_Consulta);
A Figura 6.11 mostra que após a operação, os objetos instanciados tiveram o domínio
dos valores do atributo “Consulta” modificado de lista para conjunto. Além disto, um valor
nulo foi assumindo, cabendo ao usuário suas atualizações pela aplicação.
•
Exemplo no 6
Operação: Modifica_dom_atributo (PESSOA, Endereço, “tupla”), modificação de
domínio do atributo “Endereço” da classe PESSOA, de caracter para tupla;
Estrutura da tabela antes da operação: PESSOA (Id_Pessoa, Id_Foto, Sexo, Idade,
Nome, Endereço);
Estrutura da tabela após a operação: PESSOA (Id_Pessoa, Id_Foto, Sexo, Idade,
Nome, Id_tupla_Endereço);
A Figura 6.13 mostra que após a operação, os objetos instanciados tiveram o domínio
dos valores do atributo “Endereço” modificado de caracter para tupla. Além disto, um valor
nulo foi assumindo, cabendo ao usuário suas atualizações pela aplicação.
•
Exemplo no 7
Operação:
Modifica_rest_atributo
(EXAME,
Preço,
777777,
“≤
450.00”),
modificação de restrição sobre o atributo Preço da classe EXAME, de “nenhuma” para “≤
450.00”, estabelecendo o maior preço possível para um exame;
Id_Requisitos);
118
Estrutura da tabela após a operação: EXAME (Id_Exame,
Nome_Exame,
Id_Requisitos);
A Figura 6.15 mostra os objetos instanciados após a operação. O usuário informou o
novo valor 449.99 para o objeto acessado “Id_Exame = 777777”, uma vez que o valor
anterior não atendia a nova restrição definida.
•
Exemplo no 8
Operação: Modifica_carac_atributo (EXAME, Requisitos, 777777, “não nulo”),
modificação de característica sobre o atributo Requisitos da classe EXAME, de “nenhuma”
para “não nulo”, estabelecendo que todos os exames têm requisitos;
Id_Requisitos);
Estrutura da tabela após a operação: EXAME (Id_Exame, Nome_Exame, Preço,
Id_Requisitos);
A Figura 6.17 mostra os objetos instanciados após a operação. O usuário informou o
novo texto “não ter feito abreugrafia nos últimos seis meses” para o objeto acessado
“Id_Exame = 777777”, uma vez que o valor anterior “nulo” não atendia a nova restrição
definida, o texto recebeu o “Id_Requisitos = 444444”.
•
Exemplo no 9
119
Operação: Cria_classe (RESIDENTE, Responsável, “classe PESSOA”), criação da
classe RESIDENTE, com o atributo “Responsável” do tipo “classe PESSOA”, que define o
responsável pelo médico residente;
Estrutura da tabela antes da operação: não há;
Objetos instanciados antes da operação: não há;
Estrutura da tabela após a operação: RESIDENTE (Id_Residente, Id_Pessoa).
•
Exemplo no 10
Operação: Insere_superclasse (RESIDENTE, MÉDICO, 888888), torna a classe
MÉDICO superclasse da classe RESIDENTE criada no exemplo no 9;
Estrutura da tabela PESSOA: PESSOA (Id_Pessoa, Id_Foto, Sexo, Idade, Nome,
Endereço) ;
Estrutura da tabela MÉDICO: MÉDICO (Id_Médico, CRM, Escala);
Estrutura da tabela RESIDENTE antes da operação: RESIDENTE (Id_Residente,
Id_Pessoa);
A Figura 6.18 mostra os objetos instanciados na tabela RESIDENTE antes da
operação;
Estrutura da tabela RESIDENTE após a operação: RESIDENTE (Id_Residente,
Id_Pessoa). O mecanismo de herança faz com que a tabela RESIDENTE herde todos os
atributos de MÉDICO e PESSOA, assumindo, numa visão lógica, a seguinte estrutura:
RESIDENTE (Id_Pessoa, Id_Foto, Sexo, Idade, Nome, Endereço, CRM, Escala, Id_Pessoa);
A Figura 6.19 mostra os objetos instanciados na tabela RESIDENTE após a operação.
Todos os atributos de MÉDICO e PESSOA são inseridos com valores “nulos” para o objeto
acessado “Id_Residente = 444444”.
120
•
Exemplo no 11
Operação: Remove_superclasse (MÉDICO, RESIDENTE, 888888), remove a classe
MÉDICO do conjunto de superclasses da classe RESIDENTE. Esta operação tem efeito
inverso ao exemplo no 10, isto é, os atributos de médicos serão removidos da classe
RESIDENTE.
•
Exemplo no 12
Operação: Migrar_objeto (MÉDICO, PACIENTE, 123456), migração do objeto
“Id_Pessoa = 123456” da classe MÉDICO para a classe PACIENTE;
Estrutura da tabela MÉDICO antes da operação: MÉDICO (Id_Médico, CRM,
Escala);
A Figura 6.20 mostra os objetos instanciados na tabela MÉDICO antes da operação;
Estrutura da tabela PACIENTE antes da operação: PACIENTE (Id_Paciente,
Prontuário, Id_Anamnese, Id_Lista_Consulta);
A Figura 6.21 mostra os objetos instanciados na tabela PACIENTE antes da operação;
Estrutura da tabela MÉDICO após a operação: MÉDICO (Id_Médico, CRM, Escala);
A Figura 6.22 mostra os objetos instanciados na tabela MÉDICO após a operação. O
objeto “Id_Pessoa = 123456” foi removido da tabela;
Estrutura da tabela PACIENTE após a operação: PACIENTE (Id_Paciente,
Prontuário, Id_Anamnese, Id_Lista_Consulta);
A Figura 6.23 mostra os objetos instanciados na tabela PACIENTE após a operação.
O objeto “Id_Pessoa = 123456” é inserido na tabela, preservando seu identificador e os seus
atributos oriundos da classe PESSOA. Além disso, perde os atributos CRM e Escala da classe
121
MÉDICO e ganha os atributos Prontuário, Id_Anamnese, Id_Lista_Consulta da classe
PACIENTE, que são inicializados com valor nulo.
999999 888888
m 12 Ricardo Tijuca 111 0800 1200
777777 666555
f
26 Ana
Leblon 222 1200 1600
555555 444444
f
15 Aline
Grajaú 333 1600 1200
Id_Pessoa
Sexo
Id_Foto
Nome
Idade
CRM
Endereço
Escala
999999 888888
m 12 Ricardo Tijuca 111 0800 1200 clínica
777777 666666
f 26 Ana
Leblon 222 1200 1600 clínica
555555 444444
f 15 Aline
Grajaú 333 1600 1200 clínica
Id_Pessoa
Id_Foto
Sexo
Nome
Idade
CRM
Endereço
Especialidade
Escala
122
999999 hemograma
250.00 555555 (jejum)
888888 abreugrafia
128.00 nulo (nenhum)
777777 eletrocardiograma 455.00 nulo (nenhum)
Id_Exame
Preço
Nome_Exame
Id_Requisitos
999999 hemograma
555555 (jejum)
888888 abreugrafia
nulo (nenhum)
777777 eletrocardiograma nulo (nenhum)
Id_Exame
Id_Requisitos
Nome_Exame
123
999999 888888
m 12 Ricardo Tijuca 111 0800 1200
777777 666666
f 26 Ana
Leblon 222 1200 1600
555555 444444
f 15 Aline
Grajaú 333 1600 1200
Id_Pessoa
Sexo
Id_Foto
Nome
Idade
CRM
Endereço
Escala
FIGURA 6.6- Objetos instanciados na classe MÉDICO (Exemplo no 3)
999999 888888 m 12 Ricardo Tijuca 111 0800 1200
777777 666666
f
26 Ana
Leblon 222 1200 1600
555555 444444
f
15 Aline
Grajaú 333 1600 1200
Id_Pessoa
Id_Foto
Sexo
Nome
Idade
CRM
Endereço
Escala
Plantão
124
999999 9876 555555 (texto1) 123456
888888 5432 444444 (texto2) 789012
777777 1098 333333 (texto3) 345678
Id_Paciente
Id_Anamnese
Prontuário (caracter)
Id_Lista_Consulta
999999 9876 555555 (texto1) 123456
888888 5432 444444 (texto2) 789012
777777 1098 333333 (texto3) 345678
Id_Paciente
Id_Anamnese
Prontuário (caracter) Id_Lista_Consulta
(inteiro)
125
999999 9876 555555 (texto1) 123456
888888 5432 444444 (texto2) 789012
777777 1098 333333 (texto3) 345678
Id_Paciente
Id_Anamnese
Prontuário
Id_Lista_Consulta
999999 9876 555555 (texto1) nulo
888888 5432 444444 (texto2) nulo
777777 1098 333333 (texto3) nulo
Id_Paciente
Id_Anamnese
Prontuário
Id_Lista_Consulta
Id_Conjunto_Consulta
126
999999 888888 m 12 Ricardo Tijuca
777777 666555 f 26
Ana
Leblon
555555 444444 f 15
Aline
Grajaú
Id_Pessoa
Sexo
Id_Foto
Nome
Idade
Endereço
(caracter)
999999 888888 m 12 Ricardo
nulo
777777 666666 f
26 Ana
nulo
555555 444444 f
15 Aline
nulo
Id_Pessoa
Id_Foto
Sexo
Nome
Idade
Endereço (caracter)
(Id_tupla_Endereço)
127
999999 hemograma
250.00 555555 (jejum)
Id_Exame
Preço
Nome_Exame
Id_Requisitos
999999 hemograma
250.00 555555 (jejum)
455.00
Id_Exame
Preço
Nome_Exame
Id_Requisitos
999999 hemograma
250.00 555555 (jejum)
Id_Exame
Preço
Nome_Exame
Id_Requisitos
128
999999 hemograma
250.00 555555 (jejum)
777777 eletrocardiograma 455.00 444444 (não ter feito....)
Id_Exame
Preço
Nome_Exame
Id_Requisitos
222222 999999
333333 777777
444444 555555
Id_Residente
Id_Pessoa
444444 nulo nulo nulo nulo nulo nulo nulo 555555
Id_Pessoa
Sexo
Id_Foto
Nome
Idade
CRM
Endereço
Id_Pessoa
Escala
129
999999 888888 m 12 Ricardo Tijuca 111 0800 1200
123456 666555
f 26 Ana
Leblon 222 1200 1600
555555 444444 f 15 Aline
Id_Pessoa
Sexo
Id_Foto
Grajaú 333 1600 1200
Nome
Idade
CRM
Endereço
Escala
222222 222777 m 58 Luís
copa
9876 555555 (texto1) 123456
777777 777333 f 32 Mônica Grajaú 5432 444444 (texto2) 789012
333333 333000 f 33 Eduarda Urca 1098 333333 (texto3) 345678
Id_Pessoa
Sexo
Nome
Id_Foto Idade
Prontuário
Endereço
Id_Lista_Consulta
Id_Anamnese
130
999999 888888 m 12 Ricardo Tijuca 111 0800 1200
123456 666555 f
26 Ana
Leblon 222 1200 1600
555555 444444 f
15 Aline
Grajaú 333 1600 1200
Id_Pessoa
Sexo
Id_Foto
Nome
Idade
CRM
Endereço
Escala
222222 222777 m 58 Luís
copa
9876 555555 (texto1) 123456
777777 777333 f 32 Mônica Grajaú 5432 444444 (texto2) 789012
333333 333000 f 33 Eduarda Urca 1098 333333 (texto3) 345678
123456 666555 f 26 Ana
Id_Pessoa
Sexo
Id_Foto
Leblon nulo
Nome
Idade
nulo
Prontuário
Endereço
nulo
Id_Lista_Consulta
Id_Anamnese
131
CAPÍTULO 7
CONCLUSÃO
7.1 - CONTRIBUIÇÕES
Este trabalho apresenta o resultado da pesquisa de vários aspectos e de alternativas
sobre evolução dinâmica de esquemas num ambiente de BDOOs, através do uso efetivo de
regras ativas inseridas no gerenciador do BD. O principal objetivo foi gerenciar e realizar o
tratamento da propagação dos efeitos das operações de modificação, sob o ponto de vista
estrutural e comportamental, em relação à base de objetos instanciada, pertencente a uma
aplicação definida no Sistema Gerenciador de Objetos - SIGO.
Visando viabilizar e disponibilizar ao usuário esta funcionalidade, os resultados
obtidos foram implementados em um protótipo e incorporados à aplicação SCH - Sistema de
Controle Hospitalar.
A pesquisa desenvolvida abrangeu o estudo dos vários aspectos relativos à
consistência intencional e extensional de BDs e às alternativas para manutenção de instâncias,
no processo de evolução de esquemas em SGBDOOs. Estes aspectos foram investigados nos
seguintes SGBDOOs: O2, ORION, GEMSTONE e OBJECTSTORE. Paralelamente, também
foram pesquisadas a semântica, bem como as estruturas e mecanismos de utilização de regras
em BDs Ativos.
De uma forma objetiva, a principal contribuição deste trabalho foi garantir a
integridade de instanciação do esquema da aplicação, pela extensão da utilização de regras
ativas, no tratamento da evolução da base de objetos. Este tratamento possibilita a
modificação do esquema após a instanciação da base. Outra importante contribuição foi a
132
definição conceitual e implementação de uma estrutura hierárquica de classes denominada
R2O2, para armazenamento e propagação das efetivas modificações efetuadas sobre um
esquema de aplicação. O R2O2 é extensível, o que permite incorporar à estrutura, outras
operações de modificação, ou mesmo outros tipos de regras de ação que venham a ser
definidas.
Além disso, podem ainda ser ressaltadas algumas contribuições intermediárias, como
por exemplo:
•
Especificação e descrição funcional dos efeitos sobre os métodos e objetos das
operações de modificação de atributos, de classes, de objetos e de métodos numa
hierarquia de classes;
•
Auxílio ao usuário no processo de evolução dos métodos, através da
disponibilização das informações, referentes a todas modificações operadas sobre
os métodos e os atributos das classes da aplicação;
•
Implementação de um subconjunto de modificações selecionado sobre o protótipo
da aplicação SCH, definida no ambiente SIGO. O objetivo é mostrar a propagação
dos efeitos destas operações sobre uma base de objetos pertencentes à extensão das
classes.
7.2 - SUGESTÕES PARA TRABALHOS FUTUROS
Existem várias funcionalidades avançadas que estão sendo pesquisadas e
desenvolvidas, todas elas motivadas pelas necessidades dos SGBDOOs. Um dos objetivos
mais importantes é a extensibilidade que pode ser suportada através de diversos mecanismos,
além da alternativa de evolução apresentada nesta tese.
133
Com base no trabalho realizado, algumas sugestões para trabalhos futuros são
apresentadas a seguir:
(1)
Desenvolvimento e implementação do versionamento de esquemas descrito no
item 2.2. O principal objetivo desta funcionalidade é prover ao usuário a habilidade de
manipular múltiplas versões do esquema, além de manter um acompanhamento histórico das
modificações ocorridas. É desejável ainda que este acompanhamento alcance o esquema
conceitual e as instâncias para possibilitar, indistintamente, o correto funcionamento de novas
e antigas aplicações;
(2)
Desenvolvimento e implementação de visões, sujeitas a modificações,
relevantes a um grupo de usuários. Esta alternativa provê um conjunto de operações, através
do qual as visões podem ser definidas e manipuladas numa hierarquia de classes;
(3)
Análise de desempenho e de complexidade assintótica das operações
desenvolvidas para operar a varredura e a propagação dos efeitos das modificações sobre a
base de objetos. Estas implementações foram feitas em C++, utilizando a biblioteca de
funções do PARADOX ENGINE. A sugestão apresentada se justifica porque, em alguns
casos, os tempos de resposta mostraram-se extremamente ineficientes, mesmo quando a
manipulação das estruturas envolviam um pequeno número de instâncias. Este trabalho,
portanto, teria por objetivo a otimização destas operações, devendo-se incluir o estudo de
outros métodos de acesso e de estruturas de armazenamento, além do sistema atual adotado
pelo SIGO (BORLAND,1992);
(4)
Extensão da definição conceitual e implementação do R2O2 para o tratamento
de regras semânticas de aplicação;
(5)
Inclusão no R2O2 de uma classe DICIONÁRIO para o armazenamento dos
valores dos objetos, dos atributos e das classes modificadas ou retiradas do esquema. Este
134
gerenciamento visa atender a uma possível necessidade de recuperação ou de retorno a
estados anteriores do esquema da aplicação. Além disso, a ativação ou não desta facilidade
seria opcionalmente expressa pelo usuário, como um parâmetro de “retenção” nas operações
de evolução de esquemas.
7.3 - CONSIDERAÇÕES FINAIS
A evolução natural da tecnologia de BDs, visando prover o suporte necessário às
aplicações não convencionais, voltou-se para o desenvolvimento de SGBDs mais poderosos,
os SGBDOOS, incluindo-se modelos, linguagens e capacitação para definição de novos tipos
de dados (KHOSHAFIAN,1993).
Um dos aspectos em destaque nos SGBDOOs, diz respeito à modelagem conceitual
de BDs. É imprescindível que tais sistemas ofereçam ambientes simples e amigáveis que
disponibilizem, ao usuário, as abstrações necessárias para modelar suas aplicações.
Além disso, o tratamento de esquemas complexos, a herança múltipla, as modificações
dinâmicas durante a execução de programas são também aspectos a serem avaliados. Em
particular, observa-se que a realidade de interesse das aplicações não convencionais está
sujeita a freqüentes alterações. Estas se refletem diretamente na modelagem das aplicações, e
devem acompanhar este aspecto dinâmico.
O capítulo 2 descreve algumas propostas de evolução de esquemas, envolvendo o
tratamento por versionamento ou sobre um esquema único. Estas propostas foram
consideradas para a adoção daquela mais adequada ao ambiente SIGO. Porém, conforme a
especificação contida no item 4.3, o tratamento de evolução de esquemas no SIGO pelo uso
135
de regras ativas constitui, de fato, uma proposta original, visto que, no contexto da literatura
pesquisada, nenhuma outra sugeriu abordagem semelhante.
As novas capacidades embutidas nos SGBDOOs representam, efetivamente, a
perspectiva de processamento de uma extensa gama de operações consideradas de nova geração
de SGBDs. O tratamento de evolução de esquemas no SIGO, com garantia de integridade
intencional e extensional, acompanha a tendência das pesquisas realizadas na área e incorpora
aspectos particulares específicos do protótipo em desenvolvimento (BARROS, 1995).
136
REFERÊNCIAS BIBLIOGRÁFICAS
ABITEBOUL, 1988 - ABITEBOUL, R. H.; IFO: A Formal Semantic Database Model; ACM
Transactions on Database Systems, dezembro 1988.
ARAUJO, 1993 - ARAUJO, G. M. Linguagem de Métodos para um Ambiente de Banco de
Dados Orientado a Objetos. Tese de Mestrado, IME, Rio de Janeiro, março 1993.
ATKINSON, 1990 - ATKINSON, M. et al., The Object-Oriented Database Systems
Manifesto. Proceedings of the 1990 ACM SIGMOD International Conference on
Management of Data, Atlantic City, NJ, maio 1990.
BANERJEE, 1987 - BANERJEE et al., Semantics and Implementation of Schema Evolution
in Object-Oriented Database, ACM Sigmod Record vol 16 nº 93 1987.
BARROS, 1995 - BARROS, R.O.; MOURA, A.M.C; Uso de Regras Ativas no Tratamento de
Evolução de Esquemas em BDOOs, II Wokshop de Bancos de Dados Não Convencionais - UFF,
Rio de Janeiro - RJ, dezembro 1995.
BARROS, 1996 - BARROS, R.O.;MOURA, A.M.C., Use of Active Rules in the Schema
Evolution Process of an Object Manager System, submetido à XXII Conferência
Latinoamericana de Informática, Bogotá, Colômbia, junho 1996.
BORLAND, 1992 - BORLAND INTERNATIONAL INC.; Borland Paradox Engine Version 3.0; C Reference; and User’s Guide, 1992.
BUTTERWORTH, 1991 - BUTTERWORTH, P.; OTIS, A.; STEIN, J., The GemStone Object
Database System. Communications of ACM, Oct 1991.
CATTELL, 1991 - CATTELL, R.G.G., Sun Microsystems Inc. Object Data Management
Object-Oriented and Extended Relational Database System, 1991.
CATTELL, 1994 - CATTELL, R.G.G. et al., Object Database Standard ODMG 93, 1994.
CERI, 1994 - CERI, S.; et al.; Active Databases Systems, PUC-Rio DB Workshop on New
Databases Research Challenges, setembro 1994.
CHAKRAVARTHY, 1992 - CHAKRAVARTHY, S.; Architectures and Monitoring
Techniques for Active Databases: An Evaluation. Technical Report UF-CIS-TR-92-041,
1992.
CODD, 1970 - CODD, E. Relational Model of Data for Large Shared Data Bank,
Comunications of the ACM, Junho 1970.
COLLYER, 1996 - COLLYER, C.S.G.; Linguagem de Consulta ao SIGO: Um Sistema
Gerenciador de Objetos. Tese de Mestrado, IME, Rio de Janeiro, 1996 (em
desenvolvimento).
137
COSTA, 1992 - COSTA, M. R. Uma Linguagem de Consulta para um Banco de Dados
Orientado a Objetos. Tese de Mestrado, IME, Rio de Janeiro, 1992.
DATE, 1987 - DATE, C.J., Introducion to Database Systems, Ed. Campus, 1987.
DEUX, 1991 - DEUX, O. et al. The O2 System. Communications of the ACM, vol 34 nº 10
Oct 1991.
FERRANDINA, 1995 - FERRANDINA, F. et al.; Schema and Database Evolution in the O2
Object Databse System, Proceedings of the 21th VLDB Conference Zurich, Switzerland,
1995.
FREITAS, 1991 - FREITAS, L. Esquema Físico para Armazenamento de Objetos
Complexos. Tese de Mestrado, IME, Rio de Janeiro, 1991.
FORNARI, 1993 - FORNARI, M. RODRIGUES et al., Evolução de Esquemas Utilizando
Versões em BDOOs, Anais do 8º SBBD, João Pessoa - PB, 1993 pp 115-127.
GEMSTONE, 1995 - GEMSTONE SYSTEMS, INC., Introduction to Gemstone; Object
Server Version 4.1, Internet, homepage gemstone, http://www.gemstone.com/, 1995.
GOLENDZINER, 1993 - GOLDSTEIN, LIA G. GOLENDZINER, Um estudo sobre Versões
em Bancos de Dados Orientados a Objeto, exame de qualificação no CPGCC/UFRGS, março
1993.
GOLENDZINER, 1995 - GOLDSTEIN, LIA G. GOLENDZINER et el., Definição e
Manipulação de Configurações em BDOOs, X SBBD - Simpósio Brasileiro de Banco de
Dados, Recife, Outubro 1995, pp 335-349.
GUIMARÃES, 1995 - GUIMARÃES, A. R. N., Interface Orientada a Objetos para Criação
e Manipulação de Esquemas Conceituais no SIGO. Tese de Mestrado, IME, Rio de Janeiro,
março 1995.
HARRUS, 1990 - HARRUS, G.F., et al., Implementing Schema Upadates in an Objectoriented Databases System: Acost Analisys, Technical Report, GIP Altair, Le Chesnay Cedex,
France, 1990.
ITASCA, 1990 - ITASCA SYSTEMS INC., ITASCA System Overview, Unisys, Mineapolis,
Minesota, 1990.
KATZ, 1990 - KATZ, R.H. Towards a Unified Framework for Version Modeling in
Engineering Databases. ACM Computing Surveys, Dec 1990.
KHOSHAFIAN, 1993 - KHOSHAFIAN, S. et al., Object Orientation Databases, John Wiley
& Sons Inc, 1993.
138
KIM, 1987 - KIM, W. et al., Features of the ORION Object-oriented Databases System,
Proceedings of the Very Large Databases Endowment, 1987.
KIM, 1990 - KIM W., Introducion to Object-oriented Databases, The MIT Press, 1990.
KIM, 1995 - KIM W., Modern Databases Systems, The Object Model, Interoperability and
Beyond, ACM Press, Addison Wesley Publishing Company, 1995.
LAMB, 1991 - LAMB, C.; LANDIS, G.; ORENSTEIN, J.; and WEINREB, D. The Object
Store Database System. Communications of the ACM, Oct 1991.
LÈCLUSE, 1989 - C.LÈCLUSE; et al., The O2 Data Model, Altair Technical Report 39,
França, 1989.
LIMA, 1993 - LIMA, C. A. A. Tratamento de Dados Multimídia num Ambiente de Banco de
Dados Orientados a Objeto. Tese de Mestrado, IME, Rio de Janeiro, 1993.
MORSI, 1992 - MORSI, MAGDI M.A., Extensible Object-Oriented Databases with
Dynamic Schemas, tese de doutorado, Georgia Institute Technology, agosto 1992.
MOSS, 1992 - MOSS, J.E.; Working with Persistent Object: to Swizzle or not Swizzle, IEEE
Transactions on Software Engineering, vol. 18, agosto 1992.
MOURA, 1994 - MOURA, A.M.C. et al., Ambiente para Desenvolvimento de Aplicações
não Convencionais em BDs, Relatório Técnico de Pesquisa, FAPERJ, 1994.
MOURAa, 1995 - MOURA, A.M.C. et al.., Exploring Aspects of Schema Evolution and
Persistence in a Object Manager System, Relatório Técnico nº 009/DE9/95, Instituto Militar
de Engenharia / Departamento de Engenharia de Sistemas, dezembro, 1995.
MOURAb, 1995 - MOURA, A.M.C. et al., Dealing with Persistence in an Object
Management System Using Relational Implementation, XV Internacional Conference of the
Chilean Computer Science Society, Arica, Chile, novembro 1995.
NAVATHE, 1994 - NAVATHE S.B.; ELMASRI R., Fundamentals of Database Systems, 2nd
edition, Benjamin/Cunnings, 1994.
OBJECTIVITY, 1990 - OBJECTIVITY INC., Objectitity Database Reference, Menlo Park,
California, 1990.
OBJECTDESIGN, 1990 - OBJECT DESIGN INC., ObjectStore Reference, Burlington, 1990.
QUADROS, 1996 - QUADROS, J.R.T.; Modelagem Hiperdocumentos em um Sistema
Gerenciador de Objeto. Tese de Mestrado, IME, Rio de Janeiro, abril 1996.
PENNEY, 1987 - PENNEY, J.STEIN, Class Modification in the GemStone Object-Oriented
Database Systems, in Proceedings of de Second International Conference on Object-Oriented
Programming Systems, Languages and Applications (OOPSLA), 1987.
139
PREVOT, 1994 - PREVOT, M.PREVOT; LANZELOTE R. S. G., Formalizando a Evolução
de Esquemas em SGBDOOs, Anais do 9º SBBD, São Carlos -SP, 1994 pp 157-172.
ROSSETI, 1991 - ROSSETI, L. C. Linguagem de Definição e Manipulação de Esquema num
Banco de Dados Orientado a Objetos. Tese de Mestrado, IME, Rio de Janeiro, 1991.
SILBERCHATZ, 1994 - SILBERCHATZ, A. et al. Database Systems Concepts, McGraw
Hill, 1994.
SILVA, 1996 - ANDRÉA, T.S.; Implementação de Regras Ativas em um Sistema
Gerenciador de Objetos. Tese de Mestrado, IME, Rio de Janeiro, 1996 (em
desenvolvimento).
SOLOVIEV, 1992 - SOLOVIEV, V. et al.;An Overview of Three Commercial ObjectOriented Database Management Systems: ONTOS, ObjectStore, and O2. SIGMOD Records,
March 1992.
TANAKA, 1995 - TANAKA, A.K., BDs Ativos, Anais do 10º SBBD, Recife -PE, outubro
1995, pp 29-53.
ULLMAN, 1989 - ULLMAN, J.D., Principles of Database Systems, Computer Science
Press, 1989.
VELEZ, 1989 - VELEZ, F. et al.; The O2 Manager: an Overview, Rapport Technique, Altair,
Fevereiro 1987.
VERSANT, 1990 - VERSANT OBJECT TECHNOLOGY INC., Versant Reference Manual,
Menlo Park, California, 1990.
WIDOM, 1996 - WIDOM, J.; CERI, S.; Active Databases Systems Triggers and Rules for
Advanced Database Processing, Morgam Kaufmann Publishers, Inc., 1996.
XAVIER, 1989 - MAGNO, C. M. S. Modelagem Conceitual Orientada a Objetos para Banco
de Dados. Tese de Mestrado, IME, Rio de Janeiro, 1989.
XIDAK , 1990 - XIDAK INC., Orion System Overview, Palo Alto, California, 1990.
ZICARI, 1991 - ZICARI, ROBERTO; A Framework for Schema Updates in an ObjectOriented Database System, 7 º IEEE International Conference on Data Engineering Kobe,
Japão, Abril 1991.
140
APÊNDICE A
ESTRUTURA DO ARQUIVO DE MODIFICAÇÕES DO ESQUEMA ALT.DAT
141
APÊNDICE A - ESTRUTURA DO ARQUIVO DE MODIFICAÇÕES DO ESQUEMA
ALT.DAT
Arquivo texto gerado pelo MAME para leitura e instanciação dos objetos no R2O2.
Este arquivo possui a seguinte estrutura:
•
Atributos comuns a todos os registros:
Base (char) 7
Operação (char) 2
Classe (char) 24
•
Para registros referentes às operações 1, 2, 3, 4, 5 e 6:
Atributo (char) 24
•
Para registros referentes à operação 1
DomínioAtrib (char) 8
TamanhoAtrib (int)
CaracterísticaAtrib (char) 7
RestriçãoAtrib (char) 32
•
NovoNomeAtrib (char) 24
•
NovoDom (char) 8
NovoTamanhoAtrib (int)
•
NovaRest (char) 32
•
NovaCarac (char) 7
142
•
Para registros referentes às operações 7, 8, 9, 10 e 11
NomeIndice (char) 24
•
Para registros referentes às operações 7, 9, 10 e 11 (tantos quantos forem os atributos
componentes do índice conforme NumeroAtrib)
NumeroAtrib (int)
Atributos (char) 24
•
NomeIndatual (char) 24
•
Para registros referentes às operações 12 e 13
Superclasse (char) 24
•
NovoNomeClasse (char) 24
•
ClasseDestino (char) 24
Id_obj (double)
•
Para registros referentes às operações 18 e 19
Método (char) 32
•
NovoNomeMétodo (char) 32
143
Exemplos:
aplica; 1; pessoa; telefone; caracter; 7; nenhuma;;;; 0; ;;;;;;;;;0; 0;
Id_Obj
Número_Atributo
Tamanho_Atributo
Característica_Atributo
Tamanho_Atributo
Domínio_Atributo
Atributo
Classe
Operação
Base
aplica;2;pessoa;endereço;;0;;;;;0;;;;;;;;;;0;0;
aplica;3;pessoa;matricula;;0;;;;;0;;;;;;;inscricao;;;0;0;
aplica;4;medico;crm;;0;;;;caracter;8;;;;;;;;;;0;0;
aplica;5;paciente;idade;;0;;;;;0;>=18;;;;;;;;;0;0;
aplica;6;medico;especialidade;;0;;;;;0;;naonula;;;;;;;;0;0;
aplica;7;medico;;;0;;;;;0;;;;;indcrm;;;;;0;2;crm;nome;
aplica;8;pessoa;;;0;;;;;0;;;;;indcrm;;;;;0;0;
aplica;9;pessoa;;;0;;;;;0;;;;;indcrm;indmatr;;;;0;2;crm;idt;
aplica;10;pessoa;;;0;;;;;0;;;;;indcrm;;;;;0;2;crm;nome;
aplica;11;pessoa;;;0;;;;;0;;;;;indcrm;;;;;0;2;crm;nome;
aplica;12;medico;;;0;;;;;0;;;pessoa;;;;;;;0;0;
144
aplica;13;medico;;;0;;;;;0;;;pessoa;;;;;;;0;0;
aplica;15;medico;;;0;;;;;0;;;;;;;;;;0;0;
aplica;16;paciente;;;0;;;;;0;;;;associado ;;;;;;0;0;
aplica;17;medico;;;0;;;;;0;;;;paciente;;;;;;9612011645301915;0;
aplica;19;paciente;;;0;;;;;0;;;;;;;;retirapaciente;;0;0;
aplica;20;paciente;;;0;;;;;0;;;;;;;;retirapaciente;excluipaciente;0;0;
145

Dissertação de Mestrado de Ricardo Oliveira Barros - SE/8

Transcrição

Documentos relacionados

Dependência funcional Dependência funcional total

CSS

Modelagem

Seção do Cabeçalho - profª msc. elizabete munzlinger

Modelagem de banco de dados para diagnóstico de transtornos

versão pdf

Plano de Ensino - Departamento de Matemática

Proposta de Priorização de Projetos e Demandas por

E-book Banco de Dados I

Uma Introdução à Mineração de Informações.