Datos o metadatos, esa es la cuestión

En un post anterior acerca del lenguaje M, se planteó una duda en los comentarios acerca de qué relación guarda M con las tecnologías ORM, empleadas para el mapeado de datos de tipo relacional. Lo cierto es que el lenguaje M cubre una gran cantidad de necesidades diferentes (tanto en cuanto es modular y cada módulo ya desarrollado aborda diferentes problemas) y proporciona una serie de herramientas que posibilitan la creación de nuevos lenguajes específicos de dominio (DSL) que permiten describir modelos. Si bien, no es en sí mismo una tecnología que vaya a reemplazar a ningún ORM empleado en la actualidad. Al menos no es esa la intención, ni tampoco será la tendencia más generalizada.

No obstante, considero interesante puntualizar algunos aspectos ya que a menudo cuando hablamos acerca de Oslo surge cierta confusión en el público. Esta confusión viene según mi percepción causada por dos motivos principales. El primero de ellos es el hecho de que Oslo esté diseñado en un nivel de abstracción superior al de la mayoría de sistemas actuales, por tanto su ámbito es muy amplio y tendrá un impacto importante en prácticamente cualquier producto de desarrollo de Microsoft… y sino al tiempo…  Podéis apostar sobre seguro acerca de esto último, yo ya lo he hecho. Debido a la propia amplitud y elevada abstracción de este concepto, resulta en ocasiones complejo percibirlo con exactitud.

El segundo motivo de confusión principal es consecuencia directa de esta naturaleza abstracta de Oslo. Cuando hablamos en Oslo acerca de determinados conceptos como lenguajes, modelos, repositorio, etc. estamos empleando términos que han sido definidos ya en multitud de ocasiones para niveles de abstracción inferiores. Hablando en términos OOP, al emplear este vocabulario hablando sobre Oslo estamos redefiniendo métodos de una clase base que ya han sido definidos durante años en las clases derivadas de ésta. En este sentido, mi recomendación es que tratéis de olvidar todo cuanto os han enseñado en este ámbito, ya que muchos de esos conceptos asimilados en el pasado están basados en una visión miope del espacio. No obstante, una vez nos hayamos familiarizado con la jerga de Oslo, percibiremos el uso de estos términos como algo natural, e incluso comprenderemos mejor su significado para dominios más concretos.

Otro de los comentarios en dicha entrada hacía referencia al hecho de que Oslo “no es para nada algo nuevo“. Bien, en este sentido, argumentaré que de hecho Oslo no es algo completamente nuevo. Es más, me compadezco de cualquier presunto avance tecnológico que sea totalmente nuevo. Obviar tecnologías previas y aproximaciones a problemas ya propuestas es uno de los mayores defectos en Ingeniería, puesto que limita la capacidad de análisis en la validez de nuestra propia solución. Más allá de esta consideración, lo cierto es que Oslo toma prestadas muchas ideas sobre herramientas previas en el campo del desarrollo dirigido por modelos (MDD) y a dichas ideas añadimos un plus de funcionalidad y una vuelta de tuerca, basada en años de investigación propia y, por supuesto, influenciada por la comunidad investigadora en el ámbito MDD. Oslo trata de dar un enfoque coherente con las tecnologías y herramientas actuales y una visión evolucionada sobre el desarrollo de software, combinando partes muy diversas que han estado tradicionalmente desconectadas y que además entrañan una serie de dificultades de conexión, la combinación efectiva de todas estas piezas proporciona “un todo” mucho más potente, eficiente y adaptativo, aplicable a cualquier tipo de entorno de desarrollo. Sobre esto último me he propuesto convenceros en los próximos meses y años, así que prepararos para ver muchas, muchísimas, entradas al respecto de este tema. 😛

Tras esta introducción al contexto del post, ahí va mi pequeña historieta. Espero que sea en cierto grado explicativa.

A menudo vienen a mi cabeza recuerdos de mis primeros años de carrera. En realidad, no ha pasado demasiado tiempo desde eso, e incluso se podría decir que casi fue ayer cuando comencé en 1º de Informática (allá por el año 2002). Tras unos cuantos años en las aulas y muchas más horas de aprendizaje autodidacta y momentos excepcionales en la cafetería, vuelvo a plantearme algunas de esas preguntas, debates y conceptos un tanto dogmáticos que en aquellos primeros maravillosos años me hicieron asumir.

Uno de estos dogmas gira en torno a la diferencia entre datos y metadatos. Generalmente, a la hora de abordar esta cuestión, solemos encontrarnos con dos tipos diferentes de respuestas, o dos enfoques diferentes para una misma respuesta: “existe una gran diferencia entre datos y metadatos”. En mi modesta opinión, uno de los enfoques es ambiguo, y el otro es erróneo.

