Diseño de modelos de datos y mejores prácticas: Parte 1

Aplicaciones corporativas, integración de datos, gestión de datos maestros, almacenamiento de datos, big data, data lakes y machine learning. Todos ellos tienen (o deberían tener) un ingrediente compartido y esencial: un modelo de datos. Conviene NO olvidarlo jamás ni, como en muchas situaciones que observo, ¡ignorarlo por completo!

El modelo de datos es el pilar básico de prácticamente todas nuestras soluciones empresariales fundamentales de gran valor del ámbito del comercio electrónico y el punto de venta, finanzas, gestión de productos y de clientes, o business intelligence e Internet de las cosas. Sin un buen modelo de datos, ¿dónde están los datos relativos al negocio? Probablemente: ¡perdidos!

Tras el éxito de mi serie de artículos en el blog sobre patrones de diseño de tareas de Talend y mejores prácticas (pueden consultar la Parte 1, Parte 2, Parte 3 y Parte 4), que abarca 32 mejores prácticas y analiza la mejor formar de crear tareas en Talend, apunté que los modelos de datos estaban al caer. ¡Pues aquí los tenemos!

Los modelos de datos y las metodologías de modelado llevan entre nosotros desde tiempos inmemoriales. O, si no inmemoriales, sí desde que se inventó la computación. Los datos requieren una estructura para tener sentido y darles a los ordenadores una forma de manejar todos esos bits y bytes. Es verdad que hoy en día tenemos datos sin estructurar o semiestructurados también, pero en mi opinión lo que hemos hecho es evolucionar hacia paradigmas más sofisticados que aquellos a los que se enfrentaban nuestros predecesores computacionales. Por lo tanto, los modelos de datos persisten y son los cimientos sobre los que creamos aplicaciones comerciales muy avanzadas. Al igual que con las mejores prácticas de Talend, considero que debemos tomarnos seriamente nuestros modelos de datos y métodos de modelado.

Descargar >> Talend Open Studio for Data Integration

Puede resultar iluminador echar un vistazo a la historia del modelado de datos, por lo que estudié un poco el tema para refrescar la memoria.

Una breve clase de historia sobre los modelos de datos

En el «oscurantismo informático» utilizábamos diseños de registros planos o vectores; todos los datos se grababan en casetes o en grandes unidades de disco para su posterior recuperación. Sin embargo en 1958 J. W. Young y H. K. Kent describieron los sistemas de información basados en el modelado como “una forma precisa y abstracta de especificar la información y las características temporales de un problema de procesamiento de datos”. Poco después, en 1959, CODASYL o «Conference/Committee on Data Systems Languages«, un consorcio, fue formado por el Charles Babbage Institute de la Universidad de Minnesota, que acabó presentando lenguajes de programación normalizados, como COBOL, y el «Almacén de Datos Integrados» (IDS, en inglés); una tecnología temprana de bases de datos diseñada durante la década de los sesenta en GE/Honeywell por Charles Bachman. Con el tiempo se vio que IDS era complicado de utilizar, de modo que evolucionó hasta convertirse en el «Sistema de Gestión de Bases de Datos Integradas» (IDMS, en inglés) desarrollado en B. F. Goodrich (una empresa aeroespacial estadounidense de aquella época y, en efecto, la empresa de neumáticos que conocemos en la actualidad), comercializado por Cullinane Database Systems (hoy en día propiedad de Computer Associates). Estas dos metodologías de modelado de datos, conocidas como el «Modelo de datos jerárquicos» y el «Modelo de datos en red«, respectivamente, fueron muy habituales en los ordenadores centrales durante los siguientes 50 años. Se siguen empleando hoy en día. ¡Impresionante!

A finales de la década de los sesenta, cuando aún trabajaba en IBM, E. F. Codd en colaboración con C. J. Date (autor de «Introducción a los sistemas de bases de datos«), cartografía las innovadoras teorías de modelado de datos de Codd en «Un modelo relacional de datos para grandes bancos de datos compartidos«, que fue publicado en 1970. La campaña de Codd para garantizar que los proveedores aplicaban correctamente la metodología conllevó la publicación de sus conocidas «Las doce reglas del modelo relacional» en 1985. En realidad eran trece reglas, numeradas de cero a doce; Codd fue lo que llamaríamos un friki de la informática de su tiempo. El Modelo relacional también introdujo el concepto de «normalización» con la definición de las «Cinco formas normales«. Muchos hablamos de la «3NF» o la «Tercera forma normal«, pero ¿sabe usted cómo definirla? Consulte estos dos enlaces y descubra si realmente conoce lo que cree que conoce. ¡Al final tendrá que pasar un examen! Es broma…

