La integración de datos implica combinar datos que residen en diferentes fuentes y proporcionar a los usuarios una vista unificada de ellos. [1] Este proceso adquiere importancia en una variedad de situaciones, que incluyen dominios tanto comerciales (como cuando dos empresas similares necesitan fusionar sus bases de datos ) como científicos (combinando resultados de investigación de diferentes repositorios bioinformáticos , por ejemplo). La integración de datos aparece con una frecuencia cada vez mayor a medida que explota el volumen, la complejidad (es decir, big data ) y la necesidad de compartir datos existentes . [2] Se ha convertido en el foco de un extenso trabajo teórico y numerosos problemas abiertos siguen sin resolverse. La integración de datos fomenta la colaboración entre usuarios internos y externos. Los datos que se integran deben recibirse de un sistema de base de datos heterogéneo y transformarse en un único almacén de datos coherente que proporcione datos sincrónicos a través de una red de archivos para los clientes. [3] Un uso común de la integración de datos es en la minería de datos cuando se analiza y extrae información de bases de datos existentes que puede ser útil para la información empresarial . [4]
Los problemas con la combinación de fuentes de datos heterogéneas , a menudo denominados silos de información , bajo una única interfaz de consulta, existen desde hace algún tiempo. A principios de la década de 1980, los informáticos comenzaron a diseñar sistemas para la interoperabilidad de bases de datos heterogéneas. [5] El primer sistema de integración de datos impulsado por metadatos estructurados fue diseñado en la Universidad de Minnesota en 1991, para la Serie Integrada de Microdatos de Uso Público (IPUMS) . IPUMS utilizó un enfoque de almacenamiento de datos , que extrae, transforma y carga datos de fuentes heterogéneas en un esquema de vista único para que los datos de diferentes fuentes se vuelvan compatibles. [6] Al hacer interoperables miles de bases de datos de población, IPUMS demostró la viabilidad de la integración de datos a gran escala. El enfoque del almacén de datos ofrece una arquitectura estrechamente acoplada porque los datos ya están físicamente conciliados en un único repositorio consultable, por lo que normalmente lleva poco tiempo resolver las consultas. [7]
El enfoque del almacén de datos es menos factible para conjuntos de datos que se actualizan con frecuencia, lo que requiere que el proceso de extracción, transformación y carga (ETL) se vuelva a ejecutar continuamente para su sincronización. También surgen dificultades en la construcción de almacenes de datos cuando sólo se tiene una interfaz de consulta para resumir las fuentes de datos y no se tiene acceso a los datos completos. Este problema surge con frecuencia al integrar varios servicios de consulta comerciales, como aplicaciones web de viajes o anuncios clasificados.
A partir de 2009, [actualizar]la tendencia en la integración de datos favoreció el acoplamiento flexible de los datos [8] y proporcionó una interfaz de consulta unificada para acceder a datos en tiempo real a través de un esquema mediado (ver Figura 2), que permite recuperar información directamente de las bases de datos originales. Esto es consistente con el enfoque SOA popular en esa época. Este enfoque se basa en asignaciones entre el esquema mediado y el esquema de las fuentes originales, y en traducir una consulta en consultas descompuestas para que coincida con el esquema de las bases de datos originales. Dichos mapeos se pueden especificar de dos maneras: como un mapeo de entidades en el esquema mediado a entidades en las fuentes originales (el enfoque "Global-as-View" [9] (GAV)), o como un mapeo de entidades en el fuentes originales al esquema mediado (el enfoque "Local-as-View" [10] (LAV)). El último enfoque requiere inferencias más sofisticadas para resolver una consulta en el esquema mediado, pero facilita agregar nuevas fuentes de datos a un esquema mediado (estable).
A partir de 2010, [actualizar]parte del trabajo en la investigación de la integración de datos se refiere al problema de la integración semántica . Este problema no aborda la estructuración de la arquitectura de la integración, sino cómo resolver conflictos semánticos entre fuentes de datos heterogéneas. Por ejemplo, si dos empresas fusionan sus bases de datos, ciertos conceptos y definiciones en sus respectivos esquemas, como "ganancias", inevitablemente tendrán significados diferentes. En una base de datos puede significar ganancias en dólares (un número de punto flotante), mientras que en la otra puede representar el número de ventas (un número entero). Una estrategia común para la resolución de tales problemas implica el uso de ontologías que definen explícitamente términos de esquema y, por lo tanto, ayudan a resolver conflictos semánticos. Este enfoque representa la integración de datos basada en ontologías . Por otro lado, el problema de combinar resultados de investigación de diferentes repositorios bioinformáticos requiere una evaluación comparativa de las similitudes, calculadas a partir de diferentes fuentes de datos, según un único criterio, como el valor predictivo positivo. Esto permite que las fuentes de datos sean directamente comparables y puedan integrarse incluso cuando las naturalezas de los experimentos sean distintas. [11]
A partir de 2011, [actualizar]se determinó que los métodos actuales de modelado de datos estaban impartiendo aislamiento de datos en cada arquitectura de datos en forma de islas de datos dispares y silos de información. Este aislamiento de datos es un artefacto involuntario de la metodología de modelado de datos que resulta en el desarrollo de modelos de datos dispares. Los modelos de datos dispares, cuando se instancian como bases de datos, forman bases de datos dispares. Se han desarrollado metodologías mejoradas de modelos de datos para eliminar el artefacto de aislamiento de datos y promover el desarrollo de modelos de datos integrados. [12] Un método mejorado de modelado de datos reformula los modelos de datos aumentándolos con metadatos estructurales en forma de entidades de datos estandarizadas. Como resultado de la refundición de múltiples modelos de datos, el conjunto de modelos de datos refundidos ahora compartirá una o más relaciones comunes que relacionan los metadatos estructurales que ahora son comunes a estos modelos de datos. Las relaciones de similitud son un tipo de relaciones entre entidades de igual a igual que relacionan las entidades de datos estandarizadas de múltiples modelos de datos. Múltiples modelos de datos que contienen la misma entidad de datos estándar pueden participar en la misma relación de similitud. Cuando los modelos de datos integrados se instancian como bases de datos y se completan adecuadamente a partir de un conjunto común de datos maestros, estas bases de datos se integran.
Desde 2011, los enfoques de centros de datos han sido de mayor interés que los almacenes de datos empresariales totalmente estructurados (normalmente relacionales). Desde 2013, los enfoques de lagos de datos han alcanzado el nivel de centros de datos. (Consulte la popularidad de los tres términos de búsqueda en Google Trends. [13] ) Estos enfoques combinan datos no estructurados o variados en una ubicación, pero no necesariamente requieren un esquema relacional maestro (a menudo complejo) para estructurar y definir todos los datos en el Hub.
La integración de datos juega un papel importante en los negocios con respecto a la recopilación de datos utilizados para estudiar el mercado. Convertir los datos sin procesar obtenidos de los consumidores en datos coherentes es algo que las empresas intentan hacer al considerar qué pasos deben dar a continuación. [14] Las organizaciones utilizan con mayor frecuencia la minería de datos para recopilar información y patrones de sus bases de datos, y este proceso les ayuda a desarrollar nuevas estrategias comerciales para aumentar el rendimiento empresarial y realizar análisis económicos de manera más eficiente. Recopilar la gran cantidad de datos que recopilan para almacenarlos en su sistema es una forma de integración de datos adaptada a la inteligencia empresarial para mejorar sus posibilidades de éxito. [15]
Considere una aplicación web donde un usuario puede consultar una variedad de información sobre ciudades (como estadísticas de criminalidad, clima, hoteles, demografía, etc.). Tradicionalmente, la información debe almacenarse en una única base de datos con un único esquema. Pero a cualquier empresa le resultaría algo difícil y costoso recopilar información de esta amplitud. Incluso si existieran los recursos para recopilar los datos, probablemente se duplicarían los datos de las bases de datos sobre delitos, los sitios web meteorológicos y los datos del censo existentes.
Una solución de integración de datos puede abordar este problema considerando estos recursos externos como vistas materializadas sobre un esquema mediado virtual , lo que da como resultado una "integración de datos virtuales". Esto significa que los desarrolladores de aplicaciones construyen un esquema virtual (el esquema mediado ) para modelar mejor los tipos de respuestas que desean sus usuarios. A continuación, diseñan "envoltorios" o adaptadores para cada fuente de datos, como la base de datos sobre delitos y el sitio web meteorológico. Estos adaptadores simplemente transforman los resultados de la consulta local (aquellos devueltos por los respectivos sitios web o bases de datos) en un formulario fácilmente procesado para la solución de integración de datos (consulte la figura 2). Cuando un usuario de la aplicación consulta el esquema mediado, la solución de integración de datos transforma esta consulta en consultas apropiadas sobre las respectivas fuentes de datos. Finalmente, la base de datos virtual combina los resultados de estas consultas en la respuesta a la consulta del usuario.
Esta solución ofrece la conveniencia de agregar nuevas fuentes simplemente construyendo un adaptador o una hoja de software de aplicación para ellas. Contrasta con los sistemas ETL o con una solución de base de datos única, que requieren la integración manual de un conjunto de datos completamente nuevo en el sistema. Las soluciones ETL virtuales aprovechan el esquema mediado virtual para implementar la armonización de datos; mediante el cual los datos se copian desde la fuente "maestra" designada a los destinos definidos, campo por campo. La virtualización de datos avanzada también se basa en el concepto de modelado orientado a objetos para construir un esquema mediado virtual o un repositorio de metadatos virtual, utilizando una arquitectura radial .
Cada fuente de datos es dispar y, como tal, no está diseñada para admitir uniones confiables entre fuentes de datos. Por lo tanto, la virtualización de datos, así como la federación de datos, dependen de datos comunes accidentales para respaldar la combinación de datos e información de conjuntos de datos dispares. Debido a la falta de valores comunes de los datos entre las fuentes de datos, el conjunto de resultados puede ser inexacto, incompleto e imposible de validar.
Una solución es refundir bases de datos dispares para integrarlas sin necesidad de ETL . Las bases de datos refundidas admiten restricciones de elementos comunes donde se puede imponer la integridad referencial entre bases de datos. Las bases de datos refundidas proporcionan rutas de acceso a datos diseñadas con valores de datos comunes entre las bases de datos.
La teoría de la integración de datos [1] forma un subconjunto de la teoría de bases de datos y formaliza los conceptos subyacentes del problema en lógica de primer orden . La aplicación de las teorías da indicaciones sobre la viabilidad y dificultad de la integración de datos. Si bien sus definiciones pueden parecer abstractas, tienen suficiente generalidad para dar cabida a todo tipo de sistemas de integración, [16] incluidos aquellos que incluyen bases de datos XML/relacionales anidadas [17] y aquellos que tratan las bases de datos como programas. [18] Las conexiones a sistemas de bases de datos particulares como Oracle o DB2 son proporcionadas por tecnologías de nivel de implementación como JDBC y no se estudian a nivel teórico.
Los sistemas de integración de datos se definen formalmente como una tupla donde está el esquema global (o mediado), el conjunto heterogéneo de esquemas de origen y el mapeo que mapea las consultas entre el esquema de origen y el global. Ambos y se expresan en idiomas sobre alfabetos compuestos de símbolos para cada una de sus respectivas relaciones . El mapeo consta de afirmaciones entre consultas terminadas y consultas terminadas . Cuando los usuarios plantean consultas sobre el sistema de integración de datos, plantean consultas y el mapeo afirma conexiones entre los elementos del esquema global y los esquemas de origen.
Una base de datos sobre un esquema se define como un conjunto de conjuntos, uno para cada relación (en una base de datos relacional). La base de datos correspondiente al esquema fuente comprendería el conjunto de conjuntos de tuplas para cada una de las fuentes de datos heterogéneas y se denomina base de datos fuente . Tenga en cuenta que esta base de datos de origen único puede representar en realidad una colección de bases de datos desconectadas. La base de datos correspondiente al esquema mediado virtual se denomina base de datos global . La base de datos global debe satisfacer el mapeo con respecto a la base de datos de origen. La legalidad de este mapeo depende de la naturaleza de la correspondencia entre y . Existen dos formas populares de modelar esta correspondencia: Global como Vista o GAV y Local como Vista o LAV.
Los sistemas GAV modelan la base de datos global como un conjunto de vistas sobre . En este caso se asocia a cada elemento de una consulta sobre . El procesamiento de consultas se convierte en una operación sencilla debido a las asociaciones bien definidas entre y . La carga de la complejidad recae en la implementación del código mediador que indica al sistema de integración de datos exactamente cómo recuperar elementos de las bases de datos de origen. Si se incorporan nuevas fuentes al sistema, puede ser necesario un esfuerzo considerable para actualizar el mediador, por lo que el enfoque GAV parece preferible cuando parece poco probable que las fuentes cambien.
En un enfoque GAV para el sistema de integración de datos de ejemplo anterior, el diseñador del sistema primero desarrollaría mediadores para cada una de las fuentes de información de la ciudad y luego diseñaría el esquema global en torno a estos mediadores. Por ejemplo, considere si una de las fuentes proporcionó un sitio web meteorológico. El diseñador probablemente luego agregaría un elemento correspondiente al clima al esquema global. Luego, la mayor parte del esfuerzo se concentra en escribir el código mediador adecuado que transformará los predicados sobre el tiempo en una consulta sobre el sitio web del tiempo. Este esfuerzo puede volverse complejo si alguna otra fuente también se relaciona con el clima, porque es posible que el diseñador necesite escribir código para combinar adecuadamente los resultados de las dos fuentes.
Por otro lado, en LAV, la base de datos de origen se modela como un conjunto de vistas sobre . En este caso se asocia a cada elemento de una consulta sobre . Aquí las asociaciones exactas entre y ya no están bien definidas. Como se ilustra en la siguiente sección, la carga de determinar cómo recuperar elementos de las fuentes recae en el procesador de consultas. El beneficio de un modelado LAV es que se pueden agregar nuevas fuentes con mucho menos trabajo que en un sistema GAV, por lo que se debe favorecer el enfoque LAV en los casos en que el esquema mediado sea menos estable o tenga menos probabilidades de cambiar. [1]
En un enfoque LAV para el sistema de integración de datos de ejemplo anterior, el diseñador del sistema diseña primero el esquema global y luego simplemente ingresa los esquemas de las respectivas fuentes de información de la ciudad. Considere nuevamente si una de las fuentes sirve a un sitio web meteorológico. El diseñador agregaría los elementos correspondientes al clima al esquema global solo si ninguno existiera ya. Luego, los programadores escriben un adaptador o contenedor para el sitio web y agregan una descripción del esquema de los resultados del sitio web a los esquemas fuente. La complejidad de agregar la nueva fuente pasa del diseñador al procesador de consultas.
La teoría del procesamiento de consultas en sistemas de integración de datos se expresa comúnmente mediante consultas conjuntivas y Datalog , un lenguaje de programación de lógica puramente declarativa. [20] Uno puede pensar vagamente en una consulta conjuntiva como una función lógica aplicada a las relaciones de una base de datos como " dónde ". Si una tupla o un conjunto de tuplas se sustituye en la regla y la satisface (la hace verdadera), entonces consideramos esa tupla como parte del conjunto de respuestas de la consulta. Si bien los lenguajes formales como Datalog expresan estas consultas de manera concisa y sin ambigüedades, las consultas SQL comunes también cuentan como consultas conjuntivas.
En términos de integración de datos, la "contención de consultas" representa una propiedad importante de las consultas conjuntivas. Una consulta contiene otra consulta (indicada como ) si los resultados de la aplicación son un subconjunto de los resultados de la aplicación de cualquier base de datos. Se dice que las dos consultas son equivalentes si los conjuntos resultantes son iguales para cualquier base de datos. Esto es importante porque tanto en los sistemas GAV como en los LAV, un usuario plantea consultas conjuntivas sobre un esquema virtual representado por un conjunto de vistas , o consultas conjuntivas "materializadas". La integración busca reescribir las consultas representadas por las vistas para que sus resultados sean equivalentes o estén contenidos al máximo en la consulta de nuestro usuario. Esto corresponde al problema de responder consultas mediante vistas (AQUV). [21]
En los sistemas GAV, un diseñador de sistemas escribe un código mediador para definir la reescritura de consultas. Cada elemento de la consulta del usuario corresponde a una regla de sustitución del mismo modo que cada elemento del esquema global corresponde a una consulta sobre la fuente. El procesamiento de consultas simplemente expande los subobjetivos de la consulta del usuario de acuerdo con la regla especificada en el mediador y, por lo tanto, es probable que la consulta resultante sea equivalente. Si bien el diseñador hace la mayor parte del trabajo de antemano, algunos sistemas GAV como Tsimmis implican simplificar el proceso de descripción del mediador.
En los sistemas LAV, las consultas se someten a un proceso de reescritura más radical porque no existe ningún mediador para alinear la consulta del usuario con una estrategia de expansión simple. El sistema de integración debe ejecutar una búsqueda en el espacio de posibles consultas para encontrar la mejor reescritura. La reescritura resultante puede no ser una consulta equivalente pero contenida al máximo, y las tuplas resultantes pueden estar incompletas. A partir de 2011, [actualizar]el algoritmo GQR [22] es el algoritmo líder de reescritura de consultas para sistemas de integración de datos LAV.
En general, la complejidad de la reescritura de consultas es NP-completa . [21] Si el espacio de reescritura es relativamente pequeño, esto no plantea un problema, incluso para sistemas de integración con cientos de fuentes.
Las cuestiones científicas de gran escala, como la evidencia del mundo real , el calentamiento global , la propagación de especies invasoras y el agotamiento de los recursos , requieren cada vez más la recopilación de conjuntos de datos dispares para el metanálisis . Este tipo de integración de datos es especialmente desafiante para los datos ecológicos y ambientales porque no se acuerdan estándares de metadatos y hay muchos tipos de datos diferentes producidos en estos campos. Las iniciativas de la National Science Foundation, como Datanet, tienen como objetivo facilitar la integración de datos para los científicos proporcionando ciberinfraestructura y estableciendo estándares. Las cinco iniciativas Datanet financiadas son DataONE , [23] dirigida por William Michener en la Universidad de Nuevo México ; The Data Conservancy, [24] dirigido por Sayeed Choudhury de la Universidad Johns Hopkins ; SEAD: Medio ambiente sostenible a través de datos procesables, [25] dirigido por Margaret Hedstrom de la Universidad de Michigan ; el Consorcio de la Federación DataNet, [26] dirigido por Reagan Moore de la Universidad de Carolina del Norte ; y Terra Populus , [27] dirigido por Steven Ruggles de la Universidad de Minnesota . La Research Data Alliance , [28] ha explorado más recientemente la creación de marcos globales de integración de datos. El proyecto OpenPHACTS , financiado a través de la Iniciativa de Medicamentos Innovadores de la Unión Europea , creó una plataforma de descubrimiento de fármacos vinculando conjuntos de datos de proveedores como el Instituto Europeo de Bioinformática , la Real Sociedad de Química , UniProt , WikiPathways y DrugBank .
{{cite news}}: Mantenimiento CS1: varios nombres: lista de autores ( enlace )