¿Está muerto el modelado de datos?

¿Seguimos necesitando modelos de datos? ¿Cuál es el valor de los modelos? ¿Por qué fracasó el modelado de datos en el pasado? ¿Cómo crear modelos de datos? ¿Cómo crear valor mediante el modelado? Intento responder a todo esto en la siguiente presentación.

¿Está muerto el modelado de datos?

La pregunta interesante es: ¿está muerto el modelado de datos? Y no es una pregunta hipotética. Empezó hace unos años cuando estaba en una conferencia en Estados Unidos, y unos modeladores de datos muy famosos, que llevaban 30-40 años trabajando para grandes aseguradoras, preguntaban: «¿Está muerto el modelado de datos?» Hacían su trabajo, creaban valor, pero ya no se sentían apreciados. El valor del modelado de datos no se percibía tanto como antes.

Empecemos por entender qué es el modelado de datos y por qué lo necesitamos. Para contexto, trabajo para una herramienta de automatización de data warehouse llamada Datavault Builder. Creemos en trabajar sobre modelos de negocio y convertirlos automáticamente en código funcional. Esta es mi perspectiva personal.

Permítanme compartir mi experiencia profesional y una historia simplificada del modelado de datos. Empecé a trabajar en el área de data warehousing en el año 2000. Inicialmente trabajé para una entidad financiera donde nos centrábamos en la conciliación de datos. Posteriormente pasé a trabajar con variables de telecomunicaciones y dirigí un equipo de data management para una telco. Trabajábamos con tareas más complejas.

En 2012 me enfrenté a desafíos con el data warehousing ágil y casi en tiempo real. Probé Data Vault como paradigma de modelado y funcionó bien. Sin embargo, nos dimos cuenta de que la automatización era necesaria para que fuera efectivo. Esta toma de conciencia en 2012 sentó las bases de Datavault Builder.

Hoy, mi rol incluye actividades pre-sales y post-sales, además de presentaciones para formar a la gente y permitir el intercambio de ideas en la comunidad.

¿Qué son los modelos de datos?

¿Qué significan los modelos para mí? Dan sentido a cosas complejas simplificándolas. Un modelo es habitualmente una representación simplificada de algo más complicado. Si busca «ontología» en Wikipedia, encontrará distintos tipos de elementos: clases o conceptos, propiedades, relaciones, axiomas y restricciones. Estos elementos básicos del modelado de datos se han mantenido consistentes a lo largo de la historia. Esto significa que si aprende modelado de datos en un momento dado, estará bien preparado durante muchos años.

Pongamos el ejemplo de un árbol. Un árbol real con todas sus hojas y ramas tiene miles de aspectos distintos. Capturar un árbol real en una base de datos sería enorme y a menudo innecesario para fines analíticos. Podemos crear un modelo más simple que represente las características clave. Incluso con esa representación simplificada, reconocería el árbol. Contar árboles sería sencillo. Este nivel de simplicidad es suficiente para muchas aplicaciones.

Hay una imagen famosa que ilustra la relación entre la cosa real y su modelo. Dice: «Esto no es una pipa»; es una imagen de una pipa. Es una representación simplificada en dos dimensiones, pero aún reconoce qué es. Sin embargo, es importante recordar que no es la cosa real.

Ahora consideremos el bosque en esa imagen. Podemos simplificar el concepto: dentro de un bosque hay muchos árboles. Un guarda forestal cuida del bosque, o de varios. Existen distintas especies de árboles y hay propietarios. Con esta imagen simple ya entiende el concepto básico.

Esto se convierte en un medio de comunicación. Personas de distintas áreas de negocio en la misma empresa pueden reunirse y discutir asegurándose de que tienen el mismo entendimiento. Esta capa permite encontrar terreno común entre IT y negocio.

¿De dónde viene todo esto? Algunos afirman que Edgar F. Codd es el padre de las bases de datos relacionales. Escribió un libro influyente en los años 70. Todos los enfoques posteriores de modelado se apoyan en los mismos principios: el modelado de datos consiste en identificar y describir cosas y establecer relaciones entre ellas. También implica trabajar sobre ACID y la normalización.

Normalización

La normalización implica dividir los datos en claves primarias para identificación, claves foráneas para establecer relaciones y atributos para describir cosas. Un objetivo principal de la normalización es eliminar la duplicación. Por ejemplo, en lugar de repetir la descripción completa de un tipo de cliente para cada cliente, podemos crear una tabla aparte de tipos de cliente y referenciarla mediante una relación.

Codd se ocupaba de los sistemas OLTP (online transaction processing). Más tarde surgieron nuevos sistemas con el objetivo de proporcionar mejores vistas y capacidades de reporting. La velocidad es crucial, ya que los sistemas de data warehousing abarcan un periodo de tiempo largo y queremos rastrear los cambios históricos.

En el mundo del data warehousing preferimos transitar gradualmente al uso de business keys para identificar entidades, garantizando estabilidad en el tiempo aunque los sistemas IT se reemplacen.

El Data Warehouse 3NF

