Método de transformación de un esquema entidad-relación en una base de datos con MongoDB

Escuela de Ingeniería Informática TRABAJO FIN DE GRADO Grado en Ingeniería Informática Mención: tecnologías de la información. Método de transformación de un esquema Entidad-Relación en una base de datos con MongoDB. Autor: Rubén de Diego Varona Tutora: Dra. M.ª Mercedes Martínez González A mi padre y mi hermana, sin su ayuda, comprensión y cariño no habría llegado hasta aquí. Resumen. La finalidad de este trabajo de fin de grado es el de proponer una serie de reglas para convertir un diagrama Entidad-Relación en una base de datos no relacional, en concreto con MongoDB. Para lograr dicho objetivo se estudiarán los conceptos teóricos de dicho diagrama, así como la funcionalidad y características necesarias de MongoDB para posteriormente definir un método de transformación de los elementos presentes en un diagrama ER en sus correspondientes elementos en MongoDB, ejemplificando cada una de las transformaciones. Posteriormente se realizará la transformación de un diagrama Entidad-Relación completo en una base de datos con MongoDB utilizando las reglas previamente definidas. Palabras clave Diagrama Entidad-Relación, MongoDB, Bases de datos, NoSQL Abstract. The purpose of this final degree project is to propose a series of rules to convert an Entity- Relationship diagram into a non-relational database, specifically with MongoDB. To achieve this objective, the theoretical concepts of said diagram will be studied, as well as the functionality and necessary characteristics of MongoDB to achieve said conversion. Subsequently, the transformation of a complete entity-relationship diagram will be carried out in a database with MongoDB using the previously defined rules. Key words Entity relationship diagram, MongoDB, Databases, NoSQL Tabla de Contenidos Capítulo 1 Introducción y objetivos. ....................................................................................... 1 1.1 Motivación. ................................................................................................................... 1 1.2 Objetivos ....................................................................................................................... 2 1.3 Planificación. ................................................................................................................. 2 1.3.1 Diagrama de Gantt y cronograma. ........................................................................ 4 1.4 Herramientas utilizadas. ................................................................................................ 5 1.5 Estructura de la memoria. .............................................................................................. 6 1.6 Gestión de riesgos. ........................................................................................................ 6 1.6.1 Tipos de riesgos asociados al proyecto. ................................................................ 7 1.6.2 Exposición a los riesgos. ....................................................................................... 7 1.6.3 Formularios de gestión de riesgos. ........................................................................ 9 Capítulo 2 Diagrama Entidad-Relación. ............................................................................... 19 2.1 Modelo Entidad-Relación. .......................................................................................... 20 2.2 Componentes. .............................................................................................................. 21 2.2.1 Entidades y conjuntos de entidades. .................................................................... 21 2.2.2 Relaciones, conjuntos de entidades y roles. ........................................................ 22 2.2.3 Atributos, valores y conjuntos de valores. .......................................................... 23 2.2.4 Identificador de entidad. ...................................................................................... 27 2.2.5 Grado de una relación. ........................................................................................ 27 2.2.6 Relaciones recursivas. ......................................................................................... 27 2.3 Restricciones. .............................................................................................................. 28 2.3.1 Restricciones de cardinalidad. ............................................................................. 28 2.3.2 Restricciones de participación. ............................................................................ 31 2.3.3 Restricciones de cardinalidad (min, max). .......................................................... 31 2.4 Entidades débiles. Relaciones identificantes. .............................................................. 32 2.5 Entidades asociativas................................................................................................... 33 2.6 Modelo Entidad-Relación extendido. .......................................................................... 34 2.6.1 Especialización. ................................................................................................... 34 2.6.2 Generalización. .................................................................................................... 35 2.6.3 Herencia. ............................................................................................................. 37 2.6.4 Agregación. ......................................................................................................... 37 Capítulo 3 MongoDB. ........................................................................................................... 39 3.1 NoSQL. ....................................................................................................................... 40 3.2 MongoDB. ................................................................................................................... 43 3.3 Colecciones y documentos. ......................................................................................... 43 3.4 Tipos de datos en MongoDB. ...................................................................................... 45 3.4.1 ObjectID. ............................................................................................................. 46 3.5 Operaciones MongoDB. .............................................................................................. 47 3.5.1 Creación/cambio base de datos. .......................................................................... 47 3.5.2 Creación de colecciones. ..................................................................................... 47 3.5.3 Creación/inserción de documentos. ..................................................................... 49 3.5.4 Actualización de documentos. ............................................................................. 50 3.5.5 Borrado de documentos. ...................................................................................... 51 3.5.6 Operaciones de consulta. ..................................................................................... 51 Capítulo 4 Reglas de transformación de un esquema Entidad-Relación a una base de datos con MongoDB. ............................................................................................................................ 53 4.1 Entidades. .................................................................................................................... 54 4.1.1 Transformación de entidades en MongoDB. ....................................................... 55 4.2 Atributos. ..................................................................................................................... 60 4.2.1 Atributo identificador. ......................................................................................... 61 4.2.2 Atributos simples y compuestos. ......................................................................... 63 4.2.3 Atributos mono valuados y multivaluados. ......................................................... 66 4.2.4 Atributos derivados. ............................................................................................ 68 4.2.5 Atributos requeridos y opcionales. ...................................................................... 68 4.3 Relaciones. .................................................................................................................. 70 4.3.1 Relaciones uno a uno. .......................................................................................... 71 4.3.2 Relaciones uno a muchos. ................................................................................... 79 4.3.3 Relaciones muchos a muchos. ............................................................................. 89 4.4 Transformación jerarquía ISA (generalización/especialización). .............................. 107 4.5 Entidades asociativas................................................................................................. 115 4.6 Relaciones recursivas. ............................................................................................... 121 4.7 Agregación. ............................................................................................................... 124 4.8 Tabla resumen reglas de transformación. .................................................................. 128 Capítulo 5 Ejemplo de transformación. .............................................................................. 133 5.1 Requisitos. ................................................................................................................. 134 5.2 Diagrama Entidad-Relación. ..................................................................................... 135 5.2.1 Entidades y atributos. ........................................................................................ 136 5.2.2 Relaciones. ........................................................................................................ 137 5.3 Creación de la base de datos. .................................................................................... 139 5.4 Conversión de entidades. ........................................................................................... 139 5.4.1 Entidades fuertes. .............................................................................................. 139 5.4.2 Entidades de la jerarquía ISA. ........................................................................... 149 5.4.3 Entidades débiles. .............................................................................................. 152 5.5 Conversión de relaciones. ......................................................................................... 153 5.5.1 Obtención del valor ObjectID. .......................................................................... 153 5.5.2 Relaciones uno a uno. ........................................................................................ 154 5.5.3 Relaciones uno a muchos. ................................................................................. 155 5.5.4 Relaciones muchos a muchos. ........................................................................... 157 5.5.5 Relaciones recursivas. ....................................................................................... 162 5.6 Tabla resumen conversión. ........................................................................................ 163 Capítulo 6 Conclusiones y Trabajo Futuro.......................................................................... 165 6.1 Objetivos alcanzados. ................................................................................................ 165 6.2 Conclusiones del trabajo ........................................................................................... 165 6.3 Experiencia personal. ................................................................................................ 165 6.4 Trabajo futuro. ........................................................................................................... 166 Referencias. ............................................................................................................................... 168 Anexo A. Tablas con relaciones existentes entre las instancias. ............................................... 170 Anexo B. ................................................................................................................................... 175 Enlaces adicionales ................................................................................................................... 175 Lista de figuras. Figura 1.1 Diagrama de Gantt y cronograma. ............................................................................... 5 Figura 2.1 Conjuntos de entidades e instancias. .......................................................................... 21 Figura 2.2 Representación de entidad. ........................................................................................ 22 Figura 2.3 Representación de relación. ....................................................................................... 22 Figura 2.4 Rol de una entidad en una relación. ........................................................................... 23 Figura 2.5 Representación de atributo. ........................................................................................ 24 Figura 2.6 Representación de atributo compuesto. ..................................................................... 25 Figura 2.7 Representación de atributo multi-valuado. ................................................................ 25 Figura 2.8 Representación de atributo clave. .............................................................................. 25 Figura 2.9 Representación de atributo derivado. ......................................................................... 26 Figura 2.10 Atributos de una relación. ........................................................................................ 26 Figura 2.11 Identificador de entidad. .......................................................................................... 27 Figura 2.12 Relación ternaria. ..................................................................................................... 27 Figura 2.13 Relación recursiva. ................................................................................................... 28 Figura 2.14 Cardinalidad mínima y máxima. .............................................................................. 29 Figura 2.15 Cardinalidad mínima y máxima. .............................................................................. 29 Figura 2.16 Relación 1 a 1. ......................................................................................................... 30 Figura 2.17 Relación 1 a muchos. ............................................................................................... 30 Figura 2.18 Relación muchos a muchos. ..................................................................................... 30 Figura 2.19 Restricción total y parcial. ....................................................................................... 31 Figura 2.20 Relación min, max. .................................................................................................. 32 Figura 2.21 Entidades fuertes y débiles. ..................................................................................... 32 Figura 2.22 Relación identificante. ............................................................................................. 33 Figura 2.23 Discriminadores de entidades débiles. ..................................................................... 33 Figura 2.24 Entidad asociativa. ................................................................................................... 34 Figura 2.25 Relación ISA. ........................................................................................................... 35 Figura 2.26 Generalización y especialización. ............................................................................ 36 Figura 2.27 Especialización total. ............................................................................................... 36 Figura 2.28 Especialización parcial. ........................................................................................... 37 Figura 2.29 Agregación. .............................................................................................................. 38 Figura 3.1 Base de datos en MongoDB ....................................................................................... 44 Figura 4.1 Entidades débiles y fuertes. ....................................................................................... 54 Figura 4.2 Entidades débiles y fuertes. ....................................................................................... 55 Figura 4.3 Entidades a colecciones. ............................................................................................ 55 Figura 4.4 Ejemplo conversión entidades. .................................................................................. 56 Figura 4.5: Entidades débiles incrustadas. ................................................................................. 57 Figura 4.6 Entidades débiles incrustadas. ................................................................................... 57 Figura 4.7 Ejemplo entidad débil. ............................................................................................... 58 Figura 4.8 Ejemplo atributos diagrama ER. ................................................................................ 60 Figura 4.9 Ejemplo atributos diagrama ER. ................................................................................ 61 Figura 4.10 Ejemplo atributo identificador diagrama ER. .......................................................... 62 Figura 4.11 Atributos simples ER. .............................................................................................. 64 Figura 4.12 Atributos compuestos ER. ....................................................................................... 64 Figura 4.13 Atributos compuestos ER. ....................................................................................... 65 Figura 4.14 Atributos multi-valuados ER. .................................................................................. 66 Figura 4.15 Ejemplo atributo multi-valuado ER. ........................................................................ 67 Figura 4.16 Ejemplo atributo derivado ER. ................................................................................ 68 Figura 4.17 Ejemplo atributo requerido ER. ............................................................................... 69 3 Planificación del proyecto 13/08/2023 05/09/2023 24 días Identificación de tareas Identificar, estudiar y describir cada una de las tareas o hitos que se van a llevar a cabo durante la ejecución del proyecto. 13/08/2023 15/08/2023 3 días Determinar la duración de las tareas Determinar la duración de cada una de las secciones de las que va a constar el proyecto. 16/08/2023 17/08/2023 2 días Identificación de los recursos. Identificar los recursos necesarios para la elaboración de cada una de las tares del proyecto. 18/08/2023 18/08/2023 1 día Instalación y análisis de recursos. Instalar, analizar y probar los recursos necesarios para la ejecución del proyecto. 19/08/2023 24/08/2023 6 días Identificación y análisis de riesgos. Identificar los riesgos a los que nos podemos enfrentar durante el desarrollo del proyecto. Documentar, analizar, describir y trazar una estrategia para enfrentarnos a ellos. 25/08/2023 05/09/2023 12 días Introducción y objetivos. 06/09/2023 18/09/2023 13 días Documentación “Introducción y objetivos”. Elaborar la documentación referente a esta primera etapa del proyecto. 06/09/2023 18/09/2023 13 días Diagrama Entidad-Relación. 15/09/2023 21/10/2023 37 días Búsqueda de información diagrama Entidad-Relación. Búsqueda de información del modelo Entidad- Relación. En particular del diagrama Entidad- Relación 15/09/2023 23/09/2023 9 días Estudio diagrama Entidad-Relación. Estudio del diagrama Entidad-Relación. Base, teoría y usos del mismo. 24/09/2023 24/09/2023 1 día Adquisición, instalación y estudio de herramientas necesarias. Adquirir y usar para su mejor entendimiento una serie de herramientas necesarias para el estudio y posterior ejemplificación de los diferentes casos. 25/10/2023 30/10/2023 6 días Documentación “Diagrama Entidad- Relación”. Elaborar la documentación referente a este segundo capítulo de la memoria. 01/10/2023 21/10/2023 21 días MongoDB 28/10/2023 21/11/2023 26 días Búsqueda de información sobre MongoDB Búsqueda de la información necesaria para familiarizarse con esta base de datos y su funcionalidad 28/10/2023 06/11/2023 10 días 4 Documentación “MongoDB”. Elaborar la documentación referente a este capítulo de la memoria 07/11/2023 22/11/2023 16 días Reglas de transformación 22/11/2023 26/02/2024 97 días Creación de las bases teóricas de transformación. Ejemplificación de cada una de ellas. Estudio, creación y ejemplificación de cada una de las reglas de transformación del modelo Entidad- Relación a MongoDB 22/11/2023 02/02/2024 73 días Documentación “Reglas de transformación de un diagrama Entidad-Relación en una base de datos con MongoDB”. Elaborar la documentación referente a este capítulo de la memoria. 03/01/2024 26/02/2023 24 días Ejemplo transformación completo. 28/02/2024 20/03/2024 22 días Creación de un diagrama Entidad- Relación completo. Creación de un diagrama ER para su posterior transformación. 28/02/2024 29/02/2024 2 días Creación instancias/colecciones/documentos. Creación de las instancias que van a poblar la base de datos. 01/02/2024 02/03/2024 2 días Transformación del diagrama creado en una base de datos con MongoDB. Creación de las colecciones, documentos y referencias en estos para obtener la base de datos final. 03/03/2024 08/03/2024 6 días Documentación “Ejemplo de transformación de un diagrama ER en una base de datos con MongoDB”. Elaborar la documentación referente a este capítulo de la memoria. 09/03/2024 20/03/2024 41 días Revisión completa 19/03/2024 27/03/2024 9 días Revisión, corrección de errores, ampliación de ejemplos 19/03/2024 27/03/2024 9 días Revisión, corrección de errores, ampliación de la memoria 14/05/2024 22/05/2024 8 días Tabla 1.1 Planificación temporal del proyecto. 1.3.1 Diagrama de Gantt y cronograma. A continuación, se muestra el cronograma únicamente para las tareas principales de la tabla anterior. Para cada una de las tareas mostramos el nombre de la misma, la duración en días entre la fecha de comienzo y la fecha de fin y una visualización gráfica de la carga de cada tarea principal a lo largo del tiempo de realización del proyecto. [Figura 1.1] 5 Figura 1.1 Diagrama de Gantt y cronograma. 1.4 Herramientas utilizadas. Para la realización de este proyecto ha sido necesario el uso de una máquina con doble instalación de sistema operativo. En una partición (usada para realizar los diagramas ER y la memoria de la práctica) Windows en su versión 11. En otra partición Ubuntu, concretamente la versión 22.04.3 LTS de 64 bits con las características que podemos observar en la tabla [Tabla 1.2] para el proceso de crear la base de datos con MongoDB y la realización de todos los ejemplos que acompañan a la misma. CPU RAM Disco Marca Arquitectura Frec. (GHz) Núcleos 8 GB 256 GB Dell Inc. Vostro 3590 x86_64 1.60 8 Tabla 1.2 Hardware utilizado para la elaboración del proyecto. Para la creación del cronograma se ha utilizado Microsoft Project en su versión 2021. Para la figura del diagrama de Gantt mostrada en esta memoria se utilizó Microsoft Office en su versión 2021 (con los datos previamente creados con Microsoft Project) debido a la expiración de la licencia de esta última herramienta. Para la creación de los distintos diagramas Entidad-Relación se ha decidido utilizar el software DIA en su versión 0.97.2 La versión de MongoDB con la que se han creado las distintas bases de datos y los ejemplos contenidos en este proyecto ha ido variando a lo largo de su desarrollo siendo la 7.0.7 la utilizada para realizar las conversiones y ejemplos finales incluidos en esta memoria. Finalmente se ha utilizado una máquina con sistema operativo Windows para la creación de la memoria de este TFG. 6 1.5 Estructura de la memoria. Capítulo 1: Motivación general y personal sobre la elección del tema de este presente proyecto. Detalles sobre el equipo y software necesarios para su elaboración. Objetivos, planificación general del proyecto y plan de riesgos y soluciones en caso de que se presente alguno de ellos. Capítulo 2: Introducción y conceptos básicos del diagrama Entidad-Relación. Descripción de los diferentes componentes del mismo, necesarios para posteriormente, a partir de cada uno de ellos, convertirlos en una base de datos con MongoDB. Capítulo 3: Introducción a la base de datos NoSQL MongoDB. Terminología, características, componentes y funcionamiento. Capítulo 4: Estudio de las reglas para transformar cada uno de los componentes de un esquema Entidad-Relación en una base de datos en MongoDB manteniendo las restricciones del modelo de partida. Para cada regla de transformación se realizará un ejemplo de conversión del elemento perteneciente al diagrama ER en su equivalente en MongoDB. Capítulo 5: Conversión de un diagrama Entidad-Relación completo en una base de datos en MongoDB aplicando las reglas descritas en el capítulo 4. Capítulo 6: Conclusiones y líneas de trabajo futuras. 1.6 Gestión de riesgos. La planificación que se llevará a cabo durante la realización de este proyecto está descrita en el apartado [1.3] de esta misma memoria. A la hora de realizar dicha planificación se han intentado tener en cuenta todos los posibles riesgos asociados a la elaboración del proyecto. Una vez identificados los riesgos que pueden aparecer durante el periodo de ejecución del mismo se ha procedido a su división en categorías atendiendo a su tipo y, posteriormente, se ha procedido a la elaboración de una serie de formularios en los que se describen los mismos, se resume su naturaleza, implementa un plan de acción ante su posible aparición y se detallan las posibles actuaciones en caso de producirse. Asimismo, se ha evaluado y asignado una probabilidad de aparición, así como el nivel de impacto que supondría y un plan de contingencia. 7 1.6.1 Tipos de riesgos asociados al proyecto. - Riesgos de personal. - Enfermedad. - Falta de conocimiento. - Falta de destreza con las herramientas. -Riesgos de Hardware. - Obsolescencia de materiales. - Catástrofe externa. - Caída de la red del sistema. -Riesgos de Seguridad. - Desastre natural. -Riesgos de planificación. - Decisiones incorrectas. - Recursos insuficientes. -Riesgos de desarrollo. - Cambio de versión de la herramienta 1.6.2 Exposición a los riesgos. Factor Probabilidad Consecuencia Impacto Enfermedad. Media 3-4 días Medio Falta de conocimiento. Alta 6 días Medio Falta de destreza con las herramientas. Media 3 días Medio Obsolescencia de los materiales. Baja 2 días Bajo Catástrofe externa. Baja 15 días Alto Caída de la red del sistema. Media 2 días Medio Desastre natural Baja 10 días Alto Decisiones incorrectas. Media 5 días Medio 8 Recursos insuficientes Media 4 días Medio Cambio de versión de la herramienta Baja 2 días Bajo Exposición Total 53 días Tabla 1.3 Exposición a riesgos 9 1.6.3 Formularios de gestión de riesgos. FORMULARIO DE GESTIÓN DE RIESGOS. Número: 01 Fecha: 09/2023 Categoría de riesgo: Riesgos de personal Título de riesgo: Enfermedad. Probabilidad: Media Consecuencia: 3-4 días Marco de tiempo: Todo el proyecto Proyecto: TFG Rubén de Diego Varona Fase: Todas. Impacto: Alto EVALUACIÓN DEL RIESGO. Descripción del riesgo: Durante el tiempo de desarrollo del proyecto debido a enfermedad o indisposición del encargado de llevar a cabo el proyecto, es imposible avanzar en el mismo o de realizar las tareas asignadas para ese periodo de tiempo Contexto del riesgo: Durante el desarrollo del proyecto se produce una parada en el desarrollo del proyecto debido a enfermedad o indisposición del encargado de llevarlo a cabo. Análisis del Riesgo: Presente durante todo el tiempo necesario para desarrollar el proyecto. PLANIFICACIÓN DEL RIESGO. Estrategia: Plan de acción frente a riesgos: El conjunto de tareas que se iban a realizar en el periodo de tiempo descrito son pospuestas, sin que ello lleve un incremento importante en el tiempo destinado al cómputo total del proyecto, ya que la carga de trabajo perdida se repartiría en días posteriores • Evitación. • Protección. • Reducción. • Investigación. • Reserva. • Transferencia. Objetivos cuantitativos. Plan de acción frente a riesgos: Reservar el riesgo. La tarea o conjunto de tareas que se iban a realizar en ese periodo de tiempo se realizarán posteriormente aumentando la carga de trabajo hasta la correcta resolución de las mismas. Indicador: Desde que se para el proyecto debido a Indisposición o enfermedad. Umbral: Desde que el encargado de llevar a cabo el proyecto es incapaz de continuar con el debido a una enfermedad o indisposición hasta que se recupera y el desarrollo retoma la normalidad. Disipador: Se produce la enfermedad o indisposición y el desarrollo del proyecto se pausa. Tabla 1.4 Riesgo 01. Enfermedad. 10 FORMULARIO DE GESTIÓN DE RIESGOS. Número: 02 Fecha: 09/2023 Categoría de riesgo: Riesgos de personal Título de riesgo: Falta de conocimiento. Probabilidad: Alta Consecuencia: 6 días. Marco de tiempo: Todo el proyecto Proyecto: TFG Rubén de Diego Varona Fase: Todas. Impacto: Medio EVALUACIÓN DEL RIESGO. Descripción del riesgo: La persona encargada de llevar a cabo el proyecto es incapaz de llevar a cabo alguna de las fases del mismo debido a falta de conocimientos sobre algún determinado aspecto de esa fase Contexto del riesgo: Llegados a un determinado punto del proyecto, el encargado de llevarlo a cabo es incapaz de realizar alguna de las partes del proyecto debido a la falta de conocimientos sobre el mismo. Análisis del Riesgo: Riesgo siempre presente debido al tipo de proyecto realizado. PLANIFICACIÓN DEL RIESGO. Estrategia: Plan de acción frente a riesgos: Estrategia de investigación en fases preliminares de desarrollo del proyecto. En caso de presentarse una vez avanzado reservar tiempo suficiente para afianzar el conocimiento • Evitación. • Protección. • Reducción. • Investigación. • Reserva. • Transferencia. Objetivos cuantitativos. Plan de acción frente a riesgos: En caso de producirse este riesgo, pedir ayuda externa o aumentar los conocimientos sobre la información relevante a esa parte mediante bibliografía o fuentes externas y necesaria para poder seguir avanzando. Indicador: el realizador del proyecto es incapaz de realizar una determinada tarea. Umbral: Desde el momento en que se conoce el hecho hasta que se soluciona. Disipador: Se es consciente de la incapacidad para realizar una determinada tarea. Tabla 1.5 Riesgo 02. Falta de conocimiento. 11 FORMULARIO DE GESTIÓN DE RIESGOS. Número: 03 Fecha: 09/2023 Categoría de riesgo: Riesgos de personal. Título de riesgo: Falta de Destreza con las herramientas. Probabilidad: Media Consecuencia: 3 días Marco de tiempo: Todo el proyecto Proyecto: TFG Rubén de Diego Varona Fase: Todas. Impacto: Media EVALUACIÓN DEL RIESGO. Descripción del riesgo: Durante la realización del proyecto, la persona que lo está llevando a cabo es incapaz de continuar alguno de los procesos del mismo debido a la falta de destreza o ausencia de conocimiento de alguna herramienta necesaria para la finalización del mismo, más concretamente MongoDB. Contexto del riesgo: Durante el desarrollo del proyecto se es incapaz de seguir avanzando debido a la falta de destreza en el uso de alguna de las herramientas. Análisis del Riesgo: Riesgo siempre presente debido a la ausencia de uso en determinadas herramientas, más concretamente MongoDB. PLANIFICACIÓN DEL RIESGO. Estrategia: Plan de acción frente a riesgos: Investigación y búsqueda de recursos necesarios para solventar dicha carencia fuera de los tiempos previamente previstos en la planificación. • Evitación. • Protección. • Reducción. • Investigación. • Reserva. • Transferencia. Objetivos cuantitativos. Plan de acción frente a riesgos: Petición de ayuda a una persona con conocimientos superiores y/o aprendizaje activo buscando documentación y literatura referente a MongoDB. Indicador: El encargado de llevar a cabo el proyecto es consciente de que no puede continuarlo debido a la falta de destreza en alguna de las herramientas. Umbral: Desde que se es consciente de la carencia hasta que se solventa por medio del aprendizaje. Disipador: Ausencia de capacidades para la realización de alguna de las fases del proyecto. Tabla 1.6 Riesgo 03. Falta de destreza con las herramientas. 12 FORMULARIO DE GESTIÓN DE RIESGOS. Número: 04 Fecha: 09/2023 Categoría de riesgo: Riesgos de hardware. Título de riesgo: Obsolescencia de materiales. Probabilidad: baja. Consecuencia: 2 días Marco de tiempo: Todo el proyecto Proyecto: TFG Rubén de Diego Varona Fase: Todas. Impacto: Bajo EVALUACIÓN DEL RIESGO. Descripción del riesgo: El equipo utilizado para la realización del proyecto queda obsoleto antes de finalizar el proyecto. Contexto del riesgo: Durante el desarrollo del proyecto el material utilizado para llevarlo a cabo nos percatamos de la existencia de un problema de obsolescencia en alguno de los materiales necesarios para la consecución de la práctica. Análisis del Riesgo: Si en la fase de análisis previa al proceso de ejecución del proyecto se tiene en cuenta este riesgo, es poco probable que cause problemas, aunque es un riesgo que va a estar siempre presente. PLANIFICACIÓN DEL RIESGO. Estrategia: Plan de acción frente a riesgos: Previsión en las fases previas del desarrollo del proyecto. • Evitación. • Protección. • Reducción. • Investigación. • Reserva. • Transferencia. SEGUIMIENTO DEL RIESGO. Objetivos cuantitativos. Plan de acción frente a riesgos: mantener el equipo actualizado y prever los elementos hardware y software necesarios para la finalización del proyecto. En caso de obsolescencia o ruptura de componentes hardware reemplazar los mismos en el menor tiempo posible. Indicador: El equipo es insuficiente para finalizar el proyecto o alguno de los componentes deja de funcionar correctamente. Umbral: Desde que el equipo deja de funcionar correctamente o sufre la ruptura de unos sus componentes hasta que el mismo es reemplazado. Disipador: El equipo queda obsoleto o alguno de sus componentes imposibilita el correcto desarrollo del proyecto. Tabla 1.7 Riesgo 04. Obsolescencia de materiales. 19 Capítulo 2 Diagrama Entidad-Relación. La finalidad de este proyecto es definir una serie de reglas para transformar un diagrama Entidad-Relación en una base de datos con MongoDB. Para lograr este objetivo es necesario, en primer lugar, conocer las características de dicho diagrama y los fundamentos teóricos en los que se basa. En este capítulo explicaremos los conceptos básicos del modelo Entidad-Relación, del cual depende el diagrama asociado, el cual será el punto de partida para la realización de la transformación en una posterior base de datos. Se estudiarán los dos componentes principales del diagrama: las entidades y las relaciones, así como sus características propias, los distintos tipos de atributos, las relaciones entre entidades dependiendo de su participación en las mismas, las restricciones a dicho diagrama y algunas de las características extendidas que fueron implementándose a lo largo de los años tras la aparición de este modelo. 20 2.1 Modelo Entidad-Relación. En el año 1977 Peter Chen, un informático especializado en la teoría de las bases de datos, publicó un artículo “The entity-relationship model: towards a unified view of data”. 3 Esta es la primera vez que aparece el concepto Entidad-Relación. En este artículo Chen propuso un nuevo modelo de datos [2]. Dicho modelo describe aspectos de un dominio específico de conocimiento, relacionados entre sí, cuya información es necesaria para almacenarla en una futura base de datos Su principal finalidad era ofrecer una técnica basada en esquemas como herramienta para diseñar bases de datos. Los componentes del diagrama son dos conceptos principales: el de entidades y el de relaciones, así como una serie de restricciones de ellas. Hasta ese momento se consideraban tres principales modelos da datos: el modelo de red, el relacional y el de conjunto de entidades. Chen consideraba que cada uno de esos tres modelos tenía una serie de ventajas y desventajas. El modelo de red proporcionaba una visión natural de los datos debido a la distinción que realizaba entre las relaciones y las entidades. El modelo relacional (basado en la teoría relacional) tenía la desventaja de perder información semántica del mundo real, sin embargo, lograba una gran independencia de los datos, y por último el modelo de conjuntos de entidades (basado en la teoría de conjuntos), al igual que el modelo relacional, lograba obtener un alto grado de independencia de los datos, sin embargo, la visión de ciertos valores de esos conjuntos podía no ser natural para ciertos desarrolladores. Este nuevo modelo propuesto por Chen (basado en la teoría de conjuntos y en la teoría de las relaciones) denominado modelo Entidad Relación quería alcanzar también un alto grado de independencia de los datos, así como una visión natural de los mismos. y quería sentar las bases para realizar una visión unificada de los datos. No se desprendía de ellos, ya que estaba basado en los mismos, sino que lo exponía como una extensión de los ya existentes. Este modelo es un modelo conceptual y, a día de hoy, sigue siendo uno de los más utilizados a hora de diseñar una base de datos en muchas organizaciones. La expresión gráfica del modelo definido por Chen se denomina esquema Entidad-Relación, el cual utiliza una serie de figuras para representar los componentes del modelo. A lo largo del presente capítulo se estudiarán los componentes del modelo, así como su representación gráfica. Las principales características de un esquema Entidad-Relación son: 4 - Completo: El esquema ha de Representar todas las características del dominio de la aplicación. - Correcto: Ha de utilizar correctamente aquellos conceptos definidos en el modelo Entidad-Relación. - Mínimo: Cada uno de los aspectos de los requerimientos aparece una única vez en el esquema, no debe haber duplicados. 3 Peter Pín-Shan Chen “The entity-relationship model: towards a unified view of data”. March 1977 4 Dra. M.ª Mercedes Martínez González, Carmen Hernández Díez “Apuntes de la asignatura bases de datos” ETSII Uva 21 - Expresivo: Ha de representar todos los requerimientos necesarios de una forma natural. 2.2 Componentes. Como su propio nombre indica, los dos componentes principales del modelo Entidad-Relación son, las entidades y las relaciones existentes entre esas mismas entidades. 2.2.1 Entidades y conjuntos de entidades. Las entidades (las cuales denotaremos e) son aquellos objetos del mundo real sobre los que deseamos almacenar información. Son algo que existe y se puede diferenciar de otras. Podemos decir que las entidades son objetos que forman parte de un universo. Este universo será dado por la organización para la que haremos la base de datos o la aplicación sobre la que deseamos crear una aplicación. Estos objetos pueden ser tanto reales (una persona específica, el actor de una película…) como abstractos (un determinado suceso, la crítica de una película…). Ejemplos de entidades son un actor llamado Miguel, una película que se titula 2001 o un cine situado en Valladolid con nombre Roxy. Una entidad no es una propiedad concreta, sino un objeto que tiene varias propiedades (a las que llamaremos atributos). Todas aquellas entidades que tienen las mismas propiedades forman conjuntos de entidades (o tipos de entidad) (denotada por Ei) [Figura 2.1]. Ejemplos de conjuntos de entidades son el conjunto de todos los Actores, el conjunto de todas las Películas, o el conjunto de las Críticas de una película… Una instancia de entidad es una única ocurrencia de un conjunto de entidad [Figura 2.1]. Por ejemplo, dado el conjunto de todas las Películas, una instancia concreta de este conjunto, sería la película con título 2001. Figura 2.1 Conjuntos de entidades e instancias. 22 Existe una implicación asociada a este hecho, si sabemos que una determinada película forma parte del conjunto de entidades Pelicula, dicha película va a tener un conjunto de características iguales al resto de elementos que forman parte de ese conjunto de Películas. En el diagrama Entidad-Relación las entidades están representadas por un rectángulo. [Figura 2.2] Figura 2.2 Representación de entidad. Existen varios tipos de entidades atendiendo a los atributos de las mismas o a las relaciones que estas poseen, pero antes de definirlos necesitamos conocer ciertos conceptos que veremos a lo largo de este capítulo. Identificar las entidades es el primer objetivo a la hora de realizar un esquema Entidad-Relación. 2.2.2 Relaciones, conjuntos de entidades y roles. Una relación es la asociación entre dos o más entidades. También forman parte del universo al que nos hemos referido en la definición de entidad. De forma matemática y utilizando la teoría de conjuntos si tenemos dos conjuntos A y B, entonces R (una relación) es un subconjunto de A y B. Refiriéndonos a entidades y no conjuntos, R es un subconjunto de las entidades A y B. Por ejemplo, la relación entre una determinada película y el director que la dirige, o esa misma película y la reseña que han escrito sobre ella. Entre estos ejemplos existe una relación, la película es dirigida por un director (o un director dirige una determinada película) y la reseña es escrita por un determinado crítico (o un crítico escribe una reseña). Debemos tener en cuenta que los conjuntos de entidades pueden, pero no tienen por qué ser, necesariamente disjuntos. Una entidad Director puede ser una entidad Actor, una entidad Actor puede pertenecer a la vez a Director o no serlo. Identificar estas relaciones es el segundo objetivo a la hora de la realizar el esquema Entidad-Relación. En el diagrama Entidad-Relación las relaciones están representadas por un rombo. [Figura 2.3] Figura 2.3 Representación de relación. 23 Si consideramos la asociación entre entidades, un conjunto de relaciones (detonada por Ei) es una relación matemática entre n entidades (siendo n mayor o igual a 2) (n>=2), cada una de ellas tomada de un conjunto de entidades. {[ e 1, e 2, …, e n] | e1 ∈ E1, e2 ∈ E2, …, en ∈ En} Y cada una de las tuplas de entidades [e1, e2, …, en], es una relación. Por ejemplo: (Steven Spielberg, Tiburón) ∈ Dirige . Dirige es una relación entre la Película Tiburón y el Director Steven Spielberg. El rol de una entidad (denotado por r) en una relación es la función que dicha entidad realiza en esa relación. Los roles representan la función de un conjunto de entidades en un conjunto de relaciones. Mientras que en el diagrama Entidad-Relación los nombres tanto de las relaciones como de las entidades son necesarios, en el caso de los roles esto no es así. Siguiendo el ejemplo anterior, un director tiene el rol de dirigir una película o un actor el de actuar en ella. En el diagrama Entidad-Relación son las líneas rectas que vinculan las entidades con las relaciones. [Figura 2.4] Figura 2.4 Rol de una entidad en una relación. 2.2.3 Atributos, valores y conjuntos de valores. La información que poseen tanto las relaciones como los atributos se expresan por un conjunto de atributos. Estos conjuntos de atributos son comunes a las entidades que pertenecen a un conjunto de entidades o a las relaciones que pertenecen a un conjunto de relaciones. Cuando deseamos almacenar el conjunto de entidades que forman parte de un universo, todo este conjunto tendrá una serie de características (atributos), sin embargo, cada una de estas tendrá un valor que hará que se diferencien unas de otras instancias dentro de dicho conjunto. Formalmente un atributo se define como una función que esquematiza a un conjunto de entidades o un conjunto de relaciones en un conjunto de valores o un producto cartesiano de conjunto de valores de la siguiente forma: f: Ei ⟶ Vi o f: Ri ⟶ Vi 24 El conjunto de valores permitidos para cada atributo se denomina Dominio. El dominio especifica el tipo de datos a almacenar o las restricciones que hay que aplicar a los valores. Ejemplos de dominio son; booleano, entero, Double, String… Por ejemplo, una entidad Película está formada por los siguientes atributos: un resumen, el año de producción, el título original, la duración y el idioma (entre otros muchos). Una entidad Director tendrá como atributos el nombre del mismo, la fecha de nacimiento y la nacionalidad. Película = (Resumen, Año de producción, Título original, Duración, Idioma). Director = (Nombre, Fecha de nacimiento, Nacionalidad). Los atributos en el diagrama asociado se representan como óvalos. Para ligarlos a la entidad a la que pertenecen se utiliza una línea recta [Figura 2.5] . Figura 2.5 Representación de atributo. Debemos tener en cuenta que los nombres de los atributos no se deben repetir, estos han de ser únicos para cada tipo o conjunto de entidad. Si existen dos atributos similares es necesario utilizar calificadores. Si necesitamos almacenar para un conjunto de entidades cierta característica con un nombre similar al de otra, como por ejemplo para un conjunto de Películas, el nombre original de la película y el nombre en el país de emisión, no podríamos tener dos atributos con el mismo valor, por ejemplo título, por lo que, si necesitamos almacenar dos títulos, utilizamos calificadores, pudiendo separar ambos títulos en titulo_original y título, manteniendo así la diferencia entre ambos y haciendo que no se repitan. 2.2.3.1 Tipos de atributos. Los atributos se pueden dividir en varios tipos atendiendo a diversas características como pueden ser el número de valores que pueden tomar, la división en partes más simples o su dependencia con otros de la misma entidad. Pueden ser simples o compuestos. Simple significa que el valor del mismo es mínimo y ya no se pude dividir en partes con significado propio, como por ejemplo el título de una Película. Los compuestos son aquellos que, si se pueden dividir en partes [Figura 2.6], cada una de ellas tiene significado propio, como por ejemplo la dirección en la que está un cine. Dicha dirección, considerada como compuesto se puede dividir a su vez en otros atributos, esta vez simples: calle, número y código postal. 25 Figura 2.6 Representación de atributo compuesto. Los atributos también pueden ser mono-valuados y multi-valuados. Un atributo mono-valuado es el que tiene un único valor para cada ocurrencia de la entidad o la relación a la que hace referencia mientras que uno multi-valuado es el que puede tener varios valores para cada ocurrencia de la entidad o relación. Por ejemplo, el título de una película puede tener varios valores dependiendo del país en el que se emita. La instancia del conjunto de entidades Peliculas con nombre original “Alien”, tiene en otras regiones el título “El octavo pasajero”, dicho atributo sería multivaluado, teniendo esos dos valores como posibles. Los atributos multivaluados en el diagrama Entidad-Relación asociado se representan mediante un óvalo doble [Figura 2.7] Figura 2.7 Representación de atributo multi-valuado. Los atributos pueden ser atributos identificadores como veremos en el siguiente apartado. Si un atributo es identificador o clave, estos se subrayan en el diagrama entidad-relación [Figura 2.8]. Figura 2.8 Representación de atributo clave. Los atributos pueden ser, debido a la necesidad o no de tener valores, opcionales u obligatorios. Esta distinción no existía en la propuesta original del diagrama Entidad-Relación propuesto por Chen, sin embargo, vamos a explicar este tipo debido a que nos va a resultar de utilidad ya que 26 en el capítulo 4 [Capítulo 4] a la hora de transformar un diagrama Entidad-Relación completo, veremos que dicha distinción si es posible a la hora de modelar datos con MongoDB. Mientras que los atributos opcionales son aquellos que tienen que tener un valor si o si, los opcionales son aquellos que no tienen por qué tenerlo. La finalidad de los atributos obligatorios es asegurar que la información para esa característica particular se recoge. Por ejemplo, los identificadores de entidad siempre serán obligatorios, ya que son datos que se necesitan recoger si o si, mientras que por ejemplo la url de un cine puede ser opcional ya que ese determinado cine puede que tenga un sitio web o que no lo haya dado de alta. Finalmente existen los atributos derivados, que son aquellos que se derivan a partir de otros atributos. La edad de un director, calculada a partir de la fecha de su nacimiento, es un atributo derivado. Los atributos derivados se representan como un óvalo con línea discontinua en el diagrama Entidad-Relación [Figura 2.9]. Figura 2.9 Representación de atributo derivado. Como hemos comentado, un atributo puede ser una propiedad de un conjunto de relaciones y no solo de un conjunto de entidades [Figura 2.10], como por ejemplo el conjunto de relaciones dirigir entre los conjuntos de entidades director y película puede tener el atributo fecha de dirección. Figura 2.10 Atributos de una relación. 27 2.2.4 Identificador de entidad. Las entidades pueden tener un identificador de entidad, aunque esto no siempre es necesario como veremos posteriormente. El identificador de entidad son uno o varios atributos cuyos valores permiten distinguir esa entidad del resto del conjunto de entidades, como por ejemplo el nombre completo de un director o el nombre de un cine en una ciudad. Estos atributos que son identificadores se muestran en el diagrama Entidad-Relación subrayados [Figura 2.11]. Figura 2.11 Identificador de entidad. 2.2.5 Grado de una relación. El grado de un conjunto de relaciones (también expresado en la literatura referente con el término aridad) hace referencia al número de conjuntos de entidades que participan en el conjunto de relaciones. El conjunto de relaciones puede tener cualquier grado. Las relaciones binarias (las más comunes dentro de una base de datos) son aquellas relaciones en las que intervienen dos entidades (como la relación interpreta entre actor y película). Las ternarias son las que involucran a tres entidades [Figura 2.12] Mientras que las n-arias son aquellas en las que intervienen n entidades. Figura 2.12 Relación ternaria. 2.2.6 Relaciones recursivas. Las relaciones recursivas son aquellas cuyo mismo conjunto de entidades participa más de una vez en el mismo conjunto de relaciones, pero con diferentes roles. 28 Comentábamos anteriormente que el rol en el diagrama Entidad-Relación no suele necesario nombrarlo, sin embargo, en las relaciones recursivas pueden aportar información que de otra forma sería imposible comprender [Figura 2.13]. Siguiendo el mismo ejemplo podemos ver una relación recursiva en la que interviene el conjunto de entidades Directores, cuando por ejemplo un director se dirige a sí mismo en caso de actuar en una determinada película. Figura 2.13 Relación recursiva. 2.3 Restricciones. Existen dos tipos de restricciones que se pueden utilizar en nuestro modelo, estas son las restricciones de cardinalidad y las restricciones de participación. 2.3.1 Restricciones de cardinalidad. La cardinalidad es una restricción estructural del modelo Entidad-Relación. Esta especifica el número de asociaciones en las que una entidad determinada puede estar. En otras palabras, la cardinalidad es el número de instancias de un determinado conjunto de entidades que pueden relacionarse con instancias de otro conjunto de entidades distinto. Teniendo dos conjuntos de entidades A y B, e instancias de cada uno de los conjuntos a y b. La instancia a puede no estar relacionada con ninguna entidad b, puede estar relacionada con una o puede que lo esté con varias. En este último caso decimos que la cardinalidad es N. Por lo tanto, la cardinalidad puede tomar tres valores: 0, 1 o N (siendo N siempre mayor que 1). 2.3.1.1 Cardinalidad máxima y mínima. A la hora de realizar un diagrama Entidad-Relación y calcular u obtener su cardinalidad, lo que importa son las cardinalidades máximas y mínimas. Definimos cardinalidad mínima al número mínimo de asociaciones que una instancia de un conjunto de entidades presenta una relación con una instancia de un conjunto distinto de entidades. 35 Figura 2.25 Relación ISA. Ejemplo: Si en un diagrama Entidad-Relación hemos identificado previamente las entidades (dentro del universo de los trabajadores de una Universidad) Profesores, Investigadores, Pas y Trabajadores podemos observar fácilmente la relación existente entre dichas entidades. De la entidad Trabajadores podemos obtener los siguientes subconjuntos: Profesores, Investigadores y Pas. Todos ellos pertenecen al conjunto de entidades de mayor orden (en este caso Trabajadores) y comparten atributos pertenecientes a la misma (como podrían ser nombre, sueldo o centro de trabajo), sin embargo, los subconjuntos Profesores, Investigadores y Pas, aun perteneciendo a Trabajadores, poseen atributos que les diferencian unos de otros, como por ejemplo el conjunto de entidades Profesores puede tener asociado un atributo con nombre departamento, el cual no posee el conjunto de entidades Pas. 2.6.2 Generalización. La generalización consiste en designar una serie de subconjunto de entidades en un conjunto de entidades de mayor orden. Podemos decir que es el proceso contrario al de especialización. Para el ejemplo que acabamos de ofrecer relativo a los trabajadores de la Universidad, mientras que la especialización sería obtener del conjunto de entidades Trabajador los subconjuntos de entidades Profesores, Investigadores y Pas, la generalización sería el proceso opuesto: una vez obtenidos los tres subconjuntos (Profesores, investigadores y Pas) obtener uno de mayor orden que estos, que en el caso descrito sería Trabajadores. En el diagrama Entidad-Relación, estos dos conceptos son indistinguibles, ambos (generalización y especialización) son operaciones inversas. [Figura 2.26] 36 Figura 2.26 Generalización y especialización. Existen dos tipos de generalización: total y parcial. En la especialización total toda instancia del conjunto de entidades de orden superior ha de estar representada en las de nivel inferior. En el diagrama Entidad-Relación se representa dicha participación con una línea doble que une el conjunto de entidades de mayor orden con el triángulo que representa la especialización ISA [Figura 2.27]. Figura 2.27 Especialización total. Mientras que en la especialización parcial pueden existir instancias del conjunto de entidades del nivel superior las cuales no estén representadas en el conjunto de entidades de nivel inferior. La representación en el diagrama ER se realiza, al contrario que en la especialización total, con una línea simple que une el conjunto de entidades de mayor orden con el triángulo que representa la especialización ISA [Figura 2.28]. 37 Figura 2.28 Especialización parcial. 2.6.3 Herencia. Otro concepto importante en el diagrama Entidad-Relación extendido es el de la herencia. Definida la especialización y la generalización, los conjuntos de entidades de nivel más bajo heredan los atributos de los conjuntos de entidades de nivel más alto, así como la participación en las relaciones del conjunto de entidades de más alto nivel con el que están relacionadas. 2.6.4 Agregación. Hay ocasiones en las que existe una relación entre conjuntos de entidades (supongamos A y B) y se desea relacionar ese conjunto (ambas entidades junto con su relación asociada) con otra entidad diferente C. En el diagrama Entidad-Relación, este tipo de relaciones (denominada agregación) se representa introduciendo el conjunto de entidades junto con la relación existente entre ambas en un rectángulo, de tal forma que ese conjunto esté relacionado a su vez con una tercera entidad. [Figura 2.29]. 38 Figura 2.29 Agregación. 39 Capítulo 3 MongoDB. Una vez estudiadas las características del modelo Entidad-Relación y su esquema asociado procedemos a ver cuáles son las particularidades de MongoDB En este capítulo veremos las principales características y el surgimiento de las bases de datos no relacionales, para entender el contexto en el que nos encontramos. Posteriormente nos centraremos en este sistema de bases de datos no relacional, MongoDB. Se explicará su funcionamiento, la forma en la que se estructuran los datos y los tipos de los mismos, así como las operaciones elementales de creación, inserción, borrado y modificación de datos necesarios para polar una base de datos. MongoDB tiene una forma particular de relacionar los datos, pero se estudiará en el siguiente capítulo, cuando veamos las reglas de transformación del esquema Entidad-Relación a esta base de datos. 40 3.1 NoSQL. Aunque el término se acuñó en el año 1998, no fue hasta finales de la década del 2000 cuando se instauraron los modelos NoSQL. En ese marco de tiempo fueron las bases SQL las que dominaron el mercado. Las bases de datos NoSQL nacieron como respuesta a la era de internet, la Big Data y la necesidad de procesar datos no estructurados. Dichos sistemas aparecieron debido a una serie de necesidades que los anteriores modelos no eran capaces de satisfacer. Entre ellas destacaran: - La necesidad de una mayor escalabilidad que las bases de datos relacionales, incluyendo una cantidad muy grande de datos o un rendimiento en operaciones de escritura muy alto. - La preferencia por el software gratuito y de código abierto por encima de productos comerciales. - Operaciones “query” especializadas que no estaban respaldadas completamente por el modelo relacional. - Los problemas causados por la las restricciones de los modelos relacionales, y un deseo de modelos de datos más dinámicos y expresivos. Entre las características más importantes que introdujeron este nuevo modelo de bases de datos (y de las que carece el modelo relacional) estas serían las más importantes: - Ausencia de soporte para el lenguaje Sql. La mayor parte de las bases de datos no relacionales definen su propio lenguaje, como por ejemplo MongoDb, sistema en el que profundizaremos en este proyecto, que carece de los “joins” y de las transacciones clásicas de las bases de datos relacionales, o Cassandra que utiliza su propio CQL (Cassandra Query Language) un derivado reducido de SQL. - Ausencia de relaciones como se conocían previamente en el modelo relacional entre los datos. - Ausencia de transacciones ACID (Atomicity, Consistency, Isolation, Durability). - Modelos de datos muchísimo más flexibles. Aun así, a día de hoy Oracle MySQL, Microsoft SQL server y PostgreSQL (todas ellas basadas en el modelo relacional) son las bases de datos más utilizadas en todo el mundo. Sin embargo, las bases de datos NoSQL están ganando terreno y MongoDB (base de datos no relacional) ya es la quinta base de datos más usada del mundo 8 [Tabla 3.1]. 8 “DB-Engine Ranking”. [Recurso online] Disponible en: https://db-engines.com/en/ranking Fecha última consulta: 01/06/2024 41 Ranking/mes Nombre de base de datos Modelo de base de datos Nov 2023 Oct 2023 Nov 2022 1. 1. 1. Oracle Relacional, Multimodelo 2. 2. 2. MySQL Relacional, Multimodelo 3. 3. 3. Microsoft SQL Server Relacional, Multimodelo 4. 4. 4. PostgreSQL Relacional, Multimodelo 5. 5. 5. MongoDB Documentos, Multimodelo 6. 6. 6. Redis Clave-Valor, Multimodelo 7. 7. 7. Elasticsearch Motor de búsqueda, Multi-modelo 8. 8. 8. IBM Db2 Relacional, Multimodelo 9. 9. 10. SQLite Relacional 10. 10. 9. Microsoft Access Relacional Tabla 3.1 Bases de datos más utilizadas en la actualidad. Entender las diferencias entre los modelos tradicionales y los NoSQL no es uno de los objetivos de este proyecto, ya que vamos a utilizar características o funcionalidades de ambos modelos para la creación de una base de datos. Estos dos modelos (SQL y NoSQL) no tienen por qué ser completamente antagónicos, es más, cabe recordar el significado de las siglas NoSQL (Not Only SQL) por lo que ciertas características del modelo relacional (como puede ser un esquema previo a la creación de la base de datos) junto con la flexibilidad que ofrece este nuevo enfoque, pueden ser características que se pueden conjuntar en el proceso completo de la creación de una base de datos (como veremos en el presente estudio). En la siguiente tabla [Tabla 3.2] podemos observar, de forma muy resumida, las principales diferencias entre los modelos SQL y NoSQL. SQL NoSQL Tipo de modelo Modelo relacional. Almacena los datos en tablas. Modelo no relacional. Almacena los datos en documentos tipo Json. 42 Datos Ideal si cada uno de los registros almacenados tiene las mismas propiedades. El hecho de añadir una nueva propiedad puede ocasionar una modificación del esquema. Útil para datos estructurados. Las relaciones son normalmente plasmadas por datos no normalizados y mostrándolos en un único registro Ofrece mucha flexibilidad y los registros no tienen por qué almacenar las mismas propiedades. Se pueden ir añadiendo propiedades a medida que estas sean necesarias. Útil para datos semi estructurados. Las relaciones son a menudo plasmadas utilizando joins para determinar referencias. Escala Escala de forma correcta verticalmente. Escala de forma correcta horizontalmente. Consistencia Alto nivel de consistencia. La consistencia varía dependiendo de la implementación adoptada. Naturaleza Naturaleza estructurada. Naturaleza semi-estructurada o no estructurada. Esquema Rígido Flexible Soporte Mucho soporte Depende de la comunidad, aunque cada vez el mismo es mayor. OLTP (Procesamiento de Transacciones en línea) Es el recomendado para este tipo de transacciones. Todavía no Lenguaje Lenguaje de consultas estructuradas. Lenguaje de consultas no estructurado. Ventajas Esquema definido de forma precisa, asegura la integridad de los datos. Las relaciones permiten almacenar cada uno de los datos una sola vez. Ausencia de duplicados. Ausencia de esquema, aunque proporciona una mayor flexibilidad. Los datos se almacenan según las necesidades, hace que la búsqueda de datos sea mucho más rápida. Desventajas Modelo menos flexible. Tiene la necesidad de ser planificado de antemano. Algunas relaciones pueden conducir a consultas muy complejas (haciéndolas más lentas). El aumento de flexibilidad puede acarrear un desarrollo desordenado y posponer decisiones estructurales. El hecho de tener datos duplicados puede implicar el tener que actualizar varias colecciones. Tabla 3.2 Diferencias SQL y NoSQL. 43 3.2 MongoDB. MongoDB es un sistema de base de datos NoSQL orientada a documentos, de código abierto y escrito en C++ que nació en el año 2007 y fue creada por Dwight Merriman, Eliot Horowitz y Kevin Ryan. La principal característica de MongoDB, en contraposición con las bases de datos relacionales, es que no necesita de un esquema para describir cada uno de los elementos funcionales, esto es, son bases de datos schemaless. 9 Es una plataforma de base de datos flexible y escalable diseñada como comentamos anteriormente, para modificar o ampliar el enfoque de las bases de datos relacionales y las limitaciones ofrecidas por otras bases de datos también NoSQL. Posee un alto grado de escalamiento horizontal y de equilibrio de la carga . 10 Esto significa que los desarrolladores pueden centrarse en los datos que necesitan almacenar y procesar, en lugar de invertir tiempo en cómo introducir y repartir los datos en tablas rígidas. En el siguiente apartado veremos la estructura de las colecciones y sus documentos asociados. En relación con las consultas, MongoDB permite realizarlas ad hoc, permitiendo buscar datos o información por campo, consultas de rango y también búsquedas con expresiones regulares. Es posible indexar cualquier documento. Esta es una de las características más importantes de esta base de datos. No entraremos en sus detalles en este trabajo ya que a la hora de transformar los diagramas ER intentaremos que la base de datos resultante represente de la forma más fiel el diagrama objeto de conversión Permite también replicación (concepto el cual permite replicar y actualizar los datos ya sean estos persistentes o no), así como la replicación y una serie de características adicionales que no estaban disponibles en las anteriores bases de datos. 11 3.3 Colecciones y documentos. Mientras que en el modelo relacional la información se almacena en filas y columnas, las cuales están organizadas en tablas, MongoDB almacena la información en documentos, los cuales se reúnen en colecciones. Una base de datos en MongoDB es un contenedor de colecciones de documentos. 9 “MongoDB Schemaless” [Recurso Online] Disponible en: https://www.mongodb.com/unstructureddata/schemaless Fecha última consulta: 01/06/2024 10 “MongoDB features” [Recurso Online] Disponible en: https://www.mongodb.com/features Fecha última consulta: 01/06/2024 11 “Replicación (informática)” [Recurso Online] Disponible en: https://es.wikipedia.org/wiki/Replicaci%C3%B3n_(inform%C3%A1tica) Fecha última consulta: 01/06/2024 44 Las bases de datos MongoDB no poseen esquema, al contrario que las bases de datos relacionales, esto quiere decir que el formato o esquema de un documento dentro de una colección no tiene por qué ser igual al de otro documento que pertenezca a esa misma colección. Una base de datos en MongoDB puede almacenar una o varias colecciones. Las colecciones son como las tablas de las bases de datos relacionales, ya que almacenan los datos, solo que en forma de documentos. Los documentos son registros individuales de una colección, estos son la unidad básica de los datos en MongoDB. En la siguiente figura podemos ver cómo es la estructura de datos en MongoDB. [Figura 3.1] Figura 3.1 Base de datos en MongoDB BSON es la abreviatura de Binary JSON. En otras palabras, BSON es la codificación en binario de documentos tipo Json (formato de texto para el acceso, almacenamiento e intercambio de datos que forma parte del sistema de JavaScript) Cada uno de estos documentos (que sería el equivalente a las filas en las bases de datos relacionales) contiene un número indeterminado de “Campos” (atributos en el modelo tradicional), y cada uno de estos campos es un par clave valor, que sustituye a las columnas [Tabla 3.3]. // Colección A // Documento a { _id: <id_a>, clave_a_1: valor_a_1, 51 "fecha_nac": "02-03-1963" }) 3.5.5 Borrado de documentos. Las operaciones de borrado eliminan documentos de una colección. MongoDB nos proporciona dos métodos para eliminar documentos de nuestras colecciones. Tienen como objetivo una única colección, y nos permite utilizar filtros. Al igual que otros métodos que hemos visto anteriormente MongoDB nos permite borrar un único documento, varios o todos los documentos de una colección. - deleteOne( ) Elimina un único documento de nuestra colección. Como argumento se le pasa el filtro de búsqueda. A continuación, mostramos la forma de eliminar un determinado realizador de nuestra colección Realizadores. En vez de aplicar el filtro nombre como en anteriores ejemplos utilizaremos como argumento el ObjectId del mismo, algo que nos será de gran utilidad cuando más adelante veamos la forma de relacionar nuestras colecciones mediante referencias. db.Realizadores.deleteOne( {_id: ObjectId("6557a6452b113681d0ed0d89")} ) - deleteMany( ) Funciona de la misma manera que deleteOne( ) pero elimina varios documentos. En el siguiente ejemplo eliminamos todos los documentos que coincidan con el filtro pasado como argumento, todos cuya fecha_nac sea 02-03-1986: db.Realizadores.deleteMany( {"fecha_nac": "02-03-1963"} ) 3.5.6 Operaciones de consulta. Este tipo de operaciones son necesarias para buscar documentos de nuestras colecciones. En las bases de datos relacionales se tiene un lenguaje propio para realizar las consultas, SQL (Structured Query Language). En MongoDB no tenemos esta opción, ya que las búsquedas se 52 realizan mediante las funciones find( ) y findOne( ). Estas devuelven un subconjunto de elementos de una determinada colección. - find( ) tiene dos argumentos, el primero de ellos es un documento que especifica los criterios de consulta, el segundo especifica el campo a devolver de entre los documentos que coincidan. Si el primer argumento de consulta es vacío (es decir, el argumento es {}), nos devolverá todos los elementos de la colección seleccionada. En el siguiente ejemplo: db.Realizadores.find() La consulta nos devolverá todos los documentos de la colección Realizadores. Sin embargo, si utilizados la siguiente clave/valor en la misma consulta: db.Realizadores.find({"nombre": "Ridley Scott"}) La consulta nos devolverá todos los realizadores que cumplan con el filtro: nombre: Ridley Scott. - findOne() Funciona de forma idéntica a find() salvo en que devuelve un único documento que satisfaga los criterios de búsqueda utilizados. En caso de que sean más de uno, devuelve el primero de ellos según el orden natural que en el que estén localizados los documentos en el disco. Si ningún documento coincide con los criterios introducidos devuelve null. db.Realizadores.findOne({"nacionalidad": "Estados Unidos"}) La consulta nos devolverá un único documento que cumpla el filtro: nacionalidad: Estados Unidos. 53 Capítulo 4 Reglas de transformación de un esquema Entidad- Relación a una base de datos con MongoDB. Tras el estudio de las características que definen el modelo Entidad-Relación y habernos familiarizado con los conceptos y funcionalidad de la base de datos MongoDB, en este capítulo definiremos una serie de reglas para convertir un diagrama Entidad-Relación en esta base de datos. Lo primero que debemos aclarar es que, como hemos visto en capítulos anteriores, las bases de datos NoSQL en general y de MongoDB en particular, surgieron con una serie de objetivos, entre los que destaca eliminar las restricciones del modelo relacional. Es por ello que a priori parezca que no tiene mucho sentido sentar una base de reglas para transformar esquemas pertenecientes al modelo relacional en bases de datos que huyen de los principios de estos mismos y que aparecieron gracias a avances tecnológicos que ampliaban la forma de almacenar los datos. Sin embargo, y a pesar de cada vez más aplicaciones utilizan bases de datos NoSQL para almacenar la información, el estándar relacional sigue muy presente a día de hoy, siendo la base de la gestión y almacenamiento de datos en buena parte de organizaciones. Sin embargo, solo hace falta consultar foros de desarrolladores de software en internet para percatarse de que muchos de estos realizaron su software teniendo como base de almacenamiento de datos una base de datos relacional y desean trasladarlos o migrarlos a MongoDB para beneficiarse de ciertas ventajas de estos nuevos modelos, pero manteniendo características del modelo tradicional, como puede ser la forma en la que desean almacenar los datos. Puede que sea una tarea muy compleja la obtención, a partir de una base de datos NoSQL (en la que posiblemente no se haya creado un modelo de la misma previo a su implementación) un esquema gráfico en el que se vea exactamente la forma en la que están estructurados los datos. Sin embargo, como veremos a continuación, sí que es posible obtener a partir de un esquema relacional una base de datos implementada con esta nueva tecnología, pero manteniendo la mayor parte de las características de dicho esquema. Gracias a la ausencia de restricciones que proponía el modelo tradicional, la base de datos resultante podría implementar, sin necesidad de realizar modificaciones en su modelo, una serie de características pertenecientes a esta nueva tecnología lo cual la dotaría en parte, de los beneficios del esquema tradicional y a su vez, de las características adicionales de este nuevo tipo de bases de datos. A continuación, procedemos a definir una serie de reglas de transformación para plasmar de la forma más precisa (y, por ende, con una serie de restricciones) la información presente en un diagrama Entidad-Relación en una base de datos no relacional (MongoDB) lo cual es algo completamente opuesto a la naturaleza de estas últimas. Asimismo, para cada una de las reglas de conversión de los diferentes componentes que forman un diagrama Entidad-Relación, se ejemplificará con casos concretos dicha conversión. En este capítulo dichos ejemplos no formarán parte de un único universo con la finalidad de abarcar el total de casos propuestos. En el siguiente capítulo se realizará la conversión de un diagrama 54 Entidad-Relación completo (no solo de sus componentes individuales) en una base de datos con MongoDB. Junto a esta memoria se adjunta un Script (Hacer clic) [TFG - Método de transformación - Rubén de Diego Varona Capítulo 4.js] 15 en el que se puede consultar el código de todos los ejemplos realizados. Haciendo clic sobre el enlace de este mismo párrafo se redirigirá al repositorio GitHub en el que se puede ver el código utilizado. 4.1 Entidades. En el diagrama Entidad-Relación [Capítulo 2] nos encontramos con dos tipos de entidades, las denominadas entidades fuertes y las entidades débiles. Las fuertes están representadas en el mismo como un rectángulo, mientras que las débiles lo están con un doble rectángulo o un rectángulo con doble línea. [Figura 4.1] Figura 4.1 Entidades débiles y fuertes. Recordemos la definición de entidad débil: Si la existencia de la entidad x (entidad débil) depende de la existencia de la entidad y, entonces decimos que x depende por existencia de y. En otras palabras, la existencia de las entidades débiles depende de la existencia de otras entidades con las que se relacionan. Como hemos comentado anteriormente, es posible encontrarnos con diagramas en los que las entidades fuertes y débiles aparecen representadas únicamente con un rectángulo. En este caso, y para diferenciar las débiles de las fuertes, basta con observar si la entidad posee o no un atributo identificador (el cual aparece subrayado) [Figura 4.02]. 15 Rubén de Diego Varona “Código capítulo 4 TFG” [Recurso online] Disponible en: https://github.com/rubdedi/MongoDB/blob/main/TfgCap%C3%ADtulo4.js Fecha última consulta: 01/06/2024 55 Figura 4.2 Entidades débiles y fuertes. El primer paso que tendremos que realizar a la hora de convertir el esquema Entidad-Relación en una base de datos con MongoDB será identificar las entidades fuertes y débiles en el diagrama. 4.1.1 Transformación de entidades en MongoDB. 4.1.1.1 Entidades fuertes. En MongoDB un conjunto de entidades fuertes se convertirá en una colección cuyo nombre será el del conjunto de entidades. Como veremos posteriormente, en general, los atributos se corresponderán con los campos de los documentos. [Figura 4.03]. Figura 4.3 Entidades a colecciones. Ejemplo: Veamos cómo se transformarían las entidades fuertes en el siguiente ejemplo: Tenemos un conjunto de entidades Clientes las cuales se relacionan mediante la relación Tener con un conjunto de entidades Préstamos: [Figura 4.4]. 56 Figura 4.4 Ejemplo conversión entidades. El primer paso sería identificar las entidades en el diagrama, las cuales serían Clientes y Préstamos. El conjunto de entidades Clientes se convertiría en la colección Clientes en MongoDB, de igual forma el conjunto de entidades Préstamos se convertiría en la colección Préstamos en MongoDB. Bastaría con crear las colecciones en MongoDB con los comandos adecuados como vimos en el capítulo anterior. Ejemplo> db.createCollection("Clientes") Ejemplo> db.createCollection("Préstamos") 4.1.1.2 Entidades débiles. Una de las características de las entidades débiles es que, al contrario que aquellas de las que dependen, no tienen identificador propio o atributo identificador. Sin embargo, si en MongoDB creamos un documento sin un campo _id, será MongoDB el que automáticamente lo cree y le asigne un ObjectID de tipo Bson único. Como vimos en el capítulo anterior, no puede existir ningún documento perteneciente a una colección sin _id en MongoDB. Al igual que hemos hecho con las entidades fuertes, podríamos convertir las entidades débiles en colecciones, pero a la hora de crearlas, y aunque no introdujésemos un ObjectID para cada una de ellas, MongoDB lo crearía de forma predeterminada, con lo que tendríamos información redundante y no estaríamos modelando con el concepto base del esquema Entidad-Relación. Si siguiésemos este patrón, posteriormente deberíamos referenciar dichos documentos para establecer la relación existente en el modelo ER. En una sección posterior de este documento estudiaremos la forma de referenciar documentos. Para transformar un conjunto de entidades débiles en MongoDB se crea un campo clave valor dentro del documento perteneciente a la colección que representa la entidad fuerte con la que esté relacionada. Este campo tendrá como clave el nombre del conjunto de entidades débiles y como valor un array con tantos pares clave valor como número de atributos tuviese el conjunto de 57 entidades débiles. [Figura 4.5]. A este proceso en MongoDB se le denomina incrustar documentos, proceso que veremos más adelante. Figura 4.5: Entidades débiles incrustadas. Sean A y B conjuntos de entidades (A entidad fuerte y B entidad débil) relacionadas entre sí. Cada una de ellas con i y j atributos respectivamente. [Figura 4.6]. Figura 4.6 Entidades débiles incrustadas. En su paso a MongoDB el conjunto de entidades A sería la colección A y una instancia de A sería un documento a con i+1 campos clave valor de la siguiente forma: [Tabla 4.1]. // Colección A // Documento a { _id: < ObjectId_a >, Atributo_a_1: valor_a_1, Atributo_a_2: valor_a_2, ... Atributo_a_i: valor_a_i } Tabla 4.1 Documento a. 58 Al incrustar el conjunto de entidades débiles B relacionadas con el conjunto de entidades fuertes A, la transformación resultante sería el mismo documento A más un clave valor con clave el nombre de la colección B y valor un array conteniendo tantos campos clave valor como atributos tuviese el conjunto de entidades débiles B (j campos) con sus respectivos nombres y valores de atributos. [Tabla 4.2]. Nota: Solo para el caso de las entidades débiles en su paso a MongoDB, a la hora de incrustarlas en el documento padre (correspondiente a la entidad fuerte del diagrama ER), omitiremos el ObjectID de la entidad débil, para, de esta forma mantener la idea de que las entidades débiles no han de tener atributo identificador en el diagrama ER. No crearemos colecciones para las entidades débiles, ya que serán directamente datos incrustados en las entidades fuertes correspondientes. // Colección A // Documento a { _id: < ObjectId_a >, Atributo_a_1: valor_a_1, Atributo_a_2: valor_a_2, ... Atributo_a_i: valor_a_i Nombre_colección_B: [{ Atributo_b_1: valor_b_1, Atributo_b_2: valor_b_2, ... Atributo_b_j: valor_b_j, }] } Tabla 4.2 Documento b incrustado en a. Ejemplo: En la siguiente figura podemos observar que existen dos conjuntos de entidades distintas. El conjunto de entidades fuertes Préstamos y el Conjunto de entidades débiles Pagos. [Figura 4.7]. Figura 4.7 Ejemplo entidad débil. 59 Como acabamos de ver el conjunto de entidades Préstamos se transformaría en la colección Préstamos. Ahora bien, Pagos no sería una nueva colección en MongoDB ya que se trata de una entidad débil. Cada instancia del conjunto de entidades Préstamos sería un nuevo documento, mientras que la información del pago asociado a dicho documento estaría incrustada en el mismo. Supongamos una instancia del conjunto de entidades Préstamo con los siguientes valores de atributos: [Tabla 4.3]. Préstamo Instancia 1 Número_préstamo 123456 Cantidad 10 Tabla 4.3 Instancia Préstamo. Y una instancia del conjunto de entidades Pago con los valores de atributos: [Tabla 4.4]. Pago Instancia 1 Número_pago 654321 Importe 100 Tabla 4.4 Instancia Pago. Tras convertir la entidad fuerte Préstamo en su correspondiente colección con igual nombre, la instancia de pago se incrustaría en la correspondiente instancia préstamo mediante un nuevo campo clave valor con clave nombre Pago y valor el array que contiene el nombre de los atributos y su respectivo valor. [Tabla 4.05]. // Colección Préstamos // Documento préstamo1 { _id: ObjectId('65c899073342ee53cbf8f866'), Número_préstamo: 123456, Cantidad: 10, Pago: [{ Número_pago: 654321, Importe: 100 }] } Tabla 4.5 Ejemplo conversión entidad débil. 60 4.2 Atributos. Una vez identificadas las entidades es necesario hacerlo con los atributos. [Figura 4.8]. Figura 4.8 Ejemplo atributos diagrama ER. En general, los atributos del diagrama Entidad-Relación pasan a ser campos (del tipo clave valor) en un documento de MongoDB. Si una entidad tiene i atributos, en MongoDB el documento asociado a dicha entidad tendrá i + 1 campos clave valor: i correspondientes a los atributos de la entidad más un campo adicional que contendrá el _id del documento. Las claves del documento serán los nombres de los atributos, mientras que los valores serán los mismos asociados a los atributos de la entidad [Tabla 4.06]. // Colección A // Documento a { _id: < ObjectId_a >, Atributo_a_1: valor_a_1, Atributo_a_2: valor_a_2, ... Atributo_a_i: valor_a_i } Tabla 4.6 Ejemplo atributos en MongoDB. Ejemplo: Tenemos el conjunto de entidades Clientes con los siguientes atributos: Número, Nombre y Calle. [Figura 4.9]. 67 ... } Tabla 4.14 Atributos multi-valuados MongoDB. Por ejemplo, la entidad Cliente, la cual posee los siguientes atributos: Número, Nombre y Teléfono, los dos primeros atributos simples, mientras que Teléfono multivaluado. [Figura 4.15]. Figura 4.15 Ejemplo atributo multi-valuado ER. Una instancia de dicha entidad posee los siguientes valores para los tres atributos [Tabla 4.15]. Clientes Instancia 1 Número 143214 Nombre Henar Teléfono 983123456 983987654 689123456 Tabla 4.15 Instancia Cliente. En su paso a MongoDB, el documento resultante de la transformación contendría la siguiente información: [Tabla 4.16]. // Colección Cliente // Documento cliente { _id: ObjectId('65c6436fffdb3aec9dbf0d85'), Número: 143214 Nombre: Henar, Teléfono: [{ 68 Teléfono1: 983123456, Teléfono2: 983987654, Teléfono3: 689123456 ]} } Tabla 4.16 Ejemplo Atributos multi-valuados MongoDB. 4.2.4 Atributos derivados. Los atributos derivados son aquellos cuyo valor puede ser calculado mediante el valor de otros atributos. [Figura 4.16]. Figura 4.16 Ejemplo atributo derivado ER. En MongoDB se utilizan las denominadas Aggregation operations, término que podemos traducir como operaciones de suma u operaciones de adición. Estas operaciones permiten agrupar valores de varios documentos, realizar operaciones sobre un conjunto de datos y devolver un único resultado y analizar el cambio de los datos a través del tiempo. No podemos definir un método general de transformación de atributos derivados en un esquema ER en su correspondiente par clave valor en MongoDB ya que dependiendo del atributo derivado que se desee calcular (y el atributo del que se desee “derivar”) habrá que hacer una serie de operaciones mediante las posibilidades que nos ofrece MongoDB con las Aggregation operations. 4.2.5 Atributos requeridos y opcionales. Como su propio nombre indica definiremos atributos requeridos como aquellos que han de estar presentes en nuestra base de datos, mientras que los opcionales pueden aparecer o no. [Figura 69 4.17]. En los diagramas Entidad-Relación todos los atributos que aparecen en el mismo son requeridos. Figura 4.17 Ejemplo atributo requerido ER. Sin embargo, MongoDB nos permite a la hora de crear colecciones, la posibilidad de aplicar una serie de restricciones a los futuros documentos que formen parte de esa determinada colección mediante los denominados JSON Schema que vimos en capítulo referente a MongoDB. [Capítulo 3]. Para definir los atributos como requeridos, a la hora de transformarlos en campos en MongoDB, basta con marcarles como required en dicho esquema. De esta forma el esquema validará los documentos que introduzcamos en esa determinada colección y, si a la hora de realizarlo, falta algún campo marcado como required en el mismo, no nos permitirá crear la colección devolviéndonos un error para informarnos. [Tabla 4.17]. // Colección A Validator: { $jsonSchema: { bsonType: “object”, title: “Título”, required: [atributo_a_1, atributo_a_2, ..., atributo_a_i] ... ... } } Tabla 4.17 Ejemplo JsonSchema Validator Siguiendo con el ejemplo planteado con anterioridad tomemos el siguiente componente del diagrama Entidad-Relación. [Figura 4.18]. 70 Figura 4.18 Ejemplo entidad ER. La entidad cliente tiene tres atributos: Número, Nombre y Calle. A la hora de crear una base de datos en MongoDB podemos marcar los campos correspondientes a los atributos que posee esta entidad como requeridos como vemos en el siguiente ejemplo: // Creación de la colección Cliente con atributos obligatorios db.createCollection("Cliente", { validator: { $jsonSchema: { bsonType: "object", title: "Cliente", required: [ "numero", "nombre", "calle"], properties: { numero: { bsonType: "int", minimum: 1, maximum: 100000000000, description: "'numero' ha de ser un integer en el rango [1,100000000000] y es necesario" }, nombre: { bsonType: "string", description: "'nombre' ha de ser un string y es necesario" }, calle: { bsonType: "string", description: "'calle ha de ser un string y es necesario" } } } } } ) 4.3 Relaciones. En MongoDB la finalidad a la hora de diseñar el modelo de la base de datos se basa en la estructura de los documentos y el comportamiento de la posible aplicación para la que estemos 71 diseñando esa base de datos para representar las relaciones existentes entre los datos. Como comentamos en la introducción de este TFG el objetivo de este estudio no es obtener una base de datos lo más eficiente posible, sino transformar un esquema Entidad-Relación en una base de datos en este sistema, manteniendo, en la medida de lo posible, las restricciones del diagrama Entidad-Relación. En las bases de datos relacionales las relaciones se efectúan utilizando las claves primaria y foránea. En MongoDB no se utiliza esta técnica, sino que las relaciones se crean mediante dos técnicas diferentes: Incrustando documentos dentro de otros y mediante referencias entre documentos. a) Mediante documentos incrustados (también denominados embebidos) – Es una forma de aunar en un único documento datos relacionados. En este modelo introducimos la información de uno o varios documentos(s) dentro de otro(s). Como resultado, en vez de tener documentos independientes, obtenemos un único documento con toda la información referente a todos los documentos relacionados. b) Mediante referencias – De esta forma mantenemos la estructura de documentos independientes. Las relaciones se crean mediante referencias manuales, las cuales consisten en incluir el (los) campo(s) _id del (los) documento(s) relacionado(s) con otro(s) como un campo clave valor. En él [Capítulo 2] vimos que no solo existen relaciones binarias en los diagramas Entidad- Relación, sino que dependiendo del número de entidades que estén relacionadas entre sí nos podemos encontrar relaciones ternarias, cuaternarias… n-arias. En este capítulo nos vamos a centrar solo en las relaciones binarias, ya que una vez conocidas estas (y al no existir para ninguno de sus transformaciones un único método) podemos extrapolar las reglas de transformación que enunciaremos a relaciones en las que intervengan más de dos entidades (pudiendo bien referenciar o incrustar como veremos en las binarias). Independientemente, en el diagrama ER, siempre se puede disminuir el grado de una relación, si este es superior a dos, con las transformaciones necesarias. A continuación, se expondrán ambas formas (incrustar documentos y referenciarlos) para los tipos de relaciones existentes en un diagrama Entidad-Relación (1:1, 1: N y N:M). Para cada una de las reglas generales se realizará un ejemplo práctico para todas y cada una de las posibilidades de transformación. 4.3.1 Relaciones uno a uno. Sean A y B conjuntos de entidades relacionadas uno a uno. Cada una de ellas con i y j atributos respectivamente [Figura 4.19]. 72 Figura 4.19 Relación uno a uno ER. En su paso a MongoDB el conjunto de entidades A sería la colección A y una instancia de A sería un documento a el cual tendría i+1 campos clave valor. El conjunto de entidades B sería la colección B y una instancia de b sería un documento b con j+1 campos clave valor. 4.3.1.1 Relaciones uno a uno con documentos incrustados. Una de las formas de crear relaciones del tipo uno a uno entre datos es utilizando documentos incrustados unos dentro de otros. Dado un documento a resultante de la transformación del conjunto de entidades A en la colección A, con i +1 campos clave valor [Tabla 4.18]. // Colección A // Documento a { _id: <ObjectId(id_a)>, atributo_a_1: valor_a_1, atributo_a_2: valor_a_2, ... atributo_a_i: valor_a_i } Tabla 4.18 Documento a. Y un documento b resultante de la transformación del conjunto de entidades B en la colección B, con j+1 campos clave valor [Tabla 4.19]. // Colección B // Documento b { 73 _id: <ObjectId(id_b)>, atributo_b_1: valor_b_1, atributo_b_2: valor_b_2, ... atributo_b_j: valor_b_j } Tabla 4.19 Documento b Y ambos relacionados entre sí en el diagrama Entidad-Relación mediante una relación tipo uno a uno: Incrustando el documento b en el documento a obtendríamos un único documento a, de la colección A, de la siguiente forma. El documento resultante a contendría toda la información de sí mismo y la del documento b [Tabla 4.20]. // Colección A // Documento a { _id: <ObjectId(id_a)>, atributo_a_1: valor_a_1, atributo_a_2: valor_a_2, ... atributo_a_i: valor_a_i Nombre_colección_B: // Documento b incrustado { _id: <ObjectId(id_b)>, atributo_b_1: valor_b_1, atributo_b_2: valor_b_2, ... atributo_b_j: valor_b_j } } Tabla 4.20 Documento b incrustado en a La posición en la que introduzcamos nuestro documento a incrustar es indiferente siempre y cuando mantenga la estructura definida, pero para mantener una estructura igual en todas las transformaciones que hagamos de aquí en adelante introduciremos el documento incrustado en la última posición del documento principal. 74 De igual forma podríamos incrustar el documento a en el documento b obteniendo de esta forma un único documento b, de la colección B, con la información de ambos, solo que con diferente estructura [Tabla 4.21]. // Colección B // Documento b { _id: <ObjectId(id_b)>, atributo_b_1: valor_b_1, atributo_b_2: valor_b_2, ... atributo_b_j: valor_b_j, Nombre_coleccion_A: // Documento a incrustado { atributo_a_1: valor_a_1, atributo_a_2: valor_a_2, ... atributo_a_i: valor_a_i } } Tabla 4.21: Documento a incrustado en b Ejemplo: Veamos un ejemplo concreto de la transformación de una relación uno a uno en un diagrama Entidad-Relación en su respectivas colecciones y documentos en MongoDB. Tenemos la entidad Estudiante (cuyos atributos son Número_estudiante, Nombre, Curso y Centro) y la entidad Tarjeta_Uva (con atributos Número_Tarjeta y Tipo, pudiendo ser este último de crédito, débito o solo identificativa). Ambas entidades relacionadas entre sí mediante Posee. Un estudiante solo va a poder poseer una tarjeta _Uva, mientras que una tarjeta_Uva solo puede pertenecer a un estudiante. [Figura 4.20]. Figura 4.20 Ejemplo relación uno a uno ER. 75 Tenemos una instancia del conjunto de entidades Estudiantes con los siguientes valores de atributos: [Tabla 4.22]. Estudiante Instancia 1 Número_estudiante 542531987 Nombre Miguel Ángel Curso Cuarto Centro ETSII Tabla 4.22 Instancia 1 estudiante. Y una instancia del conjunto de entidades Tarjeta_Uva con los siguientes valores de atributos: [Tabla 4.23]. Tarjeta_Uva Instancia 1 Número_Tarjeta VA1133545 Tipo_tarjeta Identificativa Tabla 4.23 Instancia 1 de tarjeta uva Aplicando las reglas de transformación definidas, en MongoDB tendríamos dos documentos: estudiante_1 y tarjeta_uva_1 pertenecientes a las colecciones Estudiante y Tarjeta_Uva respectivamente con la siguiente información: [Tabla 4.24]. [Tabla 4.25]. // Colección Estudiante // Documento estudiante_1 { _id: ObjectId ('65c640a4ffdb3aec9dbf0d73 '), Número_estudiante: 542531987, Nombre: Miguel Ángel, Curso: Cuarto, Centro: ETSII } Tabla 4.24 Documento estudiante_1. // Colección Tarjeta_Uva // Documento tarjeta_uva_1 { _id: ObjectId('65c65065ffdb3aec9dbf0d87'), Número_Tarjeta: VA1133545, Tipo_tarjeta: Identificativa 76 } Tabla 4.25 Documento tarjeta_uva_1. Incrustando el documento tarjeta_uva_1 en el documento estudiante_1 obtendríamos un único documento perteneciente a la colección Estudiante el cual contendría tanto la información de estudiante como la de la tarjeta_Uva con la que está relacionada: [Tabla 4.26]. // Colección Estudiante // Documento estudiante_1 { _id: ObjectId ('65c640a4ffdb3aec9dbf0d73 '), Número_estudiante: 542531987, Nombre: Miguel Ángel, Curso: Cuarto, Centro: ETSII, Tarjeta_uva: // Documento tarjeta_uva_1 incrustado { _id: ObjectId('65c65065ffdb3aec9dbf0d87'), Número_tarjeta: VA1133545, Tipo_tarjeta: Identificativa, } Tabla 4.26 Documento tarjeta_uva_1 incrustado en estudiante_1. Como hemos comentado anteriormente también se podría incrustar el documento estudiante_1 en el documento tarjeta_uva_1. La decisión de incrustar un determinado documento en otro dependerá del desarrollador de la base de datos y como desea que estén estructurados los mismos. Incrustando el documento estudiante_1 en el documento tarjeta_uva_1 obtendríamos un único documento tarjeta_uva_1 el cual contendría tanto la información de la tarjeta como la del estudiante con la que está relacionada: [Tabla 4.27]. // Colección Tarjeta_Uva // Documento tarjeta_uva_1 { _id: ObjectId ('65c65065ffdb3aec9dbf0d87'), Número_tarjeta: VA1133545, Tipo_tarjeta: Identificativa Estudiante: // Documento estudiante_1 incrustado 83 Asignatura Instancia 1 Instancia 2 Instancia 3 Código_asignatura 46962 46901 46977 Nombre_asignatura Administración de bases de datos Fundamentos de matemáticas Trabajo Fin de grado Número_créditos 6 6 12 Tipo Optativa Obligatoria Obligatoria Periodo 1C 1C 2C Tabla 4.36 Instancias asignatura. La instancia de grado_1 está relacionada con las tres instancias de Asignatura. Tras realizar las transformaciones de entidades en colecciones vistas anteriormente obtendríamos 4 documentos: Uno de ellos perteneciente a la colección Grados: el documento grado_1 [Tabla 4.37] y tres pertenecientes a la colección Asignatura, los documentos: asignatura_1, [Tabla 4.38] asignatura_2 [Tabla 4.39] y asignatura_3 [Tabla 4.40] conteniendo la siguiente información: // Colección Grados // Documento grado_1 { _id: ObjectId ('65c640a4ffdb3aec9dbf0d73 '), Número_grado: 123456, Nombre: Grado en ingeniería informática, } Tabla 4.37 Documento grado_1. // Documento asignatura_1 { _id: ObjectId('65c64223ffdb3aec9dbf0d7e'), Código_asignatura: 46962, Nombre_asignatura: Administración de bases de datos, Número_créditos: 6, Tipo: Optativa, Periodo: 1C } Tabla 4.38 Documento asignatura_1. // Documento asignatura_2 { _id: ObjectId('65c6425affdb3aec9dbf0d7f'), 84 Código_asignatura: 46901, Nombre_asignatura: Fundamentos de matemáticas, Número_créditos: 6, Tipo: Obligatoria, Periodo: 1C } Tabla 4.39 Documento asignatura_2. // Documento asignatura_3 { _id: ObjectId('65c642abffdb3aec9dbf0d80'), Código_asignatura: 46977, Nombre_asignatura: Trabajo Fin de grado, Número_créditos: 12, Tipo: Obligatoria, Periodo: 2C } Tabla 4.40 Documento asignatura_3. Incrustando los documentos de la colección Asignaturas en los documentos de la colección Grados obtendríamos un documento perteneciente a la colección Grados con toda la información referente a dicho grado, así como la de las asignaturas con las que está relacionado [Tabla 4.41]. // Colección Grados // Documento grado_1 { _id: ObjectId ('65c640a4ffdb3aec9dbf0d73 '), Número_grado: 123456, Nombre: Grado en ingeniería informática, Asignaturas: [ // Asignaturas relacionadas incrustadas { _id: ObjectId('65c64223ffdb3aec9dbf0d7e'), // Incrustamos asignatura 1 Código_asignatura: 46962, Nombre_asignatura: Administración de bases de datos, Número_créditos: 6, Tipo: Optativa, Periodo: 1C 85 }, { _id: ObjectId('65c6425affdb3aec9dbf0d7f'), // Incrustamos asignatura 2 Código_asignatura: 46901, Nombre_asignatura: Fundamentos de matemáticas, Número_créditos: 6, Tipo: Obligatoria, Periodo: 1C }, { _id: ObjectId('65c642abffdb3aec9dbf0d80'), // Incrustamos asignatura 3 Código_asignatura: 46977, Nombre_asignatura: Trabajo Fin de grado, Número_créditos: 12, Tipo: Obligatoria, Periodo: 2C } } } Tabla 4.41 Documentos asignatura incrustados en estudiante. 4.3.2.2 Relaciones uno a muchos con documentos referenciados. Al igual que hemos hecho con las relaciones tipo uno a uno podemos referenciar el tipo uno a muchos. Dados los documentos resultantes de la transformación de entidades en Colecciones en MongoDB descritos en las tablas [Tabla 4.32] y [Tabla 4.33]. Si un documento a se puede relacionar con varios documentos b y un documento b se puede relacionar con un documento a debemos realizar dos operaciones: 1. La primera es referenciar los documentos b relacionados con los documentos a. Para ello introducimos un campo clave valor adicional en los documentos a cuya clave será el nombre de la colección B y valor un array conteniendo los ObjectId de todos los documentos b relacionados. Los documentos a de la colección A tendrían la siguiente estructura [Tabla 4.42]: // Colección A // Documento a 86 { _id: < ObjectId_a>, atributo_a_1: valor_a_1, atributo_a_2: valor_a_2, atributo_a_2: valor_a_3, ... atributo_a_i: valor_a_i Nombre_colección_B: [<ObjectId_b1>, …, <ObjectId_bn>] // Referencia a n documentos b } Tabla 4.42 Documentos b referenciados en a. 2. La segunda es referenciar el documento a relacionado con el documento b. Para ello introducimos un campo clave valor adicional en los documentos b cuya clave será el nombre de la colección A y valor el ObjectID del documento a relacionado. Así los documentos de la colección B tendrían la siguiente estructura [Tabla 4.43]: // Colección B // Documento b_1 { _id: <ObjectId_b1>, atributo_b1_1: valor_b1_1, atributo_b1_2: valor_b1_2, ... atributo_b1_j: valor_b1_j, Nombre_coleccion_A: < ObjectId_a> // Referencia documento a } // Documento b_2 { _id: <ObjectId_b2>, atributo_b2_1: valor_b2_1, atributo_b2_2: valor_b2_2, ... atributo_b2_j: valor_b2_j, Nombre_coleccion_A: < ObjectId_a> // Referencia documento a } ... 87 // Documento b_n { _id: <ObjectId_bn>, atributo_bn_1: valor_bn_1, atributo_bn_2: valor_bn_2, ... atributo_bn_j: valor_bn_j Nombre_coleccion_A: < ObjectId_a> // Referencia documento a } Tabla 4.43 Documento b incrustado en a. Ejemplo: Veamos un ejemplo práctico de la conversión de una relación uno a muchos entre entidades en un diagrama Entidad-Relación referenciando los documentos resultantes de sus respectivas transformaciones en MongoDB. Vamos a volver a utilizar el ejemplo presentado a la hora de crear relaciones uno a muchos mediante documentos incrustados para observar la diferencia de utilizar uno u otro método. [Figura 4.23]. Figura 4.23 Ejemplo relación uno a muchos ER. Las colecciones y documentos resultantes de la transformación de las entidades y sus respectivos atributos son los mismos que obtuvimos en el apartado anterior: Grados (grado_1) [Tabla 4.37] asignatura_1, [Tabla 4.38] asignatura_2 [Tabla 4.39] y asignatura_3 [Tabla 4.40] Sin embargo, al referenciar los documentos de la colección Grados en el documento de la colección Asignaturas obtenemos 4 documentos: los 3 pertenecientes a Asignaturas con el campo adicional referenciando al grado con el que están relacionadas, mientras que el correspondiente a Grados tendrá el campo adicional con clave Asignaturas y valor un array conteniendo todos los ObjectId de las asignaturas. // Colección Asignaturas // Documento asignatura_1 88 { _id: ObjectId('65c64223ffdb3aec9dbf0d7e'), Código_asignatura: 46962, Nombre_asignatura: Administración de bases de datos, Número_créditos: 6, Tipo: Optativa, Periodo: 1C, Grados: '65c640a4ffdb3aec9dbf0d73 ' // Referencia a grado Ingeniería informática } Tabla 4.44 Instancia 1 asignatura. // Colección Asignaturas // Documento asignatura_2 { _id: ObjectId('65c6425affdb3aec9dbf0d7f'), Código_asignatura: 46901, Nombre_asignatura: Fundamentos de matemáticas, Número_créditos: 6, Tipo: Obligatoria, Periodo: 1C, Grados: '65c640a4ffdb3aec9dbf0d73 '// Referencia a grado Ingeniería informática } Tabla 4.45 Instancia 2 asignatura. // Colección Asignaturas // Documento asignatura_3 { _id: ObjectId('65c642abffdb3aec9dbf0d80'), Código_asignatura: 46977, Nombre_asignatura: Trabajo Fin de grado, Número_créditos: 12, Tipo: Obligatoria, Periodo: 2C, Grados: '65c640a4ffdb3aec9dbf0d73 '// Referencia a grado Ingeniería informática } Tabla 4.46 Instancia 3 asignatura. 89 // Colección Grados // Documento grado_1 { _id: ObjectId ('65c640a4ffdb3aec9dbf0d73 '), Número_grado: 542531987, Nombre: Grado en ingeniería informática, Asignaturas: [ '65c640a4ffdb3aec9dbf0d73 ', '65c6425affdb3aec9dbf0d7f', '65c642abffdb3aec9dbf0d80'] } Tabla 4.47 Instancia Grados sin cambios 4.3.3 Relaciones muchos a muchos. Cuando nos encontramos en un diagrama Entidad-Relación con relaciones muchos a muchos podemos utilizar los dos métodos vistos anteriormente para convertirlos en una base de datos con MongoDB: mediante documentos incrustados o mediante referencias entre documentos. Explicaremos ambos procesos de transformación, sin embargo, para este tipo siempre es recomendable hacerlo mediante documentos referenciados. Como hemos explicado en el punto referente a las relaciones uno a muchos con documentos referenciados [4.3.2.2] nuestros documentos pueden crecer de tamaño a medida que introduzcamos información en nuestra futura base de datos, haciendo que la información pueda ser extremadamente redundante y el rendimiento de la misma se vea afectado, además de ser uno de los pocos patrones de diseño a evitar o “anti patrones” (término utilizado por los propios desarrolladores de MongoDB). 18 En las relaciones tipo muchos a muchos, varias instancias de una entidad pueden estar relacionadas con varias instancias de otra entidad. Varias instancias del conjunto de entidades A pueden estar relacionadas con varias instancias del conjunto de entidades B, mientras que varias instancias del conjunto de entidades B pueden estar relacionadas con varias instancias del conjunto de entidades A. [Figura 4.24]. 18 Lauren Schaefer, Daniel Coupal “Schema design anti pattern massive arrays” [Recurso online] Disponible en: https://www.mongodb.com/developer/products/mongodb/schema-design-anti-pattern-massive-arrays/ Fecha última consulta: 01/06/2024 90 Figura 4.24 Relación muchos a muchos ER. 4.3.3.1 Relaciones muchos a muchos con documentos incrustados. Sean A y B conjuntos de entidades relacionadas muchos a muchos. Sean a y b documentos de las colecciones A y B respectivamente, resultantes de la transformación de dichas entidades en sus correspondientes colecciones. Si tenemos n documentos (con i campos cada uno) de la colección A relacionados con m documentos (con j campos cada uno) de la colección B. Y del mismo modo, los m documentos de la colección B relacionados con n documentos de la relación A. Dados n documentos a pertenecientes a la colección A: [Tabla 4.48] // Colección A // Documento a1 { _id: <ObjectId_a1>, atributo_a1_1: valor_a1_1, atributo_a1_2: valor_a1_2, atributo_a1_3: valor_a1_3, ... atributo_b1_j: valor_a1_i 91 } ... // Documento an { _id: <ObjectId_an>, atributo_an_1: valor_an_1, atributo_an_2: valor_an_2, atributo_an_3: valor_an_3, ... atributo_an_j: valor_an_i, } Tabla 4.48 Documentos colección A. Y dados m documentos b pertenecientes a la colección B: [Tabla 4.49] // Colección B // Documento b1 { _id: <ObjectId_b1>, atributo_b1_1: valor_b1_1, atributo_b1_2: valor_b1_2, atributo_b1_3: valor_b1_3, ... atributo_b1_j: valor_b1_j } ... // Documento bm { _id: <ObjectId_bm>, atributo_bm_1: valor_bm_1, atributo_bm_2: valor_bm_2, atributo_bm_3: valor_bm_3, ... atributo_bm_j: valor_bm_j, } Tabla 4.49 Documentos colección B. 92 Incrustando los documentos b en los documentos a con los que están relacionados obtendríamos documentos a de la colección A de la siguiente forma: [Tabla 4.50] // Colección A // Documento a1 { _id: <ObjectId_a1>, atributo_a1_1: valor_a1_1, atributo_a1_2: valor_a1_2, atributo_a1_3: valor_a1_3, ... atributo_a1_j: valor_a1_i, Nombre_colección_B: [ // Documentos b relacionados incrustados { _id: <ObjectId_b1>, atributo_b1_1: valor_b1_1, atributo_b1_2: valor_b1_2, atributo_b1_3: valor_b1_3, ... atributo_b1_j: valor_b1_j }, ... { _id: <ObjectId_bm>, atributo_bm_1: valor_bm_1, atributo_bm_2: valor_bm_2, atributo_bm_3: valor_bm_3, ... atributo_bm_j: valor_bm_j } ] } ... // Documento an { _id: <ObjectId_an>, atributo_an_1: valor_an_1, atributo_an_2: valor_an_2, 99 Número_créditos: 6, Tipo: Obligatoria, Periodo: 1C },{// Asignatura administración de bases de datos incrustada _id: ObjectId('65c64223ffdb3aec9dbf0d7e'), Código_asignatura: 46962, Nombre_asignatura: Administración de bases de datos, Número_créditos: 6 },{ _id: ObjectId('65c642abffdb3aec9dbf0d80'), Código_asignatura: 46977, Nombre_asignatura: Trabajo Fin de grado, Número_créditos: 12, Tipo: Obligatoria, Periodo: 2C ] } } Tabla 4.60 Resultado incrustar instancia 1 profesor. Para el documento profesor 2: [Tabla 4.61] // Colección Profesores // Documento instancia 2 profesor { _id: ObjectId('65c67dc6ffdb3aec9dbf0d93'), Número_profesor: 159263, Nombre: Ángela, Email: [email protected], Teléfono: 983222222, Asignaturas: [ // Asignaturas relacionadas incrustadas 100 {// Asignatura fundamentos de matemáticas incrustada _id: ObjectId('65c6425affdb3aec9dbf0d7f'), Código_asignatura: 46901, Nombre_asignatura: Fundamentos de matemáticas, Número_créditos: 6, Tipo: Obligatoria, Periodo: 1C },{ // Asignatura TFG incrustada _id: ObjectId('65c642abffdb3aec9dbf0d80'), Código_asignatura: 46977, Nombre_asignatura: Trabajo Fin de grado, Número_créditos: 12, Tipo: Obligatoria, Periodo: 2C ] } } Tabla 4.61 Resultado incrustar instancia 2 profesor. Y, por último, para el documento profesor 3: [Tabla 4.62] // Colección Profesores // Documento instancia 3 profesor { _id: ObjectId('65c67e35ffdb3aec9dbf0d94'), Número_profesor: 159263, Nombre: María Luz, Email: [email protected], Teléfono: 983333333, Asignaturas: [ // Asignaturas relacionadas incrustadas {// Asignatura Administración de bases de datos incrustada _id: ObjectId('65c64223ffdb3aec9dbf0d7e'), Código_asignatura: 46962, Nombre_asignatura: Administración de bases de datos, 101 Número_créditos: 6 },{ // Asignatura TFG incrustada _id: ObjectId('65c642abffdb3aec9dbf0d80'), Código_asignatura: 46977, Nombre_asignatura: Trabajo Fin de grado, Número_créditos: 12, Tipo: Obligatoria, Periodo: 2C ] } } Tabla 4.62 Resultado incrustar instancia 3 profesor. De igual forma podríamos incrustar documentos de la colección Profesor en documentos de la colección Asignatura si están relacionados entre sí. Por ejemplo, para la asignatura TFG los tres Profesores imparten dicha Asignatura: [Tabla 4.63] // Colección Asignaturas // Documento asignatura_3 { _id: ObjectId('65c642abffdb3aec9dbf0d80'), Código_asignatura: 46977, Nombre_asignatura: Trabajo Fin de grado, Número_créditos: 12, Profesores: [ // Profesores relacionados incrustados { _id: ObjectId('65c67d05ffdb3aec9dbf0d91'), Número_profesor: 159261, Nombre: Fernando, Email: [email protected], Teléfono: 983111111 },{ _id: ObjectId('65c67dc6ffdb3aec9dbf0d93'), Nombre: Ángela, Email: [email protected], 102 Teléfono: 983222222 },{ _id: ObjectId('65c67e35ffdb3aec9dbf0d94'), Número_profesor: 159263, Nombre: María Luz, Email: [email protected], Teléfono: 983333333 Tabla 4.63 Resultado incrustar instancia 3 asignatura. El resto de relaciones y documentos se crearían de la misma forma que hemos descrito tomando como documento principal Profesor, solo que esta vez insertando los ObjectID correspondientes a las relaciones de los documentos de la colección Asignatura. 4.3.3.1 Relaciones muchos a muchos con documentos referenciados. Al igual que hemos hecho con las relaciones tipo uno a uno y uno a muchos, podemos referenciar las relaciones existentes en el tipo muchos a muchos. Dados los documentos resultantes de la transformación de entidades en Colecciones en MongoDB descritos en las tablas [Tabla 4.48] y [Tabla 4.49]. Si un documento a se puede relacionar con varios documentos b y varios documentos b se pueden relacionar con varios documentos a debemos realizar dos operaciones: 1. La primera es referenciar los documentos a relacionados con los documentos b. Para ello introducimos un campo adicional en los documentos b cuya clave será el nombre de la colección A y valor un array conteniendo los ObjectId de todos los documentos a relacionados. Obteniendo la siguiente estructura para los documentos de la colección B: [Tabla 4.64] // Colección B // Documentos b { _id: <ObjectId_b1>, atributo_b1_1: valor_b1_1, atributo_b1_2: valor_b1_2, atributo_b1_2: valor_b1_3, 103 ... atributo_b1_i: valor_b1_j Nombre_coleccion_a: [ObjectId_a1,...,ObjectId_an] //Referencias a documentos a } ... // Documento bm { _id: <ObjectId_bm>, atributo_bm_1: valor_bm_1, atributo_bm_2: valor_bm_2, atributo_bm_3: valor_bm_3, ... atributo_bm_j: valor_bm_j, Nombre_coleccion_A: [ObjectId_a1,...,ObjectId_an] //Referencias a documentos a } Tabla 4.64 Resultado referenciar n a m, documentos b. 2. La segunda es referenciar los documentos b relacionados con los documentos a. Para ello introducimos un campo adicional en los documentos a cuya clave será el nombre de la colección B y valor un array conteniendo los ObjectId de todos los documentos b relacionados. Obteniendo así los documentos de la colección A con la siguiente estructura: [Tabla 4.65] // Colección A // Documentos a { _id: <ObjectId_a1>, atributo_a1_1: valor_a1_1, atributo_a1_2: valor_a1_2, atributo_a1_2: valor_a1_3, ... atributo_a1_i: valor_a1_i Nombre_coleccion_B: [ObjectId_b1,..., ObjectId_bm] //Referencias a documentos b 104 } ... // Documento an { _id: <ObjectId_an>, atributo_an_1: valor_an_1, atributo_an_2: valor_an_2, atributo_an_3: valor_an_3, ... atributo_an_j: valor_an_j, nombre_colección_B: [ObjectId_b1, ..., ObjectId_bm] //Referencias a documentos b } Tabla 4.65 Resultado referenciar n a m, documentos a. Ejemplo: Veamos un ejemplo práctico de la conversión de una relación muchos a muchos entre entidades en un diagrama Entidad-Relación referenciando documentos en MongoDB. Vamos a volver a utilizar el ejemplo presentado a la hora de crear relaciones muchos a muchos mediante documentos incrustados para observar la diferencia de utilizar uno u otro método. [Figura 4.26]. Figura 4.26 Relación muchos a muchos ER. Igualmente utilizaremos las instancias de Profesor y Asignatura utilizadas en la anterior transformación mediante documentos incrustados: [Tabla 4.52] y [Tabla 4.53] La instancia 1 de Profesor (Fernando) está relacionada mediante imparte con las instancias de Asignatura Fundamentos de matemáticas, Administración de bases de Datos y Trabajo Fin de Grado. Añadimos un campo extra en el documento de dicha instancia con clave el nombre de la colección con la que está relacionada (Asignatura) y tres valores, los ObjectId de dichas asignaturas. Añadimos al documento profesor_1 un campo con clave el nombre Asignaturas y valor los tres ObjectID de las asignaturas con las que está relacionado. [Tabla 4.66] 105 // Colección Profesor // Documento profesor_1 { _id: ObjectId('65c67d05ffdb3aec9dbf0d91'), Número_profesor: 159261, Nombre: Fernando, Email: [email protected], Teléfono: 983111111 Asignatura: ['65c6425affdb3aec9dbf0d7f', '65c64223ffdb3aec9dbf0d7e', '65c642abffdb3aec9dbf0d80'] } Tabla 4.66 Resultado referenciar instancia 1 de profesor La instancia 2 de Profesor (Ángela) está relacionada mediante imparte con las Asignaturas Fundamentos de matemáticas y Trabajo Fin de Grado. Realizamos el mismo proceso, esta vez añadiendo los ObjectId correspondientes. [Tabla 4.67] // Colección Profesor // Documento profesor_2 { _id: ObjectId('65c67dc6ffdb3aec9dbf0d93'), Número_profesor: 159262, Nombre: Ángela, Email: [email protected], Teléfono: 983222222 Asignaturas: ['65c6425affdb3aec9dbf0d7f', '65c642abffdb3aec9dbf0d80'] } Tabla 4.67 Resultado referenciar instancia 2 de profesor Por último, la instancia 3 de Profesor (María Luz) está relacionada mediante imparte con Trabajo Fin de Grado y Administración de bases de datos. Referenciamos en el documento correspondiente los ObjectID de las dos asignaturas. [Tabla 4.68] // Colección Profesor // Documento profesor_3 { _id: ObjectId('65c67e35ffdb3aec9dbf0d94'), 106 Número_profesor: 159263, Nombre: María Luz, Email: [email protected] Teléfono: 983333333 Asignatura: ['65c6425affdb3aec9dbf0d7f', '65c64223ffdb3aec9dbf0d7e'] } Tabla 4.68 Resultado referenciar instancia 3 de profesor De esta forma quedarían referenciadas las asignaturas con las que están relacionados los profesores dentro de estos últimos. Ahora tendríamos que insertar dentro de los documentos de la colección Asignaturas las referencias a los profesores con los que están relacionados: [Tabla 4.69] [Tabla 4.70] [Tabla 4.71] // Colección Asignatura // Documento asignatura_1 { _id: ObjectId('65c64223ffdb3aec9dbf0d7e'), Código_asignatura: 46962, Nombre_asignatura: Administración de bases de datos, Número_créditos: 6, Tipo: Optativa, Periodo: 1C Profesor: ['65c67d05ffdb3aec9dbf0d91', '65c67e35ffdb3aec9dbf0d94'] } Tabla 4.69 Resultado referenciar instancia 1 de asignatura. // Colección Asignatura // Documento asignatura_2 { _id: ObjectId('65c6425affdb3aec9dbf0d7f'), Código_asignatura: 46901, Nombre_asignatura: Fundamentos de matemáticas, Número_créditos: 6, Tipo: Obligatoria, Periodo: 1C Profesor: ['65c67d05ffdb3aec9dbf0d91', '65c67dc6ffdb3aec9dbf0d93'] } Tabla 4.70 Resultado referenciar instancia 2 de asignatura. 107 // Colección Asignatura // Documento asignatura_3 { _id: ObjectId('65c642abffdb3aec9dbf0d80'), Código_asignatura: 46977, Nombre_asignatura: Trabajo Fin de grado, Número_créditos: 12, Tipo: Obligatoria, Periodo: 2C Profesor: ['65c67d05ffdb3aec9dbf0d91','65c67dc6ffdb3aec9dbf0d93', '65c67e35ffdb3aec9dbf0d94'] } Tabla 4.71 Resultado referenciar instancia 3 de asignatura. Una vez expuestos ambos ejemplos de transformación de relaciones N:M a sus correspondientes colecciones y documentos en MongoDB y aun siendo únicamente 3 documentos por colección, podemos observar que es mucho más beneficioso, en términos del crecimiento de los arrays contenedores de la información, referenciar los documentos antes que incrustar la información de unos en otros. 4.4 Transformación jerarquía ISA (generalización/especialización). Dado un conjunto de entidades de mayor orden (llamémosle A) con i atributos, y un número x de entidades de menor orden (el conjunto de entidades B con j atributos… el conjunto de entidades X con k atributos) las cuales están relacionadas mediante jerarquía ISA con la entidad A de mayor orden. [Figura 4.27] Figura 4.27 jerarquía ISA ER. 108 Sean A, B…X conjuntos de entidades relacionadas muchos a muchos. Sean a, b, … x documentos de sus respectivas colecciones, resultantes de la transformación de dichas entidades en sus correspondientes colecciones. Cada uno de los documentos con un número determinado de campos clave valor (i campos para los documentos a, j campos para los documentos b,…,k campos para los documentos x). Podemos abordar la transformación de dicha jerarquía ISA en sus respectivas colecciones, documentos y relaciones en MongoDB de tres maneras distintas con diferentes resultados: 1. Integrando la jerarquía de generalización en una sola colección. Los documentos pertenecientes a dicha colección tendrán como campos clave valor todos los atributos de cada uno de los conjuntos de entidades participantes de la relación ISA. Se mantendrá una única colección con nombre la de mayor orden cuyos documentos tendrán tantos campos clave valor como atributos tuviesen todas las entidades participantes (i + j+ … +k) más uno que será el objectId del documento a. [Tabla 4.72] De esta forma perderíamos el concepto de generalización/especialización. // Colección A // Documento a { _id: <ObjectId_a>, atributo_a_1: valor_a_1, atributo_a_2: valor_a_2, ... atributo_a_i: valor_a_i, atributo_b_0: valor_b_1, atributo_b_1: valor_b_2, ... atributo_b_j: valor_b_j, ... atributo_x_1: valor_x_1, atributo_x_2: valor_x_2, ... atributo_x_k: valor_x_k } Tabla 4.72 Resultado primera transformación ISA. 115 Curso_grado: Cuarto, Título_TFG: Método de transformación de un diagrama ER, Estudiante: '65d1fa41b55dcd9eddd12e77'// Referencia } Tabla 4.83 Documento estudiante_grado. // Colección Estudiante_master // Documento estudiante_máster { _id: ObjectId('65d1f9d5b55dcd9eddd12e75'), Estudiante: '65d1fa86b55dcd9eddd12e78' Curso_máster: Segundo, Título_TFM: Método de transformación de una base de datos con MongoDB, Estudiante: '65d1f9d5b55dcd9eddd12e75' //Referencia } Tabla 4.84 Documento estudiante_máster. 4.5 Entidades asociativas. Las entidades asociativas relacionan las instancias de uno o más conjuntos de entidades y contiene atributos los cuales pertenecen a dicha relación entre esas instancias de entidades. [Figura 4.29] Figura 4.29 Entidad asociativa modelo ER. Sean A y B conjuntos de entidades (cada una de ellas con i y j atributos) relacionadas por un conjunto de entidades asociativas C (con k atributos). En su paso a MongoDB el conjunto de entidades A sería la colección A y una instancia de A sería un documento a el cual tendría i+1 campos clave valor. [Tabla 4.85] 116 // Colección A // Documento a { _id: <ObjectId_a>, Atributo_a_1: valor_a_1, Atributo_a_2: valor_a_2, ... Atributo_a_i: valor_a_i } Tabla 4.85 Documento colección A. El conjunto de entidades B sería la colección B y una instancia de b sería un documento b con j+1 campos clave valor. [Tabla 4.86] // Colección B // Documento b { _id: <ObjectId_b>, Atributo_b_1: valor_b_1, Atributo_b_2: valor_b_2, ... Atributo_b_j: valor_b_j } Tabla 4.86 Documento colección B. El conjunto de entidades asociativas C sería una colección C y una instancia de c sería un documento c con k+3 campos clave valor: uno de ellos correspondiente al propio ObjectID del documento, otro con clave el nombre de la colección A y valor el ObjectID del documento a con el que está relacionado y por último uno con clave el nombre de la colección B y valor el ObjectID del documento b con el que está relacionado. [Tabla 4.87] // Colección C // Documento c { _id: <ObjectId_c>, Atributo_c_1: valor_c_1, Atributo_c_2: valor_c_2, 117 ... Atributo_c_k: valor_c_k, Nombre_coleccion_A: ObjectId_a, // Referencia a documento a Nombre_colección_B: ObjectId_b // Referencia a documento b } Tabla 4.87 Documento colección C. Ejemplo: Veamos el siguiente ejemplo de un diagrama Entidad-Relación con una entidad asociativa: [Figura 4.30] Figura 4.30 Ejemplo entidad asociativa modelo ER. Tomemos tres instancias: estudiante_1, estudiante _2 y estudiante _3 del conjunto de entidades Estudiantes con los siguientes valores de atributos: [Tabla 4.88] Estudiante Instancia 1 Instancia 2 Instancia 3 Número_estudiante 321261 321262 321263 Nombre_estudiante Rubén Henar Miguel Centro ETSII ESS ESA Tabla 4.88 Instancias estudiante. Tomemos tres instancias carrera_1, carrera_2 y carrera_3 del conjunto de entidades Carreras con los siguientes valores de atributos: [Tabla 4.89] Carreras Instancia 1 Instancia 2 Instancia 3 Número_carrera 159687 159345 159276 Nombre_carrera Ingeniería informática Psicología Periodismo Campus Valladolid Palencia Soria Tabla 4.89 Instancias carreras. Tenemos la siguiente información a introducir en nuestra base de datos: - El estudiante Rubén obtuvo el título en Periodismo el año 2000, así como el de Ingeniería informática en el 2023. 118 - La estudiante Henar obtuvo el título en Psicología en el año 2024. - Por último, el estudiante Miguel obtuvo el título en Periodismo en el año 2000. Tomemos tres instancias títulos_1, títulos_2 y títulos_3 del conjunto de entidades asociativa Títulos, asociadas a sus respectivas asociaciones con Estudiantes y Carreras con los siguientes valores de atributos: [Tabla 4.90] Títulos Instancia 1 Instancia 2 Instancia 3 Instancia 4 Número_título 21 22 23 24 Fecha_obtencíon 2024 2023 2022 2000 Tabla 4.90 Instancias Títulos. Los documentos resultantes en MongoDB pertenecientes a la colección Profesores tras realizar las oportunas transformaciones serían los siguientes: [Tabla 4.91] [Tabla 4.92] [Tabla 4.92] // Documento estudiante_1 { _id: ObjectId ('65d9be24c9215662e68ca821'), Número_estudiante: 321261, Nombre: Rubén, Centro: ETSII } Tabla 4.91 Instancia 1 estudiante. // Documento estudiante_2 { _id: ObjectId (65d9be93c9215662e68ca822), Número_estudiante: 321262, Nombre: Henar, Centro: ESS } Tabla 4.92 Instancia 2 estudiante. // Documento estudiante_3 { _id: ObjectId (65d9bf54c9215662e68ca823), Número_estudiante: 321263, 119 Nombre: Miguel, Centro: ESA } Tabla 4.93 Instancia 3 estudiante. Mientras que los documentos resultantes en MongoDB pertenecientes a la colección Carreras tras realizar las oportunas transformaciones serían los siguientes: [Tabla 4.94] [Tabla 4.95] [Tabla 4.96] // Documento carrera_1 { _id: ObjectId (65d9cb50c9215662e68ca825), Número_carrera: 159687, Nombre_carrera: Ingeniería informática, Campus: Valladolid } Tabla 4.94 Instancia 1 carrera. // Documento carrera_2 { _id: ObjectId (65d9cbadc9215662e68ca826), Número_carrera: 159345, Nombre_carrera: Psicología, Campus: Palencia } Tabla 4.95 Instancia 2 carrera. // Documento carrera_3 { _id: ObjectId (65d9cbd5c9215662e68ca827), Número_carrera: 159276, Nombre_carrera: Periodismo, Campus: Soria } Tabla 4.96 Instancia 3 carrera. 120 Utilizando las reglas de transformación para las entidades asociativas propuestas en este punto, los documentos asociados a la colección Títulos tendrían la siguiente información: El estudiante Rubén obtuvo el título en Periodismo el año 2000, así como el de Ingeniería informática en el 2023. Se crean dos documentos, uno por título obtenido [Tabla 4.97], y [Tabla 4.98] referenciando tanto el Estudiante que lo obtuvo como la Carrera a la que pertenece el título. // Documento título_1 { _id: ObjectId (65d9de6bc9215662e68ca836), Número_título: 24, Fecha_obtención: 2000, Estudiantes: '65d9be24c9215662e68ca821', // Estudiante Rubén Carreras: '65d9cbd5c9215662e68ca827' // Carrera periodismo } Tabla 4.97 Instancia 1 título. // Documento título_2 { _id: ObjectId (65d9de4ec9215662e68ca834), Número_título: 22, Fecha_obtención: 2023, Estudiantes: '65d9be24c9215662e68ca821', // Estudiante Rubén Carreras: '65d9cb50c9215662e68ca825' // Carrera ingeniería } Tabla 4.98 Instancia 2 título. La estudiante Henar obtuvo el título en Psicología en el año 2024. Se crea el documento perteneciente a la colección Título referenciando tanto a la estudiante como a la carrera asociada. [Tabla 4.99] // Documento título_3 { _id: ObjectId (65d9de0bc9215662e68ca833), Número_título: 21, Fecha_obtención: 2024, Estudiantes: '65d9be93c9215662e68ca822', // Estudiante Henar Carreras: '65d9cbadc9215662e68ca826' // Carrera Psicología 121 } Tabla 4.99 Instancia 3 título. Por último, el estudiante Miguel obtuvo el título en Periodismo en el año 2023. Referenciamos tanto al estudiante Miguel como la carrera Periodismo en el documento de Título. [Tabla 4.98] // Documento título_4 { _id: ObjectId (65d9de6bc9215662e68ca836), Número_título: 23, Fecha_obtención: 2000, Estudiantes: 65d9bf54c9215662e68ca823, //Estudiante Miguel Carreras: 65d9cbd5c9215662e68ca827//Carrera periodismo } Tabla 4.100 Instancia 4 título. 4.6 Relaciones recursivas. Son aquellas relaciones en las que una entidad se relaciona consigo misma. Este tipo de relaciones requieren un nombre en el vínculo (rol). [Figura 4.31] Figura 4.31 Ejemplo entidad recursiva. Para anteriores transformaciones se han estudiado a lo largo de este trabajo diferentes formar de relacionar los documentos. Las relaciones recursivas pertenecientes a un diagrama ER también podríamos convertirlas a MongoDB con los instrumentos estudiados: podríamos crear dos colecciones para posteriormente incrustarlas o referenciarlas, o utilizar los mecanismos de herencia o relaciones jerárquicas vistos en las transformaciones ISA. Sin embargo, para continuar 122 con la estructura de conversiones que hemos utilizado hasta ahora y mantener una única colección por entidad representada en el diagrama (que en este caso representa la entidad o relación recursiva) decidimos crear una única colección y realizar la referencia dentro de los documentos que la componen. Sea A un conjunto de entidades relacionadas con el mismo conjunto de entidades A (entidad recursiva) con i atributos. En su paso a MongoDB el conjunto de entidades A sería la colección A y una instancia de A sería un documento a con i+3 campos clave valor. Uno para el ObjectID del propio documento y otros dos con clave el nombre del rol 1 y valor el ObjectId con el que está relacionado, el último con clave el nombre del rol 2 y valor el ObjectId con el que está relacionado. [Tabla 4.101] Definida esta estructura de documentos, si en la entidad recursiva existen instancias que no tengan valor para alguno de los dos roles bastaría con marcar el valor del campo como null o no introducir el campo clave-valor referente a ese rol. Además, esta estructura nos permite recursividad en árbol (en el sentido de que una instancia a puede estar relacionada de forma recursiva con una b y esta a su vez con una c o la misma a) simplemente referenciando la instancia o documento con el que esté relacionado. // Colección A // Documento a1 { _id: <ObjectId_a1>, Atributo_a1_1: valor_a1_1, Atributo_a1_2: valor_a1_2, ... Atributo_a1_i: valor_a1_i, Nombre_rol1: <ObjectId_ax>, // Siendo ax el documento relacionado con nombre rol 1 Nombre_rol2: <ObjectId_ay> // Siendo ay el documento relacionado con nombre rol 2 } Tabla 4.101 Transformación entidad recursiva. Ejemplo: Dentro del entorno de la Universidad existe un programa llamado Programa mentor en el que alumnos veteranos ayudan en diferentes facetas del entorno universitario a aquellos que llegan por primera vez a la Universidad. Ambos son estudiantes con una serie de atributos comunes, la única diferencia es que unos pueden hacer de mentor de otros (los denominaremos Aprendices). En la siguiente figura vemos el componente del diagrama ER en el que se representa dicha entidad recursiva [Figura 4.32] 123 Figura 4.32 Ejemplo entidad recursiva ER. Tomemos dos instancias: estudiante_1 y estudiante _2 del conjunto de entidades recursivas Estudiantes con los siguientes valores de atributos: [Tabla 4.102] Estudiante Instancia 1 Instancia 2 Número_estudiante 321261 321262 Nombre_estudiante Rubén Henar Centro ETSII ESS Tabla 4.102 Instancias estudiante. La estudiante Henar es mentora del estudiante Rubén, mientras que Rubén es mentor de la estudiante Henar. Solo tendríamos que crear una colección con nombre Estudiantes y referenciar los documentos con la información de Rubén y Henar como comentábamos en la regla de transformación. [Tabla 4.103] y [Tabla 4.104] // Colección Estudiante // Documento estudiante_1 { _id: ObjectId ('65d9be24c9215662e68ca821'), Número_estudiante: 321261, Nombre: Rubén, Centro: ETSII Mentor: null, // o podemos omitir el campo Aprendiz: '65d9be93c9215662e68ca822'// Aprendiz de Henar } Tabla 4.103 Instancia 1 estudiante. // Colección Estudiante // Documento estudiante_2 { 124 _id: ObjectId (65d9be93c9215662e68ca822), Número_estudiante: 321262, Nombre: Henar, Centro: ESS, Mentor: '65d9be24c9215662e68ca821’, // Mentor de Rubén Aprendiz: null, // o podemos omitir el campo } Tabla 4.104 Instancia 2 estudiante. 4.7 Agregación. Hay ocasiones en las que existe una relación entre conjuntos de entidades (supongamos A y B) y se desea relacionar ese conjunto (ambas entidades junto con su relación asociada) con otro conjunto de entidades diferente C. [Figura 4.33] Figura 4.33 Ejemplo agregación ER Trataremos la relación entre entidades (en el ejemplo la relación R entre el conjunto de entidades A y B) como un conjunto de entidades de orden superior o más compleja que llamaremos G. A la hora de transformar el concepto de agregación en MongoDB el primer paso a realizar es transformar el conjunto de entidades superior (G) con las técnicas vistas ahora dependiendo del tipo de relación existente entre ambos conjuntos de entidades 1:1 [4.3.1] , 1:N [4.3.2] o N:M [4.3.3] 131 conteniendo todos los campos clave valor de cada uno de los documentos de la colección a con los que está relacionado. Generalización y especialización Jerarquía ISA (Generalización y especificación) Tres posibles soluciones: 1. Integrando la jerarquía de generalización en una sola colección. 2. Eliminando el conjunto de entidades de orden superior y transformando el conjunto de entidades de inferior orden en sus respectivas colecciones. 3. Transformando todos los conjuntos de entidades participantes en la relación ISA, cada uno de ellos en una colección. (Mejor aproximación) Relaciones recursivas Recursivas El conjunto de entidades A sería la colección A y una instancia de A sería un documento a con i+3 campos clave valor. Uno para el ObjectID del propio documento y otros dos adicionales. Uno con clave el nombre del rol 1 y tantos valores como documentos con los que esté relacionado conteniendo los ObjectId de los mismos, el último con clave el nombre del rol 2 y tantos valores como documentos con los que esté relacionado conteniendo los ObjectId de los mismos Entidades asociativas Asociativas Siendo C una entidad asociativa. En su paso a MongoDB el conjunto de entidades A sería la colección A y una instancia de A sería un documento a el cual tendría i+1 campos clave valor. El conjunto de entidades B sería la colección B y una instancia de b sería un documento b con j+1 campos clave valor. El conjunto de entidades asociativas C sería una colección C y una instancia de c sería un documento c con k+3 campos clave valor: uno de ellos correspondiente al propio ObjectID del documento, otro con clave el nombre de la colección A y valor el ObjectID del documento a con el que está relacionado y por último uno con clave el nombre de la colección B y valor el ObjectID del documento b con el que está relacionado. 132 Agregación Sea una relación entre conjuntos de entidades (supongamos A y B) y se desea relacionar ese conjunto G (ambas entidades junto con su relación asociada) superior con otro conjunto de entidades diferente C mediante la relación s Agregación Transformamos el conjunto de entidades superior G con las técnicas vistas ahora dependiendo del tipo de relación existente entre ambos conjuntos de entidades 1:1, 1:N o N:M Posteriormente transformaremos el conjunto de entidades C del mismo modo que transformamos los conjuntos de entidades. Por último, añadimos dos nuevos campos clave valor a los documentos c de la colección C. Las claves serán los nombres de las colecciones A y B mientras que el valor asociado dependerá del tipo de relación (1:1, 1:N o N:M) de S. Dichos valores serán referencias a los documentos relacionados de sus respectivas colecciones. Tabla 4.114 Tabla resumen reglas de transformación. 133 Capítulo 5 Ejemplo de transformación. Una vez definidas las reglas de transformación para los diferentes componentes de un diagrama Entidad-Relación, en este capítulo se realizará la transformación de un diagrama ER completo en su correspondiente base de datos en MongoDB aplicando las reglas enunciadas en el capítulo anterior. [Capítulo 4] Debido a la extensión que supondría incluir las transformaciones de todas las instancias en sus respectivas colecciones, documentos y relaciones, solo vamos a incluir en esta memoria una de ellas para cada uno de los componentes que aparecen en el diagrama ER objeto de transformación a modo de ejemplo. En el script adjunto en este TFG se puede consultar todo el código necesario para crear la base de datos completa utilizando una máquina con una instalación de MongoDB. 19 Para este capítulo, se ha decidido crear una base de datos que alberga la información referente a la proyección de películas en un conjunto de cines de una ciudad. Debido a que, en el apartado anterior, los datos de instancias utilizados han sido elegidos por el autor de este trabajo, se ha creído conveniente que la información del ejemplo de transformación completo sea referente a datos que pueden ser fácilmente accesibles con una simple conexión a internet (como pueden ser que directores o actores han llevado a cabo una determinada película, a que género pertenecen las mismas, o diferente información sobre algunos de los datos que vamos a exponer a continuación). Independientemente, en el primer anexo de esta memoria [Anexo 1] se adjuntan tablas con las relaciones existentes entre las distintas instancias con las que hemos poblado nuestra base de datos para que sea más sencillo, una vez consultado el código, ver la relaciones que existen entre ellas. 19 Rubén de Diego Varona “Código capítulo 5 TFG” [Recurso online] Disponible en: https://github.com/rubdedi/MongoDB/blob/main/TfgCap%C3%ADtulo5.js Fecha última consulta: 01/06/2024 134 5.1 Requisitos. Se desea crear una base de datos para una aplicación llamada Cine_TFG de la que se desea almacenar la siguiente información: Los cines de la ciudad de Valladolid, cada uno de los cuales tienen un número de cine independiente del resto, un nombre, una dirección completa (que consta del nombre de la calle, el número la ciudad y el código postal) así como el o los números de teléfono de contacto del cine. Cada uno de estos cines proyectará una o más películas, pero siempre están en activo y tienen alguna proyección. Se desea almacenar así un conjunto de películas. Estas no tienen por qué estar siendo emitidas en alguno de los cines, sino que también se guardarán aquellas que ya hayan sido proyectadas o de las que se sepa que van a proyectarse próximamente. De cada una de estas películas se quiere guardar su número de película, el título, tanto original como con el que llegó a nuestro país, la duración en minutos, el país en el que se produjo y la fecha de estreno internacional. Igualmente se desea conocer el género al que pertenece cada película, teniendo en cuenta que una película puede ser de un único género o de varios. Por cada película se almacenarán el o los directores que se encargaron de llevarla a cabo, así como los actores que la interpretaron, teniendo en cuenta que aquellas películas de no ficción o documentales no cuentan con actores. De cada uno de ellos (tanto de los actores como de los directores) queremos saber el número que les identifica, así como su nombre, fecha de nacimiento y nacionalidad. También se desea (en caso de que exista) almacenar una cita perteneciente a la película y por la que se haya hecho famosa o sea conocida. De la misma se desea almacenar la cita textual tal cual se expresó en la película y el personaje (que no actor) que la entonó. Es posible que las películas hayan recibido críticas. Si es así se desea almacenar hasta un máximo de 100 críticas por película, y de cada una de ellas su número, un breve resumen y las estrellas (a modo de nota) con las que se las valoró (siendo el número mínimo de estrellas 1 y un máximo de 5). Sabemos que estas críticas están escritas o publicadas por críticos (cada uno con su número y nombre) los cuales publican las mismas en un solo medio cada uno (no existen críticos que escriban en dos o más medios) distintos, y que estos medios pueden de dos tipos: el medio tradicional impreso (periódicos o revistas) en cuyo caso se desea saber su tirada y si esta es nacional o internacional, o bien pueden ser medios digitales, en cuyo caso se desea saber su Url, además del número de medio, nombre y país del cual procede dicho medio. Nota: Las instancias utilizadas para crear esta base de datos se han tomado de la web Filmaffinity, tanto la información de las películas como la de los actores y directores de las mismas. 20 20 Filmaffinity España [Recurso online] Disponible en: https://www.filmaffinity.com/es/main.html Fecha última consulta: 01/06/2024 135 5.2 Diagrama Entidad-Relación. Dados los requisitos proporcionados en el apartado obtenemos el diagrama Entidad-Relación que se muestra en la [Figura 5.1] Figura 5.1 Diagrama Entidad-Relación Cines 136 5.2.1 Entidades y atributos. Veamos cual ha sido el proceso que hemos llevado a cabo para obtener este diagrama E-R. El primer paso a la hora de crear un diagrama Entidad-Relación es identificar las entidades y sus respectivos atributos. Atendiendo a los requisitos proporcionados plasmamos las siguientes entidades en el diagrama E-R de la [Figura 5.1]: - Cines: Representa el conjunto de todos los cines en el universo planteado (en este caso Valladolid). Esta entidad va a poseer los siguientes atributos: Número_cine (el cual va a ser el atributo identificador, ya que este es único para el conjunto de todas ellas. Cada una de sus instancias va a tener su propio número de cine, el cual no se puede repetir e identifica de forma unívoca al mismo). Nombre_Cine indica el nombre del mismo, Dirección atributo compuesto a su vez de los siguientes atributos simples: Calle, Número, Ciudad (sabemos que es Valladolid ya que nos limitamos a ese universo, pero se nos pide almacenar la misma). Teléfono, atributo multivaluado ya que su valor puede ser múltiple y por último Código_postal. - Películas: Esta entidad representa todas las películas emitidas, en emisión o por emitir en los diferentes cines de Valladolid. Sus atributos serán Número_película (atributo identificador del conjunto de entidades), Título (representará el nombre de la misma con el que se estrenó en nuestro país), Título_original (pudiendo coincidir con el anterior, pero almacenándolo como un atributo diferente), Duración (en minutos) País (indicará la nacionalidad de producción) y Fecha_estreno (el día en el que se presentó en salas). - Géneros: Cada película pertenece a uno (o varios) de ellos. Decidimos identificarlo como entidad. Podríamos tratarlos como atributos de la entidad Película (con tipo multi valor), pero decidimos crear una entidad independiente para representarlos ya que nos parece una forma más natural de ver los datos (característica de este tipo de diagramas). Sus atributos serán Número_género (identificador) y Nombre_género. - Directores: Representa el conjunto de directores que, valga la redundancia, dirigen películas o documentales. Sus atributos serán Número_director (atributo identificador o identificativo), Nombre_director, Fecha_ nacimiento y Nacionalidad. Todos ellos atributos simples ya que solo pueden tener un único valor. - Actores: Representa el conjunto de actores de las diferentes películas. Los atributos de esta entidad serán: Número_actor, Nombre, Fecha_ nacimiento y Nacionalidad. Al igual que con la entidad Directores, todos sus atributos serán de tipo simple. - Citas: Esta entidad tendrá dos atributos, la Cita_textual nombrada en la película a la que pertenece, así como el Personaje que la interpreta en la película. Observamos que esta entidad no existiría de no ser de la existencia de la entidad Películas, por lo que tenemos una entidad débil (y así la plasmaremos en el diagrama) y, por lo tanto, carece de atributo identificador. 137 - Críticas: Con tres atributos diferentes, uno de ellos el atributo identificador (Número_crítica), así como Estrellas y Resumen de la misma. - Críticos: Esta entidad representará el conjunto de críticos que valoran las diferentes películas que almacenaremos en nuestra base de datos. Posee dos atributos: Número_crítico (atributo identificador de la entidad) y Nombre (atributo simple). - Medios: Entidad que representa los diferentes medios para los que trabajan los críticos de películas. Con tres atributos todos ellos simples: Número_medio (identificador), Nombre_medio y País cuyo valor será el mismo al que pertenece. A la hora de analizar los requisitos y crear el diagrama Entidad-Relación hemos identificado en primer lugar la entidad de orden superior Medios (con los atributos antes nombrados para todo el conjunto de entidades), para posteriormente identificar dos entidades de orden inferior Medios_impresos y Medios_digitales. Este proceso es el de la especialización. Si hubiésemos identificado las entidades de orden inferior en primer lugar (para posteriormente hacerlo con una de orden superior con un conjunto de atributos comunes para todas), hablaríamos de Generalización. Podemos observar que el resultado final a la hora de implementar las entidades en el diagrama no variaría. - Medios_impresos: Entidad perteneciente a la jerarquía ISA identificada con dos atributos simples: Tirada que representará el número de ejemplares repartidos para su venta y Nacional cuyos valores podrán ser “sí” o “no” (dependiendo de si se distribuye en nuestro país o en el extranjero). - Medios_digitales: Con un único atributo Url que tendrá como valor la dirección web del mismo. 5.2.2 Relaciones. Una vez identificadas y representadas las entidades de nuestro diagrama Entidad-Relación debemos hacerlo con las relaciones existentes entre las mismas para, posteriormente indicar la cardinalidad entre las relaciones y las entidades y, a partir de ellas, obtener el tipo de la relación. De esta forma las relaciones que identificamos partiendo de los requisitos presentados son las siguientes: - Proyecta: Relación existente entre las entidades Cines y Películas. Un cine puede proyectar una o varias películas (1,n), mientras que una película puede no ser proyectada en un cine (porque ya ha sido proyectada o lo hará en un futuro, o incluso no se proyecta nunca) o puede ser proyectada (esa misma instancia) en varios cines de forma simultánea (0,n). Tomamos la mayor de las cardinalidades identificadas en esta relación (como haremos en las restantes) y obtenemos un tipo de relación N:M (muchos a muchos). 138 - Tiene: Es la relación entre la entidad débil Cines y la entidad fuerte de la que depende esta última, Películas. Es por ello que es una relación identificante y la representamos como tal en el diagrama asociado (con un rombo doble o rombo con doble línea). Una película puede o no tener citas (0,n), mientras que una cita solo puede pertenecer a una película (y además se nos expresa en los requisitos que no se desea almacenar más de una), siendo así esta cardinalidad de (1,). Así obtenemos el tipo de la relación Tiene: 1:N (uno a muchos). - Pertenece: Esta relación existe entre las entidades Géneros y Películas. Una película ha de pertenecer, mínimo, a un determinado género (1,n), al igual que a un género le pueden corresponder una o varias películas (1,n). No existen películas sin género. El tipo de la relación Pertenece es por tanto del tipo N:M (muchos a muchos). - Dirige: Relación existente entre las entidades Directores y Películas. Una película puede tener uno o varios directores (no existen películas sin ellos) (1,n), mientras que un director puede dirigir una o más películas (1,n). Tenemos una relación del tipo N:M (Muchos a muchos). - Precede: Relación existente entre diferentes instancias de Películas. Es por ello que es una relación recursiva y debemos nombrar sus roles, que serán Precuela y Secuela. Una película solo puede tener una precuela (1,1), al igual que una única secuela (1,1) Relación recursiva tipo 1:1 (uno a uno). - Interpreta: Relación existente entre Películas y Actores. Un actor puede interpretar una o varias películas (1,n) mientras que una película puede no tener actores si es un documental (como se nos indica en los requisitos) o puede que tenga varios (0,n). Tipo de relación N:M (muchos a muchos). - Reciben: Las Películas reciben Críticas. Una película puede o no tener críticas. En caso de tenerlas, se nos especifica que el máximo número a almacenar en nuestra base de datos es de 100 (identificamos una cardinalidad min, max) (0,100). Mientras que una determinada crítica pertenece a una determinada película. Tipo de relación de Reciben 1:N (uno a muchos). - Escriben: Relación entre Críticas y Críticos. Un crítico puede escribir una o varias críticas (1,n), pero una crítica es escrita por un determinado crítico (1,1). Tipo de relación 1:N (uno a muchos). - Escriben_en: Por último, identificamos la relación Escriben_en entre las entidades Críticos y Medios. Analizando los requisitos sabemos que un crítico solo puede 139 pertenecer a un medio (1,1) (aunque esto no sea así en la vida real), y que un determinado medio solo tiene contratado a un crítico (1,1) 5.3 Creación de la base de datos. Iniciamos el servidor MongoDB con el siguiente comando: sudo systemctl start mongod El primer paso es crear la base de datos en la que alojaremos las colecciones, documentos y relaciones resultantes del diagrama Entidad-Relación proporcionado. Se decide llamar a la base de datos TFG_Capítulo5. La creamos mediante el comando necesario. [3.5.1] test> use TFG switched to db TFG 5.4 Conversión de entidades. 5.4.1 Entidades fuertes. Aplicamos las reglas de transformación enunciadas en este trabajo y procedemos en primer lugar a transformar las entidades en las colecciones correspondientes aplicando un Json squema que vimos en el apartado [3.5.3] Tenemos un total de 6 entidades fuertes que se convertirán en 6 colecciones con idéntico nombre al de la entidad del diagrama original y una jerarquía ISA que consta de 3 entidades, cuya transformación abordaremos tras transformar las 6 anteriores. [5.2.2] Cada una de ellas serán implementadas con un Json squema, marcando todos los atributos como requeridos (required). Como vimos en el punto [3.5.2] de este trabajo, a la hora de poblar con instancias nuestra base de datos, si no se introduce alguno de los campos marcados como required a la hora de crear las colecciones nos devolverá un error, sin embargo, en el siguiente paso, a la hora de crear las relaciones existentes no tendremos problemas en añadir más campos clave valor. Para el conjunto de entidades Película [Figura 5.2] 140 Figura 5.2 Conjunto de entidades Películas Creamos la colección Películas con sus correspondientes campos, todos ellos Strings excepto Número_película y Duración, ambos Integer, el último con la condición añadida de que esté comprendido entre los valores 1 y 999: // Creación colección Películas db.createCollection("Películas", { validator: { $jsonSchema: { bsonType: "object", title: "Peliculas Object Validation", required: [ "Número_película", "Título_original","Título","Duración","País","Fecha_estreno","Resumen","Subtítulos"], properties: { Número_película: { bsonType: "int", description: "'Número_película' ha de ser un string y el campo es necesario" }, Título_original: { bsonType: "string", description: "'Título_original' ha de ser un string y el campo es necesario" }, Título: { bsonType: "string", description: "'Título' ha de ser un string y el campo es necesario" }, Duración: { bsonType: "int", minimum: 1, maximum: 999, description: "'Duración' ha de ser un integer dentro del intervalo [ 1, 999] y es necesario" }, País: { bsonType: "string", description: "'País' ha de ser un string y el campo es necesario" }, Fecha_estreno: { bsonType: "date", description: "'Fecha_estreno' ha de ser string y el campo es necesario" }, Resumen: { bsonType: "string", description: "'Resumen' ha de ser string y el campo es necesario" }, Subtítulos: {