alessandro rodrigues zamboni

ALESSANDRO RODRIGUES ZAMBONI

UMA PROPOSTA DE SISTEMA DE SOFTWARE PARAAUXILIO NA GERACAO DE TRANSFORMACOES DO

FORMALISMO BAV PARA INTEGRACAO DE BANCOS DEDADOS

Dissertacao apresentada como requisito par-cial a obtencao do grau de Mestre. Pro-grama de Pos-Graduacao em Informatica,Setor de Ciencias Exatas, Universidade Fed-eral do Parana.Orientador: Prof. Dr. Andre Luiz PiresGuedes

CURITIBA

2004

ALESSANDRO RODRIGUES ZAMBONI

UMA PROPOSTA DE SISTEMA DE SOFTWARE PARAAUXILIO NA GERACAO DE TRANSFORMACOES DO

FORMALISMO BAV PARA INTEGRACAO DE BANCOS DEDADOS

Dissertacao aprovada como requisito parcial a obtencao do grau deMestre no Programa de Pos-Graduacao em Informatica da Universidade

Federal do Parana, pela Comissao formada pelos professores:

Orientador: Prof. Dr. Andre Luiz Pires Guedes

Departamento de Informatica, UFPR

Prof. Dr. Milton Ramos Ramirez

Instituto de Matematica, UFRJ

Prof. Dr. Marcos Sfair Sunye

Departamento de Informatica, UFPR

Curitiba, 7 de julho de 2004

Ministério da Educação Universidade Federal do Parana ÜFPR Mestrado em Informática

PARECER

Nos, abaixo assinados, membros da Banca Examinadora da defesa de Dissertação de Mestrado em Informática, do aluno Alessandro Rodrigues Zambom, avaliamos o trabalho intitulado, “UMA PROPOSTA DE SISTEMA DE SOFTWARE PARA AUXILIO NA GERAÇÃO DE TRANSFORMAÇÕES DO FORMALISMO BAVPARA INTEGRAÇÃO DE BANCOS DE DADOS", cuja defesa foi realizada no dia 07 de julho de 2004, as dez horas, no Auditono do Departamento de Informática do Setor de Ciências Exatas da Universidade Federal do Parana Apos a avaliação, decidimos pela aprovação do candidato

Curitiba, 07 de julho de 2004

Prof Dr Andre Luiz Pires Guedes DINF/UFPR - Onentador

i

AGRADECIMENTOS

Agradeco a Coordenacao de Graduacao e Pos-Graduacao de Informatica da Universi-

dade Federal do Parana pela educacao e confianca depositadas em mim ao longo desses

anos. Agradeco a meu orientador, Prof. Dr. Andre Luiz Pires Guedes, pelo apoio e pelos

sabios conselhos nos momentos de desespero. Agradeco aos professores Marcos Sunye e

Carmem Satie Hara por me mostrarem a direcao a seguir. Por fim agradeco a todos os

meus colegas de mestrado e a meus familiares pela pequenas contribuicoes que fizeram a

diferenca entre a vitoria e o fracasso.

ii

SUMARIO

LISTA DE FIGURAS vi

LISTA DE TABELAS viii

RESUMO ix

ABSTRACT x

1 INTRODUCAO 1

1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Organizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 BANCOS DE DADOS 7

2.1 Sistema Gerenciador de Bancos de Dados . . . . . . . . . . . . . . . . . . . 7

2.2 Esquemas e Instancias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Modelos de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 O Modelo Entidade-Relacionamento . . . . . . . . . . . . . . . . . . 8

2.3.2 O Modelo de Dados Relacional . . . . . . . . . . . . . . . . . . . . 10

2.3.3 Outros Modelos de Dados . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.3.1 O Modelo de Dados em Rede . . . . . . . . . . . . . . . . 12

2.3.3.2 O Modelo de Dados Hierarquico . . . . . . . . . . . . . . . 13

2.3.3.3 O Modelo de Dados Orientado a Objeto . . . . . . . . . . 13

2.4 Bancos de Dados Distribuıdos . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 INTEGRACAO DE BANCOS DE DADOS 16

3.1 Fases da Integracao de Bancos de Dados . . . . . . . . . . . . . . . . . . . 17

3.1.1 Consideracoes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.2 Pre-Integracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

iii

3.1.3 Identificacao de Correspondencias . . . . . . . . . . . . . . . . . . . 20

3.1.4 Identificacao de Conflitos . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.5 Integracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.6 Uniao e Reestruturacao . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Casos de Conflito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2.1 Conflitos de Incompatibilidade de Domınio . . . . . . . . . . . . . . 24

3.2.1.1 Conflitos de Nomes . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1.2 Conflitos de Representacao dos Dados . . . . . . . . . . . 24

3.2.1.3 Conflitos de Unidade . . . . . . . . . . . . . . . . . . . . . 25

3.2.1.4 Conflitos de Precisao dos Dados . . . . . . . . . . . . . . . 25

3.2.1.5 Conflitos de Valores Padrao . . . . . . . . . . . . . . . . . 25

3.2.2 Conflitos entre Definicoes de Entidades . . . . . . . . . . . . . . . . 26

3.2.2.1 Conflitos de Equivalencia de Chaves . . . . . . . . . . . . 26

3.2.2.2 Conflitos de Uniao . . . . . . . . . . . . . . . . . . . . . . 27

3.2.2.3 Conflitos de Isomorfismo . . . . . . . . . . . . . . . . . . . 27

3.2.2.4 Conflitos de Falta de Atributos . . . . . . . . . . . . . . . 27

3.2.2.5 Conflitos entre Relacoes e Atributos . . . . . . . . . . . . 28

3.2.2.6 Conflitos entre Atributos e Dados . . . . . . . . . . . . . . 28

3.3 Formalismos para Integracao de Bancos de Dados . . . . . . . . . . . . . . 29

3.3.1 Global as View (GAV) . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.2 Local as View (LAV) . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 O FORMALISMO E SUAS METODOLOGIAS 31

4.1 O Projeto AutoMed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 O Modelo de Dados Baseado em Hipergrafos . . . . . . . . . . . . . . . . . 32

4.3 Linguagem Intermediaria para Consultas (IQL) . . . . . . . . . . . . . . . 33

4.3.1 Sintaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.2 Funcoes Nativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4 Both as View (BAV) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.5 Metodologias Utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

iv

4.6 Resolucao dos Casos de Conflito . . . . . . . . . . . . . . . . . . . . . . . . 47

4.6.1 Conflitos de Incompatibilidade de Domınio . . . . . . . . . . . . . . 47

4.6.1.1 Conflitos de Nomes . . . . . . . . . . . . . . . . . . . . . . 47

4.6.1.2 Conflitos de Representacao dos Dados . . . . . . . . . . . 47

4.6.1.3 Conflitos de Unidade . . . . . . . . . . . . . . . . . . . . . 48

4.6.1.4 Conflitos de Precisao dos Dados . . . . . . . . . . . . . . . 48

4.6.1.5 Conflitos de Valores Padrao . . . . . . . . . . . . . . . . . 49

4.6.2 Conflitos entre Definicoes de Entidades . . . . . . . . . . . . . . . . 50

4.6.2.1 Conflitos de Equivalencia de Chaves . . . . . . . . . . . . 50

4.6.2.2 Conflitos de Uniao . . . . . . . . . . . . . . . . . . . . . . 50

4.6.2.3 Conflitos de Isomorfismo . . . . . . . . . . . . . . . . . . . 51

4.6.2.4 Conflitos de Falta de Atributos . . . . . . . . . . . . . . . 51

4.6.2.5 Conflitos entre Relacoes e Atributos . . . . . . . . . . . . 52

4.6.2.6 Conflitos entre Atributos e Dados . . . . . . . . . . . . . . 52

5 UMA PROPOSTA DE SISTEMA DE SOFTWARE PARA AUXILIO

NA INTEGRACAO DE BANCOS DE DADOS 54

5.1 Visao Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2 O Funcionamento do SAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2.1 Remover Chaves Estrangeiras . . . . . . . . . . . . . . . . . . . . . 58

5.2.2 Gerar Tabela de Correlacionamentos . . . . . . . . . . . . . . . . . 58

5.2.3 Unificar Chaves Primarias . . . . . . . . . . . . . . . . . . . . . . . 59

5.2.4 Unificar Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2.5 Remover Objetos nao Unificados . . . . . . . . . . . . . . . . . . . 62

5.2.6 Gerar Chaves Estrangeiras . . . . . . . . . . . . . . . . . . . . . . . 63

5.3 Vantagens do Sistema SAI . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6 CONCLUSAO 65

BIBLIOGRAFIA 68

v

ANEXO A 71

A.1 O Modelo de Dados Baseado em Hipergrafos . . . . . . . . . . . . . . . . . 71

A.1.1 Nocoes Basicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

A.1.2 Transformacoes Primitivas . . . . . . . . . . . . . . . . . . . . . . . 73

ANEXO B 76

B.1 Observacoes Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

B.2 Etapas do SAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

B.2.1 Remover Chaves Estrangeiras . . . . . . . . . . . . . . . . . . . . . 76

B.2.2 Gerar Tabela de Correlacionamentos . . . . . . . . . . . . . . . . . 77

B.2.3 Unificar Chaves Primarias . . . . . . . . . . . . . . . . . . . . . . . 77

B.2.3.1 Resolucao de Conflitos entre Chaves Primarias . . . . . . 79

B.2.3.2 Extracao de Chaves Primarias . . . . . . . . . . . . . . . . 80

B.2.4 Unificar Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

B.2.5 Remover Objetos nao Unificados . . . . . . . . . . . . . . . . . . . 82

B.2.6 Gerar Chaves Estrangeiras . . . . . . . . . . . . . . . . . . . . . . . 82

vi

LISTA DE FIGURAS

1.1 Funcionamento do Sistema SAI . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Exemplo de Diagrama Entidade-Relacionamento . . . . . . . . . . . . . . . 11

3.1 Estrategias de Processamento de Fontes de Dados . . . . . . . . . . . . . . 20

4.1 Grafo do Modelo Relacional em BAV . . . . . . . . . . . . . . . . . . . . . 41

4.2 Processo de Integracao que Utiliza Esquemas Compatıveis a Uniao . . . . . 46

5.1 Funcionamento do Sistema SAI . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2 Visualizacao do Sistema SAI . . . . . . . . . . . . . . . . . . . . . . . . . . 56

vii

LISTA DE TABELAS

2.1 Analogia entre o Modelo de Dados Relacional e o Modelo de Dados em Rede 13

3.1 Exemplo de Conflito de Nomes . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Exemplo de Conflito de Representacao dos dados . . . . . . . . . . . . . . 24

3.3 Exemplo de Conflito de Unidade . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4 Exemplo de Conflito de Precisao de Dados . . . . . . . . . . . . . . . . . . 25

3.5 Exemplo de Conflito de Valores Padrao . . . . . . . . . . . . . . . . . . . . 26

3.6 Exemplo de Conflito de Equivalencia de Chaves . . . . . . . . . . . . . . . 26

3.7 Exemplo de Conflito de Uniao . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.8 Exemplo de Conflito de Isomorfismo . . . . . . . . . . . . . . . . . . . . . 27

3.9 Exemplo de Conflito de Falta de Dados . . . . . . . . . . . . . . . . . . . . 28

3.10 Exemplo de Conflito entre Relacao e Atributo . . . . . . . . . . . . . . . . 28

3.11 Exemplo de Conflito entre Atributo e Dados . . . . . . . . . . . . . . . . . 29

4.1 Esquemas para o Exemplo de Integracao de Esquemas . . . . . . . . . . . 44

4.2 Exemplo de Conflito de Nomes . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3 Exemplo de Conflito de Representacao dos dados . . . . . . . . . . . . . . 48

4.4 Exemplo de Conflito de Unidade . . . . . . . . . . . . . . . . . . . . . . . . 48

4.5 Exemplo de Conflito de Precisao de Dados . . . . . . . . . . . . . . . . . . 49

4.6 Exemplo de Conflito de Valores Padrao . . . . . . . . . . . . . . . . . . . . 49

4.7 Exemplo de Conflito de Equivalencia de Chaves . . . . . . . . . . . . . . . 50

4.8 Exemplo de Conflito de Uniao . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.9 Exemplo de Conflito de Isomorfismo . . . . . . . . . . . . . . . . . . . . . 51

4.10 Exemplo de Conflito de Falta de Dados . . . . . . . . . . . . . . . . . . . . 51

4.11 Exemplo de Conflito entre Relacao e Atributo . . . . . . . . . . . . . . . . 52

4.12 Exemplo de Conflito entre Atributo e Dados . . . . . . . . . . . . . . . . . 52

6.1 Transformacoes Inversas do Formalismo HDM . . . . . . . . . . . . . . . . 74

viii

6.2 Transformacoes Adicionais do Formalismo HDM . . . . . . . . . . . . . . . 75

ix

RESUMO

O objetivo da integracao de bancos de dados e fornecer uma interface integrada e

uniforme para consultas em diversos bancos de dados que descrevam os mesmos objetos do

mundo real. O formalismo ”both as view”(BAV) foi desenvolvido de modo a ser aplicado

em esquemas de bancos de dados para realizar a sua integracao. Seu funcionamento

se caracteriza por ver o processo de integracao como uma sequencia de transformacoes

reversıveis que modificam tanto o esquema como as instancia do banco de dados. Este

trabalho apresenta uma proposta de sistema de software que automatiza parcialmente

o processo de integracao, auxiliando o administrador de banco de dados na tarefa de

integracao, guiando-o pelo processo de gerar transformacoes e consultando-o em momentos

em que seja impossıvel para o sistema tomar uma decisao. Alem disso sao apresentados

estudos realizados sobre o formalismo BAV e sua aplicacao nos casos de conflito entre

esquemas de bancos de dados.

x

ABSTRACT

The objective of the database integration is to supply an integrated uniform interface

to consultations in diverse databases that describe same objects of the real world. The

formalism ”both view”(BAV) was developed in order to be applied in schemas during

the process of databases integration. Its functionality characterizes for seeing the inte-

gration process as a sequence of reversible transformations that modify the schema and

the instances of the data base. This work presents a proposal of system software that

automatizes the integration process partially, assisting the user in the integration process,

guiding him to generate transformations and consulting it at moments where the system

can not take a decision. Moreover are presented studies about the BAV formalism and

its applications in the cases of conflict between database schemas.

1

CAPITULO 1

INTRODUCAO

Um banco de dados e construıdo com o objetivo de armazenar informacoes de um

modo estruturado permitindo consultas rapidas e eficazes sobre as mesmas. O esquema

de um banco de dados representa o modo como ele guarda as informacoes. Suas instancias

sao as informacoes propriamente ditas.

Um dos maiores objetivos da integracao de dados e fornecer uma interface integrada e

uniforme para consultas em diversos bancos de dados que descrevam os mesmos objetos do

mundo real. Assim um sistema de integracao de dados possibilita ao usuario se concentrar

no que ele deseja sem ter de pensar em como conseguir essa informacao.

Desse modo a integracao de bancos de dados e o processo que toma como entrada

um conjunto de bancos de dados e produz como saıda uma unica descricao dos esquemas

dos bancos de dados de entrada (esquema integrado) e um mapeamento das informacoes

associadas que permita o acesso as informacoes existentes nos bancos de dados de entrada

atraves do esquema integrado.

O estudo do processo de integracao de bancos de dados nas suas diversas formas de

abordagem e realizacao foi feito, entre outros, por C. Parent e S. Spaccapietra em [18] e

por C. Batini, M. Lenzerini e S. B. Navathe em [2]. Eles dividiram o processo em fases

conforme suas necessidades ou preocupacoes sugerindo as tecnicas mais utilizadas para a

sua resolucao. De modo sucinto, essas fases podem ser apresentadas como:

• consideracoes iniciais - fase onde os esquemas a serem integrados sao transformados

de modo a se tornarem sintaticamente e semanticamente mais homogeneos;

• pre-integracao - consiste de uma analise dos esquemas a serem integrados com o

objetivo de escolher uma polıtica de integracao eficiente, definindo, entre outras

coisas, quais esquemas serao integrados e em que ordem ou se serao integrados

apenas pedacos dos esquemas ao inves do esquema inteiro;

2

• identificacao de correspondencias - fase onde as correspondencias entre os esquemas

sao identificadas e descritas;

• identificacao de conflitos - fase onde os esquemas sao analizados e comparados para

determinar as correspondencias entre conceitos e detectar possıveis conflitos (con-

flitos de tipo, estrutura, etc.);

• integracao - fase onde os conflitos entre os esquemas sao resolvidos e os itens corres-

pondentes sao unificados;

• uniao e reestruturacao - nesta fase sao gerados esquemas integrados intermediarios,

para analise e se necessario, uma reestruturacao para que se alcance qualidades

desejaveis como completude, corretude, minimalidade e entendibilidade.

Os casos de conflito recebem uma atencao especial neste trabalho, uma vez que a

identificacao e a resolucao dos mesmos esta entre os maiores desafios encontrados pelo

processo de integracao de bancos de dados. Os casos de conflito existentes podem ser

divididos em conflitos de incompatibilidade de domınio e conflitos entre definicoes de

entidades, sendo listados a seguir:

• conflito de nomes - ocorre quando dois objetos semanticamente equivalentes pos-

suem nomes diferentes ou quando dois objetos sem nenhuma equivalencia semantica

possuem nomes iguais;

• conflito de representacao dos dados - ocorre quando dois objetos semanticamente

equivalentes sao representados por diferentes tipos de dados;

• conflito de unidades - ocorre quando dois objetos semanticamente equivalentes sao

representados em diferentes unidades ou medidas;

• conflito de precisao dos dados - ocorre quando dois atributos que sao semantica-

mente parecidos sao representados com diferentes unidades e medidas de modo a

nao ocorrer uma correspondencia de um para um entre os respectivos domınios;

3

• conflito de valores padrao - ocorre quando em um atributo passa a ter um valor

especıfico quando nao e indicado um valor para ele;

• conflito de equivalencia de chaves - ocorre quando duas entidades semanticamente

parecidas sao definidas com identificadores semanticamente diferentes;

• conflito de uniao - ocorre quando dois objetos semanticamente equivalentes sao

representados com um numero diferente de atributos ou com atributos nao rela-

cionados de modo que a uniao entre eles nao e compatıvel;

• conflito de isomorfismo - ocorre quando um numero diferente de atributos e utilizado

para representar conceitos similares;

• conflito de falta de atributos - ocorre quando o atributo que falta pode ser recuperado

atraves de mecanismos de inferencia;

