Vous êtes sur la page 1sur 10

Eligio Martnez

Fernando

RESUMEN DEL
CAPITULO 4
Base de datos distribuidos

Nombre. Eligio Martnez

Fernando
Grupo.

5701

Profesor. Jimnez Alfaro Abraham Jorge

Introduccin

Integracin de base de datos


4.1 de depsito de datos

El proceso consiste en la integracin de bases


de datos locales con su (locales) esquemas en
una base de datos global con su esquema
conceptual global (GCS) (tambin llamado el
esquema mediada).

Integracin de base de datos, y el problema


relacionado de consultar multidatabases (ver
Captulo 9), es slo una parte del problema
ms general de interoperabilidad. en reciente
aos, las nuevas aplicaciones distribuidas han
comenzado a plantear nuevos requisitos
relativos la fuente (s) de datos que tienen
acceso. Paralelamente, la gestin de los
"sistemas de legado" y la reutilizacin de los
datos que generan han ganado importancia. El
resultado ha sido una se vuelva a considerar la
cuestin ms amplia de la informacin sobre la
interoperabilidad del sistema, incluyendo
fuentes no base de datos y la interoperabilidad
a nivel de aplicacin, adems al nivel de la
base de datos.

La integracin de bases de datos puede ser


fsica o lgica [Jhingran et al., 2002]. En el
primero, las bases de datos fuente se integran
y se materializa la base de datos integrada.
Estos son conocidos como los almacenes de
datos. La integracin es ayudado por el
extracto-transformador
carga
(ETL)
de
herramientas que permiten la extraccin de
datos de fuentes, su transformacin para que
coincida con la GCS, y su carga (es decir, la
materializacin) de aplicaciones de empresa.
Integracin (EAI), que permite el intercambio
de datos entre aplicaciones, realice similares
funciones de transformacin, aunque los datos
no se materializan en su totalidad. Este
proceso se representa en la figura 4.1. En la
integracin lgica, lo conceptual global (o
mediada) esquema es completamente virtual y
no se ha materializado.

Captulo 4

Aplicaciones OLTP, como la reserva de vuelos o


sistemas bancarios, son de alto rendimiento de
la transaccin orientada. Que necesitan gran
cantidad de datos
control y disponibilidad, alto rendimiento
multiusuario y predecible respuesta, rpido
veces. En contraste, las aplicaciones OLAP,
tales como anlisis de tendencias o la
prediccin, la necesidad de analizar, datos
histricos resumidos procedentes de una serie
de bases de datos operativas.
Utilizan consultas complejas sobre tablas
potencialmente muy grandes. Debido a su
estratgica la naturaleza, el tiempo de
respuesta es importante. Los usuarios son
responsables o analistas.
Consultas OLAP directamente a ms bases de
datos operativas distribuidas plantea dos
problemas.
En primer lugar, me duele el rendimiento de las
aplicaciones OLTP 'al competir por los recursos
locales.
En segundo lugar, el tiempo total de respuesta
de las consultas OLAP puede ser muy pobre,
porque grandes cantidades de datos deben ser
transferidos a travs de la red. Adems, la
mayora OLAP las aplicaciones no necesitan las
versiones ms actuales de los datos, y por lo
tanto no es necesario acceso directo a la
mayora de los datos de funcionamiento de
hasta al da. En consecuencia, los almacenes
de datos recopilar datos de una serie de bases
de datos operacionales y materializarlas. como
actualizaciones suceder en las bases de datos
operacionales, que se propagan al almacn de
datos (tambin referido como materializado
vista de mantenimiento [Gupta y Mumick,
1999b]).

bastante difcil dada la autonoma


subyacente DBMS operacionales.

del

Lgica de datos de integracin, y los sistemas


resultantes, son conocidos por una variedad de
nombres; integracin de datos e integracin de
informacin son quizs los ms comunes los
trminos utilizados en la literatura. La
generalidad de estos trminos apuntan al
hecho de que las fuentes de datos subyacentes
no tienen que ser las bases de datos. En este
captulo nos centramos nuestra

