Modelos de datos NoSQL

A medida que las bases de datos NoSQL cobran mayor protagonismo, he observado a compañeros del área que se preguntan cómo diseñar las bases de datos no relacionales que, tal como describe la wikipedia, “No garantizan completamente atomicidad, consistencia, y durabilidad, y habitualmente escalan bien horizontalmente”. Es decir, el esquema puede variar dinámicamente (agregar campos y conceptos en tiempo de ejecución) y variar entre las distintas particiones de almacenamiento . Pero, pensar solamente en cómo se almacenan y cómo se distribuyen en particiones, es como ver una sola cara de la moneda, en este caso la cara de la moneda que se ve es la del dominio de infraestructura. Pues, el hecho de que los datos físicamente no estén fuertemente cohesionados, no implica que, en los otros dominios, los conceptos no lo estén y que su esquema carezca de estructura.

En este sentido, si analizamos los conceptos desde el dominio de negocio, los conceptos se relacionan entre si de manera directa o indirecta. Para ejemplificar mejor este tema, pensemos en una funcionalidad, por ejemplo: “vender libros”. Los conceptos como: cliente, inventario, venta, etc. cobran sentido dentro de la funcionalidad de manera directa, es decir: si no existiera el concepto cliente el concepto venta no existe, pasa lo mismo si no existiera el concepto inventario. Por otro lado, los conceptos de naturaleza mas abstracta como: reputación de escritores, índice de analfabetismo, etc. afectan a la funcionalidad porque tienen un efecto indirecto en el concepto ventas. En el primer caso, si la reputación de los autores de los libros aumenta, las ventas tienen una gran probabilidad de subir , y tiene el efecto inverso en sentido contrario. En el segundo ejemplo, si el índice de analfabetismo sube, la probabilidad de ventas de la librería baja, y sucede lo mismo en sentido contrario. Dicha causalidad entre conceptos es la que define la relación inherente que existe entre ellos, (Este tema formará parte de en otra entrada acerca de Open Linked – data 🙂 ).

Pero entonces, ¿Qué importancia tiene esta causalidad en las bases de datos NoSQL? Implica que al momento de modificar/agregar/quitar los campos o conceptos dinámicamente se deben tener en cuenta estas relaciones de causalidad entre conceptos (ojo que no se habla de un modelo entidad-relación en ningún momento).

ANTES DE EMPEZAR: Un meta-modelo es un modelo de un modelo, y el meta-modelado es el proceso de generación de dichos meta-modelos. Así, el meta-modelado es el análisis, la construcción y el desarrollo de los marcos, reglas, restricciones, modelos y teorías aplicables y útiles para modelar una clase predefinida de problemas. Como su nombre lo indica, este concepto aplica las nociones de meta y modelado en ingeniería de software e ingeniería de sistemas.

Propuesta

Para ejemplificar vamos a desglosar un concepto sencillo de “Person” o “Persona”: Por un lado, se mostrara el diseño bases de datos documentales y, por otro lado, para bases de datos de grafos. En ambos casos los tipos de modelos describirán:

Modelo y Meta-modelo conceptual: Permitirá entender la relación y la organización de los posibles conceptos a alto nivel describiéndolos en más de un dominio, por lo tanto, vamos a utilizar el punto de vista de Información de ArchiMate (Information Archimate Viewpoint).
Metamodelo lógico: Permite visualizar todos los campos susceptibles a ser utilizados en los conceptos. Para esto, vamos a utilizar un diagrama de clases de UML (UML Class diagram). A cada concepto le corresponde una clase.
Modelo y Meta-modelo físico: Este modelo extiende el meta-modelo lógico y en él se describen las distintas formas en las que un concepto o esquema puede ser almacenado físicamente. Esta visualización permite verificar los modelos/meta-modelos conceptual y lógico para, mas tarde, visualizar las bases de datos en funcionamiento. Para esto vamos a utilizar un diagrama de clases de UML (también puede ser un diagrama de objetos UML).

Modelo y meta-modelo conceptual:

A continuación vemos un modelo en 2 dimensiones. Por un lado, en la dimensión de negocio se describe el concepto Person o persona. Por otro lado, en la dimensión de aplicación, el concepto Person se desglosa en tres entidades: Person se compone de Identification, y se le agrega Address, es decir, una persona debe tener al menos una identificación y puede tener al menos una dirección.

Si nuestro modelo representa una base de datos documental. Agregamos al modelo conceptual el dominio de infraestructura, en el que se indican los tipos de documentos físicos que se van a crear, ademas, se indicara qué conceptos van a almacenar, como se puede ver a continuación:

El artefacto Person (ArchiMate Artifact) representa a un tipo de documento NoSql que internamente describe a los conceptos Person e Identification, paralelamente un artefacto Address almacenara sólo un concepto de su mismo nombre. Por lo tanto, el artefacto Person en JSON, tiene una estructura similar a la que se ve a continuación:

{
 "Nombre": "String",
 "FechaNacimiento": "Number",
 "Genero": "String",
 "address_id": "ref (Address)",
 "identification": ["identification_1", "identification_2"]
}

