A2

Prévia do material em texto

Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 1 - Parte II (Engenharia de Banco de Dados)
Engenharia de
Banco de Dados
29 páginas
♦♦ IINNTTRROODDUUÇÇÃÃOO
♦♦ EETTAAPPAASS
♦♦ MMOODDEELLOOSS DDEE DDAADDOOSS
♦♦ MMOODDEELLAAGGEEMM DDEE DDAADDOOSS
♦♦ MMAAPPEEAAMMEENNTTOO
♦♦ NNOORRMMAALLIIZZAAÇÇÃÃOO
♦♦ EEVVOOLLUUÇÇÃÃOO DDOO EESSQQUUEEMMAA DDEE DDAADDOOSS
♦♦ TTEEMMAASS RREELLAACCIIOONNAADDOOSS
♦♦ MMOOTTIIVVAAÇÇÃÃOO
♦♦ CCLLAASSSSIIFFIICCAAÇÇÃÃOO
♦♦ EEVVOOLLUUÇÇÃÃOO DDEE PPRROOJJEETTOO
♦♦ EEVVOOLLUUÇÇÃÃOO DDAA FFOORRMMAA
♦♦ EEVVOOLLUUÇÇÃÃOO DDAA LLÓÓGGIICCAA
♦♦ EESSQQUUEEMMAA FFÍÍSSIICCOO
♦♦ EESSQQUUEEMMAA EEXXTTEERRNNOO ((VVIISSÃÃOO))
♦♦ PPAADDRRÕÕEESS EE NNOORRMMAASS
♦♦ HHIISSTTÓÓRRIICCOO
♦♦ SSIISSTTEEMMAASS AABBEERRTTOOSS
♦♦ FFRROONNTTEEIIRRAASS
♦♦ BBEENNEEFFÍÍCCIIOOSS UUTTÓÓPPIICCOOSS
♦♦ OOSS PPAADDRRÕÕEESS
♦♦ OOMMGG
♦♦ OODDMMGG
♦♦ AANNSSII//XX33
♦♦ PPCCTTEE++
♦♦ IISSOO//SSTTEEPP
♦♦ AANNÁÁLLIISSEE GGEERRAALL
“A vida é como o equilibrismo
simultâneo de 5 bolas: o corpo; a mente; a alma; a
família e o trabalho. Dependendo de cada pessoa,
algumas destas bolas podem ser feitas de um vidro
muito frágil e outras de aço.”
“Desconhecido”
II
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 2 - Parte II (Engenharia de Banco de Dados)
1 - INTRODUÇÃO
Na informatização de um mini-mundo com a utilização de um BD, deve-se primeiramente
preocupar-se com a escolha do SBGD que será utilizado. De nada servirá uma Engenharia de BD
bem realizada se o gerenciador oferecer restrições inaceitáveis, como por exemplo, baixa capacidade
de armazenamento. As máquinas utilizadas e a arquitetura do Sistema de Informações (Centralizada,
Distribuída ou Cliente/Servidor) também são elementos de igual importância.
A Engenharia de Banco de Dados (ou Projeto de Banco de Dados, como é mais
conhecido) é um dos temas mais discutidos e estudados nesta área. A razão é forte, uma engenharia
incorreta pode resultar em um SBD que não atende as necessidades dos seus usuários, pedindo
frequentes e custosos reparos ou mesmo uma completa reengenharia. O tempo gasto em estudos e na
aplicação de princípios de uma boa engenharia de BD é sempre um tempo bem empregado.
A maior habilidade exigida para os especialistas em Engenharia de BD é saber recolher
informações a partir da vivência com o mini-mundo, é também extrair dos usuários por meio de
entrevistas e reuniões o que desejam do BD e é estruturar todas estas informações de modo a se
tornarem concretamente um BD. A grande valorização deste tipo de profissional ocorre devido a
dificuldade em se encontrar pessoas experientes tanto na área técnica quanto no tratamento com o
usuários, que na verdade são os clientes.
A grande maioria dos Bancos de Dados
existentes foram projetados manualmente por
especialistas que usaram seus conhecimentos e
experiências no processo. Todavia, com o crescimento da
complexidade dos BD’s (“Very Large Databases”) e o
estabelecimento de regras bem definidas para algumas
fases da Engenharia de BD, sugiram ferramentas de apoio
(“Automated Design Tools”) que auxiliam nas diversas
etapas do processo. Entre as vantagens podemos citar a
rapidez na realização da Engenharia, uma vez que estas
ferramentas oferecem um interface amigável que orienta
os projetistas nas decisões mais difíceis e realiza verificações seguras dos resultados intermediários.
A tecnologia dos Sistemas Especialistas (SE) em conjunto com as ferramentas CASE
(“Computer-Assisted Software Engineering”) tem colaborado nesta atividade, evitando-se
desperdícios de tempo, frustrações e melhorando os resultados de um processo extremamente crítico
e delicado tanto para os projetistas quanto para os usuários.
2 - ETAPAS
Uma boa engenharia de BD compreende resumidamente os seguintes passos:
Estabelecer o Objetivo : Buscar definir
o objetivo do sistema, benefícios que o sistema trará para
o mini-mundo, estabelecer restrições gerais de
desempenho, custos e restrições técnicas;
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 3 - Parte II (Engenharia de Banco de Dados)
Organização p/ o Trabalho: Definir a(s) equipe(s) de trabalho e sua estrutura
levando-se em consideração as habilidades de cada indivíduo e sua disponibilidade, recursos
necessários (descrição e disponibilidades), cronograma de atividades de acordo com as
disponibilidades estabelecidas.
Uma equipe pode ser estruturada em :
♦ Convencional : composta pelo pessoal disponível; entre estas pessoas é designado um
gerente do projeto; o trabalho é dividido entre os componentes da equipe; cada pessoa
é responsável pelo seu sub-projeto e respectiva implementação;
♦ Não-Egocêntrica : Organização de estilo democrático, descentralizado; Relações e
comunicações informais entre os seus componentes; A liderança não é exercida por
uma determinada pessoa de forma permanente; A liderança fica com o indivíduo que
tiver maior capacitação para resolver o problema em pauta; Todos os sub-projetos são
examinados pelos outros projetistas;
♦ Projetista-Chefe : Pequeno
número de integrantes;
Comunicações centralizadas
no projetista chefe; Decisões
tomadas nos níveis mais
elevados; O chefe tem que
ser muito experiente e
capacitado para a função;
♦ Hierárquica: líder de projeto
dirige analistas experientes; cada um desses analistas dirige um grupo de analistas
menos experientes; comunicação descentralizada nos subgrupos e centralizada nos
níveis superiores; o chefe de subgrupo transmite informações para seu subgrupo
(elemento de ligação com os outros subgrupos)
É importante notar
que as participações das
pessoas em uma engenharia
pode variar com o seu grau
de comprometimento e
conhecimento, como mostra
o gráfico abaixo.
É importante que
exista um cronograma geral
de atividades e um
cronograma de cada
indivíduo, que pode ser
apresentado de várias
formas, como mostrado abaixo.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 4 - Parte II (Engenharia de Banco de Dados)
Coleta de Dados: Coletar todos os tipos de informação que são precisos armazenar.
Pensar sobre os relatórios e/ou formulários que possam ser desejados. Para
esta fase é necessário conhecer profundamente o mini-mundo
e isto pode requerer algum tempo e a experiência (sabedoria)
nesta etapa é fundamental. Não deve ser realizada por uma
única pessoa, mas por um grupos de projetistas;
O levantamento dos dados necessários é,
basicamente, feito através da observação e das entrevistas.
Por meio da observações o analista utiliza sua habilidade
e sua sensibilidade na constatação de ocorrências que
devam ser computadas na análise, como também
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 5 - Parte II (Engenharia de Banco de Dados)
verifica a veracidade ou não dos dados fornecidos pelos entrevistados. Nas entrevistas o analista
aplica os questionários, anotando as respostas obtidas para posterior análise.
Técnica de entrevista : Importante fase do levantamento de dados, a entrevista é o meio
utilizado para o recolhimento das informações que compõem o questionário analítico. Merece pois,
que lhe seja dada especial atenção, a fim de que a mesma seja realizada segundo o adequado
embasamento técnico.
Escolha do entrevistado : O analista deve ter o máximo cuidado quando da escolha do
elemento a ser entrevistado, de modo que a entrevista seja realizada com a pessoa mais capacitada a
responder os quesitos constantes do questionário. De um modo geral, o elemento a ser inicialmente
entrevistado deve ser o chefe do setor em estudo, para que posteriormente se sucedam as entrevistas
com os encarregados das seções componentes do setor, caso se façam necessárias.
Marcação da entrevista : Para a marcação da entrevista, o analista deve fazer uma pré-
abordagem, contactando um subordinado da pessoa a entrevistar, a fim de conhecer a sua maneira de
agir, sua personalidade e aprecisa posição hierárquica. A data, hora e local da entrevista devem ser
de inteira conveniência do entrevistado, pois a experiência nos mostrou que uma entrevista
freqüentemente interrompida por contingência do serviço, perde quase que totalmente sua finalidade
inicial.
Precauções do analista : Confirmar com antecedência, a validade do local e a hora
anteriormente combinados. Tomar o cuidado de ser pontual ao compromisso.
Tempo de duração da entrevista : O tempo de duração dependerá das características de
cada entrevista. O tirocínio do analista garantirá o tempo razoável para cada uma, com o cuidado
para que não se torne fatigante e que quaisquer ocorrências não venham a apressá-la.
O analista não deve se furtar a efetuar o número de entrevistas que se fizer necessário ao
levantamento.
Apresentação : Um dos primeiros passos para uma entrevista é a apresentação do analista
ao entrevistado, que deverá ser feita de preferência pelo superior imediato do entrevistado, o qual
aproveitará a ocasião para explicar os objetivos da análise e as vantagens que representa para a
empresa e, também, para o próprio entrevistado.
Postura correta, simpatia, boa apresentação pessoal, simplicidade, etc., são qualidades
essenciais ao entrevistador. Não devemos esquecer que todo homem dá uma idéia de si mesmo pelo
seu porte, pelo seu olhar, pela sua apresentação, pelo seu aperto de mão. É de utilidade para o
analista o uso de cartões de visita.
Atitude do analista : O analista deve procurar manter uma atitude sincera, amável e atenta,
pois a precisão do levantamento depende das informações do entrevistado. Deve evitar julgamentos
precipitados de valores. Nunca esquecer que o objeto de análise faz parte da vida do entrevistado,
que, em muitos casos, foi ele próprio quem imaginou os instrumentos e os métodos de execução. É
difícil para um indivíduo que conhece seu trabalho a muito tempo admitir que alguém, que nunca o
fez, possa introduzir alguma melhoria ou romper um paradigma.
Deixar o entrevistado falar e tentar entendê-lo são condições básicas para o sucesso da
entrevista, principalmente porque aprende mais quem sabe ouvir. Adaptar o nível de linguagem ao
entrevistado torna-se fundamental, não se pode usar os mesmos termos, fazer as mesmas perguntas e
ter as mesmas atitudes com um operário e com um diretor.
A entrevista deve ser realizada em clima de informalidade, procurando o analista ser
comedido no emprego de termos técnicos. Os bons aspectos do trabalho do entrevistado devem ser
valorizados e elogiados. Segundo Maslow, classificado como uma das necessidades, o
reconhecimento enriquece o ego do ser humano.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 6 - Parte II (Engenharia de Banco de Dados)
Técnica de levantamento : Esta fase consiste na aplicação do questionário e obtenção dos
dados para a análise quantitativa. O levantamento exige muita atenção e cuidado, pois envolve
também problemas de relações humanas. Nem sempre será fácil obter as informações, sobretudo se
o analista não desenvolver sua habilidade para entrevistar dentro da técnica acima apresentada. É
importante ter sempre em mente que de um levantamento incorreto resultará numa análise
deformada da empresa.
Perguntas : As perguntas do questionário poderão ser lidas, com a maior clareza possível,
ou feitas com palavras que o analista considere como mais à altura da compreensão do entrevistado.
O entrevistador deve ser claro, procurando explicar o que deseja e, se necessário, repetir as
perguntas de vária maneiras, até estar seguro de que as mesmas foram perfeitamente compreendidas.
Anotação das respostas : As respostas deverão ser anotadas imediatamente após sua
formulação pelo entrevistado. O analista deve procurar ser sucinto na redação, sem no entanto
permitir que a simplificação prejudique a compreensão posterior das respostas. Pode ser
conveniente, em reforço às anotações, o uso de um pequeno gravador de áudio durante a entrevista.
Caso seja necessário, ao fazer a revisão das anotações, o analista deverá voltar ao
entrevistado para dirimir as dúvidas que porventura surjam.
As anotações devem, preferencialmente, ser feitas na própria cópia do questionário e nos
espaços logo após as respectivas perguntas.
Material utilizado : Durante o levantamento, o analista deve estar equipado com o seguinte
material:
♦ Uma cópia do questionário a se utilizar
♦ Uma cópia dos quadros estatísticos
♦ lápis ou caneta esferográfica
♦ Prancheta para anotações
♦ Bloco para anotações complementares
É obvio que muitas são as variantes, dependendo dos recursos disponíveis, pode se lançar
mão do uso de gravadores, laptops (questionário e respostas em arquivos), etc.
Cuidados durante o levantamento :
♦ Procurar interpretar bem a resposta antes de registrá-la.
♦ Cuidar para que o tom de voz ou o modo de fazer a pergunta não influam na
resposta do entrevistado.
♦ Nas perguntas cujas respostas envolvam opiniões, procurar auxiliar na objetividade
de sua expressão.
♦ Nas perguntas cujas respostas envolvam dados exatos, insistir na exatidão
necessária à analise.
♦ Permitir liberdade de expressão ao entrevistado, sem contudo permitir que fuja ao
assunto da entrevista.
♦ Suspender o levantamento para um coffe break ou similar (em companhia ao
entrevistado) quando sentir queda do ritmo ou da qualidade do mesmo.
Análise e Especificação: O grupo de projetistas deve
ponderar sobre todas as informações obtidas e gerar documentos que
especifiquem as necessidades dos usuários. Caso perceba-se a falta de
alguma informação deve retornar a fase anterior (coleta);
A análise dos dados levantados, por meio dos
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 7 - Parte II (Engenharia de Banco de Dados)
questionários e da observação do analista, é a fase mais importante de todo o processo para se chegar
ao diagnóstico propriamente dito. É quando o analista utiliza realmente todo o seu conhecimento e
sua habilidade.
Quem deve analisar : A análise deve ser realizada pela mesma pessoa que levantou os
dados, pois, como dissemos acima, além das respostas dadas pelos entrevistados e anotadas, também
forma feitas observações que são necessárias à análise. Na realidade a análise de determinados
métodos se inicia, ou mesmo é feita totalmente, na própria fase de levantamento.
Método de análise : Não se pode, evidentemente, estabelecer regras precisas para este tipo
de trabalho, que vai depender da capacidade e experiência do(s) analista(s).
Assim, ao passo que durante o levantamento devemos partir do geral para o particular, na
fase de análise o mais correto é primeiro analisar os detalhes e daí tirar conclusões sobre o todo.
Quanto à prioridade a ser estabelecida para o estudo dos detalhes, estará sujeita ao bom senso do
analista, como de resto grande parte de suas decisões nesta fase de análise.
Projeto Conceitual: Através de uma ferramenta
conceitual (modelo de dados a nível conceitual) um grupo de
especialistas repassa a especificação textual em um diagrama ou
outras forma de linguagem que descreve com clareza as
necessidades dos usuários, isto é chamado modelagem. O
objetivo desta fase é organizar melhor as idéias passadas pela fase
anterior (Análise e Especificação) e perceber alguma falta de
informações e neste caso é necessário retornar;
Projeto Lógico: Através de uma ferramenta
lógica (modelo de dados a nível lógico) um grupo de
especialistas repassa a especificação conceitual em lógica
através de um diagrama ou outra linguagem, isto é chamado
mapeamento. Com esta fase obtém-se a definição lógica dos
arquivos de dados. Especificação lógica depende do SGBD que
será utilizado pois as estruturas dos arquivos devem ser
compatíveis com o gerenciador utilizado;
Projeto Físico : Através de conhecimentos
coletados no requisitos, com relação a freqüência e forma de
utilização dos dados, estabelece-se a organizaçãomais adequada
para os arquivos e os métodos de indexação mais eficientes.
Tipos de Organização de Arquivos:
Heap File (Serial) Sorted File (Seqüencial) 
Hashed File
Métodos de Indexação:
ISAM B Tree B* Tree
B++++ Tree Trie Multilist Inverted File
Double Chained Tree
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 8 - Parte II (Engenharia de Banco de Dados)
Implantação: Tendo a especificação dos arquivos
pode-se implanta-los, através da linguagem DDL para formarem
um BD;
Verificação e Validação: Os testes são
realizados medindo a satisfação dos usuários em
termos de velocidade e o padrão com que os dados
são apresentados;
Acompanhamento da Qualidade: o DBA
deve permanecer atendo a mudanças de requisitos de modo a
perceber alterações nas especificações anteriormente corretas;
Manutenção: A insatisfação de um usuário ou mesmo
modificação no mini-mundo (expansão da empresa, etc.) pode exigir
pequenas alterações na estrutura do BD. Mudanças drásticas como por
exemplo modificações no organograma de uma empresa podem
exigir um trabalho maior na restruturação do BD (reengenharia).
A similaridade do processo de Engenharia de BD com a
Engenharia de Software não é coincidência. Na verdade pode-se
dizer que ambas são complementares, uma vez que na Engenharia
de Software é necessário a criação dos arquivos de dados (BD) e na Engenharia de BD é necessário a
criação dos programas aplicativos (software) que irão operar o Banco de Dados.
3. MODELOS DE DADOS
Um Modelo de Dados é um conjunto de conceitos utilizados para descrever a estrutura de
um BD a nível conceitual, lógico ou físico. Os modelos apresentam um conjunto de operações para a
especificação e manipulações dos dados do BD. Os tipos de modelos existentes na literatura se
classificam em:
A). Modelos Baseados em Registros: são modelos que fornecem conceitos de modelagem
a nível lógico utilizando-se da representação de registros. Comercialmente, os modelos mais
encontrados são o Rede, Hierárquico e Relacional;
B). Modelo Semânticos: são modelos conceituais que apresentam uma capacidade maior
de representação fiel de um problema, pela simples razão de possuir conceitos mais elaborados.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 9 - Parte II (Engenharia de Banco de Dados)
Exemplos de modelos desta categoria são o Modelo Entidade-Relacionamento (MER) e o Modelo
Funcional;
C). Modelos Orientados a Objetos: são modelos conceituais que procuram representar e
estruturar Bancos de Dados através
do paradigma de “Orientação a
Objetos”. Este tipo de modelo esta
em grande destaque mundial
(inclusive no Brasil) nas pesquisas
atuais. Alguns dos modelos em
pesquisa são: O2 (França); PCTE
(Comunidade Européia) ;Orion
(EUA) e o Modelo de Representação
de Objetos - MRO (Brasil -
USP/São Carlos).
O reflexo das
necessidades evolutivas do mercado pode ser cronologicamente visualizado através dos diversos
Modelos de Dados desenvolvido, desde os Modelos Baseados em Registros passando pelos
Semânticos até os recentes Modelos Orientados a Objetos, como pode ser visualizado pela figura
abaixo.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 10 - Parte II (Engenharia de Banco de Dados)
4 - MODELAGEM DE DADOS
Atualmente o Modelo de Dados Conceitual mais difundido e utilizado para a modelagem
de dados é o MER criado por Peter Chen. O resultado da modelagem utilizando o MER é um
diagrama (DER)
bastante simples porém
de grande utilidade.
Tendo
exatamente definido
qual o problema ser
resolvido, ou seja,
tendo determinado as
fronteiras que
delimitam e restringem
o mini-mundo a ser
modelado e realizado a
especificação, utiliza-se
um roteiro a ser
seguido para se
determinar uma
primeira versão do
DER.
Após criada a
primeira versão do
DER deve-se
apresentar aos usuários
para que sejam
verificados a corretude
e completude do diagrama. Sucessivas apresentação do DER devem ser realizadas enquanto foram
detectados falhas na representação.
À primeira vista pode-se pressupor que esta rotina de trabalho trará atrasos na construção
do Banco de Dados, porém os especialistas em engenharia (software, mecânica e etc) sabem da
extrema importância da fase de projeto. Erros ocorridos nesta fase acarretam graves atrasos e
aumento no custo de realização do produto. Por esse motivo, o MER se tornou uma ferramenta de
modelagem entre as mais difundidas, estimadas e utilizadas no mercado de informática.
5 - MAPEAMENTO
O Modelo Entidade Relacionamento é responsável por realizar uma representação dos
dados de uma determinada aplicação a um nível mais conceitual, um pouco distante da forma como
os seus elementos serão efetivamente implementados. Os modelos de registros, dentre eles Modelo
Relacional (mais usado), fornece uma representação dos dados de forma mais próxima como estes se
encontrarão quando forem definidos os arquivos para o BD.
A passagem do diagrama do MER para a representação do Modelo Relacional é
denominado Mapeamento do MER para o Relacional e é uma das técnicas mais utilizadas por ser
uma ligação entre os modelos de dados mais utilizados.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 11 - Parte II (Engenharia de Banco de Dados)
Existem outros mapeamentos estabelecidos como :
- MER para o Modelo Rede; e
- MER para o Modelo Hierárquico,
contudo não serão abordados nestas notas por serem pouco utilizados.
6 - NORMALIZAÇÃO
O processo de Normalização é uma etapa complementar ao Mapeamento e consiste da
aplicação de uma série de regras (Formas Normais). Estas regras irão provocar algumas
modificações na especificação lógica. A Normalização permite ao projetista definir quanto da
consistência é garantida pela estrutura dos arquivos e quanto deve ser responsabilidade dos
aplicativos e/ou do SGBD. Deve ser realizada alguma ponderação: normalizar demais diminui a
eficiência dos aplicativos e de menos abre flancos para inconsistências.
7 – EVOLUÇÃO DO ESQUEMA DE DADOS
O ciclo de vida de um Sistema de Informações típico pode ser especializado para Sistemas
de Bases de Dados (“Micro Life Cycle”) cujas fases teriam as seguintes denominações: Definição,
Projeto Conceitual, Lógico e Físico (“Design”), Implementação, Implantação de dados e aplicativos,
Teste/Validação, Operação, Monitoramento e Manutenção. Particularmente, as fases de Operação e
Monitoramento são permanentes e, em respostas as suas execuções, podem necessitar da ativação da
Manutenção.
A Manutenção de um SBD pode envolver a troca e/ou reciclagem de qualquer de seus
componentes: “hardware” (computadores e equipamentos); “software” (ambientes, aplicativos,
SGBD, componentes e estruturas da BD); “peopleware” (usuários comuns, programadores e
DBA’s); e até mesmo das técnicas empregadas (modelagem e linguagem).
Em termos de componentes da Bases de Dados, BD Intencional (Esquema de Dados1) e
BD Extensional (Instâncias), a flexibilidade para a Manutenção é determinada pela adequação de
seu projeto e pela capacidade funcional de seus respectivos SGBD’s. Essa habilidade, que pode-se
denominar Evolução2, é atualmente um fator diferenciador entre as BD’s existentes, e pode depender
tanto do Modelo quanto de sua implementação.
Para outros componentes e aspectos de um Sistema de Bases de Dados, a Evolução recebe
diversas denominações e/ou variações. No entanto, no que se refere particularmente à Manutenção
da Base de Dados Intencional, a denominação técnica predominante na literatura atualmente é
“Evolução do Esquema de Dados”, em gradativa substituição ou incorporação de semântica com o
antigo termo Reorganização.
Apesar de ser um tema ha muito discutido, não existe nenhuma norma ou padrão que
regularize a Evolução do Esquema de Dados como um processo de trabalho. Isso possibilita sua
abrangência e desdobramento para inúmeras situações, e desta forma, as variações entre as diversas1 Esquema de Dados: repositório de conhecimento sobre as estruturas da Base de Dados. Em alguns
paradigmas, o Esquema dificilmente pode ser separado do Modelo de Dados. (definição segundo RODDICK).
2 Evolução, em um sentido amplo, pode ser definida como uma habilidade ou um processo de adaptação a
novas situações (internas ou externas), de modo a manter uma estabilidade relativa ou para melhorá-la, determinada e em
conformidade com os requisitos relacionados ao meio (ou ambiente).
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 12 - Parte II (Engenharia de Banco de Dados)
pesquisas existentes sobre este tema permite abordar a Evolução do Esquema de Dados sobre
diversos enfoques.
7.1 - TEMAS RELACIONADOS
7.1.1 - TEMPO 3
O Tempo é uma parte essencial e determinante dos dados em função da constante mutação
envolvendo o mundo real. Os Eventos (fatos ou acontecimentos) e dados precisam ser interpretados
no contexto do Tempo; baseado neles são criadas Transações, ou operações sobre as informações do
Esquema de Dados, cujos valores anteriores podem ser retidos historicamente em uma Base de
Dados Temporal (BDT), de acordo com um parâmetro temporal mensurável (Tempo da Transação,
Tempo Válido, Tempo Real).
O controle de parâmetros temporais apresenta-se envolvido com o tema “Evolução do
Esquema de Dados”. Contudo, não se deve relacioná-los em uma associação de interdependência de
“serviços”, pois a representação de aspectos temporais das informações está intimamente ligada ao
registro histórico de alteração de valores, que por sua vez, é uma alternativa entre os procedimentos
que envolvem a Evolução do Esquema.
7.1.2 - REGRAS 4
A capacidade de expressar a Evolução, na sua forma mais simples/primitiva, pode ser
encontrada em Regras para a manutenção da consistência do Esquema de Dados. Para esse fim,
existem Sist. de Gerenciamento de Regras (SGBD/SGR) que controlam a disponibilidade e
veracidade lógica dos dados, e que tornam a Evolução de informações uma tarefa involuntária, que
não depende de avaliações ou comandos do usuário.
7.1.3 - VERSÕES 5
Versões são normalmente utilizadas para apoiar a recuperação de dados, para o controle de
concorrências de curta ou longa duração utilizando-se de operações de “check-in” para gerar Versões
e posteriormente “check-out” para integrá-las, ou para a realização de distribuição dinâmica da Base
de Dados. Apesar dessas funções e de outras bastante consolidadas, é cada vez mais freqüente a
colocação de Versões como sendo individualmente importantes, porém não necessariamente
obrigatórias, em aplicações que realizam atividades relacionadas a Evolução de Esquemas.
 
