Interoperabilidade Ulrich Schiel [email protected] (C) COPIN - Coordenação de Pós-Graduação em Informática UNIVERSIDADE FEDERAL DE CAMPINA GRANDE

Interoperabilidade

Ulrich [email protected]

(C) COPIN - Coordenação de Pós-Graduação em InformáticaUNIVERSIDADE FEDERAL DE CAMPINA GRANDE

Roteiro

• Bibliografia• Histórico• Arquiteturas de distribuição• Data Warehouses• Heterogenidade• Conceitos de distribuição• Transparência• Extração e integração• Processamento de consultas• Controle de Concorrência• Data Warehouse-criação e atualização• Seminários• Projeto

BIBLIOGRAFIA O. Bukhres& A. Elmagarmid (eds.) Object Oriented Multidatabase Systems,

Prentice-Hall, (1996) (capítulos 1-9)SISTEMAS: Pegasus (HP), VODAK/KODIM (GMD-IPSI), OIS/CIS(ESPRIT-Bertino),, EIS/XAIT (Xerox), DOMS (GTE-Labs:Buchman, Ozsu, Brodie),Carnot (MCC-Woelk), Thor (MIT-Liskov), FBASE (Purdue-Mullen), InterBase* (Purdue-Bukhres), A La Carte (U.o.Colorado, HKBMS (Florida-Su)IRO-DB (ESPRIT-Versailles, GMD,)(Caps.10-20)

M.T. Özsu, U. Dayal & P. Valduriez (eds.) Distributed Object Management, Morgan Kaufmann (1994)(Part 6. Interoperability - PP. 304-398

M.T. Özsu, & P. ValduriezPrincípios de Bancos de Dados Distribuidos – 2ª Edição, Campus (2001)

(Capítulo 4-Arquiteturas DDBMS; Cap. 15 – Interoperabilidade)

BIBLIOGRAFIA

M. Jarke, M. Lenzerini, Y. Vassiliou & P. Vassiliadis Fundamentals of Data Warehouses, Springer Verlag, 2000 (itens 1.1, 1.2, 1.3, 2.1 e capítulos 3 e 4.1,4.2, 4.3) Os autores coordenam um projeto ESPRIT, denominado DWQ SISTEMAS:Carnot, SIMS, Inf. Manifold, TSIMMIS, Sqirrel, WHIPS)

V. Poe, P. Klauer & S. Probst Building a Data Warehouse for Decision Support -2nd ed. Prentice-Hall, 1998

(Cap. 8 - Data Integration)

W. Kim (ed.) Modern Database Systems, Addison Wesley (1995) Part II - Interoperating Legacy Systems - Cap. 25-29 SISTEMAS - UniSQL/M, EDA/SQL, Pegasus, ADDS(Cap. 30-33)

H. Garcia-Molina, J. Ullman & J. Widom Database System Implementation, Prentice-Hall, 2000

(capítulo 11 - Information Integration, §11.1 e 11.2)

BIBLIOGRAFIA - cont.[Cea98] D. Calvanese et.al. Information Integration: conceptual modeling and reasoning support,

Proc. 6th Intl. Conf. on Cooperative Information Systems -CoopIS, 1998, pp. 280-

291

[BLN86] C. Batini, M. Lenzerini, S. Navathe A comparative analysis of methodologies for database

schema integration, ACM Comp. Surveys 18(4), 1986 pp. 323-364

[Gea97] H. Garcia-Molina et.al. The TSIMMIS approach to mediation: data models and languages,

J. Intell. Information Systems 8:2, 1997, pp.117-132

[HZ96] R. Hull & G. Zhou A framework for supporting data integration using the materialized and

virtual approaches, Proc. of ACM SIGMOD Conference, 1996, pp.481-492

[O 97] R.J. Orli Data extraction, transformation, and migration tools, Kismet Corp,

http://www.kismeta.com/ex2.com

[PGW95] Y. Papakonstantinou, H. Garcia-Molina & J. Widom Object exchanges across heterogeneous

information sources, Proc. Intl. Conf on Data Engineering 1995 pp. 251-260

[SL90] A.P. Sheth & J.A. Larson Federated Databases for managing distributed, heterogeneous,

and autonomous databases ACM Computing Surveys 22:3, 1990, pp.183-236

[Tra04] R. Traunmüller (ed.) Third Intl. Conf EGOV 2004, LNCS 3183, Zaragoza 2004

Seminários / Projetos

Temas para seminários:• • • Projetos – especificação da integração de fontes heterogêneas em:• F-Logic / FLORA• Description Logic• Z

HISTÓRICO

1. Dados independentes

2. Dados Integrados

• problemas de redundância• problemas de inconsistência

• novas tecnologias (mainframes,..)

HISTÓRICO

3. Dados distribuídos

• questões gerenciais• questões políticas• novas tecnologias (micros, comunicação, internet)

2. Dados Integrados

HISTÓRICO

4. Dados operacionais distribuídos e gerenciais centralizados

• heterogeneidade• necessidades gerenciais e estratégicas (históricos, agregados,.)

• assincronismo operacional X gerencial

3. Dados distribuídos

SISTEMAS DISTRIBUIDOS

Usuário global

Usuário local

BANCOS DE DADOS DISTRIBUÍDOS

• Banco de Dados Distribuído homogêneo

• Banco de Dados Distribuído heterogêneo = Banco de Dados Federado = Multibanco de Dados

• Data Warehouse

PROJETO TOP-DOWN

PROJETO BOTTOM-UP

MULTIBANCOS DE DADOS

MDBS

Integrado (não-federado)(sem autonomia local)

federado

Fracamente acoplado(sem esq. Global)

Fortemente acoplado(com esq. Global)

Federaçãosimples

Federaçãomúltipla

ACESSO AOS DADOS

• Com esquema global

• Sem esquema global • Com dados

globais

• Sem dados globais

ARQUITETURAS DE DISTRIBUIÇÃO

• Aspectos:

• Autonomia: – 0 = integração total– 1 = autonomia parcial– 2 = isolamento total

• Distribuição:– 0 = centralizado– 1 = sistemas cliente/servidor– 2 = sistemas peer-to-peer

• Heterogeneidade: – 0 = homogêneo– 1 = heterogêneo


• Combinações:

• (A0,D0,H0): sistemas compostos• (A0,D0,H1): sistemas heterogêneos• (A0,D1,H0): sistema Cliente/servidor• (A0,D2,H0): sistemas distribuídos peer-to-peer• (A1,D0,H0): federação centralizada de SGBDs específicos• (A1,D0,H1): SGBD federado heterogêneo• (A1,D1,H1): SGBD federado distribuído heterogêneo• (A2,D0,H0): Multidatabase homogêneo • (A2,D0,H1): Multidabase federado heterogêneo• (A2,D1,H1)&(A2,D2,H1): Multidabase Distribuído


• Resumindo temos:

• (Ax,D1,Hy): sistemas cliente-servidor• (A0,D2,Hy): Bancos de Dados Distribuídos• (A2,Dx,Hy): Multidatabase Systems


• Formas de acesso a fontes heterogêneas:

• Migrar todos os dados para o local da consulta (ex. IMS-EXTRACT P/ SQL/DS, DB2, Data Warehousing)

• Gateways dois-a-dois (ex. INGRES-DB2; ORACLE-IMS)

• Federação de SGBDs (MDBS) baseado em um esquema global


Características de um MDBS:

• necessidades de conversões e migração de uma fonte para a outra

• autonomia local

• acesso local independente

• acesso global único

• transparência da heterogeneidade

• transações distribuidas

• BD global completo (atualização esquema e dados, consultas ad-hoc, integridade, autorização, etc.

• sem efeitos colaterais locais

• performance comparável aos BDDs homogêneos


MULTIDATABASE

SGBD globalconsultas Controle deglobais concorr. Glob.

SGBD localesquema Dadoslocal locais.

SGBD localesquema Dadoslocal locais.

Esquema global

Esquema globaldos dados locais

Esquema globaldos dados locais

conversão conversão

PROCESSAMENTODE CONSULTASGLOBAIS

Interface global.

SGBD local

Definir consulta global

Traduzir sub-consultapara modelo local

Decompor consulta global

Distribuir sub-consultas global

SGBD local

Traduzir sub-consultapara modelo local

Data Warehouse no contexto MDBSData

Warehouse

Consultasprogramadas

ObjectData Store

ODS

Agregação

MDBS

Data Warehouse: arquit. tradicional

DataWarehouse

Mediator

Meta-BD

Texto BD Dados externosfontes

Data mart Data mart

GIS OLAP DSSclientes

wrappers

Data Warehouse: 3 perspectivasLÓGICA FÍSICACONCEITUAL

Modelodo cliente

Modeloda empresa

Modelooperacional

Esquemafonte

Esquemado DW

Esquemado cliente

Dadosfonte

DadosDW

Dadoscliente

conversão

conversão

agregação

wrapper

OLAP

OLTP

HETEROGENEIDADE

• hardware• sistema operacional• modelo de dados• SGBD• formato dos dados

Conceitos• Distribuição de bases de dados entre

ambientes distintos;

•Geografia;

•Interligação de ambientes através de

protocolos de rede

matriz PB

filial Recife

BD Campina - PB

TCP/IP

Conceitos•Em cada um dos nós o software do SGBDD consiste minimamente do que se segue:

– Um sistema operacional local.

– O gerenciador de comunicação, que permite a troca mútua de informação entre programas remotos.

– Um Sistema de Gerência de Banco de Dados (SGBD) para atender aos usuários locais.

Conceitos• O MDBS possui um ou vários catálogos globais

– Atender usuários globais– Determinar quais nós precisam ser acessados para atender uma consulta particular– Integrar os resultados da consulta– Realizar otimização de consultas globais– garantir controle de concorrência global

Conceito• Sistema Multidatabase deve prover

também:– Gerência de transações globais

• Atomicidade, confiabilidade, isolamento e durabilidade das transações.

– Funções Administrativas• Autorização, autenticação, definição de restrições de

integridade e gerência do dicionário de dados.

– Heterogeneidade• Diferenças de Hardware, Sistema Operacional,

canais de comunicação, sistema de gerência de dados e modelos de dados.

Vantagens de Distribuição de Dados

• Associar autonomia local com usuários globais.

• Confiabilidade e Disponibilidade– Se um nó falhar em um sistema distribuído, os nós remanescentes podem ser capazes de continuar operando. – Replicação: aumenta a disponibilidade.

Vantagens de Distribuição de Dados

• Aceleração no Processamento de Consultas – Se uma consulta envolve dados em diversos nós, é possível dividi-la em subconsultas que podem ser executadas em paralelo.

Desvantagens de Distribuição de Dados

• Custo de desenvolvimento de software– É mais difícil e mais caro.

• Maior Potencial para erro – O potencial existe para erros extremamente sutis;

• Aumento de overhead de processamento– A troca de mensagens e a computação adicional exigida para se conseguir coordenação interlocal.

Reprodução de Dados

• O sistema mantém diversas réplicas idênticas (cópias) de uma relação em nós diferentes

• Aumenta o desempenho de operações read e a disponibilidade de dados• Transações de atualização ficam sujeitas a baixos desempenhos• Controle de concorrência mais difícil

Fragmentação de Dados• Uma relação r é dividida em fragmentos armazenados em nós distintos

• Tipos de fragmentação:– Fragmentação Horizontal: divide a relação designando cada tupla de r para um ou mais fragmentos. Recuperação por união.

– Fragmentação Vertical: divide a relação decompondo o esquema R da relação r. Recuperação por junção.

– Fragmentação Mista: aplicação das duas fragmentações

anteriores • Reconstrução: operação união ou junção

Sistemas Orientados a Objetos

• Cada fragmento é uma subclasse• Tipos de fragmentação:

– Fragmentação Horizontal: pode ser • primária (= relacional) ou cada sublcasse em um site ou • Secundária: baseada em um atributo complexo ou

relacionamento• Secundária: baseada em métodos complexos.

– Fragmentação Vertical: discutível, pois quebra o encapsulamento. Gera subclasses unidas por agregação

– Fragmentação Mista: aplicação das duas fragmentações anteriores

– Acesso a partes de objetos complexos

Sistemas Orientados a Objetos

• Replicação: objetos, atributos, métodos

• Alocação de objetos:– Comportamento local-objeto local– Comportamento local-objeto remoto– Comportamento remoto-objeto local– Comportamento remoto-objeto remoto

• Gerenciamento dos OIDs• Ponteiros e caminhos• Migração de objetos (manter placeholders):

Objeto pode estar 1. pronto (pode migrar), 2. ativo ou 3. esperando

TRANSPARÊNCIA

Tipos [Özsu&Valduriez]:

• dados (EE x EC)

• distribuição

• replicação

• fragmentação

Separa semântica de alto nível da Implementação de baixo nível

Transparência e Autonomia• No esquema global local

– Dois nós não devem usar o mesmo nome para itens de dados distintos

– Dicionário de dados central

– Cada nó pode prefixar seu próprio identificador para qualquer nome que ele gerar

Transparência e Autonomia

•Transparência de Localização

– Criar um conjunto de nomes alternativos ou aliases para cada local

•Atualização– Assegurar que todas as réplicas de um item de dado e todos os fragmentos afetados sejam atualizados

– Relacionado ao problema de atualização de visões.

Topologia de rede•Formas de conexão:

– rede totalmente conectada, parcialmente conectada, rede com estruturada em árvore, estrela e anel

•Considerações:– custos de instalação e comunicação. – Confiabilidade: a freqüência com que uma ligação ou nó falha.

–Disponibilidade: O grau em que os dados podem ser acessados apesar da falha de alguns elos ou nós.

Integração

FORMAS:

1. Integração de esquemas

esquemasfonte

Esquemaglobal

2. Integração virtual dos dados

dadosfonte

Especificação deacessos globais

2. Integração materializada

dadosfonte

Visõesmaterializadas

Integração


ETAPAS:

• pré-integraçãoanálise dos esquemas fonte estratégia de integraçãotécnicas: Description Logic ou BC de terminologia

• comparação de esquemassolução de conflitos:- heterogeneidade (de modelo de dados)- conflitos de nomes (homônimos, sinônimos)- conflitos semânticos (níveis de abstração)- conflitos estruturais (representação distinta de conceitos)

Integração


ETAPAS:

• homogenização de esquemas - manutenção da capacidade de informação - manutenção da semântica de atualizações

• integração de esquemas (schema merging) sobreposição de esquemas deve garantir: completude, corretude, minimalidade e usabilidade

Integração


Semelhante às visões em bancos de dados convencionais. As visões são a base para formulação de consultas

Integração1. Integração virtual dos dados

• Existe uma visão global ou não• Quais os passos metodológicos (decomposição, transporte, reconstrução)• Qual o formalismo de descrição dos dados (arquivos, legados, RDB, ORDB, não-estruturados, ..)• Linguagem para consultas globais• critérios de casamento dos dados (baseados em chave, em tabela look-up, comparações, ..• Qualidade dos dados (interpretabilidade, credibilidade, ..

QUESTÕES:

Integração


• Carnot (MCC) - Collete, Huhns - esquemas locais determinam uma ontologia global descrita em GCL - Global Context Language - transformações baseadas em axiomas de articulação - consultas e atualizações são transformadas em GCL•

SISTEMAS:

Integração


• SIMS (Arens) - múltiplas fontes de dados - a partir de um modelo do domínio da aplicação as fontes são descritas neste modelo - consultas são distribuídas dinamicamente

SISTEMAS:

Integração


• UniSQL (D’Andrea, Janus)

- SGBD OR- Extensão SQL/M para definir visões virtuais

SISTEMAS:

Albert D'Andrea , Phil Janus UniSQL's next-generation object-relational database management system, ACM SIGMOD Record , Volume 25 , Issue 3 (September 1996


• Information Manifold (AT&T) - múltiplas fontes de dados - componentes: visão do mundo e descrição das fontes de informação - usa Description Logic para os componentes e regras para otimização de consultas• Consultas em Datalog

SISTEMAS:

T. Kirk, A. Y. Levy, Y. Sagiv, and D. Srivastava. The Information Manifold. In Proc. of the AAAI Spring Symposium on Information Gathering in Distributed Heterogeneous Environments,


• TSIMMIS (Stanford) - múltiplas fontes de dados - um mediator é uma visão das fontes de informação integradas e processadas - usa o OEM - Object Exchange Model - Descrição do mediator por uma linguagem lógica MSL = Datalog + OEM - não há integração global. Cada mediator atende às consultas a uma certa visão

SISTEMAS:

Integração

1. Integração materializada dos dados

• as mesmas da integração virtual• quais dados são materializados• níveis da participação das fontes (suficiente, restrita, não-ativa) • estratégias de manutenção (incremento local, baseado em polling, refrescamento completo)• timing (imediato, periódico)

QUESTÕES:

Integração


• Sqirrel (Zhou, Hull) - baseado em um integration mediator com múltiplas fontes - geração automática de novos integradores especificados pela ISL - Integration Specification Language - ISL especifica: esquema local, critérios de casamento de objetos entre classes. Diversos critérios de casamento de OIDs

SISTEMAS:

R. Hull and G. Zhou, "A Framework for Supporting Data Integration Using the Materialized and Virtual Approaches,", Proceedings of SIGMOD, June 1996, Montreal, Canada, pgs. 481-492

Integração


• WHIPS (Garcia-Molina) - módulos implementados como objetos CORBA - visões criadas por expressões SQL - ;;;;

SISTEMAS:

Janet L. Wiener, Himanshu Gupta, Wilburt Labio, Yue Zhuge, Hector Garcia-Molina: The WHIPS Prototype for Data Warehouse Creation and Maintenance. ICDE 1997: 589

Extração e Integração


Data Warehouse

ODS

MetaEsquema

Customização

DataMart

DataMart

OLTP

OLAP

Agregação


Fonte de Informação DW

WRAPPER,LOADER

Carregamento,transformação,limpeza,atualização

MEDIATOR

Conflitos,incosistências,integração


FONTES DEINFORMAÇÃO

• Bancos de dados (relacionais, OO, OR, hierárquicos, rede, outros)• fontes externas (outras empresas, resultados de pesquisas, ...)

• Arquivos (planilhas, arquivos, textos, documentos multimidia)

META-ESQUEMA/METADADOS

• dicionário de dados• fluxo de dados• transformação dos dados• controle de versões dos metadados•estatísticas de uso•aliases•segurança


TAREFAS• extração (diversas fontes)• limpeza (cleaning)• transformação (formatos, linguagens,..)• carregamento• replicação• análise (p.ex. valores inválido/inesperados)• transferência• cheque da qualidade dos dados (completeza, duplicidade, granularidade, necessidade, ..)• análise dos metadados

Solução de Conflitos CONFLITOS ESTRUTURAIS

1. Entidade-vs-entidade (a) entidade 1-1 i. nome: homônimos e sinônimos ii. Estrutura: falta de atributos, atributos implícitos iii. restrições de entidade

iv. Inclusão de entidade (generalização) (b) entidades n-m

2. Atributo-vs-atributo (a) atributos 1-1 i. nome ii. Restrições: integridade, domínio, composição iii. Valores default (valores nulos, constantes) iv. Inclusão de atributos (generalização) v. métodos

Solução de Conflitos CONFLITOS ESTRUTURAIS

3. Entidade-vs-atributo

4. Relacionamentos i. nomes ii. Cardinalidades

5. Entidade-vs-atributo-vs-relacionamento

6. Abstrações: generalização, agregação, agrupamento (a) agregação-vs-relacionamento-vs-composição

7. Diferentes representações da mesma informação (a) expressões diferentes (b) unidades diferentes (c) níveis de precisão

Solução de Conflitos TÉCNICAS DESOLUÇÃO DECONFLITOS 1. Renomear entidades e atributos

2. Homogenizar representações (a) expressões diferentes (p.ex. abstrações)

(b) unidades diferentes (c) níveis de precisão

3. Homogenizar atributos e relacionamentos (a) valores default (b) cardinalidades

4. Uniões (completar os atributos)5. Junções verticais (entidades, atributos, agregações)6. Junções mistas7. Homogenizar métodos

Solução de Conflitos

TÉCNICAS DE SOLUÇÃO DE CONFLITOS

Criação de classes virtuais

CREATE VCLASS nome-da-classe-virtual SIGNATURE lista-de-atributos AS SELECT lista-de-seleção FROM lista-de-entidades WHERE condição

SELECT ...

Sintaxe (linguagem SQL/M do UniSQL):

Solução de conflitosEXEMPLO: MDBS de quatro universidades.

UNIVERSIDADE-1 (BD relacional)

Est-grad(nome CHAR(25), mat INTEGER, end CHAR(50),curso CHAR(7))Curso(cnome CHAR(20), cnum INTEGER)Disciplina(dnome CHAR(20), dnum INTEGER, cnum CHAR(7))Matricula(dnum CHAR(7), mat INTEGER, cre REAL)

Est-pós(nome-e CHAR(25), mat INTEGER, curso CHAR(20), tese CHAR(50) aproveitamento CHAR(1))

NOTAÇÃO: Classes começam com maiúsculas, atributos em minúsculas e PALAVRAS-RESERVADAS em maiúsculas.

ExemploUNIVERSIDADE-3 (BD OO ou OR)

CLASS EstudanteSIGNATURE nome:CHAR(25), mat:INTEGER,

curso: CHAR(20), cre:REAL, /*métodos*/CLASS Est-pós-graduação SUPERCLASS EstudanteSIGNATURE orientador: SET-OF Professor

CLASS Professor SUPERCLASS EmpregadoSIGNATURE depto: CHAR(25), nível: CHAR(20)

CLASS Empregado...CLASS MatriculadoSIGNATURE curso:Curso, est:Estudante, conceito:REAL

Classe virtual

CREATE VCLASS Todos-estudantesSIGNATURE nome CHAR(25), matricula INTEGER,

curso CHAR(20), cre: REALAS SELECT eg.nome eg.mat c.cnome eg.cre FROM un1.Est-grad eg, un1.Matricula m, un1.Curso c WHERE eg.mat=m.mat AND

c.cnum = eg.curso AS INTEGER SELECT nome-e epg.mat curso valor(aproveitamento) FROM un1.Est-pós epg, un1.Matricula m SELECT nome mat curso cre from un3.Estudante

Conflitos - Homogenizar representações

CONFLITO: diferentes valores escalares denotam a mesma informação

SOLUÇÃO: definir um isomorfismo que cria classes de equivalência

EXEMPLO: “Dr.”, “PhD” ou “DSc” denominam o mesmo nível.Conceitos na pós podem ser A, B, C ou D ou então 1, 2, 3, 4 ou excelente, bom , regular, ruim.“Bach. em C. da Computação” ou “Bacharelado em Ciência da Computação”

SELECT nome FROM Todos-estudantesWHERE curso LIKE Bach% em C% da Computação

Expressões distintas denotam a mesma informação


CONFLITO: valores numéricos distintos denotam a mesmaquantidade física

SOLUÇÃO: definir uma função de conversãoEXEMPLO: quilogramas e libras;

graus centígrados e graus Farenheit

Unidades distintas


CONFLITO: valores numéricos expressos em granularidadesdistintas

SOLUÇÃO: converter para a granularidade menos precisaEXEMPLO: gramas e quilos; segundos e minutos

Precisões distintas

Conflitos - Homogenizar atributos

CONFLITO: domínios distintos para atributos semanticamente equivalentes

SOLUÇÃO: em muitos casos é possível converter de um domínio para outro

EXEMPLO: INTEGER e CHAR(n); INTEGER e FLOAT;CHAR(n) e CHAR(m)

Conflitos de tipos

WHERE eg.mat=m.mat AND c.cnum = eg.curso AS INTEGER


CONFLITO: o mesmo fato é ora modelado com atributo ora como relacionamento

SOLUÇÃO: criar uma classe virtual e converter o atributo em relacionamento

EXEMPLO: em Uni-1 Curso é um entidade relacionada com Est-grad enquanto em Uni-3 é um atributo de Estudante

Conflitos atributo X relacionamento X entidade

CREATE VCLASS Cursos SIGNATURE nome CHAR(25)AS SELECT cnome FROM un1.Curso SELECT curso FROM un3.Estudante


Valores default

Atributos concatenados (e.g. nome=primeiro nome + sobrenome)

Conflitos - Uniões

Tabelas união-compatíveis

SEM CONFLITOS ESTRUTUAIS

SOLUÇÃO fazer a união com o cuidado de não repetir a mesma entidade e considerar possíveis restrições

COM CONFLITOS ESTRUTUAIS

CONFLITO: uma tabela tem mais atributosSOLUÇÃO: criar atributos ‘fantasma’ ou eliminar os

atributos a mais

Conflitos - Junções

Entidade n-m

CONFLITO: as mesmas entidades são espalhadas por várioslocais com atributos distintos

SOLUÇÃO: processar junções

Conflitos - Métodos

Entidade n-m

CONFLITO: métodos distintos realizam a mesma tarefaSOLUÇÃO: analisar os dois métodos e criar um método

genérico que realiza as duas tarefas

Conflitos - Navathe & Savasere: A Schema Integration Facility using O-O Data Model

Meta-conhecimento para raciocínio aproximado

• nomes de objetos (variações, parcial, abreviações, convenções)• nomes de objetos (thesaurus de sinônimos e homônimos)• tipos e domínios (chaves, valores nulos, default)• interação com objetos ao redor• cardinalidades esperadas de classes e relacionamentos• atualidade• descrições textuais

Ex. OCL = Object Constraint Language ou Organization Communiste Libertáire

Conflitos - Navathe et. al.

Casamento (aproximado) de nomes

Casamento (aproximado) de atributos

Casamento (aproximado) de estruturas

Grau de similaridade entre entidades


E1 E2

Generalizar E1 E2

E12 E12 = E1 E2AE12 = AE1 AE2

L1 L2

G

OBS: E1 e E2podem ficar em Gou não


E1 E2

Especializar E1 E2

E12E12 = E1 E2AE12 = AE1 AE2

L1 L2

G



E1 E1

Subordinar E2 a E1

E2 E1AE1 AE2

E2 E2

L1

L2 G


E1 E2

Agregar E1 e E2

E12 E12 E1 X E2

L1 L2

G



E1 E1

Agrupar E2 em E1

E2 E2

L1

L2 GE1 P(E2)


E1 E2

Combinar r1 e r2

L1 L2

G

r1E1 E2

r2

E1 E2r12

E1r12E2 = E1r1E2 E1r1E2


E1

Atributo X relacionamento

L1 L2

G

atE1 A

r

E1 Ar’

A

r’ = r at


Entidade X relacionamento

L1 L2

G

E1 E2r

E1 E2

R’ = R r

R’

E1 E2

R


Entidade X atributo

Agregação X relacionamento

SISTEMA: • O usuário escolhe esquemas locais• O sistema sugere regras de integração

que podem ser aceitas ou não pelo usuário• O usuário pode estabelecer suas próprias regras

de integração

Integração baseada em agentes

TECNOLOGIAS:

• Inteligência Artificial• Inteligência Artificial Distribuída• Recuperação da Informação• Ciências cognitivas • Computer Supported Collaborative Work – CSCW• Interação Homem-Máquina

FONTE: M. Klusch “Intelligent Information Agents”, Springer Verlag (1999) [749 referências!]

Integração baseada em agentes

CLASSIFICAÇÃO DE AGENTES (Franklin&Gaesser):

Autônomos computacionais

biológicos

robóticos

• software

• vida artificial

• virus• aplicativos

• diversão

• de informação

• cooperativos• não-cooperativos

• adaptivos• racionais• móveis

Integração baseada em agentes –

cooperação

• cooperativos• delegação hierárquica de tarefas• contratação simples e complexa• negociação descentralizada

• não-cooperativos

Integração baseada em agentes –

categorias

• racionais(agem e interagem para melhorar seus benefícios)

• adaptativos

(se alteram de acordo com estados da rede e do ambiente)

• móveis (se locomovem autonomamente pela Internet)

Agentes de Informação

• Agentes de Informação Cooperativos

• Agentes de Informação Racionais(agem e interagem para melhorar seus benefícios)

• Agentes de Informação Adaptativos (se alteram de acordo com estados da rede e do ambiente)

• Agentes de Informação Móveis (se locomovem autonomamente pela Internet)

Agentes de Informação Cooperativos

• Sistemas de Informação Cooperativos - CIS

RequerenteInterme-

diárioServidor

INTERMEDIAÇÃO (BROKERING)

2.Solicitarserviço

4.Resultado 1.Anunciarserviço

3.Solicitarserviço

Agentes de Informação Cooperativos

• Sistemas de Informação Cooperativos - CIS

Requerente

Associador

Servidor

ASSOCIAÇÃO (MATCHMAKING)

2.Solicitarserviço

5.Resultado

1.Anunciarserviço

4.Solicitarserviço

3.Informarservidor

Agentes de Informação Racionais

• Interfaces conversacionais e perfis •Filtragem colaborativa de informação (agentes antecipam necessidades do usuário no contexto de outros usuários)• Shopping comparativo (agentes selecionam produtos baseado na análise de preços e outras condições)• Mercados baseados em agentes (leilões, múltiplos agentes de informação associando clientes e

fornecedores) • Coalizações

Aplicação em comércio eletrônico, govêrno eletrônico, turismo

Agentes de Informação Adaptativos

• Estratégia• Instrução• Exemplo• Analogia• Descoberta

•Objetivo• habilidades• cap. do sistema

• Decentralização• tipo de distribuição• comp. concorrente

ADAPTAÇÃO

• Feedback• Supervisão• Reforço• Auto-organização

•Interação• Agente-agente• Agente-humano• Ambiente do sistema

Agente simples Multi-Agentes

Agentes de Informação Móveis

• Padrões• Mestre-escravo• Itinerário

• Descoberta de fontes de informação

• Acesso à estrutura das fontes (memória, arquivos, serviços, threads)

• Agentes heterogêneos

DIA

Seminários• A uniform framework for integration of information from the web

by W May; G Lausen, Information Systems. 29, no. 1, (2004): 59-91• Combining schema and instance information for integrating

heterogeneous data sources, Huimin Zhao , Sudha Ram, Data & Knowledge Engineering 61 (2007) 281–303

• An ontology based approach to the integration of entity–relationship schemas, Qi He, Tok Wang Ling, Data & Knowledge Engineering 58 (2006) 299–326

• How to act on inconsistent news: Ignore, resolve, or reject, Anthony Hunter, Data & Knowledge Engineering 57 (2006) 221–239

• Semantic integration in Xyleme: a uniform tree-based approach, C. Delobel et al. Data & Knowledge Engineering 44 (2003) 267–298

• Supporting ontological analysis of taxonomic relations, C. Welty, N. Guarino, Data & Knowledge Engineering 39 (2001) 51-74

• DFD – a dialog based integration of concept and rule, M. Balban, A. Eyal, Data & Knowledge Engineering 38 (2001) 301-334

Integração - García-Solaco, Saltor, Castellanos: Semantic Heterogeneity in Multidatabase Systems - uma survey

CLASSIFICAÇÃO DE HETEROGENIDADES:

• entre classes (diferenças em extensão, nomes, atributos e métodos, domínios (sintático e semântico), restrições)

• entre estruturas (inconsistências de generalização/espec., agregação/decomp., dados/metadados, metaclasses

• entre instâncias (presença/ausência, atributos multivalorados, valores nulos, valores diferentes nos atributos)


1. DETECÇÃO DE HETEROGENIDADES:

TOOLS: SIS-Schema Integration System; Honeywell TestbendMUVIS_Multiuser View Integration System; BERDI-Bellcore Schema Design and Integration Toolkit;MIST of Carnot;

CONTRIBUTIONS: Theory of Attribute Equivalence;Common Concept Approach; Semantic Unification Approach;Maximum Spanning Tree Appr.; Semantic Proximity Proposal;Mathematical Model of Meaning; Semantic Abstractions


2. SOLUÇÃO DE HETEROGENIDADES:

TOOLS: Multibase; Honeywell Testbend;MUVIS; BERDIViewSystem; Carnot; Pegasus; UniSQL/M

CONTRIBUTIONS: Superview - Integration Operators;Rule Based Approach; Approach that preserves semantic relativism;Semantic Unification Approach; Semantic Abstractions;Structural Integration

Integração - Papazoglou, Zahir Tari, Russel: Object-Oriented technology for Interschema and language Mappings

Baseado em losely coupled architectures.Troca direta de informações entre as fontesPartially unified schemasInteração usa um Common Object Model

denominado KOM


Inforrmation Broker

ClientInterface

ServerInterface

Shared Inf.metadataThesauri

Service desc.

Object wrapper

RDB

CommonObjectModel

Inforrmation Broker

ClientInterface

ServerInterface

Shared Inf.metadataThesauri

Service desc.

Object wrapper

FDB

Control flow

Data flow


O modelo KOM:

ODL - Object Definition Layer

OTL - Object Transformation Layer

RELACIONAL

FUNCIONAL

ORIENTADOA OBJETOS

Transformação de estruturas e operações

Integração - Bertino & Illaramendi: The Integration of Heterogeneous DBMS: Approaches based on the OO Paradigm

1) TRADUÇÃO - características OO• enriquecimento semântico• tradução operacional• correspondência complexa

2) INTEGRAÇÃO - características OO• integração operacional• vários níveis (esquemas) de integração• integração inteligente (detecção de erros na correspondência de objetos}

Integração - Bertino & Illaramendi: The Integration of Heterogeneous DBMS: Approaches based on the OO Paradigm

Survey dos sistemas:

• Pegasus•CIS - Comandos Integration System• OOA• Cyc• Candide• AIMS

Integração – Domingos Sávio & U. Schiel: RDF na interoperabilidade de dados entre domínios

• Domínios descritos em RDF• Comunicação direta entre domínios

Processamento de ConsultasConsulta global

Decomposição e otimização global

SC1 SCn CPP1 CPPm

EG

EGL1

tradutor

CL1

BDlocal

resultado

tradutor

CLn

BDlocal

... ...

...

CPP = consulta de pós-processamento

Processamento de Consultas

• Modificação da consulta• Tradução da consulta• otimização global

DECOMPOSIÇÃO/TRADUÇÃO:

1) modificação para atender os EGLs2) decomposição em consultas internas e consultas externas (externas sobre dados intermediários transmitidos)3) tradução para esquemas locais

PASSOS:


• Modificação da consulta

Fatores que afetam complexidade:

• linguagem de consulta global e modelo de dados global

• métodos de integração dos esquemas de exportação: generalização e outerjoin

• replicação de dados

• inconsistências e outras incompatibilidades

Processamento de Consultas• Modificação da consulta

Dada uma classe C:

tipo(C) = atributos de C com os domíniosextensão(C) = {instâncias de C}mundo(C) = {objetos do mundo real

descritos por C}

C = generalização(C1,C2) sss tipo(C) = tipo(C1) tipo(C2)extensão(C) = extensão(C1) extensão(C2)

C = outerjoin(C1,C2) sss tipo(C) = tipo(C1) tipo(C2)extensão(C) = equi-outerjoin(C1,C2, ID)mundo(C) = mundo(C1) mundo(C2)

OBS. Em caso de diferenças, ajustá-las por funções de agregação

Processamento de Consultas• Outerjoin

Emp1 >< Emp2 = <1,José, 28, sup>

Emp1(#e, nome, idade)<1, José, 28><2, Karla, 22>

Emp2(#e, nome, nivel)<1, José, sup><3, Cintia, méd>

Emp1 >o< Emp2 = {<1,José, 28, sup>, <2, Karla, 22, {}>, <3, Cintia, {}, méd>

Processamento de Consultas• OuterjoinEmp1(#e, nome, sal, idade)

<1, José, 300.-, 28><2, Karla, 450,-, 22>

Emp2(#e, nome, sal, nivel)<1, José, 120.-, sup><3, Cintia, , méd>

Emp1 >o< Emp2 (sum(sal)) = {<1,José, 28, 450.-, sup>, <2, Karla, 22, 450.-, >,

<3, Cintia, , , méd>


Emp1(#e, nome, salario, idade) - esquema exportação-local 1Emp2(#e, nome, salario, nivel) - esquema exportação-local 2

EXEMPLO

EmpG(#e, nome, salario) - esquema generalizaçãoEmpG.nome = Emp1.nome se EmpG está em mundo(Emp1) = Emp2.nome se EmpG caso contrárioEmpG.salario = Emp1.salário se EmpG está em

mundo(Emp1) - mundo(Emp2) = Emp1.salario+Emp2.salario se EmpG está em

mundo(Emp1) mundo(Emp2). . .


EmpOJ(#e, nome, salario, idade, nivel) - esquema outerjoin

EXEMPLO

EmpOJ.idade = Emp1.idade se EmpOL está em mundo(Emp1) = nulo se EmpOJ está em

mundo(Emp2) - mundo(Emp1)EmpOJ.nivel = Emp2.nivel se EmpOJ está em mundo(Emp2)

= nulo se EmpOJ está em mundo(Emp1) - mundo(Emp2)

Processamento de ConsultasEmpOJ(#e, nome, salario, idade, nivel)

SEJA A CONSULTA:

SELECT EmpOJ.nome, EmpOJ.nivelFROM EmpOJWHERE EmpOJ.salario > 2000 AND EmpOJ.idade = 49

A tabela EmpOJ é dividida em três partições:

mundo(Emp2)-mundo(Emp1);

mundo(Emp1)-mundo(Emp2);

mundo(Emp2) mundo(Emp1);


Para o mundo(Emp2)-mundo(Emp1) o atributo idade é nulo;

Para o mundo(Emp1)-mundo(Emp2) teremosSELECT Emp1.nome FROM Emp1WHERE Emp1.salario > 2000 AND Emp1.idade =49AND Emp1.#e NOT IN (SELECT Emp2.#e FROM Emp2)

Para o mundo(Emp2) mundo(Emp1) teremosSELECT Emp1.nome, Emp2.nivel FROM Emp1, Emp2WHERE sum(Emp1.salario, Emp2.salario) > 2000 AND Emp1.idade =49 AND Emp1.#e = Emp2.#e

Uma consulta de pós-processamento irá produzir o resultado final


• Tradução da consulta

A qualidade da tradução irá depender do poder expressivoda linguagem local

CASOS:

Uma única consulta local• otimização local

Várias consultas locais. • Definir consultas locais de forma a otimizar a performance• otimização local

ALGORITMOS CONVENCIONAIS


• Otimização global da consulta

Para o mundo(Emp2) mundo(Emp1) temos

SELECT Emp1.nome, Emp2.nivel FROM Emp1, Emp2WHERE sum(Emp1.salario, Emp2.salario) > 2000 AND Emp1.idade =49 AND Emp1.#e = Emp2.#e

VOLTEMOS AO EXEMPLO:

Processamento de Consultas• Otimização global da consulta

POSSIBILIDADES:

Emp1SELECT

Result1 + Emp2SELECT

Emp2SELECT

Result2 + Emp1SELECT

Emp2SELECT

Result1 + Result2SELECT

Emp1SELECT


Algoritmos de BDDs homogêneos podem ser aplicados, se

• não houver inconsistências• facilidades de transmissão de dados• estatísticas locais comparáveis entre si

Árvores de junção: linearfechada


Solução de inconsistências - funções de agregação

Seja C global e C1, C2 uma partição horizontal.

A operação: C[A op a] = C1[A op a] int-op C2[A op a]

usa outerunion: C1 OJ C2 = C1-O OU C2-O OU (C1-C J C2-C)

parte privada parte comum


Otimização com funções de agregação f(a1,a2)

minminmaxmaxsumsum

<=>=<=

f(a1,a2) op

f(a1,a2)op a a1 op a AND a2 op a (1)f(a1,a2)op a f(a1 op1 a, a2 op2 a) op a (2)f(a1,a2)op a a1 op a AND a2 op a (1)f(a1,a2)op a f(a1 op1 a, a2 op2 a) op a (2)f(a1,a2)op a f(a1 op a, a2 op a) op a (3)f(a1,a2)op a f(a1 op1 a, a2 op2 a) op a (2)

Para os outros casosnenhuma otimização

é possível (4)

Processamento de Consultasa1=E1.sal = 500 a2=E2.sal = 600

minminmaxmaxsumsum

>=<<<=

f(a1,a2) op

min(E1.sal,E2.sal)> 600 E1.sal > 600 AND E2.sal > 600 (1) min(E1.sal, E2.sal)= 550 min(a1<600, a2<600) = 600 (2)max(a1,a2)< a a1 < 600 AND a2 < 600 (1)max(a1,a2)= a max(a1 > 600, a2 > 600) = 600 (2)sum(a1,a2)< a sum(a1>600, a2>600) < 600 (3)

sum(a1,a2)= a sum(sum(a1) > 600, sum(a2) > 600) = 600 (2)

sal = 600

(1) = processamento em todos locais(2) = processamento em um local pode resolver(3) = processamento local e global

Controle de Concorrência

• Autonomia de projeto• Autonomia de execução• Autonomia de comunicação

TIPOS DE TRANSAÇÕES

• Transações locais• Transações globais

AUTONOMIA LOCAL


MDBS

• locais (s1,...,sm),

• Operações básicas: r (read), w (write), c (commit), a (abort)

• GTG (Gerente de Transações Globais)• SGBD local• Server (ligação entre GTG e SGBD local)


MDBS

GTG

Ti

Tj

SGBD

Server

SGBD

Server

Tl Tl


MDBS - Interface Server/SGBD

• O SGBD aceita operações individuais begin, op.1, op.n, commit

• O SGBD aceita serviços na forma de transações locais

POSSIBILIDADES


• Serializabilidade global

• Atomicidade e recuperação

• Deadlock

PROBLEMAS



Local s1 com a, bLocal s2 com c, d

Transações:globais: T1 : r1(a) r1(c)

T2 : r2(b) r2(d)locais: T3 : w3(a) w3(b) em s1

T4 : w4(c) w4(d) em s2

Visão global: T1 ,T2

Schedules locais: S1: r1(a) w3(a) w3(b) r2(b) T1 , T3 , T2

S2 : w4(c) r1(c) r2(d) w4(d) r2(d) w4(c) w4(d) r1(c) T2 , T4 , T1


• Atomicidade global e recuperação

Local s1 com aLocal s2 com c

Transações:global: T1 : r1(a) w1(a) w1(c)local: T2 : r2(a) w2(a) em s1

Execução: T1 completa suas 3 ações e manda commit para s1 e s2 s2 recebe e confirma o commit, mas s1 aborta a subtransação original antes do commit T2 é executada e realiza commit GTG resubmete w1(a)

s1 considera isto uma nova transação RESULTADO:schedule não serializavel: r1(a) r2(a) w2(a) w1(a)



SOLUÇÃO:

Prepare-to-commit reduz heterogenidade


• Deadlock global


Execução: T1 executou r1(a) e T2 executou r2(c) T3 executa w3(b) e submete w3(a) e espera liberação de T1

T4 executa w4(d) e submete w4(c) que espera por T2 T1 e T2 submetem seus restos e o deadlock ocorre

Nem os locais nem o global conseguem detectar este deadlock

Transações:globais: T1 : r1(a) r1(d)

T2 : r2(c) r2(b)locais: T3 : w3(b) w3(a) em s1

T4 : w4(d) w4(c) em s2





T2 : r2(b) r2(d) locais: T3 : w3(a) w3(b) em s1

T4 : w4(c) w4(d) em s2 Visão global: T1 ,T2

• evitar transações T1 ,T2 que atuam no mesmo local provocar conflito artificial

SOLUÇÕES:

• identificar schedules como S2 e evita-los






T4 : w4(c) w4(d) em s2



S2 : w4(c) r1(c) r2(d) w4(d) não é serializável r2(d) w4(c) w4(d) r1(c) T2 , T4 , T1

Provocar conflito entre T1 ,T2 com um ticket

w1(t)r2(t)

r2(t)w1(t)

, t


• Serializabilidade global - SGBDs com 2PL rigoroso




T4 : w4(c) w4(d) em s2



S2 : w4(c) r1(c) r2(d) w4(d) não ocorre, pois c é bloqueado até o final de T4



PROBLEMA: Falha de subtransação global

TIPOS DE TRANSAÇÕES

• com redo (operações de write são repetidas)

• com retry (toda subtransação é repetida)

• com compensação (compensação desfaz ação da transação original)



TIPO DA OPERAÇÃO

COMPENSÁVEL REPETÍVEL EXEMPLO

ler (read) sim - (ler de novo) sim update de troca não sim (reescrever) escrever um inteiro update relativo sim (usar valor) sim incrementar um

valor update relativo c/restrição

condicional condicional depósito, cancelamento

inserção em conjunto

sim - (remover) sim

entrada em fila sim (remover) sim inserção em lista sim (remover) não (pode ter

mudado)

update em textos não não


• Outros conceitos em

Özsu&Valduriez-Princípos de Bancos de Dados Distrtibuídos

CONTROLE DE CONCORRÊNCIA

• Bloqueio; centralizado, cópia primária e distribuído•Pessimista: bloqueio e timestamp ordering• Otimista: bloqueio, timestamp ordering, híbrido

• Deadlock: prevenção, anulação, detecção e resolução

CONTROLE DE CONCORRÊNCIA RELAXADO OU ANINHADO

Data Warehousing - Alimentação

Projeto do Data Warehouse - FASES:

• PROJETO: definição de visões, extratores, revisores, integradores.

• ALIMENTAÇÃO: carga inicial. Passos: preparação (Logs, deltas, histories), integração (ODS), agregação (CDW), customização (Datamarts)

• ATUALIZAÇÃO: como alimentação, só que o ODS é atualizado e alterações são propagadas

- FIGURA 4.1-

Data Warehousing - Atualização

Considerações

• requisitos da aplicação (e.g. atualidade e precisão dos dados, tempo de computação de consultas)

• restrições da fonte (disponibilidade, frequência de alterações)

• limites do Data Warehouse (espaço, funcionais)


ODS - Object Data Store - atualização

• atualização imediata - Banco com lançamentos locais e saldo global)

• atual - ODS com estatísticas semanais de lançamentos locais e atualização horária)

• periódica (assíncrona) - resultados diários, após n lançamentos, sob demanda (saldo, #lançamentos, ..)

Semelhante para o Data Warehouse


CDW - Data Warehouse - atualização

• volume muito grande de dados - de GB a TB

• sobrecarga transacional - transações de carga e acesso pesadasGB/hora, processamento paralelo, transferência compactada

• concorrência entre atualização e consulta divisão do tempo entre batch e on-line difícil, conflitos

PROBLEMAS CRÍTICOS


Extração Histórico Limpeza

PREPARAÇÃO

Temporal/externo

Integração HistóricoINTEGRAÇÃO

Propagação

Customização

AGREGAÇÃO


• detectar alterações• extrair alterações• registrar alterações

• isolar alterações cedo reduz drasticamente massas de dados• integração incremental (limpeza)

QUESTÕES AO ODS:• processar dados que alteram o DW• prever informações de outras fontes, antes da atualização• estimar tempo da preparação• estimar tempo de atualização do DW

Data Warehousing - Extração

FONTES:

não-cooperativas

cooperativas

snapshot

logadas

específicas

consultáveis

arquivos

BDs, e-mails

legados

BDs relacionais

replicadas

ativascallback

Ações internas

BDs c/ replicação

BDs c/triggersexternos

BDs c/triggerse delta tables

Data Warehousing - Limpeza

Dados devem ser: precisos, relevantes, consistentes e completos

DADOS SUJOS:

• diferença de formato• dados relevantes escondidos em textos• mal-entendidos (atributo ‘nome’ de que?)• erros de digitação inconsistências• falta de valores• informação duplicada


módulos de limpeza:

• conversão e normalização transformação de formatos heterogêneos

• limpeza específica arquivos textuais, uso de dicionários

• limpeza independente do domínio algoritmos de casamento de campos

• limpeza baseada em regras regras específicas de casamento (business rules)


• conversão e normalização transformação de formatos heterogêneos

SQL*Loader Arquivos Oracle

Wrappers Dados fonte Data Warehouse

NORMALIZAÇÃO Exemplos: • textos sem acentuação• formato do datas


• limpeza específica arquivos textuais, uso de dicionários

normalização de nomes próprios• nome farmaceuticos• normalização postal

EXEMPLOS:PostalSoftACESSA(Search Soft America)PostalSoft Library and MailersCarleton’s Pure Integrator (DW)ETI Data Cleanse


• limpeza independente do domínio algoritmos de casamento de campos

PROBLEMA: o mesmo valor descrito de forma distinta

• junções aproximadas• valores alternativos• graus de casamento

Carlton’s Pure Integrator: • casamento com chaves• casamento sem chaves (fuzzy)


• limpeza baseada em regras regras específicas de casamento (business rules)

MERGE/PURGE Problem;• criação de chaves analisando os dados das fontes• ordenar fontes segundo estas chaves• intercalar registros (funções distância)

Data Warehousing - Limpeza• limpeza baseada em regras regras específicas de casamento (business rules)

Regras explícitas:for(all tuples) boolean similar-nome = compare(nome1, nome2) boolean similar-end = compare(end1,end2) boolean similar-cidade =

mesma-cidade(cid1, cid2) boolean similar-cep =

mesmo-cep(cid1, cid2) similar-end = (similar-cidade

similar-cep) if (similar-nome && similar-end)

merge-tuples(pessoa1, pessoa2)

Data Warehousing - Limpeza• limpeza baseada em regras

Regras geradas automaticamente (baseadas em data mining)

A=B*C WHERE A = p-total, B=quant. C=p-unitRule’s accuracy level: 0.99rule exists in 1890 records

regras matemáticas

regras IF-THEN

IF Cliente IS “UFCG” AND item IS “Informática”THEN Vendedor=“Chico”Rule’s probability: 0.95rule exists in 102 records


o estudo das semânticas de limpeza e estratégias de atualização de um DW a partir de diversas fontesé uma área aberta de pesquisa

FIM

Documents

Interoperabilidade Ulrich Schiel [email protected] (C) COPIN - Coordenação de Pós-Graduação em Informática UNIVERSIDADE FEDERAL DE CAMPINA GRANDE