Por el contrario, en la integracin de datos


lgicos, la integracin es slo virtual y hay sin
materializado base de datos global (vase la
Figura 1.18). Los datos residen en las
operativas bases de datos y la GCS proporciona
una integracin virtual para consultar sobre
ellos similares para el caso descrito en el
captulo anterior.
La diferencia es que el GCS no puede ser la
unin de los schamas conceptuales local (LCS).
Es posible que el GCS no para capturar toda la
informacin en cada uno de los LCS. Adems,
en algunos casos, GCS puede definirse de
abajo hacia arriba, por "integracin" de las
partes de los LCS de lo local bases de datos
operacionales en lugar de ser definido por
adelantado (ms sobre esto en breve).

4.1 abajo hacia arriba la metodologa


de diseo
Las consultas se posaron sobre este esquema
global, que luego se descompone y enviados a
las bases de datos operacionales locales para
el procesamiento como se hace en bien
integrada sistemas. Las principales diferencias
son la autonoma y el potencial de la
heterogeneidad sistemas locales. Estos tienen
efectos importantes en el procesamiento de
consultas que se discuten en
Captulo 9. Aunque hay un amplio trabajo sobre
la gestin de transacciones en estos sistemas,
apoyo a las actualizaciones globales es

atencin en la integracin de los autnomos y


(posiblemente) bases de datos heterogneas;
por lo tanto vamos a utilizar la integracin
trmino base de datos (que tambin ayuda a
distinguir estos sistemas de almacenes de
datos)

4.1 abajo hacia arriba la metodologa


de diseo
Diseo de abajo hacia arriba implica el proceso
por el cual la informacin de participar bases
de datos pueden ser (fsica o lgicamente)
integrada para formar un nico multi- cohesiva
base de datos. Hay dos enfoques alternativos.
En algunos casos, el conceptual mundial(o
mediada) esquema se define primero, en cuyo
caso el diseo de abajo hacia arriba implica
mapeo de los LCS a este esquema. Este es el
caso en los almacenes de datos, pero la
prctica es no se limita a estas y otras
metodologas de integracin de datos puede
seguir el mismo
estrategia. En otros casos, el GCS se define
como una integracin de partes del LCS. En
esto caso, el diseo de abajo hacia arriba
implica tanto la generacin de la GCS y el
mapeo de los LCS individuo a este GCS.

3. asignacin de esquema que determina cmo


asignar los elementos de cada uno de LCS los
otros elementos de la GCS (seccin 4.4).

(GAV), por otro lado, el GCS se define como un


conjunto de vistas sobre el LCS. Estas vistas
indican cmo los elementos de la GCS se
pueden derivar, cuando sea necesario, de la
elementos de LCS. Una forma de pensar en la
diferencia entre los dos es en trminos de los
resultados que se pueden obtener a partir de
cada sistema [Koch, 2001]. En GAV, la consulta
los resultados se ven limitados al conjunto de
objetos que se definen en la GCS, aunque el
DBMS local puede ser considerablemente ms
rico (Figura 4.2 a). En LAV, por otra

Tambin es posible que la etapa de asignacin


de esquema se puede dividir en dos fases
[Bernstein y Melnik, 2007]: generacin de
restriccin de la cartografa y la transformacin
generacin cin. En la primera fase, dada
correspondencias entre dos esquemas, una
funcin de transformacin, tales como una
consulta o definicin de la vista sobre el
esquema de origen se genera que "rellenar" el
esquema de destino.

lado, los resultados se ven limitados por los


objetos en los DBMS locales, mientras que el
GCS definicin puede ser ms rico (Figura 4.2
b). Por lo tanto, en los sistemas de LAV, puede
ser necesario para hacer frente a las
respuestas incompletas. Una combinacin de
estos dos enfoques tiene tambin
ha propuesto como global-local-as-view (GLAV)
[Friedman et al., 1999], donde la relacin entre
el GCS y LCS se especifica utilizando tanto LAV
y el GAV sistemas locales slo pueden estar
dispuestos a aportar una parte de sus datos a
varias bases de la[Sheth y Larson, 1990].

