DALTON LUIZ MARCLIO

ANLISE E METODOLOGIAS DE INTEGRAO DE ESQUEMAS DE

BANCO DE DADOS
Monografia apresentada para
obteno do ttulo de Especialista
em Tecnologia da Informao no
Curso de Ps-Graduao em
Informtica, Setor de Cincias
Exatas, Universidade Federal do
Paran.
Orientador: Prof. Jos Simo de
Paula Pinto
CURITIBA
MAIO 2002
ii

SUMRIO
LISTA DE ILUSTRAES............................................................................................... V
LISTA DE QUADROS .................................................................................................... VII
RESUMO........................................................................................................................ VIII
ABSTRACT...................................................................................................................... IX
1 INTRODUO............................................................................................................1
2 ASPECTOS GERAIS..................................................................................................4
3 VISO GERAL DE INTEGRAO DE DADOS........................................................8
3.1 Integrao de vises......................................................................................................10
3.2 Integrao de bases de dados ....................................................................................12
4 METODOLOGIAS PARA A INTEGRAO DE ESQUEMAS ................................14
4.1 Causas da diversidade de esquemas........................................................................18
4.1.1 Diferentes perspectivas ............................................................................................18
4.1.2 A equivalncia entre construes do modelo .......................................................19
4.1.3 Projeto de especificao incompatvel ...................................................................20
4.1.4 Conceitos comuns.....................................................................................................21
4.1.5 Conceito relacionado por propriedades semnticas............................................22
4.2 Etapas e objetivos do processo da integrao......................................................23
4.2.1 Pr integrao............................................................................................................23
4.2.2 Comparao dos esquemas....................................................................................24
iii

4.2.3 Adequao de esquemas.........................................................................................24
4.2.4 Unio e reestruturao .............................................................................................24
5 COMPARAO DE METODOLOGIAS...................................................................26
5.1 Aplicabilidade das metodologias de integrao....................................................26
5.2 Caractersticas das entradas e sadas......................................................................28
5.3 Arquiteturas das metodologias ..................................................................................31
5.4 Pr integrao..................................................................................................................33
5.5 Comparao dos esquemas ........................................................................................36
5.5.1 Nomeando conflitos...................................................................................................36
5.5.2 Conflitos estruturais...................................................................................................39
5.6 Adequao de esquemas .............................................................................................40
5.7 Unio e reestruturao..................................................................................................41
5.7.1 Integridade..................................................................................................................43
5.7.2 Minimizao................................................................................................................43
5.7.3 Compreenso.............................................................................................................44
6 METODOLOGIA DE UNIO DE ESQUEMAS DE ELMASRI .................................45
6.1 Viso Geral da Metodologia.........................................................................................45
6.2 Abordagem da integrao de vises.........................................................................46
6.2.1 Fase de pr-integrao.............................................................................................47
6.2.2 Reviso de integrao de objetos...........................................................................48
6.3 Integrao de relacionamentos ..................................................................................51
6.3.1 Critrios para a comparao de relacionamentos................................................52
iv

6.3.2 Classificao dos relacionamentos ........................................................................53
6.3.3 Unindo relacionamentos com o mesmo grau........................................................54
6.3.4 Unindo relacionamentos de diferentes graus........................................................60
7 CONCLUSO...........................................................................................................67
REFERNCIAS................................................................................................................69
ANEXOS ..........................................................................................................................71
v
LISTA DE ILUSTRAES
FIGURA 1 - O PROCESSO GLOBAL DE INTEGRAO................................................................... 8
FIGURA 2 - FASES DO PROJETO DE BASE DE DADOS. ............................................................. 12
FIGURA 3 - ENTRADAS E SADAS NA INTEGRAO 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 - SOBREPOSIO DOS ESQUEMAS. ............................................................................ 17
FIGURA 9 - CRIAO DE UM SUBCONJUNTO RELACIONAMENTO. ....................................... 17
FIGURA 10 - DELETAR AS PROPRIEDADES DE BOOK COMUNS A PUBLICATION. ............ 18
FIGURA 11 - DIFERENTES PERSPECTIVAS.................................................................................... 19
FIGURA 12 - CONSTRUES EQUIVALENTES. (A) HIERARQUIA DE GENERALIZAO
(B) UMA ENTIDADE SIMPLES...................................................................................................... 20
FIGURA 13 - ESPECIFICAO DE PROJETO INCOMPATVEL................................................... 21
FIGURA 14 - PROPRIEDADES DE INTERESQUEMA. .................................................................... 23
FIGURA 15 - TIPOS DE ESTRATGIAS DE PROCESSAMENTO DE INTEGRAO. ............. 34
FIGURA 16 - EXEMPLO DE HOMNIMO........................................................................................... 38
FIGURA 17 - EXEMPLO DE SINNIMO. ............................................................................................ 38
FIGURA 18 - TRANSFORMAO DE UM ATRIBUTO EM UMA ENTIDADE. ............................. 41
FIGURA 19 - UM ESQUEMA COM REDUNDNCIA. ....................................................................... 43
FIGURA 20 - APRIMORANDO O ENTENDIMENTO. ........................................................................ 44
FIGURA 21 - DOMNIOS IDNTICOS.................................................................................................. 49
FIGURA 22 SUBCONJUNTOS........................................................................................................... 50
FIGURA 23 - HIERARQUIA DE GENERALIZAO. ......................................................................... 50
FIGURA 24 - ABORDAGEM SEMNTICA DOS RELACIONAMENTOS. ...................................... 55
FIGURA 25 - RELACIONAMENTOS COM O MESMO GRAU......................................................... 55
vi

FIGURA 26 - UNIO DE MESMO GRAU ............................................................................................ 55
FIGURA 27 - RELACIONAMENTOS COM CONSTRAINTS DIFERENTES.................................. 57
FIGURA 28 - UNIO COM CONSTRAINTS DIFERENTES. ............................................................ 57
FIGURA 29 DETENO...................................................................................................................... 58
FIGURA 30 - RELACIONAMENTOS DISJUNTOS............................................................................. 59
FIGURA 31 - RELACIONAMENTOS CRUZADOS............................................................................. 59
FIGURA 32 - UNIO DE RELACIONAMENTOS CRUZADOS. ....................................................... 60
FIGURA 33 - CLASSIFICAO DE RELACIONAMENTOS DE DIFERENTES GRAUS. ........... 62
FIGURA 34 - RELACIONAMENTOS UNIFICVEIS. ......................................................................... 62
FIGURA 35 - RELACIONAMENTOS UNIFICVEIS POR CONDIO.......................................... 63
FIGURA 36 - RELACIONAMENTOS RETIDOS. ................................................................................ 64
FIGURA 37 - DEPENDNCIA FUNCIONAL. ...................................................................................... 64
FIGURA 38 - VISES DERIVVEIS..................................................................................................... 65
FIGURA 39 - RELACIONAMENTOS NO UNIFICVEIS. ............................................................... 66
vii

LISTA DE QUADROS
QUADRO 1 - FASES DA INTEGRAO DE ACORDO COM METODOLOGIAS............................27
QUADRO 2 - ENTRADAS E SADAS................................................................................................31
QUADRO 3 - ATIVIDADES DA INTEGRAO DE ESQUEMAS .....................................................32
QUADRO 4 - ESTRATGIAS DE PROCESSAMENTO DE INTEGRAO.....................................36
QUADRO 5 - CONFLITOS ESTRUTURAIS E DE NOME.................................................................39
QUADRO 6 - PROPRIEDADES DE INTERESQUEMA.....................................................................42
viii

