bd federadas

SISTEMAS DE BASES DE DATOSSISTEMAS DE BASES DE DATOSSISTEMAS DE BASES DE DATOSSISTEMAS DE BASES DE DATOSFEDERADASFEDERADAS

Material de la Conferencia dada por:

Dept LSIU i it t P litè i d C t l

Prof. Fèlix Saltor

1

Universitat Politècnica de Catalunya

Contenido

1. Introducción: Sistemas de Información Cooperativos

2. Características de los Sistemas de Bases de Datos Federadas

3. Arquitecturas de SBDFs

4 La construcción de un SBDF4. La construcción de un SBDF

5. La operativa de un SBDF5. La operativa de un SBDF

6. Conclusiones y bibliografía

2

y g

Contenido

1. Introducción






3

y g

1. Introducción

1.1 Sistemas de Información Cooperativos y Bases de Datos Federadas

1.2 Consultas Multi-base: problemática y solucionessoluciones

1.3 El acceso integradog

1.4 Sistemas de Bases de Datos Federadas

4

Relevant disciplines

• Distributed computing

• Federated Databases

• Human Computer interfacingHuman Computer interfacing

• Multi Agent Systems

• Workflow Management Systems

C t S t d C ti W k• Computer Supported Cooperative Work

• Management of Change

• ...

5

1.2 El problema:

Consulta cuya respuesta requiere

acceder a diversas bases de datos?

acceder a diversas bases de datos

SBD SBD SBD

SGBD SGBD SGBD

• • •• • •

BD BD BD

• • •

BD

6

BD2-1 2-m

El problema

No se trata de:• Conectividad entre B de D (supuesta)• Intercambio electrónico de datos (EDI), Business to

Business (B2B), eB-XML (p.ej. SOAP)• Acceso remoto a una sola base de datos (RDA)• Acceso remoto a una sola base de datos (RDA)• Una arquitectura multicliente/multiservidor• Una base de datos única que físicamenteUna base de datos única que físicamente

está distribuida Se trata de:

• poder formular una sola consulta, y• recibir una única respuesta, de modo que

l ió d l i i

7

• en la preparación de la respuesta intervienendatos de varias bases de datos

Ejemplos

1. Dos empresas, cada una con sus bases de datos,f i f t dque se fusionan o pasan a formar parte de un

mismo holding

2. Ministerios que quieren compartir sus datos

3. Provincias o territorios autónomos que deseanacceder mutuamente a ciertos datos

4. Países de un mercado común que necesitanintercambiar datos

8

intercambiar datos

Soluciones:

a) Consultar separadamente cada base de datos, eintegrar manualmente las respuestas

b) Crear una nueva base de datos que integre todos l d t d l i t t i ió d dlos datos de las preexistentes: integración de datos

c) Construir un Sistema Federado en el que las basesc) Construir un Sistema Federado en el que las bases de datos interoperen: integración del acceso

d) Crear un Data Warehouse

En cada caso hay que analizar cuál es la mejor solución

9

En cada caso hay que analizar cuál es la mejor solución

a) Consultas separadas e integración manual

La(s) persona(s) que lo realice(n) debe(n):S b é b d d t tá ibl• Saber qué bases de datos están accesibles

• Saber qué datos hay en cada base de datos• Saber descomponer la consulta en lasSaber descomponer la consulta en las

consultas parciales a cada base de datos• Conocer el modelo de cada base de datos• Conocer el lenguaje de cada base de datos• Saber integrar los resultados parciales para

producir el resultado deseado

Viable sólo muy excepcionalmente

10

Viable sólo muy excepcionalmente

b) Integración de datos

• Diseñar la nueva base de datos(posiblemente distribuida)

• Convertir los programas • Transferir los datos de las bases de datos

preexistentes a la nuevaPreparar enseñar los n e os modos de• Preparar y enseñar los nuevos modos de

trabajar de los usuarios

La gestión autónoma de cada base de datosse pierde, en aras de una gestión única

11

c) Acceso integrado

• Superponer un sistema nuevo sobre los SGBDsde las bases de datos preexistentesde las bases de datos preexistentes

• El nuevo sistema acepta la consulta y devuelvela respuesta, generando internamente las p , gconsultas parciales e integrando sus respuestas

• La existencia de múltiples bases de datos puedeser transparente al usuario

• Los programas y usuarios preexistentes no seven afectadoven afectado.

Se preserva la autonomía de cada base de datos

12

p

Autonomía y flexibilidad

Una de las principales diferencias entre las soluciones radica en el grado en que se mantiene la autonomíade las bases de datos preexistentes:de las bases de datos preexistentes:

• Se pierde totalmente en la integración de datos

• Se preserva totalmente en la integración manualSe preserva totalmente en la integración manual

• Grados intermedios en bases de datos federadas y en almacén de datos

Análogamente respecto a la flexibilidad de añadir más Bases de datosBases de datos

13

1.3 El acceso integrado

Cualquiera de las soluciones debe superardificultades técnicas importantes

En muchos casos es preferible el acceso integrado,dpor razones de:

• viabilidad• preservación de autonomía• preservación de autonomía• flexibilidad y evolución

NoNo sese integranintegran loslos datosdatos, sinosino queque eses elel accesoacceso elelqueque sese dicedice queque eses integradointegrado

14

Dos tipos de usuarios

SBD SBD SBD

SGBD SGBD SGBD

• • •• • •

BD BD BD

• • •

BD

15

BD2-1 2-m

Dos niveles

Hay dos niveles, como mínimo:

• el de las bases de datos preexistentes, quedenominaremos bases de datos componentes:denominaremos bases de datos componentes:

NIVEL COMPONENTE

• el del conjunto de bases de datos que interoperan,que llamaremos

NIVEL FEDERADONIVEL FEDERADO

16

Sistema de Bases de Datos FederadoSistema de Bases de Datos Federado

Diremos queDiremos que

los sistemas de bases de datos componentesse FEDERAN

para dar lugar a un

Sistema de Bases de Datos Federado

(SBDF)

17

Analogía entre la situación actual y la situación de los años 60’s

60’s Proliferación de ficheros en una organizaciónNecesidad de integrar éstos SBD (tecnología de BD)g S ( ec o og de )