• conflito entre relacoes e atributos - ocorre quando o mesmo objeto e modelado como

um atributo em um esquema e como uma relacao em outro esquema;

• conflito entre atributos e dados - ocorre quando o valor de um atributo em um

esquema corresponde ao proprio atributo em outro esquema.

De modo a permitir que o sistema de integracao de banco de dados possa responder

as consultas, deve haver alguma descricao do relacionamento entre o esquema global e os

esquemas locais. O processador de consultas deve estar apto a reformular uma consulta

submetida a ele como novas consultas submetidas aos esquemas locais [9]. Dois forma-

lismos de grande importancia para a integracao de bancos de dados sao os formalismos

”global as view”(GAV) e ”local as view”(LAV). No formalismo GAV, para cada relacao

pertencente ao esquema global, escreve-se uma consulta sobre os esquemas locais especi-

ficando como obter as instancias destinadas a essa relacao. Ja no formalismo LAV cada

uma das relacoes das fontes e descrita atraves de consultas sobre o esquema global.

Atraves da parceria de pesquisas realizada pela Universidade de Birkbeck (Birkbeck

University of London) e pela Universidade Imperial (Imperial College of London) foi cri-

ado o Projeto de Geracao Automatica de Ferramentas Mediadoras para Integracao de

4

Bancos de Dados Heterogeneos (Automatic Generation of Mediator Tools for Heteroge-

neous Database Integration - AutoMed) [3].

No AutoMed as linguagens de modelagem para bancos de dados sao representadas

atraves de um modelo de dados baseado em hipergrafos (HDM) [12]. A metodologia

utilizada pelo projeto AutoMed se caracteriza por ver o processo de integracao como uma

sequencia de transformacoes reversıveis que modificam tanto o esquema como a extensao

do banco de dados. Essa sequencia de transformacoes incrementalmente adiciona, apaga

ou renomeia um objeto do esquema do banco de dados ate que se possa mapear diversos

esquemas de bancos de dados uns com os outros.

O formalismo both as view (BAV) [13, 14, 11] foi desenvolvido a partir do formalismo

HDM e dos formalismos GAV e LAV e desenvolvido de modo a ser aplicado em esquemas

que usem o modelo de dados relacional.

Do mesmo modo que o formalismo HDM, o formalimo BAV se caracteriza por trans-

formacoes aplicadas em sequencia onde cada uma adiciona, retira ou renomeia um objeto

do formalismo. Alem disso sao especificadas operacoes de extend e contract que respectiva-

mente adicionam ou retiram objetos do formalismo especificando a consulta que determina

a origem das instancias apenas parcialmente ou ate mesmo nao as especificando.

O Projeto AutoMed possui diversas metodologias para realizar a integracao de dados

atraves do formalismo BAV. Todas elas se caracterizam por produzir sequencias de trans-

formacoes aplicadas tanto no esquema quanto nas instancias de cada uma das fontes de

dados. Duas metodologias se destacam por serem as mais utilizadas.

A primeira metodologia [13] se destaca por uma postura mais artesanal, direcionada

a casos especıficos onde nao se pretende adicionar ou retirar fontes de dados do processo

de integracao apos seu termino. Esta metodologia da grande enfase a completude do

processo de integracao, incentivando a ideia de que toda as informacoes das fontes de

dados locais devem estar no banco de dados global. Costuma ser utilizada, por exemplo,

em casos onde grandes corporacoes precisam integrar bancos de dados muito extensos.

A segunda metodologia [11] se destaca por uma postura de trabalho como a de uma

linha de montagem. Por um lado e mais flexıvel, uma vez que e razoavelmente facil adi-

5

cionar ou retirar fontes de dados ao processo de integracao mesmo apos seu termino. Por

outro lado a completude do processo de integracao e ignorada uma vez que normalmente

nem todas as informacoes das fontes de dados locais estarao presentes no banco de dados

global. Costuma ser utilizada, por exemplo, em casos em que existe a necessidade de

integrar muitos bancos de dados de tamanho reduzido como locadoras ou escolas.

1.1 Objetivos

O objetivo desta dissertacao e apresentar uma proposta de sistema de software para

integracao de bancos de dados atraves do formalismo BAV.

Este sistema de software e aplicado na metodologia de integracao que aplica o forma-

lismo nas fontes de dados como se estas estivessem em uma linha de montagem. Nessa

metodologia assume-se um esquema de uniao e cada esquema local tera de se tornar

compatıvel a uniao com o esquema assumido por meio de transformacoes BAV.

O objetivo deste sistema de software e auxiliar o usuario na geracao das transformacoes

BAV que tornarao a estrutura de um esquema local identica ao esquema de uniao. Para

alcancar esse objetivo o sistema orienta o usuario atraves das varias etapas do processo

consultando-o em momentos em que seja impossıvel para o sistema tomar uma decisao.

De modo sucinto, o que se espera do funcionamento do sistema de software proposto

neste trabalho e que sejam fornecidos para ele dois esquemas, o primeiro relativo a um

banco de dados local e o segundo relativo ao esquema de uniao definido para a integracao.

A medida que realiza diversas consultas ao usuario o software deve fornecer a sequencia

de transformacoes necessaria para tornar a estrutura do esquema relativo ao banco de

dados local identica a estrutura do esquema de uniao. A figura 1.1 ilustra esse processo

mais nitidamente. Baseado nessas caracterısticas de funcionamento o sistema de software

foi batizado como: Sistema de Software para Auxilio na Geracao de Transformacoes BAV

para Integracao de Bancos de Dados, abreviado atraves da sigla SAI.

6

Figura 1.1: Funcionamento do Sistema SAI

1.2 Organizacao

Esta dissertacao esta organizada em seis capıtulos divididos conforme seus objetivos.

O capıtulo dois apresenta uma breve introducao aos bancos de dados, apresentando

conceitos basicos utilizados no decorrer da dissertacao.

O capıtulo tres descreve o estudo da integracao de dados, dividindo-o em fases, apon-

tando seus problemas e mostrando alguns formalismos utilizados para sua resolucao.

O capıtulo quatro descreve o projeto AutoMed, o formalismo baseado em hipergrafos,

o formalismo BAV, suas metodologias, a linguagem utilizada por esses formalismos para

descrever consultas e um estudo feito nesta dissertacao sobre como o formalismo BAV

pode resolver cada um dos casos de conflito.

O capıtulo cinco expoe a proposta do sistema de software SAI, o objetivo desta dis-

sertacao.

O capıtulo seis conclui esta dissertacao, expondo resultados, contribuicoes e projetos

futuros.

Existem ainda dois anexos acompanhando este trabalho. O anexo A define mais

formalmente o formalismo baseado em hipergrafos. O anexo B contem especificacoes

informais de cada uma das etapas do sistema de software SAI.

7

CAPITULO 2

BANCOS DE DADOS

E necessario apresentar de modo breve e sucinto a tecnologia de bancos com o objetivo

de tornar termos utilizados neste trabalho mais claros. Este capıtulo foi baseado em

[24, 25, 1, 26, 22].

2.1 Sistema Gerenciador de Bancos de Dados

Para entender o funcionamento de um sistema gerenciador de bancos de dados e

necessario ter em mente o ambiente em que ele atua e suas necessidades. Imagine uma

grande empresa ou industria, como uma fabrica de automoveis por exemplo. Tal fabrica

possui uma grande quantidade de dados que precisam ser mantidos por um longo perıodo

de tempo. Entre outras informacoes estao fornecedores, estoque, clientes, setores, empre-

gados, producao, contratos, etc. Essas informacoes se relacionam entre si e como possıveis

relacionamentos estao as entregas (quais clientes receberam carros de quais lotes), a lista

de compras (quanto comprar de cada fornecedor para manter o estoque constante), dis-

tribuicao dos empregados (quais empregados trabalham em quais setores), etc.

Dados como esses que sao armazenados mais ou menos permanentemente em um

computador sao chamados de Bancos de Dados. O software que permite que uma ou mais

pessoas usem e/ou modifiquem esses dados e chamado de Sistema Gerenciador de Bancos

de Dados (Database Management System - DBMS). A principal funcao de um DBMS e

permitir que o usuario manipule os dados de uma forma abstrata ao inves de manipular os

dados na forma como sao armazenados no computador. Nesse sentido o DBMS age como

um interpretador para uma linguagem de programacao de alto nıvel, permitindo que o

usuario especifique o que precisa ser feito, com pouca ou nenhuma atencao aos algorıtmos

e representacoes de dados utilizados pelo sistema.

8

2.2 Esquemas e Instancias

Durante a fase de criacao de um banco de dados o foco de interesse esta no objetivo

final do banco de dados. Ja na fase de utilizacao o foco de interesse esta nas informacoes

que ele contem. Os dados contidos em um banco de dados mudam frequentemente mas

seu objetivo final continua o mesmo por longos perıodos de tempo (apesar de nao durar

para sempre em alguns casos).

Os termos esquema ou intencao sao usados para referenciar os objetivos do banco de

dados expressos como uma enumeracao dos tipos de entidades com os quais o banco de

dados ira lidar e os relacionamentos entre elas. Ja o conteudo de um banco de dados e

chamado de instancia ou extensao do banco de dados.

2.3 Modelos de Dados

Um Modelo de Dados (Data Model) e um formalismo matematico composto de duas

partes: uma notacao para descrever os dados e um conjunto de operacoes para manipular

esses dados.

Existe uma grande quantidade de modelos de dados em uso atualmente. Cada um

deles com caracterısticas e objetivos especıficos. Entre as qualidades mais relevantes que

diferenciam modelos de dados uns dos outros estao:

• proposito;

• orientacao a objetos ou valores;

• capacidade de lidar com redundancia;

• capacidade de lidar com relacionamentos de alta cardinalidade (muitos-para-muitos).

2.3.1 O Modelo Entidade-Relacionamento

O proposito do modelo entidade-relacionamento e permitir a descricao do esquema

conceitual sem preocupacoes com a eficiencia do sistema, com a estrutura fısica do banco

de dados ou ate mesmo com o DBMS como seria esperado na maioria dos modelos.

9

Esse modelo de dados carece de um conjunto de operacoes sobre seus dados. De

certo modo pode-se afirmar que ele nao e um modelo de dados completo por definicao.

Apesar disso esse modelo mostra sua utilidade ao ser usado para justificar os tipos de

estruturas e modelos de dados que venham a ser utilizados posteriormente na fase de

implementacao. Este modelo tambem pode se mostrar muito pratico quando existe a

necessidade de consultar o usuario sobre assuntos relativos ao projeto.

Uma entidade representa algo que exista e seja distinguıvel, sendo possıvel diferenciar

um elemento de outro, como por exemplo uma pessoa, um carro ou uma loja. Um conjunto

de entidades consiste de um grupo de entidades similares, como o conjunto de todas as

pessoas, todos os carros ou todas as lojas de uma regiao.

Conjuntos de entidades possuem propriedades, chamadas atributos, que associam para

cada entidade do conjunto um valor pertencente a um domınio de valores. Normalmente

o domınio de valores para um atributo sera o conjunto dos inteiros, reais ou strings

de caracteres, apesar de que outros tipos de domınios de valores tambem podem ser

utilizados. Uma conjunto de entidades que representam pessoas podem possuir atributos

como nome ou peso, por exemplo.

O conjunto de atributos cujos valores identificam de modo unico cada entidade sao

chamados de atributos chaves. Cada conjunto de entidades deve possuir um conjunto de

chaves de modo a se distinguir uma entidade especıfica em um conjunto de entidades.

Um possıvel exemplo de chave para o conjunto de entidades pessoa seria um identificador

unico como o CPF ou o RG.

O termo ISA, utilizado na forma A ISA B quando A e B forem conjuntos de entidades,

identifica B como uma generalizacao de A, ou seja, A e um tipo especial de B. Nesse

caso, A herda todos os atributos de B, mas possui atributos proprios que B nao possui.

O conjunto de chaves de A e o mesmo de B de modo que seus valores para entidades

correspondente em A e B seja igual. Possıveis exemplos para a generalizacao veıculos

seriam carros ou motocicletas.

Diferentes conjuntos de entidades geralmente nao tem utilidade em isolamento uns

dos outros. Eles sao associados uns aos outros atraves de relacionamentos. Por exemplo,

10

pessoas possuem carros ou pessoas trabalham em lojas.

Relacionamentos costumam ser classificados de acordo com o numero de entidades

de dois conjuntos de entidades que se relacionam entre si. Existem tres classificacoes

possıveis: um-para-um, que sao os mais simples e mais raros, um-para-muitos e muitos-

para-muitos.

Diagramas entidade-relacionamentos sao utilizados para resumir todo o trabalho de

uma maneira facil de apresentar e entender. Estes diagramas utilizam a seguinte metodolo-

gia:

• entidades sao representadas por retangulos;

• relacionamentos sao representados por losangos que sao ligados aos retangulos atraves

de retas nao direcionadas;

• atributos sao representados por cırculos que sao ligados aos retangulos ou losangos

atraves de retas nao direcionadas;

• os nomes dos atributos sao sublinhados quando eles forem chaves;

Um exemplo de diagrama entidade-relacionamento e apresentado na figura 2.1.

2.3.2 O Modelo de Dados Relacional

Desde sua apresentacao em 1970, o modelo de dados relacional tem crescido em im-

portancia ate se tornar o modelo de dados mais utilizado no mundo para implementar

novos bancos de dados. Provavelmente a maior razao da sua popularidade e a maneira

como ele suporta poderosas, apesar de simples, linguagens declarativas atraves das quais

as operacoes sobre os dados sao expressas.

O fato desse modelo de dados ser orientado a valor permite que se possa definir

operacoes sobre relacoes cujos resultados sao tambem relacoes. Desse modo estas operacoes

podem ser combinadas sequencialmente em cascata utilizando a notacao chamada de

algebra relacional.

11

Figura 2.1: Exemplo de Diagrama Entidade-Relacionamento

O conceito matematico no qual reside o modelo de dados relacional e o da teoria de

conjuntos. Uma relacao e qualquer subconjunto do produto cartesiano entre um ou mais

domınios. Por exemplo, {(0, a), (0, c), (1, b)} e uma relacao, um subconjunto de D1xD2

para D1 = {0, 1} e D2 = {a, b, c}. Cada um dos membros de uma relacao e denominado

tupla, cada um dos membros de uma tupla e denominado atributo e o numero de membros

de uma tupla em uma relacao e denominado aridade. E importante lembrar que uma

vez que cada atributo recebe um nome a ordem dos atributos em uma relacao perde a

importancia. Por outro lado, tambem e muito comum imaginar uma relacao como uma

tabela, onde cada linha e uma tupla e cada coluna e um componente da tupla, um atributo.

Tal como conjuntos de entidades no modelo entidade-relacionamento, relacoes tambem

possuem atributos que funcionam como chaves no modelo relacional. Tais atributos sao

chamados de chaves primarias (primary keys - PK).

As operacoes utilizados para manipulacao dos dados no modelo relacional sao:

• uniao - representada por R∪ S, toma duas relacoes R e S e devolve o conjunto das

tuplas que estao em R, em S ou em ambas. Esta operacao so pode ser realizada em

relacoes que possuam a mesma aridade;

12

• diferenca - representada por R− S, toma duas relacoes R e S e devolve o conjunto

das tuplas que estao em R mas nao estao em S. Esta operacao so pode ser realizada

em relacoes que possuam a mesma aridade;

• projecao - dada uma relacao R, essa operacao remove e/ou reordena seus atributos

gerando uma nova relacao;

• selecao - esta operacao testa para cada tupla na relacao R uma expressao logica L

e devolve na forma de uma relacao todas a tuplas para as quais L seja verdadeiro.

• produto cartesiano - representada por R⊗S, toma duas relacoes R e S, com aridade

k1 e k2 respectivamente, e devolve o conjunto de todas as possıveis tuplas com

aridade k1+k2 cujos primeiros k1 elementos pertencam a R seguidos por k2 elementos

pertencentes a S;

A partir das operacoes citadas pode-se construir varias outras operacoes. Entre elas

estao as operacoes de quociente, join, join natural, etc.

2.3.3 Outros Modelos de Dados

2.3.3.1 O Modelo de Dados em Rede

Informalmente pode-se definir o modelo de dados em rede como o modelo entidade-

relacionamento tendo todos os seus relacionamentos restritos a serem binarios ou um para

muitos. Esses relacionamentos sao chamados de links no modelo de dados em rede. No

lugar de conjuntos de entidades o modelos de dados em rede oferece tipos de registros

logicos. Tipos de registros logicos sao compostos de campos nos quais valores elementares

como inteiros ou strings de caracteres sao guardados. O conjunto de nomes para esses

campos e seus tipos de dados e chamado de formato do registro logico.

Pode-se ver uma analogia entre os termos utilizados no modelo relacional e os termos

utilizados no modelo de dados em rede na tabela 2.1.

Contudo ha uma importante distincao a ser feita entre os dois modelos. Como o

modelo de dados relacional e orientado a valor duas tuplas exatamente iguais com os

13

Modelo em Rede Modelo RelacionalFormato do Registro Logico Esquema da RelacaoTipo de Registro Logico Nome da RelacaoRegistro Logico Tupla

Tabela 2.1: Analogia entre o Modelo de Dados Relacional e o Modelo de Dados em Rede

mesmos valores para todos os atributos sao vistas como a mesma tupla. Ja o modelo de

dados em rede e orientado a objeto, desse modo todo registro logico possui um identificador

transparente que e o seu endereco e mesmo que dois registros logicos sejam iguais em todos

os seus campos eles nao sao vistos como sendo o mesmo registro logico.

A utilizacao de links no modelo de dados em rede permite a construcao de um grafo

direcionado chamado de rede. Esse grafo nao e nada mais que um modelo simplificado do

diagrama entidade-relacionamento que tem como objetivo representar os tipos de registros

e seus links.

2.3.3.2 O Modelo de Dados Hierarquico

O modelo de dados hierarquico e composto por uma colecao de registros conectados uns

aos outros atraves de links de maneira similar ao modelo de dados em rede. Na verdade

pode-se afirmar que o modelo de dados hierarquico e um modelo de dados em rede no

qual o grafo resultante lembra um floresta (um conjunto de arvores). Isto e obtido com a

construcao de um vertice virtual para cada arvores do modelo. Este vertice tem a funcao

de ser a raiz da arvore do banco de dados. Ao contrario do modelo de dados em rede, os

links no modelo de dados hierarquico sao direcionados de pai para filho restringindo os

caminhos possıveis na arvore.

2.3.3.3 O Modelo de Dados Orientado a Objeto