RESUMO
O conhecimento e a informao se tornaram um bem precioso para a
organizao. Sendo assim, necessrio gerenci-lo bem para se ter um efetivo
controle sobre este patrimnio peculiar. O seu valor aumenta considerando que
as informaes esto cada vez mais integradas e passam a dar apoio a
tomadas de deciso a fim de obter vantagens competitivas. Relacionado a isso,
novas aplicaes usaro dados existentes de vrios bancos dos dados, de
preferncia novos dados que incorporam as empresas. Por conseqncia, vm
tona a necessidade do conhecimento de integrao de esquemas de base de
dados, a fim de fornecer compatibilidade e acesso transparente aos recursos
da informao sem envolver investimentos completos no replanejamento do
sistema.
Neste trabalho analisada e oferecida uma abordagem no processo de
integrao de esquemas de base de dados, fornecendo para isso uma
estrutura geral do problema da integrao de esquemas, as definies
envolvidas no processo, as metodologias existentes e o detalhamento de uma
arquitetura especfica para a integrao.
Palavras-chave: Banco de Dados; Integrao de Esquemas; Metodologias de
Integrao.
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 INTRODUO
A Tecnologia da Informao, seja atravs de uma simples
automatizao de um processo at a elaborao de uma soluo mais
complexa, tem nos possibilitado uma maior flexibilidade e rapidez no acesso s
informaes.
A evoluo destas ferramentas tem proporcionado maiores
facilidades de utilizao pelo usurio comum. Com isto, a informatizao vem
atingindo praticamente todas as reas do conhecimento humano.
Como conseqncia destes fatores, o nmero de usurios e a
quantidade de informaes que se tem produzido e disponibilizado vem
crescendo exponencialmente. Devido ao grande volume, para se chegar s
informaes desejadas necessrio um filtro eficiente atravs do contexto e da
semntica desta informao.
Como cada rea de conhecimento tem o seu vocabulrio
caracterstico, quando necessitamos integr-la a uma outra rea podem ocorrer
divergncias de entendimento devido a ambigidade de algumas palavras.
Esta ambigidade aumenta se considerarmos que o ambiente tecnolgico tem
uma linguagem prpria e especfica e necessita interagir com estas reas de
conhecimento.
Uma das reas da Tecnologia da Informao de suma importncia e
que possui caractersticas peculiares acima descritas a de bases de dados,
que est se tornando cada vez mais essencial nas organizaes. A
disponibilidade de dados e os acessos informao com resultados
satisfatrios tem se tornado um fator crtico para ganho de vantagem
competitiva.
Enquanto as estruturas das companhias evoluem, os limites entre os
departamentos mudam, criando novas unidades de negcio, acarretando uma
maior utilizao dos computadores e do nmero de aplicaes especficas.
2
Essas novas aplicaes usaro dados existentes de vrios bancos dos dados,
de preferncia novos dados que incorporam a organizao.
Entretanto, um nmero de questes emergentes complicam a
habilidade das organizaes de fornecer o acesso detalhado e de confiana
aos diferentes recursos da informao. Exemplos de tais questes que
surgiram nas dcadas passadas incluem a proliferao e investimento em base
de dados autnomas dentro da organizao, heterogeneidade entre modelos
de dados e sistemas gerenciadores de base de dados empregados e o
aumento da importncia das regras e da complexidade de sistemas
distribudos. Todos estes fatores contribuem para o aumento da importncia de
desenvolver opes praticveis para fornecer interoperabilidade entre base de
dados existentes, e conseqentemente, buscar a pesquisa na rea de
integrao de esquemas de base de dados.
De fato, estas caractersticas focalizam o conhecimento do problema
envolvido na integrao de esquemas em base de dados existentes a fim de
fornecer compatibilidade e acesso transparente aos recursos da informao
sem envolver investimentos completos no replanejamento do sistema.
As contribuies para o estado da arte de metodologias de projeto da
base de dados, e em particular o processo de integrao de esquemas foram
particularmente significativos nos ltimos vinte anos. Este projeto de pesquisa
se prope a analisar e oferecer uma abordagem no processo de integrao de
esquemas de base de dados, fornecendo primeiramente uma estrutura geral de
como o problema de integrao de esquemas pode ser melhor compreendido.
Tambm so levantadas questes problemticas envolvidas no processo, a
descrio de levantamento de dados, modelagens e tcnicas existentes e
descrio geral comparativa sobre metodologias relacionadas a rea. Dentro
de uma esfera de utilizao de modelagem amplamente aceita e de uma
descrio ntida de procedimentos, apresentado o detalhamento de uma
metodologia de integrao especfica proposta por ElMasri[1987] e descrio
3
de linhas de pesquisa para trabalhos futuros.
Assim, no captulo 2 apresentado um histrico do processo de
Integrao bem como as escolas de pensamento concernentes; no captulo
seguinte descrita uma viso geral e definies sobre integrao de dados; o
captulo 4 reservado para delinear as etapas, objetivos e caractersticas
gerais do processo de integrao; no captulo subseqente demonstrada a
comparao de diversas metodologias existentes; o captulo 6 aborda a
metodologia de unio de esquemas de ElMasri[1987].
4
2 ASPECTOS GERAIS
As metodologias de projeto de base de dados emergiram em 1970.
Uma das motivaes fundamentais para usar a abordagem de base de dados
sobre a tradicional abordagem processamento de dados usando arquivos foi
a afirmao que os sistemas gerenciadores de base de dados poderiam tornar
possvel definir um esquema integrado de dados relevante para todas as
aplicaes, eliminando desse modo duplicaes, problemas de mltiplos
updates e minimizar inconsistncias atravs da aplicao. Estas importantes
vantagens motivaram a pesquisa na rea de integrao de esquemas sobre as
duas dcadas passadas. O objetivo geral da integrao do esquema integrar
uma organizao com diferentes propsitos ou sistemas de base de dados e
percepes do usurio que facilitam desse modo o acesso global a um recurso
organizacional integrado da informao.
O projeto de base de dados convencional dependente da
experincia e intuio do desenvolvedor. O desenvolvimento de tcnicas para
suportar o projeto de base de dados no avanou comparavelmente com as
aplicaes de bases de dados. Passados alguns anos algumas tentativas
foram feitas para tratar o projeto de base de dados como uma forma cientfica e
estrutural. Houveram essencialmente duas escolas de pensamento:
a) Na primeira, o projeto de base de dados comea com itens de
dados individuais. Todos os tipos funcionais e outros tipos de
dependncias entre itens de dados individuais devem ser
especificados antes de construir o esquema. Porm como
discutido por Bubenko [BUBE79], as suposies desta abordagem
no so sempre realsticas. Alm disso, a abordagem trabalha
geralmente com a idia que o conjunto mnimo de relaes
melhor no projeto de base de dados. As consideraes semnticas
so ignoradas quase que completamente. Com isso, o esquema
5
resultante dependente da ordem nos quais as dependncia de
dados so fornecidas para algoritmos de sntese.
b) A segunda escola do pensamento advoga a operao no nvel de
entidades, relacionamentos e atributos. Nesta abordagem o
processo de projeto de base de dados dividido nas seguintes
fases:
I) Modelagem de vises.
II) Integrao de vises.
III) Anlise e mapeamento do esquema.
IV) Projeto e otimizao fsicas do esquema.
O termo viso est sendo usado no contexto de representao da
viso de dados de um grupo de usurios ou de um desenvolvedor da empresa.
Os termos como viso do usurio ou viso da empresa torna claro a
respeito de quem elabora a viso. Dois aspectos so relacionados com este
termo:
- Estrutura dos dados.
- Processamento dos dados.
Neste trabalho, a viso ser usada para referenciar somente a
estrutura dos dados. As transaes em vises so consideradas durante as
fases de anlise e de otimizao.
Durante a modelagem de vises, as vises dos usurios so
expressadas em um nvel elevado tal como no modelo semntico Entidade
Relacionamento(E-R) ou variante. Todas as vises do usurio so integrados
durante a fase de integrao de vises 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] esto
nesta categoria. A integrao de vises como um processo foi analisada mais
profundamente por [NAVA82, BATI83]. A integrao total vista como um
processo incremental da definio da integrao e de resolues de conflitos.
6
Esta escola da opinio que a resoluo de conflitos de integrao
de vises pode ser efetuada por ferramentas de projeto interativas. A
integrao o resultado de um dilogo constante com o usurio sobre a
definio de conflitos.
Trs caractersticas distinguem esta escola da precedente:
a) Nesta abordagem a semntica dos objetos e dos relacionamentos
entre objetos dirige a integrao. A metodologia tenta alcanar
uma representao global dos dados que o "melhor
compromisso para o conjunto dado das vises locais que
consideram todos os conflitos. A semntica referencia todas as
dependncias funcionais que esto tipicamente includas na outra
escola. As abordagens dirigidas puramente por dependncias no
podem ter nenhuma noo de compromisso.
b) A metodologia confia fielmente na interveno do desenvolvedor.
A primeira escola do pensamento espera a atividade de projeto ser
automatizada inteiramente visto que a ltima supe que a
abordagem semi automatizada deve ajudar ao desenvolvedor
identificando os conflitos e propondo alternativas unio de
esquemas. Uma unio automtica de vises no considerada
apenas irreal mas tambm sem sentido na ausncia de informao
semntica que integra mltiplas vises de dados.
c) A otimizao de projeto sob a segunda escola de pensamento est
tipicamente baseada em uma avaliao de projeto alternativa no
contexto de processos de carga. As abordagens baseadas em
pura dependncia de informao [CASA83 ] geralmente supe que
a redundncia mnima o objetivo preliminar do projeto. Alguns
modelos funcionais so advogados como Yao et al. [YAO82], que
usam a noo de transao em seu mtodo.
Este trabalho trata da fase de integrao de vises de um projeto de
7
base de dados sob a segunda escola de pensamento. [BAT182, BAT84] props
extenses do modelo E-R para facilitar as integraes das vises. Eles
consideraram os problemas de nome(homnimos e sinnimos) em detalhes e
abordaram a integrao das vises como uma modificao incremental do
ncleo de uma viso global para acomodar todos as outras vises
considerando uma por uma. Elmasri e Wlederhold [ELM79] especificam tipos
diferentes de relacionamentos binrios entre classes de objetos e consideram
como eles podem serem feitos para coexistir. Eles no consideram
relacionamentos de grau mais elevado. O mtodo 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 integrao de relacionamentos. Uma viso do
modelo E-C-R encontra-se em anexo neste trabalho.
8
3 VISO GERAL DE INTEGRAO DE DADOS
A integrao da base de dados o processo que leva como entrada
um conjunto de bases de dados e produz como a sada uma nica descrio
unificada dos esquemas de entrada (o esquema integrado) e o mapeamento de
informaes associadas que suportam acesso integrado aos dados existentes
atravs do esquema integrado. A integrao da base de dados usada
tambm no processo do reengenharia de sistemas legados.
A finalidade e a contribuio deste trabalho so fornecer um retrato
de quais so as abordagens e as solues a serem atingidas. Apresentamos
ento as etapas envolvidas em desenvolver um esquema integrado (veja
Figura 1 ):

