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 se vuelve significativo 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 de bioinformática , 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 al analizar y extraer información de bases de datos existentes que puede ser útil para la información comercial . [4]
Los problemas con la combinación de fuentes de datos heterogéneas a menudo se denominan silos de información , bajo una única interfaz de consulta, que existen desde hace algún tiempo. A principios de la década de 1980, los científicos 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 se diseñó 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 que miles de bases de datos de población sean interoperables, IPUMS demostró la viabilidad de la integración de datos a gran escala. El enfoque de almacenamiento de datos ofrece una arquitectura estrechamente acoplada porque los datos ya están físicamente reconciliados en un único repositorio consultable, por lo que generalmente lleva poco tiempo resolver las consultas. [7]
El enfoque de almacenamiento de datos es menos viable 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 la sincronización. También surgen dificultades en la construcción de almacenes de datos cuando solo se tiene una interfaz de consulta para las fuentes de datos resumidas 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 la provisión de una interfaz de consulta unificada para acceder a los datos en tiempo real a través de un esquema mediado (ver Figura 2), lo que permite recuperar información directamente de las bases de datos originales. Esto es coherente 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 la traducción de una consulta en consultas descompuestas para que coincidan con el esquema de las bases de datos originales. Dichas asignaciones se pueden especificar de dos maneras: como una asignación de entidades en el esquema mediado a entidades en las fuentes originales (el enfoque "Global-as-View" [9] (GAV)), o como una asignación de entidades en las 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 la adición de nuevas fuentes de datos a un esquema mediado (estable).
A partir de 2010, [actualizar]parte de los trabajos de investigación sobre integración de datos se centran en el 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 los 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 tienen 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 los términos del esquema y, por lo tanto, ayudan a resolver los conflictos semánticos. Este enfoque representa la integración de datos basada en ontologías . Por otro lado, el problema de combinar los resultados de investigación de diferentes repositorios de bioinformática requiere una evaluación comparativa de las similitudes, calculadas a partir de diferentes fuentes de datos, en un único criterio como el valor predictivo positivo. Esto permite que las fuentes de datos sean directamente comparables y se puedan integrar incluso cuando la naturaleza de los experimentos sea distinta. [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 no deseado de la metodología de modelado de datos que da como resultado 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 de modelos de datos mejorados para eliminar el artefacto de aislamiento de datos y promover el desarrollo de modelos de datos integrados. [12] Un método de modelado de datos mejorado reformula los modelos de datos al aumentarlos con metadatos estructurales en forma de entidades de datos estandarizadas. Como resultado de reformular múltiples modelos de datos, el conjunto de modelos de datos reformulados ahora compartirá una o más relaciones de puntos en común que relacionan los metadatos estructurales ahora comunes a estos modelos de datos. Las relaciones de puntos en común son un tipo de relaciones de entidad 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 puntos en común. 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, entonces estas bases de datos se integran.
Desde 2011, los enfoques de centros de datos han suscitado mayor interés que los almacenes de datos empresariales totalmente estructurados (normalmente relacionales). Desde 2013, los enfoques de lagos de datos han ascendido al 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 única ubicación, pero no requieren necesariamente un esquema relacional maestro (a menudo complejo) para estructurar y definir todos los datos en el centro.
La integración de datos juega un papel importante en las empresas en lo que respecta a la recopilación de datos que se utilizan para estudiar el mercado. Convertir los datos brutos recuperados de los consumidores en datos coherentes es algo que las empresas intentan hacer cuando consideran 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 las 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]
Consideremos una aplicación web en la que un usuario puede consultar una variedad de información sobre ciudades (como estadísticas de delincuencia, clima, hoteles, demografía, etc.). Tradicionalmente, la información debe almacenarse en una única base de datos con un único esquema. Pero cualquier empresa individual consideraría que recopilar información de esta amplitud sería algo difícil y costoso. Incluso si existieran los recursos para recopilar los datos, probablemente se duplicarían los datos en las bases de datos sobre delincuencia, 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 virtual". 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 (los que devuelven los respectivos sitios web o bases de datos) en un formato fácil de procesar 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 comodidad de agregar nuevas fuentes simplemente construyendo un adaptador o un blade 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 todo el nuevo conjunto de datos en el sistema. Las soluciones ETL virtuales aprovechan el esquema virtual mediado para implementar la armonización de datos, mediante la cual los datos se copian desde la fuente "maestra" designada a los destinos definidos, campo por campo. La virtualización avanzada de datos también se basa en el concepto de modelado orientado a objetos para construir un esquema virtual mediado o un repositorio de metadatos virtual, utilizando una arquitectura de tipo hub and spoke .
Cada fuente de datos es diferente 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 la similitud accidental de datos para admitir la combinación de datos e información de conjuntos de datos diferentes. Debido a la falta de similitud de valores de datos entre las fuentes de datos, el conjunto de retorno puede ser inexacto, incompleto e imposible de validar.
Una solución es reformular bases de datos dispares para integrarlas sin necesidad de ETL . Las bases de datos reformuladas admiten restricciones de puntos en común en las que se puede aplicar la integridad referencial entre bases de datos. Las bases de datos reformuladas proporcionan rutas de acceso a datos diseñadas con valores de datos comunes en todas 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 proporciona 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 relacionales/XML 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 es el esquema global (o mediado), es el conjunto heterogéneo de esquemas fuente y es la asignación que asigna consultas entre el esquema fuente y los esquemas globales. Ambos y se expresan en idiomas sobre alfabetos compuestos de símbolos para cada una de sus respectivas relaciones . La asignación consiste en afirmaciones entre consultas sobre y consultas sobre . Cuando los usuarios plantean consultas sobre el sistema de integración de datos, plantean consultas sobre y la asignación luego afirma conexiones entre los elementos en el esquema global y los esquemas fuente.
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 de origen comprendería el conjunto de conjuntos de tuplas para cada una de las fuentes de datos heterogéneas y se denomina base de datos de origen . Tenga en cuenta que esta única base de datos de origen 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 la asignación con respecto a la base de datos de origen. La legalidad de esta asignación 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 del 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 sirviera a un sitio web meteorológico. El diseñador probablemente agregaría entonces un elemento correspondiente para el clima al esquema global. Luego, la mayor parte del esfuerzo se concentra en escribir el código de mediador adecuado que transformará los predicados sobre el clima en una consulta sobre el sitio web meteorológico. Este esfuerzo puede volverse complejo si alguna otra fuente también se relaciona con el clima, porque el diseñador puede necesitar escribir código para combinar correctamente los resultados de las dos fuentes.
Por otra parte, 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 el enfoque LAV debería favorecerse en los casos en que el esquema mediado es menos estable o es probable que cambie. [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 fuentes de información de la ciudad respectiva. Considere nuevamente si una de las fuentes sirve a un sitio web meteorológico. El diseñador agregaría los elementos correspondientes para el clima al esquema global solo si no existía ninguno 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 de origen. 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 utilizando consultas conjuntivas y Datalog , un lenguaje de programación lógica puramente declarativa. [20] Se puede pensar libremente en una consulta conjuntiva como una función lógica aplicada a las relaciones de una base de datos como " where ". 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 en la consulta. Si bien los lenguajes formales como Datalog expresan estas consultas de manera concisa y sin ambigüedad, 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 (denotada como ) si los resultados de la aplicación son un subconjunto de los resultados de la aplicación para 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 en los sistemas GAV y 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 hacer que sus resultados sean equivalentes o estén contenidos al máximo por la consulta de nuestro usuario. Esto corresponde al problema de responder consultas utilizando vistas (AQUV). [21]
En los sistemas GAV, un diseñador de sistemas escribe el código del mediador para definir la reescritura de la consulta. Cada elemento de la consulta del usuario corresponde a una regla de sustitución, de la misma manera que cada elemento del esquema global corresponde a una consulta sobre la fuente. El procesamiento de la consulta simplemente expande los subobjetivos de la consulta del usuario según la regla especificada en el mediador y, por lo tanto, es probable que la consulta resultante sea equivalente. Si bien el diseñador realiza la mayor parte del trabajo de antemano, algunos sistemas GAV como Tsimmis implican la simplificación del 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 un mediador que alinee 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 consultas posibles para encontrar la mejor reescritura. La reescritura resultante puede no ser una consulta equivalente, sino que debe contenerse al máximo, y las tuplas resultantes pueden estar incompletas. A partir de 2011, [actualizar]el algoritmo GQR [22] es el algoritmo de reescritura de consultas líder para los sistemas de integración de datos LAV.
En general, la complejidad de la reescritura de consultas es NP-completa . [21] Si el espacio de reescrituras es relativamente pequeño, esto no representa un problema, incluso para sistemas de integración con cientos de fuentes.
Las preguntas a gran escala en la ciencia, 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] liderada por William Michener en la Universidad de Nuevo México ; The Data Conservancy, [24] liderada por Sayeed Choudhury de la Universidad Johns Hopkins ; SEAD: Sustainable Environment through Actionable Data, [25] liderado por Margaret Hedstrom de la Universidad de Michigan ; el Consorcio de la Federación DataNet, [26] liderado por Reagan Moore de la Universidad de Carolina del Norte ; y Terra Populus , [27] liderada por Steven Ruggles de la Universidad de Minnesota . Más recientemente, la Research Data Alliance [28] ha explorado la creación de marcos globales de integración de datos. El proyecto OpenPHACTS , financiado a través de la Iniciativa sobre Medicamentos Innovadores de la Unión Europea , construyó una plataforma de descubrimiento de fármacos vinculando conjuntos de datos de proveedores como el Instituto Europeo de Bioinformática , la Royal Society of Chemistry , UniProt , WikiPathways y DrugBank .
{{cite news}}: CS1 maint: varios nombres: lista de autores ( enlace )