El proceso de generacin de esquemas consta


de los siguientes pasos:
1. Esquema de juego para determinar las
correspondencias sintcticas y semnticas
entre los elementos de LCS traducidos o entre
los elementos y LCS individuales los elementos
de GCS predefinidos (seccin 4.2).
2. Integracin de los elementos del esquema
conceptual comn en un mundial (Mediado)
esquema si uno no ha sido definida (Seccin
4.3).

En la segunda fase, un eje-cutable cdigo se


genera correspondiente a esta funcin de
transformacin que lo hara en realidad
generar una base de datos destino coherente
con estas limitaciones. En algunos casos, las
restricciones se incluyen de forma implcita en
las correspondencias, eliminando la necesidad
para la primera fase.

4.2 Coincidencia de esquema


Coincidente esquema determina qu conceptos
de un esquema coinciden con los de otro.
Como se discuti anteriormente, si el GCS ya
se ha definido, a continuacin, uno de estos
esquemas es tpicamente el GCS, y la tarea es
para que coincida con cada uno de LCS a la
GCS. De otra manera, se realiza la casacin en
dos LCS. Los partidos que se determinan en
esta fase son entonces se utiliza en la

cartografa de esquema para producir un


conjunto de asignaciones dirigidas, que,
cuando se aplicada al esquema de origen, sera
mapear sus conceptos para el esquema de
destino.
Los partidos que se definen o encontradas
durante la coincidencia de esquema se
especifican como un conjunto de reglas, donde
cada regla (r) identifica una correspondencia
(c) entre dos elementos, un predicado (P) que
indica cuando la correspondencia puede llevar
a cabo, y un valor (s) la similitud entre los dos
elementos identificados en la correspondencia.

A pesar de estas dificultades, se han logrado


avances importantes en los ltimos aos en el
desarrollo
de
enfoques
algortmicos
al
problema de la concordancia. En esta seccin,
discutir un nmero de estos algoritmos y los
diversos enfoques.

Aparte de la heterogeneidad de esquema,


otras cuestiones que complican el juego
proceso son los siguientes:
esquema e informacin insuficientes ejemplo:
Coincidencia de algoritmos dependen
en la informacin que se puede extraer a partir
del esquema y la existente
Las instancias de datos. En algunos casos hay
una cierta ambigedad de los trminos debido
a la insuficiente informacin proporcionada
sobre estos artculos. Por ejemplo, usando
nombres cortos o abreviaturas ambiguas para
conceptos, como lo hemos hecho en nuestro
ejemplo, pueden conducir a la coincidencia
incorrecta.

Una serie de cuestiones afecta al algoritmo de


coincidencia
en
particular
[Rahm
y
Bernstein,2001]. Los ms importantes son los
siguientes:

Falta de disponibilidad de documentacin del


esquema: En la mayora de los casos, los
esquemas
de
bases
no
estn
bien
documentados
o
no
documentados
en
absoluto. Muy a menudo, el esquema
diseador ya no est disponible para guiar el
proceso. La falta de estos vitales fuentes de
informacin se suma a la dificultad de juego.

Esquema frente ejemplo a juego. Hasta


ahora, en este captulo, nos hemos centrado en
la integracin de esquemas; por lo tanto,
nuestra atencin ha sido, naturalmente, en
caso de coincidencia conceptos de un esquema
a los de otra. Un gran nmero de algoritmos se
han desarrollado que el trabajo sobre "objetos
de esquema." Hay otros, sin embargo, que se
han centrado en cambio en las instancias de
datos o una combinacin de esquema
informacin y datos instancias. El argumento
es que considerando instancias de datos puede
ayudar a aliviar algunos de los problemas
semnticos discutidos anteriormente.

La subjetividad del juego: Por ltimo,