Figura 1 - O processo global de integrao.
9
a) Pr integrao: onde os esquemas de entrada so transformados
para se tornarem mais homogneos (sintaticamente e
semanticamente)
b) Identificao de correspondncia: dirigida a identificao e
descrio de relacionamentos de interesquemas;
c) Integrao: a etapa final que resolve conflitos de interesquemas e
unifica itens correspondentes em um esquema integrado.
Um dos princpios fundamentais da abordagem de base de dados
que uma base de dados permite uma representao no redundante e
unificada de todos os dados controlados em uma organizao. Isto
conseguido somente quando as metodologias esto disponveis para suportar
a integrao atravs dos limites organizacionais e da aplicao.
As metodologias para o projeto de base de dados executam
geralmente a atividade de projeto separada produzindo diversos esquemas
representando as partes da aplicao, que so unificadas subseqentemente.
O objetivo geral da integrao de esquemas integrar uma
organizao com diferente propsitos ou sistemas de base de dados e
percepes do usurio que facilitam desse modo o acesso global a um recurso
organizacional integrado da informao. De qualquer forma, a pesquisa da
integrao de esquemas foi especializada em duas reas:
a) integrao de vises: se dirige s bases de dados propostas, e
b) integrao de base de dados: se dirige s bases de dados
existentes.
A integrao de vises usada como uma ferramenta de auxlio no
projeto da base de dados e produz uma descrio global e conceitual de uma
base de dados proposta unindo diferentes requisies de dados ou vises do
usurio. De outra forma, a integrao da base de dados usada para produzir
um esquema global que representa uma coleo de bases de dados
10
relacionadas em toda a organizao. Este esquema global uma viso virtual
de todas as bases de dados juntas em um ambiente de base de dados
distribudo.
Quando a integrao da base de dados e das vises diferirem
contextualmente, elas podem ser descritas como atividades de integrao de
esquemas de bases de dados propostas ou existentes em um esquema global
e unificado que satisfaa as constraints impostas por todos os esquemas
componentes.
3.1 INTEGRAO DE VISES
O problema do projeto de base de dados aponta para o
desenvolvimento de um esquema de base de dados que inclui especificaes
lgicas tais como agrupamentos de atributos e relacionamentos entre esses
agrupamentos (esquema lgico), bem como as especificaes fsicas tais
como tipo de acesso a registros, ndices e ordenao(esquema fsico). No caso
de distino, as atividades de projeto correspondentes da base de dados so
denominadas projeto lgico e fsico do esquema.
O projeto lgico do esquema envolve o problema de projetar o
esquema conceitual e de mapear o esquema em uma linguagem de definio
do esquema (ou linguagem de definio de dados) de um SGBD especfico. A
Figura 2 mostra as fases do projeto de base de dados e das representaes
intermedirias do esquema. As fases do projeto de base de dados so :
a) Especificao e anlise de requisitos. Uma anlise da informao
de requisitos de vrias reas dentro de uma organizao tendo
como resultado uma especificao preliminar das necessidades de
informao de vrios grupos de usurios.
b) Projeto Conceitual. Modelagem e representao de usurios e
vises das aplicaes da informao e possivelmente uma
11
especificao do processamento do uso da informao. O
resultado final desta atividade um esquema conceitual que
represente uma descrio global de alto nvel dos requisitos.
c) Execuo do Projeto. Transformao de um esquema conceitual
no esquema lgico de um SGBD. A segunda e a terceira fases
feitas em conjunto so chamadas projeto de base de dados lgico.
d) Projeto fsico e otimizao do esquema. Mapeamento do esquema
lgico de uma base de dados em uma representao apropriada
armazenada em um SGBD, incluindo novos parmetros fsicos
para otimizar o desempenho da base de dados contra um conjunto
de transaes.
Tipicamente, a atividade de projeto da aplicao prossegue
paralelamente com projeto de base de dados. A Figura 2 mostra tambm as
especificaes relacionadas s aplicaes relatadas como as sadas das
ltimas duas fases.
12

Figura 2 - Fases do Projeto de Base de Dados.
3.2 INTEGRAO DE BASES DE DADOS
A integrao de base de dados um problema relativamente recente
que aparece no contexto de bases de dados distribudas. Uma base de dados
distribuda uma coleo de dados que logicamente pertencem ao mesmo
sistema mas esto espalhados sobre uma rede de computadores.
Bases de dados distribudas e o sistema de gerncia da base de
13
dados distribudo podem ser classificados em duas categorias principais:
homognea, tratando das bases de dados locais que tm os mesmos modelos
de dados e Sistemas Gerenciadores de Banco de Dados(SGBDs) idnticos; e
heterognea, 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 integrao da base de dados descrita em uma
maneira geral na Figura 3. Ela mostra que esta atividade tem como entrada
esquemas e consultas as transaes locais.
Figura 3 - Entradas e sadas na integrao de bases de dados.
14
4 METODOLOGIAS PARA A INTEGRAO DE ESQUEMAS
A fim de introduzir as principais caractersticas e os problemas da
integrao de esquemas, apresentado um exemplo. A Figura 4 mostra duas
descries que se refere as exigncias e os possveis esquemas conceituais
correspondentes. A seguinte informao adicional aplica-se a este exemplo:
a) A idia 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 continuaes, jornais, monografias, etc..
Segue texto explicativo aos esquemas da Figura 4 :
No primeiro esquema(4a): Os dados de interesse so sobre livros.
Livros tm ttulos. Eles so publicados por editores com nomes e endereos.
Livros so adotados pelas Universidades tendo um nome e pertencendo a um
estado. Livros se referem a certos tpicos.
No segundo esquema(4b): Os dados de interesse incluem
publicaes de diferentes tipos. Cada publicao tem um ttulo, um editor e
uma lista de palavras chave. Cada palavra chave consistem em um nome, um
cdigo 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, conclumos 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 mudana
correspondente no segundo esquema (Figura 5 para Figura 6). Quando ns
observamos os novos esquemas (Figura 6), uma outra diferena observada
que publisher est presente nos dois esquemas com tipos diferentes: uma
entidade no primeiro esquema e em um atributo no segundo. A razo para
15
escolher tipos diferentes (atributo contra entidade) vem da diferente relevncia
que publisher tem nos dois esquemas.
Entretanto, observa-se que necessrio adequar as duas
representaes para a unio ser realizada. Conseqentemente ns
transformamos o atributo Publisher em uma entidade no segundo esquema e
adicionamo-lhe um novo atributo, Name (veja a Figura 7).
Ns agora podemos sobrepor os dois esquemas, produzindo a
representao na Figura 8. A unio ainda no 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 representao, podemos reestruturar o
esquema excluindo as propriedades (relacionamentos e atributos) de Book que
so comuns Publication. Isto permitido desde que o relacionamento do
subconjunto implique que todas as propriedades de Publication so
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 - Sobreposio dos esquemas.
Figura 9 - Criao 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 bsico se
comparado aos principais problemas envolvendo integrao de esquemas. O
problema bsico a ser tratado durante a integrao vm das diversidades
estruturais e semnticas dos esquemas a serem unidos.
A investigao da integrao comea com uma classificao das
vrias causas para a diversidade do esquema, que so: diferentes
perspectivas, equivalncia entre construes do modelo e especificaes
incompatveis do projeto.
4.1.1 Diferentes perspectivas
No processo de projeto, os diferentes grupos de usurio ou
desenvolvedores adotam seus prprios pontos de vista em modelar os mesmos
objetos no domnio da aplicao. Por exemplo, no exemplo na seo 4, nomes
diferentes estavam ligados ao mesmo conceito nas duas vises.
Um outro exemplo dado na Figura 11, em que os dois esquemas
19
representam informaes sobre empregados e seus departamentos. Na Figura
11a, a informao 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. Supe-se que um
Employee(empregado) "pertence" aquele departamento que est envolvidos
nos projetos onde o empregado trabalha. Ento o relacionamento entre
empregado e departamento entendido como uma relao direta em um
esquema.
Figura 11 - Diferentes perspectivas
4.1.2 A equivalncia entre construes do modelo
Tipicamente em modelos conceituais, diversas combinaes das
construes podem modelar o mesmo domnio da aplicao
equivalententemente. Como conseqncia, modelos "mais ricos" causam uma
variedade maior de possibilidades para modelar a mesma situao. Por
exemplo, na Figura 4, a associao 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 construes equivalentes.
20
Man e Woman so distinguidos em uma hierarquia de generalizao no
primeiro esquema visto que no segundo esquema eles so distinguidos por
diferentes valores do atributo sexo.
Figura 12 - Construes equivalentes. (a) Hierarquia de Generalizao (b) Uma
entidade simples.
4.1.3 Projeto de especificao incompatvel
Escolhas errneas a respeito do nome, tipo, constraints de
integridade, etc. podem resultar em entradas errneas no processo de
integrao de esquemas. Uma boa metodologia de integrao de esquemas
deve conduzir deteco de tais erros. O Esquema a na Figura 13 mostra
erroneamente que um empregado est atribudo sempre a um nico projeto,
onde a constraint de cardinalidade 1:N foi especificada. A situao correta (que
um empregado pode ser atribudo a muitos projetos) aparece no esquema b.
Os aspectos acima representam as razes do porque a modelagem
pode ocorrer de diferentes maneiras em esquemas diferentes. A fim executar a
integrao, crucial escolher no somente um conjunto de conceitos comuns
mas tambm conjuntos de diferentes conceitos em esquemas diferentes que
esto mutuamente relacionados por algumas propriedades semnticas. Isto
referenciado como propriedades de interesquema, que so relacionamentos
21
semnticos que contm um conjunto dos objetos em um esquema e um
conjunto diferente de objetos em um outro esquema.
Figura 13 - Especificao de projeto incompatvel.
4.1.4 Conceitos comuns
De acordo com as causas de diversidade de esquemas descritas
acima, pode acontecer que o mesmo conceito do domnio da aplicao possa
ser representado por diferentes representaes R1 e R2 em esquemas
diferentes, e diversos tipos de relacionamentos semnticos podem existir entre
tais representaes. Esses relacionamentos podem ser idnticos, equivalentes,
compatveis ou incompatveis:
a) Idnticos: R1 e R2 so exatamente os mesmos. Isto acontece
quando o mesmo modelo de construo utilizado, as mesmas
percepes so aplicadas e nenhuma incoerncia existe na
especificao.
b) Equivalentes: R1 e R2 no so exatamente os mesmos porque
utilizam modelagens equivalentes, porm diferentes. As
percepes so ainda as mesmas e coerentes.
Embora diversos modelos semnticos de dados ainda esto em
existncia hoje, os autores destes modelos no fornecem nenhum critrio para
a equivalncia dos conceitos. As definies so baseadas tipicamente em trs
22
tipos diferentes de equivalncia:
a) Comportamental: R1 equivalente a R2 se para cada
instanciao de R1, a correspondente instanciao R2 existe com
o mesmo conjunto de respostas a uma dada consulta e vice versa.
b) De mapeamento: R1 e R2 so equivalentes se suas instncias
podem ser descritas em uma correspondncia 1:1.
c) Transformacional: R1 equivalente a R2 se R2 pode ser obtido de
R1 aplicando um conjunto de transformaes atmicas que, por
definio, preservam equivalncias.
1) Compatvel: R1 e RS no so nem idnticos nem equivalentes.
Entretanto, as construes, a percepo do desenvolvedor, e
constraints de integridade no so contraditrios.
2) Incompatvel: R1 e R2 so contraditrios por causa da incoerncia
da especificao.
As situaes (2), (3), e (4) acima podem ser interpretadas como
conflitos. Os conflitos e suas resolues so peas chave nos problemas de
integrao.
4.1.5 Conceito relacionado por propriedades semnticas
A respeito dos conceitos em componentes de esquemas que no so
os mesmos mas esto relacionados, precisamos descobrir todas as
propriedades relacionadas ao interesquema. Na Figura 14, ns mostramos dois
exemplos de propriedades de interesquema.
23

