Teoría de Grafos aplicada al Gobierno del Dato

Teoría de Grafos aplicada al Gobierno del Dato

La Teoría de Grafos aplicada al mundo Data nos dice que una base de datos, orientada a grafos, representa la información como nodos de un grafo y sus relaciones con las aristas del mismo, de manera que se pueda usar dicha teoría para recorrer la base de datos ya que esta puede describir atributos de los nodos (entidades) y las aristas (relaciones).

Graph Model

Bien, dicha afirmación que es sacada casi textual de la Wikipedia, “amañada” un poco a mi interés, nos dice claramente que podemos crear una estructura de control y Gobierno del Dato que a partir de la descripción de los atributos podamos generar tantas relaciones como queramos. La construcción de Arquitecturas tecnológicas totalmente desacopladas, desde varios puntos de vista, simplifican todavía más los Stacks como tal, es decir, por ejemplo la conexión entre aplicaciones y/o módulos, la conexión de las aplicaciones con los datos y la própia conexión de la aplicación entre si (frontend & backend). Al final, el desacoplo, tiene que ser total para poder crear tantos layers como se necesiten.

Muchas veces la necesidad de tener un simple “user management” complica la contrucción de las aplicaciones, ya que debemos contemplar los permisos de los usuarios para el acceso tanto a las aplicaciones como a las informaciones que salen por pantalla. Un simple cambio de legislación, de estructura organizativa, etc… haría o podría hacer, que nuestra aplicación tenga que rrefacturizarse porque ha habido un mayor change. No es nuevo.

Para ello y cada vez más por suerte, la Teoría de Grafos, se puede aplicar en el modelo de desacoplo de los sistemas o módulos que forman la Solución, entendida como única visión. Es decir, podemos profundizar en lo que son los layer de la Solución, entendiendo que la primera capa sería lo que el usuario final visualiza (tangible, la aplicación), segido de la parte más back (el módulo o módulos que componen la aplicación) y los datos (uno o muchos modelos de datos y fuentes origen). ¿Cómo podemos realmente separar esto para hacerlo fácil?

No es tarea fácil pero, entendamos que cada nodo es una capa, para hacerlo todavía más fácil, en un lado tenemos la parte más tangible, un usuario con unas reglas de negocio y unos permisos de acceso y visualización; en otro nodo, tenemos otro nodo, por ahora imaginemos solo uno que es un dashboard analítico que muestra unos datos u otros según el tipo de Role y en otro nodo, la base de datos, que tras un proceso de normalización ya está como queríamos y solo debemos extraer los datos en un report que se mostraría, según Role, por el Dashboard anteriormente indicado. Por lo tanto tenemos tres nodos: usuarios + dashboard analítico + base de datos. Fácil.

Bien, la gracia de la aplicación de la Teoría de Grafos en una base de datos orientada a grafos es que podremos crear las relaciones y estructuras para Gobernalos a Todos, ya que podremos relaciones los permisos de usuarios con los módulos y con los datos, para que ese microservicio encargado de gestionar las conexiones y/o relaciones pueda aplicar en Realtime todas las reglas. ¿Imgináis lo que simplifica a nivel programación la lógica?. Básicamente estamos elevando a otro nivel lo que es la parte más complicada de negocio y la podemos cambiar según necesidades para que esta nueva Realidad se aplique en formato cascada en ese momento.

Soluciones como OrientDB o neo4j (interesante post al respecto) nos facilitan, y mucho, la aplicación de estas teorías. La imagen que precede el artículo, intenta explicar visualmente lo comentado, aunque continuaremos hablando en otros artículos al respecto y, para acabar, la última imagen que nos muestra auténticas ideas de olla…

Autor: Joakim Vivas

comments powered by Disqus