tenemos que tener en cuenta (y admitir) que la
igualacin elementos de esquema pueden ser
altamente subjetiva; dos diseadores pueden
no estar de acuerdo sobre una solo mapeo
"correcta". Esto hace que la evaluacin de un
algoritmo dado de exactitud significativamente
difcil.

Elemento de nivel vs. estructura de los


niveles. Algunos algoritmos de correspondencia
operan en la indicacin elementos del esquema

indivi- mientras que otros tambin tengan en


cuenta las relaciones estructurales
entre estos elementos. El concepto bsico del
enfoque de nivel de elemento es que la mayor
parte de la semntica de esquema son
capturados por los nombres de los elementos.
Sin embargo, esto puede no encontrar
correlaciones complejas que abarcan mltiples
atributos. Partido algoritmos que tambin se
consideran estructura se basan en la creencia
de que, normalmente,las estructuras de los
esquemas de apareamiento tienden a ser
similares.
Coincidencia de cardinalidad. Algoritmos de
correspondencia exhiben diversas capacidades
en trminos de cardinalidad de asignaciones.
Los enfoques ms simples utilizan mapeo 1: 1,
lo cual significa que cada elemento en un
esquema se corresponde con exactamente un
elemento de el otro esquema. La mayora de
los algoritmos propuestos pertenecen a esta
categora, porque los problemas se simplifican
en gran medida en este caso. Por supuesto que
hay muchos los casos en que dicha presuncin
no es vlida. Por ejemplo, un atributo
nombrado
"Precio total" podra ser asignada a la suma de
los dos atributos en otro esquema llamado
"Subtotal" y "Impuestos". Tales asignaciones
requieren una compatibilidad ms complejo
algoritmos que tienen en cuenta: 1 M y N: M
mappings.
Estos criterios, y otros, se pueden utilizar para
llegar a una taxonoma de coincidencia
enfoques [Rahm y Bernstein, 2001]. De
acuerdo con esta taxonoma (que seguir en
este captulo con algunas modificaciones), el
primer nivel de separacin est entre
comparadores basadas en esquema frente a
comparadores basados en instancia (Figura
4.7).

Comparadores basada en esquemas pueden


ser clasificados como de nivel de elemento y la
estructura de los niveles, mientras que para los
enfoques basados en instancia, slo las

tcnicas
de
significativos.

nivel

de

elemento

son

En el nivel ms bajo, las tcnicas se


caracterizan como sea lingstica o constraintbasado. Es a este nivel que las diferencias
fundamentales entre los algoritmos de
correspondencia se exhiben y nos centramos
en estos algoritmos en el resto, discutiendo linenfoques de tics en la seccin 4.2.2, los
enfoques basados en restricciones en la
Seccin 4.2.3, y tcnicas en la Seccin 4.2.4aprendizaje basado. Rahm y Bernstein [2001]
se refieren a todos de stos matcher como
individuo se acerca, y sus combinaciones son
posibles gracias ael desarrollo de cualquiera de
comparadores
hbridos
o
comparadores
compuestos (Seccin 4.2.5).

2.1 Esquema de heterogeneidad


Esquema coincidente acuerdo con algoritmos
tanto
la
heterogeneidad
estructural
y
semntica heterogeneidad entre los esquemas
coincidentes. Se discuten estos en esta seccin
antes la presentacin de los diferentes
algoritmos de partido.
Conflictos estructurales se producen en cuatro
maneras posibles: como conflictos de tipos, la
dependencia conflictos, conflictos clave, o
conflictos de comportamiento [Batini et al.,
1986]. conflictos de tipos ocurrir cuando el
mismo objeto se representa por un atributo en
un esquema y por una entidad (relacin) en
otro. Conflictos de dependencia se producen
cuando la relacin diferente modos (por
ejemplo, uno-a-uno contra muchos-a-muchos)
se utilizan para representar la misma cosa en
diferentes esquemas. Conflictos de clave se
producen cuando diferentes claves candidatas
estn disponibles y diferentes claves primarias
son seleccionados en diferentes esquemas.
conflictos de comportamiento estn implcitos
en el mecanismo de modelado. Por ejemplo,
eliminar el ltimo elemento de una base de
datos puede provocar la eliminacin de la
entidad que contiene (es decir, la supresin de

la ltima empleado hace que la disolucin del


departamento)

