Universidad Mayor de “San Simón”

Facultad de Ciencias y Tecnología

Diseño de Repositorios NoSQL con MongoDB

Elaborado por: Edwin Rojas Claros

Carrera: Ingeniería de Sistemas
Tutor: Ing. Edson Ariel Terceros Torrico
Fecha: Noviembre de 2018
Cochabamba – Bolivia
 ii

A mis padres, a mi esposa, mis

hijas Steffany, Kamila,
Antonella, a mis maestros,
compañeros, por todos los que
conocí en este camino y que
culmina con una meta más, a
Dios gracias. Gracias por tanta
paciencia.
 ÍNDICE DE CONTENIDO

RESUMEN 7

INTRODUCCIÓN 8

1 GENERALIDADES 9

1.1 ANTECEDENTES GENERALES 9

1.2 ANTECEDENTES ESPECÍFICOS 9

2 METODOLOGÍA 10

3 BASE DE DATOS A GRAN ESCALA (BIG DATA) 10

4 BASE DE DATOS NoSQL 11

4.1 NoSQL - NOT ONLY SQL” (NO SOLO SQL). 11

4.2 CARACTERÍSTICAS DE NoSQL 11

4.3 CARACTERÍSTICAS PRINCIPALES DE NoSQL 12

4.3.1 ANALÍTICAS: 12

4.3.2 MAPREDUCE. 13

4.3.3 ESCALABILIDAD 13

4.3.4 DISPONIBILIDAD 13

4.3.5 REDUNDANCIA 13

4.3.6 FLEXIBILIDAD 14

4.3.7 DESARROLLO AMPLIO DISTRIBUIDO (CLOUD COMPUTING) 14

4.4 ATOMICIDAD, CONSISTENCIA, AISLAMIENTO Y DURABILIDAD (ACID) VS

COHERENCIA EVENTUAL FLEXIBLE BÁSICAMENTE DISPONIBLE (BASE) 14

5 BASES DE DATOS ORIENTADAS A DOCUMENTOS 16

3
 4

6 MONGODB 16

6.1 ORIGEN DE MONGODB 17

6.2 MONGODB, BASE DE DATOS DE DOCUMENTOS 17

6.3 CARACTERÍSTICAS CLAVE DE MONGO DB 18

6.3.1 ALTO RENDIMIENTO 18

6.3.2 LENGUAJE DE CONSULTA ENRIQUECIDO 18

6.3.3 ALTA DISPONIBILIDAD 19

6.3.4 ESCALABILIDAD HORIZONTAL 19

6.4 MONGODB ESTRUCTURA Y MODELADO 20

6.5 ESTRUCTURA DEL MODELO 21

6.5.1 REFERENCIAS 21

6.5.2 DOCUMENTOS EMBEBIDOS 22

6.5.3 COLECCIONES 22

6.5.4 RELACIONES 23

A. RELACIONES 1 A 1 23

B. RELACIONES 1 A VARIOS 24

6.5.5 INCRUSTACIÓN DE DATOS 27

6.5.6 LA INCRUSTACIÓN 30

6.5.7 CUÁNDO NO SE DEBE INCRUSTAR 32

6.7 DATOS DE REFERENCIA 35

6.7.1 LAS CLAVES EXTERNAS 36

6.7.2 ESTABLECER REFERENCIAS 36

6.7.3 COLOCANDO LA RELACIÓN 36

 5

6.8 MODELOS DE DATOS HÍBRIDOS 38

7 CONCLUSIONES 40

8 REFERENCIAS BIBLIOGRÁFICAS 41
 6

ÍNDICE DE FIGURAS

Figura 1.- Sharding (Compartir los datos entre fragmentos). ........................................ 19

Figura 2.- Referencias entre Documentos .......................................................................... 21
Figura 3.- Modelo de datos Embebido ............................................................................... 22
Figura 4.- Colección de documentos ................................................................................. 22
Figura 5.- Modelo relacional varios a varios ...................................................................... 25
Figura 6.- Ej. Almacenamiento en una Base de Datos relacional .......................................... 27
 7

RESUMEN
En la actualidad y en el futuro, la cantidad de datos digitales que se genera el mundo se
ha Multiplicado de forma exponencial. Las redes sociales, los archivos de imagen,
videos, sonidos y el acceso cada vez más fácil a la Internet, por los distintos dispositivos
que disponen las personas, hacen que el volumen de tráfico y de datos que se generan
sea cada vez mayor. Y a través del tiempo con el surgimiento de las bases de datos
relacionales las empresas encontraron el aliado perfecto para cubrir sus necesidades de
almacenamiento, disponibilidad, copiado de seguridad y gestión de sus datos.
Pero debido a las tendencias actuales del uso masivo de Internet, este tipo de sistemas
comenzó a experimentar dificultades técnicas, en algunos casos bloqueantes, que
impiden el buen funcionamiento de los sistemas de algunas de las empresas más
importantes de Internet. Este tipo de datos que son masivamente generados reciben un
nombre: BigData, y un tipo de tecnología surgió para tratar de poner solución a muchos
de los problemas de los que adolecen los sistemas de almacenamiento tradicionales
(modelo relacional) cuando intentan manejar este tipo de datos masivos.
Esta tecnología emergente se conoce como bases de datos no relacionales o NoSQL
acrónimo de Not only SQL – No sólo SQL y que han llegado con la intención de hacer
frente a las bases de datos relacionales utilizadas por la mayoría de los usuarios.
En este sentido, se orienta la presente monografía, en la cual se expondrá una referencia
en el diseño de una base de datos NoSQL, analizando las características del Gestor de
bases de datos, específicamente MongoDb.
MongoDB es una base de datos de documentos de código abierto que ofrece alto
rendimiento, alta disponibilidad y escalado automático, MongoDB es la más
representativa de las bases de datos NoSQL. También podemos denominarla con el
término de base de datos documental, ya que almacenara documentos JSON y no
registros, como sucede en las tablas de las bases de datos relacionales.
Palabras clave: Base de datos, Repositorio, SQL, NoSQL, BigData., MongoDB, JSON,
ACID, BASE.
 8

INTRODUCCIÓN
El éxito de cada negocio se basa en su capacidad de utilizar, adaptarse a las tecnologías
emergentes, y en particular de software y datos. Las empresas quieren desarrollar
rápidamente nuevos productos y servicios digitales para impulsar la expansión de las
fuentes de ingresos, mejorar la experiencia del cliente. Para este cometido las empresas
adoptan diferentes estrategias, metodologías agiles, DevOps, micro servicios, servicios
en la nube, servicios móviles, inteligencia artificial.
A pesar de estas nuevas estrategias para hacer frente a las iniciativas de la tecnología,
la transformación y adaptación y el crecimiento exponencial de información, la
consolidación de las redes sociales utilizada por millones de usuarios, llevan a tener que
realizar modificaciones que faciliten la administración de los datos. Según (Schönberger,
pág. 19). A esto surgen las bases de datos no relacionales (NoSql), y entre los gestores
de datos emergentes como Cassandra, Redis entre otros, se eligió MongoDB, porque
respondió a estos retos mediante la creación de una base de tecnología que permite a
los equipos de desarrollo adaptarse a través de: 1. El modelo de datos de documentos,
2. Un diseño de sistemas distribuidos, 3. Una experiencia unificada, la libertad de ejecutar
en cualquier lugar.
Con estas capacidades, se puede construir una plataforma inteligente de datos
operativos, sustentado por MongoDB. con la finalidad de dejar de lado el modelo
relacional, pero Si venimos de un trasfondo “100% relacional”, nuestro primer instinto es
tratar de adaptar lo que sabemos a este nuevo modelo, pero así no solo perdemos sus
mejores virtudes, sino que podemos perjudicar el producto. En esta monografía, veremos
cómo identificar y realizar el modelado de una base de datos NoSQL con MongoDB,
aprovechando las características que este nos proporciona. Se presenta una alternativa
de modelado de datos con mongoDB, para los que tienen interés de adentrarse en este
gestor de base de datos en el desarrollo de sus aplicaciones. El diseño de datos deberá
pasar necesariamente por un análisis detallado de Modelo de datos conceptuales (MDL),
el Modelo de Datos Lógicos (LDM)y el Modelo de datos Físico (PDM). Este análisis de
diseño se pasará por alto en la presente monografía.
 9

