7.1 Introducción a los sistemas de integración de datos distribuidos

Transcripción

1 7.1 Introducción a los sistemas de integración de datos distribuidos

2 Integración de Datos Distribuidos El problema de la integración de datos distribuidos consiste en integrar datos de fuentes distribuidas, heterogéneas y posiblemente autónomas. Heterogéneas Sistema De Integración Distribuidas Autónomas Poco estructuradas

3 Ámbito (1) Mundo actual -> Grandes volúmenes de información accesibles: Explosión de informatización y herramientas de creación y compartición de contenidos Internet: WWW es la norma de facto para compartición de información Heterogeneidad interna: 2000 principales empresas USA tienen más de 15 plataformas diferentes y de 8 arquitecturas de almacenamiento con esquemas y convenciones semánticas incompatibles (Gartner Group). Heterogeneidad externa: Internet tiene multitud de fuentes de información útiles. Información proveniente de otras organizaciones (socios, proveedores, clientes, )

4 Ámbito (2) Heterogeneidad a múltiples niveles: Nivel de estructuración: Información estructurada (bases de datos), Información no estructurada y semi-estructurada (documentos, sitios web). Información en formatos legibles para humanos pero no para máquinas. Ejemplo: HTML. Modelo de datos (e.g. Modelo relacional vs Modelo jerárquico). Plataforma software (e.g. MySQL vs Postgress). Convenciones de sintaxis ( Calle Alcalá, nº 32, C\Alcalá, 32 ). Convenciones semánticas. Taxonomías: Una fuente clasifica ofertas de empleo de informática y telecomunicaciones en categoría Informática y Teleco. Otra las separa en dos categorías: Informática, Teleco. Otra agrupa todas las de ingeniería en Ingenieros. Otra tiene una categoría Telemática que tiene ofertas para ambos.

5 Ámbito (y 3) Heterogeneidad a múltiples niveles: Diferencias de granularidad. Una fuente tiene una tabla con un campo Heterogeneidad de esquema. Ejemplo: representación de información de criminales y tipos de delito: Una BD tiene una tabla CRIMINALES y una tabla DELITOS con una relación M:N. Etc. Otra BD tiene una única tabla CRIMINALES que indica el tipo o tipos de delito. Otra BD tiene en una tabla distinta a los criminales de cada tipo de delito: tablas ASESINOS, LADRONES, ESTAFADORES, etc.

6 Información No Estructurada Sólo puede ser consultada mediante consultas imprecisas: Granularidad de documento (estructura de presentación, no de contenido) Búsquedas por palabra clave, combinadas mediante operadores booleanos. En información En metainformación Búsquedas de patrones.

7 Información Estructurada (1) Datos presentan un esquema rígido: Define tipos de datos para los elementos atómicos Define su organización interna (como se combinan los elementos) Define las restricciones a aplicar Definido por separado de los datos Ejemplos típicos: Bases de Datos Modelo relacional, orientado a objetos, jerárquico, etc.

8 Información Estructurada (y 2) Admiten consultas precisas: Granularidad de elemento de información Pueden manejar la información del esquema para la construcción de condiciones Ejemplos típicos: los lenguajes de consulta sobre bases de datos: SQL, OQL, etc.

9 Información Semi-estructurada (1) Presentan algún tipo de esquema, pero: No es conocido de antemano. Es relativamente grande y puede cambiar con frecuencia y sin previo aviso. Se admiten ciertas violaciones del esquema. No hay tipado fuerte. Además puede ocurrir: El modo de acceso/almacenamiento no es consciente del esquema. Formato de representación no contiene información sobre el esquema o la semántica de sus contenidos (e.g. HTML). Puede haber partes irrelevantes y/o cambiantes Las capacidades de consulta pueden ser limitadas

10 Información Semi-estructurada (2)

11 Información Semi-estructurada (3) Página html (Publicidad, logos...) Lista de productos obtenidos (libros) Diferencias en el conjunto de datos para un item determinado

12 Información Semi-estructurada (y 4) Ejemplos típicos: Documentos XML (esquema no rígido) Resultado de una consulta en una fuente web. Cualquier lista en formato imprimible (Word, PDF, etc.) Catálogos de productos Listas de personal Etc. Lo ideal sería poder tratar esta información de la manera más similar posible a como si fuese estructurada: Enfoques que aprenden la estructura de la información partiendo de algunos ejemplos. Enfoques basados en proporcionar normas para la etiquetación de estos contenidos (Web Semántica).

13 Clasificación Sistemas Integración de Datos Criterio 1: Materializados vs Virtuales Criterio 2: Tipo de información y tipo de consultas que tratan: Consultas imprecisas sobre información no estructurada (no los veremos): Motores de recuperación y clasificación automática de información. Materializado. Metabúsqueda. Virtual. Útiles en Gestión del conocimiento, portales, etc. Consultas precisas sobre información estructurada: Base de Datos Universal. Materializado. Data Warehouse (almacén de datos). Materializado. Bases de Datos Federadas. Virtual. Consultas precisas sobre información estructurada y semiestructurada: Sistemas EII: Enterprise Information Integration. Virtual