Figura 14 - Propriedades de interesquema.
4.2 ETAPAS E OBJETIVOS DO PROCESSO DA INTEGRAO
Daqui em diante, trataremos a questo da natureza do problema da
integrao de esquemas e da identificao das causas e as implicaes da
diversidade do esquema. Como as metodologias realizam a tarefa da
integrao? Cada metodologia segue seu prprio procedimento da soluo.
Entretanto, toda metodologia eventualmente pode ser considerada uma mistura
das seguintes atividades:
4.2.1 Pr integrao
Uma anlise dos esquemas realizada antes da integrao para se
decidir alguma poltica de integrao. Isto engloba a escolha dos esquemas a
24
serem integrados, a ordem da integrao e uma possvel atribuio das
preferncias para esquemas inteiros ou das suas parcelas. A preferncia a
aplicaes financeiras do que aplicaes de produo um exemplo de como
uma poltica de integrao pode ser gerenciada.
As estratgias globais para integrao, quantidade de interao dos
desenvolvedores e o nmero de esquemas para serem integrados em um dado
tempo tambm so decididas nesta fase. A coleta de informao adicional
relevante integrao, tal como declaraes ou constraints entre vises,
considerada tambm uma parte desta fase.
4.2.2 Comparao dos esquemas
Os esquemas so analisados e comparados para determinar as
correspondncias entre conceitos e para detectar possveis conflitos. As
propriedades de interesquemas podem ser descobertas ao comparar
esquemas.
4.2.3 Adequao de esquemas
Uma vez que os conflitos forem detectados, um esforo feito para
resolv-los de modo que a unio de vrios esquemas seja possvel. A
resoluo automtica do conflito no geralmente praticvel; a interao
prxima com desenvolvedores e usurios requerida antes que os acordos
possam ser alcanados em qualquer atividade de integrao da vida real.
4.2.4 Unio e reestruturao
Agora os esquemas esto prontos serem sobrepostos, causando
alguns esquemas intermedirios integrados. Os resultados intermedirios so
analisados e, se necessrio, reestruturados a fim de se conseguir qualidades
25
desejveis. Um esquema conceitual global pode ser testado de encontro aos
seguintes critrios qualitativos:
a) Integridade e exatido.
O esquema integrado deve conter corretamente todos os conceitos
presentes em qualquer componente do esquema. O esquema integrado deve
ser uma representao da unio dos domnios da aplicao associados com os
esquemas. O esquema conceitual global deve ser testado de acordo com os
seguintes quesitos:
b) Minimizao.
Se o mesmo conceito for representado em mais de um componente
do esquema, este deve ser representado somente uma vez no esquema
integrado.
c) Compreenso.
O esquema integrado deve ser de fcil compreenso para o
desenvolvedor e o usurio final. Isto implica que entre diversas representaes
possveis dos resultados da integrao permitidos por um modelo dos dados, o
mais compreensvel deve ser escolhido.
26
5 COMPARAO DE METODOLOGIAS
Neste trabalho 12 Metodologias completas so consideradas. A
maioria das metodologias de integrao analisadas aqui esto na categoria de
metodologias de integrao de vises. 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 integrao de vises e da
integrao de base de dados.
5.1 APLICABILIDADE DAS METODOLOGIAS DE INTEGRAO
H uma pequena questo em decidir quando os esquemas so
integrados no caso da integrao de base de dados. De qualquer forma, essa
integrao tem que ser executada em esquemas existentes nas bases de
dados locais quando o que se deseja alcanar uma relao global. Em
contrapartida, a integrao de vises pode ocorrer em diferentes momentos
(veja Figura 2).
Ento, vale a pena considerar a correspondncia entre as fases do
projeto de base de dados e as metodologias de integrao de vises. O
Quadro 1 mostra as fases em que as vrias metodologias de integrao de
vises podem ser melhor aplicveis.
27
Fases do projeto de base de dados Referncias
Entre anlise 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 Implementao Al-Fedaghi e Scheuermann[1981],
Casanova e Vidal[1983], Yao et al[1982]

Quadro 1 - Fases da integrao de acordo com metodologias.
Executar a integrao durante a fase de anlise de requisitos difcil
porque as exigncias do usurio so geralmente muito deficientes em termos
estruturais, e difcil negociar em termos de uma metodologia formal
envolvendo anlise semntica. Entre as metodologias, somente Kahn [1979]
pode ser considerado aplicvel fase de anlise de requisitos. Alm disso,
executar a integrao durante a fase de implementao do projeto difcil
porque as representaes nesse ponto no permitem que se faa uso eficaz
das abstraes.
Metodologias tais como Al-Fedaghi-Fedaghi e Scheuermann [1981] e
Yao et al. [1982] so capazes de realizar a integrao como uma parte da fase
de projeto lgico trabalhando com um modelo de dados relacional (ou
funcional) e vrios tipos de dependncias. Os algoritmos relacionais puros para
sntese (por exemplo, Bernstein [1976] e Biskup et al. [1979]) tambm podem
ser considerados exemplos desta abordagem. Portanto, no tratam de
abstraes ou construes semnticas mais poderosas.
As observaes acima sugerem que a fase preferida para integrao
est na fase do projeto conceitual, onde o uso de abstrao ser muito til para
comparar e adequar diferentes percepes dos domnios da aplicao por
diferentes grupos de usurios. Outro ponto de vista a respeito da fase de
28
quando a integrao do esquema deve ser feita. Isto pode ser analisado pelas
indicaes abaixo:
a) Executar a integrao assim que possvel porque o custo de
carregar dados errneos e/ou inconsistentes aumenta durante o
ciclo de vida da base de dados e da aplicao.
b) Executar a integrao somente aps a correo, integridade,
minimizao e reduo de ambigidade.
Isto conduz que a integrao do esquema deve ser feita aps a
anlise de requisitos mas antes do projeto de implementao. Metodologias
[Batini e Lenzerini 1984; ElMasri et al. 1987; Navathe e Gadgil 1982; Teorey e
Fry 1982; Wiederhold e ElMasri 1979] confirmam esta posio. Estas
metodologias foram inseridas sob o conceito de "projeto conceitual" no Quadro
1 de acordo com a terminologia atual. A integrao 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 integrao da base de
dados advogando a traduo de esquemas lgicos heterogneos em
representaes de dados conceituais. Assim, todas as metodologias para a
integrao da base de dados [Dayal e Hwang 1984; ElMasri et al. 1987;
Mannino e Effelsberg 198; Motro e Buneman 19811 so includas nessa
categoria.
5.2 CARACTERSTICAS DAS ENTRADAS E SADAS
A entrada bsica integrao do esquema so um nmero de
esquemas componentes e a sada bsica um esquema integrado. O Quadro
2 mostra as entradas e as sadas especficas feitas por diferentes
metodologias. Navathe e Gadgil [1982] representaram o processo da
integrao de vises com uma lista detalhada das entradas e sadas, que
29
significam aproximadamente uma unio de todas as metodologias. Abaixo est
descrito a terminologia associada a representao acima descrita:
a) Viso da empresa. Pertinente somente integrao de vises, e
no a integrao da base de dados, esta viso um esquema
conceitual inicial no qual a viso da empresa a mais importante
no domnio da aplicao. Ter tal viso torna as atividades de
comparao e adequao mais fceis.
b) Declaraes. Estes correspondem aos constraints. As
declaraes de intraviso so constraints definidas em conceitos
dentro de um esquema, visto que as declaraes da interviso so
constraints entre os conceitos pertencentes a diferentes vises.
Metodologias que assumem declaraes de interviso para serem
entradas implicitamente requerem que algum conhecimento global
que pertence a diversas aplicaes esteja fornecida ao
desenvolvedor. As declaraes modificadas na sada sero
constraints revisadas.
c) Processamento de requisitos. Refere-se s operaes definidas
em componentes de vises. Podem ser especificados na forma de
uma linguagem de manipulao de dados de alto nvel.
d) Mapeamento de regras. Estes definem o mapeamento das
consultas (operaes) aplicveis aos componentes do esquema
para consultas (operaes) no esquema integrado.
e) Indicao dos conflitos. Este um conjunto de conflitos que o
desenvolvedor no pode resolver e que fica alm do escopo da
metodologia.
30
Referncia Entrada Sada
Al-Fedaghi and
Scheuermann[1981]
N vises externas N esquemas externos
Esquema conceitual
Mapeamento entre
esquemas externos e
esquemas conceituais
Batini e Lenzerini[1984] Esquemas do usurio
Esquemas da empresa
Esquema global
Casanova and Vidal[1983]

Vises do usurio 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
Declaraes de
interesquemas
Esquema Global
Mapeamento de regras
Kahn[1979] Estruturas de informao
locais
Estrutura de informao
global
Motro e Buneman[1981] Esquemas lgicos
Consultas a base de
dados
Supervises
Consultas modificadas
Mannino e
Effelsberg[1984]
Esquemas locais
Declaraes de
interesquemas sobre
entidades e atributos
Esquema global
Mapeamento de regras
Definio dos objetos de
integrao de esquemas
Navathe e Gadgil[1982] Viso empresarial
Vises locais
Declaraes de
intervises
Declaraes de
intravises
Processamento de
requisitos
Viso global
Mapeamento de regras
Declaraes modificadas
Conflitos
Teorey and Fry[1982] Informao, aplicao, Estrutura global de
31
Referncia Entrada Sada
eventos, perspectivas
corporativas, poltica de
direo e regras
informao
Conflitos
Yao et al.[1982] Vises
Processamento de
especificaes
Viso global
Processamento de
especificaes modificada

