Criterio técnico · WAVE56

Qué revisar antes de integrar una fuente de datos

Antes de construir un conector reviso qué dato hace falta y qué ocurrirá cuando la fuente cambie. Que una API responda en la primera prueba dice poco de cómo se comportará cuando una aplicación dependa de ella cada día.

Primero, la pregunta que debe responder el dato

La misma fuente puede servir para mostrar un mapa, alimentar un informe o tomar una decisión operativa. Esos usos piden distinta precisión y distinta frecuencia de actualización. Si solo necesitas una consulta puntual, quizá no haga falta una base de datos que se actualice cada noche. Si el dato interviene en una operación diaria, necesito saber cuánto retraso admite y quién detectará un fallo.

La revisión inicial deja por escrito el uso previsto, la cobertura geográfica o temporal, los campos imprescindibles y los casos que no cubre la fuente.

Permiso de uso y acceso real

Compruebo cómo se accede, qué condiciones permiten reutilizar la información y si hay límites técnicos o costes. Que una página sea pública no autoriza cualquier extracción ni cualquier uso posterior. También separo las licencias del software de las condiciones de la fuente y de los datos personales que pueda contener.

Si el acceso depende de una cuenta o de una autorización de tu empresa, me aseguro de que esté disponible antes de presupuestar la integración.

El modelo debe conservar el contexto

Identificar cada registro por su posición en un archivo suele fallar en cuanto cambia el orden o se publica una versión nueva. Busco identificadores estables; si no existen, documento cómo se reconocerá una actualización frente a un registro nuevo. Conservo el origen y la fecha de obtención cuando hacen falta para explicar una cifra o rehacer una carga.

Pruebo una muestra con valores ausentes, fechas inconsistentes y duplicados. Los casos dudosos no se convierten automáticamente en ceros ni se descartan sin dejar rastro.

La carga también debe fallar bien

Defino qué hacer si la fuente no responde, cambia un nombre de campo o entrega solo una parte de los registros. El proceso debe mostrar dónde se detuvo, permitir repetir una carga sin multiplicar filas y avisar cuando el dato disponible ya no está actualizado. La forma exacta depende del volumen y del coste de un error; no todos los proyectos necesitan la misma infraestructura.

Puedo plantear una primera fase con tres entregas: el inventario de las fuentes, una prueba con datos reales que tengas autorización para usar y una propuesta de modelo y de actualización. Con eso decides si merece la pena construir el pipeline completo.

Referencia para contrastar la calidad

La guía de calidad de datos abiertos de datos.gob.es reúne problemas de duplicidad, formatos, valores ausentes y documentación. Es una referencia para revisar fuentes públicas, no una garantía de que una fuente concreta esté libre de esos problemas.

Si buscas datos públicos de tu comunidad, explico también qué hay en el portal de datos abiertos de la Región de Murcia y cómo aprovecharlo. Si la fuente son datos de contratación pública, en otra nota explico cómo estudiaría datos de licitaciones y contratos. Si el destino es un panel de indicadores, explico también cómo plantear un cuadro de mando que se actualice solo.

¿Tienes un caso parecido?

Escríbeme qué ocurre ahora y qué te gustaría cambiar; no hace falta una especificación técnica. Preparar la propuesta no tiene coste.

Te respondo en dos días laborables como máximo. También puedes escribir a hola@wave56.com.

Escribir una consulta