4.2.2 Enfoques a juego lingsticas


Enfoques coincidentes lingsticos, como su
nombre lo indica, utilizan nombres de
elementos y otros informacin textual (por
ejemplo,
las
descripciones
textuales
/
anotaciones en definiciones de esquema) para
realizar bsquedas de coincidencias entre los
elementos. En muchos casos, se pueden
utilizar fuentes externas, tales como tesauros,
para ayudar en el proceso.
Tcnicas lingsticas pueden ser aplicados en
ambos enfoques basados en el esquema y los
basados en instancia. En el primer caso, las
similitudes se establecen entre esquema
elementos mientras que en el segundo, que se
especifican entre elementos del individuo

partido. porejemplo, RESP y responsabilidad


tienen valores relativamente bajos de similitud
de accin acuerdo con clculos en el Ejemplo
4.5. Sin embargo, si tienen el mismo tipo de
datos definicin, esto se puede utilizar para
aumentar su valor de similitud. Del mismo
modo, el tipo de datos comparacin puede
diferenciar entre elementos que tienen una alta
similitud lxica.
En los enfoques basados en la estructura, las
similitudes estructurales en los dos esquemas
pueden ser explotado en la determinacin de la
similitud de los elementos del esquema. Si dos
de esquema elementos son estructuralmente
similares, esto mejora nuestra confianza de
que de hecho representar el mismo concepto.
Por ejemplo, si dos elementos tienen nombres
muy diferentes
y no hemos sido capaces de establecer su
similitud a travs de elementos comparadores,
pero que tienen las mismas propiedades (por
ejemplo, los mismos atributos) que tienen los
mismos tipos de datos, entonces podemos
estar ms seguros de que estos dos elementos
pueden estar representando a la mismo
concepto.

4.2.4 juego basado en el aprendizaje

4.2.3 Enfoques a juego basado en


restricciones
Las definiciones de esquema casi siempre
contienen la informacin semntica que limitan
los valores en la base de datos. Estos son
normalmente informacin de tipo de datos,
rangos admisibles para los valores de datos,
restricciones de claves, etc. En el caso de las
tcnicas basadas en ejemplo, el gamas
existentes de los valores se pueden extraer, as
como algunos patrones que existen en los
datos de la instancia.
Considere los tipos de datos que capturan una
gran cantidad de informacin semntica. Esta
la informacin se puede utilizar para eliminar la
ambigedad de conceptos y tambin centrar el

Una tercera aproximacin alternativa que se ha


propuesto es el uso de la mquina de
aprendizaje las tcnicas para determinar
partidos de esquema. enfoques basados en el
aprendizaje a formular la problema como uno
de la clasificacin en la que se clasifican los
conceptos de diferentes esquemas en clases
de acuerdo a su similitud.
La similitud se determina mediante la
comprobacin las caractersticas de las
instancias de datos de las bases de datos que
corresponden a estos esquemas.
Cmo clasificar los conceptos en funcin de
sus caractersticas que se aprende mediante el
estudio de los datos instancias en un conjunto
de datos de entrenamiento.
El proceso es el siguiente (Figura 4.8) . Un
conjunto de entrenamiento ( se prepara) que

consiste
de
instancias
de
ejemplo
correspondencias entre los conceptos de dos
bases de datos Dyoy Dj

Por lo tanto, un "completo" a juego algoritmo o


metodologa general tiene que hacer uso de
ms de uno matcher individual.

Este conjunto de entrenamiento se puede


generar despus de la identificacin manual
del esquema correspondencias entre dos bases
de datos, seguido de extraccin de ejemplo de
entrenamiento instancias de datos [Doan et al.,
2003a] , o mediante la especificacin de una
expresin de consulta que convierte los datos
de una base de datos a otro [Berlin y Motro,
2001] . el aprendiz utiliza estos datos de
entrenamiento
para
adquirir
informacin
probabilstica sobre las caractersticas de los
conjuntos de datos. El clasificador, cuando se
les da otras dos instancias de base de datos
( Dky Dl),