90’s Proliferación de SBDs en múltiples organizacionesProliferación de SBDs en múltiples organizacionesNecesidad de federación SBDF: acceso integrado

(tecnología de interoperabilidad)

18

1.4 Sistemas de Bases de Datos Federadas

SBD consiste en un software llamado Sistema de Gestión de Bases de Datos (SGBD) y una o más bases de datos que

tigestiona

SBDF consiste en una colección de Sistemas de Bases deDatos componentes:

cooperantes y autónomosInter-operando según:

Datos componentes:

Inter-operando según:Las necesidades de los usuarios de la federaciónEl deseo de los administradores de las bases de

d i i i ddatos en participar y compartir sus datosManipulados y controlados de manera coordinada por

un software llamado Sistema de Gestión de Bases de

19

Datos Federadas (SGBDF)

Características

• Autonomía (2.1) y heterogeneidad (2.2)• El sistema es distribuido (2 3)• El sistema es distribuido (2.3)

No hay un esquema conceptual global único, común atoda la federación

Las federaciones pueden formarse y desaparecerSistemas de bases de datos pueden entrar y salir de unaSistemas de bases de datos pueden entrar y salir de una

federaciónUn sistema componente puede ser distribuido o a su vez

otro SBDFotro SBDFUn sistema de base de datos puede ser componente de

varias federaciones al mismo tiempo

20

No hay un Esquema conceptual único

SGBDFEC1 EC2

EC3EC3

SBD SBD SBD

SGBD SGBD SGBD

• • •• • •

BD BD BD

• • •

BD

21

BD2-1 2-m

SBDFs

SGBDF SGBDF

SBDcomponente 1

SBDcomponente 2

SBDcomponente n

SGBDcomponente 1

(centralizada)

SGBDcomponente 2

(distribuida)

SGBDcomponente n

(otro SGBDF)• • •• • •

BD• • •

BD c. BD c.

• • •

22

BDcomponente 1 2-1 2-m

Múltiples modelos de federación

No existe un modelo ideal de federación:

· la autonomía y la· en entorno político: Las Naciones Unidas

yheterogeneidad desus componentes

· el poder del cuerpo

difieren en La C.E.I. (ex URSS)La Federación Rusa

el poder del cuerpo de la federación

La UniónEuropeaLa Confederación HelvéticaLa República Federal de AlemaniaE t d U id M iEstados Unidos MexicanosEstados Unidos de AméricaEl grupo de Rioetc

· en el entorno de las bases de datos: diversas arquitecturas(ver 3.)

etc.

23

(ver 3.)

Taxonomía de los Sistemas de Bases de Datos

Centralizados

SBD no FederadosDébilmente acoplados• Es responsabilidad de los usuarios

SBD SMBDHomogéneos

• SBD componentes no autónomos• Lógicamente aparecencomo SBDD

el crear y mantener la federación.• El SBDF no ejerce el control.• Los usuarios deben explícitamentetratar con las múltiples SBDautónomas

SBD Federados

Fuertemente acoplados

gHeterogéneos

• SBD componentes autónomos• Ideal para la migración a un sistemaque permita compartir los datos de forma

autónomas

La federación y sus administradoresque permita compartir los datos de forma parcial y controlada sin afectar lasaplicaciones existentes.

soporte a operaciones a 2 niveles

f ytienen la responsabilidad de crear ymantener ésta, controlando el accesoa los SBD componentes.

24

DistribuidosEsq.Fed.

único MúltiplesEsq.Fed.

Objetivo de esta presentación:

• Exponer la aplicación del concepto de federación paragestionar SBD heterogéneas y autónomas existentes

• apuntarlt ti it tó i• alternativas arquitectónicas

• componentes• puntos relacionados con el desarrollo de un SBDFpuntos relacionados con el desarrollo• puntos relacionados con la operación

25

Guión de la conferencia

1. Introducción






26

y g

2. Características de los SBDFs

2 1 A í2.1 Autonomía

2 2 Heterogeneidad2.2 Heterogeneidad

2.3 Sistema distribuido: Diferencias con bases de datos distribuidas

27

2.1 Autonomía

Los SBD estaban normalmente controlados de forma separada e independientede forma separada e independiente.

¿Compartir datos? ... únicamente si se retiene el control

La autonomía de cada componente puede ser de

• diseño• comunicacionesLa autonomía de cada componente puede ser de comunicaciones• ejecución• asociación

28

Autonomía de diseño

Principal fuentede heterogeneidad

Capacidad del diseñador para elegir su propio diseño entodos sentidos:

i d di é• universo de discurso: qué• conceptualización: qué conceptos• representación (modelo, lenguaje) y nombres: cómo• comportamiento (operaciones, restricciones)• implementación: hard, soft, SGBD, esquema interno, ...• etc.

29

etc.

Antes y después de entrar en la federación: efecto 2000, Euro

Semantics: the three “worlds”

Reality

REAL WORLD

CONCEPTUALWORLD

•Perception•Conceptualization

•DenotationConcepts

Information

Denotation

•Representation•Interpretation

Abstraction

30

REPRESENTEDWORLD DATA

SCHEMAS

Autonomía de comunicación:

Capacidad de un SGBD para decidir:

• si acepta mensajes de otros sistemas componentes

• cómo y cuándo responder a las solicitudesde otros sistemasde otros sistemas

Un SBDF requiere una red de comunicaciones entre los sistemascomponentes, y las correspondientes capas OSI

31

Autonomía de ejecución:

Capacidad de cada SGBD para

• Ejecutar operaciones sin interferencia de operaciones externas(de otros SGBD o SGBDF)• Decidir el orden en que son ejecutadas las operaciones externas• Abortar cualquier operación que no cumpla con las restriccionesq p q ppropias• Que las operaciones a nivel componente no se afecten lógica-mente por su participación en un SBDF

L SGBD t t t l

p p p• No tener que informar a un sistema externo del orden deejecución

Los SGBD componentes tratan a lasoperaciones externas de la mismaforma que a las operaciones propias:

32

no siempre pueden distinguirlas

Autonomía de asociación:

Capacidad de un SGBD para decidir

• con quién compartir

• qué compartir

• cómo compartir• cómo compartir

• si asociarse / desasociarse de una federación

según protocolos establecidos durante la negociación (4.1)