3 Tempo pode ser definido como um parâmetro de variação continua da caractéristica de qualquer objeto, e
que pode ser simbolizado por números reais ou inteiros, extraídos de uma seqüência equidistante de valores
representativos da unidade de tempo escolhida.
4 Regras são formadas pelos conjuntos {Evento, Condição, Ação} e representam o “Conhecimento
Procedural” que retrata a definição e forma de atuação de mecanismos internos de controle, como por exemplo,
restrições de integridade.
5 Versão é uma descrição do aspecto de um objeto e que se estabelece no contexto da aplicação de modo a
definir um marco delimitador do trabalho realizado ou a realizar-se. Sua utilização é bastante flexível, ou seja, sobre as
Versões pode-se realizar quaisquer operações (leitura/escrita, remoção, atualização e criação) desde que definidas pelo
Modelo de Versões seguido.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 13 - Parte II (Engenharia de Banco de Dados)
7.2 - MOTIVAÇÃO
A Manutenção da Base de Dados, com relação ao Esquema e sempre sob a supervisão da
Administração (DBA), era motivada apenas pela deterioração da performance causada pelas
constantes atualizações (restruturações) do Esquema. Se não fosse evitada, esta deterioração elevava
os custos de acesso às informações e consequentemente inviabilizava a utilização de uma Base de
Dados.
Atualmente, o reconheci-
mento das necessidades de Evolução
do Esquema de Dados é uma tarefa
mais complexa, e dela surgem diversas
questões tais como: O que deve ser
alterado? Quando deve ser realizado?
Como realizar? Quais os benefícios?
Qual o custo desse processo? Quem
será afetado? e outras interrogações
que devem fazer parte da política de
Manutenção do SBD.
Mesmo com a complexidade
desse tema, o seu elevado grau de
aplicabilidade torna-o funcionalmente
necessário em várias situações e por diferentes motivos, dentre os quais cita-se:
• Correção do Esquema de Dados diante de problemas encontrados durante a Fase de
Operação com a Base de Dados.
• Adaptação do Esquema de Dados aos novos componentes e/ou circunstâncias que
envolvem o Sistema de Base de Dados e seu ambiente de utilização.
• Refinamento de componentes do Esquema que foram pouco detalhados durante a fase de
projeto e portanto estavam semanticamente pobres.
• Atualização de componentes do Esquema de modo a acompanharem as constantes
modificação de requisitos dos usuários e a evolução do empreendimento.
• Experimentação de novas concepções do Esquema de Dados em momentos quando
buscam-se alternativas para a modelagem da Base de Dados.
• Incorporação de novos elementos ao Esquema de Dados.
• Integração de Bases de Dados completas na forma de: “Federated Database” (FDB)
através de uma metodologia “Bottom-up” que integra várias BD para a criação da FDB ou em uma
metodologia “Top-Down” para incorporação de uma BD à uma FBD existente; “SuperViews” - uma
virtual integração de múltiplas BD’s; ou “MultiDatabases Systems” (MDBS) - confederação de
preexistentes, autônomos e possivelmente heterogêneos SBD’s.
7.3 - CLASSIFICAÇÃO
Uma classificação dos trabalhos de pesquisa sobre o tema “Evolução de Esquemas de
Dados” pode ser muito útil para aqueles que se propõem a desenvolver um Modelo de Dados e/ou
Deterioração da BD
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 14 - Parte II (Engenharia de Banco de Dados)
um SGBD com capacidade de Manutenção da Base Intencional. Neste sentido, pode-se relacionar
três linhas de trabalho para a Evolução6:
• Projeto: voltada ao problema de Evolução do Esquema ao nível de técnicas de Projeto da
Base de Dados e de gerência de grupos de DBA’s;
• Forma (Física): voltada ao problema de Evolução do Esquema Físico e de suas
conseqüências (Restruturação/Reformatação) para a Base de Dados;
• Lógica: voltada ao problema de Evolução do Esquema Físico/Conceitual e do Esquema
Externo (Visões do usuário). Estuda especialmente as operações de alteração do Esquema lógico, as
Técnicas de Evolução de Esquemas empregadas e as Estratégias de Propagação das atualizações na
BD Intencional.
Em um nível Físico ou Lógico, a Administração (DBA) do Sistema de Bases de Dados
pode optar por duas estratégias básicas, em um processo de Evolução do Esquema de Dados que
envolve alterações reais na BD. Dependendo do grau de complexidade e abrangência, estas
alterações são realizadas:
- Off-line: esta estratégia interrompe todos os processos em andamento enquanto a BD está
sendo reorganizada. É
executada em um período
de pouca requisição de
dados, pois os usuários
comuns têm seus pedidos
de acesso negados durante
o período em que as
alterações na BD estão
sendo realizadas;
- On-line: esta estratégia
mantém o SBD em
operação enquanto se
realiza a Evolução do
Esquema. É recomendada
para aqueles SBD’s que
são “críticos” para seus
usuários; ou para BD que
envolvem grande volume
de dados. A reorganização
e utilização da BD são
processos concorrentes,
controlados de forma que o
usuário comum possa ter
suas requisições atendidas enquanto uma porção da BD é atualizada.
 
