En los días actuales se ha incrementado el uso de las bases de datos no relacionales, en correspondencia con el contexto en que son usadas. Sin embargo, al tornarse compleja la estructura de los datos es posible incurrir en el error de estructurar la base de datos siguiendo los antiguos patrones relacionales que se utilizan en gestores como MySQL y PostgreSQL. En esta ocasión plasmaremos una opción para construir bases de datos No SQL en aplicaciones complejas. Tal es el ejemplo de base de datos como MongoDB, CouchDB y Firebase.  En este momento tomaremos como ejemplo, Firebase. Comenzando que los datos son almacenados en un documento JSON, ordenando con la forma atributo – valor. Observando cómo se mantienen las relaciones en las bases de datos SQL, tenemos en cuenta las llaves primarias, las foráneas y las relaciones que son creadas cuando se crean tablas con la forma de M2M y utilizando las instrucciones JOIN podemos navegar entre las consultas que deseamos, pero en este caso, prescindiremos de todo ello. Entonces ¿cómo se pudieran representar? En un primer acercamiento, en el caso de una relación de muchos a muchos(M2M), se pudieran tener objetos anidados.

 

nested

 

Pero esto lleva a la complejidad de recuperar los datos puesto que los duplica, sobre todo cuando existe multiplicidad de pertenencia (en el ejemplo que un usuario pertenezca a varios grupos), se complejiza saber las relaciones para un objeto específico. Solucionar este inconveniente se logra con aplicar principios para modelar esquemas NOSQL.

Denormalizar

En este caso, implica almacenar los objetos lo más simple posible, donde cada objeto sea raíz en si mismo.

 

flatten

 

Relaciones O2M o listas estáticas

Para el caso de las relaciones de uno a muchos, en ocasiones son registros únicos, lo que lleva a incluirse dentro del propio objeto como una lista de registros. Por ejemplo, situemos la cantidad de veces que un usuario se autentica en el sistema.

o2m

 

Relaciones M2M

En este caso, es sabida que la opción de anidamiento está descartada por lo que la recomendación es mantener un índice que sobre un tipo de objeto de cómo está relacionado. Por ejemplo, en el grupo, cuales son los usuarios miembros.

 

Siguiendo estas prácticas es posible mantener aplicaciones complejas, cuyos datos sean almacenados en estructuras que siguen la forma JSON. Mantener actualizado cada objeto se tornan operaciones de alto costo.

Fuentes:

https://www.airpair.com/firebase/posts/structuring-your-firebase-data

https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/

 

 

Anuncios