33

Puede considerarse parte de la autonomía de diseño

Autonomía versus comparticiónAutonomía versus compartición

A t íAutonomía

Compartición de datosrequerimientos antagónicos !

En la práctica no es deseable un soporte total de autonomía

34

2.2 Heterogeneidad

HeterogeneidadSemántica(ver luego)

Heterogeneidad de sistemas

SO Hardware (ver luego)

Té i

CPU, comunicacionesSGBD

Modelode Datos

Técnicas

Proceso de

Lenguajes

Heterogeneidadsintáctica

Relacionaly Object-R. Orientado

a objetos

Control deConcurrencia

Recuperación

CODASYL

DB2

consultassintáctica

jOracle

Sybase

SQL Server

ObjectstoreO2GemstoneObjectivity DBPoet

35

CA-Ingres

etc.Matisseetc.

Heterogeneidad de SGBD: la autonomía de diseño por parte de los diseñadores dió lugar a múltiples SGBDslos diseñadores dió lugar a múltiples SGBDs

• requerimientos diferentesdistintos SGBDs etc• cultura informática

• cambios en la tecnología

distintos SGBDs, etc.

Heterogeneidad Semántica: ocurre cuando hay discordancias en• la percepción• la conceptualizaciónla conceptualización• la abstracción•la representación

del universo de discursodel universo de discurso

36

Problema: detectar la heterogeneidad semántica (4.3)

Semantics

• What we mean by semantics?

• Many schools of thought and shades of opinion

• Definitions in philosophy, in linguistics, in logics, in communications, in informatics, ...

• A branch of semioticsA branch of semiotics

37

Semiotics (Morris 1946)Semiotics (Morris, 1946)

S i ti (th th f i ) h 3 b hSemiotics (the theory of signs) has 3 branches:

• Pragmatics:deals with the origin, uses and effects of signs within the behavior in which they occurg y

• Semantics: deals with the signification of signs in allmodes of signifying

S t ti d l ith th bi ti f i ith t• Syntactics: deals with the combination of signs withoutregard for their specific significations or their relation tothe behavior in which they occur

38

The semiotic ladder (Stamper)

SOCIAL WORLD

beliefs expectations commitments contracts social lawsbeliefs, expectations, commitments, contracts, social laws, culture, ...

PRAGMATICS

intentions, communication, conversations, negotiations, speech acts, ...

SEMANTICS

meanings, propositions, validity, truth, signification, denotations, ...

SYNTACTICS

EMPIRICS

pattern, variety, noise, entropy, channel capacity, codes, efficiency, d d

formal structure, language, logic, data, records, deduction, software, files, ...

PHYSICAL WORLDsignals, traces, physical destinctions, hardware, physical tokens, component density, speeds, economics, laws of nature, ...

redundancy, ...

39

Relativismo semántico

L

MUNDO REAL O EXTERIOR

LaRealidad

MUNDO DE LASCONCEPCIONESConceptos ConceptosConceptos

Información

P A

p

Información PersonaB

ESQUEMAS Heterogeneidad

PersonaA

ESQUEMAS

40

MUNDO DE LASREPRESENTACIONES DATOS

ESQUEMAS Heterogeneidadsemántica DATOS

ESQUEMAS

Ejemplo de relativismo semántico

MUNDO REAL O EXTERIOR

Etc

MUNDO DE LASCONCEPCIONES

Etc.

CONCEPCIONES

PersonaB

id d

PersonaA

H

41

MUNDO DE LASREPRESENTACIONES

Heterogeneidadsemántica

CoupleH

WPartners

Clasificaciones de las heterogeneidades semánticas

• Múltiples ad hoc• Múltiples ad hoc

• Kim & Seo (IEEE Computer 91), Kim, Choi, Gala &Kim & Seo (IEEE Computer 91), Kim, Choi, Gala & Scheevel (DPDB 93)

• Sheth & Kashyap (DS5 93)