Ao contrario do que se possa pensar, nao existe apenas uma mas varias propostas e

implementacoes do que deveria ser um modelo de dados orientado a objeto. Apesar da

variacao de nomes que eles possam ter (tais como semantico, funcional, etc.) eles reunem

caraterısticas em comum. Sao elas:

14

• identidade dos objetos - os elementos trabalhados sao registros com um endereco

unico, seguindo a linha dos modelos de dados hierarquico e em rede;

• objetos complexos - e permitida a construcao de novos tipos a partir de tipos nativos;

• hierarquia de tipos - e permitido que tipos tenham subtipos com propriedades es-

peciais.

A ideia basica por traz do modelo de dados orientado a objeto e a de encapsular dados

e codigo relacionados a um objeto em uma simples unidade. Como resultado disso toda a

interacao entre um objeto e o resto do sistema e feita atraves de mensagens. Geralmente

um objeto e composto por um conjunto de variaveis que contem os dados relativos ao

objeto, um conjunto de mensagens para os quais o objeto esta programado a responder e

um conjunto de metodos que implementam e respondem as mensagens.

Objetos similares, ou seja, que atendem as mesmas mensagens, usam os mesmos

metodos e possuem variaveis com nomes e tipos identicos, sao agrupados de modo a

formar uma classe. E cada ocorrencia da classe e chamada de instancia da classe.

O conceito de hierarquia de classes permite que uma classe possua um conjunto de

subclasses (ou classes filhas) que herdam todas as propriedades da classe pai e possuem

caracterısticas proprias referentes apenas a elas.

Se for feita uma comparacao com o modelo de dados entidade-relacionamento, um

objeto corresponderia a uma entidade, uma classe corresponderia a um conjunto de en-

tidades, uma subclasse corresponderia a uma generalizacao do tipo ISA e uma variavel

corresponderia a um atributo.

2.4 Bancos de Dados Distribuıdos

Um banco de dados distribuıdos possui seus dados dispersos e/ou replicados em varios

locais. Computadores diferentes controlam o acesso a diferentes partes dos dados e as

maquinas utilizadas para gerar a inteface com o usuario podem nao ser as mesmas que

fazem o acesso aos dados. Estes computadores costumam estar ligados por links de

comunicacao que geralmente possuem uma baixa velocidade em comparacao com o resto

15

do sistema. Consequentemente esses links se tornam o gargalo dos bancos de dados

distribuıdos e a maior parte dos trabalhos e pesquisas relativos a essa area contribuem

com diferentes formas de lidar com esse gargalo.

As relacoes se dividem em dois tipos: relacoes logicas, que nao existem de verdade

e sao construıdas virtualmente pela uniao de fragmentos de relacoes, e relacoes reais,

tambem chamadas de relacoes fısicas que constituem os proprios fragmentos de relacoes.

2.5 Conclusao

Nesse capıtulo foram apresentados conceitos da tecnologia de banco de dados com o

objetivo de familiarizar o leitor com o restante do trabalho apresentado nesta dissertacao.

No restante deste trabalho serao apresentados conceitos da integracao de bancos de da-

dos bem como formalismos e metodologias que tentam diagnosticar e resolver o problema

da integracao.

Por fim sera apresentada um sugestao de projeto de sistema de software para auxiliar

o processo de integracao atraves da automatizacao parcial.

16

CAPITULO 3

INTEGRACAO DE BANCOS DE DADOS

Um dos maiores objetivos da integracao de dados e fornecer uma interface integrada e

uniforme para consultas em diversas fontes de dados que descrevam os mesmos objetos do

mundo real. Assim um sistema de integracao de dados possibilita ao usuario se concentrar

no que ele deseja sem ter de pensar em como conseguir essa informacao. O usuario se ve

livre da tarefa de descobrir quais fontes de dados contem as informacoes relevantes, fazer

o acesso e combinar os resultados em uma unica resposta.

Existem muitas situacoes que utilizam as tecnologias de integracao de bancos de dados.

Um bom exemplo sao organizacoes que a medida que evoluem precisam aumentar a sua

estrutura criando novas unidades, cada uma delas com funcoes e localizacoes distintas.

Normalmente essas novas unidades precisarao de uma parte ou ate mesmo de todos os

dados de cada uma das unidades ja existentes.

Por esse motivo a interoperabilidade entre os dados dessas fontes se torna cada vez

mais crucial para a obtencao de informacoes relevantes. Existem varios graus de interop-

erabilidade, desde gateways que permitem a comunicacao de um par especıfico de DBMS

(sistemas gerenciadores de bancos de dados) ate sistemas de softwares que criam visoes

persistentes sobre varias fontes de dados sem se importar em conciliar as restricoes ja

existentes sobre os dados de cada uma das fontes. Mas a interoperabilidade completa so

pode ser alcancada por bancos de dados distribuıdos ou federados porque eles permitem

a uniao dos dados em um unico banco de dados virtual.

Um banco de dados distribuıdo possui seus dados espalhados por varios locais em uma

rede (muitas vezes ate mesmo replicados em mais de um local da rede) de modo a facilitar

seu acesso. Ja os bancos de dados federados denotam um conjunto de fontes de dados

locais que compartilham suas informacoes de modo explıcito atraves da exportacao de

esquemas. Esses esquemas definem o que deve ser compartilhado de cada fonte. O que

17

difere sistemas de bancos de dados federados de sistemas de bancos de dados distribuıdos

e que no primeiro as fontes de dados foram criadas independentemente umas das outras

e continuam funcionando de maneira autonoma.

De um modo mais formal, a integracao de bancos de dados e o processo que toma

como entrada um conjunto de bancos de dados e produz como saıda uma unica descricao

dos esquemas dos bancos de dados de entrada (esquema integrado) e um mapeamento

das informacoes associadas que permita o acesso as informacoes existentes nos bancos de

dados de entrada atraves do esquema integrado.

3.1 Fases da Integracao de Bancos de Dados

O estudo do processo de integracao de bancos de dados nas suas diversas formas de

abordagem e realizacao foi feito, entre outros, por C. Parent e S. Spaccapietra em [18] e

por C. Batini, M. Lenzerini e S. B. Navathe em [2]. Eles dividiram o processo em fases

conforme suas necessidades ou preocupacoes sugerindo as tecnicas mais utilizadas para a

sua resolucao. Assim nem todas as fases que aparecem aqui foram definidas pelo mesmo

autor ou pelo mesmo trabalho. Na verdade foi feita uma compilacao dos trabalhos pelo

autor desta dissertacao de modo a se obter uma nova e mais completa divisao das fases

da integracao de bancos de dados. Essas fases sao:

• consideracoes iniciais - fase onde os esquemas a serem integrados sao transformados

de modo a se tornarem sintaticamente e semanticamente mais homogeneos;

• pre-integracao - consiste de uma analise dos esquemas a serem integrados com o

objetivo de escolher uma polıtica de integracao eficiente, definindo, entre outras

coisas, quais esquemas serao integrados e em que ordem ou se serao integrados

apenas pedacos dos esquemas ao inves do esquema inteiro;

• identificacao de correspondencias - fase onde as correspondencias entre os esquemas

sao identificadas e descritas;

• identificacao de conflitos - fase onde os esquemas sao analizados e comparados para

18

determinar as correspondencias entre conceitos e detectar possıveis conflitos (con-

flitos de tipo, estrutura, etc.);

• integracao - fase onde os conflitos entre os esquemas sao resolvidos e os itens corre-

spondentes sao unificados;

• uniao e reestruturacao - nesta fase sao gerados esquemas integrados intermediarios,

para analise e se necessario, uma reestruturacao para que se alcance qualidades

desejaveis, como:

– completude e corretude - a base de dados integrada precisa apresentar de forma

correta todas as informacoes que estao nas fontes de dados locais;

– minimalidade - quando uma mesma informacao for representada em mais de

uma das fontes de dados locais, devera aparecer apenas uma vez na base de

dados integrada;

– entendibilidade - o esquema integrado devera ser facil de entender, tanto para

o administrador quanto para o usuario final.

3.1.1 Consideracoes Iniciais

Um pre-requisito para a integracao de bancos de dados e uma visualizacao comum

do funcionamento de todas as fontes de dados a serem integradas, tornando-as o mais

homogeneas possıvel para comparacoes futuras.

Uma vez que pesquisadores da area de integracao de banco de dados assumem que

todos os bancos de dados utilizam o mesmo modelo de dados comum (common data model

- CDM), o trabalho de traducao se torna um pre-requisito da integracao e e tratado como

um problema a parte. Infelizmente a quantidade de solucoes que facam a traducao de um

CDM para outro automaticamente ainda e muito escassa.

Um problema que gera muita polemica e a escolha do CDM para o esquema integrado.

Muitos pesquisadores sao favoraveis ao modelo orientado a objeto, uma vez que contem

em si todos os conceitos dos outros modelos de dados e seus metodos podem ser usados

19

para implementar regras especıficas de mapeamento. Em contrapartida, quanto mais rico

e o modelo mais complexo se torna o processo de integracao porque mais discrepancias

irao surgir devido as escolhas dos diferentes modelos de dados das fontes.

Para simplificar a integracao deve-se escolher um CDM com o mınimo de semantica,

onde as estruturas de dados sejam trazidas a estruturas elementares sem alternativas de

modelagem, como os modelos de relacionamentos binarios.

Deve ficar claro que a modelagem dos dados nao e um processo determinıstico. O rela-

tivismo semantico (onde cada desenvolvedor aplica a sua perspectiva ao criar o esquema)

e o preco a se pagar pela riqueza semantica do modelo de dados a disposicao.

3.1.2 Pre-Integracao

Para qualquer metodologia, mesmo que ela considere uma fase de pre-integracao ou

nao, existe a necessidade de considerar a sequencia e o agrupamento das fontes de dados

de entrada (mesmo que implicitamente).

Inicialmente deve-se considerar a quantidade de fontes de dados que devem ser in-

tegradas. Espera-se que esse numero seja maior que dois mas em alguns casos o numero

exato nao e constante e existe a possibilidade de serem acrescentadas ou retiradas fontes

de dados ao processo de integracao.

A seguir deve-se escolher uma polıtica de integracao das fontes a ser seguida. A

figura 3.1 mostra quatro possıveis estrategias de processamento de fontes de dados para

integracao. Cada uma das estrategias esta representada como uma estrutura de grafos,

uma arvore. Os vertices que sao folhas representam os esquemas das fontes de dados e os

vertices que nao sao folhas representam estados intermediarios da integracao. O vertice

raiz representa o resultado final da integracao.

As estrategias binarias permitem que os esquemas sejam integrados aos pares. A

estrategia em escada permite que a cada passo do processo de integracao sejam integrado

um esquema de uma fonte de dados com um estado intermediario. A estrategia balanceada

requer que se divida as fontes de dados em pares para que a integracao seja feita de modo

simetrico. As estrategias N-Arias permitem a integracao de varios esquemas de uma vez.

20

Figura 3.1: Estrategias de Processamento de Fontes de Dados

A estrategia em um-passo e a que tem o conceito mais simples e consiste de integrar todas

as fontes de dados juntas e ao mesmo tempo. A estrategia interativa e aquela que segue

qualquer outra polıtica de integracao que nao tenha sido apresentada.

A maior vantagem das estrategias binarias esta em simplificar as atividades de com-

paracao entre esquemas dividindo-as em varios passos. Cada um desses passos analisa

apenas dois esquemas de cada vez. Pesquisas indicam que em geral a complexidade da

comparacao entre n esquemas tem um grau de complexidade de n2. Esse fato faz com que

as estrategias binarias sejam as preferidas entre as estrategias utilizadas. Mas sua maior

desvantagem esta em gerar um grande numero de passos para um numero alto de fontes

de dados.

As vantagens e desvantagens das estrategias N-Arias sao diretamente opostas as van-

tagens e desvantagens das estrategias binarias.

3.1.3 Identificacao de Correspondencias

Um banco de dados contem representacoes de objetos do mundo real. Na fase de iden-

tificacao de correspondencias a integracao de bancos de dados vai alem das representacoes

de modo a observar o que e representado ao inves de como e representado.

Dois bancos de dados possuem alguma coisa em comum se os objetos do mundo real

que eles representam possuem elementos em comum ou sao de algum modo relacionados.

Dois objetos (instancias ou valores) em dois bancos de dados correspondem um ao outro

21

se eles representam o mesmo objeto do mundo real.

Para que esse processo fique mais claro pode-se apresentar a metodologia mostrada

em [18] onde as correspondencias entre dois bancos de dados sao representadas atraves de

afirmacoes de correspondencias entre esquemas ( interschema correspondence assertion -

ICA). Um ICA se baseia nos tipos ao inves das instancias para definir correspondencias.

De um modo extremamente simples pode-se dizer que um ICA seria uma descricao de

quando e como dois objetos sao equivalentes.

Para se definir completamente um ICA deve-se obedecer quatro passos.

1. Identificar os conjuntos de elementos em cada fonte de dados que representam o

mesmo objeto do mundo real.

2. Definir que tipo de relacionamento entre conjuntos se mantem entre as extensoes

de cada uma das fontes de dados: equivalencia (≡), inclusao (⊇), intersecao (∩) ou

disjuncao (�=).

3. O sistema precisa saber como encontrar em um banco de dados o objeto (instancia ou

valor) correspondente a um determinado objeto em outro banco de dados. Portanto

cada ICA precisa definir um mapeamento entre as instancias correspondentes em

meio a diversas fontes de dados.

4. Por fim e necessario identificar atributos que estejam em ambos os conjuntos de

elementos de cada banco de dados com o objetivo de evitar duplicatas no esquema

integrado.

Infelizmente, uma vez que se trabalhe com esquema grandes e reais, o processo de

identificar todos os ICAs necessarios para a integracao nao e nem simples nem trivial.

3.1.4 Identificacao de Conflitos

A atividade fundamental dessa fase e a de identificar todos os conflitos existentes na

representacao de objetos correspondentes em esquemas diferentes.

22

Os casos de conflito existentes podem ser divididos em conflitos de incompatibilidade

de domınio e conflitos entre definicoes de entidades, sendo melhor apresentados na secao

3.2.

3.1.5 Integracao

Uma vez que todas as correspondencias tenham sido descritas a integracao pode

comecar. Cada correspondencia e analizada de modo a decidir qual representacao dos

elementos relacionados deve ser escolhida para ser incluida no esquema integrado e qual

esquema de mapeamento deve ser definido entre o esquema integrado e as fontes de da-

dos. A representacao escolhida devera se ajustar as necessidades apresentadas permitindo

a resolucao de quaisquer conflitos de dados que se apresentem e a solucao devera ser

acrescentada ao esquema de mapeamento.

Algumas vezes conflitos nao podem ser resolvidos porque surgem como resultado de

alguma discrepancia basica entre os esquemas e nesse caso a melhor solucao e o dialogo

com os usuarios e administradores para buscar um meio de contornar o problema.

A fase de integracao pode ser realizada manualmente pelo administrador do banco

de dados (database administrator - DBA) federado atraves de uma linguagem de ma-

nipulacao procedimental, declarativa ou logica. Essa fase tambem pode ser realizada

semi-automaticamente por uma ferramenta (como por exemplo a ferramenta descrita em

[23]). Nesse caso o DBA federado e responsavel apenas pelas correspondencias e pela

escolha de algumas alternativas de integracao.

Quando uma correspondencia descreve dois objetos como identicos (mesma repre-

sentacao e extensoes equivalentes) a sua integracao e simples e direta. Mas muitas vezes

existem diferencas nas extensoes ou na representacao das mesmas, os assim chamados

conflitos.

3.1.6 Uniao e Reestruturacao

Durante esta fase os mais variados tipos de operacoes sao empregados tanto nos esque-

mas das fontes de dados como nos esquemas integrados para obter qualidades desejaveis

23

como completude, corretude, minimalidade e entendibilidade. Em algumas metodologias

essa fase ja possui um prototipo do banco de dados integrado para avaliacao.

Para alcancar a completude e a corretude deve-se analisar o esquema integrado para

averiguar se todos os dados que estao nas fontes de dados estarao presentes no banco de

dados integrado de modo correto. A completude e rejeitada em muitos casos devido ao

fato de que os desenvolvedores desejam que apenas determinado subconjunto dos dados

relevante ao objetivo da integracao esteja presente no banco de dados integrado.

O objetivo da minimalidade e o de descobrir e eliminar redundancias que venham a

ocorrer. Se uma informacao esta presente em mais de uma fonte de dados ela devera

aparecer apenas uma vez no banco de dados integrado.

A entendibilidade do esquema integrado e necessaria para que usuario e administradores

possam utilizar mais facilmente o banco de dados integrado e para que futuras manutencoes

e atualizacoes possam ser realizadas. Infelizmente nao existem meios eficientes de se medir

o quanto um esquema e entendıvel ou nao, de modo que na maior parte dos casos a intuicao

termina por ser a melhor solucao.

3.2 Casos de Conflito

Pessoas diferentes veem os objetos do mundo real de formas diferentes. Portanto e

justo que usem nomes, estruturas e hierarquias diferentes uns dos outros para representar

estes objetos do mundo real. Essa situacao pode gerar diversos conflitos para a integracao

de dados.

Classificar os tipos de conflitos que podem surgir entre duas representacoes de um

mesmo objeto nao e uma tarefa simples. Definir uma metodologia que os solucione e uma

tarefa ainda mais difıcil. A classificacao e identificacao dos casos de conflito relevantes

na integracao de banco de dados apresentada aqui foi inspirada nos trabalhos de Sheth

e Kashyap [21] e W. Kim e J. Seo [8]. Tecnicas para resolucao destes casos de conflito

pertinentes a metodologia empregada nesse trabalho sao apresentadas na secao 4.6.

Para facilitar o entendimento serao apresentados alguns exemplos criados pelo autor

desta dissertacao para cada um dos casos de conflito. Os exemplos seguem modelo rela-

24

cional porque esse sera o modelo de dados mais utilizado no restante do projeto. Cada

caixa e uma relacao. O nome da relacao aparece no topo destacado em letras maiusculas.

Ao seu lado e exibido o esquema de origem da relacao. Cada um dos nomes a seguir e

um atributo da relacao. Atributos sublinhados sao atributos chaves da relacao. O tipo

do atributo aparece, quando relevante, ao lado do nome do atributo.

3.2.1 Conflitos de Incompatibilidade de Domınio

3.2.1.1 Conflitos de Nomes

Ocorre quando dois objetos semanticamente equivalentes possuem nomes diferentes ou

quando dois objetos sem nenhuma equivalencia semantica possuem nomes iguais. Uma