La siguiente metodología de modelado de datos relevante llegó en 1996 a propuesta de Ralph Kimball (jubilado), en su libro pionero escrito a cuatro manos con Margy Ross, «The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling». El modelo de datos en «esquema en estrella« de Kimball, ampliamente aceptado, aplicaba conceptos introducidos en el primer paradigma de almacenes de datos propuesto en los setenta por W. H. (Bill) Inmon (nombrado en 2007 por Computerworld una de las diez personas más influyentes de los primeros 40 años de la informática). El texto «Building the Data Warehouse» de Inmon, publicado en 1991, se ha convertido en la norma de referencia para la computación relativa a los almacenes de datos. Si bien es cierto que Inmon y Kimbal tuvieron sus diferencias acerca del enfoque correcto para poner en marcha los almacenes de datos, Margy Ross, del grupo de Kimball, en su artículo «Differences of Opinion» ofrece una explicación justa y equilibrada que vale la pena conocer.

Hace poco ha surgido otra metodología de modelado de datos que parece un sólido aspirante. ¡La bóveda de datos (data vault)! Su autor e inventor, Dan Linsdedt, concibió esta bóveda de datos en 1990 por primera vez y sacó una publicación al dominio público en 2001. El modelo de bóveda de datos soluciona muchas de las discusiones contrarias de Inmon y Kimball, incorporando linaje histórico de datos y ofreciendo un paradigma muy adaptable, auditable y expandible. Una mejora fundamental (en mi humilde opinión); eche una ojeada a mi entrada del blog ‘¿Qué es «la bóveda de datos» (data vault) y por qué la necesitamos?. La bóveda de datos de Linstedt demostró ser valiosísima para diferentes proyectos importantes del Departamento de Defensa de EE.UU., la NSA y empresas privadas. En 2013 Linsdedt publicó Data Vault 2.0, en la que abordaba los big data, NoSQL, la integración de datos no estructurados y semiestructurados, junto con mejores prácticas de SDLC para darle un mejor uso. El momento perfecto, diría yo. Y hasta aquí hemos llegado…

Resumen de los modelos de datos

He aquí un rápido repaso histórico a algunas de las distintas metodologías de modelado de datos:

  • Modelo plano: único vector bidimensional de elementos de datos
  • Modelo jerárquico: registros que contienen campos y conjuntos que definen una jerarquía padre/hijo
  • Modelo en red: parecido al modelo jerárquico, pero permite relaciones de uno a muchos con un mapeo de tablas asociativas con enlace (‘link’)
  • Modelo relacional: compilación de predicados de un conjunto finito de variables de predicado definido con limitaciones sobre los posibles valores y su combinación
  • Modelo de esquema en estrella: tablas de hechos y dimensiones normalizadas que eliminan los atributos de baja cardinalidad para las agregaciones de datos
  • Modelo de bóveda de datos: registra datos históricos a largo plazo a partir de distintas fuentes por tablas concentradores, satélites y enlaces

Ciclo de vida del desarrollo de bases de datos (DDLC, en inglés)

Hoy en día el diálogo parece centrarse en exclusiva en la complejidad y el volumen de los datos. Es importante, no hay duda, pero me gustaría insistir una vez más en que el modelo de datos debería ser una parte importante de esta conversación. A medida que los requisitos evolucionan, el esquema (un modelo de datos) debe adaptarse a los tiempos, o incluso abrir camino; pero en todo caso debe ser gestionado. Por esta razón les presento… ¡el Ciclo de vida del desarrollo de bases de datos!

Para cada entorno (como DEV/TEST/PROD) en los que se manejen datos, los desarrolladores tienen que ajustar y adaptar el código para su inevitable mutación estructural. De forma parecida al Ciclo de vida del desarrollo del software (SDLC, en inglés), una base de datos debería ajustarse a un diseño de modelo de datos y a las mejores prácticas. De los muchos modelos de datos que he diseñado, he detectado una serie de preceptos claros como estos:

  • Adaptabilidad: creación de esquemas que resistan el refuerzo o la corrección
  • Capacidad de ampliación: creación de esquemas que crezcan más allá de lo esperado
  • Fundamentalidad: creación de esquemas que cumplan sus prestaciones y funcionalidades
  • Portabilidad: creación de esquemas que puedan alojarse en sistemas dispares
  • Explotación: creación de esquemas que maximicen una tecnología de host
  • Almacenado eficiente: creación de esquemas optimizados para su presencia en disco
  • Alto rendimiento: creación de esquemas optimizados destacados

Estos preceptos de diseño incorporan la esencia de cualquier metodología de modelado que elijamos, aunque algunos se contradigan entre sí. En mi experiencia, independientemente de estas dicotomías, un modelo de datos presenta siempre tres etapas vitales de la cuna a la sepultura:

  • Una INSTALACIÓN desde cero: a partir de la versión actual del esquema
  • Aplicación de una ACTUALIZACIÓN: eliminar/crear/modificar objetos de Bd al actualizar de una versión a la siguiente
  • MIGRACIÓN de datos: en la que tenga lugar una «mejora» disruptiva (como la división de tablas o una plataforma)