14 Sistemas Materializados Los datos de las fuentes se copian periódicamente de forma masiva al sistema de integración. Consultas eficientes: Datos son locales al sistema de integración. Datos no actualizados. La información se carga periódicamente. Es necesario construir un gran repositorio central: largo y costoso de construir y mantener No siempre es posible con fuentes autónomas: Organizaciones quieren mantener el control sobre cómo se consulta su información (e.g. Vendedores de contenidos online, socios B2B). No es factible proporcionar copias periódicas completas de la información de las fuentes.

15 Sistemas Virtuales (1) Los datos permanecen en las fuentes. Cuando se recibe una consulta sobre el sistema de integración: La consulta se reformula en una serie de subconsultas sobre las fuentes, El sistema ejecuta las subconsultas sobre las fuentes en tiempo real, recogiendo de cada fuente los datos precisos para contestar la consulta del usuario. Integra los sub-resultados obtenidos. Finalmente, devuelve el resultado al usuario.

16 Sistemas Virtuales (y 2) Datos actualizados. Se recogen los datos en tiempo real de las fuentes. El Sistema de Integración es ligero ya que no maneja por si mismo grandes cantidades de datos. Más adecuado con fuentes autónomas. Las fuentes mantienen el control sobre cómo se consulta su información. Se pueden aprovechar los interfaces de consulta ya existentes y no hay cargas masivas. Menos eficiente: Hay que transmitir los datos por la red desde las fuentes en el momento de la consulta. Pueden usarse sistemas de cache para materializar las fuentes no autónomas y que no precisemos actualizadas en tiempo real.

17 Base de Datos Universal Se construye un nuevo sistema integrando todos los datos. Las fuentes de información originales desaparecen. Lecturas y Escrituras se realizan sobre el sistema de integración. Ventaja: Eficiente Problemas: Hay que rehacer todas las aplicaciones Hay que volver a formar a los usuarios Requiere un caro y crítico servidor central No es válido para fuentes autónomas Intrusivo. Conclusión: inviable muchas veces. Cuando es viable, largo y costoso.

18 Data Warehouse (1) Los datos de las fuentes se copian periódicamente a un almacén central. Pueden copiarse todos los datos o sólo un subconjunto. Para disminuir la carga de las actualizaciones, las fuentes pueden enviar sólo los cambios producidos. Requiere dicho soporte por parte de las fuentes. Ventajas: No es necesario rehacer aplicaciones ni volver a formar a los usuarios Eficiente

19 Problemas: Datos no actualizados Data Warehouse (y 2) Puede no ser posible o muy ineficiente con fuentes autónomas Organizaciones quieren mantener el control sobre sus datos. No es factible hacer copias masivas periódicas. Sistema de integración pesado Contiene gran cantidad de datos. Conclusión: muy bueno para obtención de informes, tratamiento de históricos, análisis de tendencias, etc. Menos útil en otros ámbitos. En informes/análisis de tendencias, a menudo no es importante tiempo real, pero sí lo es mucho la eficiencia (a veces, los procesos son muy pesados).

20 Sistemas EII (1) EII: Enterprise Information Integration. Similares conceptualmente a las bases de datos federadas. Bases de datos federadas se limitan a fuentes que sean bases de datos. Pueden tratar otras fuentes que no sean BDs: Servicios Web, XML, aplicaciones populares Algunos pueden tratar fuentes semi-estructuradas casi como si fuesen estructuradas. A veces, incluso fuentes web no etiquetadas (sólo legibles para humanos ), mediante técnicas de aprendizaje. Datos permanecen en las fuentes y se define un esquema virtual de integración. Cuando el sistema recibe una consulta, la subdivide en consultas para los esquemas de las bases de datos origen. El sistema EII combina los resultados de las fuentes y devuelve la respuesta unificada de acuerdo al esquema global.

21 Sistemas EII (2): Ejemplo APLICACIÓN USUARIO R={TITULO,AUTOR,PRECIO,PUNTOS} DATOS R SELECT * FROM R WHERE TITULO= Moby Dick DATOS R=(DATOS A) (DATOS B) NIVEL LÓGICO NIVEL FÍSICO SELECT * FROM A WHERE TITULO= Moby Dick HTTP DATOS A DATOS B ENVOLTORIO1 ENVOLTORIO 2 SELECT * FROM B WHERE TITULO= Moby Dick HTTP HTML A={TITULO,AUTOR,PRECIO} HTML B={TITULO,AUTOR,PUNTOS}