Hay dos posibles formas en que se pueden


combinar comparadores [Rahm y Bernhard
Stein, 2001] :. hbridos y compuestos hbridos
algoritmos
se
combinan
mltiples
comparadores el plazo de un algoritmo. En
otras palabras, los elementos de dos esquemas
se pueden comparar utilizando una serie de
comparadores de elementos (por ejemplo,
cadena de bsqueda, as como el tipo de datos
de juego) y / o comparadores estructurales
dentro de un algoritmo para determinar su
general semejanza.

a continuacin, utiliza este conocimiento para


ir a travs de las instancias de datos en Dky Dl
y hacer predicciones acerca de la clasificacin
de los elementos de Dky Dl.
Este enfoque general se aplica a todo el
esquema basado en el aprendizaje propuesto
enfoques coincidentes. En lo que difieren es el
tipo de estudiante que utilizan y cmo que
ajustan el comportamiento de este estudiante
para la coincidencia de esquema. Algunos han
usado neuronal redes (por ejemplo, SEMINT [Li
y Clifton, 2000; Li et al., 2000] ).

4.4 Asignacin de esquema


Una vez que se define un GCS (o esquema
mediada), es necesario identificar cmo el los
datos de cada una de las bases de datos
locales (fuente) se pueden asignar a GCS
tiempo (objetivo) preservar la coherencia
semntica (como se define tanto por el origen
y el destino).
A pesar de coincidencia de esquema ha
identificado las correspondencias entre el LCS y
la
GCS,
puede
no
haber
identificado
explcitamente cmo obtener la base de datos
global de los locales. Esto es lo que se trata de
asignacin de esquema.
En el caso de los almacenes de datos, las
asignaciones de esquema se utilizan para
extraer datos de forma explcita de las fuentes,
y traducirlos al esquema del almacn de datos
para poblarlo.

4.2.5 Enfoques de casacin combinada


Las tcnicas de correspondencia individuales
que hemos considerado hasta ahora tienen su
fuerte puntos y sus debilidades. Cada uno
puede ser ms adecuado para hacer coincidir
determinados casos.

En el caso de los sistemas de integracin de


datos, estas asignaciones se utilizan en el
procesamiento de consultas fase tanto por el
procesador de consultas y las envolturas
(vase el captulo 9) .
Hay dos cuestiones relacionadas con la
asignacin de esquema que vamos a estudiar:
mapeo creacin y mantenimiento de la
cartografa . Creacin Mapping es el proceso de
crear consultas explcitas que se asignan los
datos de una base de datos local a los datos

globales. Cartografa el mantenimiento es la


deteccin y correccin de las inconsistencias
de mapeo resultante de la evolucin del
esquema. esquemas de origen pueden sufrir
cambios estructurales o semnticas que las
asociaciones del Invalidate. mantenimiento
Mapping se refiere a la deteccin de
asignaciones rotos y el (automtica) de
reescritura de asignaciones de tal manera que
semntica compatibles con el nuevo esquema
y equivalencia semntica con la asignacin
actual se consiguen.

4.4.2.1 Deteccin de asignaciones no