En 1992 Bill Inmon, a menudo llamado el padre del data warehousing, entró en escena. Comenzó a construir el data warehouse y lo definió como «una colección de datos orientada a sujeto, no volátil, integrada y variante en el tiempo en apoyo a las decisiones de gestión». Esta definición sigue siendo cierta para muchos casos.

Inmon usó bases en tercera forma normal, que mejoraban en aquel momento. Introdujo claves surrogate para guardar distintas versiones de información. El reto con este enfoque es la mantenibilidad. Las claves foráneas se utilizan, y en un data warehouse totalmente historizado, cualquier cambio a la entidad cliente puede impactar todo el historial de las entidades relacionadas. Este efecto en cascada hace que los cambios sean extremadamente costosos.

El modelo dimensional

¿Cuál era el propósito de lo que Kimball llamó conformed dimensions? Integró todos los datos de distintos sistemas IT en una única dimensión cliente, desnormalizando los datos ya que el almacenamiento se ha vuelto mucho más barato. Desnormalizar facilita las consultas con menos joins.

Otro enfoque que tomó Kimball fue construir fact tables ligeras que referencian distintas dimensiones. La mantenibilidad sigue siendo una preocupación, especialmente con dimensiones históricas. El impacto se limita a la fact table y a las dimensiones, ya que son objetos desnormalizados.

Aquí entra Data Vault y sugiere que volvamos al núcleo normalizado y lo mejoremos en lugar de reemplazarlo. Para presentar datos, el modelo dimensional sigue siendo apropiado, pero debería crearse de forma virtual o reconstruible a partir del núcleo normalizado.

Modelado Data Vault

Volvemos al concepto de definir e identificar cosas, donde un objeto único llamado Hub almacena solo la clave inmutable. Los atributos con historia se almacenan en tablas separadas (satélites), y las relaciones se almacenan en su propia tabla de relación (links). Al separar las funciones de los datos en objetos distintos, Linstedt logró beneficios en términos de mantenibilidad.

Aunque puede que no sea tan eficiente físicamente como un star o snowflake, ofrece ventajas en mantenibilidad.

La evolución de la tercera forma normal al modelo Data Vault sigue dependiendo del modelo dimensional para consultas, que puede ser una vista virtual.

Otros enfoques de modelado

Aparte de estos enfoques, si quiere saber más sobre Anchor Modeling recomiendo leer los antiguos artículos de Lars Rönnbäck. Abordó algunos problemas mal automatizados.

También está BEAM y el ensemble logical modeling. El énfasis está en un modelo conceptual primero, identificar cosas después, luego añadir relaciones y atributos.

¿Está muerto el modelado de datos?

La pregunta final: ¿está muerto el modelado de datos? Creo que crear modelos solo sobre el papel, sin conexión con la implementación real automatizada, sin demostrar el valor directamente a los usuarios de negocio, no es un enfoque efectivo. Si no automatiza el código, los desarrolladores tendrán dificultades para entender el valor de los modelos.

Otro problema es el tiempo que se tarda en crear modelos de datos antes de empezar la implementación, lo que inicialmente no crea valor. En su lugar, debemos adoptar el modelado de datos ágil, vinculando las implementaciones conceptual, lógica y física de forma automatizada.

Conceptual, lógico y físico

Para mí, el modelo conceptual es el punto de partida del modelo lógico, y luego añadimos las relaciones y definiciones de claves. Lo importante es que haya una relación directa entre ellos, no solo del conceptual al lógico, sino también a las implementaciones físicas. Esto debería ocurrir automáticamente.

Es necesaria una conexión bidireccional. Si queremos reinventar los modelos de datos y hacerlos efectivos, debemos pasar de conceptual a lógico a físico en tiempo real.

CI/CD

Para lograrlo necesitamos separar nuestros entornos de desarrollo, test y producción. Si aspiramos a ser realmente ágiles, podemos trabajar con Git y GitFlow, adoptando un enfoque de desarrollo distribuido.

En el mundo del data warehousing no tenemos un equivalente directo a la working folder de Java. En mi opinión, el equivalente es un sandbox.

Pipelines as Code

Una solución alternativa propuesta por otros es usar pipelines as code. Cuando tenemos código podemos usar el enfoque de working folder. Sin embargo, hay un inconveniente importante: falta el aspecto del modelado, que da significado al proceso. En lugar de centrarse en los requisitos de negocio, la tecnología toma precedencia, y se pierde todo el sentido.

Devolver la vida a los modelos

El primer paso es establecer un modelo de datos ágil, y aquí entra Data Vault. Se alinea con el concepto fundamental de incorporar nuevos elementos sin fricciones. El acoplamiento débil de elementos garantiza la independencia.

El segundo aspecto es automatizar la transformación de un artefacto de modelado en un artefacto físico. Podemos transformar un hub en su representación física de forma determinista. Igualmente, podemos tomar una tabla física y transformarla en un objeto lógico.

Ahora tenemos un enfoque similar al de quienes trabajan con data pipelines as code, pero con una capa adicional de significado. Esto cierra la brecha y beneficia a desarrolladores y profesionales de negocio, dando vida a nuestros modelos de datos.

Esta es la esencia de la metodología Data Vault, y Datavault Builder facilita un proceso totalmente automatizado de modelado-a-código.