Wiederhold and
ElMasri[1979]
Dois esquemas Esquema global
Quadro 2 - Entradas e Sadas.
5.3 ARQUITETURAS DAS METODOLOGIAS
Vamos considerar as quatro atividades do processo de integrao. No
Quadro 3, ns mostramos as etapas que so executadas por cada uma das
metodologias . possvel classificar os metodologias em quatro grupos tendo
como base o Quadro 3:
a) Aqueles que executam uma comparao repetitiva, adequao e
unio dos esquemas, e tratam da necessidade de reestruturao
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 unio dos esquemas. Esses incluem somente as etapas 3 e 4 e
evitam a comparao e adequao 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 integrao
[ElMasri et al. [1987]; Mannino e Effelsberg [1984]; Navathe
Gadgil [1982]].
Quadro 3 - Atividades da integrao de esquemas.
Na base da estrutura de ligaes 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
Referncia PreIntegrao
(Passo1)
Comparao
(Passo2)
Adequao
(Passo3)
Unio
(Passo4)
Reestruturao
(Passo5)
Al-Fedaghi and
Scheuermann[1981]
X X
Batini e
Lenzerini[1984]
X X X X
Casanova and
Vidal[1983]
X X
Dayal and
Hwang[1984]
X X X X
ElMasri et al.[1987] X X X X X
Kahn[1979] X X X X
Motro e
Buneman[1981]
X X
Mannino e
Effelsberg[1984]
X X X X
Navathe e
Gadgil[1982]
X X X X
Teorey and
Fry[1982]
X X
Yao et al.[1982] X X
Wiederhold and
ElMasri[1979]
X X X
33
executam as etapas de unio e reestruturao.
b) Al-Fedaghi e Scheuermann [1981]; Dayal e Hwang [1984], Motro e
Buneman [1981], e Yao et al. [1982] so similares ao grupo que
executa somente unio e restruturao; 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 ligao global
do fim do processo a atividade inicial da comparao. Kahn [ 1979
] inclui a etapa de reestruturao, visto que os outros no .
d) Finalmente, Batini e Lenzerini [1984] e ElMasri et al.[1987] cobrem
todas as etapas; alm disso, fornecem uma execuo interativa
das etapas de comparao e adequao antes de qualquer unio.
De acordo com essas informaes, essa metodologia parece ter a
mxima interao com o usurio/desenvolvedor.
5.4 PR INTEGRAO
Como mostrado no Quadro 3, somente trs metodologias(ElMasri et
al. [1987]; Mannino e Effelsberg [1984]; Navathe e Gadgil [1982]), mencionam
explicitamente a etapa de pr integrao. Essa fase basicamente prope uma
coleo de correspondncias entre esquemas na forma de constraints e
declaraes entre componentes de esquemas. Estas especificaes so
utilizadas, por exemplo, para relatar nomes, estabelecer que um objeto em um
esquema resultado de alguma operao de um conjunto de objetos em outro
esquema, etc..
Para todas as metodologias, se a pr integrao no for mencionada
explicitamente, a seqncia e o agrupamento dos esquemas para a integrao
tm que ser consideradas. Nesta seo descrita as diferentes estratgias que
se dirigem a este problema.
34
A primeira etapa, escolha dos esquemas, envolve o processamento
de componentes dos esquemas em alguma seqncia. No general, o nmero
dos esquemas considerados para a integrao de cada etapa deve estar em n
>= 2.
A Figura 15 mostra quatro variaes possveis denominadas
estratgias de processamento da integrao. Cada estratgia mostrada na
forma de uma rvore. Os ns da folha correspondem aos componentes do
esquema e os ns no folha correspondem aos resultados intermedirios da
integrao. O n da raiz o resultado final.
A classificao preliminar das estratgias binria contra n-ria. As
estratgias binrias permitem a integrao de dois esquemas de cada vez.
Estas so chamadas estratgias escada quando um novo componente do
esquema integrado com um resultado intermedirio existente em cada etapa.
Uma estratgia binria dita equilibrada quando os esquemas so divididos
em pares no incio e so integrados em uma forma simtrica (veja a Figura 15).
As estratgias n-rias permitem a integrao de n esquemas de uma s vez (n
> 2). Uma estratgia n-ria one shot quando os n esquemas so integrados
em uma nica etapa; caso contrrio ela dita iterativa. A ltima classificao
o caso o mais geral.
Figura 15 - Tipos de estratgias de processamento de integrao.
35
O Quadro 4 uma comparao das metodologias entre duas
dimenses: binria versos n-ria.
A vantagem da estratgia binria a simplificao das atividades de
comparao e adequao para cada passo da integrao. evidente que a
maioria das metodologias adotam estratgias binrias devido ao aumento da
complexidade do processo de integrao com respeito ao nmero de
esquemas a serem integrados. Em geral, um algoritmo de unio de n
esquemas pode ter uma complexidade n
2
. A desvantagem dessa alternativa
o aumento no nmero de operaes de integrao para se chegar a uma
anlise final.
A estratgia n-ria de integrao realiza uma anlise de n esquemas
de uma vez. As bvias vantagens disso so: um aumento considervel de
anlise semntica que pode ser realizada antes da unio de esquemas,
evitando assim a necessidade de transformaes futuras no esquema
integrado; O nmero de passos para integrao minimizado.
Referncia Tipo de estratgia de
Integrao
Equilbrio
Al-Fedaghi and
Scheuermann[1981]
One-shot n-ria -
Batini e
Lenzerini[1984]
Binria Escada
Casanova and
Vidal[1983]
Binria Equilibrada
Dayal and
Hwang[1984]
Binria
Sem
declarao
ElMasri et al.[1987] One-shot n-ria -
Kahn[1979] Binria
Sem
declarao
36
Referncia Tipo de estratgia de
Integrao
Equilbrio
Motro e
Buneman[1981]
Binria
Sem
declarao
Mannino e
Effelsberg[1984]
Binria
Sem
declarao
Navathe e
Gadgil[1982]
n-ria interativa -
Teorey and
Fry[1982]
Binria Equilibrada
Yao et al.[1982] One-shot n-ria -
Wiederhold and
ElMasri[1979]
Binria Escada
Quadro 4 - Estratgias de processamento de integrao.
5.5 COMPARAO DOS ESQUEMAS
A atividade fundamental nessa etapa consiste em verificar todos os
conflitos na representao 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. Ns
examinaremos agora cada um em detalhes.
5.5.1 Nomeando conflitos
Os esquemas em modelos dos dados incorporam nomes para os
vrios objetos representados. Pessoas de diferentes reas de aplicao da
mesma organizao consultam aos mesmos dados usando a suas prprias
terminologias e nomes. Isto resulta em uma proliferao de nomes bem como
uma possvel inconsistncia entre nomes nos componentes dos esquemas. Os
relacionamentos problemticos entre nomes so de dois tipos:
a) Homnimos: Quando o mesmo nome for usado para dois
37
conceitos diferentes causando inconsistncias. 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) Sinnimos: Quando o mesmo conceito for descrito por dois ou
mais nomes. A menos que diferentes nomes melhorem o
entendimento de diferentes usurios, eles no so justificados. Um
exemplo aparece na Figura 17, onde o Client e o Customer so
sinnimos; 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 modificao de um nico objeto por meio de duas
entidades diferentes.
Note que homnimos podem ser detectados comparando conceitos
com o mesmo nome em esquemas diferentes, ao passo que sinnimos podem
somente ser detectados aps uma especificao externa.
Dicionrios de dados tem sido utilizados como ferramenta adjunta
para o processo de integrao de esquemas para um melhor gerenciamento de
nomes.
38

Figura 16 - Exemplo de homnimo.
Figura 17 - Exemplo de sinnimo.
Referncia Conflitos de
nome
Conflitos estruturais
Al-Fedaghi and
Scheuermann[1981]
- -
Batini e
Lenzerini[1984]
Homnimos
Sinnimos
Inconsistncia de tipos
Conflitos de constraints de
integridade
Casanova and
Vidal[1983]
- -
Dayal and
Hwang[1984]
Homnimos
Sinnimos
Conflitos a nvel de
esquema:
Diferenas de escala
Diferenas estruturais
Diferenas na abstrao
Inconsistncias a nvel de
dados:
Vrios nveis de
obsolescncia e segurana