vez que o problema tenha sido localizado, a resolucao deste tipo de conflito e bem simples

e parecida para os dois casos. Um exemplo deste caso e definido na tabela 3.1:

ESTUDANTE (esquema 1)cpfnome

ALUNO (esquema 2)cpfnome

Tabela 3.1: Exemplo de Conflito de Nomes

3.2.1.2 Conflitos de Representacao dos Dados

Ocorre quando dois objetos semanticamente equivalentes sao representados por difer-

entes tipos de dados. Um exemplo deste caso e definido na tabela 3.2:

ALUNO (esquema 1)cpfrg (string)nome

ALUNO (esquema 2)cpfrg (inteiro)nome

Tabela 3.2: Exemplo de Conflito de Representacao dos dados

Neste exemplo o campo rg no esquema global e representado por uma string enquanto

que no esquema 2 um campo com o mesmo nome e representado por um valor numerico.

25

3.2.1.3 Conflitos de Unidade

Ocorre quando dois objetos semanticamente equivalentes sao representados em difer-

entes unidades ou medidas. Por exemplo, o tempo pode ser representado em anos em

uma base e meses em outra base. Um exemplo deste caso e definido na tabela 3.3:

PACIENTE (esquema 1)cpfnomepesoQ

PACIENTE (esquema 2)cpfnomepesoL

Tabela 3.3: Exemplo de Conflito de Unidade

Neste exemplo, pesoQ esta representado em quilos e pesoL esta representado em libras.

3.2.1.4 Conflitos de Precisao dos Dados

Ocorre quando dois atributos que sao semanticamente parecidos sao representados

com diferentes unidades e medidas de modo a nao ocorrer uma correspondencia de um

para um entre os respectivos domınios. Um exemplo deste caso e definido na tabela 3.4:

ALUNO (esquema 1)cpfnomeconceito

ALUNO (esquema 2)cpfnomenota

Tabela 3.4: Exemplo de Conflito de Precisao de Dados

Neste exemplo, o atributo conceito tem seus valores representados como A, B, C ou

D. O atributo nota tem seus valores representados como um numero inteiro de 0 a 100.

3.2.1.5 Conflitos de Valores Padrao

Este e um tipo muito peculiar de conflito. Ocorre quando em um atributo passa a ter

um valor especıfico quando nao e indicado um valor para ele. Um exemplo deste caso e

definido na tabela 3.5:

26

PESSOAL (esquema 1)cpfnometitulo

PESSOAL (esquema 2)cpfnometitulovp

Tabela 3.5: Exemplo de Conflito de Valores Padrao

Neste exemplo, o atributo titulo tem seus valores representados por ESTUDANTE,

PROFESSOR ou FUNCIONARIO. No esquema 2 o atributo titulovp funciona da mesma

forma, mas quando seu valor for ESTUDANTE, a ocorrencia sera representada com o

valor VOID (NULL).

3.2.2 Conflitos entre Definicoes de Entidades

3.2.2.1 Conflitos de Equivalencia de Chaves

Ocorre quando duas entidades semanticamente parecidas sao definidas com identifi-

cadores (chaves primarias) semanticamente diferentes. A resolucao deste problema pode

ser alcancada se for possıvel definir um mecanismo de mapeamento entre os identifi-

cadores. Nesse caso o problema geralmente se reduz a um conflito de unidades. Caso nao

seja possıvel encontrar uma funcao de mapeamento ou mesmo um identificador comum

nao sera possıvel realizar a integracao de modo satisfatorio. Um exemplo deste caso e

definido na tabela 3.6:

ALUNO (esquema 1)cpfrgnome

ALUNO (esquema 2)rgcpfnome

Tabela 3.6: Exemplo de Conflito de Equivalencia de Chaves

Este e um caso simples, onde o identificador do esquema global e um atributo no

esquema local e vice-versa, onde a funcao de mapeamento pode ser facilmente obtida.

Existem muitos casos onde a solucao nao pode ser alcancada tao simplesmente.

27

3.2.2.2 Conflitos de Uniao

Ocorre quando dois objetos semanticamente equivalentes sao representados com um

numero diferente de atributos ou com atributos nao relacionados de modo que a uniao

entre eles nao e compatıvel. Um exemplo deste caso e definido na tabela 3.7:

ALUNO (esquema 1)cpfnomerg

ALUNO (esquema 2)cpfnomealtura

Tabela 3.7: Exemplo de Conflito de Uniao

Neste exemplo, o atributo rg existe no esquema 1 mas nunca existiu no esquema 2. Ja

o atributo altura existe no esquema 2 mas nao existe no esquema 1.

3.2.2.3 Conflitos de Isomorfismo

Ocorre quando um numero diferente de atributos e utilizado para representar con-

ceitos similares. Deve-se entao definir uma funcao de mapeamento entre os atributos de

um esquema e os atributos de outro. Um exemplo deste caso e definido na tabela 3.8:

ALUNO (esquema 1)cpfnomecompleto

ALUNO (esquema 2)cpfnomesobrenome

Tabela 3.8: Exemplo de Conflito de Isomorfismo

Neste exemplo, o esquema 1 guarda o nome dos aluno no atributo nomecompleto

enquanto que no esquema 2 o mesmo conceito e armazenado nos atributos nome e so-

brenome.

3.2.2.4 Conflitos de Falta de Atributos

A maior parte dos casos onde isso pode ocorrer ja foi mostrado neste capıtulo. Mas

existe um caso em especial onde o atributo que falta pode ser recuperado atraves de

28

mecanismos de inferencia. Um exemplo deste caso e definido na tabela 3.9:

ALUNO (esquema 1)cpfnometipo

ALUNOGRAD (esquema 2)cpfnome

Tabela 3.9: Exemplo de Conflito de Falta de Dados

Neste exemplo, o esquema 1 guarda alunos de todos os tipos (graduacao, pos-graduacao,

etc.). Ja o esquema 2 guarda apenas os alunos de graduacao. Apesar do atributo tipo nao

estar presente no esquema local, ele pode ser facilmente deduzido atraves de inferencia

uma vez que todos os alunos obtidos do banco de dados representado pelo esquema 2

serao alunos da graduacao.

3.2.2.5 Conflitos entre Relacoes e Atributos

Ocorre quando o mesmo objeto e modelado como um atributo em um esquema e como

uma relacao em outro esquema. Um exemplo deste caso e definido na tabela 3.10:

ALUNO (esquema 1)cpfnomeidadeorientador

ALUNO (esquema 2)cpfnomeidade

ALUNOPG (esquema 2)cpforientador

Tabela 3.10: Exemplo de Conflito entre Relacao e Atributo

Neste exemplo, o esquema 1 guarda todas as informacoes sobre todos os alunos na

mesma tabela. Ja o esquema 2 guarda as informacoes gerais sobre os alunos em uma

tabela e informacoes especıficas sobre alunos da pos-graduacao em outra tabela.

3.2.2.6 Conflitos entre Atributos e Dados

Ocorre quando o valor de um atributo em um esquema corresponde ao proprio atrib-

uto em outro esquema. Um exemplo deste caso e definido na tabela 3.11:

29

ALUNO (esquema 1)cpfnometipo

ALUNO (esquema 2)cpfnomegradmestredoutor

Tabela 3.11: Exemplo de Conflito entre Atributo e Dados

Neste exemplo, o esquema 1 guarda no atributo tipo a condicao do aluno (grad, mestre,

doutor). Ja o esquema 2 possui um atributo do tipo booleano para cada condicao possıvel.

3.3 Formalismos para Integracao de Bancos de Dados

Uma das principais diferencas entre um sistema de integracao de dados e um sistema

de banco de dados tradicional e o fato de que as consultas sao submetidas pelos usuarios a

um esquema global, mesmo que os dados estejam sendo armazenados em esquemas locais.

Entao, de modo a permitir que o sistema de integracao de banco de dados possa responder



submetida a ele como novas consultas submetidas aos esquemas locais [9].

Em princıpio, poderia-se usar formulas logicas de primeira ordem para descrever as

fontes de dados. Mas nesse caso a reformulacao completa seria praticamente impossıvel.

Entao varias aproximacoes foram desenvolvidas nas quais formas restritas de formulas

logicas de primeira ordem acompanhadas de algorıtimos de reformulacao tem sido uti-

lizadas. Serao descritas duas dessas aproximacoes, ”Global as View”(GAV) e ”Local as

View”(LAV).

3.3.1 Global as View (GAV)

Para cada relacao pertencente ao esquema global, escreve-se uma consulta sobre os

esquemas locais especificando como obter as instancias destinadas a essa relacao.

Reformulacao de consultas em GAV e algo relativamente direto. Uma vez que as

relacoes no esquema global estao definidas em termos das relacoes locais, tudo o que se

30

tem a fazer e abrir as definicoes das relacoes do esquema global. Entretanto, adicionar

novas fontes ao sistema de integracao nao e um processo trivial. Para uma nova fonte de

dados, e necessario descobrir todos os modos pelos quais se possa obter dados para cada

uma das relacoes do esquema global.

O formalismo GAV e provavelmente o mais largamente utilizado e pesquisado. Maiores

informacoes sobre ele podem ser acessadas no projeto TSIMMIS [6] onde diversas ferra-

mentas para integracao de fontes de dados heterogeneas tem sido desenvolvidas.

3.3.2 Local as View (LAV)

Nesta tecnica cada uma das relacoes das fontes e descrita atraves de consultas sobre

o esquema global.

Reformulacao de consultas em LAV e uma operacao mais complexa do que em GAV

porque nao e possıvel simplesmente abrir as definicoes das relacoes do esquema global.

Algorıtimos para a resolucao desse problema sao fornecidos em [9]. Em compensacao e

facil adicionar novas fontes de dados, uma vez que se tera de escrever consultas apenas

para cada uma das relacoes da nova fonte.

Um bom exemplo de metodologia que utiliza esse formalismo pode ser encontrado em

[10] onde cada uma das fontes de dados e estudada de forma a se obter uma descricao

declarativa do seu conteudo e capacidade para resolucao de consultas. Essa metodologia e

considerada centrada nas fontes de dados e nao nas consultas porque utiliza as descricoes

das fontes para gerar os planos de resposta das consultas.

31

CAPITULO 4

O FORMALISMO E SUAS METODOLOGIAS

4.1 O Projeto AutoMed

O Projeto de Geracao Automatica de Ferramentas Mediadoras para Integracao de Ban-

cos de Dados Heterogeneos (Automatic Generation of Mediator Tools for Heterogeneous

Database Integration - AutoMed) [3] e uma parceria de pesquisas realizada pela Universi-

dade de Birkbeck (Birkbeck University of London) e pela Universidade Imperial (Imperial

College of London).

A metodologia utilizada pelo projeto AutoMed se caracteriza por ver o processo de

integracao como uma sequencia de transformacoes reversıveis que modificam tanto o es-

quema como a extensao do banco de dados. Essa sequencia de transformacoes incremen-

talmente adiciona, apaga ou renomeia um objeto do esquema do banco de dados ate que se

possa mapear diversos esquemas de bancos de dados uns com os outros. Acompanhando

cada uma dessas transformacoes ha uma consulta que especifica como as instancias do

objeto que esta sendo adicionado ou apagado podem ser obtidas a partir de outros objetos

do esquema.

Talvez a maior vantagem do projeto AutoMed seja a de que ele nao esta restrito a

apenas uma linguagem de modelagem para bancos de dados. Ao inves disso as linguagens

de modelagem podem ser representadas atraves de um modelo de dados baseado em hiper-

grafos (secao 4.2). Em consequencia disso basta configurar a linguagem de modelagem

escolhida em termos do modelo de dados baseado em hipergrafos para que seja possıvel

utilizar a implementacao existente do projeto.

A implementacao do projeto AutoMed ja possui um repositorio de dados que fun-

ciona atraves de Java API e prove um armazenamento persistente das informacoes de

configuracoes da linguagem de modelagem dos dados, dos esquemas dos bancos de dados

e das sequencias de transformacao entre esses esquemas. Maiores informacoes sobre o

32

funcionamento do repositorio de dados com relacao a representacao das linguagens de

modelagem e sua integracao podem ser encontradas em [4].

4.2 O Modelo de Dados Baseado em Hipergrafos

Muitos formalismos e metodologias ja foram criados para resolver o problema da in-

tegracao de bancos de dados. A. Poulovassilis e P. McBrien criaram um formalismo [12]

que procura eliminar as diferencas entre esquemas atraves de transformacao dos mesmos.

Este formalismo e denominado modelo de dados baseado em hipergrafos (hipergraph data

model - HDM).

Este formalismo utiliza o conceito de hipergrafos para representar o esquema, as

instancias e o mapeamento entre ambos, representando assim um modelo de dados.

Para trabalhar com esse formalismo foram definidas transformacoes primitivas que sao

listadas a seguir:

• renameNode(fromName, toName) - Renomeia um vertice.

• renameEdge(〈fromName, c1, . . . , cm〉, toName) - Renomeia uma aresta.

• addConstraint c - Adiciona uma nova restricao c.

• delConstraint c - Apaga uma restricao c.

• addNode(name, q) - Adiciona um vertice chamado name cuja extensao e dada pela

consulta q.

• delNode(name, q) - Apaga um vertice chamado name. q e um consulta que deter-

mina como a extensao do vertice apagado pode ser recuperada a partir dos objetos

restantes do esquema.

• addEdge(〈name, c1, . . . , cm〉, q) - Adiciona uma nova aresta entre uma sequencia de

objetos c1, . . . , cm do esquema. A extensao da aresta e determinada pelo valor da

consulta q.

33

• delEdge(〈name, c1, . . . , cm〉, q) - Apaga uma aresta. q e um consulta que deter-

mina como a extensao da aresta apagada pode ser recuperada a partir dos objetos

restantes do esquema.

Aqueles que desejarem se aprofundar mais nesse formalismo podem consultar o anexo

A onde encontrarao uma especificacao bem mais completa. Mais informacoes sobre a

utilizacao e evolucao deste formalismo podem ser encontradas em [15] onde foi demon-

strado que o formalismo consegue suportar todas as trasnformacoes usadas na integracao

de esquemas utilizando o modelo de dados entidade-relacionamento e em [17] onde foi

demonstrado que o formalismo pode ser aplicado para varias linguagens de modelagem

de alto nıvel como o modelo de dados entidade-relacionamento, relacional, documentos

da Internet e ate mesmo UML.

4.3 Linguagem Intermediaria para Consultas (IQL)

Como dito anteriormente, o HDM nao possui uma linguagem propria para consultas

e restricoes. Ele permite que o desenvolvedor escolha a linguagem utilizada para dar

mais liberdade ao formalismo. Como o formalismo BAV (secao 4.4) usa uma linguagem

especıfica entao ela sera apresentada atraves de um breve resumo. Nao e necessario

aprofundar o conhecimento da linguagem aqui uma vez que este trabalho nao utiliza todo

o seu potencial.

A Linguagem Intermediaria para Consultas (Intermediate Query Language - IQL)

[19, 7, 20] e uma linguagem que pertence ao paradigma funcional. Seu proposito e ser

uma linguagem para consultas com facil traducao para varias linguagens de alto nıvel,

como SQL por exemplo.

A linguagem suporta strings de caracteres, valores booleanos, numeros reais e numeros

inteiros. Ela trabalha com varios tipos de colecoes como conjuntos (representados na

forma {1, 2, 3}), multi-conjuntos (conjuntos que aceitam repeticoes representados na forma

{|1, 2, 3|}), listas (representadas na forma [1, 2, 3]) e tuplas (representadas na forma (1, 2, 3)).

Varias funcoes nativas sao definidas pela linguagem. Estao entre elas: (+), (−), (∗), (/), (=

34

), (! =), (<), (>), (<=), (>=), and, or, not, if . As funcoes costumam ser utilizadas na

forma prefixa com excecao dos operadores (++) e (−−) que representam respectivamente

a uniao e diferenca entre colecoes e podem ser utilizados tanto na forma prefixa quanto

na forma infixa.

Funcoes anonimas podem ser definidas atraves de abstracoes lambda. O exemplo a

seguir define uma funcao que retorna o valor de uma expressao que recebe tres argumentos,

soma os dois primeiros e multiplica pelo terceiro.

λ (x, y, z) ((∗) ((+) x y) z)

Expressoes do tipo let tambem sao aceitas pela linguagem. Sua utilidade esta em ligar

uma expressao a um nome. Desse modo pode-se tornar menor uma expressao que use

o mesmo codigo repetidamente. O exemplo a seguir repete o exemplo anterior por duas

vezes somando seus resultados e retornado o valor 44.

let v = λ (x, y, z) ((∗) ((+) x y) z) in ((+) (v(1, 2, 3)) (v(3, 4, 5)))

Mas o que torna a linguagem agradavel e facil de usar e a utilizacao da sintaxe de

compreensao [5]. O uso da sintaxe de compreensao nao gera nenhuma expressividade

adicional a linguagem mas torna a linguagem sintaticamente facil de ler e entender. Alem

disso e esperado que seja uma tarefa facil a traducao do IQL para outras linguagens de

alto nıvel e vice-versa.

Uma compreensao se apresenta na forma [e |Q1; . . . ; Qn] para n ≥ 0. Ela e composta

por uma expressao inicial que denota o formato do resultado seguido por uma sequencia

de qualificadores que podem ser geradores ou filtros. Geradores relacionam uma variavel

ou uma tupla de variaveis com uma expressao que denota uma lista de valores. Filtros

sao expressoes booleanas que selecionam as instancias devolvidas pelos geradores.

Assumindo que R e S sejam colecoes, o conjunto das operacoes para manipulacao

de dados no modelo relacional podem ser utilizados da seguinte maneira atraves da lin-

guagem:

• Uniao: R + +S ou (++)R S

35

• Diferenca: R −−S ou (−−)R S

• Projecao: [(x, z) | (x, y, z) ← R]

• Selecao: [(x, y, z) | (x, y, z) ← R; (>) z 10]

• Produto Cartesiano: [(x1, y1, x2, y2) | (x1, y1) ← R; (x2, y2)← S]

A linguagem intermediaria para consultas esta se tornando rapidamente a principal

linguagem do projeto AutoMed sendo utilizada em grande escala para representar as

operacoes de transformacao de seus formalismos e para representar as consultas disparadas

contra a sua implementacao de um repositorio de dados.

4.3.1 Sintaxe

query ::= expr

| Let VarToken Equal query In query

| query Append query

| query Difference query

| query expr

expr ::= NumToken

| StrToken

| VarToken

| Any

| BoolToken

| Void

| scheme

| VarToken Colon scheme

| LSB query Bar quals RSB