1 GENERALIDADES
1.1 ANTECEDENTES GENERALES
No todas las aplicaciones necesitan almacenar y procesar datos de la misma manera, la
arquitectura de almacenamiento debería pensarse de forma acorde a las necesidades.
Si se pretende desarrollar una aplicación que requiera la lectura/escritura de millones de
datos y pueda dar servicio a millones de usuarios sin perder rendimiento (escalabilidad),
entonces debe plantearse el uso de una base de datos NoSQL. Pues, el término NoSQL
se refiere al procesamiento de información en bases de datos que intentan solventar las
limitaciones que el modelo relacional encuentra en entornos de almacenamiento masivo
de datos, y concretamente al momento de escalar, donde es necesario disponer de
servidores de alta performance y de balanceo de carga. (Soumendra, Madhu, & Harsha,
pág. 14). Una vez tomada la decisión de la implementación de una base de datos
NoSQL, se tiene entre los más importantes gestores los siguientes: redis, Casandra,
MongoDB, de los cuales centraremos la atención en MongoDB.

1.2 ANTECEDENTES ESPECÍFICOS

Como desarrolladores, es común que en alguna etapa de nuestra vida desarrollando
software, hemos encontrado conceptos de bases de datos, puesto que la información de
los sistemas, que desarrollamos necesitan ser almacenados en algún lugar para su
posterior consulta.
Los conceptos de bases de datos con los que estamos familiarizados son los relacionales
pues fue de los primeros modelos que se hizo popular por su forma de organizar, escribir
y consultar la información almacenada. Al usar bases de datos relacionales nos
encontramos familiarizados con SQL (Structured Query Language) y la forma de poder
usar este lenguaje para la definición de datos (DDL) y la consulta de estos mismos (DML)
en sistemas de gestión de bases de datos ó DBMS (Database Management System).
Las tablas, columnas, registros, restricciones, relaciones, consultas, procedimientos
almacenados, son términos que usamos para referirnos a los datos del sistema que se
desea manipular y mentalmente transformamos los datos al modelo relacional.
 10

Los desarrolladores en la actualidad ya tienen en mente otros conceptos y términos que

mapean sus datos a otros modelos, es por eso, que esta monografía servirá para todos
aquellos que quieren migrar de SQL a NoSQL, en específico a MongoDB, realizando una
comparación con el modelo relacional y los nuevos conceptos de una base de datos
NoSQL.

2 METODOLOGÍA
Para el presente trabajo se utilizarán los siguientes métodos de investigación:
 Método Bibliográfico, debido a que se realizará la lectura y compilación de
libros relacionados al tema de estudio.
 Método Analítico, debido a que se procederá a revisar y analizar
ordenadamente documentos relacionados al tema de estudio, para la
redacción del presente trabajo.

3 BASE DE DATOS A GRAN ESCALA (BIG DATA)

La definición de Big Data varía según las características de las empresas. Para unas
empresas prima el volumen, para otras la velocidad, para otras la variabilidad de las
fuentes. Las empresas con mucho volumen van a estar interesadas en capturar la
información, guardarla, actualizarla e incorporarla en sus procesos de negocio; pero hay
empresas que, aunque tengan mucho volumen, no necesitan almacenar, sino trabaja en
tiempo real y a gran velocidad. (Schönberger, 2013).
Una Base de datos a gran escala o también llamada “masiva”, permite el
almacenamiento y manipulación de un orden alcanzable a petabytes de cualquier tipo de
información diaria. El crecimiento exponencial de información es directamente aplicable
a estas bases de datos. Según (Soumendra, Madhu, & Harsha, pág. 34).
Por ejemplo, la consolidación de las redes sociales sumado a su utilización de forma
diaria y masiva por parte de sus millones de usuarios, llevan a tener que realizar
modificaciones que faciliten la administración de los datos. (Soumendra, Madhu, &
Harsha, pág. 15)
 11

4 BASE DE DATOS NoSQL

Las bases datos NoSQL, también conocidas como “No sólo SQL”, implican una amplia
clase de sistemas de gestión de datos o mecanismos para el almacenamiento y
recuperación de datos que no cumplen con el modelo relacional, por lo cual no usan SQL
como lenguaje de consulta. Las principales características a las que están orientadas
son: analíticas, map reduce, escalabilidad, disponibilidad, redundancia, flexibilidad.

4.1 NoSQL - NOT ONLY SQL” (NO SOLO SQL).

Las bases de datos NoSQL son sistemas de almacenamiento de información que no
cumplen con el esquema entidad-relación, es decir, con el conocido modelo relacional.
El término NoSQL, independientemente del concepto “Base de datos” es interpretado
comúnmente como “Not Only SQL” (no solo SQL). También se lo conoce como una
combinación de dos palabras: “No” y “SQL”, es decir que el término no posee un único
significado.

El creador del término “NoSQL” fue Carlo Strozzi, quién en 1998 Según (Strozzi, 2017)
lo utilizó para referirse a una base de datos específica, a la cual utilizaba como base de
estudio. Luego, el concepto NoSQL fue reintroducido por varios investigadores, entre los
más destacados se encuentran Eric Evans y Johan Oskarsson, ambos en 2009. Eric
Evans se refirió a NoSQL para referirse específicamente a bases de datos no
relacionales. Johan Oskarsson definió el término refiriéndose a la variedad de sistemas
de bases de datos distribuidas y no relacionales que evolucionan constantemente.
Según (Evans, 2009) .

4.2 CARACTERÍSTICAS DE NoSQL

Mientras las tradicionales bases de datos relacionales basan su funcionamiento en
tablas, joins y transacciones ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad),
las bases de datos NoSQL no imponen una estructura de datos en forma de tablas y
relaciones entre ellas (no imponen un esquema pre-fijado de tablas). Estas bases de
 12