6 O interrelacionamento entre as três linhas de Evoluçãodo Esquema é bastante significativo para tratá-los
separadamente.
Usuário
Evolução da BD
Evolução "Off-line"
Usuário
Evolução da BD
leitura
escrita
Evolução "On-line"
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 15 - Parte II (Engenharia de Banco de Dados)
7.4 - EVOLUÇÃO DO PROJETO
Para o Projeto, a Evolução do Esquema de Dados envolve o retorno às fases de Definição
e “Design”, e consequentemente implica em nova Implementação, Implantação, Teste/Validação e
Operação, dependendo do grau de Manutenção realizada. Para isso, foram criadas técnicas
específicas no que se refere ao SBD e outras genéricas envolvendo Sistemas de Informação como
um todo.
7.4.1 - PROJETO DE SISTEMAS DE BASE DE DADOS
A Evolução do Esquema de Dados pode ser tratada em técnicas que enquadram-se dentro
do ciclo de vida de Sistemas de BD (“Micro Life Cycle”):
• “Schema Integration”: metodologias para a divisão do processo de Projeto em diversos
Esquemas de Dados que representam partes de uma aplicação. Subseqüentemente, estas partes são
integradas em um Esquema unificado.
• “Translation of Schemes”: metodologias para a “tradução” do Esquema representado em
um “Modelo de Dados origem” para um “Modelo de Dados destino”, utilizando-se da representação
do Esquema de Dados em um Modelo de Dados “intermediário” com grande capacidade de
abstração.
• “Schema Reuse” : metodologias de representação, armazenamento e reutilização de
componentes de um Esquema de Dados.
A Reutilização de componentes de um Esquema exige cooperação entre os projetista,
padronização de conceitos e terminologias, além obviamente de uma “biblioteca” para o
armazenamento dos componentes reutilizáveis. Apesar destas e de outras dificuldades, o objetivo a
ser atingido é o incremento da produtividade e qualidade de desenvolvimento e mesmo de
manutenção.
7.4.2 - PROJETO DE SISTEMAS DE INFORMAÇÃO
Em um contexto mais amplo, a Evolução do Esquema de Dados pode ser enquadrada em
técnicas de engenharia e/ou de desenvolvimento de um Sistemas de Informação (“Macro Life
Cicle”):
• “Reverse Engineering”: metodologias para o reconhecimento e representação dos
aspectos estruturais, funcionais e comportamentais de um Sistema de Informações já implantado.
• “Reengineering”: metodologias para a conversão de Sistemas de Informação apoiados
em ambientes ultrapassados/obsoletas para tecnologias mais modernas. Especificamente em
Engenharia de Sistemas, a Reengenharia introduz técnicas para o reestudo e conversão de sistemas
ultrapassados para novas realidades e o conseqüente reprojeto de Bases de Dados.A Reengenharia
pode ser composta por três fases: Engenharia Reversa, Delta (∆) e Engenharia Avante. A Engenharia
Reversa realiza um definição abstrata e clara de representação do Sistema. Na fase Delta estabelece-
se as modificações no Sistema, que pode incorporar novas funcionalidades (∆ positivo) ou pode
reduzi-las (∆ negativo), e exigir uma completa ou parcial implementação. A terceira e última fase,
Engenharia Avante, refere-se ao desenvolvimento normal do Sistema seguindo-se as etapas naturais.
• “Concurrent Engineering” : metodologias criadas inicialmente para as áreas de
engenharia convencionais (mecânica e elétrica) e que estabelecem o desenvolvimento simultâneo de
um “produto” através da cooperação de grupos de projetistas trabalhando separadamente porém em
constante comunicação e troca de informações. A Engenharia Concorrente adapta-se
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 16 - Parte II (Engenharia de Banco de Dados)
consideravelmente ao processo de engenharia de Sistemas de Informação grande e complexos, mas
para isso devem existir sistemas de apoio ao trabalho cooperativo entre os grupos de projeto,
denominados “Groupware”, que são abordados na área de CSCW (“Computer Support Cooperative
Work”).
7.5 - EVOLUÇÃO DA FORMA
Alterações dos requisitos de desempenho, mudanças no Modelo de Dados, no SGBD ou
na arquitetura do SBD (ex. distribuição), por exemplo, podem provocar profundas reformas na BD
como um todo. Estas reformas iniciam-se no contexto organizacional do empreendimento e podem
atingir vários processos e sistemas. Particularmente em SBD’s, a Administração (DBA) fica
obrigada a um criterioso processo de Restruturação da composição física da BD (ou Reformatação
de seus arquivos de dados).
7.6 - EVOLUÇÃO DA LÓGICA
A Evolução, em um nível lógico, pode ocorrer sobre o Esquema Físico/Conceitual ou
sobre o Esquema Externo (Visões) em dois níveis de granularidade:
• Domínios/Tipos: são alterações de tamanho, de valores ou de nomes dos Domínios/Tipos
de Atributos e apesar de representarem modificações muito simples em termos de modelagem,
podem refletir em violações de restrições semânticas nas Instâncias, caso não sejam fortemente
controladas.
• Conjuntos (Relações e Classes): são modificações mais complexas nas definições dos
conjuntos e que incluem alterações estruturais, funcionais e comportamentais nos Esquemas de
Dados.
7.6.1 - ESQUEMA FÍSICO
A Evolução do Esquema Físico/Conceitual envolve operadores e operações críticas sobre
aspectos estruturais e comportamentais dos elementos do Esquema que podem implicar em
alterações das Instâncias (Evolução de Instâncias7) envolvidas e modificações nos programas
aplicativos que utilizam estas Instâncias (Adaptação dos Aplicativos). Essa estreita relação entre
Instância e Esquema, e mesmo a associação lógica entre os elementos alterados e inalterados de um
Esquema gera a necessidade de Técnicas de Evolução de Esquema e de Estratégias de Propagação
nas Instâncias.
Cada Modelo de Dados define os elementos existentes em seu Esquema, uma taxonomia
de operações de alterações de Esquemas e as regras semânticas para a execução das ações evolutivas
que geram um “novo” Esquema. Toda ação de alteração do Esquema deve passar por filtros de
integridade, nos quais a consistência do “novo” Esquema é verificada com base nas invariantes do
Modelo de Dados, ou seja, em um conjunto de condições, restrições e/ou recomendações para cada
uma das operações de alteração permitidas.
 
