El Schema de los datos es la parte de la metadata donde se identifican las características de cada uno de los campos que forman parte de una entidad. El ejemplo más claro lo tenemos en la columna de una tabla de la base de datos. En este caso, podemos encontrar campos del tipo cadena, numérico, fecha, booleano,… e incluso alguno de ellos, a su vez se subdividen dando lugar a un amplio portfolio de valores y si no es poco esto, además existe la posibilidad de describir cada atributo más detalladamente, por ejemplo indicando la longitud, precisión, escala,… vamos que la gestión del Schema es todo un arte.
Hace unos días, con varios de los integrantes del grupo de trabajo de Arquitectura de Datos en DAMA España, estuvimos charlando acerca del mantenimiento del Schema de datos y si se debía o no confiar en su gestión automática. En mi caso, me posicioné claramente en el no. El Schema del dato, para mi, debe estar gestionado por el propietario del sistema fuente y además, entre las tareas de este debe estar el comunicar cualquier cambio que se produzca, pues como cualquier aplicación empresarial, el Schema está sujeto a modificaciones y actualizaciones.
Por otro lado, hace unos días estuve hablando con uno de los equipos de Fivetran y durante la charla salió a relucir el mantenimiento automático del Schema de datos. En ese momento aproveché para hacer una pregunta al respecto de cómo maneja la solución de datos de Fivetran internamente la gestión del Schema. Es decir, si la descripción del campo se obtiene leyendo la metadata del sistema fuente o si por contra, la asignación y las características del atributo se realizan mediante la lectura y evaluación de un subconjunto de registros (como por ejemplo hace Pandas en Python con las primeras 1.000 filas).
NOTA:
Quedaron en responderme en unos días, pues no tenían en ese momento el detalle, aunque me temo que será la segunda opción.
Pues resulta que ambas aproximaciones no son perfectas. Ya que sucede que donde la metadata del sistema fuente declara un tipo NUMERIC con precisión 0 te llegue un valor con dos decimales (o más) y lo mismo si el registro 1.001 es una cadena mientras que los 1.000 primeros sobre los que se realiza la evaluación son INTEGER. En ambos casos estaríamos introduciendo ineficiencias en la solución de gestión de datos.
CONCLUSIÓN
Como apunté en la entrada anterior, parte de la solución está en la puesta en vigor de Data Contracts donde se describa claramente la responsabilidad de cada uno de los intervinientes. Tanto productor como receptor deben estar completamente alineados y respetar ese acuerdo de mínimos o el proceso terminará siendo ingobernable, lo que supone una fuerte pérdida económica y sobre todo (y esto es mucho peor) de confianza en la información que se maneja dentro de la organización.
Por eso, si quieres sacar el mayor fruto a tus datos empresariales, sienta unas bases robustas en los procesos antes de decidirte por una u otra tecnología.
Foto de portada gracias a Pixabay: https://www.pexels.com/es-es/foto/numeros-en-el-monitor-534216/
Alb3rto Alonso 