datos no proveen ACID, con lo cual las actualizaciones son una de las características
más complejas del modelo. Ya que, por ejemplo, no es posible propagar de manera
transaccional las actualizaciones de múltiples nodos en todo el sistema.
La cuestión de escalabilidad enfocado a la escalabilidad horizontal, no solo aplicable
para sistemas NoSQL, sino también para Cloud Computing. Se añaden más recursos
(como, por ejemplo, puede ser un disco duro o añadir más máquinas) a un nodo particular
dentro de un sistema. Este concepto de escalabilidad horizontal se dirige hacia la alta
disponibilidad del hardware; en la mayoría de los casos, no es confiable, con lo cual, es
necesario ampliar recursos.
Además de la carencia de un esquema predeterminado, la principal característica de las
bases de datos NoSQL, es que están pensadas para manipular cantidades de
información que crecen de manera muy rápida y de cantidad exponencial. También
proveen diversos tipos de esquemas de representación de la información, como lo son,
el esquema orientado a documentos, clave/valor, grafos y columnas.
En NoSQL, generalmente los datos son recuperados de manera más rápida que en un
RDBMS. Sin embargo, las consultas que se pueden hacer son más limitadas y requieren
trasladar complejidad a la aplicación. Es decir, para aquellas aplicaciones que generan
informes empleando consultas complejas, NoSQL a priori no sería inmediatamente
adecuado.

4.3 CARACTERÍSTICAS PRINCIPALES DE NoSQL

4.3.1 ANALÍTICAS:
Muchas bases de datos NoSQL son muy adecuadas para la realización de consultas
analíticas. Los desarrolladores pueden utilizar los mismos lenguajes de consulta para
realizar consultas analíticas en vez de realizar consultas atómicas. Normalmente esto
será alguna variación de una consulta.
 13

4.3.2 MAPREDUCE.
Los términos Map Reduce intentan decir "agrupar por y seleccionar” al estilo “group by
/select” de SQL, aclarando esto último, para no confundir a las personas que están
acostumbradas al lenguaje SQL.

4.3.3 ESCALABILIDAD
Las Bases de datos NoSQL están diseñadas para escalar Horizontalmente. Es una de
las principales razones por las que se elige optar por una base de datos NoSQL. Por lo
general, con una base de datos relacional como SQL Server u Oracle, la escalabilidad
es lograda con la compra de servidores y de almacenamiento más grande y más rápido,
o con el empleo de especialistas para proporcionar un ajuste adicional. A diferencia de
las bases de datos relacionales, las bases de datos NoSQL están diseñadas para la
escalabilidad en forma transparente. En este aspecto, están preparadas para mantener
la misma velocidad de respuesta independientemente de la capacidad utilizada para el
almacenamiento.

4.3.4 DISPONIBILIDAD
La disponibilidad de un sistema es el resultado de los componentes requeridos para una
tarea específica. Las bases de datos NoSQL se construyen principalmente sobre la base
de alcanzar alta disponibilidad y escalabilidad, a través de la distribución sobre hardware
accesible o económico (commodity).

4.3.5 REDUNDANCIA
Las bases de datos NoSQL también están diseñadas para trabajar con datos replicados,
lo cual puede entenderse como tener redundancia en la información. Ahora bien, el
hecho de contar con redundancia de información no implica que sea una falla grave de
las bases de datos NoSQL, como sí podría serlo en las bases de datos relacionales (en
el caso que exista algún escenario en que se pueda presentar).
 14

4.3.6 FLEXIBILIDAD
Si bien los problemas de representación de datos son muy diferentes en bases de datos
NoSQL, hay una flexibilidad en cómo se almacenan los datos para no comprometer los
tiempos de ejecución y los tiempos de respuesta.

4.3.7 DESARROLLO AMPLIO DISTRIBUIDO (CLOUD COMPUTING)

El desarrollo de sistemas en forma distribuida está relacionado al concepto Cloud
Computing. Si bien las bases de datos NoSQL son independientes a la arquitectura de
procesamiento, se están utilizando en diferentes ambientes y hacia un foco específico,
como lo son: almacenamiento en clúster, servidores replicados o distribuidos,
refactorizaciones y migraciones de datos.
Respecto a cloud computing, existen algunos fundamentos a tener en cuenta al momento
de evaluar soluciones NoSQL en memoria:

 Escalabilidad Automatizada.
 Evitar la pérdida de datos.
 Asegurar alta performance.
 Mejorar la administración.
 Coste acorde a la necesidad.

4.4 ATOMICIDAD, CONSISTENCIA, AISLAMIENTO Y DURABILIDAD (ACID) VS

COHERENCIA EVENTUAL FLEXIBLE BÁSICAMENTE DISPONIBLE (BASE)
En lo que abarca fuera del alcance, no se analizan las características ACID ya que las
mismas no son garantizadas por las bases de datos que utilizan NoSQL. Si bien el
concepto ACID es meramente para bases de datos relacionales, debemos considerar
diversos conceptos asociados al mismo, pero para base de datos NoSQL, ya que siguen
en constante surgimiento y evolución.
 15

Existe un acrónimo análogo a ACID para NoSQL que prima disponibilidad frente a
consistencia. Dicho concepto es BASE (Basically Available, Soft state, Eventual
consistency).

 Basically Available (Disponibilidad Básica): El sistema responderá aún con

datos viejos.
 Soft State (Estado de Soft): El estado puede que no sea estable y puede ser
corregido.
 Eventually Consistency (Consistencia Eventual): Se garantiza que al cabo de
un tiempo el sistema quedará en un estado consistente, es decir, que
eventualmente se conseguirá un estado consistente.

La consistencia eventual es relativamente nueva, pero dicho concepto no lo es como

idea. Generalmente, BASE está asociado con las bases de datos NoSQL. Varios
servicios, como Google App Engine DataStore y Amazon S3, poseen consistencia
eventual. Según (Amazon, 2018).
Previamente a BASE, existe un teorema, el teorema CAP (Consistency, Availability,
Partition Tolerance). Dicho teorema no está enfocado específicamente a base de datos
NoSQL, sino a las características de garantías de almacenamiento en sistemas
distribuidos. No obstante, se debe mencionar, ya que son conceptos que luego se
utilizaron y derivaron al estudio de las garantías de almacenamiento de base de datos
NoSQL.
Las siglas significan:
 Consistency (Consistencia): Todos los nodos ven la misma información al
mismo tiempo.
 Availability (Disponibilidad): La garantía de que cada petición a un nodo
reciba una confirmación, fue o no resuelta satisfactoriamente.
 Partition Tolerance (Tolerancia a Fallos): Que el sistema continúa
funcionando a pesar de algunas pérdidas arbitrarias de información o fallos
parciales del sistema.
 16

5 BASES DE DATOS ORIENTADAS A DOCUMENTOS

Una base de datos de datos orientada a documentos es un programa diseñado para
almacenar, recuperar y gestionar información semiestructurada orientada a documentos.
(Ruano) .
Un documento encapsula información en un formato estándar (por ejemplo: XML, YAML,
JSON y BSON). Los documentos en una base de datos orientada a documentos son
similares a los registros de la base de datos relacionales, pero no requieren un esquema
estándar con las mismas secciones, huecos, partes o claves.

Por lo general, estos documentos son referenciados por una clave que los representa
unívocamente.
Además de la búsqueda por clave de documentos, estas Bases de Datos suelen ofrecer
una API o lenguaje de consultas que permite recuperar documentos en base a su
contenido.

Se denomina información semiestructurada a la información similar de una estructura

implícita, pero no tan regular como para poder ser gestionada y automatizada como la
información estructurada. (Salazar, Herrera, & Brenes, 2018).