7 A Evolução de Instâncias em uma BD não é fundamentalmente motivada pela Evolução do Esquema desta
BD, ou seja, mesmo não havendo alterações no Esquema de Dados pode ser necessária modificações em Instâncias, por
exemplo, migrar um Objeto para uma outra Classe ou especializar um Objeto.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 17 - Parte II (Engenharia de Banco de Dados)
7.6.1.1 - TÉCNICAS DE EVOLUÇÃO DE ESQUEMA
As Técnicas de Evolução de Esquema não possuem denominações usuais, mesmo porque
não foram classificadas. A “operação básica”, nas quais as técnicas fundamentam-se, pode ser usada
como critério para uma classificação, mas nenhuma dessas técnicas é detalhada ao ponto ter sua
aplicabilidade diminuída. Deste modo, todas são capacitadas para o uso nas mais diferentes
aplicações, mesmo porque cada técnica foi aprimorada ou estendida buscando uma compreensão
genérica dos problemas.
- “CREATING/MODIFICATION”
Esta técnica se baseia na modificação do Esquema de Dados em uso. Para isso, é criado
um “novo” Esquema utilizando-se ou não uma cópia do Esquema já implantado. As modificações no
“novo” Esquema devem ser de pequena grandeza, ou seja, poucas e pequenas alterações em relação
ao Esquema implantado, mesmo que tenham grande influência sobre as Instâncias.
Normalmente, as modificações do Esquema comportam operações simples (ex. “create”,
“delete” e “change”) descritas em comandos contidos na DDL (“Data Definition Language) e
geralmente, o Esquema de Dados “abandonado” é eliminado da BD, contudo, opcionalmente,
permite-se mantê-lo armazenado somente para revisões, dependendo do Modelo de Dados utilizado
e do suporte às “antigas” instâncias.
- “ADDITIONAL”
Esta técnica de Evolução do Esquema temcomo característica a adição de novos
elementos ao Esquema de Dados implantado, ou seja, a motivação desta técnica é acrescentar uma
quantidade significativa de novos componentes de representação ao Esquema de Dados. A adição de
uma grande quantidade de componentes ao Esquema de Dados caracteriza sua extensão para novos
contextos de representação do empreendimento.
Aliada a uma abordagem própria para a realização do Projeto da Base de Dados, esta
técnica pode oferecer meios para a adição de sub-esquemas (ex. Esquemas Suplementares) ou
mesmo de incorporação gradativa do Esquema de Dados em relação às Instâncias que já encontram-
se armazenadas na Base de Dados (ex. “approach bottom-up”, “Incomplete Information”). Para isso,
requerem-se controles especiais que permitam a adição de novos elementos ao Esquema e que não
comprometam nenhum aspecto do processo de manipulação de Instâncias.
- “SCHEMA VERSIONING”
Esta técnica propõe a criação de Versões do Esquema como uma forma de realizar sua
Evolução. Sua implantação no SGBD deve permitir uma navegação retroativa ou proativa entre as
Versões tanto para a realização de operações lógicas quanto físicas nas Versões.
Dependendo da implementação e Modelo de Dados, as Versões “antigas” do Esquema de
Dados podem ficar inativas indefinida ou momentaneamente, ou podem ter iguais condições de uso,
ou seja, a instanciação pode ser realizada em qualquer Versão do Esquema, e neste caso, passa a
existir o conceito de Esquema Corrente (ou Esquema Ativo, formado pelas Versões de Esquema
requisitadas) com as Instâncias sendo reconhecidas pelo SGBD somente quando sua definição está
no Esquema em uso corrente.
As Versões podem ser realizadas sobre todo o Esquema de Dados ou sobre uma parte (ex.
definição de algumas classes), dependendo do grau de Evolução que sofrerá o Esquema em uso, da
granularidade do Modelo de Versões seguido e da implementação (Sistema de Gerenciamento de
Versões - SGBD/SGV).
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 18 - Parte II (Engenharia de Banco de Dados)
Um controle rigoroso deve ser implementado no gerenciamento do Esquema, que permita
a criação de Versões coerentes com a taxonomia de operações de alterações do Esquema em relação
ao Modelo de Dados. Sendo, talvez, um processo de longa duração e de grande complexidade,
pode-se optar pela criação simultânea de Alternativas para uma Versão do Esquema, ou seja, o
desenvolvimento paralelo de possíveis Versões do Esquema de Dados.
Ao final do processo de criação, as Alternativas são confrontadas para a escolha daquela
que melhor representa o empreendimento em sua nova concepção e que se tornará uma Versão do
Esquema. As Alternativas podem passar também por uma operação de “conversational merging”,
onde busca-se aglutinar as melhores soluções ou inovações apresentadas em cada Alternativa para
formar uma Versão do Esquema.
7.6.1.2 - ESTRATÉGIAS DE PROPAGAÇÃO NAS
INSTÂNCIAS
Na literatura científica, pode-se encontrar classificações aparentemente estabelecidas para
as Estratégias de Propagação, que descrevem basicamente a abordagem usada para repassar o
“novo” Esquema de Dados para a BD Extensional. Pode-se encontrar também muitas variações
dessas estratégias para adaptá-las a problemas específicos. No entanto, essas estratégias atualmente
enquadram-se em categorias descritas a seguir.
- “COPYING”
A Cópia apresenta uma abordagem simples porém muito utilizada nos SGBD’s. Nela,
após o estabelecimento de um “novo” Esquema, realiza-se de uma única vez a transposição imediata
das Instâncias envolvidas na Evolução, ou então, realiza-se a transposição incremental de
subconjuntos das Instâncias envolvidas até que todas tenham sido alteradas. A transposição das
Instâncias envolvidas é realizada através da criação de cópias8 de seus dados para a nova situação
(do Esquema em uso para o “novo” Esquema).
A desvantagem desta abordagem se estabelece no tempo consumido para a concretização
das cópias de acordo com o “novo” Esquema de Dados, o que pode depender da implementação
desenvolvida pela Administração (DBA).
- “UPDATING”
Nesta estratégia, a passagem para um “novo” Esquema de Dados ocorre pela Conversão de
suas Instâncias. Quando a conversão das Instâncias envolvidas é realizada imediatamente após a
criação do “novo” Esquema de Dados, a estratégia recebe a denominação de Conversão Imediata
(“Immediate update” ou “eager update”). A desvantagem da Conversão Imediata apresenta-se no
tempo consumido para a concretização de todas as conversões em uma única vez, de acordo com o
“novo” Esquema de Dados.
Outra opção consiste em converter as Instâncias durante sua manipulação, através da
Conversão Incremental (“Delayed update” ou “Lazy update”). A cada informação acessada pelo
SGBD, é reconhecido seu Esquema de Dados e verificada a existência de alguma indicação de
Evolução; caso alguma seja encontrada, o SGBD realiza a conversão da porção acessada da
informação para o “novo” Esquema.
 