ElMasri et al.[1987]
Homnimos
Sinnimos
Tratamento de conflitos,
especificamente:
39
Referncia Conflitos de
nome
Conflitos estruturais
Declaraes de
equivalncia de
atributos
Equivalncia de
classes de
entidades
Diferenas em nveis de
abstrao
Diferenas em regras,
graus e constraints de
cardinalidade em
relacionamentos
Kahn[1979]
Homnimos
Sinnimos
Conflitos de cardinalidade
Motro e
Buneman[1981]
- -
Mannino e
Effelsberg[1984]
Uso de
qualificadores de
nome
Especificao de
atributos de
equivalncia
Diferenas em abstraes
Navathe e
Gadgil[1982]
Homnimos
Sinnimos
Conflitos de dependncia
Conflitos de redundncia
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 conseqncia de uma escolha diferente de modelar construes
ou constraints de integridade. A seguinte classificao distingue os seguintes
tipos de conflitos:
a) Tipo de Conflitos. Estes aparecem quando o mesmo conceito
representado por diferentes construes 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 dependncia. Estes aparecem quando um grupo de
conceitos so relacionados a si mesmos com diferentes
dependncias 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 so associadas ao
mesmo conceito em esquemas diferentes. Por exemplo, SS # e
identificao de Empregado podem ser as chaves do empregado
em dois componentes de esquemas.
d) Conflitos de Comportamento. Estes surgem quando as diferentes
polticas de insero/deleo so associadas com a mesma classe
de objetos em esquemas distintos. Por exemplo, em um esquema
um departamento pode ter a permisso de existir sem
empregados, visto que outro, quando o ltimo empregado
associado com um departamento deletado, feita a deleo
automtica do departamento. Note que estes conflitos podem
surgir somente quando o modelo dos dados permitir a
representao comportamental das propriedades dos objetos.
5.6 ADEQUAO DE ESQUEMAS
O objetivo desta atividade adequar ou alinhar esquemas para faz-
los compatveis para o processo de integrao. Para conseguir este objetivo,
deve-se resolver os conflitos, que por sua vez exigem que transformaes
desse esquema sejam feitas. A fim de resolver um conflito, o desenvolvedor
deve compreender os relacionamentos semnticos entre os conceitos
41
envolvidos no conflito. s vezes os conflitos no podem ser resolvidos porque
surgiram em conseqncia de alguma inconsistncia bsica. Neste caso, os
conflitos so relatados aos usurios, que devem guiar o desenvolvedor em sua
definio. A Figura 18 mostra trs exemplos de como transformar um atributo
em uma entidade, como sugerido por Batini e Lenzerini [1984].
Figura 18 - Transformao de um atributo em uma entidade.
5.7 UNIO E REESTRUTURAO
As atividades executadas por metodologias durante esta fase
geralmente requerem diferentes tipos de operaes a serem executadas nos
componentes dos esquemas ou no esquema integrado temporrio.
Estabelecendo uma estrutura comum para esta fase, ns supomos que todas
as metodologias primeiramente unem os componentes de esquemas por meio
de uma sobreposio simples de conceitos comuns, e executamos ento
operaes de reestruturao no esquema integrado obtido por unio.
O Quadro 6 mostra as transformaes propostas nas metodologias
para esta etapa. Cada transformao executada a fim melhorar o esquema
42
com respeito a um dos trs quesitos descritos na seo 5: integridade,
minimizao e entendimento. Ns analisamos agora cada um deles
separadamente.
Referncia Propriedades de
Interesquema
Al-Fedaghi and
Scheuermann[1981]
-
Batini e
Lenzerini[1984]
Subconjuntos
Generalizao
Relacionamentos
Casanova and
Vidal[1983]
Dependncias de Incluso
Dependncias de excluso
Dependncias funcionais de
unio
Dayal and
Hwang[1984]
Subconjuntos
Subfunes
ElMasri et al.[1987]
Declaraes relacionadas a
extenses
Agrupamento de atributos em
classes
Kahn[1979] -
Motro e
Buneman[1981]
Subconjuntos
Mannino e
Effelsberg[1984]
Generalizao
Sobreposio e no
sobreposio
Escopo de atributos e
significados
Navathe e
Gadgil[1982]
Categorizao
Subconjuntos
Particionamento
Teorey and
Fry[1982]
Generalizao
Agregao
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
anlise e a adio de propriedades do interesquema que iniciada em etapas
precedentes ao projeto. Na Figura 14 ns mostramos exemplos de
propriedades de interesquemas. No Quadro 6 ns 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
mltiplas perspectivas do usurio em classes de objetos comparveis.
5.7.2 Minimizao
Na maioria das metodologias, o objetivo da minimizao descobrir e
eliminar redundncias. Uma noo de minimizao ilustrada na Figura 19
onde trs relacionamentos esto presentes, indicados por setas.
O relacionamento entre Engineering_manager and Employee
redundante. Necessita-se ento reduzir os conceitos deletando os
relacionamentos redundantes.
.
Figura 19 - Um esquema com redundncia.
44
5.7.3 Compreenso
A questo de compreenso 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 so equivalentes, o esquema B est mais compreensvel do que o
esquema A. O esquema B foi obtido do esquema A adicionando uma
generalizao hierrquica relacionando Publication para Book e Paper. No
general, para melhorar a compreenso, transformaes adicionais no esquema
so necessrias.
Figura 20 - Aprimorando o entendimento.
45
6 METODOLOGIA DE UNIO DE ESQUEMAS DE ELMASRI
6.1 VISO GERAL DA METODOLOGIA
Esta metodologia utiliza uma variante do modelo de entidade
relacionamento (E-R) para representar esquemas ou vises do usurio e
discutir o problema de integrar relacionamentos de esquemas diferentes.
Usando trs critrios principais para comparar relacionamentos, foi
desenvolvido um esquema hierrquico de comparao. Cada caso
representado pelos ns terminais desta hierarquia discutido separadamente e
as regras da integrao so desenvolvidas. O problema tratado dentro de um
sentido geral de modo que a discusso qualitativa seja aplicvel a diversos
outros modelos semnticos de dados.
Com a atual diversidade dos modelos de dados e dos sistemas de
gerenciamento de base de dados, o problema da integrao de esquemas tem
se tornado cada vez mais importante. A integrao de esquemas baseia-se em
dois contextos diferentes:
a) Projeto global do esquema.
b) Projeto de base de dados lgico.
No projeto global do esquema, diversas bases de dados j existem e
esto em uso. O objetivo projetar um nico esquema global que represente
os ndices de todas estas bases de dados. Este esquema global pode ento
ser usado como uma relao s diversas bases de dados.
As consultas e transaes do usurio podem ento ser especificadas
de encontro a este esquema global, e os pedidos so mapeados s bases de
dados relevantes.
A integrao do esquema aplicvel ao projeto global do esquema
em ambientes centralizados e distribudos. Nesta metodologia de trabalho
46
focalizada o uso da integrao de esquemas no projeto de base de dados
lgico. Porm a filosofia total da integrao de esquemas discutida aqui se
aplica a ambos os contextos.
6.2 ABORDAGEM DA INTEGRAO DE VISES
Agora veremos algumas caractersticas importantes na integrao de
vises. O esboo do procedimento da integrao consiste em:
a) Especificao e modificao interativa de intervises e intravises
pelos desenvolvedores da base de dados. Esta uma fase de pr-
integrao para especificar as correspondncias exatas entre os
atributos, as classes do objeto e os relacionamentos nas diferentes
vises.
b) Integrao interativa das classes do objeto e de relacionamentos
baseadas nas afirmaes especificadas. Algumas afirmaes
podem ser modificadas durante esta fase.
c) Gerao de mapeamentos do esquema global para as vises
locais.
A integrao de relacionamentos aplica-se durante a etapa 2 descrita
acima. A filosofia por trs da integrao de vises de chegar a uma estrutura
de compromisso". Quando apresentadas vises alternativas de uma mesma
situao, ns aceitamos a viso mais geral. Qualquer constraint adicional
localmente aplicvel a uma viso do usurio pode sempre ser reforada no
ponto de viso mais geral. No contexto do modelo do E-C-R, a integrao de
vises do usurio resultam em uma combinao das seguintes mudanas a
uma viso de modo que a semntica da outra viso 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-integrao
A fase de pr-integrao necessria para especificar
correspondncias entre objetos em diferentes vises. Nesta fase tratado, por
exemplo, os problemas de homnimos e sinnimos. A fase de pr-integrao
estabelece os seguintes contextos entre as vises individuais do usurio:
a) Correspondncias de nomes de classe.
b) Correspondncias de nomes de atributos
c) Chaves candidatas para cada classe.
d) Correspondncias entre classes de entidades em diversas vises.
e) Correspondncias entre nomes de regras e relacionamentos
A noo de similaridade entre classes de objetos difcil de definir
precisamente. Por exemplo, se na viso 1 temos a classe Engenheiro e na
viso 2 temos Secretrio, as duas classes incluem o mesmo tipo de entidade
(Empregado), mas no tero qualquer das entidades em comum. Esta
concluso no pode ser descrita se compararmos a string Engenheiro com a
string Secretrio. Uma outra comparao das strings Engenheiro e Supervisor
indicam que so dissimilares; porm o relacionamento entre elas no ser o
mesmo que no caso precedente, desde que possam compartilhar de algumas
entidades em comum.
possvel desenvolver uma ferramenta automatizada para ajudar os
desenvolvedores em estabelecer correspondncias de classes comparando as
strings com os nomes de classes e nomes do atributo. Este mtodo pode
detectar os homnimos onde os nomes das strings so coincidentes, mas o
significado pode ser diferente. Contudo, quando as diferentes vises tiverem
nomes completamente diferentes para classes similares de entidades
(sinnimos), a responsabilidade inteira de denotar quais classes so similares
48
voltada ao desenvolvedor. Assim, os trs fatores seguintes contribuem para o
estabelecimento do grau de similaridade ou grau de adaptao entre vises:
a) Uma especificao de quais classes so similares, idnticas, por
sobreposio, ou contida em outra. Pode ser feita em uma
linguagem especialmente projetada para especificao de
constraints.
b) Um sistema de comparao guiada de nomes de strings.
c) Entrada do desenvolvedor para confirmar e resolver
correspondncias.
6.2.2 Reviso de integrao de objetos
Antes de entrar na questo da integrao de relacionamentos, vamos
nos dirigir momentaneamente integrao de classes de objeto. A integrao
de objetos precursora integrao de relacionamentos, desde que depois da
integrao de objetos seja possvel determinar a similaridade dos
relacionamentos. Uma vez que a similaridade entre classes de objetos
estabelecida durante a fase de pr-integrao, objetos similares de todas as
vises podem ser integrados.
Integrar duas classes do objeto de vises diferentes depende das
extenses destes objetos de base de dados quando a base de dados est
povoada. Ns referimos extenso da classe do objeto em uma viso do
domnio da classe do objeto. Duas classes de objeto similares A e B de
diferente vises podem ser relatadas de vrias 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 tero que ser refletidas no esquema global. Elmasri e Navathe
[ELMA84] discutiram o processo da integrao de objetos em detalhes. Aqui
ser mencionado resultados resumidos para cada um dos casos acima.
DOM(a)=DOM(b)
Os objetos no domnio A so idnticos aos objetos no domnio B, isto
, as extenses dos objetos em A e B so idnticas. Neste caso as classes de
objetos A e B so integradas e uma nica classe do objeto C criada.
Considere o exemplo mostrado na Figura 21.
Figura 21 - Domnios idnticos
Aps a afirmao pelo desenvolvedor que o domnio Employee na
viso 1 idntico ao domnio Workers na viso 2, uma classe de objetos
integrada Employers criada. Os atributos da classe recentemente criada so
a unio dos atributos das classes idnticas unidas. Se as chaves de ambas as
classes no forem as mesmas, ento o desenvolvedor selecionar uma chave
preliminar para a classe C, e outras chaves se transformaro em chaves
secundrias no esquema conceitual.
DOM(A)DOM(B)
Quando o domnio de uma classe B um subconjunto do domnio 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 vises. O domnio da classe Graduate-Students um
subconjunto da classe de objetos Students. A integrao 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 integrao das classes A e B, um
objeto classe AB cujo domnio a unio das classes A e B est criada.
Considere dois objetos trucks e TRACTOR-TRAILER em duas vises
diferentes. Claramente as classes de objetos no se contm mas esto
relacionadas. Integrar classes de objetos resulta em uma hierarquia da
generalizao. O resultado uma classe entidade Vehicle e duas subclasses
Truck e Tractor-Trailer como mostrado na Figura 23.
Figura 23 - Hierarquia de generalizao.
O domnio da classe Vehicles a unio dos domnios 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 no tm objetos em comum. A integrao
de tais objetos deixada para o desenvolvedor. Aquelas classes de objeto que
no so integradas sero retidas sem qualquer modificao.
6.3 INTEGRAO DE RELACIONAMENTOS
O problema da integrao de relacionamentos est associado ao
problema de integrar classes de objetos. Dado uma classe entidade A1 em
uma viso V1, sempre h uma classe entidade similar ou compatvel A2 na
viso V2, ou seja, todos os relacionamentos dos quais A1 participa torna-se um
potencial assunto de integrao com todo o relacionamento que A2 participa. A
real unio dos relacionamentos, contudo, est sujeita a semntica que
determinada pelas regras das classes de entidade, do grau, das relaes de
cardinalidade dos relacionamentos, etc.
Alm disso, quando classes de entidade A1 e B1 em V1 combinam
respectivamente A2 e B2 em V2, h uma potencial probabilidade de vrios
tipos de relacionamentos existirem entre os pares das entidades. Somente
aps um exame semntico detalhado destes relacionamentos, os mesmos
podem ser integrados. Especificaes externas que relacionam construes
entre vises assim como a entrada do desenvolvedor so feitas para ajudar na
determinao de quais relacionamentos devem ser sujeitados a unies. Uma
suposio implcita diz que os relacionamentos esto sendo analisados de dois
em dois para a integrao. As idias so aplicveis para a integrao n-ria;
entretanto, os detalhes mecnicos da integrao n-ria ainda devem ser
investigados.
52
6.3.1 Critrios para a comparao de relacionamentos
Com a finalidade da integrao de vises, relacionamentos podem
ser classificados em trs caractersticas diferentes:
a) Grau de um relacionamento: O grau de um relacionamento o
nmero de entidades (no necessariamente distintos) participando
nesse relacionamento. Uma entidade por si mesma pode ser
tratada como um relacionamento do zero grau para finalidades da
comparao 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 equivalncia semntica dos
relacionamentos baseada na correspondncia entre regras e nas
instncias dos relacionamentos. Durante a fase de pr-integrao,
as correspondncias acima so estabelecidas. Adicionalmente,
muitas linguagens de consultas a banco de dados suportam
diretamente nomes de regras em suas expresses da seleo: Se
os nomes de regras forem usados, o processo de modelagem e
recuperao de dados so facilitados para o usurio 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 especificao suportada pelo modelo para expressar os
constraints que so chamados de constraints estruturais
[ELMA80]. Ns consideraremos constraints de cardinalidade como
o tipo preliminar de constraints estruturais no processo de
53
integrao. Os constraints de cardinalidade em um relacionamento
binrio colocam restries no nmero dos objetos de uma classe
entidade que podem ser relacionados a um objeto da outra classe
entidade. Ns associamos dois nmeros: a Max Cardinality e a
Min Cardinality para especificar, respectivamente, o nmero
mximo e o mnimo de instancias do relacionamento por uma
instncia do dado tipo de entidade. Uma relao do com valor 0
implica uma participao parcial e 1 implica uma participao total
da entidade em um relacionamento. Para um relacionamento n-
rio, o conceito da relao da cardinalidade normalmente
estendido para especificar o nmero de instancias do
relacionamento que podem ser relacionadas a uma entidade da
classe participante. Assim, em um relacionamento ternrio (A, B,
C), as trs relaes de cardinalidade referem s relaes de
ocorrncias A: (B, C), B: (A, C) e C: (A, B). Estas relaes so
usadas por Lenzerini e Santuccl [LENZ83] em suas tcnicas de
especificao de cardinalidade. Alternadamente, as relaes
(A,B):C, (B, C):A e (C, A):B so significativas e tem um papel
importante durante a integrao (veja Figura 37).
6.3.2 Classificao dos relacionamentos
A fim de desenvolver uma abordagem sistemtica integrao dos
relacionamentos, os trs aspectos acima so considerados em forma de uma
estrutura de rvore. O n superior da rvore chamado de grau de um
relacionamento. No segundo nvel, ns reconhecemos diferenas nas regras.
Isto tem dois possveis resultados: a mesma regra ou uma regra diferente. O
ltimo nvel da rvore tem os ns chamados constraints estruturais. As bordas
so 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 ns da folha desta
estrutura de rvore representam esultados possveis quando os
relacionamentos das diferentes vises so comparados. Na metade esquerda
da rvore esto os casos mais fceis 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
ausncia de constraints estruturais): Este o exemplo mais simples de
integrao de relacionamentos. Duas vises V1 e V2 contm um
relacionamento entre duas classes entidade similares. Somente uma viso
retida no esquema aps a integrao. Se uma classe entidade na viso V1 for
um subconjunto da classe entidade na viso V2, a subclasse correspondente
est criada para armazenar as entidades da viso V1.
Um exemplo deste tipo mostrado na Figura 25 e Figura 26. A Figura
25 mostra duas vises de entrada onde o domnio da classe entidade classifica
Grad-Student e CS_Student que so diferentes em ambas as vises. O
esquema de integrao(Figura 26) usa duas categorias chamadas
Grad_Student e CS_Student.
55