6 MONGODB
MongoDB (de la palabra en inglés “humongous” que significa enorme,gigantesco) es un
sistema de base de datos NoSQL orientado a documentos, desarrollado bajo el concepto
de código abierto.
MongoDB forma parte de la nueva familia de sistemas de base de datos NoSQL. En vez
de guardar los datos en tablas como lo hacen las bases de datos relacionales, MongoDB
guarda estructuras de datos en documentos tipo JSON con un esquema dinámico
(MongoDB llama ese formato BSON), haciendo que la integración de los datos en ciertas
aplicaciones sea más fácil y rápida.
 17

MongoDB es un sistema de base de datos multiplataforma orientado a documentos, de

esquema libre, esto significa que cada entrada o registro tendrá un esquema de datos
diferente, con atributos o “columnas” que no tendrán que repetirse de un registro a otro.
Está escrito en C++, lo que confiere cierta cercanía a recursos de hardware de la
máquina, de modo que es bastante rápido a la hora de ejecutar sus tareas. Además, está
licenciado como GNUAGPL 3.0, de modo que se trata de un software de licencia libre.
Funciona ensistemas operativos Windows, Linux, OS X y Solaris.
MongoDB es un almacén de datos potente, flexible y escalable. Combina la habilidad de
escalar con muchas de las características más útiles de las bases de datos relacionales,
como las secundarias Índices, consultas de rango y ordenación.

6.1 ORIGEN DE MONGODB

El desarrollo de MongoDB fue trabajado con la empresa de software 10gen en 2007
cuando se estaba desarrollando una plataforma como servicio (PaaS) similar a Google
App Engine. Según (Oath Tech). En 2009 MongoDB fue lanzado como un producto
independiente y publicado bajo la licencia de código abierto AGPL.

Se ha puesto mucho esfuerzo en hacer que MongoDB sea fácil de comenzar y un placer
utilizar. MongoDB tiene un modelo de datos amigable para el desarrollador, una
configuración amigable para el administrador, opciones y API de lenguaje de
sentimientos naturales presentadas por los controladores y la base de datos, MongoDB
permitie programar en lugar de preocuparse sobre el almacenamiento de datos. Según:
(Kristina Chodorow, pág. 21).
MongoDB es una base de datos de documentos de código abierto que proporciona alto
rendimiento, alta disponibilidad y escalado.

6.2 MONGODB, BASE DE DATOS DE DOCUMENTOS

Un registro en MongoDB es un documento, que es una estructura de datos compuesta
por pares de campos y valores. Los documentos de MongoDB son similares a los objetos
 18

JSON. Los valores de los campos pueden incluir otros documentos, matrices y matrices
de documentos.

Las ventajas de utilizar documentos son:

 Los documentos (es decir, los objetos) corresponden a tipos de datos nativos en
muchos lenguajes de programación.
 Los documentos y matrices incrustados reducen la necesidad de uniones
costosas.
 El esquema dinámico soporta el polimorfismo fluido.

6.3 CARACTERÍSTICAS CLAVE DE MONGO DB

6.3.1 ALTO RENDIMIENTO

MongoDB proporciona una persistencia de datos de alto rendimiento. En particular:

 La compatibilidad con los modelos de datos integrados reduce la actividad de

Entrada y Salida en el sistema de base de datos.
 Los índices admiten consultas más rápidas y pueden incluir claves de documentos
y matrices incrustados.

6.3.2 LENGUAJE DE CONSULTA ENRIQUECIDO

MongoDB admite un rico lenguaje de consulta para admitir operaciones de lectura y
escritura (CRUD) , así como:

 Agregación de datos
 Búsqueda de textos y consultas geoespaciales .
 19

6.3.3 ALTA DISPONIBILIDAD

La facilidad de replicación de MongoDB, llamada conjunto de réplicas , proporciona:

 Failover automático.
 Redundancia de datos.

Un conjunto de réplicas es un grupo de servidores MongoDB que mantienen el mismo

conjunto de datos, proporcionando redundancia y aumentando la disponibilidad de datos.

6.3.4 ESCALABILIDAD HORIZONTAL

MongoDB proporciona escalabilidad horizontal como parte de su funcionalidad principal:

 Sharding distribuye datos a través de un grupo de máquinas.

 A partir de la versión 3.4, MongoDB admite la creación de zonas de datos basadas
en la clave de fragmento. En un grupo equilibrado, MongoDB dirige las lecturas y
escrituras cubiertas por una zona solo a aquellos fragmentos dentro de la zona.

Figura 1.- Sharding (Compartir los datos entre fragmentos).