8 A Cópia original de Instância ou Esquema é operacionalmente restritiva em sua utilização, ou seja, sobre a origem
de uma Cópia pode-se apenas realizar consultas em apoio a operações mais complexas de Evolução. Por outro lado, a Cópia
resultante terá as restrições de operação originalmente atribuídas ao elemento copiado.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 19 - Parte II (Engenharia de Banco de Dados)
A desvantagem desta abordagem se estabelece na velocidade de execução das requisições
dos dados que não encontram-se convertidos, ou seja, para os pedidos de manipulação de dados
ainda não convertidos, ocorrerá um certo atraso na apresentação, pois o SGBD deverá realizar a
conversão para o “novo” Esquema antes de retornar uma resposta.
- “SCREENING”
Mapeamento (ou “Screening”) consiste em prorrogar indefinidamente (“deferred-update”)
a atualização das Instâncias mesmo após o “novo” Esquema ser criado, ou seja, nenhuma alteração
física é realizada nas informações instanciadas até que a reorganização da Base de Dados seja
exigida explicitamente por um usuário qualificado.
A cada informação acessada pelo SGBD, é reconhecido seu Esquema de Dados e
verificada a existência de alguma indicação de Evolução. Caso alguma seja encontrada, o SGBD
realiza a adaptação lógica da informação segundo o “novo” Esquema, que age como um “filtro” para
criar a ilusão de Instâncias modificadas.
Esta estratégia compromete a velocidade de execução de qualquer operação de
manipulação de dados, uma vez que as informações apresentadas aos usuários devem ser
transformadas de acordo com o “novo” Esquema (filtro).
- “VERSIONING”
Nesta estratégia, um “novo” Esquema de Dados, ao ser instanciado, leva à criação de
Versões das Instâncias atingidas, de acordo com a granularidade imposta pelo Modelo de Versões.
Dependendo também da implementação, as Versões de Instâncias podem ter diferentes graus de
flexibilidade para a manipulação, ou podem ter iguais condições de uso.
As Versões de Instâncias podem ser criadas gradativamente pelo usuário, desde que
monitoradas pelo SGBD, ou podem ser geradas automaticamente pela cópia/conversão, imediata ou
incremental, de uma Versão de Instância para outra, desde que seja utilizado o Esquema de Dados
correspondente.
Esta abordagem não apresenta desvantagem significativa, apenas requer um nível maior de
controle das Instâncias, normalmente realizado por um Sistema de Controle de Versões, que
normalize as atividades de criação, manipulação e consulta das Versões de Instâncias que podem
habitar simultaneamente a Base de Dados.
- “MATERIALIZING”
O objetivo desta estratégia não é atingir as instâncias já existentes através de operações de
cópia, atualização, conversão lógica ou criação de Versões, mas sim realizar novas instanciações
(“materialização de Instâncias”) de acordo com o “novo” Esquema de Dados. AsInstâncias já
existentes e seu Esquema de Dados permanecem inalterados e possivelmente utilizáveis por
qualquer usuário qualificado.
Particularmente, esta estratégia não requer controles especiais e não compromete nenhum
aspecto do processo de manipulação de Instâncias, porem exige do SGBD a capacidade de
reconhecer o Esquema de Dados de cada Instância dos dados armazenados e a flexibilidade para a
“Materialização das Instâncias” em momentos propícios para os usuários.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 20 - Parte II (Engenharia de Banco de Dados)
7.6.1.3 - TÉCNICAS DE EVOLUÇÃO VERSUS
ESTRATÉGIAS DE PROPAGAÇÃO
As Técnicas de Evolução do Esquema de Dados (“Creating/Modification”, Additional” e
“Schema Versioning”) podem conviver em um mesmo sistema, isto porque, são complementares em
alguns aspectos de aplicabilidade, tornando-se útil ao DBA nas diversas situações evolutivas.
As Estratégias de Propagação apresentam algum tipo de deficiência e comprometimento
da velocidade de execução das operações de manipulação de Instâncias quando é efetivada a
propagação da Evolução para a Base de Dados Intencional. Por este motivo, uma SGBD não deve
apoiar-se exclusivamente em uma única estratégia.
A Tabela abaixo mostra as possibilidades e impossibilidades de composição entre as
Técnicas de Evolução de Esquema e as Estratégias de Propagação em Instâncias. Não existe um
estudo prático sobre estas composições, mesmo porque nunca foram explicitamente apresentadas
desta forma.
Confronto entre Técnicas de Evolução de Esquema e Estratégias de Propagação em Instâncias
As situações não permitidas devido aos princípios que regem as Técnicas de Evolução e as
Estratégias de Propagação são:
• A - A Técnica de “Creating/Modification” parte do princípio que existirá apenas um único
Esquema de Dados (“novo”) e considera o Esquema de Dados que está sendo substituído como um
elemento de apoio para cópia, conversão ou mapeamento e portanto, não existe a possibilidade ou
necessidade de existirem Versões de Instâncias para o Esquema modificado.
• B, C, D - A Técnica “Additional” pratica a adição de “novos” componente ao Esquema de
Dados, e portanto não enquadra-se nas Estratégias de “Copying”, “Updating” e “Vesioning” pelo
fato destas estratégias realizarem a intermediação entre dois estados de cada um dos componente
focalizados na Evolução do Esquema
• E - A Técnica de “Schema Versioning” propõe a existência de Versões do Esquema de
Dados em iguais condições de utilização, e portanto não pode-se simplesmente realizar a Cópia das
Instâncias de uma Versão para outra, o que restringiria a utilização das Instâncias copiadas.
O conteúdo sintático e semântico das composições permitidas entre as Técnicas de
Evolução e as Estratégias de Propagação pode sofrer variações, mesmo porque, alguns Modelos de
Dados incorporam várias destas composições buscando flexibilizar a Manutenção da Base de Dados.
As composições possíveis são:
• 1 - Partindo-se do “novo” Esquema, criado e modificado com base no Esquema original,
realiza-se a cópia das Instâncias para a nova situação.
Copying Updating Screening Versioning Materializing
Creating/Modification 1 2 3 A 4
Additional B C 5 D 6
Schema Versioning E 7 8 9 10
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 21 - Parte II (Engenharia de Banco de Dados)
• 2 - O Esquema criado é utilizado para a atualização (imediata ou incremental) das
Instâncias de um estado para outro na seqüência Evolutiva.
• 3 - O Esquema original da operação de cópia pode ser mantido na BD para uma possível
navegação retroativa (além do mapeamento), desde restrita apenas à consulta. O SGBD sustenta o
armazenamento das Instâncias vinculadas ao Esquema de Dados, mantendo os vínculos entre as
Instâncias e os Esquemas ativo e inativo para torná-las operacionais segundo os desejos de consulta
dos usuários com privilégios de acesso.
• 4 - Alguns poucos componentes podem ser alterados ou acrescentados ao “novo”
Esquema e neles realiza-se a instanciação.
• 5 - Certos componentes adicionados ao Esquema de Dados não podem ser visualizados
logicamente pelos usuários, o que caracteriza a estratégia de “Screening”.
• 6 - A adição de novos elementos ao Esquema de Dados deve provocar a instanciação
destes elementos. Assim, as Instâncias que já existem podem não ser atingidas e outras podem sofrer
o acréscimo de algumas informações (relacionamentos, atributos e até classes).
• 7 - Mantêm-se as Versões do Esquema e seus procedimentos de conversão para que se
realizem todas as alterações. No caso do Modelo de Dados incluir também os procedimentos de
restauração, tem-se caracterizado uma Conversão “Direcionada”, em que operações
“update/backdate” são realizadas de acordo com a demanda de manipulação, utilizando-se Versões
de Esquema escolhidas pelo usuário.
• 8 - Os procedimentos de conversão são mantidos inoperantes até que opte-se pela
Reorganização. Pode-se manter a Reorganização indefinidamente e possibilitar que os usuários
tenham diferentes “visões” das Instâncias, uma vez que são mantidas as interelações (ou
mapeamento) entre as Versões do Esquema. Desta forma, cada informação terá um Esquema real
(físico) e poderá adaptar-se a diversas Versões de Esquema (lógico).
• 9 - As Versões de Instâncias são criadas de acordo com as Versões de Esquema de Dados,
ou seja, no momento em que é estabelecida uma Versão consistente de um “novo” Esquema, pode-
se iniciar o processo de criação automática (imediata ou incremental) de Versões das Instâncias
atingidas pela nova Versão de Esquema. Tanto para as Versões de Esquema que possam existir,
quanto para suas respectivas Versões de Instâncias, deve existir meios para flexibilizar seu uso e
navegabilidade.
• 10 - As Versões de Instâncias são criadas gradativamente pelo usuário de acordo com as
Versões de Esquema de Dados.
7.6.2 - ESQUEMA EXTERNO (VISÃO)
As Visões estabelecem uma independência lógica de dados, de modo que, Evolução no
Esquema Lógico pode não afetar as Visões definidas e vice-versa. No entanto, quando constatada a
necessidade de Evolução das Visões, requerem-se estudos de redefinição de suas definições (por
seleção, projeção, junção) e suas implantações dinamicamente em momento apropriados
estabelecidos pela Administração (DBA).
Um conjunto de Visões pode simular um Esquema de Dados reorganizado, preservando
ou reduzindo sua capacidade de representação. Infelizmente, o aumento da capacidade de
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 22 - Parte II (Engenharia de Banco de Dados)
representação não é possível sem um processo mínimo de Evolução Lógica do Esquema de Dados e
de uma Estratégia de Propagação.
8 – PADRÕES E NORMAS
Em todas as áreas tecnológicas encontram-se tópicos de grande interesse e destes se
originam diversas linhas de pesquisa cujas intenções são normalmente enriquecedoras. Todavia, essa
busca por inovações traz à discussão as propostas que se apresentam e consequentemente muitos
conflitos, ambigüidades e indefinições são gerados tanto em um contexto nacional quanto
internacional.
Os Padrões surgiram para agrupar, harmonizar e conciliar pesquisadores e empresas com
objetivos e idéias (ou ideais) em comum, criando-se meios para tornar viável, aceitável, acessível e
consolidado todas as novas tecnologias, e deste modo formar uma base de suporte técnico que
assegure seu domínio público.
Pelas inúmeras áreas, sub-áreas ou especialidades que são abrangidas nos diversos Órgãos
de Padrões formais e legislativos, alguns citados na tabela 1, e mesmo pela existência de
sobreposições e simultaneidade entre os trabalhos realizados, há necessidade de uma classificação e
mapeamento dos Padrões que possibilite a coexistência vinculada de suas contribuições.
 Há também muitos consórcios, associações e grupos de indústrias que promovem Padrões