22 Sistemas EII (3) En ocasiones, pueden permitir inserciones: En fuentes que implementen Two-Phase Commit. Problema de inserciones sobre vistas: algunas vistas pierden información, con lo cuál no es factible hacer inserciones sobre ellas. Pueden incluir funcionalidades de consulta imprecisa combinadas con las de consulta precisa. Ventajas: Datos en tiempo real. Válidos para fuentes autónomas. Sistema de integración ligero. Tratan fuentes semi-estructuradas. Inconveniente: Menos eficiente. Puede usar precargas para las fuentes que se desee. En realidad, contiene lógicamente al esquema Data Warehouse, aunque los paquetes software actuales no siempre proporcionen esta funcionalidad.

23 Sistemas EII (y 4) Tareas principales: Reformulación y ejecución de consultas. Traducir consulta general sobre el esquema global en una lista de subconsultas sobre las fuentes. Optimización de consultas. Tener en cuenta retardos de red, trabajar con poca información de costes de las fuentes, etc. Diversidad de formatos. Heterogeneidad de taxonomías, convenciones semánticas, esquema, etc. Mayor flexibilidad en manejo de esquema (datos semiestructurados). Mayor número de fuentes y más autónomas. Heterogeneidad en las capacidades de consulta de las fuentes (e.g. un formulario web). Acceso y recuperación de datos puede ser complejo (e.g. HTTP/HTML).

24 Arquitectura EII (1) APP1 APP2 APP3 APP4 SOAP JDBC ODBC XQUERY Web Services JDBC ODBC XQuery ACCESS INTERFACES SQL / XQuery / XPath Full Text Result Sets / XML EII SYSTEM Caché Metadata Repository Query Analyzer and Decomposer Plan Generator Optimizer Execution Engine Wrapper Creator Database Wrapper JDBC/ODBC Proprietary Wrappers Proprietary APIS and Protocols Web Services Wrapper SOAP Web Wrapper HTTP HTML Graphical Tool AI - Based Web Wrapper Generation JDBC/ODBC Propietary Interface Web Services http Local Databases and Data Warehouses Backoffice and Propietary Applications Partner s Applications External Websites

25 Envoltorios (capa física): Arquitectura EII (2) Proporcionan una visión de las relaciones de las fuentes (relaciones base) de acuerdo a un modelo común (p.e. Relacional con extensiones semi-estructuradas). Suelen tratar al menos: Bases de Datos. Fuentes XML. Web Services. Algunos incorporan mecanismos de generación automática de wrappers para fuentes web convencionales (no etiquetadas).

26 Capa Lógica: Arquitectura EII (3) Generador de planes de consulta: Descomposición de consulta global en subconsultas y determinación de las acciones de recombinación necesarias con los sub-resultados obtenidos. Debe tener en cuenta que las fuentes pueden tener capacidades de consulta limitadas. Optimizador: Escoge el plan de ejecución más óptimo en función del número de resultados esperado de cada fuente, los retardos de red, etc. Motor de ejecución Se encarga ejecutar el plan de consulta escogido: Ejecutar sub-consultas (en paralelo cuando sea posible). Combinar sub-resultados.

27 Capa de aplicación: Arquitectura EII (4) Sistema EII ofrece como interfaz un lenguaje para consultas precisas, que puede incluir ciertas peculiaridades para fuentes semi-estructuradas e incluso no estructuradas. Variantes de SQL. XQuery. Normalmente es posible acceder al sistema EII de la misma forma que si fuese una BD convencional: JDBC. ODBC. También es habitual que ofrezca algún tipo de interfaz Web Service. Notar que puede ser útil que un sistema EII sea fuente de otro.

28 Arquitectura EII (5) Idea análoga al EAI, pero con la integración de datos. Se crea una sola vez un wrapper para cada fuente Para los tipos de fuentes más comunes, el EII permitirá que el wrapper se cree sólo mediante configuración. Después, cada necesidad de combinación de datos se realiza de forma declarativa, sin programar: Se requerirá sólo definir una vista en el lenguaje del sistema EII (SQL, Xquery, ).

29 Arquitectura EII (6) Ventajas similares al EAI pero en el contexto de integración de datos: Crear un nuevo proceso de combinación de datos no implica programar El sistema se encarga de tareas complejas como la reformulación de consultas, su optimización o la interacción con las fuentes. La respuesta a cambios es mucho más rápida. No es necesario escribir cada vez código ad-hoc para acceder a cada fuente de datos.

30 Arquitectura EII (y 7) Todos los procesos de combinación de datos son gestionados de la misma forma y desde un único punto: Facilidad de administración y obtención de informes. Facilita la implantación de políticas globales: autenticación, seguridad, etc. Las herramientas traen ya implementados wrappers configurables, para los tipos principales de fuentes: Bases de datos. Servicios Web. Fuentes XML Aplicaciones típicas de fabricantes populares: ERPs, CRMs, etc. Algunas incorporan sistemas de aprendizaje semiautomático para tratar fuentes web sin etiquetar.