| LSB RSB

37

BoolToken = ”True”

| ”False”

StrToken = \′ [ ∧\′ ]∗ \’

NumToken = [0− 9]+

| ([0− 9]+)(.)([0− 9]+)

VarToken = ”(+)” | ”(−)” | ”(∗)”

| ”(/)” | ”(&)” | ”(#)”

| ”(=)” | ”(! =)” | ”(<)”

| ”(>)” | ”(<=)” | ”(>=)”

| [A− Za− z ] [A− Za− z0− 9 $]∗

Let = ”let”

In = ”in”

Equal = ” = ”

Append = ” + +”

Difference = ”−−”

SemiColon = ”; ”

LArrow = ”<−”

Comma = ”, ”

Bar = ” | ”

LSB = ”[”

RSB = ”]”

LRB = ”(”

RRB = ”)”

LCB = ”{”

RCB = ”}”

38

Any = ”any”

Lambda = ”lambda”

LDAB = ”<<”

RDAB = ”>>”

Colon = ” : ”

Void = ”void”

4.3.2 Funcoes Nativas

Operadores Unarios Prefixados

• not exp - devolve a negacao de uma expressao;

• count list - devolve o comprimento de uma lista;

• sort list - devolve os elementos de uma lista;

• distinct list - retira os elementos duplicados de uma lista;

• group list - devolve uma lista de pares onde o primeiro elemento de cada par pertence

a lista fornecida como parametro e o segundo componente e uma lista;

• max list - devolve o maior valor de uma lista de numeros;

• min list - devolve o menor valor de uma lista de numeros;

• sum list - devolve a soma dos valores de uma lista;

• avg list - devolve a media dos valores de uma lista.

Operadores Binarios Infixos

• list ++ list - devolve a uniao de duas listas;

• list −− list - devolve a diferenca entre duas listas.

Operadores Binarios Prefixados

39

• operadores basicos - (+) (−) (∗) (/) (=) (! =) (>) (<) (>=) (<=) and or;

• setUnion list list - devolve a uniao de duas listas apos retirar as duplicatas;

• sub list list - devolve verdadeiro se a primeira lista for um subconjunto da segunda;

• intersect list list - devolve a interseccao entre duas listas;

• member list exp - devolve verdadeiro se a expressao pertence a lista;

• map func list - aplica a funcao a cada um dos valores da lista;

• flatmap func list - aplica uma funcao que devolve uma lista a cada um dos elementos

de uma lista devolvendo a concatenacao das listas resultantes.

Operador Ternario

• if exp exp exp - se o valor da primeira expressao for verdadeiro devolve o valor da

segunda expressao, caso contrario devolve o valor da terceira expressao.

4.4 Both as View (BAV)

O formalismo both as view (BAV) [13, 14, 11] foi desenvolvido a partir do formalismo

HDM e dos formalismos GAV e LAV e desenvolvido de modo a ser aplicado em esquemas

que usem o modelo de dados relacional. Projecoes do formalismo para o modelo de dados

entidade relacionamento, diagramas UML e documentos da Internet podem ser encon-

trados em [17]. Diante dessas projecoes avalia-se que sera uma tarefa simples estender

a implementacao do repositorio de dados do projeto AutoMed de modo a ser aplicado a

outros modelos de dados.

Cada objeto pertencente a um esquema de um banco de dados e representado atraves

de um scheme pertencente ao formalismo HDM (ver secao 4.2). Assim cada objeto de um

banco de dados relacional e representado da seguinte maneira:

• Uma relacao e representada atraves da forma << rel >> onde rel e o nome da

relacao. Suas instancias representam o conjunto de chaves primarias da relacao.

40

• Um atributo e representado atraves da forma << rel, att, const >> onde rel rep-

resenta o nome da relacao ao qual o atributo pertence, att representa o nome do

atributo e const e uma restricao opcional que expressa se o valor do atributo pode

ser nulo ou nao. Suas instancias representam o conjunto de chaves primarias da

relacao e em sequencia o valor do atributo.

• Uma restricao por chaves primarias e representada atraves da forma << rel, att1, . . . ,

attn >> onde rel representa o nome da relacao ao qual a restricao pertence e

att1, . . . , attn representa a lista de atributos pertencentes a restricao. Uma vez que

e apena uma restricao ela nao toma instancias para si.

• Uma restricao por chaves estrangeiras e representada atraves da forma << rel, a1, . . . ,

an, rele, ea1, . . . , ean >> onde rel representa o nome da relacao, rele representa a

relacao estrangeira, a1, . . . , an representa uma lista de atributos de rel e ea1, . . . , ean

representa uma lista de chaves primarias de rele. Para que a restricao seja satisfeita

a1, . . . , an devem ser iguais a ea1, . . . , ean.

Uma visualizacao das estruturas que representam instancias em um grafo e mostrada

na figura 4.1. Deve-se observar que existe uma lista de chaves primarias e uma lista de

atributos. Como chaves primarias tambem sao atributos isso gera alguma redundancia

visto que elas sao representadas duas vezes. Isto foi feito porque a uniformidade no

tratamento dos atributos aumenta a facilidade com que consultas IQL sao traduzidas em

consultas SQL alem de facilitar a codificacao e implementacao do repositorio de dados do

Projeto Automed.

Do mesmo modo que o formalismo HDM, o formalimo BAV se caracteriza por uma

sequencia de transformacoes aplicadas em sequencia onde cada uma adiciona, retira ou

renomeia um objeto do formalismo. Alem disso sao especificadas operacoes de extend e

contract que respectivamente adicionam ou retiram objetos do formalismo especificando

a consulta que determina a origem das instancias apenas parcialmente ou ate mesmo nao

as especificando. As possıveis transformacos do formalismo sao:

• addRel(<< rel >>, q) - Adiciona uma relacao chamada rel ao esquema. A consulta

41

Figura 4.1: Grafo do Modelo Relacional em BAV

q especifica como e possıvel obter o conjunto de chaves primarias a partir dos objetos

ja existentes no esquema.

• extRel(<< rel >>, q) - Adiciona uma relacao chamada rel ao esquema. A consulta

q e opcional, podendo ser substituıda pela constante void, e especifica parcialmente

como e possıvel obter o conjunto de chaves primarias a partir dos objetos ja exis-

tentes no esquema.

• delRel(<< rel >>, q) - Remove uma relacao chamada rel do esquema. A consulta

q especifica como e possıvel recuperar o conjunto de chaves primarias da relacao

excluida a partir dos objetos ja existentes no esquema.

• conRel(<< rel >>, q) - Remove uma relacao chamada rel do esquema. A consulta q

e opcional, podendo ser substituıda pela constante void, e especifica como e possıvel

recuperar o conjunto de chaves primarias da relacao excluıda a partir dos objetos

ja existentes no esquema.

• renRel(<< relold >>, << relnew >>) - Renomeia uma relacao substituindo relold

por relnew.

• addAtt(<< rel, att >>, q) - Adiciona um atributo chamado att na relacao rel. A

consulta q especifica como e possıvel obter o conjunto de instancias do atributo a

partir dos objetos ja existentes no esquema.

42

• extAtt(<< rel, att >>, q) - Adiciona um atributo chamado att na relacao rel. A

consulta q e opcional, podendo ser substituıda pela constante void, e especifica

parcialmente como e possıvel obter o conjunto de instancias do atrIbuto a partir

dos objetos ja existentes no esquema.

• delAtt(<< rel, att >>, q) - Remove um atributo chamado att da relacao rel. A

consulta q especifica como e possıvel recuperar o conjunto de instancias do atributo

excluıdo a partir dos objetos ja existentes no esquema.

• conAtt(<< rel >>, q) - Remove um atributo chamada att da relacao rel. A consulta

q e opcional, podendo ser substituıda pela constante void, e especifica como e possıvel

recuperar as instancias do atributo excluıdo a partir dos objetos ja existentes no

esquema.

• renAtt(<< rel, attold >>, << rel, attnew >>) - Renomeia um atributo de uma

relacao rel substituindo attold por attnew.

• addPK(<< rel, a1, . . . , an >>) - Adiciona a chave primaria da relacao rel. A lista

de atributos a1, . . . , an indica os atributos que serao o conjunto de chaves primarias

da relacao.

• delPK(<< rel, a1, . . . , an >>) - Remove a chave primaria da relacao rel. A lista de

atributos a1, . . . , an indica os atributos que eram o conjunto de chaves primarias da

relacao.

• addFK(<< rel, a1, . . . , an, rele, ea1, . . . , ean >>) - Adiciona uma chave estrangeira

entre a relacao rel e a relacao estrangeira rele. A lista de atributos a1, . . . , an

da relacao rel devera estar na lista de atributos chaves ea1, . . . , ean da relacao es-

trangeira rele para satisfazer a restricao.

• delFK(<< rel, a1, . . . , an, rele, ea1, . . . , ean >>) - Remove uma chave estrangeira

entre a relacao rel e a relacao estrangeira rele. A lista de atributos a1, . . . , an da

relacao rel e os atributos chaves ea1, . . . , ean da relacao estrangeira rele devem ser

indicados para realizacao da operacao.

43

As transformacao que adicionam ou removem atributos dos esquemas podem opcional-

mente ter um parametro a mais indicando se o atributo pode ou nao ter um valor nulo. A

maioria dos trabalhos e implementacoes simplificam o formalismo BAV ignorando trans-

formacoes que manipulem chaves primarias e chaves estrangeiras uma vez que nao sao

necessarias em seus metodos.

Comparacoes entre o formalismo BAV e os formalismos GAV e LAV (secao 3.3)

mostram algumas vantagens em relacao aos mesmos: as evolucoes nos esquemas locais

e globais sao mais bem aceitas pelo formalismo BAV uma vez que basta acrescentar no-

vas transformacoes a sequencia de transformacoes ja existentes evitando a reconstrucao

do trabalho e o formalismo BAV tambem armazena mais informacoes sobre as extensoes

relativas a cada esquema, armazenando nao so como recuperar as instancias mas tambem

se a recuperacao sera total ou parcial.

Alem disso, a propriedade da reversibilidade das operacoes, herdada pelo formalismo

HDM aplicada as visoes GAV e LAV do esquemas aumenta a capacidade de resolucao de

consultas disparadas tanto as fontes de dados locais quanto ao banco de dados global.

4.5 Metodologias Utilizadas

O Projeto AutoMed possui diversas metodologias para realizar a integracao de dados

atraves do formalismo BAV. Todas elas se caracterizam por produzir sequencias de trans-

formacoes aplicadas tanto no esquema quanto nas instancias de cada uma das fontes de

dados. Duas metodologias se destacam por serem as mais utilizadas. Ambas se caracter-

izam por utilizar uma estrategia de integracao de um unico passo (secao 3.1.2).

A primeira metodologia [13] se destaca por uma postura mais artesanal, direcionada

a casos especıficos onde nao se pretende adicionar ou retirar fontes de dados do processo

de integracao apos seu termino. Esta metodologia da grande enfase a completude do

processo de integracao, incentivando a ideia de que toda as informacoes das fontes de

dados locais devem estar no banco de dados global. Costuma ser utilizada, por exemplo,

em casos onde grandes corporacoes precisam integrar bancos de dados muito extensos.

Inicialmente, para cada objeto semantico pertencente as fontes de dados, adiciona-se

44

um objeto ao esquema do banco de dados global especificando de quais objetos das fontes

de dados devem ser obtidas as respectivas instancias. Uma vez que se tenha terminado de

adicionar objetos ao esquema do banco de dados global deve-se retirar cada um dos objetos

de cada uma das fontes de dados locais especificando como recuperar suas instancias a

partir do esquema do banco de dados global. A adicao de objetos ao esquema do banco

de dados global e a retirada dos objetos dos esquemas das fontes de dados locais geram

satisfatoriamente os aspectos GAV e LAV do processo de integracao.

A seguir serao mostrados os passos da integracao de dois bancos de dados simples

compostos por apenas uma relacao cada um. Seus esquemas serao exibidos na tabela

4.1. A resolucao de situacoes mais complexas atraves formalismo BAV sera mostradas na

secao 4.6.

ALUNO(esquema 1)cpfnomeano

ESTUDANTE(esquema 2)cpfnomeorientador

ALUNO(esquema global)cpfnomeorientadorano

Tabela 4.1: Esquemas para o Exemplo de Integracao de Esquemas

As siglas esq1, esq2 e esqg denotam respectivamente esquema 1, esquema 2 e esquema

global. Nomes escritos com letras maiusculas denotam nomes de relacoes e nomes escritos

com letras minusculas denotam nomes de atributos. Considera-se que todos os objetos

dos esquemas locais ja foram criados no formalismo. Portanto adiciona-se cada objeto

semantico pertencente aos esquemas locais ao esquema global.

• addRel(〈〈esqg.ALUNO〉〉, [(x)|(x) ← 〈〈esq1.ALUNO〉〉] + +[(x)|(x) ← 〈〈esq2.

ESTUDANTE〉〉])

• addAtt(〈〈esqg.ALUNO, cpf〉〉, [(x, x)|(x) ← 〈〈esqg.ALUNO〉〉])

• addAtt(〈〈esqg.ALUNO, nome〉〉, [(x, y)|(x, y)← 〈〈esq1.ALUNO, nome〉〉; not (x) ←

〈〈esq2.ESTUDANTE〉〉] + +[(x, y)|(x, y)← 〈〈esq2.ESTUDANTE, nome〉〉])

45

• addAtt(〈〈esqg.ALUNO, orientador〉〉, [(x, y)|(x, y)← 〈〈esq2.ESTUDANTE,

orientador〉〉])

• addAtt(〈〈esqg.ALUNO, ano〉〉, [(x, y)|(x, y)← 〈〈esq1.ALUNO, ano〉〉])

• addPK(〈〈esqg.ALUNO, 〈〈esqg.ALUNO, cpf〉〉〉〉)

Resta agora retirar cada objeto pertencente aos esquemas locais.

• delPK(〈〈esq1.ALUNO, 〈〈esq1.ALUNO, cpf〉〉〉〉)

• delAtt(〈〈esq1.ALUNO, ano〉〉, [(x, y)|(x, y)← 〈〈esqg.ALUNO, ano〉〉; (! =) y void])

• delAtt(〈〈esq1.ALUNO, nome〉〉, [(x, y)|(x, y)← 〈〈esqg.ALUNO, nome〉〉; (x) ←

〈〈esq1.ALUNO〉〉; ])

• delAtt(〈〈esq1.ALUNO, cpf〉〉, [(x, x)|(x)← 〈〈esq1.ALUNO〉〉)

• delRel(〈〈esq1.ALUNO〉〉, [(x)|(x, y)← 〈〈esqg.ALUNO, ano〉〉; (! =) y void])

• delPK(〈〈esq2.ESTUDANTE, 〈〈esq2.ESTUDANTE, cpf〉〉〉〉)

• delAtt(〈〈esq2.ESTUDANTE, orientador〉〉, [(x, y)|(x, y)← 〈〈esqg.ALUNO,

orientador〉〉; (! =) y void])

• delAtt(〈〈esq2.ESTUDANTE, nome〉〉, [(x, y)|(x, y)← 〈〈esqg.ALUNO, nome〉〉;

(x) ← 〈〈esq2.ESTUDANTE〉〉])

• delAtt(〈〈esq2.ESTUDANTE, cpf〉〉, [(x, x)|(x)← 〈〈esq2.ESTUDANTE〉〉)

• delRel(〈〈esq2.ESTUDANTE〉〉, [(x)|(x, y)← 〈〈esqg.ALUNO, orientador〉〉;

(! =) y void])

A segunda metodologia [11] se destaca por uma postura de trabalho como a de uma

linha de montagem. Por um lado e mais flexıvel, uma vez que e razoavelmente facil adi-

cionar ou retirar fontes de dados ao processo de integracao mesmo apos seu termino. Por

outro lado a completude do processo de integracao e ignorada uma vez que normalmente

46

nem todas as informacoes das fontes de dados locais estarao presentes no banco de dados

global. Costuma ser utilizada, por exemplo, em casos em que existe a necessidade de

integrar muitos bancos de dados de tamanho reduzido como locadoras ou escolas.

O primeiro passo desta metodologia e definir um esquema que possa armazenar todas

as informacoes desejadas no esquema do banco de dados global. Esse esquema, definido

como esquema de uniao, e construıdo baseado nas aspiracoes do objetivo do banco de da-

dos integrado. A partir daı, para cada fonte de dados local, deve-se definir uma sequencia

de transformacoes que torne seu esquema identico ao esquema de uniao. Uma vez que

cada um dos esquemas das fontes de dados locais ja foi redefinido com base no esquema

de uniao basta criar uma rotina de transformacoes que faca a uniao de todos os esquemas

compatıveis a uniao removendo as duplicatas e crie o esquema do banco de dados global

de modo muito parecido com a metodologia anterior. A figura 4.2 consegue dar uma visao

geral e mais clara de todos os passos dessa metodogia.

Figura 4.2: Processo de Integracao que Utiliza Esquemas Compatıveis a Uniao

A ultima etapa dessa metodologia, a juncao de todos os esquemas compatıveis a uniao,

ja e realizada automaticamente pela implementacao do Projeto AutoMed. Essa metodolo-

gia tem uma tendencia maior a perder o aspecto LAV do processo de integracao devido a

47

sua automatizacao, mas suas vantagens compensam isso.

4.6 Resolucao dos Casos de Conflito

O objetivo deste capıtulo e analisar cada um dos possıveis tipos de conflitos de dados

que possam surgir durante o processo de integracao e sua solucao. Serao utilizados os con-

flitos apresentados na secao 3.2 atraves dos quais o autor desta dissertacao ira demonstrar

como o formalismo BAV pode solucionar cada conflito.

A metodologia do formalismo BAV utilizada aqui e baseada em um esquema de uniao.

Assim um conflito estara solucionado quando o esquema local se tornar igual ao esquema

de uniao. Em decorrencia disso todas as transformacoes sao aplicadas nos esquemas locais.

4.6.1 Conflitos de Incompatibilidade de Domınio

4.6.1.1 Conflitos de Nomes

ESTUDANTE(esquema de uniao)cpfnome

ALUNO(esquema local)cpfnome

Tabela 4.2: Exemplo de Conflito de Nomes

Neste exemplo as relacoes Estudante e Aluno possuem o mesmo significado semantico

apesar de possuirem nomes diferentes. A resolucao atraves do formalismo BAV seria feita

assim:

• renRel(〈〈ALUNO〉〉, 〈〈ESTUDANTE〉〉)

4.6.1.2 Conflitos de Representacao dos Dados

Neste exemplo o campo rg no esquema de uniao e representado por uma string enquanto

que no esquema local um campo com o mesmo nome e representado por um valor numerico.

As funcoes int2str e str2int, responsaveis respectivamente por converter um numero em

string e uma string em numero, nao existem na definicao da linguagem IQL, mas as

48

ALUNO(esquema de uniao)cpfrg (string)nome

ALUNO(esquema local)cpfrg (inteiro)nome

Tabela 4.3: Exemplo de Conflito de Representacao dos dados

caracterısticas da linguagem permitem que se defina novas funcoes. A resolucao atraves

do formalismo BAV seria feita assim:

• renAtt(〈〈ALUNO, rg〉〉, 〈〈ALUNO, rgn〉〉)

• addAtt(〈〈ALUNO, rg〉〉, [(x, int2str(y))|(x, y)← 〈〈ALUNO, rgn〉〉])

• delAtt(〈〈ALUNO, rgn〉〉, [(x, str2int(y))|(x, y)← 〈〈ALUNO, rg〉〉])

4.6.1.3 Conflitos de Unidade

PACIENTE(esquema de uniao)cpfnomepesoQ

PACIENTE(esquema local)cpfnomepesoL

Tabela 4.4: Exemplo de Conflito de Unidade

Neste exemplo, pesoQ esta representado em quilos e pesoL esta representado em libras.

A resolucao atraves do formalismo BAV seria feita assim:

• addAtt(〈〈PACIENTE, pesoQ〉〉, [(x, (y∗0, 4536))|(x, y)← 〈〈PACIENTE, pesoL〉〉])

• delAtt(〈〈PACIENTE, pesoL〉〉, [(x, (y∗2, 2046))|(x, y)← 〈〈PACIENTE, pesoQ〉〉])

4.6.1.4 Conflitos de Precisao dos Dados

Neste exemplo, o atributo conceito tem seus valores representados como A, B, C ou

D. O atributo nota tem seus valores representados como um numero inteiro de 0 a 100.

O conceito A equivale a notas maiores que 90, o conceito B equivale a notas maiores que

80 e menores que 90, o conceito C equivale a notas maiores que 70 e menores que 80 e

49

ALUNO(esquema de uniao)cpfnomeconceito

ALUNO(esquema local)cpfnomenota

Tabela 4.5: Exemplo de Conflito de Precisao de Dados

o conceito D equivale a notas menores que 70. A resolucao atraves do formalismo BAV

seria feita assim:

• addAtt(〈〈ALUNO, conceito〉〉, [(x, A)|(x, y)← 〈〈ALUNO, nota〉〉; y >= 90]++[(x, B)|(x, y)←

〈〈ALUNO, nota〉〉; y >= 80; y < 90] + +[(x, C)|(x, y) ← 〈〈ALUNO, nota〉〉; y >=

70; y < 80]) + +[(x, D)|(x, y)← 〈〈ALUNO, nota〉〉; y < 70]

• conAtt(〈〈ALUNO, nota〉〉, void)

Mas este e um caso problematico em relacao aos outros, pois sua resolucao perde

informacoes e consequentemente perde a propriedade de reversibilidade do formalismo.

4.6.1.5 Conflitos de Valores Padrao

PESSOAL(esquema de uniao)cpfnometitulo

PESSOAL(esquema local)cpfnometitulovp

Tabela 4.6: Exemplo de Conflito de Valores Padrao

Neste exemplo, o atributo titulo tem seus valores representados por ESTUDANTE,

PROFESSOR ou FUNCIONARIO. No esquema local o atributo titulovp funciona da

mesma forma, mas quando seu valor for ESTUDANTE, a ocorrencia sera representada

com o valor VOID (NULL). A resolucao atraves do formalismo BAV seria feita assim:

• addAtt(〈〈PESSOAL, titulo〉〉, [(x, (if(y = void)(ESTUDANTE)(y)))|(x, y)←

〈〈PESSOAL, titulovp〉〉])

• delAtt(〈〈PESSOAL, titulovp〉〉, [(x, (if(y = ESTUDANTE)(void)(y)))|(x, y) ←

〈〈PESSOAL, titulo〉〉])

50

4.6.2 Conflitos entre Definicoes de Entidades

4.6.2.1 Conflitos de Equivalencia de Chaves

ALUNO(esquema de uniao)cpfrgnome

ALUNO(esquema local)rgcpfnome

Tabela 4.7: Exemplo de Conflito de Equivalencia de Chaves

Este e um caso simples, onde o identificador do esquema de uniao e um atributo

no esquema local e vice-versa. Mas caso nao seja possıvel encontrar uma funcao de

mapeamento ou um identificador comum nao sera possıvel realizar a integracao de modo

satisfatorio. A resolucao atraves do formalismo BAV seria feita assim:

• delPK(〈〈ALUNO, 〈〈ALUNO, rg〉〉〉〉)

• addPK(〈〈ALUNO, 〈〈ALUNO, cpf〉〉〉〉)

4.6.2.2 Conflitos de Uniao

ALUNO(esquema de uniao)cpfnomerg

ALUNO(esquema local)cpfnomealtura

Tabela 4.8: Exemplo de Conflito de Uniao

Neste exemplo, o atributo rg existe no esquema de uniao mas nunca existiu no esquema

local. Ja o atributo altura existe no esquema local mas nao existe interesse em mante-lo

no esquema de uniao. A resolucao atraves do formalismo BAV seria feita assim:

• addAtt(〈〈ALUNO, rg〉〉, void)

• delAtt(〈〈ALUNO, altura〉〉, void)

51

ALUNO(esquema de uniao)cpfnomecompleto

ALUNO(esquema local)cpfnomesobrenome

Tabela 4.9: Exemplo de Conflito de Isomorfismo

4.6.2.3 Conflitos de Isomorfismo

Neste exemplo, o esquema de uniao guarda o nome de um aluno em um atributo

(nomecompleto) enquanto no esquema local o mesmo conceito e armazenado em dois

atributos (nome e sobrenome). A funcao strConcat, responsavel por concatenar duas

strings, nao existe na definicao da linguagem IQL, mas as caracterısticas da linguagem

permitem que se defina novas funcoes. A resolucao atraves do formalismo BAV seria feita

assim:

• addAtt(〈〈ALUNO, nomecompleto〉〉, [(x, strConcat(y, z))|(x, y)← 〈〈ALUNO, nome〉〉;

(x, z) ← 〈〈ALUNO, sobrenome〉〉])

• conAtt(〈〈ALUNO, nome〉〉, void)

• conAtt(〈〈ALUNO, sobrenome〉〉, void)

Deve-se tomar cuidado uma vez que este e um caso problematico em relacao aos outros.

Dependendo da funcao de mapeamento escolhida pode ocorrer a perda da propriedade de

reversibilidade do formalismo BAV.

4.6.2.4 Conflitos de Falta de Atributos

ALUNO(esquema de uniao)cpfnometipo

ALUNOGRAD(esquema local)cpfnome

Tabela 4.10: Exemplo de Conflito de Falta de Dados

Neste exemplo, o esquema de uniao guarda alunos de todos os tipos (graduacao, pos-

graduacao, etc.). Ja o esquema local guarda apenas os alunos de graduacao. Apesar

52

do atributo tipo nao estar presente no esquema local, ele pode ser facilmente deduzido

atraves de inferencia. A resolucao atraves do formalismo BAV seria feita assim:

• addAtt(〈〈ALUNOGRAD, tipo〉〉, [(x, ”grad”)|x← 〈〈ALUNOGRAD〉〉])

• renRel(〈〈ALUNOGRAD〉〉, 〈〈ALUNO〉〉)

4.6.2.5 Conflitos entre Relacoes e Atributos

ALUNO(esquema de uniao)cpfnomeidadeorientador

ALUNO(esquema local)cpfnomeidade

ALUNOPG(esquema local)cpforientador

Tabela 4.11: Exemplo de Conflito entre Relacao e Atributo

Neste exemplo, o esquema de uniao guarda todas as informacoes sobre todos os alunos

na mesma tabela. Ja o esquema local guarda as informacoes gerais sobre os alunos em

uma tabela e informacoes especıficas sobre alunos da pos-graduacao em outra tabela. A

resolucao atraves do formalismo BAV seria feita assim:

• addAtt(〈〈ALUNO, orientador〉〉, [(x, y)|(x, y)← 〈〈ALUNOPG, orientador〉〉])

• delAtt(〈〈ALUNOPG, orientador〉〉, [(x, y)|(x, y)← 〈〈ALUNO, orientador〉〉])

• delRel(〈〈ALUNOPG〉〉, [(x)|(x, y)← 〈〈ALUNO, orientador〉〉; not(y = void)])

4.6.2.6 Conflitos entre Atributos e Dados

ALUNO(esquema de uniao)cpfnometipo

ALUNO(esquema local)cpfnomegradmestredoutor

Tabela 4.12: Exemplo de Conflito entre Atributo e Dados

53

Neste exemplo, o esquema de uniao guarda no atributo tipo a condicao do aluno

(grad, mestre, doutor). Ja o esquema local possui um atributo do tipo boolean para cada

condicao possıvel. A resolucao atraves do formalismo BAV seria feita assim:

• addAtt(〈〈ALUNO, tipo〉〉, [(x, grad)|(x, TRUE)← 〈〈ALUNO, grad〉〉]++[(x, mestre)|

(x, TRUE) ← 〈〈ALUNO, mestre〉〉]++[(x, doutor)|(x, TRUE)← 〈〈ALUNO, doutor〉〉])

• delAtt(〈〈ALUNO, grad〉〉, [(x, TRUE)|(x, grad)← 〈〈ALUNO, tipo〉〉])

• delAtt(〈〈ALUNO, mestre〉〉, [(x, TRUE)|(x, mestre) ← 〈〈ALUNO, tipo〉〉])

• delAtt(〈〈ALUNO, doutor〉〉, [(x, TRUE)|(x, doutor)← 〈〈ALUNO, tipo〉〉])

54

CAPITULO 5

UMA PROPOSTA DE SISTEMA DE SOFTWARE PARA

AUXILIO NA INTEGRACAO DE BANCOS DE DADOS

O trabalho desenvolvido nessa dissertacao alcanca seu auge neste capıtulo, onde e

apresentada uma proposta de sistema de software para integracao de bancos de dados

atraves do formalismo BAV (secao 4.4). O sistema de software nao foi implementado, uma

vez que o objetivo era o de moldar sua concepcao, seu funcionamento e suas necessidades,

deixando a sua implementacao para trabalhos futuros.

5.1 Visao Geral

Este sistema de software e utilizado na metodologia de integracao que aplica o for-

malismo nas fontes de dados como se estas estivessem em uma linha de montagem (secao

4.5). Nessa metodologia assume-se um esquema de uniao e cada esquema local tera de se

tornar compatıvel a uniao com o esquema assumido por meio de transformacoes BAV.

O objetivo deste sistema de software e auxiliar o usuario na geracao das transformacoes

BAV (secao 4.4) que tornarao a estrutura de um esquema local identica ao esquema de

uniao. Para alcancar esse objetivo o sistema orienta o usuario atraves das varias etapas

do processo consultando-o em momentos em que seja impossıvel para o sistema tomar

uma decisao.

De modo sucinto, o que se espera do funcionamento do sistema de software proposto

neste trabalho e que sejam fornecidos para ele dois esquemas, o primeiro relativo a um

banco de dados local e o segundo relativo ao esquema de uniao definido para a integracao.

A medida que realiza diversas consultas ao usuario o software deve fornecer a sequencia

de transformacoes necessaria para tornar a estrutura do esquema relativo ao banco de

dados local identica a estrutura do esquema de uniao. A figura 5.1 ilustra esse processo

mais nitidamente. Baseado nessas caracterısticas de funcionamento o sistema de software

55

foi batizado como: Sistema de Software para Auxılio na Geracao de Transformacoes BAV

para Integracao de Bancos de Dados, abreviado atraves da sigla SAI.

Figura 5.1: Funcionamento do Sistema SAI

Para gerar os esquemas de entrada em um formato aceitavel foi concebida superficial-

mente a ideia de um Software para Geracao dos Esquemas de Entrada, ou simplesmente

SGEE. O objetivo deste sistema de software e prover o usuario com ferramentas que permi-

tam a descricao dos objetos de um esquema de banco de dados (relacoes, atributos, chaves

primarias e chaves estrangeiras) e gere um arquivo onde seus objetos sejam representados

atraves de algum tipo de estrutura de dados compreendida pelo SAI. A representacao es-

colhida para os objetos do esquema ainda nao foi definida. Essa escolha sera postergada

para uma futura implementacao. Entre as possıveis estruturas imaginadas estao grafos,

matrizes ou XML.

Tanto o esquema de uniao quanto o esquema local devem ser gerados atraves do SGEE.

A definicao do esquema de uniao devera ser feita pelo lıder do projeto de integracao. A

definicao do esquema do banco de dados local ja existe e devera ser traduzida atraves do

SGEE pelo seu administrador.

O usuario do SAI deve estar familiarizado com o esquema de uniao, com o esquema

local que vai ser integrado e com o formalismo BAV. A primeira sugestao para o usuario

ideal do SAI seria o administrador do banco de dados local, uma vez que normalmente e

ele quem possui mais conhecimentos a respeito do esquema local. Conhecimentos sobre o

esquema de uniao podem ser repassados para ele atraves do lıder do projeto de integracao.

O unico problema sao os conhecimentos a respeito do formalismo BAV. Caso nao seja do

interesse do administrador do banco de dados local aprender o formalismo BAV ele devera

56

trabalhar em equipe com alguem que o conheca.

A figura 5.2 exibe um esboco de como seria a interface visual do programa. Pode-se

perceber quatro areas distintas na figura. Elas sao nomeadas como area do esquema de

uniao, area do esquema local, area das transformacoes e area de dialogo.

Figura 5.2: Visualizacao do Sistema SAI

Quando o SAI for inicializado com seus esquemas de entrada eles serao exibidos re-

spectivamente nas areas do esquema de uniao e do esquema local. O usuario podera

navegar tranquilamente atraves dos esquemas quando isso for necessario para resolver

qualquer tipo de duvida quanto a estrutura dos esquemas. As consultas ao usuario serao

feitas atraves da area de dialogo. Essas consultas poderao pedir para que ele indique

alguma relacao ou atributo especıfico no esquema local, o que sera feito com um clique

na relacao ou atributo na area do esquema local, ou poderao pedir que o usuario revise e

confirme alguma transformacao BAV que esteja sendo gerada. Apos ser confirmada cada

transformacao e armazenada na area de transformacoes e seu efeito e aplicado na area do

esquema local de modo que o usuario possa visualizar o que a transformacao causou.

57

Ao termino da execucao do SAI os esquema de entrada serao identicos e o conteudo

da area de transformacoes sera o resultado do processo de integracao.

5.2 O Funcionamento do SAI

Antes de explicar o funcionamento deve-se esclarecer alguns conceitos definidos para

este sistema de software.

Dois objetos sao equivalentes quando guardam o mesmo conceito semantico com o

mesmo formato de dados de modo que possam ser submetidos a uniao sem qualquer tipo

de problema.

A cada momento que o sistema descobrir que dois atributos sao equivalentes, sejam

eles atributos chaves ou nao, eles serao renomeados para que tenham o mesmo nome

e entao unificados, ou seja, anotados em uma tabela de unificacoes para que o sistema

saiba que nao deve mais se ocupar com eles. Cada anotacao na tabela de unificacoes sera

composta de um par, sendo o primeiro elemento um atributo de uma relacao do esquema

de uniao e o segundo elemento um atributo de uma relacao do esquema local.

A partir desses conceitos as atividades do SAI foram divididas em etapas distintas

conforme suas caracterısticas. Sao elas:

1. Remover Chaves Estrangeiras

2. Gerar Tabela de Correlacionamentos

3. Unificar Chaves Primarias

4. Unificar Atributos

5. Remover Objetos nao Unificados

6. Gerar Chaves Estrangeiras

Cada uma dessas etapas sera explicada a seguir. Para aqueles que queiram se aprofun-

dar mais no funcionamento de cada uma delas foi construıda uma especificacao informal

para cada uma dessas etapas. Estas especificacoes podem ser encontradas no Anexo B.

58

5.2.1 Remover Chaves Estrangeiras

Uma vez que o esquema local se tornara compatıvel a uniao com o esquema de uniao

e intuitivo que so se manterao no esquema local chaves estrangeiras que estejam ligadas

a relacoes cujos conceitos semanticos tambem estejam no esquema de uniao.

Mas chaves estrangeiras sao apenas restricoes que nao carregam nenhum tipo de

instancia. Entao, ao inves do sistema se dedicar a distinguir quais chaves estrangeiras

devem ser removidas do esquema local e quais nao, o sistema remove todas as chaves

estrangeiras e as adiciona novamente conforme o esquema de uniao quando o processo

estiver terminado.

A maior vantagem dessa atitude e a perda de complexidade do sistema ao lidar com

chaves estrangeiras. A maior desvantagem dessa atitude e a possıvel geracao de trans-

formacoes redundantes, uma vez que pode ocorrer de uma chave estrangeira ser removida

e gerada novamente da mesma forma. Mesmo assim a vantagem supera a desvantagem

tornando esse um preco pequeno a se pagar.

5.2.2 Gerar Tabela de Correlacionamentos

Esta etapa tem por objetivo decidir atraves de consultas ao usuario o que sera feito

com cada uma das relacoes do esquema local durante o restante do processo. Existem

apenas duas opcoes para cada relacao: ou e aplicada uma sequencia de transformacoes

a relacao de modo que ela se torne equivalente a uma relacao do esquema de uniao ou

entao as instancias relevantes da relacao do esquema local serao transferidas para outras

relacoes antes que ela seja apagada.

Tendo isso em vista foi criado o conceito da tabela de correlacionamentos. Essa tabela

representa uma funcao parcial e injetora tendo como domınio as relacoes do esquema de

uniao e tendo como imagem as relacoes do esquema local.

Para preencher a tabela de correlacionamentos e feita a seguinte pergunta ao usuario

para cada relacao do esquema de uniao: caso exista, indique a relacao do esquema local

que abriga os conceitos semanticos mais proximos daqueles guardados pela relacao do

esquema de uniao. Desse modo e criado um mapeamento onde cada elemento do conjunto

59

de relacoes do esquema de uniao aponta para um elemento distinto do conjunto de relacoes

do esquema local ou entao nao aponta para ninguem.

Nas etapas seguintes sera criada uma nova relacao no esquema local para cada relacao

do esquema de uniao cuja entrada na tabela de correlacionamentos nao aponte para

ninguem. Cada relacao do esquema local que participe da tabela de correlacionamentos

tera uma sequencia de transformacoes aplicada a ela. Cada relacao do esquema local

que nao participe da tabela de correlacionamentos sera apagada depois que as instancias

relevantes tenham sido transferidas para outras relacoes.

Para auxiliar o usuario durante a sua tarefa de responder as perguntas, o sistema

emprega a funcao Adivinho. Para cada relacao do esquema de uniao a funcao devolve

uma relacao do esquema local que julgue ser a melhor resposta para a pergunta feita ao

usuario. Essa funcao seria utilizada para dar uma sugestao de resposta ao usuario.

Infelizmente nao foi possıvel definir com precisao essa funcao devido a falta de acesso a

esquemas de bancos de dados construıdos em ocasioes distintas para um proposito similar.

Esses bancos de dados serviriam para testar e validar os parametros de decisao da funcao

adivinho. Mas entre os parametros sugeridos para essa funcao estariam:

• similaridade entre os nomes das relacoes;

• similaridade entre os nomes dos atributos chaves;

• numero de atributos chaves;

• tipos dos atributos chaves;

• numero de atributos.

5.2.3 Unificar Chaves Primarias

Esta etapa tem por objetivo gerar transformacoes que tornem o conjunto de chaves

primarias das relacoes do esquema local equivalentes as chaves primarias das relacoes do

esquema de uniao baseando-se na tabela de correlacionamentos.

60

Cada relacao do esquema de uniao sera submetida a esta etapa seguindo uma ordem

estipulada pela funcao ProximaRelacao. Essa funcao toma o esquema de uniao e a tabela

de unificacoes como parametros de entrada e devolve uma de suas relacoes como parametro

de saıda. Ela utiliza as chaves estrangeiras definidas no esquema de uniao para fazer

sua escolha. Basicamente ela ira devolver uma relacao do esquema de uniao que seja

filha do menor numero de relacoes que ainda nao tenham passado por essa etapa. Esta

polıtica mostrou-se bastante util para evitar a geracao de transformacoes desnecessarias

e simplicacao das mesmas.

Esta etapa e composta de duas etapas menores: resolucao de conflitos entre chaves

primarias e extracao de chaves primarias. Essas etapas menores serao utilizadas conforme

o estado de cada relacao do esquema de uniao em relacao a tabela de correlacionamentos.

Se uma relacao do esquema de uniao possuir uma relacao do esquema local correspon-

dente na tabela de correlacionamentos sera ativada a etapa resolucao de conflitos entre

chaves primarias que ira gerar transformacoes que alterem a relacao do esquema local.

O primeiro passo e gerar uma transformacao que renomeie a relacao do esquema local

de modo que ela fique com o mesmo nome da relacao do esquema de uniao. A seguir

o usuario devera ser consultado sobre a equivalencia do conjunto de atributos chave das

relacoes. Se forem equivalentes basta renomea-los conforme a necessidade e unifica-los.

Caso contrario serao feitas perguntas ao usuario sobre a origem das instancias de cada um

dos atributos chave com o objetivo de gerar transformacoes que os adicionem a relacao

do esquema local. Essas transformacoes serao apresentadas ao usuario porque resolvem

as situacoes mais simples mas precisam ser revisadas para que se adaptem aos casos

de conflito mais complicados. Por fim, se necessario, serao geradas transformacoes que

apaguem e recriem a restricao de chave primaria.

Mas se uma relacao do esquema de uniao nao possuir uma relacao do esquema local

correspondente na tabela de correlacionamentos sera ativada a etapa extracao de chaves

primarias que ira gerar transformacoes que criem uma nova relacao no esquema local.

Por enquanto esta relacao tera apenas seus atributos chave e esses serao equivalentes aos

atributos chave do esquema de uniao. Essa nova relacao ocupara o espaco vazio na tabela

61

de correlacionamentos.

O usuario devera indicar, se existir, a origem das instancias do conjunto de atributos

chave com o objetivo de gerar transformacoes que resolvem as situacoes mais simples

mas que precisam ser revisadas pelo usuario para se adaptarem aos casos de conflito mais

complicados. Caso a origem dessas instancias nao exista serao geradas transformacoes que

criem a relacao com um conjunto vazio de instancias. Por fim serao geradas transformacoes

que criem a restricao de chave primaria.

5.2.4 Unificar Atributos

Nas etapas anteriores foram geradas transformacoes que adicionaram relacoes ao es-

quema local de modo que a funcao parcial representada pela tabela de correlacionamentos

se tornasse uma funcao total. Agora cada relacao do esquema de uniao possui uma relacao

correspondente no esquema local e todas as chaves primarias foram unificadas.

O objetivo desta etapa e gerar transformacoes que determinem, para cada atributo

que nao seja uma chave primaria em cada relacao do esquema de uniao, um atributo no

esquema local que seja equivalente ao atributo do esquema de uniao.

A escolha da ordem em que as relacoes do esquema de uniao sao submetidas e definida

pela funcao ProximaRelacao adaptada para esta etapa, mas com o mesmo funcionamento.

Uma vez escolhida a relacao do esquema de uniao a ser trabalhada o sistema consulta a

tabela de correlacionamentos para saber qual e a relacao do esquema local correspondente.

Entao, para cada atributo da relacao do esquema de uniao, o usuario devera ser consul-

tado sobre a existencia de um atributo na relacao do esquema local que seja equivalente

ao atributo do esquema de uniao. Se esse atributo existir basta renomea-lo conforme

a necessidade e unifica-lo. Caso contrario o usuario sera consultado sobre a origem das

instancias desse atributo com o objetivo de gerar transformacoes que o adicionem a relacao

do esquema local. Essas transformacoes serao apresentadas ao usuario porque resolvem

as situacoes mais simples mas precisam ser revisadas para que se adaptem aos casos de

conflito mais complicados. Caso a origem das instancias de um atributo nao exista no

esquema local o sistema gerara uma transformacao que gere o atributo sem instancias.

62

Ao fim do processo para cada atributo ele deve ser unificado com seu correspondente no

esquema local.

5.2.5 Remover Objetos nao Unificados

Atualmente cada atributo de cada relacao do esquema de uniao, seja ele uma chave

primaria ou nao, esta unificado com um atributo do esquema local. O objetivo desta

etapa e gerar transformacoes que retirem do esquema local os atributos que nao foram

unificados e as relacoes que nao possuam atributos unificados.

Tudo que o sistema precisa fazer e gerar a transformacao e entrega-la ao usuario para

que ele a revise escrevendo a consulta que mostra como recuperar as instancias do objeto

que esta sendo removido. Mas essa parte do processo pode ser melhorada para o usuario

atraves de sugestoes de consultas. Para obter essas sugestoes surgiu o conceito de um

reversor de consultas.

O reversor de consultas pode ser explicado, de modo sucinto, atraves de um pequeno

exemplo. Suponha uma transformacao generica que adiciona um atributo, por exemplo.

Ela se apresenta na forma:

addAtt(〈〈 objeto destino 〉〉, [( tupla destino ) | ( tupla origem )← 〈〈 objeto origem 〉〉; (

outras tuplas ) ← 〈〈 outros objetos 〉〉; restricoes logicas ])

O objeto destino e o atributo que esta sendo adicionado a uma relacao do esquema. A

tupla destino representa tal atributo juntamente com quaisquer funcoes a serem aplicadas

em seus valores. O objeto origem representa o atributo do qual as instancias estao sendo

retiradas para preencherem o atributo destino. A tupla origem esta intrinsicamente ligada

a tupla destino uma vez que sao seus valores que fazem a conexao entre o objeto destino

e o objeto origem. Outras tuplas, outros objetos e restricoes logicas sao utilizados para

filtrar as instancias na transformacao.

E muito frequente surgir a necessidade de se retirar do esquema o objeto origem para

alguma transformacao que ja tenha sido gerada anteriormente. Apos alguns estudos pode-

se verificar que na maior parte dos casos simples tudo o que se tem de fazer e gerar uma

63

transformacao da forma:

delAtt(〈〈 objeto origem 〉〉, [( tupla origem ) | ( tupla destino ) ← 〈〈 objeto destino 〉〉])

O tipo da transformacao foi invertido. Os objetos e tuplas de origem e de destino

foram invertidos. As funcoes que eram aplicadas a tupla destino agora tem sua funcao

inversa aplicadas a tupla origem. As outras tuplas, os outros objetos e as restricoes logicas

foram ignoradas porque sua aplicacao so tinha valor na transformacao anterior.

A consulta resultante foi batizada de ”consulta reversa”da consulta original e o mecan-

ismo que a constroi foi batizado de reversor de consultas.

Desse modo antes de entregar uma transformacao que retire algum objeto do esquema

para o usuario o sistema pode buscar nas transformacoes geradas nas fases anteriores uma

transformacao que permita gerar a transformacao reversa que se adeque as necessidades

do usuario.

Infelizmente nao foi possıvel construir o reversor de consultas nem especifica-lo com

precisao nessa dissertacao devido a extensao do trabalho ja apresentado e o tempo necessario

para desenvolve-lo, restando apenas deixa-lo para trabalhos futuros.

5.2.6 Gerar Chaves Estrangeiras

Nesta etapa o processo de geracao de transformacoes esta praticamente completo.

Todos os atributos do esquema de uniao ja foram unificados com os atributos do esquema

local e todos os atributos que nao haviam sido unificados com ninguem ja foram retirados

do esquema.

Tudo o que resta a fazer e gerar as transformacoes que recriem as chaves estrangeiras

no esquema local de modo que elas fiquem identicas ao esquema de uniao.

Por fim, a sequencia de transformacoes geradas durante todas as etapas anteriores

sao o resultado do processo sendo suficientes para tornar a estrutura do esquema local

identica a estrutura do esquema de uniao.

64

5.3 Vantagens do Sistema SAI

O SAI foi concebido com o objetivo de auxiliar um administrador a escrever as

trasnformacoes BAV necessarias para tornar dois esquemas de bancos de dados com-

patıveis a uniao. Infelizmente resultados como a automatizacao completa do processo

sem a participacao humana ou mesmo uma participacao humana que nao necessitasse de

conhecimentos profundos sobre os esquemas ou sobre o formalismo BAV nao puderam ser

alcancados.

Mas essa proposta de sistema de software SAI traz muitas vantagens ao usuario, como

por exemplo:

• orientacao do processo de geracao de transformacoes, dividindo-o por etapas e

organizando-o de modo a torna-lo mais simples e facil de entender;

• agilidade no processo de escrita, o usuario tem de pensar apenas nos casos que o

sistema nao pode decidir sozinho;

• geracao automatica de transformacoes para os casos mais simples;

• geracao de sugestoes para os casos mais complexos, fornecendo a solucao parcial ao

usuario para revisao;

• interface visual e amigavel para o usuario.

65

CAPITULO 6

CONCLUSAO

O dos maiores objetivos da integracao de bancos de dados e fornecer uma interface

integrada e uniforme para consultas em diversos bancos de dados que descrevam os mesmos

objetos do mundo real. Assim um sistema de integracao de dados possibilita ao usuario

se concentrar no que ele deseja sem ter de pensar em como conseguir essa informacao.

De modo a permitir que o sistema de integracao de banco de dados possa responder



submetida a ele como novas consultas submetidas aos esquemas locais [9].

O objetivo desta dissertacao foi o de propor um sistema de software que automatize

parcialmente o processo de integracao de bancos de dados atraves da geracao de trans-

formacoes do formalismo BAV.

Mas antes de chegar a esse objetivo foram geradas contribuicoes menores como:

• foram estudadas diferentes visoes do processo de integracao de bancos de dados

unindo varias de suas fases de modo a se obter uma divisao mais completa de suas

etapas;

• foi realizado um estudo sobre os casos de conflito entre esquemas existentes, apre-

sentando os resultados atraves de exemplos no modelo relacional de modo a tornar

seu entendimento mais claro;

• para cada um dos casos de conflito existentes foram apresentadas possıveis solucoes

atraves do formalismo BAV com o objetivo de validar sua capacidade de resolver

tais conflitos;

• uma vez que nenhuma das metodologias utilizadas pelo formalismo BAV e bem

descrita no material ja publicado, o autor desta dissertacao produziu um texto que

66

explica com maiores detalhes essas metodologias de modo a tornar claro o papel do

sistema de software no processo de integracao de bancos de dados.

O objetivo do sistema de software proposto foi auxiliar o usuario na geracao das

transformacoes BAV que tornarao a estrutura de um esquema local identica ao esquema

de uniao. Para alcancar esse objetivo o sistema orienta o usuario atraves das varias etapas

do processo consultando-o em momentos em que seja impossıvel para o sistema tomar uma

decisao.

Este sistema de software foi batizado como Sistema de Software para Auxılio na

Geracao de Transformacoes BAV para Integracao de Bancos de Dados, abreviado atraves

da sigla SAI.

Ate onde se tem conhecimento, o sistema de softwarte SAI e a primeira tentativa de

automatizacao parcial da geracao de transformacoes BAV no processo de integracao de

bancos de dados.

Este sistema traz muitas vantagens ao usuario encarregado da tarefa de integracao,

tais como:

• orientacao do processo de geracao de transformacoes, dividindo-o por etapas e

organizando-o de modo a torna-lo mais simples e facil de entender;

• agilidade no processo de escrita, o usuario tem de pensar apenas nos casos em que

o sistema nao pode decidir sozinho;

• geracao automatica de transformacoes para os casos mais simples;

• geracao de sugestoes para os casos mais complexos, fornecendo a solucao parcial ao

usuario para revisao;

• interface visual amigavel para o usuario.

Mas esta proposta deixou questoes em aberto, que deverao ser realizadas em trabalhos

futuros. Sao elas:

• finalizacao da especificacao do Software para Geracao dos Esquemas de Entrada, ou

simplesmente SGEE, bem como a sua implementacao.

67

• testar os parametros da funcao adivinho de modo a otimizar o seu resultado, melho-

rando assim as sugestoes dadas pelo SAI;

• finalizacao da especificacao reversor de consultas bem como a sua implementacao;

• implementar o sistema de software SAI, realizar testes e apresentar seus resultados.

68

BIBLIOGRAFIA

[1] Serge Abiteboul, Richard Hull, e Victor Vianu. Foundations of Databases. Addison-

Wesley Publishing Company, 1995.

[2] C. Batini, M. Lenzerini, e S. B. Navathe. A comparative analysis of methodologies

for database schema integration. ACM Computing Surveys (CSUR), 18(4):323–364,

1986.

[3] M. Boyd, P. McBrien, e N. Tong. The automed schema integration repository. 19th

British National Conference on Databases (BNCOD19), Lecture Notes in Computer

Science (LNCS), 2405:42–45, 2002.

[4] Michael Boyd, Charalambos Lazanitis, Sasivimol Kittivoravitkul, Peter McBrien,

e Nikos Rizopoulos. An overview of the automed repository. Relatorio tecnico,

AutoMed Project, 2004.

[5] Peter Buneman, Leonid Libkin, Dan Suciu, Val Tannen, e Limsoon Wong. Compre-

hension syntax. SIGMOD Record, 23(1):87–96, 1994.

[6] Sudarshan Chawathe, Hector Garcia-Molina, Joachim Hammer, Kelly Ireland, Yan-

nis Papakonstantinou, Jeffrey D. Ullman, e Jennifer Widom. The TSIMMIS project:

Integration of heterogeneous information sources. 16th Meeting of the Information

Processing Society of Japan, paginas 7–18, Tokyo, Japan, 1994.

[7] E. Jasper, A. Poulovassilis, e L. Zamboulis. Processing iql queries and migrating

data in the automed toolkit. Relatorio tecnico, AutoMed Project, 2003.

[8] Won Kim e Jungyun Seo. Classifying schematic and data heterogeneity in multi-

database systems. Computer, 24(12):12–18, 1991.

69

[9] Alon Y. Levy. Logic-based techniques in data integration. Jack Minker, editor, Work-

shop on Logic-Based Artificial Intelligence, Washington, DC, June 14–16, 1999, Col-

lege Park, Maryland, 1999. Computer Science Department, University of Maryland.

[10] Alon Y. Levy, Anand Rajaraman, e Joann J. Ordille. Querying heterogeneous infor-

mation sources using source descriptions. Proceedings of the Twenty-second Interna-

tional Conference on Very Large Databases, paginas 251–262, Bombay, India, 1996.

VLDB Endowment, Saratoga, Calif.

[11] P. McBrien. The university database integration: An automed example. Relatorio

tecnico, AutoMed Project, 2003.

[12] P. McBrien e A. Poulovassilis. A general formal framework for schema transformation.

Relatorio Tecnico 98-05, King’s College London, 1998.

[13] P. McBrien e A. Poulovassilis. Data integration by bi-directional schema transfor-

mation rules. 19th International Conference on Data Engineering, 2003.

[14] P. McBrien, A. Poulovassilis, N. Tong, e E. Jasper. View generation and optimisation

in the automed data integration framework. Relatorio tecnico, AutoMed Project,

2003.

[15] Peter McBrien e Alexandra Poulovassilis. A formalisation of semantic schema inte-

gration. Information Systems, 23(5):307–334, 1998.

[16] Peter McBrien e Alexandra Poulovassilis. Automatic migration and wrapping of

database applications - a schema transformation approach. International Conference

on Conceptual Modeling / the Entity Relationship Approach, paginas 96–113, 1999.

[17] Peter McBrien e Alexandra Poulovassilis. A uniform approach to inter-model trans-

formations. Conference on Advanced Information Systems Engineering, paginas 333–

348, 1999.

[18] Christine Parent e Stefano Spaccapietra. Issues and approaches of database integra-

tion. Commun. ACM, 41(5es):166–178, 1998.

70

[19] A. Poulovassilis. The automed intermediate query language. Relatorio tecnico, Au-

toMed Project, 2001.

[20] A. Poulovassilis. A tutorial on the iql query language. Relatorio tecnico, AutoMed

Project, 2004.

[21] Amit P. Sheth e Vipul Kashyap. So far (schematically) yet so near (semantically).

Proceedings of the IFIP WG 2.6 Database Semantics Conference on Interoperable

Database Systems (DS-5), paginas 283–312. North-Holland, 1993.

[22] Abraham Silberschatz, Henry F. Korth, e S. Sudarshan. Database System Concepts.

WCB/McGraw-Hill, 1998.

[23] Stefano Spaccapietra, Christine Parent, e Yann Dupont. Model independent asser-

tions for integration of heterogeneous schemas. The VLDB Journal, 1(1):81–126,

1992.

[24] Jeffrey D. Ullman. Principles of Database Systems. Computer Science Press, 1982.

[25] Jeffrey D. Ullman. Principles of Database and Knowledge - Base Systems. Computer

Science Press, 1988.

[26] Gottfried Vossen. Data Models, Database Languages and Database Management Sys-

tems. Addison-Wesley Publishing Company, 1990.

71

ANEXO A

A.1 O Modelo de Dados Baseado em Hipergrafos

A.1.1 Nocoes Basicas

Muitos formalismos e metodologias ja foram criados para resolver o problema da inte-

gracao de bancos de dados. A. Poulovassilis e P. McBrien criaram um formalismo [12]

que procura eliminar as diferencas entre esquemas atraves de transformacao dos mesmos.

Este formalismo e denominado modelo de dados baseado em hipergrafos (hipergraph data

model - HDM).

Suponha a existencia de dois conjuntos disjuntos: o conjunto V alue, composto por

todos os valores, e o conjunto Name, composto por todos os nomes que um vertice ou

uma aresta podem receber.

O conjunto Scheme e definido recursivamente da seguinte maneira:

• Name ⊆ Scheme;

• 〈n0, n1, . . . , nm〉 ∈ Scheme se m ≥ 1, n0 ∈ Name e ni ∈ Scheme para todo 1 ≤ i ≤

m.

A constante Null ∈ Name (tambem chamada de V oid). Para qualquer conjunto T ,

Seq(T ) indica o conjunto de sequencias finitas construıda com membros de T.

Desse modo, um Esquema S e uma tripla 〈Nodes, Edges, Constraints〉 (representando

respectivamente o conjunto dos vertices, arestas e restricoes) onde:

• Nodes ⊆ Name;

• Edges ⊆ Name X Seq(Scheme) de modo que para todo 〈n0, n1, . . . , nm〉 ∈ Edges, ni ∈

Nodes ∪ Edges para todo 1 ≤ i ≤ m;

• Constraints e um conjunto de expressoes que resultam valores booleanos e cujas

variaveis pertencem ao conjunto Nodes ∪ Edges.

72

Desse modo, Nodes e Edges definem um hipergrafo aninhado e rotulado. Aninhado

porque uma aresta pode se ligar a qualquer numero de vertices e/ou outras arestas.

Vertices sao identificados unicamente por seus nomes. Arestas e restricoes podem ter um

nome opcional associado a elas. A linguagem utilizada por restricoes ou por quaisquer

consultas direcionadas ao esquema nao esta associada ao formalismo de modo a dar-lhe

mais liberdade.

Dado um esquema S = 〈Nodes, Edges, Constraints〉, uma instancia de S e um con-

junto I tal que I ⊆ P (Seq(V alue)) e exista uma funcao ExtS,I : Nodes ∪ Edges −→

P (Seq(V alue)) onde:

• cada conjunto pertencente a imagem de ExtS,I pode ser derivado atraves de uma

expressao sobre os conjuntos de I;

• cada conjunto em I pode ser derivado atraves de uma expressao sobre os conjuntos

da imagem de ExtS,I ;

• para cada aresta 〈n0, c1, . . . , cm〉 ∈ Edges, cada sequencia s ∈ ExtS,I(〈n0, c1, . . . , cm〉)

contem m subsequencias s1, . . . , sm onde si ∈ ExtS,I(ci) para todo 1 ≤ i ≤ m (in-

tegridade de domınio);

• para todo c ∈ Constraints, a expressao c[c1/ExtS,I(c1), . . . , cn/ExtS,I(cn)] retorna

verdadeiro, onde c1, . . . , cn sao elementos de Nodes ∪Edges.

Tal funcao ExtS,I e chamada de mapeamento de extensoes de S para I.

Um modelo e uma tripla 〈S, I, ExtS,I〉 onde S e um esquema, I e uma instancia de S e

ExtS,I e uma funcao de mapeamento de extensoes de S para I. O conjunto dos modelos

e chamado de Models.

Dois esquemas sao equivalentes se eles tem o mesmo conjunto de instancias. Dada uma

condicao f , um esquema S condicionalmente contem um esquema S ′ com respeito a f se

qualquer instancia de S ′ satisfazendo f tambem e uma instancia de S. Dois esquemas S e

S ′ sao condicionalmente equivalentes com respeito a f se ambos condicionalmente contem

um ao outro com respeito a f .

73

A.1.2 Transformacoes Primitivas

As transformacoes primitivas suportadas pelo HDM sao listadas a seguir. Cada uma das

transformacoes e uma funcao que quando aplicada a um modelo retorna um novo modelo.

Cada transformacao possui uma exigencia que deve se manter para a tranformacao resultar

em sucesso. Transformacoes que falham retornam um modelo indefinido (ou invalido)

representado por φ. Qualquer transformacao aplicada a φ retorna φ.

• renameNode(fromName, toName) - Renomeia um vertice. Exigencia: nao deve

existir um vertice ja com nome igual a toName.

• renameEdge(〈fromName, c1, . . . , cm〉, toName) - Renomeia uma aresta. Exigencia:

nao deve existir uma aresta ja com nome igual a toName.

• addConstraint c - Adiciona uma nova restricao c. Exigencia: c deve retornar ver-

dadeiro.

• delConstraint c - Apaga uma restricao c. Exigencia: c deve existir.

• addNode(name, q) - Adiciona um vertice chamado name cuja extensao e dada pela

consulta q. Exigencia: nao deve existir um vertice ja com nome igual a name.

• delNode(name, q) - Apaga um vertice chamado name. q e um consulta que deter-

mina como a extensao do vertice apagado pode ser recuperada a partir dos objetos

restantes do esquema. Exigencia: o vertice deve existir e nao deve participar de

nenhuma aresta.

• addEdge(〈name, c1, . . . , cm〉, q) - Adiciona uma nova aresta entre uma sequencia de

objetos c1, . . . , cm do esquema. A extensao da aresta e determinada pelo valor da

consulta q. Exigencia: a aresta ja nao existe, c1, . . . , cm existem e q satisfaz as

restricoes de domınio apropriadas.

• delEdge(〈name, c1, . . . , cm〉, q) - Apaga uma aresta. q e um consulta que deter-

mina como a extensao da aresta apagada pode ser recuperada a partir dos objetos

restantes do esquema. Exigencia: a aresta existe e nao participa de outras arestas.

74

Para cada uma dessas transformacoes existe uma outra versao que toma um argumento

extra. Este argumento e uma condicao que deve ser satisfeita para que a transformacao

tenha sucesso.

Uma transformacao composta e uma sequencia de n ≥ 1 transformacoes primitivas.

Uma transformacao t e dependente do esquema (schema-dependent - s-d) com respeito ao

esquema S se nao retornar φ para qualquer modelo de S, caso contrario t e dependente da

instancia (instance-dependent - i-d) com respeito a S. E facil perceber que se um esquema

S pode ser transformado em um esquema S ′ atraves de transformacoes dependentes do

esquema e vice-versa, entao S e S ′ sao equivalentes. Se S pode ser transformado em S ′

atraves de transformacoes dependentes da instancia com uma exigencia f e vice-versa,

entao S e S ′ sao condicionalmente equivalentes com respeito a f .

Para cada transformacao primitiva t tal que t((S, I, ExtS,I)) �= φ existe uma trans-

formacao primitiva inversa t−1 tal que t−1(t((S, I, ExtS,I))) = (S, I, ExtS,I). No caso de

t possuir um argumento extra c para validar a transformacao ele nao precisa estar em t−1

uma vez que ele foi validado em t. Uma listagem das transformacoes inversas e apresen-

tada na tabela 6.1.

Transformacao t Transformacao t−1

renameNode(from, to) c renameNode(to, from)renameEdge(〈from, schemes〉, to) c renameEdge(〈to, schemes〉, from)addConstraint q c delConstraint qdelConstraint q c addConstraint qaddNode(n, q) c delNode(n, q)delNode(n, q) c addNode(n, q)addEdge(e, q) c delEdge(e, q)delEdge(e, q) c addEdge(e, q)

Tabela 6.1: Transformacoes Inversas do Formalismo HDM

A reversibilidade das transformacoes primitivas pode ser generalizada para qualquer

transformacao composta que tenha resulte em sucesso: dada uma tranformacao composta

t1; . . . ; tn a sua transformacao inversa e t−1n ; . . . ; t−1

1 .

Mesmo quando dois bancos de dados sao designados para guardar a mesma informacao

eles provavelmente vao ser um pouco diferentes e nao serao exatamente equivalentes. Para

75

lidar com tais casos foram criadas [16] mais quatro transformacoes para lidar com tais

situacoes. Elas sao definidas a partir das transformacoes primitivas existentes na tabela

6.2.

extendNode n = addNode(n, V OID)extendEdge n = addEdge(e, V OID)contractNode n = delNode(n, V OID)contractEdge n = delEdge(e, V OID)

Tabela 6.2: Transformacoes Adicionais do Formalismo HDM

Mais informacoes sobre a utilizacao e evolucao deste formalismo podem ser encontradas

em [15] onde foi demonstrado que o formalismo consegue suportar todas as trasnformacoes

usadas na integracao de esquemas utilizando o modelo de dados entidade-relacionamento

e em [17] onde foi demonstrado que o formalismo pode ser aplicado para varias linguagens

de modelagem de alto nıvel como o modelo de dados entidade-relacionamento, relacional,

documentos da Internet e ate mesmo UML.

76

ANEXO B

B.1 Observacoes Gerais

A seguir serao apresentadas especificacoes informais de cada uma das etapas do sistema de

software SAI. Maiores explicacoes sobre cada uma dessas etapas podem ser encontradas

no capıtulo 5.

Letras do alfabeto escritas em letra maiusculas representam relacoes. Quando acom-

panhadas do sinal ’ representam um atributo da relacao. Quando utilizadas dentro de

transformacoes representam o nome do objeto e nao o objeto em si. Quando utilizadas

fora das transformacoes representam o objeto em si e nao apenas seu nome.

Foram definidas algumas abreviaturas nas especificacoes para as palavras que ocorriam

com mais frequencia. Sao elas:

• rel. = relacao

• rels. = relacoes

• esq. = esquema

• atr. = atributo

• atrs. = atributos

B.2 Etapas do SAI

B.2.1 Remover Chaves Estrangeiras

Para cada chave estrangeira com uma rel. filha A e uma rel. pai B noesq. local:

Gerar transformacao sem revisao do usuario:delFK(<< rel. A, <<rel. A, atrs. da chave estrangeira na rel. A>>,rel. B, <<rel. B, atrs. da chave estrangeira na rel. B>>>>)

77

B.2.2 Gerar Tabela de Correlacionamentos

Para cada rel. A no esq. de uniao:

Aplicar a funcao adivinho fornecendo a rel. A e obtendo uma rel. Bdo esq. local.

Perguntar ao usuario qual e a rel. do esq. local que ele escolhe para fazero correlacionamento, fornecendo como sugestao a rel. B.

Adicionar a informacao na tabela de correlacionamentos.

B.2.3 Unificar Chaves Primarias

Enquanto existirem rels. no esq. de uniao com chaves primarias nao unificadas:

Aplicar a funcao ProximaRelacao para escolher uma rel. A do esq. deuniao.

Verificar se existe uma rel. B no esq. local correspondente a rel. A natabela de correlacionamentos:Se sim:

Se o nome da rel. A for diferente do nome da rel. B:

Gerar transformacao sem revisao do usuario:renRel(<< rel. B >>, << rel. A >>)

Executar a etapa Resolucao de Conflitos entre Chaves Primarias passando Ae B como parametros.

Se nao:

Executar a etapa Extracao de Chaves Primarias passando A como parametro:

78

Funcao ProximaRelacao

Objetivo: Indicar a proxima rel. a ser trabalhada na fase Unificar Chaves Primariasou na fase Unificar Atributos.Parametro de Entrada: esq. de uniao e fase atual.Parametro de Saıda: rel. do esq. de uniao.

Para cada rel. A do esq. de uniao em que haja algum att. chave nao unificado(fase Unificar Chaves Primarias) ou algum att. nao chave nao unificado (faseUnificar Atributos):

Para cada chave estrangeira em que A for filha de uma rel. cujos atts. chavesnao tenham sido unificados (fase Unificar Chaves Primarias) ou que haja atts.nao chave nao unificados (fase Unificar Atributos) A recebe 1 ponto.

Guardar a quantidade de pontos que A recebeu.

Devolver como resultado da funcao uma das rels. que tenha recebido o menornumero de pontos.

79

B.2.3.1 Resolucao de Conflitos entre Chaves Primarias

Lembrete: esta estapa recebe uma rel. A do esq. de uniao e uma rel. B do esq.local da etapa anterior.

Perguntar ao usuario se o conjunto de atts. chave de A e B sao equivalentes.Se sim:

Para cada atr. chave A’ da rel. A ainda nao unificado:

Perguntar ao usuario qual e o atr. chave B’ da rel. B equivalente ao att.A’ da rel. A.

Se o nome do att. A’ for diferente do nome do att. B’:

Gerar transformacao sem revisao do usuario:renAtt(<< att. B’ >>, << att. A’ >>)

Unificar A’ e B’.

Se nao:

Para cada atr. chave A’ da rel. A ainda nao unificado:

Pedir ao usuario para indicar, caso exista, um atr. B’ na rel. B que sejaequivalente ao atr. A’ da rel. A.Se sim:.




Se nao:

Pedir ao usuario para indicar, caso exista, um atr. C’ de uma rel. Cpertencente ao esq. local do qual possam ser extraıdas as instanciasdo atr. A’ da rel. A.Se sim:

Gerar transformacao com revisao do usuario:addAtt(<< rel. A, att. A’ >>, [(x1, . . . , xn, y)| (x1, . . . , xn, y)←<< rel. C, att. C’ >>])(Obs: O lista de atts. (x1, . . . , xn) se refere aos atts. chaves de B.)

Unificar A’ com o atr. criado.

Se nao:

Gerar transformacao com revisao do usuario:extAtt(<< rel. B, att. A’ >>, void)

Remover a restricao das chaves primarias da rel. B:delPK(<< rel. B, << rel. B, lista de atrs. chaves de B >>>>)

Recriar a restricao das chaves primarias da rel. B conforme a rel. A:delPK(<< rel. A, << rel. A, lista de atrs. chaves de A >>>>)

80

B.2.3.2 Extracao de Chaves Primarias

Lembrete: esta estapa recebe uma rel. A do esq. de uniao da etapa anterior.

Perguntar ao usuario se e possıvel obter as instancias do conjunto de atts.chaves atraves do esq. local ou atraves de valores fixos.Se sim:

Pedir para o usuario indicar, se existir, a rel. B no esq. local do qual sevai extrair o conunto de atts. chaves:

Gerar transformacao com revisao do usuario:addRel(<< rel. A >>, [(x1, . . . , xn) | (x1, . . . , xn) ←<< rel. B >>])(Obs: O valor n e o numero de atts. chaves da rel. A.)

Para cada att. chave A’ da rel. A:

Gerar transformacao sem revisao do usuario:addAtt(<< rel. A, att. A’ >>, [(x1, . . . , xk, . . . , xn, xk)| (x1, . . . , xn)←<< rel. A >>])(Obs: O valor k e um possıvel valor de n relativo ao att. A’.)


Gerar transformacao sem revisao do usuario:addPK(<< rel. A << rel. A, atts. chave da rel. A >>>>)

Se nao:

Gerar transformacao sem revisao do usuario:extRel(<< rel. A >>, void )

Para cada att. A’ chave ou nao chave da rel. A:

Gerar transformacao sem revisao do usuario:extAtt(<< rel. A , att. A’ >>, void )

Gerar transformacao sem revisao do usuario:addPK(<< rel. A , << atts. chaves de A >>>>)

Alterar a entrada na tabela de correlacionamentos de modo que a entradarelativa a rel. A aponte para a rel. criada.

81

B.2.4 Unificar Atributos

Enquanto existirem rels. no esq. de uniao com atts. nao unificados:

Aplicar a funcao ProximaRelacao para escolher uma rel. A do esq. deuniao e tomar como rel. B a rel. do esq. local correspondente natabela de correlacionamentos.

Para cada att. nao unificado A’ da rel. A do esq. de uniao:

Pedir para o usuario indicar, se existir, um att. B’ na rel. B do esq.local que seja equivalente a A’.Se sim:




Se nao:

Pedir para o usuario indicar, se existir, um att. C’ de uma rel. C do esq.local de onde possam ser extraıdas as instancias do atr. A’ da rel. A.Se sim:

Gerar transformacao com revisao do usuario:addAtt(<< rel A, att. A’ >>, [(x1, . . . , xn, y)| (x1, . . . , xn, y)←<< rel. C, att. C’ >>])


Se nao:

Gerar transformacao sem revisao do usuario:extAtt(<< rel A, att. A’ >>, void )


82

B.2.5 Remover Objetos nao Unificados

Para cada rel. A do esq. local com atts. nao chaves nao unificados:

Para cada att. A’ da rel. A que nao tenha sido unificado:

Tentar encontrar nas transformacoes geradas uma transformacao reversa parao att. A’.Se sim:

Gerar transformacao com revisao do usuario:delAtt(<< rel A, att. A’ >>, transformacao reversa )

Se nao:

Gerar transformacao com revisao do usuario:extAtt(<< rel A, att. A’ >>, void )

Para cada rel. A do esq. local com atts. chaves nao unificados:

Gerar transformacao sem revisao do usuario:delPK(<< rel. A << rel. A, atts. chaves da rel. A >>>>)

Para cada att. chave A’ da rel. A que nao tenha sido unificado:

Gerar transformacao sem revisao do usuario:delAtt(<< rel. A, att. A’ >>, [(x1, . . . , xk, . . . , xn, xk)| (x1, . . . , xn)←<< rel. A >>])(Obs: O valor k e um possıvel valor de n relativo ao att. A’.)

Tentar encontrar nas transformacoes geradas uma transformacao reversa paraa rel. A.Se sim:

Gerar transformacao com revisao do usuario:delRel(<< rel A >>, transformacao reversa )

Se nao:

Gerar transformacao com revisao do usuario:extRel(<< rel A >>, void )

B.2.6 Gerar Chaves Estrangeiras

Para cada chave estrangeira com uma rel. filha A e uma rel. pai B noesq. de uniao:

Gerar transformacao sem revisao do usuario:addFK(<< rel. A, <<rel. A, atrs. da chave estrangeira na rel. A>>,rel. B, <<rel. B, atrs. da chave estrangeira na rel. B>>>>)

alessandro rodrigues zamboni

Documents