de consenso, alguns dos quaiscontrolam a tecnologia por eles criada e a utilizam em benefício
próprio (exemplo: “SQL Access Group” - SAG), outros consórcios, no entanto, qualificam-se apenas
como usuários de uma tecnologia controlada exclusivamente por uma empresa (exemplo: “Open
Database Connectivity” da Microsoft).
Particularmente, a informática têm despertado um crescente interesse dos Órgãos de
Padronização e de muitos grupos de empresas nos últimos anos. Motivados pela necessidades
comerciais, essas associações têm abordado diversos escopos que abrangem desde “Hardware” (em
geral), Redes, Linguagens de Dados, Aplicativos Específicos (CAD, CAE, CASE) e Sistemas de
Bases de Dados.
Para efeito de estudo, são citados nesse trabalho alguns Padrões (ODMG, OMG e
ANSI/X3) preocupados com os problemas das Bases de Dados e suas respectivas linguagens, e
outros especificamente direcionados a áreas correlacionadas como é o caso do ISO/STEP voltado a
sistemas CAD e PCTE+ para sistemas CASE.
8.1 - HISTÓRICO
Nos primordios do processamento de informações, todas as plataforma eram proprietárias.
Arquiteturas de hardware, sistemas operacionais, linguagens de programação e gerenciadores de
Sigla Nome Escopo
ANSI American National Standards Institute Padrões em geral dos EUA.
CCITT International Telegraph and Telephone
Consultative Committee
Padrões de Telecomunicações e Redes.
IEEE Institute of Electrical and Electronic Engineers Padrões de Engenharia Elêtrica, Rede
e Software.
ISO International Standards Organization Padrões de Redes, Linguagens
de Programação e dados.
NIST U.S. National Institute of Standards an Technology Padrões do governo dos EUA.
Órgãos de Padronização
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 23 - Parte II (Engenharia de Banco de Dados)
arquivos, todos eram sui generis e fornecidos por fabricantes de hardware. Uma vez que uma
organização tivesse desenvolvido seus aplicativos críticos em uma determinada plataforma, era
extremamente difícil mudar de fornecedor, por causa dos custos e da complexidade associados à
reimplantação da base de aplicativos. Além disso, os funcionários altamente qualificados, como
programadores e analistas, relutavam em abandonar as ferramentas conhecidas, para aprender novas
linguagens e interfaces.
Nesse ambiente, as força-motriz para a elaboração das normas era a portabilidade dos
aplicativos e culturas. As normas sobre linguagens de programação, como o Cobol e SQL,
atenuavam o sofrimento causado pela transferência de aplicativos e pessoal qualificado entre um
ambiente proprietário e outro. Ajudavam a preservar os investimentos das empresas em aplicativos e
em funcionários técnicos e operacionais.
As normas iniciais representavam os primeiros passos em direção ao rompimento das
amarras dos ambientes totalmente proprietários. Embora a maioria das empresas se contentasse em
confiar numa única fonte para atender a todas as suas necessidades de processamento de
informações, as normas conferiam um certo grau de credibilidade às ameaças (raramente cumpridas)
de optar por outro fornecedor.
8.2 - SISTEMAS ABERTOS
Com o advento dos sistemas cliente/servidor e dos sistemas abertos, o principal enfoque
das normas deslocou-se para a interoperabilidade. De fato, os sistemas abertos e ambientes
cliente/servidor heterogêneos exigiam interfaces padronizadas. Não se tratava mais de procurar
normas porque eram simpáticas; nesse mundo novo de hardwares e softwares intercambiáveis, eram
um imperativo tecnológico.
As forças econômicas e mercadológicas obrigaram muitos diretores de informática,
embora relutantes, a deixar o útero do mainframe para adentrar um mundo de múltiplos
fornecedores. Nesse novo ambiente, as normas eram vistas como uma fonte de conforto que antes
fora dado pelo fornecedor do mainframe e de todos os sistemas que o acompanhavam. De fato, as
normas preenchiam algumas necessidades dessas empresas.
Tendo se curvado às forças econômicas e operacionais que justificam o uso de sistemas
cliente/servidor, muitas empresas estão comprometidas com a manutenção de sistemas abertos. Não
querem mais regredir à situação em que todos os seus produtos e serviços de informática vinham de
uma única fonte. Ademais, sabem muito bem que mesmo que estivessem dispostas a se
comprometer com um único fornecedor agora, as atividades futuras das empresas provavelmente
exigiriam de qualquer maneira o suporte a um ambiente heterogêneo. Essa aplicação inevitável do
escopo e das fronteiras tecnológicas dos sistemas de informação das empresas é uma das
características da próxima fase da informática.
Desse modo, as normas devem ser vistas como um piso sobre o qual se constroem
sistemas abertos e não como um teto que limita a criação de novos recursos que se tornam
necessários. Finalmente, os aplicativos futuros certamente irão se estender para além da empresa,
acessando os dados dos clientes e fornecedores e sendo acessado por estes, além de terceiros cujas
opções tecnológicas não poderão ser controladas. Portanto, a equação da próxima década é : Normas
= portabilidade + interoperabilidade + base de inovação.
8.3 - FRONTEIRAS
Um Sistema Aberto é implementado com componentes que aderem a padrões específicos.
A implicação é que esses componentes podem ser comprados de vários fornecedores independentes,
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 24 - Parte II (Engenharia de Banco de Dados)
reduzindo portanto, a dependência da empresa para com um vendedor em particular. Da mesma
forma, assume-se que os clientes suportam estes padrões requerendo-os como parte de suas compras
de tecnologia de informações. Portanto, a dinâmica de mercado deve moldar a indústria em uma
direção que persiga bons padrões.
Os padrões podem ser de dois tipos: de jure e de facto. Um padrão de jure é aquele que é
publicamente reconhecido por um órgão governamental como o ANSI ou ISO. Cada país têm o seu
órgão governamental, como o ANSI para os Estados Unidos. Cada um destes órgãos nacionais é
então representado pela ISO, que define padrões mundiais. Um padrão de facto é aquele publicado
por um líder de vendas, para o qual os clientes e vendedores acabam aderindo. No passado, a IBM
foi responsável por muitos padrões de facto, alguns dos quais evoluíram para padrões de jure. Na
indústria de hoje, nenhum órgão particular é capaz de estabelecer qualquer padrão significante
baseando-se em sua fatia de mercado. Consórcios industriais de vendedores e consumidores
assumiram o direito de desenvolver padrões de fato de várias espécies.
Um padrão aberto se estabelece quando todos os vendedores possuem oportunidades
iguais para desenvolver produtos e mercados. Mesmo com padrões de jure, vendedores que
contribuem ativamente para o processo de padronização terão sempre vantagens sobre outros
vendedores. Como os padrões de facto, a situação é mais complexa. Já que estes padrões são
desenvolvidos por um ou mais vendedores, a abertura dos padrões de facto é altamente dependente
de outros fatores, como, por exemplo, uma documentação adequada, taxas de licença e controle de
arquiteturas. O outro extremo de um padrão aberto é o padrão proprietário, sobre o qual apenas um
vendedor é capaz de desenvolver e comercializar produtos. Mantendo segredos comerciais, patentes
e copyrighys, o vendedor pode impedir a competição de outros no mesmo nicho de mercado.
8.4 - BENEFÍCIOS UTÓPICOS
Na situação ideal, uma padronização ou normatização de componentes gera benefícios que
vão desde a portabilidade de aplicações e interoperabilidade de sistemas até a escalabilidade, a
estabilidade e o preço competitivo.
A portabilidade possibilita o translado de um aplicativo de uma plataforma para outra com
o mínimo de esforço, enquanto a interoperabilidade acrescenta ao sistema a habilidade de operar
com outros, através do compartilhamento de dados comuns ou da solicitações de processos comuns
que basicamente são definidospor protocolos (comandos e argumentos) que fluem de um sistemas a
outro.
A escalabilidade é a habilidade de escolher componentes alternados que possuem maior ou
menor capacidade. De modo ideal, um sistema aberto pode ser facilmente escalonado para cima,
selecionando-se uma plataforma com maior capacidade de processamento e/ou armazenamento,
trilhando um caminho migratório por uma seqüência se plataformas de capacidades superiores.
A estabilidade permite a um sistema aberto ser mantido apesar da falta de viabilidade de
qualquer um dos fornecedores. Assim, mudar para um outro vendedor não é tão traumático quanto
antigamente o que oferece maior estabilidade ao sistema.
Os componentes de um sistema aberto tendem a ser considerados “commodities”, sujeitos
a competição de numerosos vendedores, o que determina a existência de preços competitivos de
mercado.
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 25 - Parte II (Engenharia de Banco de Dados)
8.5 – OS PADRÕES
8.5.1 - OMG
Formado em 1989 por consórcio de dezenas de companhias dentre as quais estão os
maiores desenvolvedores de “software” e “hardware” incluindo usuários, o Object Management
Group (OMG) iniciou suas atividades tendo como meta padronizar e promover o paradigma de
orientação a objetos.
Os trabalhos envolvendo o padrão OMG estão atualmente divididos por grupos de
trabalho seguindo os componentes da tecnologia proposta. Dentre suas mais significativas
especificações encontram-se o Modelo de Objetos, a CORBA (“Commom Object Request Broker
Architecture”, e os “Object Services.
A utilização do
ORB (“Object Request
Broker”) estabelece
diversas funcionalidades
aos objetos dentre as quais
temos: a distribuição em
rede; a localização baseado
em identificadores; a
invocação remota de
métodos e outras, que
podem ser comparadas às
funcionalidades encontradas em SGBDOO.
Os Serviços são também funcionalidades dos objetos, contudo para tornar o padrão OMG
mais flexível, optou-se pela
colocação em ORB apenas do
mínimo necessário para a
comunicação entre objetos. Assim
sendo, por meio da utilização da
linguagem de definição de
interfaces (IDL), pode-se realizar
os vários Serviços que se
estendem desde a manipulação
convencional de objetos (criação,
remoção, movimentação e cópia),
a definição de integridades
referenciais que permite a
propagação seletiva de operações,
até a colocação de níveis de
autorização, consultas em
ambiente distribuído, suporte a Versões de Objetos e Evolução de Esquemas, todos incluídos em
planos futuros de extensão do Padrão.
CORBA
ORB e SGBDOO
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 26 - Parte II (Engenharia de Banco de Dados)
8.5.2 - ODMG
Com o interesse comum por Bases de Dados Orientadas a Objetos, o Object Database
Management Group (ODMG) foi criado em 1991 e desde então vem agregando membros dentre os
quais estão pesquisadores e desenvolvedores das seguintes companhias: Ontos, O2 Technology,
Objectivity, GemStone Systems, Andersen Consulting, HP, Sybase, Texas Instruments e outras.
Buscando agir sobre as demandas dos usuários, o ODMG propôs um padrão de
portabilidade cujo objetivo é garantir que programas aplicativos (atuando sobre SGBDOO) possam
ser facilmente convertidos para as diversas linguagem de programação aceitas pelo gerenciador,
possibilitando assim, que uma mesma Base de Dados possa ser compartilhada pela utilização (em
aplicativos) de linguagens de programação suportadas pelo Padrão.
Os estudos
realizados em conjunto
resultaram em um
documento cuja versão
revisada foi
denominada ODMG-
93. Nele encontram-se
as especificações de:
uma Arquitetura para
SGBDOO’s; um
Modelo de Objetos;
uma Linguagem de
Definição de Objetos
(ODL); uma
Linguagem de Consulta
de Objetos (OQL)
baseada no SQL; uma
Linguagem de
Manipulação de
Objetos (OML) que
atua em propriedades e
operações sobre objetos
persistentes; sintaxes e
semânticas dos comandos em
ODL, OML e OQL para as
linguagens C++ e Smalltalk; e
o Mapeamento para a
Arquitetura e Modelo OMG.
O Modelo de
Objetos suporta os conceitos
tradicionais de Classe, Objeto,
Atributo, Método, Herança e
Arquitetura do SGBDOO - ODMG
Hierarquia de Tipos
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 27 - Parte II (Engenharia de Banco de Dados)
Abstração de Generalização/Especialização. Adicional-mente, oferece integridade referencial através
de um Objeto Referência (relacionamento 1:1, 1:N e N:M) e a representação de coleções de objetos
por meio de tipos pré-definidos (por exemplo: set; bag -conjunto permite duplicação; array -
tamanho variável; e list -tamanho variável e tipo incerto).
As linguagens ODL, OML e OQL apresentam-se desvinculadas de qualquer linguagem
existente, proporcionando assim um mecanismo de independência. Desta forma, Esquemas de Dados
definidos em ODL podem ser transladados para a linguagem de programação desejada, e consultas
criadas pelo OQL oferecem uma interface de acesso interativo ou programado em uma linguagem de
programação.
A versão atual do Padrão ODMG atinge somente as necessidades básicas dos usuários de
programas aplicativos orientados a objetos. Particularmente, o conceito de Versões (Objetos ou
Classes) e operações para Evolução de Esquemas, ainda não são tratados nas Bases de Dados
centralizadas e muito menos nas distribuídas.
8.5.3 - ANSI/X3
O instituto de padronização americano ANSI9 possui o comitê National Committee for
Information Technology Standards* - NCITS (entre 1961- 1996 era denominado X3) direcionado
a questões envolvendo Computadores e Processamento de Dados, e
X3/SPARC/DBSSG
Formou-se o sub-comitê SPARC (“Standards Planning and Requirements Committee”)
cuja responsabilidade é gerar recomendações de esforços nas áreas necessárias sob a ação do grupo
de estudos apropriado.
Em janeiro de 1989, o grupo de estudos especializado DBSSG (“Database Systems Study
Group”) estabeleceu um grupo tarefa (OODBTG10) voltado à programação orientada a Objetos e
modelos (sistemas) de Bases de Dados orientadas a objetos. Uma publicação preliminar do Padrão
foi apresentada no primeiro workshop de padronização de BDOO , Atlantic City, NJ, May 22, 1990.
X3/H2 - SQL SPECIFICATIONS
X3/H7 - OBJECT INFORMATION MANAGEMENT
X3/J16 - C++ STANDARD
8.5.4 - PCTE+
O PCTE+ ("Portable Common Tool Environment") é um padrão para ambientes integrados
de desenvolvimento de “software” que permite a portabilidade de I-CASE’s para diferentes
plataformas de “hardware” e Sistemas Operacionais. O PCTE iniciou-se em outubro de 1983 sendo
desenvolvido inicialmente no projeto ESPRIT por um consórcio pan-europeu de empresas como BULL
S.A., General Electric Company, OLIVETTI e SIEMENS entre outras.
Entre as coleções integradas de ferramentas e serviços especificados pelo PCTE+,
encontram-se um Sistema de Gerenciamento de Objetos (OMS) composto por um conjunto de
 
9 “American National Standards Institute”
10 “Object-Oriented Databases Task Group”
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 28 - Parte II (Engenharia de Banco de Dados)
primitivas para manipulação de Objetos, e mecanismos de execução e comunicação entre processos ou
programas.
Segundo o modelo (extensão do MER) utilizado no OMS, todos os Objetos (arquivos) têm
suas características descritas por um conjunto de Atributos, um conjunto de Relacionamentos
Bidirecionais, e um "Content" que define o conteúdo do Objeto ("file", "message queue", "block
device"). Cada Tipo de Objeto define as características de todas as suas instâncias. O conjunto de Tipos
forma uma Hierarquia (de Generalização) suportando o conceito de Herança e Múltipla Herança.
Um "Link" é uma associação unidirecional entre dois Objetos e pode ser usado para
representar uma referência simples entre Objetos ou para modelar estruturas. Um Relacionamento
representauma mútua dependência entre dois Objetos, sendo este determinado por dois "Links", que
juntos proporcionam as cardinalidades um-para-um, um-para-muitos ou muitos-para-muitos.
A organização do Esquema de Dados é estruturada em conjuntos não disjuntos, chamados de
"Schema Definition Sets” (SDS), onde cada um agrupa as definições específicas para um usuário, para
uma ferramenta ou para um grupo de usuário de um mesmo projeto. A criação de um "SDS" é
realizada definindo-se seus elementos componentes, independentemente de qualquer outro SDS.
Uma característica importante proporcionada pelo padrão PCTE+ é o compartilhamento de
definições de dados por diversos usuários. Através da operação de "IMPORT", uma ferramenta ou
usuário pode conseguir o compartilhamento de definições de um SDS, desde que lhe seja permitido o
acesso.
Um processo de trabalho poderá necessitar de vários SDS's na definição de sua Visão da BD.
A lista formada por SDS's utilizados em um processo é chamada de "Working Schema" (WS). Nesse
processo é realizada a composição de SDS's do respectivo WS através da união dos conjuntos que não
causam inconsistências. Na ocorrência de conflitos de informações, é realizada uma seleção das
informações prioritárias, seguindo a ordem da lista de SDS's definidas pelo "Working Schema".
As Versões são estabelecidas sobre Objetos Complexos. A estrutura de derivação entre
Versões é um grafo acíclico dirigido (DAG) expresso por relacionamentos do tipo Predecessor-
Sucessor que definem por meio de categorias e cardinalidades o comportamento dos “links”
gerenciados pelo OMS. As alterações são restritas somente às Versões que não possuem predecessores,
o que proporciona uma estratégia simples para o controle da integridade das Versões.
8.5.5 - ISO/STEP
STEP (“STandard for the Exchange of Product data”) é o nome informal para um conjunto
de documentos (ISO série 10303) estabelecidos pelo grupo de trabalho ISO/TC184/SC4. Desde sua
primeira versão publicada em 1992, a organização do padrão se manteve relativamente simples,
estruturada em partes correlacionadas e modulares com o único objetivo de oferecer condições para
o compartilhamento e troca de dados usando os recursos integrados (específicos e genéricos em
projetos de
engenharia) de
represen-tação.
O padrão
STEP, em sua Parte
11, apresenta como
métodos de
representação um
modelo de dados
(EXPRESS) similar
ao Modelo Entidade-
Organização do padrão STEP
Notas Didáticas
Prof. Luiz Camolesi Jr.Pg. 29 - Parte II (Engenharia de Banco de Dados)
Relacionamento, no entanto mais sofisticado pois inclui a descrição de estruturas de dados e
restrições semânticas através de uma linguagem de textual.
 Partindo da perspectiva futura
que o STEP será usado concorrentemente
por diversos aplicações em uma abordagem
de “engenharia simultânea”, uma extensão
do padrão inclui no modelo EXPRESS
uma série de mecanismos e ferramentas
para o reconhecimento de Versões e Deltas.
Um conjunto mínimo de operações são
usadas na definição de arquivos Delta, o
que permite um “audit trail” ou
reconstrução das mudanças realizadas e
eventos ocorridos.
8.6 - ANÁLISE GERAL
A amostragem apresentada nas
seções anteriores, sobre alguns dos
conceitos abordados pelos Padrões mais
significativos, leva a uma avaliação das
tendências futuras e principais preocupações dos especialistas em representação e manipulação de
informações. Entre as considerações apresentadas nesses padrões encontram-se propostas de
arquiteturas para sistemas, para modelos e linguagens de dados, e para os “serviços” prestados aos
objetos.
A ênfase, até o momento, dos estudos e propostas de padronização está em atingir as
demandas (no caso, portabilidade e interoperabilidade) dos usuários de BD em sistemas de
gerenciamento e em ambientes amigáveis de manipulação. Nesse sentido, nota-se a preocupação do
ODMG e PCTE+ pela portabilidade de aplicações, enquanto OMG e ISO/STEP salientam soluções
para a interoperabilidade de aplicações.
 Pela compatibilidade de interesse, é possível encontrar muita cooperação entre os grupos
de padronização, como é o caso do OMG e ODMG que possuem membros em comum o que
determinou a compatibilidade de ambos os trabalhos no reaproveitamento de algumas definições,
como por exemplo o ODMG ODL e o Modelo de Objetos que são respectivamente extensões do
OMG IDL e de seu respectivo Modelo.
A tendência futura é termos sistemas de informação baseados em uma arquitetura aberta
(OSA - “Object Services Architecture”) que integrada softwares independentes, onde obtém-se altos
graus de portabilidades e comunicação entre aplicativos (sistemas) por meio do compartilhamento de
modelos e linguagens.
Pela própria natureza desde Padrões, não existem estimativas ou previsões sobre o futuro
de seus trabalhos, pois são ainda incertos os caminhos abertos pelas tecnologias emergentes e muito
menos se conhece as demandas advindas do mercado. As expectativas, no entanto, são promissoras
no sentido de que a evolução para arquiteturas abertas e apoiadas no paradigma de orientação a
objetos é uma realidade que tem se mostrado promissora.
❋
Arquivo Delta