Integración de Datos

La integración de datos es el proceso de combinar información procedente de fuentes heterogéneas —bases de datos relacionales, APIs, ficheros, hojas de cálculo, sensores o servicios en la nube— para ofrecer al usuario una vista unificada y coherente, como si toda esa información residiera en un único lugar. No consiste en copiar datos de un sitio a otro, sino en reconciliar su significado: alinear esquemas distintos, resolver identidades duplicadas y garantizar que las cifras cuadren.

Conviene distinguirla de la simple ingesta. Ingerir es mover datos; integrar es reconciliar su semántica. Maurizio Lenzerini, en su influyente trabajo «Data Integration: A Theoretical Perspective» (2002), formalizó un sistema de integración como la relación entre un esquema global, los esquemas de las fuentes y el mapeo que los conecta. Esa tensión entre lo que el usuario quiere ver y cómo están realmente almacenados los datos es el corazón del problema.

Los problemas centrales: esquemas, entidades y calidad

El primer obstáculo es la heterogeneidad de esquemas: dos fuentes pueden llamar «cliente» y «customer» al mismo concepto, o repartir una dirección en campos distintos. Alinearlas es schema matching y schema mapping, problemas que Doan, Halevy e Ives tratan junto con los mapeos y las transformaciones. El segundo es la resolución de entidades (deduplicación o record linkage): decidir si «J. Pérez, Madrid» y «Juan Pérez, ES» representan a la misma persona pese a no compartir clave. La revisión de Elmagarmid, Ipeirotis y Verykios de 2007 explica por qué errores, campos incompletos y formatos distintos impiden una comparación exacta. El tercero es la calidad y consistencia: valores ausentes, formatos incompatibles o contradicciones entre fuentes que deben resolverse antes de confiar en la vista integrada. La revisión de Google Research sitúa estos problemas en la evolución del campo.

Arquitecturas: del ETL al lago de datos

El enfoque clásico es el ETL (extraer, transformar, cargar): se extraen los datos, se limpian y transforman, y se cargan en un almacén de datos o data warehouse. Bill Inmon publicó Building the Data Warehouse en 1992, y Ralph Kimball sistematizó el modelado dimensional en 1996. ELT invierte el orden: carga primero y transforma después. En octubre de 2010, James Dixon describió el «data lake» como datos en un estado más natural frente al «agua embotellada» de un data mart; la fecha de 2011 que figuraba aquí era incorrecta. Frente a estas soluciones materializadas, la integración virtual o federada deja los datos en origen y los combina al consultar. La arquitectura de referencia de NIST permite comparar estas piezas sin confundir almacenamiento, procesamiento e integración.

Por qué importa para la inteligencia artificial

Antes de entrenar un modelo hay que reunir señales dispersas en un conjunto coherente: la integración es condición previa, no un lujo posterior. Si dos registros de una misma entidad se tratan como personas distintas, esa entidad puede pesar dos veces; si dos esquemas asignan significados distintos a un mismo campo, la característica deja de ser comparable. Son riesgos que deben comprobarse, no una garantía automática de sesgo. La revisión de Google Research conecta integración con correspondencias, consultas y procedencia; DAMA-DMBOK incluye integración e interoperabilidad dentro de un marco más amplio de gestión y gobierno. La trazabilidad exige además conservar origen, transformación y reglas de resolución: citar el marco no demuestra que una canalización concreta las cumpla.