Figura 24 - Abordagem semntica dos relacionamentos.
Figura 25 - Relacionamentos com o mesmo grau.
Figura 26 - Unio de mesmo grau
56
Caso 2 - Mesmas regras e constraints estruturais diferentes: Neste
caso uma das vises tem mais constraints do que a outra. Considere um
exemplo onde para o relacionamento a ser integrado, a participao de uma
entidade ou viso V2 deve ser total, enquanto que a participao da mesma
entidade na viso V1 deve ser parcial. Desde que os constraints de ambas as
vises estejam conflitando, ns deixamos as constraints serem aplicadas - a
viso com a participao total remanesce no esquema.
O processo de integrao ilustrado na Figura 27 . A primeira viso mantida
pelo secretrio, onde alguns estudantes provavelmente no esto matriculados
em nenhum curso. A segunda viso mantida pelo escritrio da contabilidade,
que inclui somente estudantes atualmente registrados. A participao de
Students na viso V2 total, enquanto parcial na viso 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 so usadas nos
relacionamentos, os relacionamentos no so idnticos desde que se
conduzam em semnticas diferentes. Em muitos casos as classes de objetos
que participam no relacionamento no sero idnticos. Durante a integrao
dos objetos, as sub-classes adicionais so criadas (veja Figura 32, com as sub-
classes Home-Borrower e Auto-Borrower).
Ns consideraremos trs casos:
Caso 3 - Deteno: Neste caso o relacionamento na viso V2 contm
todos os exemplos da viso V1.
57

Figura 27 - Relacionamentos com constraints diferentes.
Figura 28 - Unio com constraints diferentes.
O relacionamento em V1 um subconjunto (subrelao) do
relacionamento em V2. Os esquemas isolados e integrados so 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 Deteno
Caso 4 - Relacionamentos disjuntos: Quando os relacionamentos nas
vises transportam semnticas diferentes e no so prximos, ento os
relacionamentos esto includos no esquema sem qualquer modificao.
59

Figura 30 - Relacionamentos disjuntos
No exemplo acima, os relacionamentos na viso V1 e V2 esto
disjuntos nos termos de seus ndices. As duas vises so mantidas no
esquema sem nenhuma modificao. O esquema inicial e resultante so
mostrados na Figura 30.
Caso 5 - Relacionamentos cruzados: Os relacionamentos descritos
entre o mesmo conjunto de entidades em duas vises poderiam ter algumas
instncias em comum, mas nenhum dos relacionamentos nas vises um
subconjunto do outro. Considere as vises mostradas na Figura 31.
Figura 31 - Relacionamentos cruzados.
60

