anÁlise e metodologias de ... - celepar7cta.pr.gov.brcelepar7cta.pr.gov.br/portfolio.nsf/0... ·...
TRANSCRIPT
DALTON LUIZ MARCÍLIO
ANÁLISE E METODOLOGIAS DE INTEGRAÇÃO DE ESQUEMAS DE
BANCO DE DADOS
Monografia apresentada para obtenção do título de Especialista em Tecnologia da Informação no Curso de Pós-Graduação em Informática, Setor de Ciências Exatas, Universidade Federal do Paraná.
Orientador: Prof. José Simão de Paula Pinto
CURITIBA
MAIO 2002
ii
SUMÁRIO
LISTA DE ILUSTRAÇÕES ............................................................................................... V
LISTA DE QUADROS..................................................................................................... VII
RESUMO ........................................................................................................................ VIII
ABSTRACT ...................................................................................................................... IX
1 INTRODUÇÃO ............................................................................................................1
2 ASPECTOS GERAIS ..................................................................................................4
3 VISÃO GERAL DE INTEGRAÇÃO DE DADOS........................................................8
3.1 Integração de visões ...................................................................................................... 10
3.2 Integração de bases de dados..................................................................................... 12
4 METODOLOGIAS PARA A INTEGRAÇÃO DE ESQUEMAS ................................14
4.1 Causas da diversidade de esquemas........................................................................ 18
4.1.1 Diferentes perspectivas............................................................................................. 18
4.1.2 A equivalência entre construções do modelo ....................................................... 19
4.1.3 Projeto de especificação incompatível ................................................................... 20
4.1.4 Conceitos comuns...................................................................................................... 21
4.1.5 Conceito relacionado por propriedades semânticas............................................ 22
4.2 Etapas e objetivos do processo da integração ...................................................... 23
4.2.1 Pré integração............................................................................................................. 23
4.2.2 Comparação dos esquemas .................................................................................... 24
iii
4.2.3 Adequação de esquemas ......................................................................................... 24
4.2.4 União e reestruturação .............................................................................................. 24
5 COMPARAÇÃO DE METODOLOGIAS...................................................................26
5.1 Aplicabilidade das metodologias de integração .................................................... 26
5.2 Características das entradas e saídas ...................................................................... 28
5.3 Arquiteturas das metodologias ................................................................................... 31
5.4 Pré integração .................................................................................................................. 33
5.5 Comparação dos esquemas......................................................................................... 36
5.5.1 Nomeando conflitos ................................................................................................... 36
5.5.2 Conflitos estruturais ................................................................................................... 39
5.6 Adequação de esquemas .............................................................................................. 40
5.7 União e reestruturação .................................................................................................. 41
5.7.1 Integridade................................................................................................................... 43
5.7.2 Minimização................................................................................................................. 43
5.7.3 Compreensão.............................................................................................................. 44
6 METODOLOGIA DE UNIÃO DE ESQUEMAS DE ELMASRI .................................45
6.1 Visão Geral da Metodologia ......................................................................................... 45
6.2 Abordagem da integração de visões ......................................................................... 46
6.2.1 Fase de pré-integração ............................................................................................. 47
6.2.2 Revisão de integração de objetos ........................................................................... 48
6.3 Integração de relacionamentos................................................................................... 51
6.3.1 Critérios para a comparação de relacionamentos ............................................... 52
iv
6.3.2 Classificação dos relacionamentos......................................................................... 53
6.3.3 Unindo relacionamentos com o mesmo grau........................................................ 54
6.3.4 Unindo relacionamentos de diferentes graus........................................................ 60
7 CONCLUSÃO............................................................................................................67
REFERÊNCIAS ................................................................................................................69
ANEXOS...........................................................................................................................71
v
LISTA DE ILUSTRAÇÕES
FIGURA 1 - O PROCESSO GLOBAL DE INTEGRAÇÃO....................................................................8
FIGURA 2 - FASES DO PROJETO DE BASE DE DADOS. ..............................................................12
FIGURA 3 - ENTRADAS E SAÍDAS NA INTEGRAÇÃO DE BASES DE DADOS.........................13
FIGURA 4 - EXEMPLOS DE REQUERIMENTOS E SEUS ESQUEMAS
CORRESPONDENTES.....................................................................................................................15
FIGURA 5 - ESQUEMAS ORIGINAIS. ...................................................................................................16
FIGURA 6 - ESCOLHER "TOPICS" POR "KEYWORD"(ESQUEMA 2). .........................................16
FIGURA 7 - TORNAR PUBLISHER UMA ENTIDADE. .......................................................................16
FIGURA 8 - SOBREPOSIÇÃO DOS ESQUEMAS. .............................................................................17
FIGURA 9 - CRIAÇÃO DE UM SUBCONJUNTO RELACIONAMENTO. ........................................17
FIGURA 10 - DELETAR AS PROPRIEDADES DE BOOK COMUNS A PUBLICATION. ............18
FIGURA 11 - DIFERENTES PERSPECTIVAS .....................................................................................19
FIGURA 12 - CONSTRUÇÕES EQUIVALENTES. (A) HIERARQUIA DE GENERALIZAÇÃO
(B) UMA ENTIDADE SIMPLES. ......................................................................................................20
FIGURA 13 - ESPECIFICAÇÃO DE PROJETO INCOMPATÍVEL....................................................21
FIGURA 14 - PROPRIEDADES DE INTERESQUEMA. .....................................................................23
FIGURA 15 - TIPOS DE ESTRATÉGIAS DE PROCESSAMENTO DE INTEGRAÇÃO...............34
FIGURA 16 - EXEMPLO DE HOMÔNIMO. ...........................................................................................38
FIGURA 17 - EXEMPLO DE SINÔNIMO...............................................................................................38
FIGURA 18 - TRANSFORMAÇÃO DE UM ATRIBUTO EM UMA ENTIDADE. ..............................41
FIGURA 19 - UM ESQUEMA COM REDUNDÂNCIA..........................................................................43
FIGURA 20 - APRIMORANDO O ENTENDIMENTO. .........................................................................44
FIGURA 21 - DOMÍNIOS IDÊNTICOS ...................................................................................................49
FIGURA 22 – SUBCONJUNTOS ............................................................................................................50
FIGURA 23 - HIERARQUIA DE GENERALIZAÇÃO. ..........................................................................50
FIGURA 24 - ABORDAGEM SEMÂNTICA DOS RELACIONAMENTOS........................................55
FIGURA 25 - RELACIONAMENTOS COM O MESMO GRAU. .........................................................55
vi
FIGURA 26 - UNIÃO DE MESMO GRAU ..............................................................................................55
FIGURA 27 - RELACIONAMENTOS COM CONSTRAINTS DIFERENTES. .................................57
FIGURA 28 - UNIÃO COM CONSTRAINTS DIFERENTES. .............................................................57
FIGURA 29 – DETENÇÃO .......................................................................................................................58
FIGURA 30 - RELACIONAMENTOS DISJUNTOS ..............................................................................59
FIGURA 31 - RELACIONAMENTOS CRUZADOS. .............................................................................59
FIGURA 32 - UNIÃO DE RELACIONAMENTOS CRUZADOS. ........................................................60
FIGURA 33 - CLASSIFICAÇÃO DE RELACIONAMENTOS DE DIFERENTES GRAUS.............62
FIGURA 34 - RELACIONAMENTOS UNIFICÁVEIS. ..........................................................................62
FIGURA 35 - RELACIONAMENTOS UNIFICÁVEIS POR CONDIÇÃO. .........................................63
FIGURA 36 - RELACIONAMENTOS RETIDOS. ..................................................................................64
FIGURA 37 - DEPENDÊNCIA FUNCIONAL. ........................................................................................64
FIGURA 38 - VISÕES DERIVÁVEIS. .....................................................................................................65
FIGURA 39 - RELACIONAMENTOS NÃO UNIFICÁVEIS. ................................................................66
vii
LISTA DE QUADROS
QUADRO 1 - FASES DA INTEGRAÇÃO DE ACORDO COM METODOLOGIAS............................27
QUADRO 2 - ENTRADAS E SAÍDAS.................................................................................................31
QUADRO 3 - ATIVIDADES DA INTEGRAÇÃO DE ESQUEMAS .....................................................32
QUADRO 4 - ESTRATÉGIAS DE PROCESSAMENTO DE INTEGRAÇÃO.....................................36
QUADRO 5 - CONFLITOS ESTRUTURAIS E DE NOME .................................................................39
QUADRO 6 - PROPRIEDADES DE INTERESQUEMA.....................................................................42
viii
RESUMO
O conhecimento e a informação se tornaram um bem precioso para a
organização. Sendo assim, é necessário gerenciá-lo bem para se ter um efetivo
controle sobre este patrimônio peculiar. O seu valor aumenta considerando que
as informações estão cada vez mais integradas e passam a dar apoio a
tomadas de decisão a fim de obter vantagens competitivas. Relacionado a isso,
novas aplicações usarão dados existentes de vários bancos dos dados, de
preferência novos dados que incorporam as empresas. Por conseqüência, vêm
à tona a necessidade do conhecimento de integração de esquemas de base de
dados, a fim de fornecer compatibilidade e acesso transparente aos recursos
da informação sem envolver investimentos completos no replanejamento do
sistema.
Neste trabalho é analisada e oferecida uma abordagem no processo de
integração de esquemas de base de dados, fornecendo para isso uma
estrutura geral do problema da integração de esquemas, as definições
envolvidas no processo, as metodologias existentes e o detalhamento de uma
arquitetura específica para a integração.
Palavras-chave: Banco de Dados; Integração de Esquemas; Metodologias de
Integração.
ix
ABSTRACT
The knowledge and the information have become precious items for
the organization. So, it is necessary to manage it successfully to have an
effective control on this peculiar patrimony. Its value increases considering that
information is, as time goes by, more integrated and starts supporting decisions
taking in order to get competitive advantages. Related to this, new applications
will use existing data of several data bases, preferentially new data that
incorporate the companies. For consequence, appears the necessity of the
knowledge to integrate data base projects, in order to supply compatibility and
transparent access to the features of the information without involving full
investments in the re-planning of the system.
In this work it is analyzed and offered a boarding on the process of
integration of data base projects, supplying this a general structure of the
problem of the schemas integration, the definitions involved in the process, the
existing methodologies and the detailing of a specific architecture for the
integration.
Key-words: Data base; Integration of Schemas; Methodologies of Integration.
1
1 INTRODUÇÃO
A Tecnologia da Informação, seja através de uma tarefa simples para
automatização de processos até a elaboração de uma solução mais complexa,
tem nos possibilitado uma maior flexibilidade e rapidez no acesso às
informações.
A evolução de ferramentas ligadas a área tem nos proporcionado
maiores facilidades de utilização tanto para o usuário comum como para o
desenvolvedor. Com isto, a informatização vem atingindo praticamente todas
as áreas do conhecimento humano.
Como conseqüência deste fator, o número de usuários e a
quantidade de informações que se tem produzido e disponibilizado vem
crescendo exponencialmente. Devido ao grande volume, para se chegar às
informações desejadas é necessário um filtro eficiente através do contexto e da
semântica desta informação.
Uma das áreas da Tecnologia da Informação de suma importância e
que possui características peculiares acima descritas é a de bases de dados,
que está se tornando cada vez mais essencial nas organizações. A
disponibilidade de dados e os acessos à informação com resultados
satisfatórios têm se tornado um fator crítico para ganho de vantagem
competitiva.
Enquanto as estruturas das companhias evoluem, os limites entre os
departamentos mudam, criando novas unidades de negócio, acarretando uma
maior utilização dos computadores e do número de aplicações específicas.
Essas novas aplicações usarão dados existentes de vários bancos dos dados,
de preferência novos dados que incorporam a organização.
Entretanto, um número de questões emergentes complicam a
habilidade das organizações de fornecer o acesso detalhado e de confiança
aos diferentes recursos da informação. Exemplos de tais questões que
2
surgiram nas décadas passadas incluem a proliferação e investimento em base
de dados autônomas dentro da organização, heterogeneidade entre modelos
de dados e sistemas gerenciadores de base de dados empregados e o
aumento da importância das regras e da complexidade de sistemas
distribuídos. Todos estes fatores contribuem para o aumento da importância de
desenvolver opções praticáveis para fornecer interoperabilidade entre base de
dados existentes, e conseqüentemente, buscar a pesquisa na área de
integração de esquemas de base de dados.
De fato, estas características focalizam o conhecimento do problema
envolvido na integração de esquemas em base de dados existentes a fim de
fornecer compatibilidade e acesso transparente aos recursos da informação
sem envolver investimentos completos no replanejamento do sistema.
As contribuições para o estado da arte de metodologias de projeto da
base de dados, e em particular o processo de integração de esquemas foram
particularmente significativos nos últimos vinte anos. Este projeto de pesquisa
se propõe a analisar e oferecer uma abordagem no processo de integração de
esquemas de base de dados, fornecendo primeiramente uma estrutura geral de
como o problema de integração de esquemas pode ser melhor compreendido.
Também são levantadas questões problemáticas envolvidas no processo, a
descrição de levantamento de dados, modelagens e técnicas existentes e
descrição geral comparativa sobre metodologias relacionadas a área. Dentro
de uma esfera de utilização de modelagem amplamente aceita e de uma
descrição nítida de procedimentos, é apresentado o detalhamento de uma
metodologia de integração específica proposta por ElMasri[1987] e descrição
de linhas de pesquisa para trabalhos futuros.
Assim, no capítulo 2 é apresentado um histórico do processo de
Integração bem como as escolas de pensamento concernentes; no capítulo
seguinte é descrita uma visão geral e definições sobre integração de dados; o
capítulo 4 é reservado para delinear as etapas, objetivos e características
3
gerais do processo de integração; no capítulo subseqüente é demonstrada a
comparação de diversas metodologias existentes; o capítulo 6 aborda a
metodologia de união de esquemas de ElMasri[1987].
4
2 ASPECTOS GERAIS
As metodologias de projeto de base de dados emergiram em 1970.
Uma das motivações fundamentais para usar a abordagem de base de dados
sobre a tradicional abordagem “processamento de dados usando arquivos” foi
a afirmação que os sistemas gerenciadores de base de dados poderiam tornar
possível definir um esquema integrado de dados relevante para todas as
aplicações, eliminando desse modo duplicações, problemas de múltiplos
updates e minimizar inconsistências através da aplicação. Estas importantes
vantagens motivaram a pesquisa na área de integração de esquemas sobre as
duas décadas passadas. O objetivo geral da integração do esquema é integrar
uma organização com diferentes propósitos ou sistemas de base de dados e
percepções do usuário que facilitam desse modo o acesso global a um recurso
organizacional integrado da informação.
O projeto de base de dados convencional é dependente da
experiência e intuição do desenvolvedor. O desenvolvimento de técnicas para
suportar o projeto de base de dados não avançou comparavelmente com as
aplicações de bases de dados. Passados alguns anos algumas tentativas
foram feitas para tratar o projeto de base de dados como uma forma científica e
estrutural. Houveram essencialmente duas escolas de pensamento:
a) Na primeira, o projeto de base de dados começa com itens de
dados individuais. Todos os tipos funcionais e outros tipos de
dependências entre itens de dados individuais devem ser
especificados antes de construir o esquema. Porém como
discutido por Bubenko [BUBE79], as suposições desta abordagem
não são sempre realísticas. Além disso, a abordagem trabalha
geralmente com a idéia que o conjunto mínimo de relações é
melhor no projeto de base de dados. As considerações semânticas
são ignoradas quase que completamente. Com isso, o esquema
5
resultante é dependente da ordem nos quais as dependência de
dados são fornecidas para algoritmos de síntese.
b) A segunda escola do pensamento advoga a operação no nível de
entidades, relacionamentos e atributos. Nesta abordagem o
processo de projeto de base de dados é dividido nas seguintes
fases:
I) Modelagem de visões.
II) Integração de visões.
III) Análise e mapeamento do esquema.
IV) Projeto e otimização físicas do esquema.
O termo visão está sendo usado no contexto de representação da
visão de dados de um grupo de usuários ou de um desenvolvedor da empresa.
Os termos como “visão do usuário” ou “visão da empresa” torna claro a
respeito de quem elabora a visão. Dois aspectos são relacionados com este
termo:
- Estrutura dos dados.
- Processamento dos dados.
Neste trabalho, a visão será usada para referenciar somente a
estrutura dos dados. As transações em visões são consideradas durante as
fases de análise e de otimização.
Durante a modelagem de visões, as visões dos usuários são
expressadas em um nível elevado tal como no modelo semântico Entidade
Relacionamento(E-R) ou variante. Todas as visões do usuário são integrados
durante a fase de integração de visões para gerar o esquema. O trabalho de
Navathe, Elmasri e Wiederhold [NAVA78, WIEDT9, ELMA79, NAVA82,
ELMA84], Batini e Lenzerini et al. [BAT182, BATI83, BAT184, ATZ81] estão
nesta categoria. A integração de visões como um processo foi analisada mais
profundamente por [NAVA82, BATI83]. A integração total é vista como um
processo incremental da definição da integração e de resoluções de conflitos.
6
Esta escola é da opinião que a resolução de conflitos de integração
de visões pode ser efetuada por ferramentas de projeto interativas. A
integração é o resultado de um diálogo constante com o usuário sobre a
definição de conflitos.
Três características distinguem esta escola da precedente:
a) Nesta abordagem a semântica dos objetos e dos relacionamentos
entre objetos dirige a integração. A metodologia tenta alcançar
uma representação global dos dados que é o "melhor
compromisso” para o conjunto dado das visões locais que
consideram todos os conflitos. A semântica referencia todas as
dependências funcionais que estão tipicamente incluídas na outra
escola. As abordagens dirigidas puramente por dependências não
podem ter nenhuma noção de compromisso.
b) A metodologia confia fielmente na intervenção do desenvolvedor.
A primeira escola do pensamento espera a atividade de projeto ser
automatizada inteiramente visto que a última supõe que a
abordagem semi automatizada deve ajudar ao desenvolvedor
identificando os conflitos e propondo alternativas à união de
esquemas. Uma união automática de visões não é considerada
apenas irreal mas também sem sentido na ausência de informação
semântica que integra múltiplas visões de dados.
c) A otimização de projeto sob a segunda escola de pensamento está
tipicamente baseada em uma avaliação de projeto alternativa no
contexto de processos de carga. As abordagens baseadas em
pura dependência de informação [CASA83 ] geralmente supõe que
a redundância mínima é o objetivo preliminar do projeto. Alguns
modelos funcionais são advogados como Yao et al. [YAO82], que
usam a noção de transação em seu método.
Este trabalho trata da fase de integração de visões de um projeto de
7
base de dados sob a segunda escola de pensamento. [BAT182, BAT84] propôs
extensões do modelo E-R para facilitar as integrações das visões. Eles
consideraram os problemas de nome(homônimos e sinônimos) em detalhes e
abordaram a integração das visões como uma modificação incremental do
núcleo de uma visão global para acomodar todos as outras visões
considerando uma por uma. Elmasri e Wlederhold [ELM79] especificam tipos
diferentes de relacionamentos binários entre classes de objetos e consideram
como eles podem serem feitos para coexistir. Eles não consideram
relacionamentos de grau mais elevado. O método proposto por ElMasri[84]
utiliza uma variante do modelo E-R chamada de modelo de Entidade-
Categoria-Relacionamento(E-C-R) [WEEL80], [ELMA84], onde será focalizado
especificamente o problema da integração de relacionamentos. Uma visão do
modelo E-C-R encontra-se em anexo neste trabalho.
8
3 VISÃO GERAL DE INTEGRAÇÃO DE DADOS
A integração da base de dados é o processo que leva como entrada
um conjunto de bases de dados e produz como a saída uma única descrição
unificada dos esquemas de entrada (o esquema integrado) e o mapeamento de
informações associadas que suportam acesso integrado aos dados existentes
através do esquema integrado. A integração da base de dados é usada
também no processo do reengenharia de sistemas legados.
A finalidade e a contribuição deste trabalho são fornecer um retrato
de quais são as abordagens e as soluções a serem atingidas. Apresentamos
então as etapas envolvidas em desenvolver um esquema integrado (veja
Figura 1 ):
Figura 1 - O processo global de integração.
9
a) Pré integração: onde os esquemas de entrada são transformados
para se tornarem mais homogêneos (sintaticamente e
semanticamente)
b) Identificação de correspondência: dirigida a identificação e
descrição de relacionamentos de interesquemas;
c) Integração: a etapa final que resolve conflitos de interesquemas e
unifica itens correspondentes em um esquema integrado.
Um dos princípios fundamentais da abordagem de base de dados é
que uma base de dados permite uma representação não redundante e
unificada de todos os dados controlados em uma organização. Isto é
conseguido somente quando as metodologias estão disponíveis para suportar
a integração através dos limites organizacionais e da aplicação.
As metodologias para o projeto de base de dados executam
geralmente a atividade de projeto separada produzindo diversos esquemas
representando as partes da aplicação, que são unificadas subseqüentemente.
O objetivo geral da integração de esquemas é integrar uma
organização com diferente propósitos ou sistemas de base de dados e
percepções do usuário que facilitam desse modo o acesso global a um recurso
organizacional integrado da informação. De qualquer forma, a pesquisa da
integração de esquemas foi especializada em duas áreas:
a) integração de visões: se dirige às bases de dados propostas, e
b) integração de base de dados: se dirige às bases de dados
existentes.
A integração de visões é usada como uma ferramenta de auxílio no
projeto da base de dados e produz uma descrição global e conceitual de uma
base de dados proposta unindo diferentes requisições de dados ou visões do
usuário. De outra forma, a integração da base de dados é usada para produzir
um esquema global que representa uma coleção de bases de dados
10
relacionadas em toda a organização. Este esquema global é uma visão virtual
de todas as bases de dados juntas em um ambiente de base de dados
distribuído.
Quando a integração da base de dados e das visões diferirem
contextualmente, elas podem ser descritas como atividades de integração de
esquemas de bases de dados propostas ou existentes em um esquema global
e unificado que satisfaça as constraints impostas por todos os esquemas
componentes.
3.1 INTEGRAÇÃO DE VISÕES
O problema do projeto de base de dados aponta para o
desenvolvimento de um esquema de base de dados que inclui especificações
lógicas tais como agrupamentos de atributos e relacionamentos entre esses
agrupamentos (esquema lógico), bem como as especificações físicas tais
como tipo de acesso a registros, índices e ordenação(esquema físico). No caso
de distinção, as atividades de projeto correspondentes da base de dados são
denominadas projeto lógico e físico do esquema.
O projeto lógico do esquema envolve o problema de projetar o
esquema conceitual e de mapear o esquema em uma linguagem de definição
do esquema (ou linguagem de definição de dados) de um SGBD específico. A
Figura 2 mostra as fases do projeto de base de dados e das representações
intermediárias do esquema. As fases do projeto de base de dados são :
a) Especificação e análise de requisitos. Uma análise da informação
de requisitos de várias áreas dentro de uma organização tendo
como resultado uma especificação preliminar das necessidades de
informação de vários grupos de usuários.
b) Projeto Conceitual. Modelagem e representação de usuários e
visões das aplicações da informação e possivelmente uma
11
especificação do processamento do uso da informação. O
resultado final desta atividade é um esquema conceitual que
represente uma descrição global de alto nível dos requisitos.
c) Execução do Projeto. Transformação de um esquema conceitual
no esquema lógico de um SGBD. A segunda e a terceira fases
feitas em conjunto são chamadas projeto de base de dados lógico.
d) Projeto físico e otimização do esquema. Mapeamento do esquema
lógico de uma base de dados em uma representação apropriada
armazenada em um SGBD, incluindo novos parâmetros físicos
para otimizar o desempenho da base de dados contra um conjunto
de transações.
Tipicamente, a atividade de projeto da aplicação prossegue
paralelamente com projeto de base de dados. A Figura 2 mostra também as
especificações relacionadas às aplicações relatadas como as saídas das
últimas duas fases.
12
Figura 2 - Fases do Projeto de Base de Dados.
3.2 INTEGRAÇÃO DE BASES DE DADOS
A integração de base de dados é um problema relativamente recente
que aparece no contexto de bases de dados distribuídas. Uma base de dados
distribuída é uma coleção de dados que logicamente pertencem ao mesmo
sistema mas estão espalhados sobre uma rede de computadores.
Bases de dados distribuídas e o sistema de gerência da base de
13
dados distribuído podem ser classificados em duas categorias principais:
homogênea, tratando das bases de dados locais que têm os mesmos modelos
de dados e Sistemas Gerenciadores de Banco de Dados(SGBD´s) idênticos; e
heterogênea, tendo uma diversidade em modelos e em SGBDs.
Os contextos acima requerem que o esquema integrado seja
projetado tendo em base os esquemas locais, os quais consultam às bases de
dados existentes.
A atividade da integração da base de dados é descrita em uma
maneira geral na Figura 3. Ela mostra que esta atividade tem como entrada
esquemas e consultas as transações locais.
Figura 3 - Entradas e saídas na integração de bases de dados.
14
4 METODOLOGIAS PARA A INTEGRAÇÃO DE ESQUEMAS
A fim de introduzir as principais características e os problemas da
integração de esquemas, é apresentado um exemplo. A Figura 4 mostra duas
descrições que se refere as exigências e os possíveis esquemas conceituais
correspondentes. A seguinte informação adicional aplica-se a este exemplo:
a) A idéia de "Topics" no primeiro esquema é o mesmo que
"Keyword" no segundo esquema.
b) "Publication" no segundo esquema é um conceito mais abstrato do
que "Book" no primeiro esquema. Isto é, "Publication" inclui itens
adicionais tais como continuações, jornais, monografias, etc..
Segue texto explicativo aos esquemas da Figura 4 :
No primeiro esquema(4a): “Os dados de interesse são sobre livros.
Livros têm títulos. Eles são publicados por editores com nomes e endereços.
Livros são adotados pelas Universidades tendo um nome e pertencendo a um
estado. Livros se referem a certos tópicos”.
No segundo esquema(4b): “Os dados de interesse incluem
publicações de diferentes tipos. Cada publicação tem um título, um editor e
uma lista de palavras chave. Cada palavra chave consistem em um nome, um
código e uma área de pesquisa”
A Figura 4 mostra um conjunto de atividades que podem ser
executadas para integrar os esquemas. Observando os dois esquemas na
Figura 5, concluímos que Topics e Keywords correspondem ao mesmo
conceito. Se tivermos que unir os esquemas, os nomes devem ser unificados
em um único nome. Vamos escolher o nome Topics. Observe a mudança
correspondente no segundo esquema (Figura 5 para Figura 6). Quando nós
observamos os novos esquemas (Figura 6), uma outra diferença observada é
que publisher está presente nos dois esquemas com tipos diferentes: É uma
entidade no primeiro esquema e em um atributo no segundo. A razão para
15
escolher tipos diferentes (atributo contra entidade) vem da diferente relevância
que publisher tem nos dois esquemas.
Entretanto, observa-se que é necessário adequar as duas
representações para a união ser realizada. Conseqüentemente nós
transformamos o atributo Publisher em uma entidade no segundo esquema e
adicionamo-lhe um novo atributo, Name (veja a Figura 7).
Nós agora podemos sobrepor os dois esquemas, produzindo a
representação na Figura 8. A união ainda não está terminada, ainda deve-se
procurar propriedades que relacionam os conceitos que pertencem a
esquemas diferentes, que foram “ocultos” previamente. Este é o caso do
relacionamento do subconjunto entre os conceitos Book e Publication. Pode-se
adicionar tal relacionamento ao subconjunto do esquema unificado, produzindo
o resultado mostrado na Figura 9.
Agora, para simplificar a representação, podemos reestruturar o
esquema excluindo as propriedades (relacionamentos e atributos) de Book que
são comuns à Publication. Isto é permitido desde que o relacionamento do
subconjunto implique que todas as propriedades de Publication são
implicitamente herdadas por Book. O esquema final é mostrado na Figura 10.
Figura 4 - Exemplos de Requerimentos e seus esquemas correspondentes.
16
Figura 5 - Esquemas originais.
Figura 6 - Escolher "Topics" por "Keyword"(Esquema 2).
Figura 7 - Tornar Publisher uma entidade.
17
Figura 8 - Sobreposição dos esquemas.
Figura 9 - Criação de um subconjunto relacionamento.
18
Figura 10 - Deletar as propriedades de Book comuns a Publication.
4.1 CAUSAS DA DIVERSIDADE DE ESQUEMAS
O exemplo utilizado acima é obviamente um exemplo básico se
comparado aos principais problemas envolvendo integração de esquemas. O
problema básico a ser tratado durante a integração vêm das diversidades
estruturais e semânticas dos esquemas a serem unidos.
A investigação da integração começa com uma classificação das
várias causas para a diversidade do esquema, que são: diferentes
perspectivas, equivalência entre construções do modelo e especificações
incompatíveis do projeto.
4.1.1 Diferentes perspectivas
No processo de projeto, os diferentes grupos de usuário ou
desenvolvedores adotam seus próprios pontos de vista em modelar os mesmos
objetos no domínio da aplicação. Por exemplo, no exemplo na seção 4, nomes
diferentes estavam ligados ao mesmo conceito nas duas visões.
Um outro exemplo é dado na Figura 11, em que os dois esquemas
19
representam informações sobre empregados e seus departamentos. Na Figura
11a, a informação é modelada por meio do relacionamento E-D. Na Figura 11b,
o relacionamento E-P relaciona os empregados com projetos, visto que o
relacionamento P-D associa projetos com departamentos. Supõe-se que um
Employee(empregado) "pertence" aquele departamento que está envolvidos
nos projetos onde o empregado trabalha. Então o relacionamento entre
empregado e departamento é entendido como uma relação direta em um
esquema.
Figura 11 - Diferentes perspectivas
4.1.2 A equivalência entre construções do modelo
Tipicamente em modelos conceituais, diversas combinações das
construções podem modelar o mesmo domínio da aplicação
equivalententemente. Como conseqüência, modelos "mais ricos" causam uma
variedade maior de possibilidades para modelar a mesma situação. Por
exemplo, na Figura 4, a associação entre Book e Publisher foi modelada como
um atributo de Publisher em um esquema e como um relacionamento entre
Book e Publisher no outro.
A Figura 12 mostra um outro exemplo de construções equivalentes.
20
Man e Woman são distinguidos em uma hierarquia de generalização no
primeiro esquema visto que no segundo esquema eles são distinguidos por
diferentes valores do atributo sexo.
Figura 12 - Construções equivalentes. (a) Hierarquia de Generalização (b) Uma
entidade simples.
4.1.3 Projeto de especificação incompatível
Escolhas errôneas a respeito do nome, tipo, constraints de
integridade, etc. podem resultar em entradas errôneas no processo de
integração de esquemas. Uma boa metodologia de integração de esquemas
deve conduzir à detecção de tais erros. O Esquema a na Figura 13 mostra
erroneamente que um empregado está atribuído sempre a um único projeto,
onde a constraint de cardinalidade 1:N foi especificada. A situação correta (que
um empregado pode ser atribuído a muitos projetos) aparece no esquema b.
Os aspectos acima representam as razões do porque a modelagem
pode ocorrer de diferentes maneiras em esquemas diferentes. A fim executar a
integração, é crucial escolher não somente um conjunto de conceitos comuns
mas também conjuntos de diferentes conceitos em esquemas diferentes que
estão mutuamente relacionados por algumas propriedades semânticas. Isto é
referenciado como propriedades de interesquema, que são relacionamentos
21
semânticos que contém um conjunto dos objetos em um esquema e um
conjunto diferente de objetos em um outro esquema.
Figura 13 - Especificação de projeto incompatível.
4.1.4 Conceitos comuns
De acordo com as causas de diversidade de esquemas descritas
acima, pode acontecer que o mesmo conceito do domínio da aplicação possa
ser representado por diferentes representações R1 e R2 em esquemas
diferentes, e diversos tipos de relacionamentos semânticos podem existir entre
tais representações. Esses relacionamentos podem ser idênticos, equivalentes,
compatíveis ou incompatíveis:
a) Idênticos: R1 e R2 são exatamente os mesmos. Isto acontece
quando o mesmo modelo de construção é utilizado, as mesmas
percepções são aplicadas e nenhuma incoerência existe na
especificação.
b) Equivalentes: R1 e R2 não são exatamente os mesmos porque
utilizam modelagens equivalentes, porém diferentes. As
percepções são ainda as mesmas e coerentes.
Embora diversos modelos semânticos de dados ainda estão em
existência hoje, os autores destes modelos não fornecem nenhum critério para
a equivalência dos conceitos. As definições são baseadas tipicamente em três
22
tipos diferentes de equivalência:
a) Comportamental: R1 é equivalente a R2 se para cada
instanciação de R1, a correspondente instanciação R2 existe com
o mesmo conjunto de respostas a uma dada consulta e vice versa.
b) De mapeamento: R1 e R2 são equivalentes se suas instâncias
podem ser descritas em uma correspondência 1:1.
c) Transformacional: R1 é equivalente a R2 se R2 pode ser obtido de
R1 aplicando um conjunto de transformações atômicas que, por
definição, preservam equivalências.
1) Compatível: R1 e RS não são nem idênticos nem equivalentes.
Entretanto, as construções, a percepção do desenvolvedor, e
constraints de integridade não são contraditórios.
2) Incompatível: R1 e R2 são contraditórios por causa da incoerência
da especificação.
As situações (2), (3), e (4) acima podem ser interpretadas como
conflitos. Os conflitos e suas resoluções são peças chave nos problemas de
integração.
4.1.5 Conceito relacionado por propriedades semânticas
A respeito dos conceitos em componentes de esquemas que não são
os mesmos mas estão relacionados, precisamos descobrir todas as
propriedades relacionadas ao interesquema. Na Figura 14, nós mostramos dois
exemplos de propriedades de interesquema.
23
Figura 14 - Propriedades de interesquema.
4.2 ETAPAS E OBJETIVOS DO PROCESSO DA INTEGRAÇÃO
Daqui em diante, trataremos a questão da natureza do problema da
integração de esquemas e da identificação das causas e as implicações da
diversidade do esquema. Como as metodologias realizam a tarefa da
integração? Cada metodologia segue seu próprio procedimento da solução.
Entretanto, toda metodologia eventualmente pode ser considerada uma mistura
das seguintes atividades:
4.2.1 Pré integração
Uma análise dos esquemas é realizada antes da integração para se
decidir alguma política de integração. Isto engloba a escolha dos esquemas a
24
serem integrados, a ordem da integração e uma possível atribuição das
preferências para esquemas inteiros ou das suas parcelas. A preferência a
aplicações financeiras do que aplicações de produção é um exemplo de como
uma política de integração pode ser gerenciada.
As estratégias globais para integração, quantidade de interação dos
desenvolvedores e o número de esquemas para serem integrados em um dado
tempo também são decididas nesta fase. A coleta de informação adicional
relevante à integração, tal como declarações ou constraints entre visões, é
considerada também uma parte desta fase.
4.2.2 Comparação dos esquemas
Os esquemas são analisados e comparados para determinar as
correspondências entre conceitos e para detectar possíveis conflitos. As
propriedades de interesquemas podem ser descobertas ao comparar
esquemas.
4.2.3 Adequação de esquemas
Uma vez que os conflitos forem detectados, um esforço é feito para
resolvê-los de modo que a união de vários esquemas seja possível. A
resolução automática do conflito não é geralmente praticável; a interação
próxima com desenvolvedores e usuários é requerida antes que os acordos
possam ser alcançados em qualquer atividade de integração da vida real.
4.2.4 União e reestruturação
Agora os esquemas estão prontos serem sobrepostos, causando
alguns esquemas intermediários integrados. Os resultados intermediários são
analisados e, se necessário, reestruturados a fim de se conseguir qualidades
25
desejáveis. Um esquema conceitual global pode ser testado de encontro aos
seguintes critérios qualitativos:
a) Integridade e exatidão.
O esquema integrado deve conter corretamente todos os conceitos
presentes em qualquer componente do esquema. O esquema integrado deve
ser uma representação da união dos domínios da aplicação associados com os
esquemas. O esquema conceitual global deve ser testado de acordo com os
seguintes quesitos:
b) Minimização.
Se o mesmo conceito for representado em mais de um componente
do esquema, este deve ser representado somente uma vez no esquema
integrado.
c) Compreensão.
O esquema integrado deve ser de fácil compreensão para o
desenvolvedor e o usuário final. Isto implica que entre diversas representações
possíveis dos resultados da integração permitidos por um modelo dos dados, o
mais compreensível deve ser escolhido.
26
5 COMPARAÇÃO DE METODOLOGIAS
Neste trabalho 12 Metodologias completas são consideradas. A
maioria das metodologias de integração analisadas aqui estão na categoria de
metodologias de integração de visões. De fato, todos exceto Dayal e o Hwang
[1984], Motro e Buneman [1981] e Mannino e Effelsberg [1984] pertencem a
esta classe. ElMasri et al[1987] pertence a área de integração de visões e da
integração de base de dados.
5.1 APLICABILIDADE DAS METODOLOGIAS DE INTEGRAÇÃO
Há uma pequena questão em decidir quando os esquemas são
integrados no caso da integração de base de dados. De qualquer forma, essa
integração tem que ser executada em esquemas existentes nas bases de
dados locais quando o que se deseja alcançar é uma relação global. Em
contrapartida, a integração de visões pode ocorrer em diferentes momentos
(veja Figura 2).
Então, vale a pena considerar a correspondência entre as fases do
projeto de base de dados e as metodologias de integração de visões. O
Quadro 1 mostra as fases em que as várias metodologias de integração de
visões podem ser melhor aplicáveis.
27
Fases do projeto de base de dados Referências
Entre análise de requisitos e projeto
conceitual
Kahn[1979]
Projeto Conceitual Batini e Lenzerini[1984], ElMasri et
al.[1987], Navathe and Gadgil[1982],
Teorey and Fry[1982], Wiederhold and
ElMasri[1979].
Projeto de Implementação Al-Fedaghi e Scheuermann[1981],
Casanova e Vidal[1983], Yao et al[1982]
Quadro 1 - Fases da integração de acordo com metodologias.
Executar a integração durante a fase de análise de requisitos é difícil
porque as exigências do usuário são geralmente muito deficientes em termos
estruturais, e é difícil negociar em termos de uma metodologia formal
envolvendo análise semântica. Entre as metodologias, somente Kahn [1979]
pode ser considerado aplicável à fase de análise de requisitos. Além disso,
executar a integração durante a fase de implementação do projeto é difícil
porque as representações nesse ponto não permitem que se faça uso eficaz
das abstrações.
Metodologias tais como Al-Fedaghi-Fedaghi e Scheuermann [1981] e
Yao et al. [1982] são capazes de realizar a integração como uma parte da fase
de projeto lógico trabalhando com um modelo de dados relacional (ou
funcional) e vários tipos de dependências. Os algoritmos relacionais puros para
síntese (por exemplo, Bernstein [1976] e Biskup et al. [1979]) também podem
ser considerados exemplos desta abordagem. Portanto, não tratam de
abstrações ou construções semânticas mais poderosas.
As observações acima sugerem que a fase preferida para integração
está na fase do projeto conceitual, onde o uso de abstração será muito útil para
comparar e adequar diferentes percepções dos domínios da aplicação por
diferentes grupos de usuários. Outro ponto de vista é a respeito da fase de
28
quando a integração do esquema deve ser feita. Isto pode ser analisado pelas
indicações abaixo:
a) Executar a integração assim que possível porque o custo de
carregar dados errôneos e/ou inconsistentes aumenta durante o
ciclo de vida da base de dados e da aplicação.
b) Executar a integração somente após a correção, integridade,
minimização e redução de ambigüidade.
Isto conduz que a integração do esquema deve ser feita após a
análise de requisitos mas antes do projeto de implementação. Metodologias
[Batini e Lenzerini 1984; ElMasri et al. 1987; Navathe e Gadgil 1982; Teorey e
Fry 1982; Wiederhold e ElMasri 1979] confirmam esta posição. Estas
metodologias foram inseridas sob o conceito de "projeto conceitual" no Quadro
1 de acordo com a terminologia atual. A integração da base de dados pode ser
considerada aplicada mais à fase do projeto conceitual. O ponto de vista acima
é confirmado por [ Dayal e Hwang 1984; ElMasri et al. 1987; Mannino e
Effelsberg 1984; Motro e Buneman 1981 que fazem a integração da base de
dados advogando a tradução de esquemas lógicos heterogêneos em
representações de dados conceituais. Assim, todas as metodologias para a
integração da base de dados [Dayal e Hwang 1984; ElMasri et al. 1987;
Mannino e Effelsberg 198â; Motro e Buneman 19811 são incluídas nessa
categoria.
5.2 CARACTERÍSTICAS DAS ENTRADAS E SAÍDAS
A entrada básica à integração do esquema são um número de
esquemas componentes e a saída básica é um esquema integrado. O Quadro
2 mostra as entradas e as saídas específicas feitas por diferentes
metodologias. Navathe e Gadgil [1982] representaram o processo da
integração de visões com uma lista detalhada das entradas e saídas, que
29
significam aproximadamente uma união de todas as metodologias. Abaixo está
descrito a terminologia associada a representação acima descrita:
a) Visão da empresa. Pertinente somente à integração de visões, e
não a integração da base de dados, esta visão é um esquema
conceitual inicial no qual a visão da empresa é a mais importante
no domínio da aplicação. Ter tal visão torna as atividades de
comparação e adequação mais fáceis.
b) Declarações. Estes correspondem aos constraints. As
declarações de intravisão são constraints definidas em conceitos
dentro de um esquema, visto que as declarações da intervisão são
constraints entre os conceitos pertencentes a diferentes visões.
Metodologias que assumem declarações de intervisão para serem
entradas implicitamente requerem que algum conhecimento global
que pertence a diversas aplicações esteja fornecida ao
desenvolvedor. As declarações modificadas na saída serão
constraints revisadas.
c) Processamento de requisitos. Refere-se às operações definidas
em componentes de visões. Podem ser especificados na forma de
uma linguagem de manipulação de dados de alto nível.
d) Mapeamento de regras. Estes definem o mapeamento das
consultas (operações) aplicáveis aos componentes do esquema
para consultas (operações) no esquema integrado.
e) Indicação dos conflitos. Este é um conjunto de conflitos que o
desenvolvedor não pode resolver e que fica além do escopo da
metodologia.
30
Referência Entrada Saída
Al-Fedaghi and
Scheuermann[1981]
N visões externas N esquemas externos
Esquema conceitual
Mapeamento entre
esquemas externos e
esquemas conceituais
Batini e Lenzerini[1984] Esquemas do usuário
Esquemas da empresa
Esquema global
Casanova and Vidal[1983]
Visões do usuário Esquema Conceitual
Dayal and Hwang[1984] Esquemas locais de
bases de dados existentes
Consultas
Interface global para as
bases de dados
Consultas modificadas
ElMasri et al.[1987] Esquemas locais
Declarações de
interesquemas
Esquema Global
Mapeamento de regras
Kahn[1979] Estruturas de informação
locais
Estrutura de informação
global
Motro e Buneman[1981] Esquemas lógicos
Consultas a base de
dados
Supervisões
Consultas modificadas
Mannino e
Effelsberg[1984]
Esquemas locais
Declarações de
interesquemas sobre
entidades e atributos
Esquema global
Mapeamento de regras
Definição dos objetos de
integração de esquemas
Navathe e Gadgil[1982] Visão empresarial
Visões locais
Declarações de
intervisões
Declarações de
intravisões
Processamento de
requisitos
Visão global
Mapeamento de regras
Declarações modificadas
Conflitos
Teorey and Fry[1982] Informação, aplicação, Estrutura global de
31
Referência Entrada Saída
eventos, perspectivas
corporativas, política de
direção e regras
informação
Conflitos
Yao et al.[1982] Visões
Processamento de
especificações
Visão global
Processamento de
especificações modificada
Wiederhold and
ElMasri[1979]
Dois esquemas Esquema global
Quadro 2 - Entradas e Saídas.
5.3 ARQUITETURAS DAS METODOLOGIAS
Vamos considerar as quatro atividades do processo de integração. No
Quadro 3, nós mostramos as etapas que são executadas por cada uma das
metodologias . É possível classificar os metodologias em quatro grupos tendo
como base o Quadro 3:
a) Aqueles que executam uma comparação repetitiva, adequação e
união dos esquemas, e tratam da necessidade de reestruturação
mais tarde [Mannino e Effelsberg [1984]; Navathe e Gadgil [1982];
Wiederhold e ElMasri [1979]].
b) Aqueles que executam a maioria das atividades durante e depois
da união dos esquemas. Esses incluem somente as etapas 3 e 4 e
evitam a comparação e adequação dos esquemas [al-Fedaghi-
Fedaghi e Scheuermann [1981]; Casanova e Vidal [1983]; Motro e
Buneman [1981]; Teorey e Fry [1982]; Yao et al. [1982]]
c) Aqueles que executam todas as atividades [Batini e Lenzerini
[1984]; Dayal e Hwang [1984]; ElMasri et al. [1987]; Kahn [1979]].
32
d) Aqueles que mencionam explicitamente a fase de pré integração
[ElMasri et al. [1987]; Mannino e Effelsberg [1984]; Navathe
Gadgil [1982]].
Quadro 3 - Atividades da integração de esquemas.
Na base da estrutura de ligações de acordo com o Quadro 3, as
seguintes similaridades podem ser observadas:
a) Casanova e Vidal [1983] e Teorey e Fry [1982] tem uma
abordagem relacionada a "sem-feedback". Eles somente
Referência PreIntegração(Passo1)
Comparação(Passo2)
Adequação(Passo3)
União(Passo4)
Reestruturação(Passo5)
Al-Fedaghi andScheuermann[1981] - - - X X
Batini eLenzerini[1984] - X X X X
Casanova andVidal[1983] - - - X X
Dayal andHwang[1984] - X X X X
ElMasri et al.[1987] X X X X X
Kahn[1979] - X X X X
Motro eBuneman[1981] - - - X X
Mannino eEffelsberg[1984] X X X X -Navathe eGadgil[1982] X X X X -Teorey andFry[1982] - - - X X
Yao et al.[1982] - - - X X
Wiederhold andElMasri[1979] - X X X -
33
executam as etapas de união e reestruturação.
b) Al-Fedaghi e Scheuermann [1981]; Dayal e Hwang [1984], Motro e
Buneman [1981], e Yao et al. [1982] são similares ao grupo que
executa somente união e restruturação; entretanto, permitem um
feedback entre estas duas etapas.
c) Kahn [1979], Mannino e de Effelsberg [1984], Navathe e de Gadgil
[1982], e Wiederhold e ElMasri [1979] provem uma ligação global
do fim do processo a atividade inicial da comparação. Kahn [ 1979
] inclui a etapa de reestruturação, visto que os outros não .
d) Finalmente, Batini e Lenzerini [1984] e ElMasri et al.[1987] cobrem
todas as etapas; além disso, fornecem uma execução interativa
das etapas de comparação e adequação antes de qualquer união.
De acordo com essas informações, essa metodologia parece ter a
máxima interação com o usuário/desenvolvedor.
5.4 PRÉ INTEGRAÇÃO
Como mostrado no Quadro 3, somente três metodologias(ElMasri et
al. [1987]; Mannino e Effelsberg [1984]; Navathe e Gadgil [1982]), mencionam
explicitamente a etapa de pré integração. Essa fase basicamente propõe uma
coleção de correspondências entre esquemas na forma de constraints e
declarações entre componentes de esquemas. Estas especificações são
utilizadas, por exemplo, para relatar nomes, estabelecer que um objeto em um
esquema é resultado de alguma operação de um conjunto de objetos em outro
esquema, etc..
Para todas as metodologias, se a pré integração não for mencionada
explicitamente, a seqüência e o agrupamento dos esquemas para a integração
têm que ser consideradas. Nesta seção é descrita as diferentes estratégias que
se dirigem a este problema.
34
A primeira etapa, escolha dos esquemas, envolve o processamento
de componentes dos esquemas em alguma seqüência. No general, o número
dos esquemas considerados para a integração de cada etapa deve estar em n
>= 2.
A Figura 15 mostra quatro variações possíveis denominadas
estratégias de processamento da integração. Cada estratégia é mostrada na
forma de uma árvore. Os nós da folha correspondem aos componentes do
esquema e os nós não folha correspondem aos resultados intermediários da
integração. O nó da raiz é o resultado final.
A classificação preliminar das estratégias é binária contra n-ária. As
estratégias binárias permitem a integração de dois esquemas de cada vez.
Estas são chamadas estratégias escada quando um novo componente do
esquema é integrado com um resultado intermediário existente em cada etapa.
Uma estratégia binária é dita equilibrada quando os esquemas são divididos
em pares no início e são integrados em uma forma simétrica (veja a Figura 15).
As estratégias n-árias permitem a integração de n esquemas de uma só vez (n
> 2). Uma estratégia n-ária é one shot quando os n esquemas são integrados
em uma única etapa; caso contrário ela é dita iterativa. A última classificação é
o caso o mais geral.
Figura 15 - Tipos de estratégias de processamento de integração.
35
O Quadro 4 é uma comparação das metodologias entre duas
dimensões: binária versos n-ária.
A vantagem da estratégia binária é a simplificação das atividades de
comparação e adequação para cada passo da integração. É evidente que a
maioria das metodologias adotam estratégias binárias devido ao aumento da
complexidade do processo de integração com respeito ao número de
esquemas a serem integrados. Em geral, um algoritmo de união de n
esquemas pode ter uma complexidade n2 . A desvantagem dessa alternativa é
o aumento no número de operações de integração para se chegar a uma
análise final.
A estratégia n-ária de integração realiza uma análise de n esquemas
de uma vez. As óbvias vantagens disso são: um aumento considerável de
análise semântica que pode ser realizada antes da união de esquemas,
evitando assim a necessidade de transformações futuras no esquema
integrado; O número de passos para integração é minimizado.
Referência Tipo de estratégia de Integração
Equilíbrio
Al-Fedaghi and Scheuermann[1981]
One-shot n-ária -
Batini e Lenzerini[1984] Binária Escada
Casanova and Vidal[1983]
Binária Equilibrada
Dayal and Hwang[1984]
Binária Sem declaração
ElMasri et al.[1987] One-shot n-ária -
Kahn[1979] Binária Sem declaração
36
Referência Tipo de estratégia de
Integração Equilíbrio
Motro e Buneman[1981] Binária
Sem declaração
Mannino e Effelsberg[1984]
Binária Sem declaração
Navathe e Gadgil[1982]
n-ária interativa -
Teorey and Fry[1982] Binária Equilibrada
Yao et al.[1982] One-shot n-ária -
Wiederhold and ElMasri[1979]
Binária Escada
Quadro 4 - Estratégias de processamento de integração.
5.5 COMPARAÇÃO DOS ESQUEMAS
A atividade fundamental nessa etapa consiste em verificar todos os
conflitos na representação dos mesmos objetos em esquemas diferentes. Das
metodologias descritas de um modo geral distinguimos dois tipos de conflitos
(veja o Quadro 5): nomeando conflitos e conflitos estruturais. Nós
examinaremos agora cada um em detalhes.
5.5.1 Nomeando conflitos
Os esquemas em modelos dos dados incorporam nomes para os
vários objetos representados. Pessoas de diferentes áreas de aplicação da
mesma organização consultam aos mesmos dados usando a suas próprias
terminologias e nomes. Isto resulta em uma proliferação de nomes bem como
uma possível inconsistência entre nomes nos componentes dos esquemas. Os
relacionamentos problemáticos entre nomes são de dois tipos:
a) Homônimos: Quando o mesmo nome for usado para dois
37
conceitos diferentes causando inconsistências. Considere os dois
esquemas mostrados na Figura 16. Ambos os esquemas incluem
uma entidade nomeada Equipment. Entretanto, o Equipment na
Figura 16a refere-se a computadores, copiadoras, etc.., visto que
na Figura 16b refere-se a equipamentos como condicionadores de
ar. É óbvio que unir as duas entidades no esquema integrado
resultaria em produzir uma entidade para dois objetos conceituais
distintos.
b) Sinônimos: Quando o mesmo conceito for descrito por dois ou
mais nomes. A menos que diferentes nomes melhorem o
entendimento de diferentes usuários, eles não são justificados. Um
exemplo aparece na Figura 17, onde o Client e o Customer são
sinônimos; as entidades com estes dois nomes nos dois
esquemas referem-se ao mesmo conceito no mundo real. Neste
caso, manter duas entidades distintas no esquema integrado
resultaria na modificação de um único objeto por meio de duas
entidades diferentes.
Note que homônimos podem ser detectados comparando conceitos
com o mesmo nome em esquemas diferentes, ao passo que sinônimos podem
somente ser detectados após uma especificação externa.
Dicionários de dados tem sido utilizados como ferramenta adjunta
para o processo de integração de esquemas para um melhor gerenciamento de
nomes.
38
Figura 16 - Exemplo de homônimo.
Figura 17 - Exemplo de sinônimo.
Referência Conflitos de nome
Conflitos estruturais
Al-Fedaghi and Scheuermann[1981] - -
Batini e Lenzerini[1984]
Homônimos Sinônimos
Inconsistência de tipos Conflitos de constraints de integridade
Casanova and Vidal[1983]
- -
Dayal and Hwang[1984]
Homônimos Sinônimos
Conflitos a nível de esquema: Diferenças de escala Diferenças estruturais Diferenças na abstração Inconsistências a nível de dados: Vários níveis de obsolescência e segurança
ElMasri et al.[1987] Homônimos Sinônimos
Tratamento de conflitos, especificamente:
39
Referência Conflitos de
nome Conflitos estruturais
Declarações de equivalência de atributos Equivalência de classes de entidades
Diferenças em níveis de abstração Diferenças em regras, graus e constraints de cardinalidade em relacionamentos
Kahn[1979] Homônimos Sinônimos
Conflitos de cardinalidade
Motro e Buneman[1981] - -
Mannino e Effelsberg[1984]
Uso de qualificadores de nome Especificação de atributos de equivalência
Diferenças em abstrações
Navathe e Gadgil[1982]
Homônimos Sinônimos
Conflitos de dependência Conflitos de redundância Conflitos de modelagem
Teorey and Fry[1982] - -
Yao et al.[1982] - -
Wiederhold and ElMasri[1979]
- Conflitos de cardinalidade
Quadro 5 - Conflitos estruturais e de nome.
5.5.2 Conflitos estruturais
Utilizamos o termo conflitos estruturais para englobar conflitos que
aparecem em conseqüência de uma escolha diferente de modelar construções
ou constraints de integridade. A seguinte classificação distingue os seguintes
tipos de conflitos:
a) Tipo de Conflitos. Estes aparecem quando o mesmo conceito é
representado por diferentes construções de modelagem em
40
esquemas diferentes. Este é o caso quando, por exemplo, uma
classe de objetos é representada como uma entidade em um
esquema e como atributo em outro esquema.
b) Conflitos de dependência. Estes aparecem quando um grupo de
conceitos são relacionados a si mesmos com diferentes
dependências em esquemas diferentes. Por exemplo, o
relacionamento Casamento entre homem e mulher é 1: 1 em um
esquema, mas pode ser m: n em outro.
c) Conflitos de chave. As diferentes chaves são associadas ao
mesmo conceito em esquemas diferentes. Por exemplo, SS # e
identificação de Empregado podem ser as chaves do empregado
em dois componentes de esquemas.
d) Conflitos de Comportamento. Estes surgem quando as diferentes
políticas de inserção/deleção são associadas com a mesma classe
de objetos em esquemas distintos. Por exemplo, em um esquema
um departamento pode ter a permissão de existir sem
empregados, visto que outro, quando o último empregado
associado com um departamento é deletado, é feita a deleção
automática do departamento. Note que estes conflitos podem
surgir somente quando o modelo dos dados permitir a
representação comportamental das propriedades dos objetos.
5.6 ADEQUAÇÃO DE ESQUEMAS
O objetivo desta atividade é adequar ou alinhar esquemas para fazê-
los compatíveis para o processo de integração. Para conseguir este objetivo,
deve-se resolver os conflitos, que por sua vez exigem que transformações
desse esquema sejam feitas. A fim de resolver um conflito, o desenvolvedor
deve compreender os relacionamentos semânticos entre os conceitos
41
envolvidos no conflito. Às vezes os conflitos não podem ser resolvidos porque
surgiram em conseqüência de alguma inconsistência básica. Neste caso, os
conflitos são relatados aos usuários, que devem guiar o desenvolvedor em sua
definição. A Figura 18 mostra três exemplos de como transformar um atributo
em uma entidade, como sugerido por Batini e Lenzerini [1984].
Figura 18 - Transformação de um atributo em uma entidade.
5.7 UNIÃO E REESTRUTURAÇÃO
As atividades executadas por metodologias durante esta fase
geralmente requerem diferentes tipos de operações a serem executadas nos
componentes dos esquemas ou no esquema integrado temporário.
Estabelecendo uma estrutura comum para esta fase, nós supomos que todas
as metodologias primeiramente unem os componentes de esquemas por meio
de uma sobreposição simples de conceitos comuns, e executamos então
operações de reestruturação no esquema integrado obtido por união.
O Quadro 6 mostra as transformações propostas nas metodologias
para esta etapa. Cada transformação é executada a fim melhorar o esquema
42
com respeito a um dos três quesitos descritos na seção 5: integridade,
minimização e entendimento. Nós analisamos agora cada um deles
separadamente.
Referência Propriedades de Interesquema
Al-Fedaghi and Scheuermann[1981] -
Batini e Lenzerini[1984]
Subconjuntos Generalização Relacionamentos
Casanova and Vidal[1983]
Dependências de Inclusão Dependências de exclusão Dependências funcionais de união
Dayal and Hwang[1984]
Subconjuntos Subfunções
ElMasri et al.[1987]
Declarações relacionadas a extensões Agrupamento de atributos em classes
Kahn[1979] -
Motro e Buneman[1981] Subconjuntos
Mannino e Effelsberg[1984]
Generalização Sobreposição e não sobreposição Escopo de atributos e significados
Navathe e Gadgil[1982]
Categorização Subconjuntos Particionamento
Teorey and Fry[1982]
Generalização Agregação
Yao et al.[1982] -
Wiederhold and ElMasri[1979]
Subconjuntos
Quadro 6 - Propriedades de interesquema.
43
5.7.1 Integridade
Para conseguir a integridade, o desenvolvedor tem que concluir a
análise e a adição de propriedades do interesquema que é iniciada em etapas
precedentes ao projeto. Na Figura 14 nós mostramos exemplos de
propriedades de interesquemas. No Quadro 6 nós apresentamos uma lista
detalhada das propriedades do interesquemas mencionadas nas metodologias.
Note que subconjunto é a propriedade do interesquema usada para a maioria
de metodologias. De fato, essa propriedade considera-se ser a base para
múltiplas perspectivas do usuário em classes de objetos comparáveis.
5.7.2 Minimização
Na maioria das metodologias, o objetivo da minimização é descobrir e
eliminar redundâncias. Uma noção de minimização é ilustrada na Figura 19
onde três relacionamentos estão presentes, indicados por setas.
O relacionamento entre Engineering_manager and Employee é
redundante. Necessita-se então reduzir os conceitos deletando os
relacionamentos redundantes.
.
Figura 19 - Um esquema com redundância.
44
5.7.3 Compreensão
A questão de compreensão é difundida em todas as metodologias. O
problema é dirigido explicitamente por Batini e Lenzerini [1984]. Como exemplo
temos a Figura 20, onde se discute termos qualitativos. Enquanto dois
esquemas são equivalentes, o esquema B está mais compreensível do que o
esquema A. O esquema B foi obtido do esquema A adicionando uma
generalização hierárquica relacionando Publication para Book e Paper. No
general, para melhorar a compreensão, transformações adicionais no esquema
são necessárias.
Figura 20 - Aprimorando o entendimento.
45
6 METODOLOGIA DE UNIÃO DE ESQUEMAS DE ELMASRI
6.1 VISÃO GERAL DA METODOLOGIA
Esta metodologia utiliza uma variante do modelo de entidade
relacionamento (E-R) para representar esquemas ou visões do usuário e
discutir o problema de integrar relacionamentos de esquemas diferentes.
Usando três critérios principais para comparar relacionamentos, foi
desenvolvido um esquema hierárquico de comparação. Cada caso
representado pelos nós terminais desta hierarquia é discutido separadamente e
as regras da integração são desenvolvidas. O problema é tratado dentro de um
sentido geral de modo que a discussão qualitativa seja aplicável a diversos
outros modelos semânticos de dados.
Com a atual diversidade dos modelos de dados e dos sistemas de
gerenciamento de base de dados, o problema da integração de esquemas tem
se tornado cada vez mais importante. A integração de esquemas baseia-se em
dois contextos diferentes:
a) Projeto global do esquema.
b) Projeto de base de dados lógico.
No projeto global do esquema, diversas bases de dados já existem e
estão em uso. O objetivo é projetar um único esquema global que represente
os índices de todas estas bases de dados. Este esquema global pode então
ser usado como uma relação às diversas bases de dados.
As consultas e transações do usuário podem então ser especificadas
de encontro a este esquema global, e os pedidos são mapeados às bases de
dados relevantes.
A integração do esquema é aplicável ao projeto global do esquema
em ambientes centralizados e distribuídos. Nesta metodologia de trabalho é
46
focalizada o uso da integração de esquemas no projeto de base de dados
lógico. Porém a filosofia total da integração de esquemas discutida aqui se
aplica a ambos os contextos.
6.2 ABORDAGEM DA INTEGRAÇÃO DE VISÕES
Agora veremos algumas características importantes na integração de
visões. O esboço do procedimento da integração consiste em:
a) Especificação e modificação interativa de intervisões e intravisões
pelos desenvolvedores da base de dados. Esta é uma fase de pré-
integração para especificar as correspondências exatas entre os
atributos, as classes do objeto e os relacionamentos nas diferentes
visões.
b) Integração interativa das classes do objeto e de relacionamentos
baseadas nas afirmações especificadas. Algumas afirmações
podem ser modificadas durante esta fase.
c) Geração de mapeamentos do esquema global para as visões
locais.
A integração de relacionamentos aplica-se durante a etapa 2 descrita
acima. A filosofia por trás da integração de visões é de chegar a uma “estrutura
de compromisso". Quando apresentadas visões alternativas de uma mesma
situação, nós aceitamos a visão mais geral. Qualquer constraint adicional é
localmente aplicável a uma visão do usuário pode sempre ser reforçada no
ponto de visão mais geral. No contexto do modelo do E-C-R, a integração de
visões do usuário resultam em uma combinação das seguintes mudanças a
uma visão de modo que a semântica da outra visão possa ser acomodada:
a) Criando categorias novas de uma ou mais classes entidade.
b) Definindo relacionamentos novos entre classes entidade e
categorias recentemente criadas.
47
c) Fazer novos relacionamentos ou sub relacionamentos.
6.2.1 Fase de pré-integração
A fase de pré-integração é necessária para especificar
correspondências entre objetos em diferentes visões. Nesta fase é tratado, por
exemplo, os problemas de homônimos e sinônimos. A fase de pré-integração
estabelece os seguintes contextos entre as visões individuais do usuário:
a) Correspondências de nomes de classe.
b) Correspondências de nomes de atributos
c) Chaves candidatas para cada classe.
d) Correspondências entre classes de entidades em diversas visões.
e) Correspondências entre nomes de regras e relacionamentos
A noção de similaridade entre classes de objetos é difícil de definir
precisamente. Por exemplo, se na visão 1 temos a classe Engenheiro e na
visão 2 temos Secretário, as duas classes incluem o mesmo tipo de entidade
(Empregado), mas não terão qualquer das entidades em comum. Esta
conclusão não pode ser descrita se compararmos a string Engenheiro com a
string Secretário. Uma outra comparação das strings Engenheiro e Supervisor
indicam que são dissimilares; porém o relacionamento entre elas não será o
mesmo que no caso precedente, desde que possam compartilhar de algumas
entidades em comum.
É possível desenvolver uma ferramenta automatizada para ajudar os
desenvolvedores em estabelecer correspondências de classes comparando as
strings com os nomes de classes e nomes do atributo. Este método pode
detectar os homônimos onde os nomes das strings são coincidentes, mas o
significado pode ser diferente. Contudo, quando as diferentes visões tiverem
nomes completamente diferentes para classes similares de entidades
(sinônimos), a responsabilidade inteira de denotar quais classes são similares é
48
voltada ao desenvolvedor. Assim, os três fatores seguintes contribuem para o
estabelecimento do grau de similaridade ou grau de adaptação entre visões:
a) Uma especificação de quais classes são similares, idênticas, por
sobreposição, ou contida em outra. Pode ser feita em uma
linguagem especialmente projetada para especificação de
constraints.
b) Um sistema de comparação guiada de nomes de strings.
c) Entrada do desenvolvedor para confirmar e resolver
correspondências.
6.2.2 Revisão de integração de objetos
Antes de entrar na questão da integração de relacionamentos, vamos
nos dirigir momentaneamente à integração de classes de objeto. A integração
de objetos é precursora à integração de relacionamentos, desde que depois da
integração de objetos seja possível determinar a similaridade dos
relacionamentos. Uma vez que a similaridade entre classes de objetos é
estabelecida durante a fase de pré-integração, objetos similares de todas as
visões podem ser integrados.
Integrar duas classes do objeto de visões diferentes depende das
extensões destes objetos de base de dados quando a base de dados está
povoada. Nós referimos à extensão da classe do objeto em uma visão do
domínio da classe do objeto. Duas classes de objeto similares A e B de
diferente visões podem ser relatadas de várias maneiras:
a) DOM(a)=DOM(b)
b) DOM(A)⊆DOM(B)
c) DOM(A)∩ DOM(B)≠0 E DOM(A)⊄ DOM(B) E DOM(B)⊄ DOM(A)
d) DOM(A)∩ DOM(B)=0
49
Quando integramos classes de objetos, as constraints acima
mencionadas terão que ser refletidas no esquema global. Elmasri e Navathe
[ELMA84] discutiram o processo da integração de objetos em detalhes. Aqui
será mencionado resultados resumidos para cada um dos casos acima.
DOM(a)=DOM(b)
Os objetos no domínio A são idênticos aos objetos no domínio B, isto
é, as extensões dos objetos em A e B são idênticas. Neste caso as classes de
objetos A e B são integradas e uma única classe do objeto C é criada.
Considere o exemplo mostrado na Figura 21.
Figura 21 - Domínios idênticos
Após a afirmação pelo desenvolvedor que o domínio Employee na
visão 1 é idêntico ao domínio Workers na visão 2, uma classe de objetos
integrada Employers é criada. Os atributos da classe recentemente criada são
a união dos atributos das classes idênticas unidas. Se as chaves de ambas as
classes não forem as mesmas, então o desenvolvedor selecionará uma chave
preliminar para a classe C, e outras chaves se transformarão em chaves
secundárias no esquema conceitual.
DOM(A)⊆DOM(B)
Quando o domínio de uma classe B é um subconjunto do domínio da
classe A, o objeto B está representado como uma categoria para denotar o
relacionamento da subclasse. Considere dois objetos, Students e Graduate-
Students em duas visões. O domínio da classe Graduate-Students é um
subconjunto da classe de objetos Students. A integração é mostrada abaixo na
Figura 22.
50
Figura 22 – Subconjuntos
Ao integrar N classes de objetos, uma hierarquia de sub classes de
relacionamentos é estabelecida.
DOM(A)∩ DOM(B)≠0 E DOM(A)⊄ DOM(B) E DOM(B)⊄ DOM(A)
Neste caso, mesmo que os objetos A e B sejam relacionados,
nenhum é um subconjunto do outro. Na integração das classes A e B, um
objeto classe AB cujo domínio é a união das classes A e B está criada.
Considere dois objetos trucks e TRACTOR-TRAILER em duas visões
diferentes. Claramente as classes de objetos não se contêm mas estão
relacionadas. Integrar classes de objetos resulta em uma hierarquia da
generalização. O resultado é uma classe entidade Vehicle e duas subclasses
Truck e Tractor-Trailer como mostrado na Figura 23.
Figura 23 - Hierarquia de generalização.
O domínio da classe Vehicles é a união dos domínios Trucks e o
Tractor-Trailer.
51
DOM(A)∩ DOM(B)=0
Neste caso, mesmo que as classes sejam especificadas para serem
similares pelo desenvolvedor, elas não têm objetos em comum. A integração
de tais objetos é deixada para o desenvolvedor. Aquelas classes de objeto que
não são integradas serão retidas sem qualquer modificação.
6.3 INTEGRAÇÃO DE RELACIONAMENTOS
O problema da integração de relacionamentos está associado ao
problema de integrar classes de objetos. Dado uma classe entidade A1 em
uma visão V1, sempre há uma classe entidade “similar” ou “compatível” A2 na
visão V2, ou seja, todos os relacionamentos dos quais A1 participa torna-se um
potencial assunto de integração com todo o relacionamento que A2 participa. A
real união dos relacionamentos, contudo, está sujeita a semântica que é
determinada pelas regras das classes de entidade, do grau, das relações de
cardinalidade dos relacionamentos, etc.
Além disso, quando classes de entidade A1 e B1 em V1 combinam
respectivamente A2 e B2 em V2, há uma potencial probabilidade de vários
tipos de relacionamentos existirem entre os pares das entidades. Somente
após um exame semântico detalhado destes relacionamentos, os mesmos
podem ser integrados. Especificações externas que relacionam construções
entre visões assim como a entrada do desenvolvedor são feitas para ajudar na
determinação de quais relacionamentos devem ser sujeitados a uniões. Uma
suposição implícita diz que os relacionamentos estão sendo analisados de dois
em dois para a integração. As idéias são aplicáveis para a integração n-ária;
entretanto, os detalhes mecânicos da integração n-ária ainda devem ser
investigados.
52
6.3.1 Critérios para a comparação de relacionamentos
Com a finalidade da integração de visões, relacionamentos podem
ser classificados em três características diferentes:
a) Grau de um relacionamento: O grau de um relacionamento é o
número de entidades (não necessariamente distintos) participando
nesse relacionamento. Uma entidade por si mesma pode ser
tratada como um relacionamento do zero grau para finalidades da
comparação com outros relacionamentos. A menos que
especificado de outra maneira, um relacionamento de n-grau teria
n classes de entidades participando nele.
b) Regras em um relacionamento: Uma regra significa a regra usada
por uma classe entidade em um relacionamento [BACH77,
CHEN76]. Há uma regra distinta para cada classe entidade que
participa de um relacionamento. A equivalência semântica dos
relacionamentos é baseada na correspondência entre regras e nas
instâncias dos relacionamentos. Durante a fase de pré-integração,
as correspondências acima são estabelecidas. Adicionalmente,
muitas linguagens de consultas a banco de dados suportam
diretamente nomes de regras em suas expressões da seleção: Se
os nomes de regras forem usados, o processo de modelagem e
recuperação de dados são facilitados para o usuário final.
c) Constraints estruturais: Um relacionamento entre duas classes de
objetos é um mapeamento que associa os objetos de uma classe
entidade com objetos da outras classes entidade. Qualquer regra
de especificação é suportada pelo modelo para expressar os
constraints que são chamados de constraints estruturais
[ELMA80]. Nós consideraremos constraints de cardinalidade como
o tipo preliminar de constraints estruturais no processo de
53
integração. Os constraints de cardinalidade em um relacionamento
binário colocam restrições no número dos objetos de uma classe
entidade que podem ser relacionados a um objeto da outra classe
entidade. Nós associamos dois números: a Max Cardinality e a
Min Cardinality para especificar, respectivamente, o número
máximo e o mínimo de instancias do relacionamento por uma
instância do dado tipo de entidade. Uma relação do com valor 0
implica uma participação parcial e 1 implica uma participação total
da entidade em um relacionamento. Para um relacionamento n-
ário, o conceito da relação da cardinalidade é normalmente
estendido para especificar o número de instancias do
relacionamento que podem ser relacionadas a uma entidade da
classe participante. Assim, em um relacionamento ternário (A, B,
C), as três relações de cardinalidade referem às relações de
ocorrências A: (B, C), B: (A, C) e C: (A, B). Estas relações são
usadas por Lenzerini e Santuccl [LENZ83] em suas técnicas de
especificação de cardinalidade. Alternadamente, as relações
(A,B):C, (B, C):A e (C, A):B são significativas e tem um papel
importante durante a integração (veja Figura 37).
6.3.2 Classificação dos relacionamentos
A fim de desenvolver uma abordagem sistemática à integração dos
relacionamentos, os três aspectos acima são considerados em forma de uma
estrutura de árvore. O nó superior da árvore é chamado de grau de um
relacionamento. No segundo nível, nós reconhecemos diferenças nas regras.
Isto tem dois possíveis resultados: a mesma regra ou uma regra diferente. O
último nível da árvore tem os nós chamados constraints estruturais. As bordas
são nomeadas como mostrado na . Elas indicam que os constraints estruturais
54
podem ser disjuntos, uma constraint pode ser um subconjunto de outra, ou os
dois conjuntos dos constraints podem se sobrepor. Os nós da folha desta
estrutura de árvore representam esultados possíveis quando os
relacionamentos das diferentes visões são comparados. Na metade esquerda
da árvore estão os casos mais fáceis de se negociar com a metade direita.
6.3.3 Unindo relacionamentos com o mesmo grau
Caso1 - Mesmas regras e mesmos constraints estruturais (ou a
ausência de constraints estruturais): Este é o exemplo mais simples de
integração de relacionamentos. Duas visões V1 e V2 contêm um
relacionamento entre duas classes entidade similares. Somente uma visão é
retida no esquema após a integração. Se uma classe entidade na visão V1 for
um subconjunto da classe entidade na visão V2, a subclasse correspondente
está criada para armazenar as entidades da visão V1.
Um exemplo deste tipo é mostrado na Figura 25 e Figura 26. A Figura
25 mostra duas visões de entrada onde o domínio da classe entidade classifica
Grad-Student e CS_Student que são diferentes em ambas as visões. O
esquema de integração(Figura 26) usa duas categorias chamadas
Grad_Student e CS_Student.
55
Figura 24 - Abordagem semântica dos relacionamentos.
Figura 25 - Relacionamentos com o mesmo grau.
Figura 26 - União de mesmo grau
56
Caso 2 - Mesmas regras e constraints estruturais diferentes: Neste
caso uma das visões tem mais constraints do que a outra. Considere um
exemplo onde para o relacionamento a ser integrado, a participação de uma
entidade ou visão V2 deve ser total, enquanto que a participação da mesma
entidade na visão V1 deve ser parcial. Desde que os constraints de ambas as
visões estejam conflitando, nós deixamos as constraints serem aplicadas - a
visão com a participação total remanesce no esquema.
O processo de integração é ilustrado na Figura 27 . A primeira visão é mantida
pelo secretário, onde alguns estudantes provavelmente não estão matriculados
em nenhum curso. A segunda visão é mantida pelo escritório da contabilidade,
que inclui somente estudantes atualmente registrados. A participação de
Students na visão V2 é total, enquanto é parcial na visão V1. O esquema
integrado é mostrado na Figura 28. Uma categoria denominada Registered-
Student é criada para conter todos os estudantes que participam no
relacionamento do registro. Qualquer Student que participa no relacionamento
Enrollment é feito automaticamente a um membro da categoria de Registered-
Student.
Regras diferentes: Quando regras diferentes são usadas nos
relacionamentos, os relacionamentos não são idênticos desde que se
conduzam em semânticas diferentes. Em muitos casos as classes de objetos
que participam no relacionamento não serão idênticos. Durante a integração
dos objetos, as sub-classes adicionais são criadas (veja Figura 32, com as sub-
classes Home-Borrower e Auto-Borrower).
Nós consideraremos três casos:
Caso 3 - Detenção: Neste caso o relacionamento na visão V2 contém
todos os exemplos da visão V1.
57
Figura 27 - Relacionamentos com constraints diferentes.
Figura 28 - União com constraints diferentes.
O relacionamento em V1 é um subconjunto (subrelação) do
relacionamento em V2. Os esquemas isolados e integrados são mostrados na
Figura 29 . O esquema reflete o fato que o relacionamento Advisor é um
subconjunto de Committee. Isto ajudaria a manter a integridade da base de
dados, onde todos as instancias no relacionamento Advisor devem estar
contidas no relacionamento Committe.
58
Figura 29 – Detenção
Caso 4 - Relacionamentos disjuntos: Quando os relacionamentos nas
visões transportam semânticas diferentes e não são próximos, então os
relacionamentos estão incluídos no esquema sem qualquer modificação.
59
Figura 30 - Relacionamentos disjuntos
No exemplo acima, os relacionamentos na visão V1 e V2 estão
disjuntos nos termos de seus índices. As duas visões são mantidas no
esquema sem nenhuma modificação. O esquema inicial e resultante são
mostrados na Figura 30.
Caso 5 - Relacionamentos cruzados: Os relacionamentos descritos
entre o mesmo conjunto de entidades em duas visões poderiam ter algumas
instâncias em comum, mas nenhum dos relacionamentos nas visões é um
subconjunto do outro. Considere as visões mostradas na Figura 31.
Figura 31 - Relacionamentos cruzados.
60
Figura 32 - União de relacionamentos cruzados.
A entidade Person poderia ser um Home Borrower e um Auto
Borrower. As instancias de Person em ambas as visões se sobrepõem. Então
duas categorias são criadas na classe entidade Person durante a integração do
objeto. Estas categorias poderiam ser atributos definidos por sub-classes ou o
usuário definiria as subclasses. Se estas categorias fossem atributos definidos
então uma inserção de uma instância de Person criaria automaticamente uma
instancia da categoria respectiva.
No caso em que o usuário definiu a categoria, o usuário tem que
especificar a inclusão das categorias. O esquema após a integração do
relacionamento é mostrado na Figura 32.
6.3.4 Unindo relacionamentos de diferentes graus
Quando são integrados relacionamentos de grau diferente, as
seguintes possibilidades existem:
- O relacionamento do grau mais baixo é derivado do
relacionamento de um grau mais elevado. A derivabilidade deve ser definida no
contexto de um dado SGDB no qual o esquema integrado está para ser
61
implementado. Uma definição informal possível é a seguinte: uma visão V1 é
derivável de v2 se toda ocorrência de entidade e relacionamento V1 ocorrer
diretamente em V2 ou possa ser gerado de V2 pelo uso de linguagens de alto
nível (como SQL ou GORDAS [ ELMA81]).
- Os diferentes relacionamentos podem ser compatíveis reforçando
constraints semânticas adicionais. Estes constraints são do seguinte tipo:
a) Constraints de Cardinalidade entre três ou mais tipos de
entidades; por exemplo, para o relacionamento (A, B, C), relações
de cardinalidade (A, B):C, (A, C):B e (B, C): A, qual são
tipicamente ausentes de notações gráficas são importantes para
reforçar a compatibilidade. Lenzerini e Santucci [LEN83] fornecem
alguns bons exemplos de diferentes constraints de cardinalidade.
b) Constraints de subconjuntos entre classes de entidade
c) Constraints deriváveis fazem uma visão derivável de outras
constraints. Essas constraints tomariam formas de especificações
complexas que podem usar linguagens de nível mais elevado.
d) Os diferentes relacionamentos não podem ser tratados como a) ou
b) acima. Então eles ficam coexistindo na integração de visões de
e fica nas mãos do desenvolvedor ter a palavra final na união.
Unir relacionamentos de diferentes graus é mais complicado quando
os relacionamentos de mais elevado grau contam com mais informação
semântica. Conseqüentemente duas considerações são mantidas:
a) Ao unir relacionamentos de graus diferentes, o relacionamento de
grau mais elevado é sempre retido.
b) Toda a tentativa de "derivar" os relacionamentos de grau mais
elevado combinando relacionamentos de grau mais baixos usando
operadores de linguagem de alto nível como SQL, sem considerar
a semântica dos dados, pode render resultados falsos. Nós
classificamos a integração dos relacionamentos de diferente graus
62
em três diferentes tipos como a estrutura mostrada na Figura 33.
Estes três casos são discutidos abaixo:
Figura 33 - Classificação de relacionamentos de diferentes graus.
Relacionamentos unificáveis: Dois relacionamentos são unificáveis
quando um relacionamento pode ser derivado do outro. Isto se aplica aos
casos onde um relacionamento em uma visão está representado por uma
entidade (isto é, um relacionamento com grau zero) em uma outra visão.
Considere duas visões V1 e V2 como mostrado na Figura 34.
Figura 34 - Relacionamentos Unificáveis.
A entidade na visão V2 é referida como uma "entidade comprimida“
[NAVA76] Na visão V2, a entidade comprimida Car-Ownership não tem
qualquer constraint de na relação entre Person e Car, isto é, pode ser
considerada uma relação de muitos–para-muitos. A visão V2 pode ser derivada
63
de V1. Os constraints de mapeamento (1:1, 1:n, N:1, ou m:n) na visão V1
podem ser reforçados em V2 pela escolha apropriada das chaves. Para o
exemplo, se SSN e LIC# forem as chaves das entidades Person e Car,
respectivamente, então as possíveis chaves de Car-Ownership seja: SSN
sozinho (N:1), LIC# (para 1:N), SSN ou LIC# (para 1:1) ou a chave combinada
SSN ou LIC# (para m:n).
A união é praticável se a chave em V2 encontra a constraint de
mapeamento em V1. Argumentos similares aplicam-se em geral para
relacionamentos n-ários onde um entidade na visão V2 possa ser considerada
equivalente para compressão de algumas entidades. O resultado da integração
no caso acima é a visão V1
Relacionamentos unificáveis por condição: Em alguns casos da união
de relacionamentos, dois relacionamentos poderiam ser unificados somente
quando as informações semânticas adicionais forem especificadas. Considere
dois relacionamentos definidos na visão V1 e V2 na Figura 35.
Figura 35 - Relacionamentos unificáveis por condição.
A derivabilidade da visão V1 em V2 é dependente da entidade C. Sob
certo aspecto, quando a semântica das duas visões são as mesmas, a visão
V1 dever ser "derivável” de V2. Aqui, V2 é retido como visão global. Mas a
interpretação semântica do relacionamento na visão V1 (como representado
pela regra) não deve ser equivalente ao relacionamento na visão V2. Por
64
exemplo, na Figura 36 temos que o relacionamento de Majors-In não é uma
composição dos relacionamentos Attends e Offered-By. Então, todos os
relacionamentos são retidos.
Figura 36 - Relacionamentos retidos.
É possível em alguns casos que um relacionamento de grau mais
baixo seja derivável de um relacionamento de grau mais elevado.
Figura 37 - Dependência funcional.
Considere a Figura 37, na visão V1, onde as relações de
cardinalidade ao longo dos arcos estão como segue:
(S,G):C = (1,N)
(S,C):G = (1,1)
(C,G):S = (1,M)
A relação (1,1) entre (S,C) e G acima implica em uma dependência
65
funcional: (Student, Course) -----> Grade
devido a isto, um relacionamento binário mostrado na visão v2 é
equivalente ao relacionamento ternário na visão 1.
Em general, uma visão binária é derivável de uma visão ternária
sempre que a relação (1,1) ou (0,1) exista . A relação (1,1) acima pode ser
modelada fazendo da classe um atributo do relacionamento. A relação de A
(0,1) significaria um atributo opcional. Se a classe tiver seus próprios atributos,
a mesma seria considerada como os atributos do novo relacionamento.
Considere um outro caso de visões deriváveis da Figura 38. O
relacionamento binário em R2 será derivável de R1 somente se a seguinte
constraint for especificada: R2 = projeção de R1 em Dealer, Customer. A
constraint acima pode ser expressada como uma especificação de derivação
em uma linguagem de alto nível. Quando duas visões são condicionalmente
unificáveis, a visão de um grau mais elevado deve ser mantida como a visão
integrada junto com as especificações da derivação.
Figura 38 - Visões deriváveis.
66
Relacionamentos não-unificáveis: Esta categoria inclui
relacionamentos de duas visões onde algumas ou todas as classes entidade
envolvidas podem ser comuns a ambas as visões, contudo o grau de
relacionamentos é dissimilar e a semântica não é exatamente a mesma.
Considere um exemplo simples(Figura 39): Na visão V1, há dois
relacionamentos R1 e R2. Eles descrevem independentemente o
relacionamento de um negociante que fornece uma peça e o cliente que
compra uma peça. A visão V2 descreve o relacionamento R3 que é uma
associação ternária que descreve o fato que um cliente compra uma
determinada parte de um determinado negociante.
Embora a mesma classe entidade está envolvida nas duas visões, o
conjunto de instancias de cada classe entidade envolvida na visão V1 e V2
deve ser idêntico. Este é o exemplo clássico de uma armadilha da conexão
[CODD70]. Agora o esquema integrado resultante conterá as classes entidade
Dealer, Part, Customer e todos os relacionamentos RI, R2, R3.
Figura 39 - Relacionamentos não unificáveis.
67
7 CONCLUSÃO
Este trabalho procurou levantar os principais esforços existentes na
área de tratamento de integração de bases de dados. Com o aumento da
complexidade e da utilização de tais recursos de armazenamento de
informação, o problema de integração se torna mais difícil e desafiador.
Embora de forma bastante condensada, foi demonstrado o estado da
arte relacionado a questão de integração de esquemas. Foi feito uma breve
análise das escolas de pensamento através do tempo, assim como as
principais causas da diversidade de esquemas e as etapas adequadas para um
bom andamento do processo da integração, para que se tenha um
amadurecimento a respeito do assunto e se evite cometer os mesmos erros.
Além disso, foram apresentadas de forma geral diversas
metodologias para a integração de esquemas de acordo com as etapas
delineadas para o processo, com a indicação de quadros comparativos e o
comportamento das entradas e saídas das referidas arquiteturas.
Levando-se em consideração características como a transparência
dos processos de integração e a utilização de uma modelagem amplamente
aceita no meio acadêmico e comercial, foi relatada com um pouco mais de
profundidade a metodologia utilizada por ElMasri[1987]. Essa arquitetura tem
como item imprescindível a classificação dos relacionamentos de acordo com
grau, além de regras e constraints estruturais que são importantes
características que nos levam a comparação de relacionamentos. A análise
deste estudo constata que é possível definir regras de integração em casos
onde os relacionamentos tem o mesmo grau. O problema se torna mais difícil
quando relacionamentos de diferentes graus têm que ser unificados. Embora a
metodologia tenha sido apresentada no contexto do modelo Entidade Categoria
Relacionamento(E-C-R), acredita-se que os resultados podem ser obtidos
através de outros modelos.
68
Novas tecnologias de redes de comunicação, bases de dados
distribuídas, conhecimento baseado em sistemas e aplicativos de escritório
tendem a difundir o uso compartilhado de dados em termos de usuários,
diversidade de aplicações e sofisticação de conceitos. O projeto,
desenvolvimento e engenharia de aplicações estão se tornando peças chave
nos sistemas de gerenciamento de bases de dados.
Com isso, tecnologias recentes de tratamento de visões de dados e
consultas(como XML) podem fazer a diferença no redirecionamento de
recentes pesquisas relacionadas a área, como a extensão de metodologias de
integração, unificação de processos e interfaces para a Web e o
desenvolvimento de sistemas inteligentes para a integração de esquemas.
O conhecimento e a informação se tornaram um bem precioso para a
organização. Sendo assim, é necessário gerenciá-lo bem para se ter um efetivo
controle sobre este patrimônio peculiar. Este gerenciamento só é possível
através de uma arquitetura coesa com o pleno domínio das bases de dados. O
seu valor aumenta considerando que as informações estão cada vez mais
integradas e passam a dar apoio a tomadas de decisão a fim de obter
vantagens competitivas para a organização.
Tendo em vista os aspectos apresentados, acredita-se que o
aumento da necessidade de metodologias para integração de dados em
conceitos e formas físicas será cada vez mais essencial em todos os
segmentos de tratamento da informação.
69
REFERÊNCIAS
ABITEBOUL, S. On views and xml. Le chesnay: I.N.R.I.A, Oct. 1999. 78153.
AL-FEDAGHI, S.; SCHEUERMANN, P. Mapping considerations in the design of schemas for the relational model. IEEE Trans. Softw. Eng., v. 7, n.1, Jan. 1981.
BATINI, C.; LENZERINI, M. A methodology for data schema integration in the entity-relationship model. IEEE Transactions on Software Engineering, v. 10, n.6, p. 650-664, Nov.1984.
BATINI, C.; LENZERINI, M; NAVATHE, S. B. A comparative analysis of methodologies for database schema integration. ACM Computing Surveys, v. 18, n. 4, p. 323-364, Dec. 1986.
CHEN, P. P. The entity-relationship model: toward an unified view of data. ACM Trans. Database Syst., v. 1, n. 1 p. 9-36, Mar.1976.
ELMASRI, R; LARSON, J; NAVATHE, S. B. Schema integration algorithms for federated databases and logical database design. Honeywell Corporate Research Center, 1986. Relatório Técnico.
ELMASRI, R; NAVATHE, S. B. Fundamentals of database systems. 3.ed.Benjamin/Cummings, 1994.
ELMASRI, R; NAVATHE, S. B. Object integration in database design. In: IEEE COMPDEC CONFERENCE, 1984, Anaheim. Proceedings... New York: IEEE, 1984. p. 426-433.
ELMASRI, R; WEELDRYER, J.; HEVNER, A. The category concept: an extension to the entity-relationship model. Data Knawl Eng., ano I, n.1, June 1985.
ELMASRI, R; WIEDERHOLD, G. Data model integration using the structural model. In: INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA, 1979, Boston. Proceedings... New York: ACM, 1979.
HALL, G. Negotiation in database schema integration. Montreal: Faculty of Management, McGill University. Disponível em: <http://hsb.baylor.edu/ramsower/acis/papers/hall.htm>. Acesso em: 02 fev. 2002.
NAVATHE, S. B.; ELMASRI, R.; LARSON, J. Integrating user views in database design. IEEE Computer, v. 19, n. l, p. 50-62, Jan. 1986.
NAVATHE, S. B; GADGIL, S. G. A methodology for view integration in logical data base design. In: INTERNATIONAL CONFERENCE ON VERY LARGE DATA BASES, 8., 1982, Mexico City. Proceedings... Saratoga: VLDB Endowment, 1982.
NAVATHE, S. B.; SASHIDHART, T.; ELMASRI, R. Relationship merging in schema integration. In: INTERNATIONAL CONFERENCE ON VERY LARGE DATA BASES, 10., 1984, Singapura. Proceedings... Singapura, 1984.
70
PARENT, C; SPACCAPIETRA, S. Issues and approaches of database
integration. Communications of the ACM, v. 41, n. 5, p.166-178, 1998.
SAMY GAMAL-ELDIN, M.; THOMAS, G; ELMASRI, R. Integrating relational databases with support for updates. IEEE Computer, 1988.
SPACCAPIETRA, S.; PARENT, C. Conflicts and correspondence assertions in interoperable databases. SIGMOD Record, v. 20, n.4, p. 49-54, Dec. 1991.
SPACCAPIETRA, S.; PARENT, C. View integration: a step forward in solving structural conflicts. IEEE Transactions on Knowledge and Data Engineering, v. 6, n.2, p. 258-274, Apr. 1994.
WIEDERHOLD, G.; ELMASRI, R. A structural model for database systems. Stanford: Stanford University, Computer Science Dept., 1979. Technical Report STANCS-79-722.
71
ANEXOS
ANEXO 1 VISÃO DO MODELO DE ENTIDADE - CATEGORIA -
RELACIONAMENTO.
O modelo E-R estendido que nós usamos é chamado aqui de modelo
do Entidade-Categoria-Relacionamento (E-C-R). O modelo do E-C-R inclui
extensões ao modelo do E-R em duas áreas principais:
a) O conceito de categoria é usado para representar as sub-classes
[HAMM81]. Adicionalmente, as categorias também podem ser
usadas para agrupar entidades que usam as mesmas regras em
um relacionamento.
b) Cardinalidades e dependência de constraints em relacionamentos
são especificados precisamente.
O modelo E-C-R usa as seguintes construções: conjunto de
entidades, conjuntos de relacionamentos, categorias e atributos. Os conjuntos
de entidade representam conjuntos de entidades que têm os mesmos atributos.
As categorias representam agrupamentos adicionais das entidades de um ou
mais conjuntos de entidades. O modelo E-C-R suporta relacionamentos n-ários
diretamente. Similarmente, uma categoria pode ser usada para modelar um
subconjunto de um conjunto de entidades.
Um exemplo do modelo E-C-R é mostrado na figura abaixo; o
diagrama E-C-R é uma extensão do diagrama E-R [CHEN76]. Caixas
retangulares representam conjuntos de entidades, as caixas hexagonais
representam categorias e as caixas em forma de diamante representam
conjuntos de relacionamentos. Dois tipos de categorias existem no modelo E-
C-R.
Uma categoria de subclasse é um agrupamento de entidades de um
conjunto de entidade ou categorias. Os membros de qualquer conjunto de
72
entidade podem pertencer a qualquer número de categorias de subclasses. As
categorias de subclasse poderiam ser atributos definidos ou que os usuários
definiram [HAMM81]. O conceito de categoria permite uma modelagem
generalizada. No exemplo da figura abaixo, Car e Truck são definidos para ser
subclasses do Vehicle ajustado. Um Vehicle pode ser um Car ou um Truck ou
ambos. O segundo tipo de categoria é usado para agrupar as entidades que
atuam no mesmo papel em um relacionamento. A categoria Owner inclui as
entidades Companies e Persons que tem regras próprias do relacionamento
Owner.
Então Owner é um subconjunto da união de Companies e Persons.
73
ANEXO 2 FASES DO PROJETO DE BASES DE DADOS PARA GRANDES
BASES DE DADOS.
74
ANEXO 3 EXEMPLOS DE REFINAMENTO TOP-DOWN. (A) GERANDO
UM NOVO TIPO ENTIDADE. (B) DECOMPONDO UM TIPO ENTIDADE EM
DOIS TIPOS ENTIDADE E EM UM RELACIONAMENTO.
75
ANEXO 4 EXEMPLOS DE REFINEMENTO BOTTOM-UP. (A)
DESCOBRINDO E ADICIONANDO RELACIONAMENTOS NOVOS. (B)
DESCOBRINDO UMA CATEGORIA NOVA (TIPO DA UNIÃO) E
RELACIONÁ-LA.
76
ANEXO 5 MODIFICANDO VISÕES PARA ADEQUAÇÃO ANTES DA
INTEGRAÇÃO
77
ANEXO 6 ESQUEMA INTEGRADO APÓS UNIÃO DAS VISÕES 1 E 2
78
ANEXO 7 DIFERENTES ESTRATÉGIAS PARA O PROCESSO DE
INTEGRAÇÃO DE VISÕES