Cabe resaltar que con el modelo anterior no se quiere decir que existen solo dos documentos, lo que se muestra es una representación de los tipos de documentos que pueden existir en la base de datos. Si se desea ser más explicito con el diseño, se pueden agregar mas artefactos en el dominio de infraestructura, que puede servir para describir como escalar horizontalmente las bases de datos, a modo de ejemplo.

A continuación vemos el diseño completo. En él que se distinguen dos partes:

El dominio de aplicación se concebirá como meta-modelo conceptual de una base de datos documental.
Y el dominio de infraestructura como el Modelo Conceptual

En el caso de que de bases de datos de gráfos, el meta-modelo conceptual tiene la apariencia que se muestra a continuación. En el meta-modelo se observan las tres entidades descritas anteriormente, pero en este caso, las relaciones son de ida y vuelta entre entidades, es decir: Person se identifica con un Identification, un Identification identifica a un Person, un Person vive en un Address y un Address pertenece a una o varias Person. Este modelo es la base para luego construir los grafos.

De esta manera, el meta-modelo describe un mapa de todas las relaciones base sobre el que luego se construye el grafo físicamente. A continuación, agregamos un ejemplo de Modelo de grafos que permite validar el meta-modelo. Se heredan los conceptos del meta-modelo para probar si el modelo de grafos se ajusta a nuestras necesidades de representación.

Meta-modelo Lógico

A continuación, se describe el meta-modelo lógico para base de datos documental. Para cada concepto identificado en el meta-modelo conceptual, se describen las propiedades susceptibles a ser utilizadas, sus tipos ( cadenas, numéricos, etc), la cardinalidad entre clases. Las relaciones entre conceptos, dependen de las que se permitan dentro de un documento NoSQL.

Si se trata de una base de datos de grafos, al igual en en el el diagrama documental, describimos las posibles propiedades y sus tipos, en el meta-modelo lógico se respetan las relaciones de ida y vuelta del meta -modelo conceptual.

Se define un meta-modelo lógico y no como modelo lógico, porque en lugar de describir un futuro modelo lógico, se describe un patrón de como debe crecer y evolucionar una base de datos NoSQL. Es decir, sirve de guía para saber como relacionar un nuevo concepto, agregar correctamente una propiedad a un concepto adecuado y tener una referencia del tipo que debería tener. Por otro lado, nos ayuda a medir el impacto, cuando es necesario evolucionar el esquema.

Modelo y meta-modelo físico

El meta-modelo físico puede llegar a ser similar o el mismo que el modelo lógico, dependerá de si la notación de los campos y tipos de datos corresponden físicamente con algún motor de base de datos específico. El propósito del meta-modelo físico, es el mismo que el del meta-modelo lógico, es decir, describir un patrón de como debe crecer la base de datos. La utilización de un solo meta-modelo lógico/físico o separarlos en dos distintos, dependerá de las necesidades de visualización que tengan, para el ejemplo el meta-modelo es el mismo.

El modelo físico en cambio, tanto en la base de datos documental, como en la base de datos de grafos, heredaran los conceptos definidos en el meta-modelo. Este modelo puede ayudar a verificar el meta-modelo lógico físico y prever reglas de validación de datos.

Para el modelo documental, se describen las cases que representan los documentos, se pueden mostrar los conceptos anidados con clases anidadas. Los campos pueden variar entre clase y clase, pero siempre se ajustan al meta-modelo físico. Una regla de ejemplo, puede ser que por cada Identification que exista, ésta debe tener al menos una propiedad Number aunque no se pueda determinar el IdentificationType.

En el caso del modelo de grafos, cada clase representa un nodo del grafo y cada nodo heredara un concepto del meta-modelo de físico y respeta sus relaciones. Las propiedades de las clases nodo, pueden contener una, o varias, o todas las de las clases del meta-modelo físico. El siguiente modelo muestra lo descrito anteriormente, el ejemplo del grafo producido por el meta-modelo. Si se utiliza un diagrama de objetos de UML(UML object diagram) los objetos del diagrama son instancias de las clases del meta-modelo físico.

Conclusiones

En esta entrada hemos podido observar como los conceptos se relacionan entre los distintos dominios, la idea principal es mostrar una visión mas amplia que va mas allá de la implementación de los esquemas en motores de datos, la tecnología actual nos brinda una gran versatilidad en la manera en la que los datos se almacenan, buscan, y estructuran en un espacio físico cada vez mas eficiente, esta visión puede ser útil tanto si eres una gran empresa y tienes grandes volúmenes de datos por gobernar, o si eres una pequeña startup que esta busca patrones entre conceptos para luego aplicar IA, por citar algunos ejemplos.

Como reflexión final, es necesario no perder de vista que cada uno de los conceptos almacenados en cualquier motor de base de datos relaciona/no-relacional es mas que un registro o un fichero. C ada concepto tiene una relación con un dominio de información que esta vivo incluso para aquellos que carecen de conocimientos de ingeniería de software e informática.