El diseño de un modelo de datos puede ser un acto de amor que exija por un lado una engorrosa atención al detalle, atenuada por la creativa abstracción de la ambigüedad. Como a mí los esquemas complicados me atraen mucho, busco grietas y recovecos que requieran corrección y que a menudo cobran formas muy distintas. Para muestra, un botón:

  • χ Claves primarias compuestas a evitar, pocas veces son eficaces o adecuadas; existen ciertas excepciones, según el modelo de datos
  • χ Claves primarias erróneas normalmente el módulo datetime o cadenas (salvo GUID o Hash) que no son adecuados
  • χ Indexación errónea por exceso o por defecto
  • χ Tipos de datos de columna cuando tan solo necesite un entero, no utilice un Long (o BigInteger), sobre todo en una clave primaria
  • χ Asignación de almacenamiento independiente del tamaño de datos o el potencial de crecimiento
  • χ Referencias circulares en las que una tabla A guarda relación con la tabla B, la tabla B guarda relación con la tabla C y la tabla C guarda relación con la tabla A; esto está simple y llanamente mal diseñado (en mi humilde opinión)

Veamos, entonces, en qué consistiría una mejor práctica de diseño de una base de datos: El proceso de diseño y publicación de un modelo de datos. Yo creo que, al idear un modelo de datos, uno debería seguir un proceso recomendado semejante a este:

Para la mayoría serán obviedades, pero me gustaría subrayar la importancia de seguir este proceso. Los cambios de esquema son ineludibles, pero es importantísimo contar con un modelo de datos sólido ya en los primeros estadios de cualquier proyecto de desarrollo de software. No hay duda de que, para poder entregar proyectos de software satisfactorios, es conveniente minimizar el impacto que se cause sobre el código de aplicación. Los cambios de esquema pueden ser una propuesta cara, de modo que resulta crucial entender el ciclo de vida de la bases de datos y el papel que desempeña. También es muy importante la creación de versiones de su modelo de base de datos. Utilice diagramas gráficos para ilustrar los diseños. Cree un «diccionario de datos» o un «glosario» para hacer seguimiento del linaje de cambios históricos. Requiere bastante disciplina, ¡pero funciona!

Metodologías de modelado de datos

Entender la historia del modelo de datos y el mejor proceso para diseñarlo es tan solo el comienzo. Como arquitecto de bases de datos tanto de modelos transaccionales (OLTP) como analíticos (OLAP), he descubierto que los primeros tres pasos ilustrados más arriba suponen aproximadamente un 80 % del trabajo. La próxima vez, más nos vale recordarlo.

En ocasiones los modelos de datos son sencillos, a menudo debido a su simplicidad o a que son de pequeña envergadura. También pueden ser muy complicados, por su complejidad, diversidad o sencillamente por la magnitud y la forma de los datos, así como las múltiples ubicaciones en la empresa en las que se utilizan. Creo que deberíamos entender cuanto antes mejor el alcance total de los datos y su localización, cómo se ven afectados o cómo afectan a las aplicaciones y los sistemas que los utilizan y cuál es el motivo de su presencia. Lo difícil es comprender realmente qué necesita cada cual y cómo suministrárselo. El objetivo es mapearlo para afianzar un modelo de datos sólido. Es fundamental elegir la metodología correcta de modelado de datos.

Valor comercial de un modelo de datos

Las tareas de ETL/ELT de Talend se escriben para leer y escribir datos. En teoría esto lo hacemos para proporcionar valor a la empresa. Si es así, ¿por qué necesitamos un modelo de datos? ¿De qué sirve? ¿No podemos limitarnos a tratar los datos y listos? Desde un punto de vista técnico, dependemos del modelo de datos para ofrecer una estructura que nos permita manipular el flujo de datos. El ciclo vital de un modelo de datos afecta directamente el diseño, el rendimiento y la escalabilidad de una tarea. Y esto, técnicamente, es tan solo la punta del iceberg. La perspectiva empresarial tal vez es más abstracta. Ante todo, el modelo de datos valida los requisitos del negocio. Ofrece una definición crítica de la integración de sistemas y el control estructural de los datos que emplea la empresa, por lo que garantiza una serie de pilares funcionales y operativos. Yo sostengo que la empresa, sin un modelo de datos, pierde toda su eficiencia. ¿Soy el único?

Conclusión

Sin el modelo de datos y herramientas como Talend, los datos pueden fracasar estrepitosamente a la hora de proporcionar valor comercial o, aún peor, dificultar su éxito debido a imprecisiones, un mal uso o malentendidos. En mi experiencia, contar un modelo de datos bien definido y mejores prácticas de DDLC acelera y aumenta el valor comercial de los datos.

En la segunda parte de esta serie ilustraré y examinaré los rudimentos y el valor del modelo de datos lógico y físico. También propondré una ampliación sobre la forma de distinguir nuestros datos: primero desde una óptica holística y luego desgranando los detalles conceptuales, antes de llegar al diseño lógico o físico en sí. Para ayudarnos a entender mejor los datos, estos los modelan y validan el modelo de nuestro diseño de base de datos.

Hasta entonces, reflexione sobre la información presentada en esta entrada y no dude en dejar comentarios, preguntar o debatir los principios que he presentado. ¡Hasta la próxima!

Haga clic aquí para acceder a la segunda parte

Descargar >> Talend Open Studio for Data Integration

Participe en las conversaciones

0 Comments

Leave a Reply