Figura 32 - Unio de relacionamentos cruzados.
A entidade Person poderia ser um Home Borrower e um Auto
Borrower. As instancias de Person em ambas as vises se sobrepem. Ento
duas categorias so criadas na classe entidade Person durante a integrao do
objeto. Estas categorias poderiam ser atributos definidos por sub-classes ou o
usurio definiria as subclasses. Se estas categorias fossem atributos definidos
ento uma insero de uma instncia de Person criaria automaticamente uma
instancia da categoria respectiva.
No caso em que o usurio definiu a categoria, o usurio tem que
especificar a incluso das categorias. O esquema aps a integrao do
relacionamento mostrado na Figura 32.
6.3.4 Unindo relacionamentos de diferentes graus
Quando so 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 definio informal possvel a seguinte: uma viso V1
derivvel de v2 se toda ocorrncia de entidade e relacionamento V1 ocorrer
diretamente em V2 ou possa ser gerado de V2 pelo uso de linguagens de alto
nvel (como SQL ou GORDAS [ ELMA81]).
- Os diferentes relacionamentos podem ser compatveis reforando
constraints semnticas adicionais. Estes constraints so do seguinte tipo:
a) Constraints de Cardinalidade entre trs ou mais tipos de
entidades; por exemplo, para o relacionamento (A, B, C), relaes
de cardinalidade (A, B):C, (A, C):B e (B, C): A, qual so
tipicamente ausentes de notaes grficas so importantes para
reforar 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 derivveis fazem uma viso derivvel de outras
constraints. Essas constraints tomariam formas de especificaes
complexas que podem usar linguagens de nvel mais elevado.
d) Os diferentes relacionamentos no podem ser tratados como a) ou
b) acima. Ento eles ficam coexistindo na integrao de vises de
e fica nas mos do desenvolvedor ter a palavra final na unio.
Unir relacionamentos de diferentes graus mais complicado quando
os relacionamentos de mais elevado grau contam com mais informao
semntica. Conseqentemente duas consideraes so 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 nvel como SQL, sem considerar
a semntica dos dados, pode render resultados falsos. Ns
classificamos a integrao dos relacionamentos de diferente graus
62
em trs diferentes tipos como a estrutura mostrada na Figura 33.
Estes trs casos so discutidos abaixo:
Figura 33 - Classificao de relacionamentos de diferentes graus.
Relacionamentos unificveis: Dois relacionamentos so unificveis
quando um relacionamento pode ser derivado do outro. Isto se aplica aos
casos onde um relacionamento em uma viso est representado por uma
entidade (isto , um relacionamento com grau zero) em uma outra viso.
Considere duas vises V1 e V2 como mostrado na Figura 34.
Figura 34 - Relacionamentos Unificveis.
A entidade na viso V2 referida como uma "entidade comprimida
[NAVA76] Na viso V2, a entidade comprimida Car-Ownership no tem
qualquer constraint de na relao entre Person e Car, isto , pode ser
considerada uma relao de muitospara-muitos. A viso V2 pode ser derivada
63
de V1. Os constraints de mapeamento (1:1, 1:n, N:1, ou m:n) na viso V1
podem ser reforados em V2 pela escolha apropriada das chaves. Para o
exemplo, se SSN e LIC# forem as chaves das entidades Person e Car,
respectivamente, ento as possveis 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 unio praticvel 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 viso V2 possa ser considerada
equivalente para compresso de algumas entidades. O resultado da integrao
no caso acima a viso V1
Relacionamentos unificveis por condio: Em alguns casos da unio
de relacionamentos, dois relacionamentos poderiam ser unificados somente
quando as informaes semnticas adicionais forem especificadas. Considere
dois relacionamentos definidos na viso V1 e V2 na Figura 35.
Figura 35 - Relacionamentos unificveis por condio.
A derivabilidade da viso V1 em V2 dependente da entidade C. Sob
certo aspecto, quando a semntica das duas vises so as mesmas, a viso
V1 dever ser "derivvel de V2. Aqui, V2 retido como viso global. Mas a
interpretao semntica do relacionamento na viso V1 (como representado
pela regra) no deve ser equivalente ao relacionamento na viso V2. Por
64
exemplo, na Figura 36 temos que o relacionamento de Majors-In no uma
composio dos relacionamentos Attends e Offered-By. Ento, todos os
relacionamentos so retidos.
Figura 36 - Relacionamentos retidos.
possvel em alguns casos que um relacionamento de grau mais
baixo seja derivvel de um relacionamento de grau mais elevado.
Figura 37 - Dependncia funcional.
Considere a Figura 37, na viso V1, onde as relaes de
cardinalidade ao longo dos arcos esto como segue:
(S,G):C = (1,N)
(S,C):G = (1,1)
(C,G):S = (1,M)
A relao (1,1) entre (S,C) e G acima implica em uma dependncia
65
funcional: (Student, Course) -----> Grade
devido a isto, um relacionamento binrio mostrado na viso v2
equivalente ao relacionamento ternrio na viso 1.
Em general, uma viso binria derivvel de uma viso ternria
sempre que a relao (1,1) ou (0,1) exista . A relao (1,1) acima pode ser
modelada fazendo da classe um atributo do relacionamento. A relao de A
(0,1) significaria um atributo opcional. Se a classe tiver seus prprios atributos,
a mesma seria considerada como os atributos do novo relacionamento.
Considere um outro caso de vises derivveis da Figura 38. O
relacionamento binrio em R2 ser derivvel de R1 somente se a seguinte
constraint for especificada: R2 = projeo de R1 em Dealer, Customer. A
constraint acima pode ser expressada como uma especificao de derivao
em uma linguagem de alto nvel. Quando duas vises so condicionalmente
unificveis, a viso de um grau mais elevado deve ser mantida como a viso
integrada junto com as especificaes da derivao.
Figura 38 - Vises derivveis.
66
Relacionamentos no-unificveis: Esta categoria inclui
relacionamentos de duas vises onde algumas ou todas as classes entidade
envolvidas podem ser comuns a ambas as vises, contudo o grau de
relacionamentos dissimilar e a semntica no exatamente a mesma.
Considere um exemplo simples(Figura 39): Na viso V1, h dois
relacionamentos R1 e R2. Eles descrevem independentemente o
relacionamento de um negociante que fornece uma pea e o cliente que
compra uma pea. A viso V2 descreve o relacionamento R3 que uma
associao ternria que descreve o fato que um cliente compra uma
determinada parte de um determinado negociante.
Embora a mesma classe entidade est envolvida nas duas vises, o
conjunto de instancias de cada classe entidade envolvida na viso V1 e V2
deve ser idntico. Este o exemplo clssico de uma armadilha da conexo
[CODD70]. Agora o esquema integrado resultante conter as classes entidade
Dealer, Part, Customer e todos os relacionamentos RI, R2, R3.
Figura 39 - Relacionamentos no unificveis.
67
7 CONCLUSO
Este trabalho procurou levantar os principais esforos existentes na
rea de tratamento de integrao de bases de dados. Com o aumento da
complexidade e da utilizao de tais recursos de armazenamento de
informao, o problema de integrao se torna mais difcil e desafiador.
Embora de forma bastante condensada, foi demonstrado o estado da
arte relacionado a questo de integrao de esquemas. Foi feito uma breve
anlise das escolas de pensamento atravs do tempo, assim como as
principais causas da diversidade de esquemas e as etapas adequadas para um
bom andamento do processo da integrao, para que se tenha um
amadurecimento a respeito do assunto e se evite cometer os mesmos erros.
Alm disso, foram apresentadas de forma geral diversas
metodologias para a integrao de esquemas de acordo com as etapas
delineadas para o processo, com a indicao de quadros comparativos e o
comportamento das entradas e sadas das referidas arquiteturas.
Levando-se em considerao caractersticas como a transparncia
dos processos de integrao e a utilizao de uma modelagem amplamente
aceita no meio acadmico e comercial, foi relatada com um pouco mais de
profundidade a metodologia utilizada por ElMasri[1987]. Essa arquitetura tem
como item imprescindvel a classificao dos relacionamentos de acordo com
grau, alm de regras e constraints estruturais que so importantes
caractersticas que nos levam a comparao de relacionamentos. A anlise
deste estudo constata que possvel definir regras de integrao em casos
onde os relacionamentos tem o mesmo grau. O problema se torna mais difcil
quando relacionamentos de diferentes graus tm 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
atravs de outros modelos.
68
Novas tecnologias de redes de comunicao, bases de dados
distribudas, conhecimento baseado em sistemas e aplicativos de escritrio
tendem a difundir o uso compartilhado de dados em termos de usurios,
diversidade de aplicaes e sofisticao de conceitos. O projeto,
desenvolvimento e engenharia de aplicaes esto se tornando peas chave
nos sistemas de gerenciamento de bases de dados.
Com isso, tecnologias recentes de tratamento de vises de dados e
consultas(como XML) podem fazer a diferena no redirecionamento de
recentes pesquisas relacionadas a rea, como a extenso de metodologias de
integrao, unificao de processos e interfaces para a Web e o
desenvolvimento de sistemas inteligentes para a integrao de esquemas.
O conhecimento e a informao se tornaram um bem precioso para a
organizao. Sendo assim, necessrio gerenci-lo bem para se ter um efetivo
controle sobre este patrimnio peculiar. Este gerenciamento s possvel
atravs de uma arquitetura coesa com o pleno domnio das bases de dados. O
seu valor aumenta considerando que as informaes esto cada vez mais
integradas e passam a dar apoio a tomadas de deciso a fim de obter
vantagens competitivas para a organizao.
Tendo em vista os aspectos apresentados, acredita-se que o
aumento da necessidade de metodologias para integrao de dados em
conceitos e formas fsicas ser cada vez mais essencial em todos os
segmentos de tratamento da informao.
69
REFERNCIAS
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. Relatrio Tcnico.
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. Disponvel 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 VISO DO MODELO DE ENTIDADE - CATEGORIA -
RELACIONAMENTO.
O modelo E-R estendido que ns usamos chamado aqui de modelo
do Entidade-Categoria-Relacionamento (E-C-R). O modelo do E-C-R inclui
extenses ao modelo do E-R em duas reas principais:
a) O conceito de categoria usado para representar as sub-classes
[HAMM81]. Adicionalmente, as categorias tambm podem ser
usadas para agrupar entidades que usam as mesmas regras em
um relacionamento.
b) Cardinalidades e dependncia de constraints em relacionamentos
so especificados precisamente.
O modelo E-C-R usa as seguintes construes: conjunto de
entidades, conjuntos de relacionamentos, categorias e atributos. Os conjuntos
de entidade representam conjuntos de entidades que tm 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 extenso 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 nmero de categorias de subclasses. As
categorias de subclasse poderiam ser atributos definidos ou que os usurios
definiram [HAMM81]. O conceito de categoria permite uma modelagem
generalizada. No exemplo da figura abaixo, Car e Truck so 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 prprias do relacionamento
Owner.
Ento Owner um subconjunto da unio 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 UNIO) E
RELACION-LA.
76
ANEXO 5 MODIFICANDO VISES PARA ADEQUAO ANTES DA
INTEGRAO
77
ANEXO 6 ESQUEMA INTEGRADO APS UNIO DAS VISES 1 E 2
78
ANEXO 7 DIFERENTES ESTRATGIAS PARA O PROCESSO DE
INTEGRAO DE VISES