García Solaco Saltor & Castellanos (Bukhres &• García-Solaco, Saltor & Castellanos (Bukhres & Elmagarmid 95)

42

Clasificación de las heterogeneidades semánticas (García-Solaco 95)

SemanticiHeterogeneity

Object classes Class structures Object instancesObject classes Class structures Object instancesdifferences in:

Extensions

discrepancies:

Presence / Absence

Inconsistencies:

Generalization/Specialization (S) S. criteria

S degrees & characterizationNames

Attributes andMethods

Number of values

Null / non null

V l

S. degrees & characterization S. kinds Constraints

Aggregation/DecompositionSimple ↔ Aggregated classes

Domains

Constraints

Value Simple ↔ Aggregated classes Inconsistency (I) kind of aggregation I. aggregated classes I. collection in aggregated classes I. specialization in aggregated classes

I. composition in aggregated classes I. composition in aggregated classes I. subkind of collection I. component class of the collection

Schematic discrepancies Specialization

43

p Composition Collection & Specialization Collection & Specialization kind

2.3 Sistema distribuido: Diferencias con B de D distribuidas

Los SBDFs y los sistemas de bases de datos distribuidas (SBDD)tienen semejanzas:• hay datos en varias instalacioneshay datos en varias instalaciones• las instalaciones están interconectadas: sistema distribuido• hay diferentes niveles

se form la na preg nta se obtiene na resp esta• se formula una pregunta y se obtiene una respuesta

pero también tienen diferencias:• de diseño• de terminología• de autonomíade autonomía• de transparencias• de arquitectura (ver 3.)

44

En SBDF la “distribución” es una consecuencia de la autonomía

Matices en el diseño

En SBDDs el diseño es descendente (top down)S di ñ l B d D ( t l)• Se diseña una sola B de D (un esquema conceptual)

• Se decide cómo se distribuye entre las instalaciones,incluyendo fragmentación y replicaciónincluyendo fragmentación y replicación

En SBDFs el diseño es ascendente (bottom up)( p)• Las B de D componentes estaban ya diseñadas• Se negocia cómo se agrupan en federaciones• Se construyen los “esquemas conceptuales”• No hay propiamente fragmentación ni replicación** Algunos autores toman también esta opción para los** Algunos autores toman también esta opción para los

45

** Algunos autores toman también esta opción para los ** Algunos autores toman también esta opción para los SBDDSBDD

Diferencia de terminología

En SBDDsL i l l b l l l• Los niveles son: global y local

En SBDFs• Los niveles son: federado y componentef y p(aunque ciertos autores usan global y local)

46

Diferencia de autonomía

En SBDDsL d t d d i t l ió d t í• Los datos de cada instalación carecen de autonomía

• Cada SGBD local obedece al global • Son una parte de la única base de datos• Son una parte de la única base de datos• La Administración de la B de D es sólo global

En SBDFs• Cada SBD componente conserva su autonomía parcialmente

• Cada SGBD componente desconoce al SGBDF• Cada SBD tiene su administrador de B de D • Un SBD puede ser componente de varios SBDFs

47

• Un SBD puede ser componente de varios SBDFs

Diferencia de transparencias

En SBDDs• Todo usuario tiene la imagen de una B de D única g• No percibe que esté distribuida, y menos cómo• Hay transparencia de distribución: fragmentación,

li ió l li ió d ireplicación, localización, correspondencias

En SBDFsEn SBDFs• Ciertos usuarios perciben una B de D única• Otros usuarios quieren saber la fuente de cada dato:q

no tienen transparencia de B de D componentes• Los usuarios preexistentes continuan accediendo sólo

48

a su B de D componente

Contenido

1. Introducción



4. La construcción de un SBDF

5 L ti d SBDF5. La operativa de un SBDF


49

y g


3.1 Arquitectura de referencia de 5 niveles [Sheth90]

3.2 Acoplamientos débil y fuerte

3.3 El papel del Modelo Canónico

3.4 Otras arquitecturas

50

Arquitecturas

Cada SBDF tiene una arquitectura de software y una arquitectura de esquemasarquitectura de esquemas

Toda arquitectura de esquemas debe superar las q q pheterogeneidades sintáctica y semántica

P ll d i ú d i l dPara ello consta de un cierto número de niveles de esquemas

La arquitectura de referencia es la de Sheth & Larson

51

Más niveles en la arquitectura de referencia

La arquitectura marco ANSI/X3/SPARC de tres niveles de esquemas no permite tratar las “tres dimensiones” dede esquemas no permite tratar las tres dimensiones de un sistema de bases de datos federadas:

• autonomía• autonomía• heterogeneidad• sistema distribuidosistema distribuido

i dEs necesario incorporar nuevos niveles

arquitectura decinco niveles

52

Arquitectura de tres niveles de esquemas para SGBD centralizados

Procesador Procesador Procesador Procesador Procesador Procesador

· · ·Esquema externo 1 Esquema externo 2 Esquema externo n

Procesadorde filtrado 1

Procesadortransform. 1

Procesadorde filtrado 2

Procesadortransform. 2

Procesadorde filtrado n

Procesadortransform. n

Esquema conceptual

Procesador de f iótransformación

Esquema interno

Procesador de acceso

53

DB

Five level Schema Architecture of a FDBS (Sheth & Larson90)

External Schema ··· ···External Schema External Schema

Federated Schema Federated Schema Federated Schema

··· ··· ···

Export Schema Export Schema Export Schema

Component Schema Component Schema Component Schema

···

Local Schema ······ Local Schema Local Schema

54

Component DB Component DB Component DB

Arquitectura de cinco niveles de esquemas para SBDF

Esquema Externo Esquema Externo Esquema Externo··· ···

Procesador filtrado Procesador filtrado Procesador filtrado

Esquema Federado

Procesador Construcción

Esquema Federado


Esquema Federado


Procesador filtrado

Esquema Exportación

Procesador filtrado


Procesador filtrado


Procesador filtrado

Esquema Componente

Procesador filtrado

Esquema Componente

Procesador filtrado

Esquema Componente

Procesador Transformación

Esquema Nativo


Esquema Nativo


Esquema Nativo······

55

q

BD Componente

q

BD Componente BD Componente

3.2 Acoplamientos débil y fuerte

SBDF débilmente acoplado (ej.: via Web):•No hay control a nivel federado•Cada usuario integra esquemas de exportación

Ejemplos: MRDSM, OMNIBASE

SBDF fuertemente acoplado:•Hay una administración a nivel federado•El administrador federal integra esquemas de exportación•El administrador federal integra esquemas de exportación•Puede haber:

- un solo esquema federado (Ejemplos: SIRIUS-DELTA, DDTS)- varios esquemas federados (Ejemplos: Mermaid, Multibase)

56

A whole spectrum of autonomy

• Separate queries, manual integration

• Integrated access

Loosely coupled FDBSLoosely coupled FDBS

Tightly coupled FDBS

with several Federated schemas

with only one Federated schema

with 1 Federated schema and interdependencies

• Data integration

57

3.3 El papel del Modelo CanónicoLa heterogeneidad sintáctica entre los modelos nativos de las B de D componentes se solventa gracias al uso deun único modelo de datos en los niveles:un único modelo de datos en los niveles:• esquemas componentes• esquemas de exportación

f d d• esquemas federadosEs el modelo canónico (MC) del SBDF

La heterogeneidad semántica se resuelve mediante laintegración de esquemas de exportación para construiresquemas federados y es el proceso más difícil enesquemas federados y es el proceso más difícil enla construcción de un SBDF (ver 4.3)Esta integración tiene lugar utilizando los recursos del

d l ó i

58

modelo canónico:Importancia de la elección del modelo canónico

The CDM in the Five level Schema Architecture of a FDBS

External Schema ··· ···External Schema External Schema

UsersmodelorCDM

Usersmodel

Usersmodel

Federated Schema Federated Schema Federated Schema

··· ··· ···CDM

CDM



···

Local Schema ······ Local Schema Local SchemaNativemodel

Nativemodel

Nativemodel

59


Enfoques en la elección del modelo canónico

Enfoque minimalista:• Adoptar un MC con el mínimo de estructuras y operaciones• Traducir estructuras de cualquier modelo a construcciones• Traducir estructuras de cualquier modelo a construcciones

de estructuras en el MC:de más nivel semántico a menos

Enfoque maximalista:• Elegir un MC con el máximo poder de representaciónElegir un MC con el máximo poder de representación• Toda estructura de otro modelo tendrá su correspondencia

en alguna estructura del MC:d i l á ti áde menos nivel semántico a más

• Conserva la expresividad semántica de los esq. componentes(o la aumenta -ver 4.2-)

60

Marco de características de un MCSe ha desarrollado un marco general de característicasdeseables de un modelo para ser MC de un SBDF:

características de i id d• características de expresividad• características de relativismo semántico

Se han analizado diversos modelos utilizando este marco,y han resultado más adecuados para MC:• algunos modelos funcionalesalgunos modelos funcionales• algunos modelos orientados a objetos• pero no los Extended E-R

ACM SIGMOD Record, vol 20, no 4 (Dec 1991)

61

Analysis of suitability of data models as CDMCharacteristic Pre-rel Rel Rel V2 RM/T E-R Ext. E-R Seman Func O-O

O-O

Eaclasses *

metaclasses some somemany levels sub/super &

inheritance *Eb

inheritance

diff. kinds of specializ.multiple inheritance

somesome

somesome

Eccartesian aggregation *

cover aggregation * someEc cover aggregation

other aggregations

some

some some

Edextensibility behaviour *

encapsulation

some

encapsulation

SRaintegration operators &

transformation ops *

upward inheritance

ERC+

someSRb d i hSRb power to derive ext. sch.

as great as view mech.*some

SRc only one basic structure &

SRd multiple semantics

62

* indicates that it is an essential characteristic, the rest are only recommended ones& indicates that it is arguable

Object oriented models as CDM

• Extended E-R models were preferred in the 80’sNavatheNavathe

LarsonSpaccapietra

etcetc

• Object Oriented models seem to be the choice in the 90’sjSchek & SchollDittrichKent

BLOOM: Semantic extension of an object oriented model

Kentetc

63

• Alternativa: Description Logics

Dimensions and abstractions

Expressed as relationships between objects/classes:

Classification/instantiation: instance of class– Classification/instantiation: instance of class

– Generalization/specialization: subclass of superclass

Aggregation/decomposition:– Aggregation/decomposition:

• part (component) of whole

• element of set• element of set

• reference to

– Behavioural: sends messages toBehavioural: sends messages to

– Point of view: internal representation of conceptual

external view of conceptual

64

external view of conceptual

– Temporal: new version of

BLOOM99 (BarceLona Object Oriented Model): a rich canonical model for integrationa rich canonical model for integration

• Semantic extension of an object oriented model

• Rich set of Abstractions:• Classification/Instantiation: Objects, Classes, Metaclasses, Metametaclass

• Specialization criteria and four kinds of Generalization/Specialization:• Alternative : each object belongs to one and only one subclass• Disjoint : each object of the superclass belongs at most to one subclass• Complementary : each object of the superclass belongs at least to one subclass• Complementary : each object of the superclass belongs at least to one subclass• General : has no restrictions

• Two kinds of Aggregation:C iti th t bj t i f d b ti bj t f•Composition : the aggregate object is formed by aggregating objects from

one or more classes (cartesian and cover aggregation)•Simple : the simplest type of aggregation, represents properties

65

Object s

Classes

instance

subcla ss

Specialization dimension in BLOOM

Met aclasses

disjointsp

e cia liza tdisjoint

spe cia liza tdisjoint

spe cia liza t

sales

Edga r

class

supe

rclass

spec ia

k ind_

gene ralspec ia liza tion

tiontiontion

pe rson

employee

sman

m

ocupation

ty pe_o

f _c o

n-

t ract

a liza tion

_o f_

spec

disjo in t

spec ia liza tiod

isjo in tspec ia liza tio

a lte rna tivespec ia liza tio

student

manage r

p ropagatea lte rna tive

special.

baltesp

subc lass_de le t_e

ffect

ononeon

d is jspecia

co mp le

spec ia

fe ma l

ma le

p ropaga teco m

ple m

.spec ia l.

subclas_e f

b lock

e rnative

pecial.

e

o intlization

e men ta ry

a lizat ion

ee e.b lo ck

co mple m

.spec ia l.

ss_delete

ffec t

66

3.4 Otras arquitecturas

Arquitectura de Wrappers y Mediators

Arquitecturas con menos niveles

Arquitecturas con más niveles

Arquitecturas integradasArquitecturas integradas

Algunos casos específicosAlgunos casos específicos

67

Una arquitectura de SBDF con menos nivelesEsquema Esquema q

Externo 1 - 1q

Externo 1 - 2

E F d d 2Esquema Federado 1 Esquema Federado 2

Esquema Exportación 1 - 1

Esquema Exportación 2

Esquema Exportación 1 - 2

Esquema Componente 1Esquema Exportación 3 =Esquema Componente 3

Esq. Nativo 1

BD Componente 1 BD Componente 2

Esq. Nativo 3

BD Componente 3

Esquema Componente 2= Esquema Nativo 2

68

BD Componente 1 BD Componente 2 BD Componente 3

Multiple semantics versus one semantics

External Schema 2 External Schema 3External Schema 1

Semantics 1 Semantics 2 Semantics 3

Federated SchemaMultiple semantics and

source tagged




69


Multiple semantics: the application schemaExternal Schema 2 External Schema 3External Schema 1

Semantics 1 Semantics 2 Semantics 3

Application SchemaApplication Schema A li ti S h

Federated Schema Multiple semantics andsource tagged

Application SchemaApplication Schema Application Schema




70


The BLOOM99 Construction Architecture

User Schema 11IJ-1

User Schema 1111

. . .

User Schema 12IJ-1 . . .

User Schema 1211 . . .

. . .

User Schema 1LIJ-1

User Schema 1LI1

. . .

Transforming Processor Transforming Processor Transforming ProcessorUser Schema M1IJ User Schema MLIJ

UDMs

Derivation Processor Derivation Processor

Translated Schema 12I

Translated Schema 121 . . .

. . .

Translated Schema 11I

Translated Schema 111

. . .

. . . . . . . . .

Derivation Processor Derivation Processor Derivation Processor

Translated Schema 1LI

Translated Schema 1L1

. . .

User Schema M1IJ || . . .Translated Schema M1I

User Schema M11J || . . .Translated Schema M11 . . .

User Schema MLIJ ||Translated Schema MLI

User Schema ML1J ||Translated Schema ML1 . . .

Security Processor Security Processor

Authorization Schema 11 Authorization Schema 12 . . . Authorization Schema 1L Authorization Schema M1 . . . Authorization Schema ML

N CDBs

M F d t d

Export Schema K1 Export Schema K2 . . .Export Schema 1 . . .

Federated Schema 1 . . .

Integration Processor

Export Schema N

Federated Schema M

Integration Processor

M Federated Schemas

L Levels of Security Classification

I User Views

J User Models

Conversion Processor

Component Schema K . . .

Negotiation Processor Negotiation Processor


Component Schema 1 . . .

Negotiation Processor


Component Schema N CDM

71


Native Schema K . . .


Native Schema 1 . . .


Native Schema N NDMs

72

Pegasus (HP)

EsquemaFederadoFederado

Esquema de Importación 1expresado en IRIS

Esquema de Importación 2expresado en IRIS

Esquema de Importación nexpresado en IRIS···

Esquema Local 1Relacional (Allbase)

Esquema Local 2Multimedia

Esquema Local nOdapter···Relacional (Allbase) Multimedia Odapter

73

Guión de la conferencia

1. Introducción




5. La operativa de un SBDF

6 Conclusiones y bibliografía

74



4.1 El proceso de negociación

4.2 Enriquecimiento semántico

4.3 Integración de esquemas

4.4 Consideraciones extensionales

4.5 Derivación de esquemas externos

75

4.1 El proceso de negociación

Hay dos casos:• Para formar una federación nueva

P i B d D t SBDF i t t• Para incorporar una B de D componente a un SBDF existente

El administrador del SBD componente cede acceso a datos• a cambio de poder acceder a otros datos• siguiendo órdenes de rango superior

El SBD pierde autonomía: debe obedecer protocolos• respecto a modificar su esquema nativo

t b d l SBDF• respecto a abandonar el SBDF

Si el SBDF es fuertemente acoplado, la negociación es más compleja

76

Si algún SBD tiene seguridad MAC1y no DAC2, más dificultades1Mandatory Acces Control, 2Discretionary Acces Control

4.2 Enriquecimiento semánticoEsquema Externo Esquema Externo Esquema Externo··· ···


Esquema Federado


Esquema Federado


Esquema Federado


Esquema Exportación Esquema Exportación

P d filt d


Procesador filtrado

Esquema Componente

Procesador filtrado

Esquema Componente

Procesador filtrado

Esquema Componente


Esquema Nativo


Esquema Nativo


Esquema Nativo······

77

Esquema Nativo

BD Componente

Esquema Nativo

BD Componente

Esquema Nativo

BD Componente

···

Semantic Enrichment

• Database schemas are usually semantically poor

• Certainly for pre-relational databases

• Often for relational databases

• Bigger problem for non-DB sources: files, spreadshets, semistructured data, closedspreadshets, semistructured data, closed applications, ...

78

Enriquecimiento semántico: por qué

Semantic Heterogeneities:really difficult!really difficult!

not only to solve them but to detect them

d d t di f th i f th DB i i d⇒ a deep understanding of the meaning of the DBs is required

but... often this understanding does not exist

⇒

and local schemas do not help to acquire it:they are semantically poor

Solution: upgrade the semantic level of the schemas

79

SEMANTIC ENRICHMENT

Una metodología de enriquecimiento semántico

• Requires additional knowledge on the semantics of the database

it must include a Knowledge Acquisition phase⇒

• Makes explicit this semantics in an enriched representation

it must include a Conversion phase⇒ it must include a Conversion phase⇒

Semantic EnrichmentKnow.Acq Conversion

BLOOMschemasRelational

schemasIntegration

Fed.Schema

80

Acq.

Discovering Semantics

The process of upgrading(creating) the semantic contents of schemas by discovering semantics not explicitly expressedexplicitly expressed

• Discovery of structures

• Discovery of integrity constraints

• Discovery of behaviour - - - - >

May analyze extensions, programs, ...

81

Uses of Semantic Enrichment

• To build a FIS*

• To add a new IS to an existing FIS

but also

• To build a Data Warehouse

• To understand a database or IS• To understand a database or IS

• To migrate to a new DBMS

a reverse engineering, Data Mining/KD case

82*Federated Information System (FIS)

4.3 Integración de esquemasEsquema Externo Esquema Externo Esquema Externo··· ···


Esquema Federado


Esquema Federado


Esquema Federado


Esquema Exportación Esquema Exportación Esquema Exportación

Procesador filtrado

Esquema Componente

Procesador filtrado

Esquema Componente

Procesador filtrado

Esquema Componente


Esquema Nativo


Esquema Nativo


Esquema Nativo···

83

Esquema Nativo

BD Componente

Esquema Nativo

BD Componente

Esquema Nativo

BD Componente

······

Integración de esquemas

Proceso de integración:• seleccionar un conjunto de esquemas de exportación a integrar• integrarlos para producir un esquema federado• generar las correspondencias entre esquemas (directorio)g p q ( )• desarrollar el procesador de construcción:

operaciones sobre el esq. federado

operaciones sobre los esq. exportación

84

Ayudas a la integración de esquemas

• Data Joiner, Websphere MQIntegrator (IBM)

• Enterprise Connect (Sybase)

• DB Integrator (DEC -> Oracle)

• Ontos*Integrator (Ontos)

• ODBX (B2 Systems)• ODBX (B2 Systems)

• ...

• OLE DB (Microsoft)OLE DB (Microsoft)

• ...

85

Detecting Semantic Heterogeneities

• When a class c1 in IS1 has the same meaning as a class c2 in IS2?

• Not just synonyms homonyms but all kinds of• Not just synonyms, homonyms, but all kinds of semantic heterogeneities

• Schematic discrepancies: data in IS1 versus metadata in IS2

• Detection is hard: that´s why as much semanticsas possible is neededas possible is needed

86

D t ti f i t d t b ti l ti hiDetection of interdatabase semantic relationships

Most critical task of the integration !

Identification of similarities among thel f diff d bclasses of different databases

Two approaches:Two approaches:• based on attribute comparison• based on structure comparison

87

Phases of integration methodology in BLOOM

1. Semantic Enrichment Semantic Enrichment

Schema nSchema 1 DB 1 DB n···

1. Semantic Enrichment

• Knowledge Acquisition• Schema Conversion to BLOOM model

Semantic Enrichment

BLOOMBLOOM ···

2. Detection of interdatabase semanticrelationships

schema nschema 1

i t t

Sequencer

p

3. Resolution of semantic conflicts andconstruction of the federated schema(s)

SimilarityDetector

ResolutionConformedschemas

Semanticrelationships

integrator

construction of the federated schema(s)

Integrateddata flow

88

gSchema

& mappingscontrol flow

Our Approach to Detection

U th i h b t ti f BLOOM l th li tiUse the rich abstractions of BLOOM along the generalizationand aggregation dimensions

Strategy: which classes to compare

• at a coarse level:at a coarse level:• guided by the structures along the generalization dimension

• at a finer level:• guided by the structures along the aggregation dimension

Criteria: how similar the classes are

89

• based on the aggregation dimension

Resolution: Discriminated Generalization

• The properties of the superclass are the union of the properties of itssubclasses

• Each object of a subclass, when viewed as member of the superclass,has a discriminant attribute

For integration purposes, the discriminant takes as value the nameof the database where it comes from--> at the federated level, each object is tagged with its DB name

• Overcomes limitations of other other approaches by:Overcomes limitations of other other approaches by:• preserving all the information

• making database transparency optional

90

• supporting multiple semantics

Example of resolutionequivalent

DB2 Step 1 Step 2

PERSONPEOPLE

Activity Activity

DB1 DB2 Step 1integrate STUDENT and STUDENT

FSTUDENT

DB

Step 2integrate WORKER and EMPLOYEE

FWORKER_EMPLOYEE

EMPLOYEEWORKERSTUDENT STUDENT

equivalent

equivalent

STUDENT_DB1 STUDENT_DB2

WORKER EMPLOYEE

DB

Step 3integrate classes PEOPLE and PERSON

FPEOPLE_PERSON

Step 4: connect the superclasses created in the previoussteps to obtain the integrated specialization

FPEOPLE_PERSON

PERSONPEOPLE

Activity Activity

DB

PERSONPEOPLE

DB Activity

FSTUDENT

DB

FWORKER_EMPLOYEE

DBActivity

Postcondition: - prop (SC) = prop (C1) ∪ prop (C2) ∪ discriminant

EMPLOYEEWORKERSTUDENT STUDENT

EMPLOYEEWORKER

Activity

STUDENT_DB1 STUDENT_DB2

91

- card (SC) = card (C1) + card (C2)

- extension (SC) = ext (C1) ∪Δ ext (C2) ( ∪Δ means outer discriminated union)

Discriminated Generalization

DB1 PERSONSDB1.PERSONSname Joan Pere Marcphone 13578 47835 47782address Bailen 4 Bruc 9 Sants 2birth_date 050160 122263 160858

DB2.PEOPLEname Joan Peter Annaname Joan Peter Annaphone 24680 12345 47782birth_date 050160 122263 160858status married single divorced

FPERSONSname_db1 Joan Pere Marc null null nullphone_db1 13578 47835 47782 null null nulladdress Bailen 4 Bruc 9 Sants 2 null null nullbirth_db1 050160 122263 160858 null null nullname_db2 null null null Joan Peter Annaphone_db2 null null null 24680 12345 47782birth_db2 null null null 050160 122263 160858status null null null married single divorced

92

status null null null married single divorceddatabase DB1 DB1 DB1 DB2 DB2 DB2

4.4 Consideraciones extensionalesWhat if database objects (from different CDBs) denoting the same

real world object need to be collapsed into a single one ?

• This requires an object identification function (oif)(to correlate objects in one database to objects in another)

• Different oif’s may exist according to different encompassingcontexts

• It is possible to derive from a federated class an external class ECfor each oif: objects correlated by oif are collapsed in the virtualextension of EC

EC = collapse (FC, oif)

93

Si hay interdependencias se puede colapsar a nivel de esq. federado

Object identification function

Obj t 1 i IS1 d 2 i IS2 id d b• Objects o1 in IS1 and o2 in IS2 are considered bya a user A to refer to the same object in theoutside world if

oifA (o1, o2) = TRUE

• Different users may have different oifs: multiplesemanticssemantics

Libros: ISBN, ISBN+print, Ncatal, ...

• All users share just one oif: used for the schemajintegration process

94

Object identification functionsFPERSONSFPERSONS

name_db1 Joan Pere Marc null null nullphone_db1 13578 47835 47782 null null nulladdress Bailen 4 Bruc 9 Sants 2 null null nullbi th db1 050160 122263 160858 ll ll llbirth_db1 050160 122263 160858 null null nullname_db2 null null null Joan Peter Annaphone_db2 null null null 24680 12345 47782birth_db2 null null null 050160 122263 160858status null null null married single divorcedstatus null null null married single divorceddatabase DB1 DB1 DB1 DB2 DB2 DB2

TPERSONS1name Joan Pere Marc Peter Annaname Joan Pere Marc Peter Annaphone 13578 47835 47782 12345 47782 address Bailen 4 Bruc 9 Sants 2 null nullbirth 050160 122263 160858 122263 160858status married null null single divorced

TPERSONS2name Joan Pere Marc Annaphone1 13578 47835 47782 47782

h 2 24680 12345 ll ll

95

phone2 24680 12345 null nulladdress Bailen 4 Bruc 9 Sants 2 nullbirth 050160 122263 160858 160858status null single null divorced

4.5 Derivación de esquemas externosEsquema Externo Esquema Externo Esquema Externo··· ···


Esquema Federado


Esquema Federado


Esquema Federado


Esquema Exportación Esquema Exportación Esquema Exportación

Procesador filtrado

Esquema Componente

Procesador filtrado

Esquema Componente

Procesador filtrado

Esquema Componente


Esquema Nativo


Esquema Nativo


Esquema Nativo···

96

Esquema Nativo

BD Componente

Esquema Nativo

BD Componente

Esquema Nativo

BD Componente

······

Contenido

1. Introducción





6 Conclusiones y bibliografía

97



5.1 Arquitectura modular

5 2 P d i ió d lt5.2 Proceso y descomposición de consultas

5 3 Gestión de transacciones5.3 Gestión de transacciones

5.4 Consolidación del resultado

98

5.1 The BLOOM99 Execution Architecture

• Data flow:

Security Controller

Federated Query Federated Result

User schema

User schema SECU

Query Transformer

Query Descomposer

Result Transformer

Result Consolidator

QUERY

+mappings

Fed. schema+

mappings

Com. schema

mappings amongUS and FS

mappings amongFS and CSs

i

URITY

M . . . . . .. . . . . .

D

I

R

E

C

T

D

I

R

E

C

TQuery Translator

Level Security Translator

Subresult TranslatorQUERYMANAGER

Com. schema+

mappings

mappings amongCSs and NSs

mappings amongFSL and CSLs

ANAGER . . . . . .

. . . . . .

. . . . . .

T

O

R

Y

T

O

R

Y

TRANSACTION MANAGER

. . . . . .DBMS1 DBMS2 DBMSK DBMSN

Control Sec

99

DB1 DB2 DBK DBN

5.2 Proceso y descomposición de consultasEsquema Externo

Procesador filtrado

Esquema Federado


Esquema Exportación Esquema Exportación

Procesador filtrado

Esquema Componente

Procesador filtrado

Esquema Componente Esquema Externo


Esquema Nativo


Esquema Nativo

Procesador de filtrado

···

100

Esquema Nativo

BD Componente

Esquema Nativo

BD Componente

···

5.3 Gestión de transacciones

• Es responsabilidad del nivel federal• permitir actualizaciones concurrentes a través de múltiples bases de datos• mantener la consistencia de las bases de datos (si hay interdependencias)

• Es muy difícil de soportar• los SBD suelen ser heterogéneos• los SBD mantienen su autonomía de ejecución

por ahora no hay ningún prototipo de SBDF que la soporte plenamente

• Dos tipos de transacciones• Transacciones de los usuarios de la federación hacia el SGBDF• Transacciones hacia los SGBD componentes de sus usuarios propios• Transacciones hacia los SGBD componentes de sus usuarios propios

problemas en el control de concurrencia: • el SGBDF no conoce las transacciones a nivel componente• los SGBDs no siempre pueden distinguir entre éstas y las subtransacciones

101

p p g y

Dos tipos de transacciones

SGBDFSGBDF

SBD SBD SBD

SGBD SGBD SGBD

• • •• • •

BD BD

• • •

BD

102

BD BD 2-1

BD 2-m

BD

Gestión de transacciones (cont.)

• Los mecanísmos de control de concurrencia de losSGBD componentes no son visibles externamente

Aumenta el problemaAumenta el problema

• Problema de detección de abrazo mortal a nivel federal

• Diversos enfoques relajar criterios (ACID)

• La autonomía total es incompatible con la Atomicidad

• Incluso para transacciones Read only, la autonomía total esincompatible con Repeatable Read

• Para transacciones que actualizan, la autonomía total no puede asegurar ningún nivel de Aislamiento

103

• Si hay interdependencias, el problema es aún más complejo

5.4 Consolidación del resultado

Cada subtransacción devuelve un (sub)resultado parcial

Conversión de subresultados al modelo canónico

Consolidación de subresultados para producir el resultado:

• problema de identificación de instancias: oifproblema de identificación de instancias: oif

• las oif se habrán definido en la integración (4.4)

Ejemplo de bibliotecas: por igualdad del ISBN?

104

ContenidoContenido

1 Introducción1. Introducción





105


Conclusiones

El acceso integrado a B de D heterogéneas es un problema cada vez más realp

Es uno de los temas de más interés (hot topics) en B de D,con una serie de problemas no resueltos

Hay programas específicos de investigación en JapónHay programas específicos de investigación en Japón, en Estados Unidos y en Europa

Se han celebrado congresos especializados y se han publicadonúmeros especiales de revistas; aparecen libros

106

Problemas abiertos• Identificar y representar toda semántica útil para la realización de diversas tareas

• Herramientas semiautomáticas para asistir en varias tareas (integración, etc.)

• Modelos y algorítmos de gestión de transacciones adecuados para distintos niveles• Modelos y algorítmos de gestión de transacciones adecuados para distintos niveles de aislamiento y con rendimiento aceptable

• Sistemas de bases de conocimientos federadosSistemas de bases de conocimientos federados• Integrar

• Bases de datos relacionales, OO, deductivas, activas, hipermedia, ...• Aplicacionesp• Sistemas expertos

• ¿ Cómo representar contenidos de información, capacidades de procesa-miento, semántica, etc. de programas y sistemas expertos adecuadamente ?

• Nuevos modelos de federación: cooperación evolutiva• El impacto de Internet y la World Wide Web

XML

107

Special issues of journals

IEEE-CS Data Engineering Bulletin 10(3), Sep’87

ACM Computing Surveys 22(3), Sep’90

ACM SIGMOD Record 20(4), Dec’91

IEEE-CS Computer 24(12), Dec’91

VLDB Journal 1(1&2), Jul&Oct’92

ACM Computing Surveys 27(2), Jun’95

Journal of Intelligent Information Systems 6(2/3) ‘96

IEEE-CS Data Engineering Bulletin 21(3), Sep’98

ACM SIGMOD Record 28(1), Mar’99

Journal of Coperative Informations Systems

108

Books on FIS issuesBooks on FIS issues

• Hurson, Bright & Pazad (eds): Multidatabase Systems. IEEE-CS Press’93CS Press 93

• W. Kim (ed.): Modern Database Systems: The Object Model, Interoperability, and Beyond. Adison Wesley’95

• Bukhres & Elmagarmid (eds): Object Oriented MultidatabaseBukhres & Elmagarmid (eds): Object Oriented Multidatabase Systems. Prentice-Hall’96

• S. Conrad: Föderierte Datenbanksysteme. Springer Verlag’97g

• Papazoglou & Schlageter (eds): Cooperative Information Systems. Academic Press’98

• Elmagarmid, Rusinkiewicz & Sheth (eds): Management ofElmagarmid, Rusinkiewicz & Sheth (eds): Management of Heterogeneous and Autonomous Database Systems. Morgan Kaufmann’99

• Mena & Illarramendi: Ontology-Based Query Processing for

109

gy y gGlobal Information Systems. Kluwer’01

bd federadas

Documents