Fuente.- (https://www.toptal.com)
 20

6.4 MONGODB ESTRUCTURA Y MODELADO

La estructura que utiliza MongoDB para almacenar información es correspondiente a la

del tipo de base de datos orientada a documentos. Esto quiere decir que cada registro o
unidad básica se la denomina documento y cada conjunto de documentos se los
denomina colección. Según (MongoDB, Inc.).
MongoDB provee el modelo JSON (JavaScript Object Notation) como formato para la
representación de información en documentos. JSON es utilizado en diversas
herramientas como CouchDB y por diversas compañías como Teradata.
MongoDB se basa sobre JSON, pero actualmente la información no se almacena
específicamente en dicho formato, sino en BSON (Binary JSON) debido a que BSON es
una representación serializada de los documentos JSON lo que permite utilizar
documentos embebidos, arreglos dentro de documentos y además realiza una extensión
de tipos de datos que no son parte de la especificación JSON como los “Date type” y
“BinData type”. Según (BSON, 2018).
Los documentos en MongoDB son un conjunto de par clave/valor, libre de esquemas.
Por ejemplo, un documento posible en Mongo podría ser el siguiente:

{ "firstname": "Peter",
"lastname": "Membrey",
"phone_numbers": [
"+852 1234 5678",
"+44 1234 565 555"
]
}

Como los documentos son libres de esquemas, MongoDB no requiere que en una lista
de documentos aparezcan siempre la misma cantidad de campos para un documento.
Esto quiere decir que en el ejemplo si no se conocería ningún teléfono de una persona,
directamente la lista “phone_numbers” no aparecería.
 21

6.5 ESTRUCTURA DEL MODELO

En MongoDB existen dos modelos de representación para las relaciones entre

documentos: referencias y documentos embebidos. La relación por referencia consiste
en que en los documentos existe un campo que identifica a otro documento que contiene
datos específicos, también se lo denominan modelos de datos normalizados por el hecho
de que con la referencia se obtendrá toda la información del documento.

La relación por documento embebido significa que podemos incluir uno o más
documentos dentro de un mismo documento, también se los denominan modelos de
datos de normalizados por el hecho de que se pueden almacenar más de un documento
dentro de un mismo documento sin realizar ninguna relación hacia otros documentos.
Según (MongoDB, Inc., 2018).

6.5.1 REFERENCIAS
En este ejemplo, los documentos “contact” el campo “user_id” incluye la referencia al
documento “user”.

Figura 2.- Referencias entre Documentos

Fuente: (MongoDB, Inc)
 22

6.5.2 DOCUMENTOS EMBEBIDOS

Figura 3.- Modelo de datos Embebido

Fuente: (MongoDB, Inc)
En este ejemplo, los documentos “contact” y “access” son documentos embebidos de un
documento particular.

6.5.3 COLECCIONES
Una colección en MongoDB es un contenedor de documentos, análogo a lo que es una
tabla en un RDBMS. Según (MongoDB, Inc)

Figura 4.- Colección de documentos

Fuente: (MongoDB, Inc)
 23

6.5.4 RELACIONES
Las relaciones en MongoDB se entienden como la información que se puede encontrar
asociada en un mismo documento (información embebida) o referenciada, cuestión que
se mencionó en la “Estructura de modelo”. Según (MongoDB, Inc, 2018).
En MongoDB existen relaciones 1 a 1 y relaciones 1 a N (Varios). Si bien se pueden
modelar relaciones N a N (Varios a Varios).

A. RELACIONES 1 A 1
Estas relaciones se utilizan cuando tenemos relacionada un conjunto de información que
corresponde a una entidad de datos. Dicha entidad de datos puede ser relacionada o
embebida Según (MongoDB, Inc). Es decir que podemos representar de dos maneras
relaciones 1 a 1, presentadas en los siguientes ejemplos:

{ _id: "joe",
name: "Joe Bookreader"
}

{ patron_id: "joe",
street: "123 Fake Street",
city: "Faketon",
state: "MA",
zip: "12345"
}

En este ejemplo (información relacionada) se muestra que para acceder al nombre que
se encuentra en el primer documento, se debe acceder a “patron_id” y luego acceder al
primer documento para acceder al nombre. La desventaja que tiene que se debe realizar
una consulta adicional para obtener una información que es propia de una misma
entidad.
{
_id: "joe",
name: "Joe Bookreader",
address:
 24

{
street: "123 Fake Street",
city: "Faketon",
state: "MA",
zip: "12345"
}
}

En este ejemplo (información embebida) la información que corresponde a una misma

entidad se encuentra en un mismo documento. Se puede obtener toda la información de
una misma entidad en una misma consulta.

B. RELACIONES 1 A VARIOS
Estas relaciones se utilizan cuando se relaciona un documento que posee referencias a
más de un documento. Se muestran los siguientes ejemplos que muestran la manera de
representar estos tipos de relaciones. Según (MongoDB, Inc)

{
_id: "joe",
name: "Joe Bookreader"
}
{
patron_id: "joe",
street: "123 Fake Street",
city: "Faketon",
state: "MA",
zip: "12345"
}
{
patron_id: "joe",
street: "1 Some Other Street",
city: "Boston",
state: "MA",
zip: "12345"
}
 25

Este ejemplo representa un modelo normalizado que los documentos “address”

contienen referencias al documento “patron”. En este caso en particular, necesitamos al
menos dos consultas para obtener todos los datos completos relacionados.
En el caso de documentos embebidos (desnormalizado), con una consulta podemos
obtener toda la información necesaria. El ejemplo quedaría de la siguiente manera:
{
_id: "joe",
name: "Joe Bookreader",
addresses: [
{
street: "123 Fake Street",
city: "Faketon",
state: "MA",
zip: "12345"
},
{
street: "1 Some Other Street",
city: "Boston",
state: "MA",
zip: "12345"
}
] }

C. RELACIONES DE VARIOS A VARIOS

En una base de datos relacional, las relaciones de varios a varios modelan con
frecuencia con tablas de unión, que simplemente unen registros de otras tablas.

Figura 5.- Modelo relacional varios a varios

Fuente: (MicrosoftDocs)
 26

Podría verse tentado a replicar lo mismo con documentos y producir un modelo de datos
que tenga un aspecto similar al siguiente.

Author documents:
{"id": "a1", "name": "Thomas Andersen" }
{"id": "a2", "name": "William Wakefield" }

Book documents:
{"id": "b1", "name": "Azure Cosmos DB 101" }
{"id": "b2", "name": "Azure Cosmos DB for RDBMS Users" }
{"id": "b3", "name": "Taking over the world one JSON doc at a time" }
{"id": "b4", "name": "Learn about Azure Cosmos DB" }
{"id": "b5", "name": "Deep Dive in to Azure Cosmos DB" }

Joining documents:
{"authorId": "a1", "bookId": "b1" }
{"authorId": "a2", "bookId": "b1" }
{"authorId": "a1", "bookId": "b2" }
{"authorId": "a1", "bookId": "b3" }

Esto funcionaría. Sin embargo, cargar un autor con sus libros o cargar un libro con su
autor siempre requeriría al menos dos consultas adicionales en la base de datos. Una
consulta para el documento de unión y, a continuación, otra consulta para capturar el
documento real que se está uniendo.
Si todo lo que hace esta tabla de unión es combinar dos datos, nos preguntamos por qué
no quitarla completamente.

Author documents:
{"id": "a1", "name": "Thomas Andersen", "books": ["b1, "b2", "b3"]}
{"id": "a2", "name": "William Wakefield", "books": ["b1", "b4"]}

Book documents:
{"id": "b1", "name": "Azure Cosmos DB 101", "authors": ["a1", "a2"]}
{"id": "b2", "name": "Azure Cosmos DB for RDBMS Users", "authors": ["a1"]}
{"id": "b3", "name": "Learn about Azure Cosmos DB", "authors": ["a1"]}
{"id": "b4", "name": "Deep Dive in to Azure Cosmos DB", "authors": ["a2"]}

Ahora, si tuviera un autor, sabría de inmediato qué libros ha escrito y, a la inversa, si

tuviera un documento del libro cargado sabría los identificadores de los autores. Esto
 27

ahorra la consulta intermedia de la tabla de unión, por lo que se reduce el número de

viajes de ida y vuelta al servidor que tiene que realizar la aplicación.

6.5.5 INCRUSTACIÓN DE DATOS

Al comenzar a modelar datos en un almacén de documentos, como MongoDB, tratamos

las entidades como documentos independientes representados en JSON.
Antes de adentrarnos demasiado, realizaremos algunos pasos y echar un vistazo a cómo
modelar algo en una base de datos relacional, un asunto con el que estamos
familiarizados. En el ejemplo siguiente se muestra los datos a almacenarse una persona
en una base de datos relacional.

Figura 6.- Ej. Almacenamiento en una Base de Datos relacional

Fuente: (MicrosoftDocs)

Al trabajar con bases de datos relacionales, hemos aprendido durante años a normalizar
constantemente.
 28

La normalización de los datos implica normalmente tomar una entidad, como una
persona, y dividirla en piezas de datos discretas. En el ejemplo anterior, una persona
puede tener varios registros de información de contacto, así como varios registros de
dirección. Podemos ir incluso un paso más allá y desglosar detalles de contacto
extrayendo aún más campos comunes, como un tipo. Al igual que ocurre con la dirección,
cada registro aquí tiene un tipo como doméstico o empresarial.

La premisa principal cuando se normalizan datos es la de evitar el almacenamiento de

datos redundantes en cada registro y, en su lugar, hacer referencia a los datos. En este
ejemplo, para leer a una persona, con toda su información de contacto y direcciones,
tendrá que utilizar CONEXIONES para agregar de forma eficaz los datos en tiempo de
ejecución.

SELECT p.FirstName, p.LastName, a.City, cd.Detail

FROM Person p
JOIN ContactDetail cd ON cd.PersonId = p.Id
JOIN ContactDetailType on cdt ON cdt.Id = cd.TypeId
JOIN Address a ON a.PersonId = p.Id

La actualización de una única persona con su información de contacto y direcciones

requiere operaciones de escritura en muchas tablas individuales.
 29

Ahora veamos cómo modelamos los mismos datos como una entidad independiente en
una base de datos de documentos.

{
"id": "1",
"firstName": "Thomas",
"lastName": "Andersen",
"addresses": [
{
"line1": "100 Some Street",
"line2": "Unit 1",
"city": "Seattle",
"state": "WA",
"zip": 98012
}
],
"contactDetails": [
{"email": "[email protected]"},
{"phone": "+1 555 555-5555", "extension":
5555}
]
}

Mediante el enfoque anterior, ahora hemos de normalizado el registro de la persona en

el que hemos incrustado toda la información relacionada con esta persona, como su
información de contacto y direcciones, en un único documento JSON. Además, puesto
que no estamos limitados a un esquema fijo, contamos con la flexibilidad para hacer
cosas como tener información de contacto de formas diferentes por completo.
Recuperar un registro de persona completa de la base de datos es ahora una única
operación de lectura frente a una colección única y para un documento único. La
actualización de un registro de una persona, con su información de contacto y
direcciones, es también una operación de escritura única frente a un documento único.
Mediante la de normalización de datos, es posible que la aplicación tenga que emitir
menos consultas y actualizaciones para completar operaciones frecuentes.
 30

6.5.6 LA INCRUSTACIÓN

Por lo general, use los modelos de datos de incrustación cuando:

 Existen relaciones de inclusión entre entidades.

 Existen relaciones de uno a algunos entre entidades.
 Existen datos incrustados que cambian con poca frecuencia.
 Existen datos incrustados que no crecerán sin límites.
 Existen datos incrustados que se integran en los datos en un documento.

Los modelos de datos de normalizados normalmente proporcionan un mejor rendimiento

de lectura.

De forma general, las operaciones con Join, (operación de manejo de datos que implica
tablas relacionadas entre sí), típicas de las bases de datos relacionales pueden resultar
no muy escalables, y puesto que éste es uno de los principales propósitos de MongoDB,
parece lógico no trabajar exactamente con Join.
A pesar de lo anterior, se debe buscar una forma de trabajar que proporcione una
funcionalidad parecida a los Joins, en tanto en cuanto necesitamos hacer consultas con
cierta complejidad. Una forma intuitiva de tratar este asunto es utilizar enlaces indirectos
dentro de la declaración de documentos, a modo de clave indirecta utilizada en bases de
datos relacionales. Según: (MicrosoftDocs)
El siguiente ejemplo muestra la base de datos de una cadena de tiendas, pertenecientes
a la colección tienda, que tienen asociados un identificador único, un nombre y la central
a la que pertenecen, en su caso. Primeramente, se muestra cómo se insertaría en la
base de datos, para continuar con una selección de información.

>db.tienda.insert({_id: ObjectId(“XXXX”), nombre: ‘Gran Plaza’});

>db.tienda.insert({_id: ObjectId(“YYYY”), nombre: ‘Dos Hermanas’, central: ObjectId(“XXXX”)});
>db.tienda.insert({_id: ObjectId(“ZZZZ”), nombre: ‘Carlos V’, central: ObjectId(“XXXX)});
 31

En estos ejemplos se relacionó las tiendas de Carlos V, y Dos Hermanas con una sede
central de la cual dependen: Gran Plaza.
Una rápida consulta nos daría las tiendas que dependen de Gran Plaza:

>db.tienda.find({central: ObjectId(“Gran Plaza”)});

El resultado de lo anterior sería la aparición por pantalla de los documentos con nombre
Dos Hermanas, y CarlosV.
Por supuesto, la potencialidad de esta función se incrementa con el uso de arrays, siendo
capaces entonces de crear dependencias múltiples:

>db.tienda.insert({_id: ObjectId(“HHHH”, nombre: ‘Avd Ciencias’, central: [ObjectId: (“XXXX”),

ObjectId(“ZZZZ”)]});

Se Puede observar que la nueva tienda creada, Avd Ciencias tiene dos dependencias,
una con Carlos V y otra con Gran Plaza. Esto se ha conseguido asociando el iD de las
dos tiendas, a la central de la que depende la recientemente creada.
De la misma forma, hay otras acciones que otorgan mayor potencial a MongoDB, como
es el anidamiento de documentos. En MongoDB se puede trabajar con documentos
embebidos, facilitando la tarea de tratar con los datos en algunos casos específicos:

>db.tienda.insert({_id: ObjectId(“AAAA”), nombre: ‘Capuchinos’, servicios: {frescos: ‘Abart’,

congelados: ‘Sisco’,
pedidos: ObjectId(“XXXX”)}});

Se utilizó el documento servicios como parte del documento tienda. El documento

servicios contiene los proveedores asociados a la tipología de productos que pueden
encontrarse en la tienda, como pueden ser la gama de productos frescos, congelados,
dietéticos, o de ocio. Para hacer una consulta en la que aparezcan documentos
embebidos, la solución pasa por utilizar la siguiente nomenclatura:
 32

>db.tienda.find({‘servicios.frescos’: ‘Abart’})

Este último comando encontrará las tiendas que tienen como proveedor de servicios de
productos frescos aquel con nombre Abart.

6.5.7 CUÁNDO NO SE DEBE INCRUSTAR

{
"id": "1",
"name": "What's new in the coolest Cloud",
"summary": "A blog post by someone real famous",
"comments": [
{"id": 1, "author": "anon", "comment": "something useful, I'm sure"},
{"id": 2, "author": "bob", "comment": "wisdom from the interwebs"},
…
{"id": 100001, "author": "jane", "comment": "and on we go ..."},
…
{"id": 1000000001, "author": "angry", "comment": "blah angry blah angry"},
…
{"id": ∞ + 1, "author": "bored", "comment": "oh man, will this ever end?"},
]
}

Puesto que la regla general en una base de datos de documentos es de normalizarlo

todo e incrustar todos los datos en un único documento, es posible que se produzcan
situaciones que se deben evitar.

El problema con este ejemplo es que la matriz de comentarios no está limitada, lo que
significa que no hay ningún límite (práctico) para el número de comentarios que puede
tener cualquier publicación única. Esto será un problema, ya que el tamaño del
documento puede aumentar notablemente.

Puesto que el tamaño del documento aumenta la capacidad de transmisión de los datos
a través de la conexión, así como la lectura y actualización del documento, a escala, se
producirá un impacto en ellos.
 33

En este caso sería mejor tener en cuenta el siguiente modelo. Según: (MicrosoftDocs).

"id": "1",
"name": "What's new in the coolest Cloud",
"summary": "A blog post by someone real famous",
"recentComments": [
{"id": 1, "author": "anon", "comment": "something
useful, I'm sure"},
{"id": 2, "author": "bob", "comment": "wisdom from
the interwebs"},
{"id": 3, "author": "jane", "comment": "....."}
]
}

Comment documents:
{
"postId": "1"
"comments": [
{"id": 4, "author": "anon", "comment": "more
goodness"},
{"id": 5, "author": "bob", "comment": "tails from the
field"},
...
{"id": 99, "author": "angry", "comment": "blah angry
blah angry"}
]
},
{
"postId": "1"
"comments": [
{"id": 100, "author": "anon", "comment": "yet more"},
...
{"id": 199, "author": "bored", "comment": "will this
ever end?"}
]
}

Este modelo tiene los tres últimos comentarios insertados en la propia publicación, que
es una matriz con un límite fijo esta vez. Los demás comentarios se agrupan en lotes
de 100 comentarios y se almacenan en documentos independientes. El tamaño del lote
se ha seleccionado como 100, puesto que nuestra aplicación ficticia permite al usuario
cargar 100 comentarios a la vez.
 34

Otro caso en el que la incrustación de datos no es una buena opción es cuando los datos
incrustados se utilizan a menudo en documentos y cambian con frecuencia.

{
"id": "1",
"firstName": "Thomas",
"lastName": "Andersen",
"holdings": [
{
"numberHeld": 100,
"stock": { "symbol": "zaza", "open": 1, "high": 2, "low": 0.5 }
},
{
"numberHeld": 50,
"stock": { "symbol": "xcxc", "open": 89, "high": 93.24, "low": 88.87 }
}
]
}

Esto podría representar la cartera de acciones de una persona. Se eligio incrustar la

información de las acciones en cada documento de la cartera. En un entorno donde los
datos relacionados cambian con frecuencia, como una aplicación de comercio bursátil,
la incrustación de datos que cambian con frecuencia significará que está actualizando
constantemente cada documento de la cartera cada vez que se negocia una acción.
Con un modelo de datos como el anterior, tendríamos que actualizar miles de
documentos de cartera varias veces al día.

Por lo tanto, la incrustación de datos funciona bien en muchos casos, pero está claro que
hay escenarios en los que la de normalización de los datos provocará más problemas
que ventajas.
 35

6.7 DATOS DE REFERENCIA

Las bases de datos relacionales no son el único lugar donde puede crear relaciones entre
entidades. En una base de datos de documentos puede tener información en un
documento que realmente se relacione con los datos en otros documentos.
En el siguiente JSON se adopto por utilizar el ejemplo de una cartera de acciones
anteriores, pero esta vez hacemos referencia al artículo comercial en la cartera en lugar
de incrustarlo. De esa forma, cuando el artículo comercial cambia frecuentemente a lo
largo del día, el único documento que tiene que actualizarse es el documento de acciones
único. Person document:
{
"id": "1",
"firstName": "Thomas",
"lastName": "Andersen",
"holdings": [
{ "numberHeld": 100, "stockId": 1},
{ "numberHeld": 50, "stockId": 2}
]
}

Stock documents:
{
"id": "1",
"symbol": "zaza",
"open": 1,
"high": 2,
"low": 0.5,
"vol": 11970000,
"mkt-cap": 42000000,
"pe": 5.89
},
{
"id": "2",
"symbol": "xcxc",
"open": 89,
"high": 93.24,
"low": 88.87,
"vol": 2970200,
"mkt-cap": 1005000,
"pe": 75.82
}

Sin embargo, una desventaja de este enfoque inmediato es si la aplicación es necesaria

para mostrar información sobre cada acción que se mantiene al mostrar la cartera de
una persona; en este caso necesitaría realizar varios viajes a la base de datos para
 36

cargar la información de cada documento de acciones. Aquí se tomó una decisión de

mejorar la eficacia de las operaciones de escritura, que se producen con frecuencia a lo
largo del día, pero a su vez, se comprometen las operaciones de lectura que
potencialmente tienen un menor impacto en el rendimiento de este sistema en particular.
Los modelos de datos normalizados pueden requerir varios viajes de ida y vuelta al
servidor.

6.7.1 LAS CLAVES EXTERNAS

Puesto que actualmente no hay ningún concepto de restricción, clave externa o de otra
índole, las relaciones entre documentos que tienen en los documentos son efectivamente
"puntos débiles" y la base de datos no los comprobará. Si desea asegurarse de que los
datos a los que hace referencia un documento existen realmente, debe hacerlo en la
aplicación o mediante el uso de desencadenadores de servidor o procedimientos
almacenados.

6.7.2 ESTABLECER REFERENCIAS

Por lo general, se deben utilizar modelos de datos normalizados cuando:

 Se realiza una representación de relaciones de uno a varios.

 Se realiza una representación de las relaciones de muchos a muchos.
 Los datos relacionados cambian con frecuencia.
 Puede cancelarse el límite de los datos de referencia.

Normalmente, la normalización proporciona un mejor rendimiento de escritura.

6.7.3 COLOCANDO LA RELACIÓN

El crecimiento de la relación ayudará a determinar en qué documento almacenar la
referencia.
Observando el JSON siguiente que sirve como modelo para los publicadores y los libros.
 37

Publisher document:
{
"id": "mspress",
"name": "Microsoft Press",
"books": [ 1, 2, 3, ..., 100, ..., 1000]
}

Book documents:
{"id": "1", "name": "Azure Cosmos DB 101" }
{"id": "2", "name": "Azure Cosmos DB for RDBMS Users" }
{"id": "3", "name": "Taking over the world one JSON doc at a time" }
...
{"id": "100", "name": "Learn about Azure Cosmos DB" }
...
{"id": "1000", "name": "Deep Dive in to Azure Cosmos DB" }

Si el número de libros por publicador es reducido con un crecimiento limitado, almacenar

la referencia del libro dentro del documento del publicador puede ser útil. Sin embargo,
si el número de libros por publicador no tiene un límite, este modelo de datos llevaría
provocaría matrices crecientes y mutables como ocurre en el documento de publicador
de ejemplo anterior.

Publisher document:
{
"id": "mspress",
"name": "Microsoft Press"
}

Book documents:
{"id": "1","name": "Azure Cosmos DB 101", "pub-id": "mspress"}
{"id": "2","name": "Azure Cosmos DB for RDBMS Users", "pub-id": "mspress"}
{"id": "3","name": "Taking over the world one JSON doc at a time"}
...
{"id": "100","name": "Learn about Azure Cosmos DB", "pub-id": "mspress"}
...
{"id": "1000","name": "Deep Dive in to Azure Cosmos DB", "pub-id": "mspress"}

Cambiar las cosas un poco provocaría la creación de un modelo que seguiría

representando los mismos datos, pero que evitaría esas grandes colecciones mutables.
En el ejemplo anterior, hemos eliminado la colección ilimitada en el documento del
publicador. En su lugar, solo tenemos una referencia al publicador en cada documento
del libro.
 38

6.8 MODELOS DE DATOS HÍBRIDOS

En función de las cargas de trabajo y los diseños de uso específico de la aplicación, es
posible que existan casos en los que mezclar los datos de referencia e incrustados tenga
sentido y puede generar una lógica de aplicación más simple con menos viajes de ida y
vuelta de servidor a la vez que se sigue manteniendo un buen nivel de rendimiento.

Author documents:
{
"id": "a1",
"firstName": "Thomas",
"lastName": "Andersen",
"countOfBooks": 3,
"books": ["b1", "b2", "b3"],
"images": [
{"thumbnail": "http://....png"}
{"profile": "http://....png"}
{"large": "http://....png"}
]
},
{
"id": "a2",
"firstName": "William",
"lastName": "Wakefield",
"countOfBooks": 1,
"books": ["b1"],
"images": [
{"thumbnail": "http://....png"}
]
}

Book documents:
{
"id": "b1",
"name": "Azure Cosmos DB 101",
"authors": [
{"id": "a1", "name": "Thomas Andersen",
"thumbnailUrl": "http://....png"},
{"id": "a2", "name": "William Wakefield",
"thumbnailUrl": "http://....png"}
]
}, {
"id": "b2",
"name": "Azure Cosmos DB for
RDBMS Users",
"authors": [
{"id": "a1", "name": "Thomas
Andersen", "thumbnailUrl":
"http://....png"},
]
}
 39

Aquí hemos seguido principalmente el modelo de incrustación, donde los datos de otras
entidades se incrustan en el documento de nivel superior, pero se establece la referencia
en otros datos.
Si se observa el documento del libro, vemos algunos campos interesantes cuando nos
centramos en la matriz de autores. Hay un campo id que es el campo que se utiliza para
volver a hacer referencia a un documento de autor, una práctica estándar en un modelo
normalizado, pero también tenemos name y thumbnailUrl. Se pudo haber parado en id y
dejar la aplicación para obtener información adicional que necesita a partir del documento
de autor correspondiente mediante el "vínculo", pero como nuestra aplicación muestra el
nombre del autor y una imagen en miniatura con cada libro mostrado, puede ahorrar un
viaje de ida y vuelta al servidor por libro en una lista mediante la normalización
de algunos datos del autor.
Por supuesto, si cambia el nombre del autor o desean actualizar sus fotos, tendríamos
que realizar una actualización de cada libro publicado, pero para nuestra aplicación, que
se basa en la suposición de que los autores no cambian sus nombres muy a menudo, se
trata de una decisión de diseño aceptable.
En el ejemplo hay valores de adiciones calculadas previamente para ahorrar un
procesamiento costoso en una operación de lectura. En el ejemplo, algunos de los datos
incrustados en el documento del autor son datos que se calculan en tiempo de
ejecución. Cada vez que se publica un nuevo libro, se crea un documento de libro y el
campo countOfBooks se establece en un valor calculado en función del número de
documentos de libro que existen para un autor concreto. Esta optimización sería
adecuada en sistemas en los que se realizan muchas operaciones de lectura, donde
podemos permitirnos hacer cálculos en las escrituras para optimizarlas.
La capacidad de tener un modelo con campos calculados previamente es posible porque
MongoDB admite transacciones de varios documentos. Muchos almacenes NoSQL no
pueden realizar transacciones en documentos y, por lo tanto, recomiendan las decisiones
de diseño, por ejemplo, "siempre incrustar todo", debido a esa limitación. Según:
(MicrosoftDocs).
 40

7 CONCLUSIONES
Las bases datos NoSQL, también conocidas como “No sólo SQL”, implican una amplia
clase de sistemas de gestión de datos o mecanismos para el almacenamiento y
recuperación de datos que no cumplen con el modelo relacional, por lo cual no usan SQL
como lenguaje de consulta. Las principales características a las que están orientadas
son: analíticas, escalabilidad, disponibilidad, flexibilidad.

Las bases datos NoSQL han sido diseñadas con la finalidad de almacenar grandes
cantidades de datos.

Una base de datos de datos orientada a documentos como MongoDB es un almacén de

datos de bajo costo, dinámico, potente, flexible y escalable, el cual lo convierte en una
opción para la implementación en un sistema a desarrollar, ya que permite el manejo de
grandes volúmenes de información, así como la habilidad de escalar, disponibilidad de
datos, y posee con muchas de las características de las bases de datos relacionales, las
cuales pueden ser aprovechadas.

Se presenta una alternativa de modelado de datos, para la ser implementada en el diseño

de base de datos con MongoDB, el cual proporciona una guía de referencia para aquellos
que desean utilizar esta herramienta en la construcción de sus sistemas.
 41

8 REFERENCIAS BIBLIOGRÁFICAS

Amazon. (Octubre de 2018). Amazon S3. Recuperado el Octubre de 2018, de Amazon:

http://aws.amazon.com/es/s3/
BSON. (Octubre de 2018). bsonspec.org/. Recuperado el Octubre de 2018, de
bsonspec.org/: http://bsonspec.org/
Evans, E. (10 de 2009). “Erics Evans’ Web Log”. Recuperado el Octubre de 2018, de
“NoSQL: What’s in a name?”: http://blog.sym-
link.com/2009/10/30/nosql_whats_in_a_name.html
Kristina Chodorow, M. D. (2010). MongoDB: The Definitive Guide. O'Reilly Media.
MicrosoftDocs. (2018). Modeling data. Recuperado el Octubre de 2018, de
https://docs.microsoft.com: https://docs.microsoft.com/es-es/azure/cosmos-
db/modeling-data
MongoDB, Inc. (2018). Data model design. Recuperado el Octubre de 2018, de
https://docs.mongodb.com: https://docs.mongodb.com/manual/core/data-model-
design/
MongoDB, Inc. (Octubre de 2018). Databases and collections. Recuperado el Octubre
de 2018, de https://docs.mongodb.com:
https://docs.mongodb.com/manual/core/databases-and-collections/
MongoDB, Inc. (2018). Databases and collections. Recuperado el Octubre de 2018, de
https://docs.mongodb.com: https://docs.mongodb.com/manual/core/databases-
and-collections/
MongoDB, Inc. (2018). Embedded data models. Recuperado el Octubre de 2018, de
https://docs.mongodb.com: https://docs.mongodb.com/manual/core/data-model-
design/#embedded-data-models
MongoDB, Inc. (2018). Model embedded one to many relationships between documents:
data modeling example one to many. Recuperado el Octubre de 2018, de
https://docs.mongodb.com: https://docs.mongodb.com/manual/tutorial/model-
embedded-one-to-many-relationships-between-documents/#data-modeling-
example-one-to-many
 42

MongoDB, Inc. (2018). Model embedded one to one relationships between document.
Recuperado el Octubre de 2018, de https://docs.mongodb.com:
https://docs.mongodb.com/manual/tutorial/model-embedded-one-to-one-
relationships-between-document
MongoDB, Inc. (Octubre de 2018). Model embedded one to one relationships between
documents. Recuperado el Octubre de 2018, de https://docs.mongodb.com:
https://docs.mongodb.com/manual/tutorial/model-embedded-one-to-one-
relationships-between-documents/
MongoDB, Inc. (Octubre de 2018). Data model design. Recuperado el Octubre de 2018,
de docs.mongodb.com: https://docs.mongodb.com/manual/core/data-model-
design/
Oath Tech. (2013 - 2018). 10gen. Recuperado el Octubre de 2018, de techcrunch.com:
https://techcrunch.com/tag/10gen/
Ruano, F. J. (2018). Analisis y desarrollo de MongoDB y Redis en Java. Ruano.
Salazar, Y., Herrera, D., & Brenes, R. (Octubre de 2018). mongodb. Recuperado el
Octubre de 2018, de prezi.com “MongoDB”:
https://prezi.com/izjqg7o_aqqn/mongodb/
Schönberger, V. M. (2013). Big data : la revolución de los datos masivos. Turner.
Soumendra, M., Madhu, J., & Harsha, S. (2013). Big Data Imperatives: Enterprise ‘Big
Data’ Warehouse, ‘BI’ Implementations and Analytics. Apress.
Strozzi, C. (2017). NoSQL: a Non-SQL RDBMS. Recuperado el Octubre de 2018, de
www.strozzi.it: http://www.strozzi.it/cgi-
bin/CSA/tw7/I/en_US/nosql/Home%20Page