Propuesta de Notación Gráfica Para...
96
Transcript of Propuesta de Notación Gráfica Para...
Propuesta de Notación Gráfica Para elModelo Orientado a Documentos de
MongoDB
Juan Pablo Poveda Galvis
Director:Roberto Albeiro Pava Díaz
Trabajo de grado para optar por el título deIngeniero Electrónico
Bogotá, Colombia2015
Licencia
CC BY-SA 4.0
A Dios por guiarme durante toda mi vida.A mi familia que siempre me apoyó y valoró mi preparación a pesar de las adversidades.
Agradecimiento
Al ingeniero Roberto Pava, mi director, quién siempre estuvo pendiente y me brindótodas las herramientas y la ayuda para llevar a cabo este proyecto.
Contenidos
CAPÍTULO 1—PRELIMINARES
1.1 INTRODUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 PLANTEAMIENTO EL PROBLEMA . . . . . . . . . . . . . . . . . . . 3
1.3 JUSTIFICACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 METODOLOGÍA . . . . . . . . . . . . . . . . . . . . . . . . . 5
CAPÍTULO 2—CONOCIENDO MONGODB
2.1 BASES DE DATOS NOSQL . . . . . . . . . . . . . . . . . . . . . . 7
2.2 INTRODUCCIÓN A MONGODB . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Componentes de una base de datos de MongoDB . . . . . . . . . . . . . 11
2.3 ACID, BASE Y CAP. . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 ACID (Atomicity, Consistency, Isolation, Durability) . . . . . . . . . . . . 12
2.3.2 BASE (Basically Available, Soft-state, Eventually-consistent) . . . . . . . . . 12
2.3.3 Teorema CAP . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 JSON – JAVASCRIPT OBJECT NOTATION . . . . . . . . . . . . . . . . 13
2.4.1 Valores . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.2 Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.3 Arreglos . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.4 Números y cadenas de caracteres . . . . . . . . . . . . . . . . . . 15
2.5 BSON – BINARY JSON . . . . . . . . . . . . . . . . . . . . . . 15
2.6 ESQUEMA DINÁMICO . . . . . . . . . . . . . . . . . . . . . . . 17
2.7 CRECIMIENTO Y RECOLOCACIÓN DE LOS DOCUMENTOS . . . . . . . . . . 17
2.8 REPLICACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8.1 Conmutación automática en caso de error . . . . . . . . . . . . . . . 19
2.8.2 Preferencias de lectura . . . . . . . . . . . . . . . . . . . . . . 19
I
2.9 DISPONIBILIDAD . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9.1 Árbitros . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.9.2 Fragmentación . . . . . . . . . . . . . . . . . . . . . . . . 21
2.9.3 Estructura general de un clúster . . . . . . . . . . . . . . . . . . . 21
CAPÍTULO 3—MODELOS DE DATOS
3.1 MODELOS PARA RELACIONES 1:N . . . . . . . . . . . . . . . . . . . 24
3.1.1 Modelando Uno-a-Pocos . . . . . . . . . . . . . . . . . . . . . 24
3.1.2 Modelando Uno-a-Muchos . . . . . . . . . . . . . . . . . . . . 25
3.1.3 Modelando Uno-a-Muchísimos . . . . . . . . . . . . . . . . . . . 26
3.1.4 Referenciación de doble vía . . . . . . . . . . . . . . . . . . . . 27
3.1.5 Desnormalización con relaciones Uno-a-Muchos . . . . . . . . . . . . . 29
3.1.6 Desnormalización con relaciones Uno-a-Muchísimos . . . . . . . . . . . 31
3.2 CONSIDERACIONES PARA MODELAR RELACIONES 1:N . . . . . . . . . . . 33
3.3 MODELOS CON ESTRUCTURAS DE ÁRBOL . . . . . . . . . . . . . . . . 33
3.3.1 Estructura de árbol con referencias parentales . . . . . . . . . . . . . . 34
3.3.2 Estructura de árbol con referencias hijas . . . . . . . . . . . . . . . . 35
3.3.3 Estructura de árbol con arreglo de ancestros . . . . . . . . . . . . . . . 36
3.3.4 Estructura de árbol con rutas visibles . . . . . . . . . . . . . . . . . 37
3.3.5 Estructura de árbol con conjuntos anidados . . . . . . . . . . . . . . . 38
3.4 CONSIDERACIONES PARA LOS MODELOS EN ÁRBOL . . . . . . . . . . . . 39
CAPÍTULO 4—DIAGRAMAS ORIENTADOS A DOCUMENTOS
4.1 CONVENCIÓN DE NOMBRES . . . . . . . . . . . . . . . . . . . . . 42
4.2 COLECCIONES . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 DOCUMENTOS . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 CAMPOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.1 Disponibilidad . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.2 Indexación . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.3 Tipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.4 Arreglo . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.5 Valor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.6 Restricción . . . . . . . . . . . . . . . . . . . . . . . . . . 47
II
4.5 CONJUNTOS DE CAMPOS . . . . . . . . . . . . . . . . . . . . . . 47
4.6 DOCUMENTOS EMBEBIDOS . . . . . . . . . . . . . . . . . . . . . 47
4.7 RELACIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.7.1 Asociación . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.7.2 Composición . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.8 RESTRICCIONES . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.8.1 Restricciones inter-relación . . . . . . . . . . . . . . . . . . . . 53
4.9 NOTAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
CAPÍTULO 5—EJEMPLOS DE USO
5.1 ESQUEMAS SENCILLOS . . . . . . . . . . . . . . . . . . . . . . . 59
5.1.1 Modelo Uno-a-Pocos . . . . . . . . . . . . . . . . . . . . . . 60
5.1.2 Modelos Uno-a-Muchos y Uno-a-Muchísimos . . . . . . . . . . . . . . 60
5.1.3 Refereciación de doble vía. . . . . . . . . . . . . . . . . . . . . 61
5.2 LIBRERÍA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 REDES SOCIALES . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.4 UNIVERSIDAD . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5 MUSEO DE ARTE . . . . . . . . . . . . . . . . . . . . . . . . . 69
CAPÍTULO 6—CONCLUSIONES Y TRABAJOS FUTUROS
6.1 CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2 TRABAJOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . 74
BIBLIOGRAFÍA
III
Índice de Figuras
1.1. Metodología empleada en el desarrollo del proyecto . . . . . . . . . . . . . 5
2.1. Escalabilidad vertical contra escalabilidad horizontal . . . . . . . . . . . . . 9
2.2. Relación entre escalabilidad y características en las bases de datos . . . . . 9
2.3. Línea de tiempo con diferentes versiones de MongoDB. G: Disponibilidadgeneral; E: estable; D: lanzamiento de desarrollo; R: candidato a definitivo 10
2.4. Componentes de una base de datos de MongoDB . . . . . . . . . . . . . . . 11
2.5. Esquema general de comunicación entre una aplicación cliente y un servi-dor MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6. Clasificación de MongoDB dentro del teorema CAP . . . . . . . . . . . . . . 13
2.7. Valores que puede tener JSON. Imagen tomada de [1] pág. 2. . . . . . . . . . . 14
2.8. Estructura de los objetos JSONImagen tomada de [1] pág. 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.9. Estructura de los arreglos JSONImagen tomada de [1] pág. 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.10. Representación de la estructura de una cadena de caracteres en JSON. Ima-gen tomada de [1] pág. 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.11. Formato BSON para el documento del Listado de código 2.2 . . . . . . . . . 16
2.12. Recolocación de un documento cuando supera el espacio adicional asignado 18
2.13. Conjunto de réplica con factor de replicación 3 . . . . . . . . . . . . . . . . . 18
2.14. Fragmentación de un sistema con 20 fragmentos y factor de replicación 3 . 21
2.15. Configuración general de un cluster y pasos de una petición . . . . . . . . . 22
3.1. Relación búsqueda–lectura en un disco duro. Imagen tomada de [2] pág. 7. . . 24
3.2. Diagrama jerárquico de empresas automotrices alemanas . . . . . . . . . . 35
V
3.3. Diagrama jerárquico con conjuntos anidados numerados . . . . . . . . . . . 38
4.1. Colección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2. Colección. (a) Con relación de contención. (b) Con documento dentro . . . 43
4.3. Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4. Conjunto de campos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5. Documento embebido. (a) Con asociación de composición. (b) Con docu-mento embebido dentro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.6. Relación de asociación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.7. Diagrama que representa los modelos en árbol de la sección 3.3. (a) Con re-ferencias parentales. (b) Con referencias hijas. (c) Con arreglo de ancestros.(d) Con rutas visibles. (d) Con conjuntos anidados . . . . . . . . . . . . . . . 50
4.8. Relación de composición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.9. Representación alternativa de una composición/contención . . . . . . . . . 51
4.10. Relación de composición con condición definida . . . . . . . . . . . . . . . . 52
4.11. Documento embebido con documentos embebidos. (a) Con asociación decomposición. (b) Con documento embebido dentro. . . . . . . . . . . . . . . 52
4.12. Restricción inter-relación con objetivo compartido. (a) Disjunta-Completa.(b) Traslapada-Incompleta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.13. Restricción inter-relación con objetivo separado . . . . . . . . . . . . . . . . 56
4.14. Anotación relacionada a una colección . . . . . . . . . . . . . . . . . . . . . 57
5.1. Diagrama que representa el modelo Uno-a-Pocos de la sección 3.1.1 . . . . . 60
5.2. Diagrama que representa el modelo Uno-a-Muchos de la sección 3.1.2 . . . 61
5.3. Diagrama que representa el modelo Uno-a-Muchísimos de la sección 3.1.3 . 61
5.4. Diagrama que representa el modelo de referenciación de doble vía de lasección 3.1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.5. Jerarquía de notas, comentarios y respuestas . . . . . . . . . . . . . . . . . . 62
5.6. Diagrama que representa el esquema de la base de datos de una librería . . 63
5.7. Diagrama que representa el esquema de la base de datos de un sistema deredes sociales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.8. Diagrama de una universidad con las entidades y sus respectivas relaciones 67
5.9. Diagrama que representa el esquema de la base de datos de las personas deuna universidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
VI
5.10. Diagrama de un museo con las entidades y sus respectivas relaciones . . . 70
5.11. Diagrama que representa el esquema de la base de datos de un museo . . . 72
VII
Capítulo
1 Preliminares
CONTENIDOS DEL CAPÍTULO
1.1 INTRODUCCIÓN
1.2 PLANTEAMIENTO EL PROBLEMA
1.3 JUSTIFICACIÓN
1.4 METODOLOGÍA
1.1 INTRODUCCIÓN
Las bases de datos han sido utilizadas ampliamente en informática para almacenardatos de manera estructurada que luego son consultados y modificados a través deuna aplicación.
El modelo de bases de datos más utilizado hoy en día es el modelo relacional [3]. Estemodelo nace en el año de 1970 cuando Edgar Frank Codd lo propone buscando queextensas cantidades de datos no se perdieran, conociendo como están organizados enuna máquina [4]. El modelo relacional se caracteriza por almacenar todos los datos enconjuntos de datos (relaciones). Normalmente cada relación es representada como unatabla, en donde las filas son llamadas tuplas y las columnas son los campos. Teniendoesto en cuenta, una base de datos relacional es la reunión de varias tablas o relaciones.
El modelo relacional tiene ventajas que hacen que su uso sea tan extendido:
Álgebra relacional: proporciona un modelo matemático con la semántica adecua-da para representar datos almacenados en una base de datos relacional [5].
Análisis de dependencias funcionales: con este análisis se puede evitar que seproduzca redundancia en los datos almacenados en una base de datos. Permite
1
1. PRELIMINARES
el análisis de una relación garantizando nivel mínimo de redundancia, nivel denormalización (hasta tercera forma Normal, incluida forma normal de Boyce-code) y calculo del conjunto de llaves.
Alto nivel de abstracción: gracias al alto nivel de abstracción se pueden recuperarlos datos eficientemente [6].
Análisis y diseño: para el diseño de bases de datos relacionales se cuenta conmetodologías como la del modelo entidad-relación, que se basa en una visióndel mundo real que consta de entidades y relaciones entre esas entidades [7].
Aunque este modelo ha solucionado el problema de organización de información du-rante mucho tiempo, hoy en día se presentan problemas con el manejo de gran canti-dad de datos o Big Data. Cuando se hacen peticiones en las que se requieren datos dedistintas tablas, son necesarias las operaciones de unión, join. Estas operaciones join sevuelven muy costosas computacionalmente cuando se busca unir datos de dos o mástablas de gran tamaño. En la práctica se ha encontrado que para peticiones complejas,el rendimiento de las bases de datos relacionales es menor que el de las bases de datosno relacionales orientadas a documentos [8].
Entre las opciones de modelos de bases de datos no relacionales, hay uno que llamala atención, MongoDB. MongoDB es la base de datos no relacional más utilizada en elmundo [3], además de ser una de las que mejores resultados presenta con el manejo deBig Data [9, 10]. Este sistema de bases de datos se caracteriza, como todos los modelosno relacionales, por ofrecer gran escalabilidad horizontal y tener un esquema flexible.Un esquema flexible permite que los datos sean almacenados sin seguir un esquemarígido, como en el modelo relacional y en el caso de MongoDB que sean almacena-dos en documentos sin la necesidad que todos los documentos sean idénticos en suestructura.
Para incrementar la productividad en la creación de bases de datos hay herramien-tas CASE (ej. MySQL Workbench, Database Designer for PostgreSQL, DB Constructor)que permiten generar código automáticamente a partir de diagramas, haciendo que eltrabajo sea más rápido que con el código creado para tal fin. Sin embargo, en la actuali-dad no hay propuestas de diagramas para representar los esquemas de MongoDB; estoen parte por la dificultad en la representación de los esquemas debido a la flexibilidadque ofrece el modelo orientado a documentos.
La finalidad de este proyecto es proponer una serie de diagramas que permitan a losdesarrolladores representar los esquemas de las bases de datos de MongoDB para fa-cilitar su comprensión.
2
1.2. Planteamiento el problema
1.2 PLANTEAMIENTO EL PROBLEMA
Cuando se piensa en un modelo de datos para MongoDB hay que analizar la estructuraque tendrán los documentos y como se representarán las relaciones entre los datos enla aplicación. Hay dos herramientas que permiten a las aplicaciones representar esasrelaciones: referencias y documentos embebidos.
En general los documentos embebidos proporcionan mejor rendimiento en las opera-ciones de lectura, y en la solicitud y recuperación de datos relacionados con una únicaoperación con la base de datos. Sin embargo, embeber datos relacionados puede cau-sar situaciones en las que los documentos crecen después de su creación. Cuando undocumento crece más del tamaño máximo asignado, es necesario reubicarlo en un nue-vo espacio de disco, ocasionando mayores tiempos de escritura y fragmentación de lainformación.
Referenciar documentos es adecuado para el uso de modelos normalizados. Éste mo-delo es ideal cuando: embeber datos puede resultar en mucha información redundanteque no proporciona suficientes ventajas de lectura para compensar las consecuenciasde la duplicación; para representar relaciones muchos-a-muchos más complejas; paramodelar grandes conjuntos jerárquicos de datos. Sin embargo, las aplicaciones del la-do del cliente deben hacer más peticiones al servidor para resolver las referencias. Hayque tener en cuenta que MongoDB ofrece atomicidad a nivel de documento y no paraoperaciones sobre varios documentos.
Existe documentación que aborda la manera en la que se pueden usar varios modelosde datos para la creación de bases de datos en MongoDB (capítulo 4 de [11]). Sin em-bargo, no hay una propuesta formal de diagramas para representar los esquemas dedatos de MongoDB.
El presente trabajo aportará una solución para la siguiente pregunta: ¿Se puede im-plementar una representación única para los diferentes modelos de datos que puedetener MongoDB y que eventualmente distintos modelos puedan converger en un solodiagrama?. Esta pregunta de investigación tiene como objeto relacionar las siguientesvariables:
1. La definición de uno o unos esquemas para modelar bases de datos orientadas adocumentos.
2. La creación de símbolos para cada uno de los elementos de MongoDB.
3. La representación de diferentes esquemas de datos en diagramas únicos.
El uso de una representación gráfica única para esquemas del modelo orientado a do-cumentos, puede facilitar la comprensión del modelo y mejorar la comprensión deesquemas más complejos.
3
1. PRELIMINARES
Con base en las dos variables planteadas, surgen algunos interrogantes que puedenayudar a determinar la solución del problema:
¿Se puede adaptar un esquema para modelar datos que pueden tener esquemadinámico?
¿Qué representación gráfica se le puede dar a la base de datos según el modelode datos seleccionado?
¿Cómo lograr que esta herramienta pueda ser usada ampliamente por usuariosque no conocen el lenguaje para la creación de bases de datos de MongoDB?
En la actualidad no hay una propuesta formal para representar gráficamente el mo-delo orientado a documentos, así que para este propósito se deben adoptar elementosdel modelo entidad-relación que no representan de forma correcta las capacidades deMongoDB.
1.3 JUSTIFICACIÓN
MongoDB es un sistema de bases de datos no relacional reciente [12] y sin embargo, seubica como el cuarto sistema de bases de datos más usado y el primer NoSQL segúnla clasificación realizada por DB-Engines. [3].
La rápida acogida de MongoDB se debe a la gran cantidad y calidad de documentaciónque hay sobre este proyecto. MongoDB University se encarga de ofrecer cursos onlinegratuitos, instruídos por sus propios ingenieros, en los que más de 200000 personas sehan documentado sobre sus fundamentos y uso adecuado [13].
Sin embargo, a pesar de toda la documentación existente, a un nuevo usuario queno conozca sobre bases de datos orientadas a documentos, le tomará por lo menos 7semanas terminar un curso introductorio sobre MongoDB.
Por otra parte, la representación gráfica de modelos como el entidad-relación, ofreceun conjunto de herramientas para mejorar la comprensión del modelo y facilitar surepresentación. Una representación gráfica permite que personas que no conocen ellenguaje empleado por el modelo, entiendan su dinámica y puedan aportar al desarro-llo del mismo.
La finalidad de este trabajo es la creación de una notación gráfica que represente losdistintos tipos de esquemas de modelos que se pueden lograr en MongoDB, en dia-gramas en los que pueden converger estos esquemas sin llegar a ambigüedades. Dichanotación gráfica puede llegar a convertirse en un factor clave para una mayor adopciónde MongoDB.
4
1.4. Metodología
Usar losdiagramas
para larepresentaciónde diferentesmodelos de
datos
Uso dediagramas
Integrar lanotacióngráfica en
diagramas deforma
congruente
Adaptación dediagramas
Crear unanotación
gráfica pararepresentar loselementos de
MongoDB
Representaciónde elementos
Identificar lascaracterísticasde MongoDB
Investigarsobre losúltimos
avances yesquemas que
se puedenimplementar
con MongoDB
Revisión deestado del arteContextualización
Figura 1.1: Metodología empleada en el desarrollo del proyecto
1.4 METODOLOGÍA
Para el desarrollo de este proyecto se llevarán a cabo las etapas mostradas en la Figura1.1.
Contextualización: Al finalizar la etapa de contextualización se comprende la estruc-tura general de MongoDB y su modelo de datos.
Estado del arte: El producto de esta etapa es el conocimiento de la situación actual deMongoDB y los desarrollos que se están llevando a cabo.
Representación de elementos: Como resultado se obtiene el planteamiento de unanotación gráfica para cada uno de los elementos que hacen parte de MongoDB.
Adaptación de diagramas: Cada uno de los elementos de MongoDB con su respectivanotación gráfica es usado en diagramas que modelan los diferentes esquemas quese pueden implementar.
Uso de diagramas: Al finalizar todas las etapas se espera tener una representacióngráfica que permita modelar cualquier modelo de datos de MongoDB.
5
Capítulo
2 Conociendo MongoDB
CONTENIDOS DEL CAPÍTULO
2.1 BASES DE DATOS NOSQL
2.2 INTRODUCCIÓN A MONGODB
2.3 ACID, BASE Y CAP
2.4 JSON – JAVASCRIPT OBJECT NO-TATION
2.5 BSON – BINARY JSON
2.6 ESQUEMA DINÁMICO
2.7 CRECIMIENTO Y RECOLOCACIÓNDE LOS DOCUMENTOS
2.8 REPLICACIÓN
2.9 DISPONIBILIDAD
2.1 BASES DE DATOS NOSQL
Comúnmente las bases de datos no relacionales son denominadas NoSQL [8, 9]. Eltérmino NoSQL inicialmente se refería bases de datos que no usaban el estándar deconsultas SQL1 (Structured Query Language – Lenguaje de Consulta Estructurado).Sin embargo con el paso de los años y un uso más extendido, el término NoSQL seentiende en la actualidad como Not Only SQL o No Sólo SQL, haciendo referencia a quelas bases de datos no relacionales también pueden soportar el lenguaje de consultasSQL.
Las bases de datos NoSQL son desarrolladas en respuesta al aumento en el volumende los datos almacenados por los usuarios, la frecuencia en que son consultados losdatos y el rendimiento y procesamiento que esto requiere. También se caracterizan porel uso de BASE en lugar de ACID (ver Sección 2.3).
1http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home %20Page
7
2. CONOCIENDO MONGODB
Los sistemas NoSQL son distribuídos por naturaleza. Un sistema distribuido es unconjunto de computadores interconectados, que comparten un estado ofreciendo una visión desistema único, en el que una aplicación cliente o el usuario no percibe la diferencia entreuna red y un sistema centralizado [14]. Para esto, las bases de datos NoSQL soportanfragmentación automática, lo que significa que de forma nativa propagan los datos através de un número arbitrario de servidores; los datos son balanceados automática-mente en los servidores, y cuando un servidor se cae, puede ser reemplazado de formarápida y transparente sin interrumpir la aplicación.
NoSQL agrupa una gran variedad de diferentes tecnologías de bases de datos [15],entre las que se encuentran:
Orientadas a documentos una reunión de claves con una estructura de datos comple-ja, se conoce como un documento. Un documento puede contener muchos paresclave-valor diferentes, pares clave-arreglo, o documentos anidados.
Orientadas a gráficos son usadas para almacenar información sobre redes, como lasconexiones sociales.
Clave valor son las bases de datos NoSQL más simples. Cada ítem en la base de datosse almacena como un nombre o clave.
Por columnas están optimizadas para peticiones sobre grandes conjuntos de datos.Almacenan conjuntos de columnas en lugar de filas.
La Tabla 2.1 muestra ejemplos de bases de datos, para los modelos descritos.
La clasificación mostrada en la Tabla 2.1 es el puesto en el que se encuentra catalogadala base de datos según DB-Engines [3]. Para calcular el puntaje dado a cada base dedatos, se miden los siguientes parámetros [16]
Número de veces que se menciona el sistema en los sitios web: Se mide con elnúmero de resultados de las búsquedas en los motores de Google y Bing.
Interés general en el sistema: Para esta medición, se usa la frecuencia de búsque-das en Google Trends.
Frecuencia de discusiones técnicas sobre el sistema: Se usa el número de pregun-tas relacionadas y el número de usuarios interesados de los sitios Stack Overflowy DBA Stack Exchange.
Número de ofertas de trabajo en las que el sistema es mencionado: Se usa elnúmero de ofertas proporcionadas en los motores de búsqueda de trabajo Indeedy Simply Hired.
Relevancia en las redes sociales: Se mide el número de tweets de la red socialTwitter en los cuales el sistema es mencionado.
8
2.2. Introducción a MongoDB
Tabla 2.1: Algunos ejemplos de bases de datos NoSQL, agrupados por tipo de tecnología
Modelo de datos Base de datos Clasificación [3]
Orientado adocumentos
MongoDBCouchbaseCouchDBRavenDB
4252445
Orientado a gráficos
Neo4jTitan
OrientDBArangoDB
21424498
Clave-valor
RedisMemcached
AmazonDynamoDB
Riak
10222731
Por columnas
CassandraHbase
AccumuloHypertable
81657
133
Escalabilidad horizontal
Esca
labi
lidad
vert
ical
Figura 2.1: Escalabilidad vertical contra es-calabilidad horizontal
CaracterísticasRDBMS
MongoDB
Esca
labi
lidad
+ve
loci
dad
Figura 2.2: Relación entre escalabilidad y ca-racterísticas en las bases de datos
2.2 INTRODUCCIÓN A MONGODB
El nombre MongoDB viene de la palabra humongous que significa enorme [17]. Es unsistema de bases de datos NoSQL orientado a documentos que proporciona alto rendi-miento, alta disponibilidad y fácil escalabilidad. La filosofía de MongoDB es conseguirmayor velocidad y escalabilidad, conservando por lo menos el 80 % de las característi-cas (Figura 2.2).
El desarrollo de MongoDB empezó en octubre 2007 por la compañía 10gen, como unaplataforma de servicio similar a Google App Engine. El primer lanzamiento oficial seda en 2009, pero no es sino hasta la versión 1.4.0 donde la base de datos se considera
9
2. CONOCIENDO MONGODB
Figura 2.3: Línea de tiem-po con diferentes versiones deMongoDB. G: Disponibilidadgeneral; E: estable; D: lanza-miento de desarrollo; R: can-didato a definitivo
2.1.02.4.02.2.0
2.3.x 2.5.x2.6.0
2.7.x
03-f
eb-1
2
29-a
go-1
2
23-o
ct-1
2
19-m
ar-1
3
22-m
ay-1
3
08-a
br-1
4
03-m
ay-1
4
D E D E D E D
2.8.0
04-d
ic-1
4
R
1.2.00.9.3
1.0.01.3.0
1.6.01.4.01.5.x 1.7.x
2.0.01.8.01.9.2
29-m
ay-0
9
27-a
go-0
9
10-d
ic-0
9
31-d
ic-0
9
25-m
ar-1
0
09-a
br-1
0
05-a
go-1
0
04-s
ep-1
0
16-m
ar-1
1
15-a
go-1
1
12-s
ep-1
1
G G E E D E D E E ED1.1.0
14-s
ep-0
9
3.0.0
03-m
ar-1
5
E
3.1.0
17-m
ar-1
5
D
3.2.0 rc4
24-n
ov-1
5
lista para su uso en producción. En la Figura 2.3 se muestra una línea de tiempo conlas versiones más relevantes de MongoDB [18]. Desde la versión 2.0.0, las versionesimpares son lanzamientos de transición (lanzamientos de desarrollo) hacia versionesdefinitivas, mientras que las versiones pares son lanzamientos estables a las que solose hace corrección de errores.
Debido a la popularidad alcanzada por MongoDB, la compañía 10gen se cambió elnombre por MongoDB Inc. y ahora enfoca todos sus esfuerzos al desarrollo de la basede datos [19]. MongoDB es el sistema de gestión de bases de datos con mayor creci-miento en 2013 [20], el sistema NoSQL más usado [21], y el cuarto sistema de bases dedatos a nivel mundial [3].
A continuación se lista empresas que han utilizado MongoDB exitosamente para eldesarrollo de sus plataformas [22]:
BOSH: creando nuevos negocios mediante la conexión de sensores con análisisen tiempo real.
ebay: entregando todos los metadatos multimedia a sus usuarios con un 99,999 %de disponibilidad.
McAfee: con un repositorio de datos centralizado para la plataforma global dedetección de amenazas.
Adobe: Almacenamiento de datos multi-petabyte para el gestor de experienciade Adobe.
Forbes: entregando un sistema de gestión de contenidos en dos meses y un nuevositio móvil en un mes.
MTV: gestión de contenidos para cientos de sitios web.
10
2.2. Introducción a MongoDB
Colección DocumentoBase de datos BinariaRepresentación
Figura 2.4: Componentes de una base de datos de MongoDB
Aplicación cliente Servidor MongoDB
PyMongo
BSON
BSON
controlador
petición
0BSONFigura 2.5: Esquema general de comu-nicación entre una aplicación cliente yun servidor MongoDB
2.2.1 Componentes de una base de datos de MongoDB
La Figura 2.4 muestra las partes que componen una base de datos de MongoDB.
Las bases de datos en MongoDB se encuentran conformadas por colecciones. A su vezuna colección es un conjunto de varios documentos agrupados en ella.
Los documentos se muestran al usuario en formato JSON (Sección 2.4) para facilitarsu lectura. La interacción entre el usuario y los documentos JSON, se hace por mediode una terminal que usa el lenguaje de programación JavaScript. Con la ayuda deJavaScript se pueden hacer consultas y modificar los documentos JSON.
Para hacer más eficiente la codificación, decodificación, transporte y el almacenamien-to de los diferentes tipos de datos, se usa BSON (Sección 2.5). BSON es la representa-ción binaria de los documentos JSON.
En la Figura 2.5 se muestra un esquema que explica de forma general como se hace lacomunicación entre una aplicación cliente y un servidor. El cliente envía una peticiónque es contestada con una trama que empieza con un bit de encabezado 0. La respuestase aloja en la memoria RAM del cliente; luego un controlador transforma el códigoBSON al lenguaje de programación utilizado por el cliente. El controlador puede serla terminal directamente, que usa JavaScript, o un controlador como PyMongo quepermite el uso de Python.
11
2. CONOCIENDO MONGODB
2.3 ACID, BASE Y CAP
2.3.1 ACID (Atomicity, Consistency, Isolation, Durability)
ACID es un termino que describe el conjunto de propiedades necesarias para garanti-zar que las transacciones en una base de datos se realicen de forma confiable [23]. Laspropiedades se describen a continuación
Atomicidad Una transacción es atómica cuando es imposible para otra parte de unsistema encontrar pasos intermedios. Si una parte de la transacción falla, toda latransacción falla y no se permiten cambios en la base de datos.
Consistencia La base de datos será consistente si la transacción empieza y termina.Llevará de un estado válido a otro estado válido.
Aislamiento Define como y cuando los cambios producidos por una operación se ha-cen visibles para las demás operaciones concurrentes. Cada transacción debe serindependiente de otras.
Durabilidad Una vez confirmada la transacción, ésta persistirá y no se podrá deshaceraunque falle el sistema.
2.3.2 BASE (Basically Available, Soft-state, Eventually-consistent)
BASE es un concepto opuesto a ACID usado por las bases de datos NoSQL. Las pro-piedades de BASE se describen a continuación
Disponibilidad básica El almacén funciona la mayoría de tiempo, incluso ante fallos,gracias al almacenamiento distribuído y replicado.
Soft-state Ni los almacenes ni sus réplicas tienen por qué ser consistentes todo el tiem-po. El programador puede verificar esa consistencia.
Consistencia eventual La consistencia se da eventualmente.
2.3.3 Teorema CAP
El teorema CAP (Consistency, Availability, Partition tolerance) establece que un sis-tema distribuido puede tener máximo dos de las tres propiedades: Consistencia (C),Disponibilidad (A), Tolerancia a particiones (P) [24].
Por defecto, MongoDB cumple con las propiedades CP del teorema CAP, consistencia ytolerancia a particiones (Figura 2.6) [25]. Hay alta consistencia gracias a que MongoDB
12
2.4. JSON – JavaScript Object Notation
Consistencia
MongoDB
Tolerancia aparticiones
Disponibilidad
Figura 2.6: Clasificación de MongoDB dentro del teoremaCAP
cuenta con un sistema de único maestro o primario, y las operaciones de escritura enla base de datos se hacen en el primario antes de replicarse a otros equipos. Comolas consultas se hacen al primario, se asegura que la información que se recibe es lamisma que se ha escrito en la base de datos. Sin embargo el administrador de la basede datos puede habilitar la lectura desde los equipos secundarios, haciendo que elsistema sea eventualmente consistente lo que genera que algunos resultados puedanestar desactualizados. También hay alta tolerancia a particiones. Cuando se presentaun fallo, el sistema conmuta automáticamente para buscar la mejor configuración delconjunto de réplica (Subsección 2.8), garantizando que la caída de un equipo no afectela operación del sistema.
2.4 JSON – JAVASCRIPT OBJECT NOTATION
JSON es un formato de texto que facilita el intercambio de datos estructurados entredistintos lenguajes de programación. Actualmente JSON está descrito por dos están-dares internacionales, el estándar ECMA-404 que describe la sintaxis permitida, y lanorma RFC 7159 que describe además algunas consideraciones de seguridad [1, 26].
El texto JSON se codifica bajo el estándar Unicode para facilitar su tratamiento infor-mático. El conjunto de caracteres incluye 6 caracteres estructurales, cadenas de texto,números y tres caracteres de nombre literal.
Los caracteres estructurales son paréntesis cuadrado izquierdo [, corchete izquierdo{, paréntesis cuadrado derecho ], corchete derecho }, dos puntos : y coma ,. Los trescaracteres de nombre literal son verdadero true, falso false, y nulo null.
A continuación se hace la descripción del resto del lenguaje:
13
2. CONOCIENDO MONGODB
Figura 2.7: Valores que puede tener JSON.Imagen tomada de [1] pág. 2.
objeto
arreglo
número
cadena de caracteres
true
false
null
valor
Figura 2.8:Estructura delos objetosJSONImagen tomadade [1] pág. 2.
cadena de caracteres valor
objeto{ }
2.4.1 Valores
Los valores JSON pueden ser un objeto, arreglo, número, cadena de caracteres, true,false o null, como se muestra en la Figura 2.7.
2.4.2 Objetos
Es una estructura que se representa en un par de corchetes {}, que puede estar vacíoo tener pares nombre-valor. El nombre siempre es de tipo string. Si hay más de un parnombre-valor, se deben separar por coma. La Figura 2.8 muestra la estructura generalde los objetos.
En MongoDB no es necesario que un nombre dentro de un objeto esté encerrado entrecomillas, si el nombre empieza con una letra. El Listado de código 2.1 muestra unejemplo de objeto JSON: en la línea 3 se ve el caso en el que el nombre no está encerradoentre comillas, lo que es permitido en MongoDB; en la línea 4 se muestra un nombreque empieza con el caracter #, lo que hace obligatorio el uso de comillas en el nombre.
Listado de código 2.1: Ejemplo de objeto en JSON
1 {2 "ciudad": "Cartagena",3 ciudad: "Bucaramanga",4 "#_habitantes": 150005 }
14
2.5. BSON – Binary JSON
valor ][
arreglo
Figura 2.9: Estructura de losarreglos JSONImagen tomada de [1] pág. 3.
2.4.3 Arreglos
Un arreglo es una estructura representada dentro de paréntesis cuadrados [], quepuede contener cero (0) o más valores. Los valores deben separarse por comas y elorden en que se colocan se mantiene. La estructura de un arreglo se muestra en laFigura 2.9.
2.4.4 Números y cadenas de caracteres
Los números representan en base decimal. Pueden ser negativos, decimales y puedentener exponentes de diez con el prefijo e.
Una cadena de caracteres es un conjunto de código Unicode dentro de comillas. Laestructura general de una cadena de caracteres de representa en la Figura 2.10.
2.5 BSON – BINARY JSON
BSON representa los documentos JSON de forma binaria y permite la representaciónde tipos de datos que no hacen parte de la especificación JSON, como datos de tipofecha y datos de tipo binario (arreglo de bytes).
Hay cuatro tipos de datos básicos que se usan en el resto de la gramática [27]
byte 1 byte (8-bits)
int32 4 bytes (32-bit entero con signo, complemento a dos)
int64 8 bytes (64-bit entero con signo, complemento a dos)
double 8 bytes (64-bit IEEE 754 punto flotante)
La Figura 2.11 muestra el formato BSON generado para el documento JSON que semuestra a continuación
Listado de código 2.2: Documento JSON usado en el formato BSON de la Figura 2.11
{ "a": "3", "b": "xyz" }
15
2. CONOCIENDO MONGODB
Cualquier punto de código excepto ” o \ ocaracter de control
comillas
barra inversa
barra inclinada
retroceso
salto de página
salto de línea
retorno de carro
tabulación
4 dígitos hexadecimales
"
\
b
f
n
r
t
u
" "
/
/
cadena de caracteres
Figura 2.10: Representación de la estructura de una cadena de caracteres en JSON. Imagen tomadade [1] pág. 5.
Figura 2.11: Forma-to BSON para el do-cumento del Listadode código 2.2
23 3 4 xyz ∅ ∅a ∅ b ∅
"b": "xyz"
valor valorclave clavelongitud valor
tipo valor (utf-8)tipo valor (int-32)
tamaño documento fin de objeto
.a": 3
16
2.6. Esquema dinámico
Como se ve en la Figura 2.11, el documento BSON empieza con el tamaño del docu-mento, 23 bytes, seguido por: el tipo de valor del primer objeto (número en formatoint-32); la clave del primer objeto, a; el valor del primer objeto, 3; el tipo de valor delsegundo objeto (cadena de caracteres en formato utf-8); la clave del segundo objeto, b;la longitud de la cadena de caracteres, 4; el valor del segundo objeto, xyz; y un valornulo ∅ que indica el fin del objeto. Nótese que cada cadena de caracteres siempre vaseguida de un valor nulo ∅.
El principal uso del formato BSON es el almacenamiento y transferencia de datos delas bases de datos de MongoDB. Un servidor de MongoDB trabaja con BSON de formanativa.
2.6 ESQUEMA DINÁMICO
Los documentos en MongoDB tienen un esquema dinámico. Esquema dinámico signi-fica que los documentos de una misma colección no necesitan tener la misma estructu-ra, y los campos comunes a varios documentos pueden tener diferentes tipos de datos.En los Listados de código 2.3 y 2.4, se ve como los dos documentos de la misma colec-ción tienen diferente estructura. Mientras que la clave "Natalicio" del primer docu-mento tiene un valor numérico, la clave "Natalicio" del segundo documento tienecomo valor una cadena de caracteres; también se ve como el primer documento tieneun par clave-valor "Ciudad": "Lituania" que el segundo documento no tiene yde la misma forma, el segundo documento tiene el par clave-valor "Cod_postal":1234 que el primer documento no contiene.
Listado de código 2.3: Documento de Mon-goDB perteneciente a la colección docentes
{"_id" : ObjectId("5462
ee906994db65eeab3075"),"Natalicio": 1911,"Nombre": "Kazys","Apellido": "Gabriunas","Ciudad": "Lituania"
}
Listado de código 2.4: Documento de Mon-goDB perteneciente a la colección docentes
{"_id" : ObjectId("5462
ee956994db65eeab3076"),"Nombre": "Vytautas","Apellido": "Gabriunas","Natalicio": "desc.","Cod_postal": 1234
}
2.7 CRECIMIENTO Y RECOLOCACIÓN DE LOS DOCUMENTOS
Todo documento en MongoDB se almacena en un registro que contiene al documentoy un espacio adicional que permite que el documento crezca si hay cambios hasta unmáximo de 16 MB.
17
2. CONOCIENDO MONGODB
D1 D2 D3
espacio adicional
(a)
D1 vacío D3 D2
movimiento(b)
Figura 2.12: Recolocación de un documento cuando supera el espacio adicional asignado
Figura 2.13: Conjunto de réplicacon factor de replicación 3
a
b
c
Primarioa
b
c
Secundario
a
b
c
Secundario
docu
men
tos réplica
réplica
Cuando se agota el espacio adicional asignado, se tiene que hacer una operación demovimiento para dar más espacio al documento. Una operación de movimiento es cos-tosa computacionalmente, por lo que hay que evitar que los documentos crezcan másde lo asignado usando una estrategia de asignación de espacio adecuada. Las opera-ciones de movimiento de documentos son efectuadas automáticamente por MongoDB.
2.8 REPLICACIÓN
La replicación consiste en contar con varias copias de la misma información en variosequipos. Esto con el fin de tener alta disponibilidad de los datos en caso de error, yasegurar copias de seguridad para recuperar los datos en caso de desastre. Al conjuntode equipos que contiene la misma información, se le llama conjunto de réplica. La Figura2.13, muestra el diagrama de un conjunto de réplica.
El número de equipos presente en un conjunto de réplica se denomina factor de replica-ción, abreviado como RF (Replication Factor). En el caso de la Figura 2.13, el factor dereplicación es RF = 3. Conociendo el factor de replicación y la cantidad de documen-tos distintos en el sistema n = 100× 106, se puede calcular con la ecuación (2.1) el total
18
2.8. Replicación
de documentos que hay en el sistema dT
RF · n = dT (2.1)3 · 100 × 106 = 300 × 106
En cada conjunto de réplica solo puede haber un equipo primario o maestro que es elque replica la información a los equipos secundarios o esclavos. Esto se hace para quesolo el miembro primario del conjunto pueda aceptar operaciones de escritura, y deesta manera asegurar estricta consistencia en todas las lecturas que se hagan en él.
2.8.1 Conmutación automática en caso de error
Los conjuntos de réplica proveen alta disponibilidad de los datos usando conmuta-ción automática en caso de error. La conmutación permite que un miembro secundariollegue a ser primario, si el primario no está disponible.
Cuando el primario no está disponible, los secundario hacen una votación para elegirun nuevo primario. En algunos casos la operación de conmutación requiere revertirlas operaciones de escritura para mantener la consistencia entre los miembros del con-junto de réplica. El ganador de la votación del conjunto de réplica se da por mayoríaabsoluta.
2.8.2 Preferencias de lectura
Por defecto las operaciones de lectura se hacen en el equipo primario para asegurarconsistencia en los datos. Sin embargo, el administrador de la base de datos puedeindicarle al sistema que cambie este comportamiento. Hay que tener en cuenta quecuando se consulta información en un equipo secundario, ésta puede ser obsoleta, loque se denomina consistencia eventual. Las opciones de lectura disponibles en Mon-goDB se describen a continuación:
Primario Modo por defecto. Todas las operaciones de lectura se hacen desde el prima-rio del conjunto de réplica actual.
Preferir primario En la mayoría de situaciones, las operaciones de lectura se hacendesde el primario, pero si éste no se encuentra disponible, se hacen desde losmiembros secundarios.
Secundario Todas las operaciones de lectura se hacen desde los miembros secundariosdel conjunto de réplica. Nunca desde el primario.
Preferir secundario Se prefiere que las operaciones de lectura se hagan desde los miem-bros secundarios, pero si no hay miembros secundarios disponibles, las operacio-nes de lectura se hacen desde el miembro primario del conjunto de réplica.
19
2. CONOCIENDO MONGODB
El más cercano Las operaciones de lectura se hacen desde el miembro del conjunto deréplica con menor latencia en la red, independientemente del tipo de miembro.
2.9 DISPONIBILIDAD
Cuando alguno de los miembros del conjunto de réplica se encuentra fuera de opera-ción, el administrador de la base de datos puede reconfigurar el conjunto. Una recon-figuración solo se puede hacer si la mayoría del conjunto está en operación y si hay unprimario disponible.
La primera configuración del conjunto de réplica es almacenada por todos los miem-bros como la 1.0 y la primera reconfiguración como la 2.0.
En caso de que un miembro del conjunto de réplica se encuentre fuera de operacióndurante una reconfiguración y se recupere después de ésta, comparará su versión conla versión de configuración del primario y entonces procederá a actualizar su configu-ración.
En la reconfiguración también se puede especificar un servidor con mayor prioridadpara ser primario. Dicho servidor será elegido entre los miembros del conjunto deréplica como primario, cuando la reconfiguración se halla efectuado.
2.9.1 Árbitros
Un árbitro es un servidor que ayuda en casos en los que es necesario votar para elegirun primario. Un árbitro no tiene copia de la réplica de datos, por lo que no puede serprimario ni votar por él mismo.
Los árbitros se permiten en conjuntos de réplica en los que hay un número par demiembros y se necesite desempatar la votación. Es importante no ejecutar árbitros enlos equipos que alojen miembros primarios o secundarios del conjunto de réplica, paraevitar que el árbitro no salga de operación en caso de falla de dicho equipo.
Existen dos maneras en las que el administrador de la base de datos puede influir enlos resultados de la votación para elegir primario:
Establecer la prioridad: Se puede establecer la prioridad de un miembro del con-junto para ser elegido como primario. Si se establece prioridad 0 en algún servi-dor, éste nunca llegará a ser primario. La prioridad se establece con cualquiernúmero real positivo, y entre mayor sea, más posibilidades tendrá el servidor deser primario. Por defecto es 1.
Número de votos de cada miembro: Por defecto cada miembro del conjuntocuenta con un voto. Sin embargo, el administrador de la base de datos puedeestablecer la cantidad de votos que tiene un determinado servidor.
20
2.9. Disponibilidad
S1 S2
m = 20
S20
. . .
S3
RF = 3 a d g
documentos
Figura 2.14: Fragmenta-ción de un sistema con 20fragmentos y factor de re-plicación 3
2.9.2 Fragmentación
La fragmentación consiste en dividir la información en varias partes, para repartir lacarga de trabajo entre varios equipos del sistema [28]. Cada fragmento Sm puede estaralojado en un conjunto de réplica. El número de fragmentos se representa con la letram. En la Figura 2.14 se tienen 20 fragmentos de la información m = 20.
Conociendo el número de fragmentos y la cantidad de documentos distintos en el sis-tema n = 100 × 106, se puede estimar con la ecuación (2.2) la cantidad aproximada dedocumentos por equipo de. La precisión de esta estimación dependerá del estado delbalance de documentos en los fragmentos.
nm
≈ de (2.2)
100×106/20 ≈ 5 × 106 (2.3)
De acuerdo con (2.3) hay aproximadamente 5 millones de documentos por equipo.
2.9.3 Estructura general de un clúster
Un conjunto de computadores o clúster en MongoDB, puede tener servidores con lossiguientes tipos de procesos:
mongos se comunican con los procesos mongod y con los servidores de configuraciónpara obtener metadatos, de tal forma que cuando el cliente realice una petición,el proceso mongos tenga la información necesaria para decidir a qué fragmentoSm enviar la petición. Los procesos mongos no tienen un estado persistente (nohay archivos de datos en ellos), en realidad son como un equilibrador de cargaentre fragmentos.
mongod cuando el proceso se ejecuta en un fragmento, es el encargado de almace-nar datos en la base de datos. Cuando el proceso se ejecuta en un servidor deconfiguración, se encarga de manejar los metadatos del servidor. Los metadatosson importantes para conocerque fragmento contiene los datos buscados. Si nohay un servidor de configuración con un proceso mongod, las operaciones paraequilibrar carga entre fragmentos no se pueden hacer.
21
2. CONOCIENDO MONGODB
Figura 2.15: Configu-ración general de uncluster y pasos de unapetición
conjunto demongod mongod mongod. . .
mongos mongos . . .
servidorconfig.
cliente cliente cliente . . .1
234
5
6
réplica
S1 S2 Sm
La Figura 2.15 muestra un diagrama de la configuración general de un clúster con lospasos llevados a cabo en una petición por parte del cliente. Dichos pasos se describena continuación:
1. El cliente envía una petición a MongoDB, que está configurado para que sea aten-dida por un servidor con proceso mongos.
2. El proceso mongos reenvía la petición al servidor de configuración para obte-ner metadatos con información sobre en que fragmento se encuentran los datossolicitados por el cliente.
3. El servidor de configuración responde al proceso mongos con los metadatos so-licitados.
4. El proceso mongos redirige la petición hecha por el cliente al proceso mongod enel fragmento en el que se encuentran los datos solicitados.
5. El proceso mongod responde enviando los datos solicitados por el proceso mon-gos.
6. El proceso mongos entrega al cliente los datos que solicitó.
22
Capítulo
3 Modelos de datos
CONTENIDOS DEL CAPÍTULO
3.1 MODELOS PARA RELACIONES 1:N
3.2 CONSIDERACIONES PARA MODE-LAR RELACIONES 1:N
3.3 MODELOS CON ESTRUCTURAS DEÁRBOL
3.4 CONSIDERACIONES PARA LOSMODELOS EN ÁRBOL
MongoDB es un sistema de bases de datos orientado a documentos, que permite mode-lar datos de muchas formas gracias a que cuenta con esquemas dinámicos. Las posibili-dades que ofrece hacen que la formulación de modelos de datos para casos específicospueda traer confunción, sobre todo cuando hay que decidir si embeber o referenciarlos documentos.
En lo posible, siempre es recomendable embeber los documentos. Cuando se embebendocumentos se logra que la operación de la base de datos sea más eficiente ya que soloes necesario hacer una petición para obtener los resultados deseados.
Por el contrario, cuando se referencian documentos es necesario hacer varias peticionespara encontrar la información. Implícitamente cada petición tiene que hacer búsque-das aleatorias en disco, por lo que a mayor número de peticiones, mayor cantidad debúsquedas aleatorias, y en consecuencia, mayor tiempo de búsqueda. En el disco durode un servidor, el tiempo de búsqueda puede variar entre 4 ms y 10 ms, y tener unatasa de lectura de 160 MiB/s (esto depende de factores como la distancia entre las pis-tas) [29]. Si se asume una consulta de 1024 bytes de información, entonces el tiempo delectura sería de aproximadamente 6, 4 µs, como se muestra en la Figura 3.1.
La relación entre tiempo de búsqueda y tiempo de lectura es de 625 : 1, lo que conviertelas búsquedas aleatorias en enemigas de los sistemas de bases de datos [2].
23
3. MODELOS DE DATOS
Figura 3.1: Relación búsqueda–lectura en un disco duro.Imagen tomada de [2] pág. 7.
Búsqueda: Lectura:4 ms 6,4µs
Sin embargo, hay casos en los que la información de los documentos embebidos esgrande y sobrepasa el límite de 16 MB de espacio asignado para cada documento.Cuando un documento agota el espacio asignado, se hace un movimiento de dichodocumento a otro lugar que ofrezca el espacio necesario. Estos movimientos son cos-tosos computacionalmente y en algunos casos se pueden evitar usando referenciación.
El manual de MongoDB presenta una breve guía sobre modelos con referencias y mo-delos con estructura de árbol (sección 4.3.2 de [11]). En las secciones 3.1 y 3.2 se descri-ben los modelos de datos propuestos por William Zola y las reglas para el diseño deun modelo 1:N. Por otra parte, en la sección 3.3 se describen brevemente los modeloscon estructura de árbol, concluyendo en la sección 3.4 donde se exponen las ventajas ydesventajas a tener en cuenta para la elección de un modelo de árbol adecuado.
3.1 MODELOS PARA RELACIONES 1:N
Los modelos de relaciones 1:N se formalizan y se acotan por el autor William Zola,clasificándolos según la cardinalidad del modelo como Uno-a-Pocos, Uno-a-Muchos yUno-a-Muchísimos. A continuación de esa formalización, el autor muestra como opti-mizar el rendimiento de dichos modelos nombrandolos como referenciación de doblevía, desnormalización con relaciones Uno-a-Muchos y desnormalización con relacio-nes Uno-a-Muchísimos respectivamente [30].
3.1.1 Modelando Uno-a-Pocos
En una relación 1:N, cuando el lado N es menor que cientos, se puede considerar quela relación es de Uno-a-Pocos. En este caso se puede embeber la información del ladoN en el lado de 1.
Un ejemplo es la programación de mantenimiento para los buses del sistema integradode transporte público. En este caso embeber es una buena opción ya que a un bus nose le programa mantenimiento más de dos o tres veces en una semana. La informaciónsobre la programación de mantenimiento se coloca en un arreglo dentro del documentodel bus.
24
3.1. Modelos para relaciones 1:N
Listado de código 3.1: Ejemplo de modelado de 1-a-pocos1 > db.buses.findOne()2 {3 placa: "UDB-015",4 empresa: "Egobus",5 tipo: "Busetón",6 ciudad: "Bogotá",7 mantenimiento: [8 { dia: "Domingo", hora: "13:15", rev: "Revisión motor" },9 { dia: "Miércoles", hora: "09:40", rev: "Lavado general"}
10 ]11 }
Este modelo tiene como ventajas que solo es necesaria una petición a la base de datospara acceder a los detalles de los documentos embebidos, y que al ser operacionessobre un solo documento, son operaciones atómicas. La desventaja es que no se puedeacceder a los detalles incrustados como entidades independientes.
3.1.2 Modelando Uno-a-Muchos
Se considera que un modelo 1:N es de Uno-a-Muchos cuando el lado N está compuestopor varios de cientos, pero por menos de un par de miles. En este caso, se colocanreferencias a los documentos del lado de “Muchos” desde los documentos del lado de“Uno”.
Un ejemplo pueden ser los estudiantes que conforman un determinado grupo de estu-dio en una universidad. En cada grupo de estudio pueden haber cientos estudiantes,pero nunca un par de cientos o menos. Este es un buen caso para usar referencias.
Para cada estudiante hay un documento y éste a su vez, tiene un código único que seusa como identificador de objeto (ObjectID).
Listado de código 3.2: Documento de un estudiante para el ejemplo de modelado de 1-a-muchos1 > db.estudiantes.findOne()2 {3 _id : ObjectID("20072005055"),4 nombre: "Luis Alberto Bustamante",5 carrera: "Ingeniería Electrónica",6 facultad: "Ingenierías",7 num_cel: 32145678908 }
Cada grupo de investigación debe tener su propio documento, que debe contener unarreglo de referencias ObjectID a los estudiantes que conforman el grupo
Listado de código 3.3: Documento de un grupo para el ejemplo de modelado de 1-a-muchos
25
3. MODELOS DE DATOS
1 > db.grupos.findOne()2 {3 _id: "FI08745",4 nombre: "GLUD",5 categoria "Software libre",6 id_estudiantes: [7 20072005055,8 20072005059,9 20081005077,
10 // etcétera11 ]12 }
Como se ve en la línea 6 del listado de código 3.3 hay un arreglo de referencias queapuntan a cada uno de los integrantes del grupo. La línea 7 apunta al documento delestudiante del listado de código 3.2.
Para encontrar los estudiantes que integran un determinado grupo, se puede usar unaunión a nivel de aplicación. Primero se busca el grupo identificado por su número deregistro
> grupo = db.grupos.findOne({registro: "FI08745"})
y luego todos los estudiantes que integran el grupo
> estudiantes_grupo = db.estudiantes.find ({_id:{$in :grupo.estudiantes }}).toArray()
Para una operación eficiente, es necesario tener un índice en grupos.registro. Siem-pre habrá un índice en estudiantes._id, de modo que las peticiones siempre seráneficientes en esa colección.
Este estilo de referenciación tiene varias ventajas:
1. Cada estudiante tiene un documento independiente por lo que es fácil buscarloy actualizar su información.
2. Un estudiante puede estar vinculado a varios grupos de investigación, por lo queun esquema uno-a-muchos se puede convertir en muchos-a-muchos sin necesi-dad de una tabla de unión.
3.1.3 Modelando Uno-a-Muchísimos
El modelo Uno-a-Muchísimos se caracteriza porque el lado de “Muchísimos” puedeestar compuesto por millones. En este modelo, los documentos del lado de “Muchísi-mos” contienen referencias a los documentos del lado de “Uno”.
26
3.1. Modelos para relaciones 1:N
Un ejemplo de Uno-a-Muchísimos es el sistema de almacenamiento de búsquedas deun motor de búsqueda. Las búsquedas realizadas se almacenan para ofrecer resultadosde búsqueda de acuerdo a los intereses del usuario. En cualquier momento la cantidadde búsquedas diferentes puede ser tan grande que supere el tamaño máximo de alma-cenamiento establecido para un documento de MongoDB, incluso si solo se almacenael ObjectID.
En el siguiente Listado de código se muestra el documento de un usuario de un deter-minado motor de búsqueda
Listado de código 3.4: Documento de usuario de un motor de búsqueda1 > db.usuarios.findOne()2 {3 _id: ObjectID("507f191e810c19729de860ea"),4 nombre: "Diego Medina",5 apodo: "tuno90",6 edad: 247 }
El siguiente listado de código muestra un documento donde se ha almacenado unabúsqueda
Listado de código 3.5: Documento de una búsqueda almacenada1 > db.busquedas.findOne()2 {3 _id: ISODate("2015-03-17T18:27:41.382Z"),4 palabras: "ultimo juego de xbox",5 ubicacion: "Bogotá D.C.",6 usuario: ObjectID("507f191e810c19729de860ea")7 }
Hay que hacer una petición un poco distinta para encontrar las 2000 búsquedas másrecientes de un usuario. Primero se encuentra el documento del usuario, en este casodel usuario del Listado de código 3.4
> usuario = db.usuarios.findOne({Apodo: "tuno90"})
Luego se encuentran las 2000 búsquedas más recientes vinculadas con ese usuario
> mensajes = db.busquedas.find({usuario: usuario._id}).sort({tiempo :-1}).limit(2000).toArray()
3.1.4 Referenciación de doble vía
Un modelo de referenciación más elaborado se puede lograr combinando dos técnicase incluyendo ambos estilos en el esquema, teniendo referencias desde el lado de “Uno”a “Muchos” y referencias desde el lado de “Muchos” hacia el lado de “Uno”.
27
3. MODELOS DE DATOS
Tomando nuevamente el ejemplo usado en la sección 3.1.1, hay una colección buses
que contiene documentos con información sobre los buses, una colección rutas quecontiene documentos de las rutas de trabajo a cubrir, y una relación Uno-a-N de buseshacia rutas. La aplicación necesitará hacer un seguimiento de todas las rutas que cubreun bus, así que es necesario crear una referencia de buses a rutas.
En las líneas 7 a 12 del Listado de código 3.6, se muestra un arreglo de referencias adocumentos de rutas.
Listado de código 3.6: Referenciación de doble vía para la colección buses1 > db.buses.findOne()2 {3 _id: ObjectID("UDB-015"),4 empresa: "Egobus",5 tipo: "Busetón",6 ciudad: "Bogotá",7 id_rutas: [8 "T04",9 "552",
10 "P64",11 //etcétera12 ]13 }
Por otro lado, en otros contextos esta aplicación mostrará una lista de rutas y necesitaráencontrar rápidamente el bus responsable para cada ruta. Esto se puede optimizarcolocando una referencia adicional al bus en el documento de la ruta, como se muestraen el Listado de código 3.7. La línea 7 referencia al documento del bus encargado de laruta.
Listado de código 3.7: Referenciación de doble vía para la colección rutas1 > db.rutas.findOne()2 {3 _id: ObjectID("T04"),4 origen: "Tres esquinas",5 destino: "Terminal del sur",6 fecha: ISODate("2015-04-03"),7 id_bus: "UDB-015"8 }
Este diseño tiene todas las ventajas y desventajas del esquema uno a muchos, pero conalgunas adiciones. Poniendo una referencia extra bus en el documento de rutas, esmás rápido y fácil encontrar el bus que cubre cada ruta, pero también significa que si senecesita reasignar la ruta a otro bus, es necesario realizar dos actualizaciones en vezde solo una. Específicamente, se tendrán que actualizar ambas: la referencia del busen la colección de rutas, y la referencia de la ruta en la colección de buses (usando
28
3.1. Modelos para relaciones 1:N
este diseño de esquema ya no es posible reasignar una ruta a un bus diferente con unaúnica actualización atómica).
3.1.5 Desnormalización con relaciones Uno-a-Muchos
La desnormalización puede eliminar la necesidad de realizar operaciones de unión anivel de aplicación, pero añade cierta complejidad adicional al realizar actualizaciones.
Desnormalizando de Muchos-a-Uno
Tomando el ejemplo de estudiantes de la sección 3.1.2, se puede desnormalizar el nom-bre del estudiante en el arreglo estudiantes[] de la línea 6 del Listado de código 3.3.
Desnormalizar significa que no hay que realizar operaciones de unión a nivel de apli-cación cuando muestren todos los nombres de los estudiantes de un grupo, pero seránecesario una operación de unión para consultar cualquier otra información acerca deun estudiante.
El Listado de código 3.8 muestra la desnormalización de los nombres de los estudiantesque conforman un grupo de investigación.
Listado de código 3.8: Documento con desnormalización del nombre de los estudiantes1 > db.grupos.findOne()2 {3 _id: "FI08745",4 nombre: "GLUD",5 categoria "Software libre",6 estudiantes: [7 { id: ObjectID("20072005055"), nombre: "Luis Bustamante" },8 { id: ObjectID("20072005059"), nombre: "Laura López" },9 { id: ObjectID("20081005077"), nombre: "Tatiana Poveda" },
10 // etcétera11 ]12 }
Mientras se hace más fácil obtener los nombres de los estudiantes, se añade solo unpoco de trabajo del lado del cliente para las operaciones de unión a nivel de aplicación.
Primero se obtiene el documento del grupo de investigación
> grupo = db.grupos.findOne({registro: "FI08745"})
Con la función map se crea un arreglo de ObjectID que contiene solo los códigos de losestudiantes
> cod_estudiante = grupo.estudiantes.map( function(doc) {return doc.id})
29
3. MODELOS DE DATOS
Por último se obtienen todas los estudiantes que se encuentran en el grupo de investi-gación
> grupo_est = db.estudiantes.find({_id: { $in: cod_estudiante }}).toArray()
Desnormalizar ahorra una búsqueda de los datos no normalizados a costa de una ac-tualización más costosa computacionalmente: si se ha desnormalizado el nombre delestudiante en el documento del grupo, entonces cuando se actualice el nombre del es-tudiante, también se deben actualizar todos los lugares en donde se encuentre en lacolección grupos.
Desnormalizar solo tiene sentido cuando hacer consultas es lo común y las actualiza-ciones se hacen rara vez. Cuando las actualizaciones llegan a ser más frecuentes enrelación a las consultas, disminuyen los beneficios de la desnormalización.
Por ejemplo, si se supone que el nombre de un estudiante nunca cambia o cambiacon poca frecuencia, pero el número de celular num_cel cambia frecuentemente, tienesentido desnormalizar el nombre del estudiante en el documento del grupo, pero notiene sentido desnormalizar el número celular.
También hay que notar que si se desnormaliza un campo, se pierde la capacidad derealizar actualizaciones atómicas y aisladas en ese campo. Al igual que con la refe-renciación de doble vía mostrada en la sección 3.1.4, si se actualiza el nombre de unestudiante en el documento del estudiante, y luego en el documento del grupo, ha-brá un intervalo de algunas décimas de segundo donde el nombre desnormalizado enel documento del grupo no reflejará el nuevo valor actualizado en el documento delestudiante.
Desnormalizando de Uno-a-Muchos
También se pueden desnormalizar campos del lado de “Uno” en el lado de “Muchos”.En el Listado de código 3.9, en las líneas 8 y 9, se observa como se desnormalizó elnombre del grupo de investigación y el número de registro del grupo.
Listado de código 3.9: Documento con desnormalización del nombre y el registro del grupo1 > db.estudiantes.findOne()2 {3 _id : ObjectID("20072005055"),4 nombre: "Luis Alberto Bustamante",5 carrera: "Ingeniería Electrónica",6 facultad: "Ingenierías",7 num_cel: 3214567890,8 grupo_inv: "GLUD",9 reg_grupo: "FI08745"
10 }
30
3.1. Modelos para relaciones 1:N
En este caso, como se ha desnormalizado el nombre del grupo en el documento delestudiante, entonces cuando se actualice el nombre del curso, se deben también actua-lizar todos los lugares donde se encuentre en la colección estudiantes. De esta formauna actualización es más costosa computacionalmente, ya que se deben actualizar múl-tiples documentos de estudiantes en vez de un único grupo de investigación. Es signi-ficativamente más importante considerar la proporción de consulta-escritura cuandose desnormaliza de esta forma.
3.1.6 Desnormalización con relaciones Uno-a-Muchísimos
Es posible desnormalizar el ejemplo de la sección 3.1.3 de dos maneras:
1. Poner la información del lado de “Uno” (a partir del documento del usuario) enel lado de “Muchísimos” (la colección de búsquedas)
2. Poner la información del lado de “Muchísimos” en el lado de “Uno”
Por ejemplo, se desnormaliza el lado de “Muchísimos” colocando el apodo del usuario(del lado de “Uno”, Listado de código 3.4) en el documento de una búsqueda
Listado de código 3.10: Documento con el campo apodo desnormalizado1 > db.busquedas.findOne()2 {3 tiempo : ISODate("2015-03-17T18:27:41.382Z"),4 palabras: "ultimo juego de xbox",5 ubicacion: "Bogotá D.C.",6 usuario: ObjectID("507f191e810c19729de860ea"),7 apodo: "tuno90"8 }
Con esto se facilita la petición para encontrar las búsquedas más recientes de un usua-rio con determinado apodo
> mensajes = db.busquedas.find({Apodo: "tuno90"}).sort({tiempo: -1}).limit(2000).toArray()
De hecho, si la cantidad de información que se quiere almacenar del lado de “Uno”es limitada, se puede desnormalizar todo en el lado “Muchísimos” y eliminar el lado“Uno” por completo
Listado de código 3.11: Documento con toda la información de usuario desnormalizada1 > db.busquedas.findOne()2 {3 tiempo : ISODate("2015-03-17T18:27:41.382Z"),4 palabras: "ultimo juego de xbox",
31
3. MODELOS DE DATOS
5 ubicacion: "Bogotá D.C.",6 nombre: "Diego Medina",7 apodo: "tuno90"8 edad: 249 }
Por otro lado, también se puede desnormalizar en el lado de “Uno”. En este caso, sequiere mantener registro de las últimas 1000 búsquedas de un usuario en el documentode usuario. Se pueden usar los operadores $each y $slice para mantener esa listaordenada, y solo conservar los últimos 1000 mensajes.
Las búsquedas son almacenadas en documentos de la colección busquedas como tam-bién en la lista desnormalizada del documento de usuario: de esta forma el registro dela búsqueda no se pierde cuando no se encuentra en el arreglo usuario.busquedas.
Primero se obtienen las palabras de la búsqueda del motor de búsquedabusqueda = obtener_busqueda();busqueda_aqui = busqueda.palabras;ubica_user = busqueda.ubicacion;apodo_user = busqueda.apodo;
Se averigua el tiempo actualt_actual = new Date();
Se encuentra el _id para el usuario que se está actualizando. La proyección _id: 1 seusa para que solo se envíe la información del campo _id
doc_user = db.usuarios.findOne({apodo: apodo_user},{_id: 1})id_user = doc_user._id
Ahora se inserta la búsqueda, la referencia parental y la información desnormalizadaen el lado de “Muchos”db.busquedas.save({tiempo: t_actual, palabras: busqueda_aqui,
ubicacion: ubica_user, apodo: apodo_user, usuario: id_user})
Se coloca el resultado de la búsqueda desnormalizado en el lado de “Uno”db.usuarios.update({_id: id_user},
{$push : {busquedas :{$each: [{tiempo: t_actual, palabras: busqueda_aqui}],
$sort: { tiempo : 1 }, $slice: -1000 }}})
Como en el caso de uno-a-muchos hay que considerar la proporción de consultas yactualizaciones. Desnormalizar las busquedas en el documento de usuario solo tienesentido si la frecuencia de una petición de búsqueda es baja con respecto al número deveces que la aplicación necesita consultar las búsquedas que se han realizado para unúnico usuario. Esta desnormalización es mala idea si se quieren consultar búsquedascon menor frecuencia de lo que se hacen actualizaciones.
32
3.2. Consideraciones para modelar relaciones 1:N
3.2 CONSIDERACIONES PARA MODELAR RELACIONES 1:N
La siguiente guía contiene 6 reglas a considerar cuando se esta diseñando un modelo1:N para una base de datos:
1. Preferir embeber documentos a menos que haya una razón de peso para no ha-cerlo.
2. Necesitar acceso a los detalles de los documentos embebidos como entidadesindependientes, es una razón para no embeberlos.
3. Los arreglos no deben crecer ilimitadamente. Si hay más de un par de cientos dedocumentos en el lado “Muchos”, no se deben embeber; si hay mas de unos po-cos miles de documentos en el lado de “Muchos”, es mejor no utilizar un arreglode referencias de ObjectID. Los arreglos de alta cardinalidad son una razón depeso para no embeber documentos.
4. No necesariamente debe evitarse hacer cálculo de uniones a nivel de aplicación:si se indexa correctamente y se usa el especificador de proyección (como el mos-trado en la sección 3.1.6), entonces las uniones a nivel de aplicación solo son unpoco más costosas computacionalmente que las uniones del lado del servidor enuna base de datos relacional.
5. Considerar la proporción escritura/lectura cuando se desnormaliza. Un campoque en su mayoría será consultado y solo se actualizará rara vez es un buen can-didato para la desnormalización: si se desnormaliza un campo que es frecuen-temente actualizado entonces el trabajo extra de encontrar y actualizar todas lasinstancias puede opacar las ventajas obtenidas con la desnormalización.
6. En MongoDB, el modelo de datos depende – completamente – de los patrones deacceso a los datos de la aplicación en particular. Lo recomendable es estructurarlos datos para encontrar las formas en que la aplicación hace las peticiones y lasactualizaciones.
La Tabla 3.1 sugiere el modelo de datos a utilizar según la cardinalidad y las caracte-rísticas del diseño de la base de datos.
3.3 MODELOS CON ESTRUCTURAS DE ÁRBOL
Los modelos con estructuras de árbol se amplían de la siguiente manera: modelos conestructuras de árbol con referencias parentales, con referencias hijas, con arreglos deancestros, con rutas visibles y con conjuntos anidados.
33
3. MODELOS DE DATOS
Tabla 3.1: Propuesta de modelos de datos según la cardinalidad y las características
CaracterísticasCardinalidad
Uno-a-Pocos Uno-a-MuchosUno-a-
Muchísimos
La cantidad delecturas es muy
superior a lacantidad de
actualizaciones
ModelandoUno-a-Pocos
ModelandoUno-a-Muchos
ModelandoUno-a-
MuchísimosNo es necesarioel acceso a losdatos del lado Ncomo entidadesindependientes
La cantidad delecturas no es muy
superior o es similara la cantidad deactualizaciones
ModelandoUno-a-Pocos
DesnormalizaciónUno-a-Muchos
DesnormalizaciónUno-a-
Muchísimos
La cantidad delecturas no es muy
superior o es similara la cantidad deactualizaciones
Referenciaciónde doble vía
ModelandoUno-a-Muchos
ModelandoUno-a-
MuchísimosAcceso a losdatos del lado Ncomo entidadesindependientes
La cantidad delecturas es muy
superior a lacantidad de
actualizaciones
Referenciaciónde doble vía
DesnormalizaciónUno-a-Muchos
DesnormalizaciónUno-a-
Muchísimos
Estos modelos almacenan información de forma jerárquica, en donde un nodo padrepuede tener varios nodos hijo.
La Figura 3.2, muestra la estructura de datos que se utilizará como referencia paraexplicar cada uno de los modelos con estructura de árbol. El nodo “Alemanas” es deprimera jerarquía, los nodos “Volkswagen Group”, “Daimler AG” y “BMW Group”son de segunda jerarquía y el resto de nodos son de tercera jerarquía.
3.3.1 Estructura de árbol con referencias parentales
Esta estructura presenta relaciones 1:N unidireccionales, en donde los documentos hijoalmacenan el identificador _id de su correspondiente documento padre: relacioneshijo→padre.
Tomando en cuenta el diagrama de la Figura 3.2, el documento de la marca Porshe ylos de jerarquía superior relacionados con él, se crearían con la siguiente estructura
Listado de código 3.12: Modelo de una estructura de árbol con referencias parentales> db.automotrices.insert({_id: "Porshe", parent: "Volkswagen Group"})
34
3.3. Modelos con estructuras de árbol
Volkswagen Group
Daimler AG
BMW Group
Audi
BugattiLamborghini
Porshe
SkodaVolkswagen
Scania
Mercedes-BenzMitsubishi FusoFreighlinerSmartMaybach
BMWMINIRolls-Royce Cars
Alemanas
Figura 3.2: Diagrama jerárquico deempresas automotrices alemanas
> db.automotrices.insert({_id: "Volkswagen Group",parent: "Alemanas"})
> db.automotrices.insert({_id: "Alemanas", parent: null})
La petición para encontrar el nodo padre sería bastante sencilla. En este caso para co-nocer a qué grupo automotriz pertenece la marca Porshe, se usaría al siguiente instruc-ción
> db.automotrices.findOne({_id: "Porshe"}).parent
Para que las búsquedas sean más rápidas, se crea un índice en el campo parent
> db.automotrices.createIndex({parent: 1})
También se pueden buscar todos los documentos que pertenecen a un determinadopadre. En este caso, para encontrar todas las marcas del grupo Volkswagen
> db.automotrices.find({parent: "Volkswagen Group"})
3.3.2 Estructura de árbol con referencias hijas
Esta estructura presenta relaciones 1:N unidireccionales, en donde los documentos pa-dre almacenan los identificadores _id de sus correspondientes documentos hijos: rela-ciones padre→hijo.
Tomando en cuenta el diagrama de la Figura 3.2, el documento de la marca MINI y losde jerarquía superior relacionados con él, se crearían con la siguiente estructura
35
3. MODELOS DE DATOS
Listado de código 3.13: Modelo de una estructura de árbol con referencias hijas> db.automotrices.insert({_id: "MINI", children: []})> db.automotrices.insert({_id: "BMW Group",
children: ["BMW", "MINI", "Rolls-Royce Cars"]})> db.automotrices.insert({_id: "Alemanas",
children: ["Volkswagen Group", "Daimler AG", "BMW Group"]})
La petición para encontrar un nodo hijo sería bastante sencilla. En este caso para co-nocer todas las marcas de automóviles que pertenecen a BMW Group, se usaría lasiguiente instrucción
> db.automotrices.findOne({_id: "BMW Group"}).children
Para que las búsquedas sean más rápidas, se crea un índice en el campo hijos
> db.automotrices.createIndex({children: 1})
También se puede buscar el documento padre que pertenece a determinado documen-to hijo. En este caso para encontrar el grupo al que pertenece la marca MINI
> db.automotrices.find({children: "MINI"})
3.3.3 Estructura de árbol con arreglo de ancestros
Esta estructura presenta relaciones 1:N unidireccionales, en donde los documentos hijoalmacenan en un arreglo todos los identificadores _id de sus ancestros, además de losidentificadores de sus correspondientes documentos padre: relaciones hijo→padre yancestros.
Tomando en cuenta el diagrama de la Figura 3.2, el documento de la marca Mercedes-Benz y los de jerarquía superior relacionados con él, se crearían con la siguiente estruc-tura
Listado de código 3.14: Modelo de una estructura de árbol con arreglo de ancestros> db.automotrices.insert({_id: "Mercedes-Benz",
ancestors: ["Alemanas", "Daimler AG"],parent: "Daimler AG"})
> db.automotrices.insert({_id: "Daimler AG",ancestors: ["Alemanas"],parent: "Alemanas"})
> db.automotrices.insert({_id: "Alemanas",ancestors: [],parent: null})
La petición para encontrar los ancestros de un nodo sería bastante sencilla. En este casopara conocer el árbol de la marca Mercedes-Benz, se usaría la siguiente petición
36
3.3. Modelos con estructuras de árbol
> db.automotrices.findOne({_id: "Mercedez-Benz"}).ancestors
Para que las búsquedas sean más rápidas, se crea un índice en el campo ancestors
> db.automotrices.createIndex({ancestors: 1})
También se pueden buscar todos los descendientes de un determinado nodo. En estecaso para encontrar todas las marcas de carros y casas automotrices pertenecientes aAlemania
> db.automotrices.find({ancestors: "Alemanas"})
3.3.4 Estructura de árbol con rutas visibles
Esta estructura presenta relaciones 1:N unidireccionales, en donde los documentos hijoalmacenan en un arreglo todos los identificadores _id de su ruta. El arreglo de path esel mismo de ancestors, sólo se cambia el nombre para diferenciar el modelo. En estecaso las relaciones son hijo→ancestros.
Tomando en cuenta el diagrama de la Figura 3.2, el documento de la marca Mercedes-Benz y los de jerarquía superior relacionados con él, se crearían con la siguiente estruc-tura
Listado de código 3.15: Modelo de una estructura de árbol con rutas visibles> db.automotrices.insert({_id: "Mercedes-Benz",
path: ["Alemanas", "Daimler AG"]})> db.automotrices.insert({_id: "Daimler AG", path: ["Alemanas"]})> db.automotrices.insert({_id: "Alemanas", path: []})
Para obtener la ruta completa de un nodo determinado ordenada según el campo path,se usa la siguiente instrucción
> db.automotrices.find().sort({path: 1})
Para encontrar los descendientes de las empresas automotrices alemanas, se puedenusar expresiones regulares en el campo path
db.automotrices.find({path: /^,Alemanas,/})
La creación de un índice en el campo ruta se hace con la siguiente instrucción
db.automotrices.createIndex({path: 1})
37
3. MODELOS DE DATOS
Figura 3.3: Diagramajerárquico con conjuntosanidados numerados
Daimler AG
BMW Group
Audi
BugattiLamborghini
Porshe
SkodaVolkswagen
Scania
Mercedes-BenzMitsubishi FusoFreighlinerSmartMaybach
BMWMINIRolls-Royce Cars
Alemanas
2
1 38
18
30
1921232527
3579
11
313335
37
29
VolkswagenGroup
17
1315
46
810
1214
16
2022
2426
28
3234
36
3.3.5 Estructura de árbol con conjuntos anidados
Con esta estructura se numera cada nodo dos veces, una vez de ida y otra de vuelta,como se muestra en la Figura 3.3. Cada documento almacena los identificadores _idde sus correspondientes nodos padre, el nodo inicial de la numeración en el campoizquierda y el nodo de la numeración final en el campo derecha.
Teniendo en cuenta la Figura 3.3, el documento de la marca Scania y los de jerarquíasuperior relacionados con él, se crearían con la siguiente estructura
Listado de código 3.16: Modelo de una estructura de árbol con conjuntos anidados> db.automotrices.insert({_id: "Alemanas", parent: 0,
left: 1, right: 38})> db.automotrices.insert({_id: "Volkswagen Group", parent:"Alemanas",
left: 2, right: 17})> db.automotrices.insert({_id: "Scania", parent: "Volkswagen Group",
left: 11, right: 12})
Para obtener todos los descendientes de un nodo, en este caso todas las marcas perte-necientes al Volkswagen Group, se usan las siguientes instrucciones
> var volks-marcas = db.automotrices.findOne({_id: "Volkswagen Group"});
> db.automotrices.find({left: {$gt: volks-marcas.izquierda},right: {$lt: volks-marcas.derecha}});
Como se observa, las instrucciones anteriores buscan todos los documentos que tenganen el campo izquierda un número mayor a 2 y en el campo derecha un número menora 17, encontrando así todos los descendientes del Volkswagen Group.
38
3.4. Consideraciones para los modelos en árbol
3.4 CONSIDERACIONES PARA LOS MODELOS EN ÁRBOL
Cada modelo con estructura de árbol tiene características que lo pueden hacer mejor opeor opción a la hora de elegir qué modelo utilizar. La Tabla 3.2 muestra las caracte-rísticas a favor y en contra con que cuenta cada modelo presentado en la sección 3.3.
Tabla 3.2: Características de los modelos con estructura de árbol
Modelo enárbol
A favor En contra
Conreferenciasparentales
Solución simple para elalmacenamiento en árbol
Requiere varias peticiones pararecuperar información de
subárbolesCon
referenciashijas
Adecuando en situaciones dondeun nodo puede tener varios padres
Requiere varias peticiones pararecuperar información de
subárbolesCon arreglode ancestros
Es una buena opción para trabajarcon subárboles
Ligeramente más lento que elmodelo con rutas visibles
Con rutasvisibles
Proporciona mayor flexibilidad enel trabajo con la ruta, como labúsqueda de nodos con rutas
parciales
Requiere pasos adicionales detrabajo con expresiones regulares y
cadenas de caracteres
Conconjuntosanidados
Es la mejor opción para trabajarcon árboles estáticos que no
cambian además de ser eficientepara encontrar información en
subárboles
Es ineficiente para modificar laestructura del árbol
39
Capítulo
4 Diagramas Orientados aDocumentos
CONTENIDOS DEL CAPÍTULO
4.1 CONVENCIÓN DE NOMBRES
4.2 COLECCIONES
4.3 DOCUMENTOS
4.4 CAMPOS
4.5 CONJUNTOS DE CAMPOS
4.6 DOCUMENTOS EMBEBIDOS
4.7 RELACIONES
4.8 RESTRICCIONES
4.9 NOTAS
Ante la necesidad de representar gráficamente los diferentes tipos de esquema que sepueden hacer en MongoDB, se propone una serie de símbolos gráficos para simplifi-car y facilitar su comprensión. Estos símbolos permiten modelar el comportamientoestático del esquema de datos.
Esta propuesta de basa ampliamente en las relaciones del estándar UML, buscandofacilitar su uso a desarrolladores de otros tipos de bases de datos. Sin embargo UML esorientado a objetos, por lo que no se puede representar con él la totalidad del modeloorientado a documentos. Al final del capítulo se especifica cada uno de los símbolosusados en este modelo, que se corresponden con símbolos de UML.
A lo largo del capítulo se usan expresiones en estilo de letra de ancho fijo para diferen-ciar las expresiones que hacen parte de un diagrama y las que no.
41
4. DIAGRAMAS ORIENTADOS A DOCUMENTOS
4.1 CONVENCIÓN DE NOMBRES
Para diferenciar los nombres de los diferentes elementos, se especifica una convenciónde nombres. Antes de especificar la convención, es necesario detallar los conceptos delowerCamelCase y UpperCamelCase [31]
lowerCamelCase Hace referencia a la escritura de palabras o frases compuestas en lasque la primera palabra empieza con minúscula y las otras palabras empiezan conmayúscula.
UpperCamelCase Se refiere a la escritura de palabras compuestas en las que cada pa-labra empieza con mayúscula.
Una vez conocidos estos conceptos, se define la convención de nombres de los diagra-mas orientados a documentos:
El nombre de una colección usa el estilo UpperCamelCase, va en negrita y enplural.
El nombre de un campo usa el estilo lowerCamelCase.
El nombre del campo contenedor de un documento embebido usa el estilo Up-perCamelCase. En caso de contener un arreglo de documentos embebidos, va enplural.
El nombre de una asociación usa el estilo lowerCamelCase.
Las restricciones con palabras compuestas usan el estilo lowerCamelCase.
Las expresiones dentro de < > indican que deben ser reemplazadas por su equi-valente, guardando consistencia con la notación del manual de MongoDB.
4.2 COLECCIONES
Una colección es la agrupación de documentos bajo un nombre concreto. Debido a esto,MongoDB sólo crea una colección después de que el primer documento es creado.
Se representa gráficamente como una carpeta con una pestaña en la parte izquierdasuperior, con su nombre en medio, como se muestra en la Figura 4.1.
Los documentos que son parte de la colección se relacionan con ella mediante unaasociación de contención (sección 4.7.1), como se ve en la Figura 4.2.a.
Alternativamente, la colección se puede representar con los documentos que la com-ponen dibujados dentro. En ese caso, el nombre de la colección va dentro de la pestaña,como se muestra en la Figura 4.2.b [32].
42
4.3. Documentos
<nombre>
Figura 4.1: Colección
<campos>
<coleccion>
relación decontención <campos>
<coleccion>
(a) (b)
Figura 4.2: Colección. (a) Con re-lación de contención. (b) Con do-cumento dentro
4.3 DOCUMENTOS
Los documentos son los elementos más importantes en un modelo orientado a docu-mentos. Tienen una estructura dinámica que se ajusta al diseño del desarrollador de labase de datos.
Un documento ordena y presenta información de un conjunto de datos de forma or-ganizada y de fácil acceso. Gráficamente se representa como un rectángulo con unaesquina doblada que simboliza la notación más común e intuitiva para un documento,como se muestra en la Figura 4.3.
<campos>
Figura 4.3: Documento
Dentro del gráfico de Documento se encuentran los campos que lo componen. Cadadocumento tiene un campo identificador, _id, que es inherente a él, y a menos queel usuario quiera darle un valor diferente al que MongoDB le asigna por defecto, estecampo se puede omitir en la representación gráfica. Cuando la cantidad de camposes demasiado grande, se pueden colocar tres puntos suspensivos después del últimocampo, indicando que el documento tiene más campos que no se escribieron.
La relación entre un documento y una colección, se hace como se muestra en la Figura4.2.
43
4. DIAGRAMAS ORIENTADOS A DOCUMENTOS
4.4 CAMPOS
Un campo es el espacio usado para una categoría particular de datos, identificado me-diante un nombre, que siempre es una cadena de caracteres (string).
Normalmente los nombres de los campos son suficiente para identificar las caracte-rísticas de un documento, sin embargo, se pueden especificar las propiedades de dis-ponibilidad, indexación, tipo, multiplicidad, valor y restricción, que hacen aún másexplícita la función del campo.
La sintaxis completa, que se presenta a continuación, ha sido tomada casi íntegramentede [33], pero adaptándola a las características de MongoDB
<"~"> nombre <"("tipo")"> <"["multiplicidad"]"><":" valor inicial> <"{"restriccion"}">
Todo el contenido dentro de los símbolos mayor-menor debe ser reemplazado por suequivalente, exceptuando el que se encuentra entre comillas.
La única característica obligatoria en todos los campos es el nombre, y a menos que seindique que el campo puede no estar disponible (sección 4.4.1), es obligatorio asignarun valor al campo.
A continuación se describen cada una de las propiedades.
4.4.1 Disponibilidad
La disponibilidad es la propiedad que especifica que el campo puede no tener valorasignado, y por tanto no estar disponible en el documento. Se indica antecediendo elsímbolo virgulilla “~” al nombre del campo.
4.4.2 Indexación
Los índices se usan para soportar eficientemente las solicitudes de búsqueda de in-formación. Un campo indexado se representa gráficamente resaltando su nombre ennegrita.
Sin índices se debería escanear cada uno de los campos de los documentos de unacolección para encontrar la información solicitada. En MongoDB el campo _id se creapor defecto y siempre está indexado; si el usuario no especifica un valor para estecampo, el valor se asigna automáticamente.
44
4.4. Campos
4.4.3 Tipo
Cuando se especifica el tipo de dato de un campo, se debe restringir el campo paraque únicamente permita datos del tipo especificado. El tipo de un campo se especificaentre paréntesis
< ”(”tipo”)” >
Aunque el formato BSON usado por MongoDB para almacenar documentos soporta19 tipos de datos (sección 4.4.5 de [11]), un usuario sólo puede asignar a un campo10 de ellos, de los cuales solo se declaran double, string, boolean, numberInt,numberLong, objectID, timestamp, isoDateTime, date y geoSpatial, comoun tipo de dato dentro de paréntesis. El tipo de dato Array se declara mediante pa-réntesis cuadrados (sección 4.4.4), mientras que los tipos null y undefined se debenespecificar como un valor inicial.
A menos que se especifique explícitamente el valor de un campo de tipo objectID, elsistema asignara automáticamente un valor único.
Pese a que el manual de MongoDB desaconseja fuertemente asociar el nombre de uncampo con diferentes tipos de datos, se puede especificar más de un tipo de dato paraun campo. Para especificar más de un tipo de dato, simplemente se separa un tipo deotro con comas
(string, boolean)
4.4.4 Arreglo
Es un tipo de dato que permite agrupar un conjunto de elementos como valores, otrosarreglos o documentos embebidos.
Para especificar que un campo es del tipo arreglo, se coloca paréntesis cuadrado des-pués del nombre del campo. El paréntesis cuadrado puede ir vacío o especificando lamultiplicidad.
< ”[”multiplicidad”]” >
Cuando el paréntesis cuadrado está vacío, el arreglo puede estar compuesto por nin-guno o más elementos.
Gracias a la libertad de esquema que tiene MongoDB es permitido tener arreglos den-tro de otros arreglos, lo que se conoce como arreglos anidados. Para especificar unarreglo de arreglos anidados, se pone cada arreglo dentro de otro de forma consecuti-va
< ”[”multiplicidad1”[”multiplicidad2”[” ...”[”multiplicidadn”]”... ”]]]” >
n ∈ Z+
45
4. DIAGRAMAS ORIENTADOS A DOCUMENTOS
donde los subíndices 1, 2, ..., n indican el nivel de anidamiento de cada arreglo. Asípor ejemplo, un arreglo con tres niveles de anidamiento, se indicaría como sigue
[0.. ∗ [1..4[2..2]]]
donde el primer nivel puede tener cero o muchos valores, el segundo uno o cuatro, yel tercero dos.
Multiplicidad
La multiplicidad es una definición del número de elementos de un conjunto, que señalala cantidad de instancias que son permitidas para un elemento descrito.
Se escribe como dos números, a y b, que indican los límites mínimo y máximo. Estoslímites se encuentran separados por dos puntos consecutivos entre ellos
a..b a, b ∈ N
Para especificar el número exacto de elementos, a debe ser igual a b, dando lugar a quela expresión de multiplicidad se puede abreviar con un único número c
a = b = c ⇒ a..b = c
Cuando no se conoce o no se quiere indicar el límite máximo de la multiplicidad, secoloca el símbolo asterisco “∗” como el límite máximo, que significa que es ilimitado(tan sólo limitado por la capacidad de la aplicación). Normalmente el asterisco se leecomo “muchos”
a..∗ ∗ ∈ N
Poner únicamente el símbolo asterisco equivale a decir que pueden haber cero o mu-chos valores
∗ ≡ 0..∗
4.4.5 Valor
Cuando se considere necesario es posible añadir un valor inicial a un campo. Un valorinicial va antecedido por dos puntos
< ” : ” valor >
A menos que se indique lo contrario, el tipo de valor de un campo será string odouble, dependiendo si es una cadena de caracteres o un número. Además, es obliga-torio asignar valor a un campo, excepto que se especifique explícitamente la propiedadde disponibilidad.
46
4.5. Conjuntos de campos
4.4.6 Restricción
En un campo las restricciones se utilizan cuando las otras propiedades no son suficien-te para definir los valores que puede tener un campo. Una restricción se especifica contexto libre dentro de corchetes
< ”{”restriccion”}” >
Según los requerimientos funcionales, un campo puede tener restricciones como porejemplo: de {solo lectura}, índice único {unique}, mayor que {>7}, menor que{<5}, entre otras. Varias restricciones van separadas por una coma una de la otra.
4.5 CONJUNTOS DE CAMPOS
Un conjunto de campos agrupa uno o más campos, que pueden pertenecer a un ele-mento de mayor nivel, como otro conjunto de campos, un documento o un documentoembebido. La composición de un conjunto de campos a un elemento de mayor nivel,siempre se encuentra condicionada por algún tipo de restricción.
Se representan gráficamente encerrados dentro de un rectángulo y unidos al elementode mayor nivel por una relación de composición. En la Figura 4.4 se muestra que elcampo universidad compondrá el documento, si el campo profesion existe.
Curriculum
nombretelefono~ profesion
conjunto
restricciónrelación decomposición
universidadde campos{profesion ∃ }
Figura 4.4: Conjunto de campos
La relación de composición se explica en la sección 4.7.2 y las restricciones en la sección4.8.
4.6 DOCUMENTOS EMBEBIDOS
Es un documento dentro de otro documento, que se encuentra asignado a un campo,el campo contenedor. Al no ser documentos como tal, sino parte de ellos, los docu-mentos embebidos no cuentan con un campo indexado _id por defecto, y a excepción
47
4. DIAGRAMAS ORIENTADOS A DOCUMENTOS
del tipo y el valor, el campo contenedor tiene todas las propiedades de un campoconvencional.
Su representación gráfica es un documento, sobre el que se encuentra el campo conte-nedor encerrado en un rectángulo. Se relaciona con su documento contenedor median-te una asociación de composición (sección 4.7.1), como se muestra en la Figura 4.5.a.
Figura 4.5: Docu-mento embebido.(a) Con asociaciónde composición.(b) Con documentoembebido dentro.
Personalidades
nombreapellido
tituloanoentidad
Premios [ ]
relación decomposición
embebidodocumento
campocontenedor
Personalidades
nombreapellido
titulo
Premios [ ]
anoentidad
campocontenedor
(a) (b)
Cuando en el campo contenedor se especifica un arreglo, corresponde a que contendráun arreglo de documentos embebidos.
Similar a la notación alternativa de una colección, un documento embebido también sepuede representar dibujando el documento embebido dentro del documento contene-dor, debajo del campo contenedor, como se ve en la Figura 4.5.b.
Un documento embebido puede contener otros documentos embebidos, teniendo encuenta que MongoDB no soporta más de 100 niveles de documentos embebidos [34].
4.7 RELACIONES
Una relación es una conexión entre elementos [33]. Las relaciones se representan comolíneas que pueden tener diferentes cabezas de flecha según el tipo de relación.
4.7.1 Asociación
Es una relación que especifica conexión entre elementos de las colecciones, o entreelementos de los documentos. Se representa gráficamente como una línea continua ala que se puede añadir multiplicidad, navegación, rol y nombre, como se muestra enla Figura 4.6.
48
4.7. Relaciones
<coleccion> <coleccion><rol> <rol>1 *
asociación
navegación
multiplicidadmultiplicidad
<nombre>
Figura 4.6: Relación de asociación
Multiplicidad Sobre el extremo de una asociación, especifica la cantidad de referen-cias que pueden haber en la colección de ese extremo, por cada documento de lacolección del otro extremo.
Navegación Una asociación dirigida con una cabeza de flecha abierta, especifica na-vegación entre elementos. Va dirigida desde el elemento que referencia hacia elelemento referenciado. Cuando no se especifica navegación, se entiende que hayreferencias desde y hacia los dos elementos asociados.
Nombre Identifica la asociación. Se escribe cerca del medio de la línea de la asociación.
Rol Se usa cuando el nombre de la colección no es suficiente para describir el papelque ésta juega en una asociación. El rol se escribe en el extremo de la asociación,junto a la colección representada.
Asociaciones recursivas
Se usan cuando una colección se relaciona con ella misma y tienen las mismas propie-dades de una asociación normal [35].
En el modelo orientado a documentos se usan, por lo general, acompañadas de unarestricción para especificar el modelo con estructura de árbol que se usa en la colección.
Las restricciones son las siguientes
{parent} Especifica el modelo de árbol con referencias parentales (sección 3.3.1).
{child} Especifica el modelo de árbol con referencias hijas (sección 3.3.2).
{ancestors} Especifica el modelo de árbol con arreglo de ancestros (sección 3.3.3).
{paths} Especifica el modelo de árbol con rutas visibles (sección 3.3.4).
{nestedSets} Especifica el modelo de árbol con conjuntos anidados (sección 3.3.5).
Adicional a la restricción en la asociación, los documentos de la colección contienenlos campos propios de cada modelo. La Figura 4.7 muestra la representación de losmodelos con estructura de árbol.
49
4. DIAGRAMAS ORIENTADOS A DOCUMENTOS
_id {:descripcion}children (string) [*]
{child}1
*Automotrices
_id {:descripcion}parent (string)
{parent}
1*
_id {:descripcion}ancestors (string) [*]
{ancestors}
1*
parent (string)
_id {:descripcion}path [*] (string)
{paths}
1*
_id {:descripcion}parent (double)
{nestedSets}
left (double)right (double)
(c)(b)(a)
(e)(d)
AutomotricesAutomotrices
AutomotricesAutomotrices
Figura 4.7: Diagrama que representa los modelos en árbol de la sección 3.3. (a) Con referenciasparentales. (b) Con referencias hijas. (c) Con arreglo de ancestros. (d) Con rutas visibles. (d) Conconjuntos anidados
4.7.2 Composición
Es un tipo de asociación que modela una relación entre un todo y sus partes. Se re-presenta gráficamente como una asociación con un rombo relleno en el extremo del“todo”, como se muestra en la Figura 4.8.
Una “parte” puede ser creada después de crear el “todo”, y sólo se puede ser partede un “todo” a la vez. Si el “todo” es eliminado o desaparece, la “parte” desaparecetambién.
Se representa de forma alternativa poniendo los símbolos de la “parte” dentro del “to-do”, como se muestra en la Figura 4.9.
Una composición se usa normalmente para asociar documentos embebidos o conjun-tos de campos con el elemento de mayor nivel al que pertenecen: como un documento,un documento embebido, o un conjunto de campos.
50
4.7. Relaciones
Vehiculos
marcamodelo
fabricantetamano
referencia
todo del documentoparte de la colección
todo del documento
parte del documento
embebido
relación decontención
relación decomposición
Neumatico
Figura 4.8: Relación de composición
Vehiculos
marca
Neumatico
modelo
fabricantetamano
referencia
colección
documento
documentoembebido
Figura 4.9: Representación alternativa de unacomposición/contención
Las relaciones de composición entre un conjunto de campos y un elemento de mayornivel, siempre cuentan con una restricción de condición definida, junto al extremo deldocumento embebido [36]. Una restricción de condición definida permite determinarcon exactitud los requisitos que se deben cumplir para que los campos del conjunto decampos hagan parte del elemento más general, como se ve en la Figura 4.10.
En el caso de una relación de composición entre un documento embebido y un elemen-to de mayor nivel, la restricción es opcional y se entiende que cuando la composiciónno la lleva, el documento embebido hará parte del elemento de mayor nivel en todoslos casos (Figura 4.8).
Nótese que el campo al que pertenece el documento embebido no se escribe dentrodel elemento de mayor nivel, sino únicamente dentro del símbolo de documento em-bebido, evitando ambigüedades por la aparición del campo en varios elementos. Sinembargo, hay casos en los que todos los campos de un documento o un documentoembebido tienen a su vez documentos embebidos. En estos casos el elemento de nivelsuperior al que pertenecen los documentos embebidos va vacío, como se muestra enla Figura 4.11.a. Para evitar esto se puede optar por la representación alternativa decomposición, como se muestra en la Figura 4.11.b.
51
4. DIAGRAMAS ORIENTADOS A DOCUMENTOS
Figura 4.10: Relación de composición concondición definida
SistemasOperativos
nombreversionbitsProcesador restricción
{nombre: Windows}
antivirusnumLicencia
composición
Figura 4.11: Documento embebido condocumentos embebidos. (a) Con asocia-ción de composición. (b) Con documentoembebido dentro.
Moviles
marca
Hardware
marcaHardware
fabricantefrecuencia
(a) (b)
pantalla
tamanofabricante
procesador
fabricantefrecuencia
Procesador
Pantalla
tamanofabricante
Moviles
Contención
La definición para la asociación de contención es idéntica a la de composición, hacien-do salvedad en que sólo asocia documentos con colecciones. Se representa gráficamen-te como una asociación con una cruz dentro de un círculo en el extremo del “todo”,como es muestra en la Figura 4.8 [32].
Otra forma de representar gráficamente una contención es poniendo el símbolo deldocumento, dentro del símbolo de la colección, como se muestra en la Figura 4.9.
52
4.8. Restricciones
4.8 RESTRICCIONES
Una restricción es un elemento que limita o condiciona la acción de otros elementosen el esquema. MongoDB, al ser libre de esquema, no revisa las restricciones por élmismo, sino que cada restricción presente en un esquema debe ser evaluada del ladode la aplicación.
En un diagrama, una restricción va encerrada dentro de llaves
< ”{”restriccion”}” >
Los operadores para peticiones de MongoDB facilitan la localización de datos y pro-porcionan una idea de las restricciones que puede tener un esquema [37]. Para su usoen diagramas, a estos operadores se les ha asignado un operador matemático (símbo-lo), como se muestra en la Tabla 4.1, y luego se ha especificado su sintaxis en la Tabla4.2.
En la Tabla 4.2, las variables vn hacen referencia a los posibles valores que se puedenrelacionar con un campo (4.1), mientras que las variables en se refieren a las expresionesque pueden haber en una condición (4.2), entendiendo como expresión a un conjuntocampo–valor (4.3)
valor1, valor2, . . . , valorn ≡ v1, v2, . . . , vn : n ∈ Z+ (4.1)
expresion1, expresion2, . . . , expresionm ≡ e1, e2, . . . , em : m ∈ Z+ (4.2)
em = campom <operador> [valorm1, valorm2, . . . , valormn] (4.3)
Para los operadores que no tienen un símbolo asignado como en el caso de $elemMatchy $size, la condición se coloca en el diagrama con la sintaxis de MongoDB.
4.8.1 Restricciones inter-relación
Describen restricciones entre dos o más relaciones. Su notación varía dependiendo silas relaciones tienen un estilo de objetivo compartido, o un estilo de objetivo separado[38].
Para relaciones con estilo de objetivo compartido, basta con poner la restricción junto ala cabeza de flecha, como se ve en la Figura 4.12 . En el caso de relaciones con estilo deobjetivo separado, se dibuja una línea discontinua que conecta con todas las relacionesafectadas, sobre la que se encuentra la restricción, como se muestra en la Figura 4.13.
A continuación se definen dos tipos de restricción que se pueden aplicar a en unarestricción inter-relación [39]
53
4. DIAGRAMAS ORIENTADOS A DOCUMENTOS
Tabla 4.1: Operadores de MongoDB utilizados para peticiones
Operador Símbolo Definición
$eq equal :Encuentra la coincidencia en documentos que tengan el
valor asignado
$gtgreaterthan
>Selecciona los documentos donde el valor del campo es
mayor que el valor especificado
$gtegreaterthan orequal
≥Selecciona los documentos donde el valor del campo es
mayor o igual que el valor especificado
$lt less than <Selecciona los documentos donde el valor del campo es
menor que el valor especificado
$lteless thanor equal
≤Selecciona los documentos donde el valor del campo es
menor o igual que el valor especificado
$ne not equal =Selecciona los documentos donde el valor del campo es
diferente que el valor especificado
$in in ∋Selecciona los documentos donde el valor del campo
equivale a por lo menos uno de los valores especificados
$nin none in
/∈ Selecciona los documentos donde: el valor del campo no seespecifica en el arreglo; el campo no existe
$or or ∨Selecciona los documentos que cumplan con alguna de las
condiciones
$and$all
andall
∧Selecciona los documentos que cumplan con todas las
condiciones del arreglo
$not not ! Selecciona los documentos que no cumplen con la condición
$nor not or ⊉Selecciona los documentos que no cumplen con ninguna de
las condiciones del arreglo (de la expresión)
$exists: true$exists: false
exists∃∄
Selecciona los documentos en los que existe o no (según lacondición) determinado campo
$type type ( )Selecciona los documentos donde el tipo de dato es igual al
especificado
$mod modulo modSelecciona los documentos donde el valor del campo
dividido por el divisor da el residuo especificado
$regexregularexpres-sion
′ ′ Selecciona los documentos donde los valores coinciden conla expresión regular especificada
$elemMatchelementmatch
–Selecciona los documentos que contienen por lo menos un
campo en un arreglo que cumple con el criterio especificado
$size size –Selecciona los documentos en los que el arreglo en un
campo tiene el número de elementos especificados
54
4.8. Restricciones
Tabla 4.2: Sintaxis para el uso de los operadores en diagramas
Símbolo Operador Condición
Asignación : <campo>: <valor>
Mayor > <campo> > <valor>
Mayor o igual ≥ <campo> ≥ <valor>
Menor < <campo> < <valor>
Menor o igual ≤ <campo> ≤ <valor>
Diferente = <campo> = <valor>
Contiene ∋ <campo> ∋ v1, v2, . . . , vn
No contiene
/∈
<campo>
/∈
<valor>
o ∨ e1 ∨ e2 ∨ . . . ∨ en
y ∧ e1 ∧ e2 ∧ . . . ∧ en
Negación ! <campo> !<operador> <valor>
NOR ⊉ ⊉ [e1, e2, . . . en]
ExisteNo existe
∃∄
<campo> ∃<campo> ∄
Tipo ( ) <campo> (<tipo>)
Módulo Mód <campo> mod <divisor> = <residuo>
Expresión regular ′ ′ <campo>: ’<expresión regular>’
$elemMatch <campo>: {$elemMatch: {e1, e2, . . . , en}}
Tamaño $size <campo>: {$size: <número>}
Figuras
tipocolor
ejeMayorejeMenor
numLados
Atletas
nombredisciplina [1..*]talla
distancia altura
{tipo:{tipo:{disciplina ∋salto alto}
{disciplina ∋velocidad}
(a) (b)
{complete,
poligono}elipse}
{incomplete,disjoint}overlapping}
Figura 4.12: Restricción inter-relación con objetivo compartido. (a) Disjunta-Completa. (b)Traslapada-Incompleta
55
4. DIAGRAMAS ORIENTADOS A DOCUMENTOS
Figura 4.13: Restricción inter-relacióncon objetivo separado
Militares
identidad
especialidadhorasCombate
Ejercito
Restricción
horasVueloaviones [1..*]
FuerzaAerea
horasAltamarfuncionNaval
Armada
{disjoint, complete}
inter-relación
Restricción de plenitud En una relación completa (complete) por lo menos uno delos elementos debe hacer parte del elemento de nivel superior. En una relaciónincompleta (incomplete) los elementos pueden o no hacer parte del elementode nivel superior.
Restricción de integridad En una relación disjunta (disjoint) únicamente uno de loselementos puede hacer parte del elemento de nivel superior. En una relación tras-lapada (overlapping) más de uno de los elementos puede hacer parte del ele-mento de nivel superior.
En ese orden, un conjunto de relaciones puede tener las siguientes combinaciones derestricciones plenitud-integridad: {complete, disjoint}, {complete, overlapping},{incomplete, disjoint}, {incomplete, overlapping}.
La Figura 4.13 muestra una restricción inter-relación entre tres asociaciones de compo-sición.
4.9 NOTAS
Son elementos que permiten añadir información textual, como comentarios o restric-ciones, para la explicación de diferentes elementos y sus funcionalidades.
Una nota se representa gráficamente encerrada dentro de un rectángulo con las esqui-nas redondeadas, y cuando se considere necesario, su relación con un elemento se harámediante una línea discontinua, como se ve en la Figura 4.14.
56
4.9. Notas
Exoplanetas
nombre~ apodosistemaSolar
nota
distanciatamano
ampliar eltamaño de losdocumentos a32 MB
Figura 4.14: Anotación relacionada a una co-lección
57
Capítulo
5 Ejemplos de uso
CONTENIDOS DEL CAPÍTULO
5.1 ESQUEMAS SENCILLOS
5.2 LIBRERÍA
5.3 REDES SOCIALES
5.4 UNIVERSIDAD
5.5 MUSEO DE ARTE
En este capítulo se usan los diagramas orientados a documentos del capítulo anterior,para representar diversos ejemplos de esquemas que permitan usar la notación gráficapropuesta.
Durante el desarrollo de los ejemplos, y como se especificó en el capítulo anterior,el campo _id solo se pondrá en los documentos cuando tenga un valor diferente alasignado por defecto por MongoDB.
5.1 ESQUEMAS SENCILLOS
En esta sección se muestra el uso de la notación gráfica para representar los esquemasde los ejemplos del capítulo 3. Los ejemplos usados en el capítulo 3 son cortos y se hanpensado para ejemplificar el uso de los modelos de datos. Es por esto que se agrupantodos en esta sección.
Aunque por lo general el nombre del campo lleva implícito el tipo de campo que sedebe usar en él, en estos ejemplos se coloca el tipo de campo para ejemplificar la formaen que se debe hacer.
59
5. EJEMPLOS DE USO
5.1.1 Modelo Uno-a-Pocos
La estructura del ejemplo de Uno-a-Pocos de la sección 5.1 se representa en la Figura5.1.
Figura 5.1: Diagrama que representa elmodelo Uno-a-Pocos de la sección 3.1.1
Buses
_id {: placa}empresa (string)
dia (string)hora (string)rev (string)
~ Mantenimiento[ ]
tipo (string)ciudad (string)
En el documento de la Figura 5.1 se muestra como el campo _id debe tener como valorla placa del vehículo. Los campos _id, empresa, tipo y ciudad son obligatorios, loque indica que deben estar presentes en todos los documentos representados por esaestructura. Por otra parte, el campo mantenimiento es opcional, lo que se interpretacomo que los documentos de los buses que no tengan programado mantenimiento, notendrán este campo, evitando campos innecesarios.
Nótese también que el campo mantenimiento contiene un arreglo de documentos,ya que un mismo bus puede tener programadas varias revisiones de mantenimiento.
5.1.2 Modelos Uno-a-Muchos y Uno-a-Muchísimos
En la Figura 5.2 se muestra la representación gráfica del ejemplo de Uno-a-Muchosusado en la sección 3.1.2.
La relación de asociación entre las colecciones, muestra la cardinalidad y cómo se usala navegación para indicar qué colección tiene referencias hacia la otra. En este caso, elcampo estudiantes de la colección grupos tendrá referencias a los identificadoresde los documentos de la colección estudiantes.
El modelo Uno-a-Muchísimos se representa en la Figura 5.3.
Comparando los diagramas de las Figuras 5.2 y 5.3 se aprecia con mayor facilidadla diferencia entre los dos modelos. Mientras que el modelo Uno-a-Muchos tiene lasreferencias en el lado de Uno, el modelo Uno-a-Muchísimos tiene las referencias en ellado de Muchos.
60
5.1. Esquemas sencillos
Estudiantes
_id (objectID) {:codigo}nombre (string)carrera (string)facultad (string)num_cel (double)
Grupos
_id (objectID) {:registro}nombre (string)categoria (string)estudiantes (double) [1..*]
1*
Figura 5.2: Diagrama que repre-senta el modelo Uno-a-Muchos dela sección 3.1.2
Usuarios
nombre (string)apodo (string)edad (double)
Busquedas
_id (timeStamp)palabras (string)ubicacion (geospatial)id_usuario (string)
*1
Figura 5.3: Diagrama que representa elmodelo Uno-a-Muchísimos de la sección3.1.3
5.1.3 Refereciación de doble vía
En la sección 3.1.4 se muestra un ejemplo que tiene referencias en las dos direcciones:referencias desde la colección buses hacia la colección rutas y viceversa. En este casola relación de asociación no especifica navegación, indicando que las referencias vanen ambas direcciones, como se muestra en la Figura 5.4.
Buses
_id (string) {:placa}empresa (string)tipo (string)
rutas
_id (objectID) {:n_ruta}origen (string)destino (string)fecha (date)
*1
ciudad (string)id_rutas (string) [1..*] id_bus (string)
Figura 5.4: Diagrama que representael modelo de referenciación de doblevía de la sección 3.1.4
61
5. EJEMPLOS DE USO
5.2 LIBRERÍA
El diagrama desarrollado en esta sección representa el esquema propuesto por [40].Este esquema es la propuesta para una base de datos de una librería que funciona enlínea. Los requisitos con los que cumple el esquema son los siguientes
La información del nombre (firstName) y el apellido (lastName) de los auto-res es almacenada en documentos de la colección Authors.
El nombre de cada usuario (userName) y su respectiva contraseña (password)se almacenan en documentos pertenecientes a la colección Users.
La colección Books contiene toda la información de los libros: title, autor,isbn, slug, available, pages, summary, subjects, language, Publisher.Del editor (Publisher), se almacena el nombre, la fecha y la ciudad.
Los usuarios pueden hacer comentarios a las notas y respuestas a los comentariosde otros usuarios; esta información se almacena en la colección BookNotes. Lasnotas, comentarios o respuestas son ilimitadas y están organizadados de manerajerárquica como se muestra en la Figura 5.5.
Figura 5.5: Jerarquía de notas,comentarios y respuestas
comment
replyreplyreply
book_notes
note
note
reply
reply
replycomment
comment
note
La Figura 5.6 muestra el diagrama resultante para del esquema propuesto.
Siguiendo la sugerencia del autor del esquema, la colección BookNotes se autorefe-rencia con la propiedad ancestors, especificando que sigue el modelo en árbol conarreglo de ancestros. Esto significa que cada nota puede referenciar a una de mayorjerarquía y a su vez las de mayor jerarquía ser reseñas de un libro.
El Listado de código muestra un documento perteneciente a la colección Books.
Listado de código 5.1: Ejemplo de documento resultante de la colección Books de la Figura 5.6{
_id: ObjectID("507f1f77bcf86cd799439011"),
62
5.2. Librería
Authors
firstNamelastName
Books
titleauthor_idisbnslugavailable (boolean)pagessummarysubjects [2]language
namedate (timeStamp)
Publisher
city
BookNotes
book_idlastChangeduser_idnoteparentancestors [ ]
Users
usernamepassword
1 * 1 * 1*
creates reviews writes
{ancestors}*
1
Figura 5.6: Diagrama que representa el esquema de la base de datos de una librería
title: "Cien años de soledad",author_id: "507f191e810c19729de860ea",isbn: 9788420471839,slug: "6-point",available: true,pages: 800,summary: "Es considerada una obra maestra ...",language: "spanish",Publisher: {
name: "Alfaguara",date: Timestamp(1410996356, 1),city: "España"
}}
63
5. EJEMPLOS DE USO
5.3 REDES SOCIALES
El esquema representado en este capítulo se encuentra en la sección 3 de [41] y en elcapítulo 8 de [2]. Este esquema es la propuesta para un sitio de redes sociales y lossiguientes son los requisitos con los que cumple
La colección User almacena la información del nombre de usuario, los contactosy su relación con ellos, además de la información de perfil.
La información sobre las publicaciones del usuario se encuentra en la colecciónPost. Esta colección almacena información sobre los círculos que pueden consul-tar la publicación, el tipo de publicación, los detalles, el autor y los comentariosque se hacen en ella.
En la colección Wall se almacenan las publicaciones creados por un usuario par-ticular. Esta colección registra el usuario que la creo, el _id de la publicación, eltiempo de creación, el número de comentarios a mostrar, el tipo de publicación,entre otros.
La colección Social almacena las publicaciones de otros usuarios que siguen alusuario. El esquema incluye la misma información que la colección Wall.
El diagrama correspondiente para el esquema propuesto se muestra en la Figura 5.7.
En la colección User el tipo de dato usado para el campo _id es base64-encoded.Este tipo de valor no es estándar de MongoDB, sin embargo el autor lo usa así pa-ra luego tomarlo como nombre de campo. En esta misma colección los documentosembebidos se encuentran con la notación alternativa de composición, para evitar re-presentar documentos vacíos, como se explico en la sección 4.7.2.
Los campos <n -user id> y <n -circle name> representan los campos que seráncreados cada vez que se inserte un nuevo usuario o un nuevo nombre de círculo. La va-riable n indica un número arbitrario de usuario o de nombre de círculo. Cada campo deestos tendrá un documento embebido asociado a él, como se muestra en el diagrama.
En las colecciones Post, Wall y Social, el documento embebido asociado al campoDetail varía según el valor asignado al campo type. El campo ts siempre es de tipoISODateTime, pero se obvio en algunos campos por motivo de espacio en la hoja.
El Listado de código 5.2 muestra la estructura de documento que resulta de la colecciónUser.
Listado de código 5.2: Ejemplo de documento resultante de la colección User de la Figura 5.7{
_id: "T4Y...AC",name: "Rick",
64
5.3. Redes sociales
Use
r
_id
(bas
e64-
enco
ded)
nam
e
age
loca
tion
Profi
le
inte
rest
s[]bl
ocke
d[]
phon
e
Follo
wer
s
<n-u
ser
id>
nam
eci
rcle
s[]
Cir
cles
<n-c
ircl
ena
me>
<n-u
ser
id>
nam
e
circ
les
[]ty
pets
(ISO
Dat
eTim
e)
text
Det
ail
text
Det
ail
geo
(geo
spat
ial)
nam
eph
oto
idBy nam
eidBy na
me
tsCom
men
ts[]
{typ
e:{t
ype:
user
_id
mon
th(s
trin
g)id
{:pos
t_id
}ts
(ISO
Dat
eTim
e)
Post
s[]
circ
les
[]ty
peco
mm
ents
_sho
wn
stat
us}
chec
kin}
text
Det
ail
text
Det
ail
geo
(geo
spat
ial)
nam
eph
oto
{typ
e:{t
ype:
stat
us}
chec
kin}
idBy nam
eidBy na
me
tsCom
men
ts[]
user
_id
mon
th(s
trin
g)id
{:pos
t_id
}ts
(ISO
Dat
eTim
e)
Post
s[]
circ
les
[]ty
peco
mm
ents
_sho
wn
text
Det
ail
text
Det
ail
geo
(geo
spat
ial)
nam
eph
oto
{typ
e:{t
ype:
stat
us}
chec
kin}
idBy nam
eidBy na
me
tsCom
men
ts[]
Wal
l
Post
Soci
al
**
* **
** *
*
*
**
Figu
ra5.
7:D
iagr
ama
que
repr
esen
tael
esqu
ema
dela
base
deda
tos
deun
sist
ema
dere
des
soci
ales
65
5. EJEMPLOS DE USO
blocked: ["GH1...0D"],Profile: {
age: 26,location: "near London",interests: ["music", "volleyball"],phone: "(020) 7323 6789",
},Followers: {
"T4Y...AD": {name: "Jared", circles: ["python", "authors"]},"T4Y...AF": {name: "Bernie", circles: ["python"]},"T4Y...AI": {name: "Meghan", circles: ["python", "speakers"]}
}Circles: {
"10Gen": {"T4Y...AD": {name: "Jared"},"T4Y...AE": {name: "Max"}
},"University": {
"T4Y...AF": {name: "Bernie"},"T4Y...AH": {name: "Paul"}
}}
}
5.4 UNIVERSIDAD
Este ejemplo se tomó de la sección 4.3.2 de [36]. A partir de los siguientes requisitos, sepropone un diagrama que representa el esquema de una posible solución.
La base de datos mantiene tres tipos de personas: empleados, ex alumnos y estu-diantes. Una persona puede pertenecer a uno, dos o los tres tipos, y dispone deun nombre, un DNI (Documento Nacional de Identificación), su sexo, su direc-ción y fecha de nacimiento.
Cada empleado dispone de un salario, y se agrupan en tres categorías distintas:personal docente, administrativos y adjuntos. Cada trabajador pertenece a unode los tres grupos. Para los antiguos alumnos se mantiene un registro con la titu-lación máxima conseguida, incluyendo el nombre de dicha titulación, el año deobtención y la especialidad.
Cada profesor tiene un rango, mientras que el personal administrativo cuentacon una posición. Los adjuntos están clasificados como asistentes de investiga-ción o de enseñanza, registrándose en la base de datos el porcentaje de tiempoque trabajan, así como sus proyectos de investigación (los primeros) o el cursoque imparten (los segundos).
66
5.4. Universidad
{complete, disjoint}
{complete, overlapping}
Docentes Administradores Adjuntos
EnsenanzaInvestigacion
{complete, disjoint}
ExalumnosEmpleados Estudiantes
{complete, disjoint}
Activos Diplomados
Personas
Figura 5.8: Diagrama de una universidad con las entidades y sus respectivas relaciones
Los estudiantes están clasificados como diplomados o como estudiantes propia-mente dichos, con los atributos específicos del programa de grado (M.S.m Ph.D.,M.B.A., etc.) o clase (estudiante de primer año, estudiante de segundo año, etc.),respectivamente.
Primero se modelan las entidades como en un modelo relacional y se establecen lostipos de relaciones, como se muestra en la Figura 5.8 [36].
Debido a que todas las relaciones son de generalización, se deja únicamente la entidadde mayor jerarquía Personas. Las entidades que hacen parte de la generalizacióntraslapada (overlapping), se tratan como documentos embebidos, para evitar con-fusiones de campos de diferentes entidades en el mismo documento. Las entidadesque hacen parte de las generalizaciones disjuntas (disjoint), se pueden tratar comoconjuntos de campos que harán parte del documento, gracias a que la naturaleza de larelación no permite que dos campos de diferentes entidades se encuentren en el mismodocumento.
La Figura 5.9 muestra el diagrama del esquema resultante.
La estructura de un documento para una persona titulada que trabaje como investiga-dor sería como la se muestra en el Listado de código 5.3.
67
5. EJEMPLOS DE USO
Personas
salariocategoria
Empleo
_id {:dni}nombresexodireccionnacimiento
tituloano
Titulacion
especialidad
departamento
Estudio
estado
{complete, overlapping}
rango posicion horasTrabtipoAdj
programa
clase
{complete, disjoint} {complete, disjoint}
docente}{categoria:
adjunto}{categoria:
admon}{categoria:
{estado: diplomado}
{estado: activo}
proyectos [ ] curso
{complete, disjoint}
investigación}{tipoAdj:
enseñanza}{tipoAdj:
Figura 5.9: Diagrama que representa el esquema de la base de datos de las personas de unauniversidad
Listado de código 5.3: Ejemplo de documento resultante del esquema de la Figura 5.9{
_id: 123456,nombre: "Sonia Castillo",sexo: "femenino",nacimiento: ISODate("1969-01-11T10:50:57.240Z"),Empleo:{
salario: 1295.24,categoria: "adjunto",horasTrab: 500,tipoAdj: "investigación",proyectos: ["Vestidas de arrugas", "El bufón idiota"]
},
68
5.5. Museo de arte
Titulacion:{titulo: "Maestra en Bellas Artes",ano: 1991,especialidad: "Dr. Ciencias sobre el arte"
}}
5.5 MUSEO DE ARTE
Este ejemplo se tomó del ejercicio 4.20 de [36]. A partir de los siguientes requisitos, sepropone un diagrama que representa el esquema de una posible solución.
El museo dispone de una colección de ObjetosDeArte. Cada uno de ellos cuen-ta con un identificador único (_id), un artista (en caso de conocerse), el añode creación (si se conoce), un titulo y una descripcion. Los objetos estánclasificados de varias formas, tal y como se comentará más adelante.
ObjetosDeArte está categorizada en función a sus tipos, de los cuales hay tresprincipales: pintura, escultura y monumento más un cuarto llamado otropara acomodar a aquellos que no se ajustan a ninguno de los otros tres.
Una pintura tiene un tipoPintura (aceite, al agua, etc.), el material sobreel que está dibujado (papel, lienzo, madera, etc.) y un estiloPintura (mo-derno, abstracto, etc.).
Una escultura o un monumento tiene el material sobre el que fue creado(madera, piedra, etc.), una altura, una anchura y un estiloEscultura.
Un objeto de arte encuadrado en la categoría otro tiene un tipoObra (impre-sión, fotografía, etc.) y un estiloOtro.
Los objetosDeArte están clasificados como una coleccionPermanente (aque-llos que son propiedad del museo) y como prestado. Los datos con los quecontamos del primer tipo son la fechaAdquisicion, su estado (en exhibi-ción, en préstamo o almacenada) y su coste. La información tomada sobre losobjetos de tipo prestado incluye la coleccion propietaria de la misma, sufechaPrestamo y la fechaDevolucion.
La información acerca del país o la cultura de origen (Itala, Egipto, América,India, etc.) y su epoca (Renacimiento, Moderna, Antigua, etc.) se almacena encada objetoDeArte.
69
5. EJEMPLOS DE USO
El museo conserva información sobre el Artista, en caso de conocerse: nombre,fechaNac (si se sabe), fechaFallecimiento (si corresponde), paisOrigen,epoca, estiloPrincipal y descripcion. Se asume que el nombre es undato único.
Se celebran distintas Exhibiciones, cada una con su nombre, fechaInicioy su fechaFinalizacion. Las exhibiciones están relacionadas con los ob-jetos de arte que están en estado de exhibición durante la misma.
También se mantiene información sobre otras Colecciones con las que el mu-seo interactúa, incluyendo su nombre (único), el tipo (museo, personal, etc.),descripción, direccion, telefono y personaContacto actual.
Dado que el problema ha sido planteado para ser resuelto con el modelo relacional,el primer paso es establecer las relaciones entre entidades, como si se tratara de unmodelo relacional [36], como se ve en la Figura 5.10.
Figura 5.10: Diagrama de unmuseo con las entidades y sus res-pectivas relaciones
ObjetosArte * 1
Pintura Escultura Monumento Otro
ColeccionPermanente Prestado
Exhibicion
Artista
Colecciones
{complete, disjoint}
{complete, disjoint}
1 *
1*
3
1
2
4
5
El siguiente paso es simplificar el número de entidades y convertirlos en colecciones,teniendo como referencia los modelos para relaciones 1:N de la sección 3.1. En la Figura5.10 cada una de las relaciones está numerada y se procederá con cada una como seindica a continuación
1. Esta relación de generalización se embebe dentro de la colección de mayor nivelObjetosArte. Aprovechando que es una generalización disjunta (disjoint)y que los campos de cada entidad no se pueden traslapar, se hace una relaciónde composición con condición definida, usando conjuntos de campos para evitarla creación de documentos embebidos.
2. Esta relación de generalización se embebe dentro de la colección de mayor ni-vel ObjetosArte. De igual forma que la generalización anterior, los campos de
70
5.5. Museo de arte
cada entidad se relacionan al documento de mayor nivel mediante una composi-ción y conjuntos de campos, y no mediante un documento embebido.
3. Según los requisitos del problema, un ObjetoArte sólo puede tener un Artista.Sin embargo, un Artista puede asociarse a muchos ObjetosArte, siendo estauna relación Uno-a-Muchos. Dado que contar con la información del artista esmuy importante, se prefiere usar el modelo de referenciación de doble vía (sec-ción 3.1.4). En ese caso, los documentos de la colección Artista tendrán referen-cias hacia los identificadores de los documentos de la colección ObjetosArte yviceversa.
4. Una Exhibicion puede tener muchos ObjetosArte, por lo que se conside-ra una relación Uno-a-Muchos (sección 3.1.2). Los documentos de la colecciónExhibicion tendrán referencias hacia los identificadores de los documentos dela colección ObjetosArte.
5. Una Colección puede tener muchos objetos prestados, por lo que se considerauna relación Uno-a-Muchos. Sin embargo, Es importante encontrar fácilmente laColeccion a la que pertenecen los ObjetosArte, por lo que se usa referencia-ción de doble vía.
La Figura 5.11 muestra el diagrama del esquema resultante.
Una escultura que pertenezca a la colección permanente del museo, tendría una es-tructura de documento como la mostrada en el Listado de código 5.4.
Listado de código 5.4: Ejemplo de documento resultante de la colección ObjetosArte delesquema de la Figura 5.11{
_id: ObjectId("2487a6d60000000000000000"),anoCreacion: 1989,titulo: "La maternidad",descripcion: "Instalada en la plaza Escandalera en España",categoria: "escultura",material: "bronce",altura: "2,46 m",anchura: "1,30 m",estiloEscultura: "figurativo",clasificacion: "colección permanente",fechaAdquisicion: 1996,estado: "exhibición",coste: 00
}
71
5. EJEMPLOS DE USO
ObjetosArte
~ artista_idanoCreaciontitulodescripcioncategoriaclasificacion
{categoria: escultura ∨{categoria:
{complete, disjoint}
categoria: monumento}pintura}
tipoPinturamaterialestiloPintura
materialalturaanchuraestiloEscultura
tipoObraestiloOtro
{categoria:otro}
fechaAdquisicionestadocoste
coleccion_idfechaPrestamofechaDevolucion
{complete,disjoint}
{clasificacion:colección permanente}
{clasificacion: prestado}
Artistas
nombre {unique}fechaNacimiento~ fechaFallecimientopaisOrigenepocaestiloPrincipaldescripcionobjetos_id [1..*]
Exhibiciones
nombrefechaIniciofechaFinobjetos_id [1..*]
Colecciones
nombre {unique}tipodescripciondireccionpersonaContactoobjPrestados_id [1..*]
*
1
crea presta
muestra
11
**
Figura 5.11: Diagrama que representa el esquema de la base de datos de un museo
72
Capítulo
6 Conclusiones y trabajos fu-turos
CONTENIDOS DEL CAPÍTULO
6.1 CONCLUSIONES 6.2 TRABAJOS FUTUROS
6.1 CONCLUSIONES
La notación gráfica permite modelar el esquema de una base de datos orientadaa documentos de MongoDB.
El uso de notación gráfica, simplifica el espacio necesario para representar unesquema. Mientras que representar el esquema mediante documentos en forma-to JSON puede resultar en el uso de mucho espacio, un diagrama representa elmismo esquema en un espacio más reducido.
Al no existir una notación formal para diagramas orientados a documentos, sedefinieron nuevos elementos y se redefinieron otros. Muchos de los elementosusados en esta notación fueron tomados del estándar UML, sin embargo, al serpensado para un uso orientado a objetos, no puede representar totalmente loselementos de un modelo orientado a documentos.
El uso de diagramas permite que el reconocimiento de un modelo de datos en unesquema sea más sencillo. Con un simple cambio en la dirección de navegacióno especificando el modelo en una restricción o una nota, se puede conocer el tipode modelo usado, sin necesidad de hacer una revisión profunda del esquema.
73
6. CONCLUSIONES Y TRABAJOS FUTUROS
6.2 TRABAJOS FUTUROS
Como trabajo futuro se sugiere la implementación de la notación gráfica en una he-rramienta CASE, que permita la generación de documentos a partir de diagramas, yademás, permita el seguimiento del esquema de una base de datos de MongoDB.
La notación propuesta en este trabajo de grado es específica para MongoDB, por lo quese propone hacer una revisión de otros modelos NoSQL orientados a documentos, paraincluirlos en una notación general de Diagramas Orientados a Documentos (DOD).
74
Bibliografía
[1] Standard ECMA-404 – The JSON Data Interchage Format, Ecma InternationalStd., october 2013. [Online]. Available: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
[2] R. Copeland, MongoDB Applied Design Patterns. .O Reilly Media, Inc.", Mar. 2013.
[3] DB-Engines. (2015, Dec.) Db-engines ranking. Solid IT. [Online]. Available:http://db-engines.com/en/ranking
[4] E. F. Codd, “A relational model of data for large sharded data banks,”Information Retrieval, vol. 13, no. 6, Junio 1970. [Online]. Available: http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
[5] D. C. Costa, El modelo relacional y el álgebra relacional. Edi-torial UOC, 2002, ch. 5, pp. 33–50. [Online].Available: http://ocw.uoc.edu/computer-science-technology-and-multimedia/bases-de-datos/bases-de-datos/P06_M2109_02148.pdf
[6] A. Silberschatz, H. F. Korth, and S. Sudarshan, Fundamentos de bases de datos,4th ed. Mc Graw Hill, 2002, ch. 1, p. 4.
[7] P. P.-S. Chen, “The entity-relationship model-toward a unified view of data,”ACM Trans. Database Syst., vol. 1, no. 1, pp. 9–36, Mar. 1976. [Online]. Available:http://doi.acm.org/10.1145/320434.320440
[8] Y. Li and S. Manoharan, “A performance comparison of SQL and NoSQL databa-ses,” in 2013 IEEE Pacific Rim Conference on Communications, Computers and SignalProcessing (PACRIM), Aug. 2013, pp. 15–19.
[9] Z. Parker, S. Poe, and S. V. Vrbsky, “Comparing nosql mongodb to ansql db,” in Proceedings of the 51st ACM Southeast Conference, ser. ACMSE ’13.New York, NY, USA: ACM, 2013, pp. 5:1–5:6. [Online]. Available: http://doi.acm.org/10.1145/2498328.2500047
75
BIBLIOGRAFÍA
[10] A. Boicea, F. Radulescu, and L. I. Agapin, “MongoDB vs Oracle - Database Com-parison,” in 2012 Third International Conference on Emerging Intelligent Data and WebTechnologies (EIDWT), Sep. 2012, pp. 330–335.
[11] MongoDB Inc., MongoDB Documentation Release 3.0.7, Nov. 2015. [Online].Available: https://docs.mongodb.org/v3.0/MongoDB-manual-v3.0.pdf
[12] D. Harris. (2013, Aug) 10gen embraces what it created, becomes mon-godb inc. Gigaom. [Online]. Available: https://gigaom.com/2013/08/27/10gen-embraces-what-it-created-becomes-mongodb-inc/
[13] MongoDB University. (2015, Dec.) Mongodb online courses. [Online]. Available:https://university.mongodb.com/courses
[14] A. Lafuente, Sistemas Distribuidos. Universidad del País Vasco, septiembre2011, ch. 1, pp. 5, 6. [Online]. Available: http://www.sc.ehu.es/acwlaroa/SDI/Apuntes/Cap1.pdf
[15] MongoDB Whitepaper. (2015, Jan.) NoSQL databases explained. MongoDBInc. [Online]. Available: http://www.mongodb.com/nosql-explained?_ga=1.239211718.439952991.1416169248
[16] DB-Engines. (2015, Dec.) Method of calculating the scores of the db-enginesranking. Solid IT. [Online]. Available: http://db-engines.com/en/ranking_definition
[17] Wikipedia. (2015, Dec.) Mongodb. Page Version ID: 693000844. [Online]. Availa-ble: https://en.wikipedia.org/w/index.php?title=MongoDB&oldid=693000844
[18] MongoDB Core Server. (2015, Dec.) Mongodb all versions. MongoDB Inc.[Online]. Available: https://jira.mongodb.org/browse/SERVER
[19] A. Williams. 10gen is now MongoDB to reflect focus onNoSQL database. [Online]. Available: http://techcrunch.com/2013/08/27/10gen-is-now-mongodb-to-reflect-focus-on-nosql-database/
[20] DB-Engines. (2014, jan) Mongodb is the dbms of the year. Solid IT. [Online].Available: http://db-engines.com/en/blog_post/25
[21] M. Whitepaper. (2015, Jan.) Mongodb – the leading nosql database.[Online]. Available: http://www.mongodb.com/leading-nosql-database?_ga=1.247026881.439952991.1416169248
[22] MongoDB Whitepaper. (2015, Jan.) Industries using mongodb. [Online].Available: http://www.mongodb.com/industries
76
Bibliografía
[23] T. Haerder and A. Reuter, “Principles of transaction-oriented database recovery,”ACM Comput. Surv., vol. 15, no. 4, pp. 287–317, Dec. 1983. [Online]. Available:http://doi.acm.org/10.1145/289.291
[24] E. Brewer, “CAP twelve years later: How the rules"have changed,” Computer,vol. 45, no. 2, pp. 23–29, Feb. 2012.
[25] A. Fox and E. Brewer, “Harvest, yield, and scalable tolerant systems,” in Procee-dings of the Seventh Workshop on Hot Topics in Operating Systems, 1999, 1999, pp.174–178.
[26] T. Bray, RFC 7159 – The JavaScript Object Notation (JSON) Data Interchange Format,Internet Engineering Task Force Std., march 2014. [Online]. Available: http://tools.ietf.org/html/rfc7159
[27] BSON Specification, Std. [Online]. Available: http://bsonspec.org/spec.html
[28] A. B. Bondi, “Characteristics of scalability and their impact on performance,”in Proceedings of the 2Nd International Workshop on Software and Performance, ser.WOSP ’00. New York, NY, USA: ACM, 2000, pp. 195–203. [Online]. Available:http://doi.acm.org/10.1145/350391.350432
[29] Hewlett-Packard. (2011, march) Server drive technology. Hewlett-PackardDevelopment Company. [Online]. Available: http://h10032.www1.hp.com/ctg/Manual/c01071496.pdf
[30] W. Zola. (2014, Jun.) 6 rules of thumb for mongodb schema design.MongoDB.org Community Blog. [Online]. Available: http://blog.mongodb.org/post/87200945828/6-rules-of-thumb-for-mongodb-schema-design-part-1
[31] Wikipedia. (2015, Nov.) CamelCase. Page Version ID: 693160183. [Online]. Availa-ble: https://en.wikipedia.org/w/index.php?title=CamelCase&oldid=693160183
[32] J. D. Backer, “Uml model organization with packages and thepackage diagram,” Sparx Systems, Tech. Rep., May 2013. [Online].Available: http://community.sparxsystems.com/white-papers/download/178_e5022ece2af18e1eeb50b9579c92107e
[33] G. Booch, J. Rumbaugh, and I. Jacobson, El lenguaje unificado de modelado: guía delusuario. Pearson Education, 2006.
[34] MongoDB Documentation Project, MongoDB Limits and Thresholds, Dec. 2015.[Online]. Available: https://docs.mongodb.org/manual/reference/limits/
[35] C. C. . T. Agency, Data Modelling. The Stationery Office, 2000, ch. 2, pp. 20, 21.
[36] R. Elmasri and S. Navathe, Fundamentos de sistemas de bases de datos. PearsonEducación, 2007, ch. 4.
77
BIBLIOGRAFÍA
[37] MongoDB Documentation Project, Query and Projection Operators, Dec. 2015.[Online]. Available: https://docs.mongodb.org/manual/reference/operator/query/
[38] OMG, OMG Unified Modeling Language v2.5, 2015, ch. 9.2.5. [Online]. Available:http://www.omg.org/spec/UML/2.5/PDF
[39] C. Coronel, Bases de Datos, Diseño, Implementación y Administración. Cengage Lear-ning Editores, Jun. 2011, ch. 5, pp. 151–153.
[40] E. Stolfo, “Schema design by example,” in MongoDB Melbourne Conferen-ce. mongoDB, Nov. 2012. [Online]. Available: https://www.mongodb.com/presentations/mongodb-melbourne-2012/schema-design-example
[41] MongoDB Documentation Project, MongoDB Use Cases, May 2012.[Online]. Available: https://jira.mongodb.org/secure/attachment/16610/MongoDB-use-cases.pdf
78