vlidas
En general, la deteccin de las asignaciones no
vlidas como resultado del cambio de esquema
puede EI-Ther suceda de forma proactiva o
reactiva. En entornos de deteccin proactiva,
esquema asignaciones se realizarn las
pruebas de inconsistencias, tan pronto como
los cambios de esquema se realizan por una
usuario.
El supuesto (o requisito) es que el sistema de
mantenimiento de mapeo es completamente
consciente de cualquier y todos los cambios de
esquema, tan pronto como se hacen. Los
Sistema de Toms [Velegrakis et al., 2004] , por
ejemplo, espera que los usuarios hacen de
esquema cambios a travs de sus propios
editores de esquema, por lo que el sistema
cuenta inmediatamente de cualquier cambio
de esquema. Una vez que se han detectado
cambios en el esquema, las asignaciones no
vlidas puede ser detectada por haciendo una
traduccin semntica de las asignaciones
existentes utilizando el las relaciones lgicas
del esquema actualizado.
En entornos de deteccin de reactivos, el
sistema de mantenimiento de mapeo no es
consciente de cundo y qu esquema se
realizan
cambios.
Para
detectar
las
asignaciones de esquema no vlido en este
ajuste, las asignaciones se ponen a prueba a
intervalos regulares por las consultas que se
realiza contra la fuentes de datos y la
traduccin de los datos resultantes utilizando
las
asignaciones
existentes.
Invlido
asignaciones se determinan en base a los
resultados de estas pruebas de mapeo.

4.5 Limpieza de datos


Los errores en las bases de datos de origen
siempre pueden ocurrir, que requieren de
limpieza con el fin de correctamente responder
a las consultas de los usuarios. limpieza de
datos es un problema que se plantea en ambos
almacenes de datos y sistemas de integracin
de datos, pero en diferentes contextos. En los
almacenes de datos donde los datos son en
realidad extrados de las bases de datos
operativas locales y materializados como una
base de datos global, la limpieza se lleva a
cabo como se crea la base de datos global. En
el caso de los sistemas de integracin de
datos, limpieza de datos es un proceso que
necesita ser realizada durante el proceso de
consulta cuando los datos se devuelven desde
las bases de datos fuente.
Los errores que estn sujetos a la limpieza de
datos generalmente se pueden dividir en ya
sea a nivel de esquema o preocupaciones a
nivel de instancia [Rahm y Do, 2000] .
Esquema de nivel problemas pueden surgir en
cada individuo LCS debido a violacines de
explcitos e implcitos restricciones. Por
ejemplo, los valores de atributos pueden estar
fuera del rango de su dominios (por ejemplo,
mes 14 o valor de salarios negativos), los
valores de atributo pueden violar dependencias
implcitas (por ejemplo, el valor del atributo
edad pueden no corresponderse con el valor
que se calcula como la diferencia entre la fecha
actual y la fecha de nacimiento), singularidad
de los valores de atributo no puede llevar a
cabo, y las restricciones de integridad
referencial puede siendo violados.

Por otra parte, en el ambiente que estamos


considerando
en
este
captulo,
las
heterogeneidades de nivel de esquema (tanto
estructurales y semnticas) entre el LCS que
hemos comentado anteriormente, pueden ser
considerados problemas que necesitan ser
resueltos. En el nivel de esquema, est claro
que los problemas deben ser identificados en el

partido de esquema escenario y fijo durante la


integracin del esquema.

Conclusin
En este captulo discutimos el proceso de
diseo de base de datos de abajo hacia arriba,
que hemos denominado integracin de base de
datos. Este es el proceso de crear un GCS (o un
esquema mediada) y determinar cmo cada
LCS asigna a la misma. Una separacin
fundamental es entre almacenes de datos en el
que se crea una instancia de GCS y se
materializ, y los datos de integracin sistemas

en los que el GCS es meramente una vista


virtual.
Aunque el tema de la integracin de base de
datos se ha estudiado ampliamente para una
mucho tiempo, casi todo el trabajo se ha
fragmentado. Los proyectos individuales se
centran en coincidencia de esquema o
depuracin de los datos, o asignacin de
esquema.
Hay
una
grave
falta
de
investigaciones que consideran la metodologa
de extremo a extremo para la integracin de
bases de datos. La falta de una metodologa se
hace ms serio por el hecho de que cada una
de estas actividades de investigacin trabajar
en diferentes supuestos relacionados con los
modelos de datos, tipos de heterogeneidades y
por lo
en. Una notable excepcin es el trabajo de
Bernstein y Melnik [2007] , que ofrece los
comienzos de una metodologa integral "de
extremo a extremo". Esta es probablemente la
ms tema importante que requiere atencin.

Vous aimerez peut-être aussi