SISTEMAS DE BASES DE DATOSSISTEMAS DE …vjsosa/clases/tsbd/... · Sybase SQL Server Objectstore O2...
Transcript of SISTEMAS DE BASES DE DATOSSISTEMAS DE …vjsosa/clases/tsbd/... · Sybase SQL Server Objectstore O2...
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
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
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
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
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
2. Características de los Sistemas de Bases de Datos Federadas
3. Arquitecturas de SBDFs
4. La construcción de un SBDF
5 L ti d SBDF5. La operativa de un SBDF
6. Conclusiones y bibliografía
49
y g
3. Arquitecturas de SBDFs
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
Procesador Construcción
Esquema Federado
Procesador Construcción
Procesador filtrado
Esquema Exportación
Procesador filtrado
Esquema Exportación
Procesador filtrado
Esquema Exportación
Procesador filtrado
Esquema Componente
Procesador filtrado
Esquema Componente
Procesador filtrado
Esquema Componente
Procesador Transformación
Esquema Nativo
Procesador Transformación
Esquema Nativo
Procesador Transformación
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
Export Schema Export Schema Export Schema
Component Schema Component Schema Component Schema
···
Local Schema ······ Local Schema Local SchemaNativemodel
Nativemodel
Nativemodel
59
Component DB Component DB Component DB
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
Export Schema Export Schema Export Schema
Component Schema Component Schema Component Schema
Local Schema ······ Local Schema Local Schema
69
Component DB Component DB Component DB
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
Export Schema Export Schema Export Schema
Component Schema Component Schema Component Schema
Local Schema ······ Local Schema Local Schema
70
Component DB Component DB Component DB
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
Conversion Processor
Component Schema 1 . . .
Negotiation Processor
Conversion Processor
Component Schema N CDM
71
Conversion Processor
Native Schema K . . .
Conversion Processor
Native Schema 1 . . .
Conversion Processor
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
2. Características de los Sistemas de Bases de Datos Federadas
3. Arquitecturas de SBDFs
4. La construcción de un SBDF
5. La operativa de un SBDF
6 Conclusiones y bibliografía
74
6. Conclusiones y bibliografía
4. La construcción de un SBDF
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··· ···
Procesador filtrado Procesador filtrado Procesador filtrado
Esquema Federado
Procesador Construcción
Esquema Federado
Procesador Construcción
Esquema Federado
Procesador Construcción
Esquema Exportación Esquema Exportación
P d filt d
Esquema Exportación
Procesador filtrado
Esquema Componente
Procesador filtrado
Esquema Componente
Procesador filtrado
Esquema Componente
Procesador Transformación
Esquema Nativo
Procesador Transformación
Esquema Nativo
Procesador Transformación
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··· ···
Procesador filtrado Procesador filtrado Procesador filtrado
Esquema Federado
Procesador Construcción
Esquema Federado
Procesador Construcción
Esquema Federado
Procesador Construcción
Esquema Exportación Esquema Exportación Esquema Exportación
Procesador filtrado
Esquema Componente
Procesador filtrado
Esquema Componente
Procesador filtrado
Esquema Componente
Procesador Transformación
Esquema Nativo
Procesador Transformación
Esquema Nativo
Procesador Transformación
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··· ···
Procesador filtrado Procesador filtrado Procesador filtrado
Esquema Federado
Procesador Construcción
Esquema Federado
Procesador Construcción
Esquema Federado
Procesador Construcción
Esquema Exportación Esquema Exportación Esquema Exportación
Procesador filtrado
Esquema Componente
Procesador filtrado
Esquema Componente
Procesador filtrado
Esquema Componente
Procesador Transformación
Esquema Nativo
Procesador Transformación
Esquema Nativo
Procesador Transformación
Esquema Nativo···
96
Esquema Nativo
BD Componente
Esquema Nativo
BD Componente
Esquema Nativo
BD Componente
······
Contenido
1. Introducción
2. Características de los Sistemas de Bases de Datos Federadas
3. Arquitecturas de SBDFs
4. La construcción de un SBDF
5. La operativa de un SBDF
6 Conclusiones y bibliografía
97
6. Conclusiones y bibliografía
5. La operativa de un SBDF
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
Procesador Construcción
Esquema Exportación Esquema Exportación
Procesador filtrado
Esquema Componente
Procesador filtrado
Esquema Componente Esquema Externo
Procesador Transformación
Esquema Nativo
Procesador Transformación
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
2. Características de los Sistemas de Bases de Datos Federadas
3. Arquitecturas de SBDFs
4. La construcción de un SBDF
5. La operativa de un SBDF
105
6. Conclusiones y bibliografía
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