El primero de estos enfoques hace referencia al tipo de información contenida por nuestros datos y por nuestros metadatos. Tradicionalmente, podemos definir el término “datos” como “conjunto de información [estructurada]” y “metadatos” como “datos que contienen información sobre otros datos”. Hasta aquí, imagino que todos estaremos de acuerdo. Ahora bien, esta definición es bastante ambigua puesto que, en muchas ocasiones, una misma información puede ser dato o metadato en función del enfoque que estemos empleando. Por ejemplo, si estamos manejando información sobre películas, el título de una película es un dato; no obstante, dicho título (probablemente) aporte información acerca del argumento o tipo de película en cuestión. Por tanto, en este caso el título de dicha película podría considerarse al mismo tiempo un metadato. Como vemos, la frontera conceptual no está muy clara en esta primera aproximación.

La segunda aproximación de la respuesta pasa por considerar la frecuencia con la que empleamos estos datos. Esta aproximación está muy extendida y parte de la premisa de asociar los conceptos de “datos” y “datos transaccionales”, tratándose de datos que utilizamos continuamente, en contraste con los metadatos que consultamos con bastante menor frecuencia. Adicionalmente, se suele asociar el concepto de metadatos con datos de sólo lectura, mientras que los datos transaccionales son aquellos que modificamos a menudo. Esta respuesta va incluso más allá, afirmando que esta diferencia no es tan sólo evidente, sino que además determina de qué forma deberemos acceder a nuestros datos y metadatos: “Los conjuntos de metadatos se rigen por patrones de acceso diferentes”, he escuchado decir en alguna ocasión… Personalmente, y perdonadme por la expresión, esto me parece una auténtica chorrada. No podemos clasificar datos en función de su uso, en lugar de hacerlo propiamente por el tipo de éstos. Ya que, incluso en el hipotético caso de que asumiéramos este método como válido, estaríamos incurriendo nuevamente en una grave relajación de la frontera conceptual de ambos términos. Por ejemplo, consideremos una factura detallando el coste de una serie de materiales empleados para la construcción de un coche. Para el Ingeniero, la factura es un dato de tipo transaccional. No obstante, para el gestor de recursos, el coste de cada material es un metadato “de sólo lectura” que deberá considerar a la hora de realizar nuevos pedidos o diseñar el plan de producción.

Como podemos ver, ninguna de ambas aproximaciones es suficientemente esclarecedora, lo cual puede inducir a malentendidos graves en caso de asumir alguna de ellas. En mi opinión, el principal problema surge de la creencia de que existe la necesidad de clasificar diferentes tipos de datos, cuando realmente lo que existe es la necesidad de comprender cuándo y cómo emplear uno u otro. Me gustaría ir más lejos en este razonamiento y argumentar que, hablando en términos de almacenamiento y consulta de datos, serialización y transferencia de los mismos, así como el resto de cuestiones que realmente importan en el desarrollo de software de tipo empresarial, todos los datos son datos al fin y al cabo (valga la redundancia), y por ello no existe motivo realmente justificable para tratarlos de diferente forma desde el punto de vista de la arquitectura de nuestro sistema. De este modo, es probable que tengamos modelos primarios y modelos secundarios, modelos protegidos y modelos compartidos, pero al fin y al cabo todos ellos son modelos cuya finalidad es representar el comportamiento de nuestro software, y por supuesto la forma de acceder a ellos e incluso de modificarlos es exactamente idéntica. Tan sólo encontraremos diferencias en el propósito último de este proceso (finalidad con que consultamos dichos datos), pero no en su metodología.

En este sentido, en el equipo de Oslo nos hemos preocupado por ofrecer un amplio conjunto de herramientas que proporcionan capacidad más que suficiente a nuestros usuarios para (por este orden) describir una serie de datos o información, validar dichos datos, poder modificarlos, almacenarlos en un repositorio “in the cloud”, y a través de dicho repositorio ser capaz de acceder nuevamente a ellos y también compartirlos. Los escenarios fundamentales en que contemplamos el uso de Oslo ahora mismo consisten en la definición de modelos y datos que describan los entornos de ejecución (runtimes) en los que ejecutar nuestro software. Sin embargo, este escenario no es el único en el que veremos presencia de Oslo con el paso del tiempo ya que, por una parte, las ambiciones del proyecto involucran además otra serie de escenarios y, por otra parte, la arquitectura y diseño del sistema permite la extensibilidad de este concepto.

De todo esto y más os hablaré en próximas entradas.  

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *