Las bases de datos no relacionales, comúnmente conocidas como NoSQL, han revolucionado la forma en que almacenamos e interactuamos con la información. A menudo, la percepción es que estas bases de datos no pueden manejar relaciones, pero eso no es del todo correcto. Si bien los sistemas tradicionales estructuran los datos en tablas, las bases de datos no relacionales como MongoDB organizan la información a través de documentos. Esto permite una flexibilidad única para representar relaciones dentro y entre documentos.
¿Cuáles son los tipos de relaciones en bases de datos?
Las bases de datos, ya sean relacionales o no, manejan tres tipos básicos de relaciones:
One to One (1:1): Una entidad está asociada a otra entidad única. Ejemplo clásico: un usuario y su credencial única.
One to Many (1:N): Una entidad está relacionada con muchas otras. Por ejemplo, un usuario puede poseer varios libros.
Many to Many (N:N): Varias entidades están relacionadas con múltiples entidades. Un claro ejemplo es un autor que ha escrito múltiples libros y un libro que puede tener varios autores.
¿Cómo se expresan estas relaciones en bases de datos documentales?
En bases de datos documentales como MongoDB, las relaciones se pueden expresar de dos maneras: embebidas o referenciadas.
¿Qué significa embeber documentos?
Embeber documentos implica incluir un subdocumento dentro de otro documento. Esto es útil cuando se desea simplificar el acceso y cuando las relaciones son intrínsecamente cercanas. Por ejemplo:
En este caso, el contacto del usuario está embebido dentro del documento del usuario, representando una relación uno a uno.
¿Cuándo es preferible utilizar la referencia?
Referenciar documentos significa mantener los documentos separados, utilizando un campo para conectar entre ellos. Es benéfico cuando los datos cambian con frecuencia o cuando se requiere acceder a los componentes individualmente. Un ejemplo básico sería tener documentos de usuario y contacto por separado, utilizándose un ID para referenciarlos:
// Documento de usuario{"id":"1","nombre":"Juan Pérez"}// Documento de contacto{"usuarioId":"1","email":"juan@example.com","telefono":"123456789"}
Aquí, la referencia a través de usuarioId en el documento de contacto conecta ambos documentos indicándonos que pertenecen al mismo usuario.
¿Cómo decidir entre embeber o referenciar?
Existen tres preguntas claves que deben guiar tu decisión:
Frecuencia de consulta: ¿Con qué frecuencia se consulta esa información? Si la respuesta es frecuentemente, es probable que sea beneficioso embebir los documentos.
Frecuencia de actualización: ¿Con qué frecuencia se actualiza la información? Un alto ritmo de cambio favorece el uso de referencias, ya que se evita reestructurar conjuntos de datos embebidos.
Consulta conjunta o separada: ¿La información se consulta en conjunto o de manera aislada? Si los datos se suelen necesitar conjuntamente, consideraría embebirlos; de lo contrario, referencia puede ser una mejor opción.
¿Cómo se representan estas relaciones visualmente?
Para las bases de datos documentales, la visualización de las relaciones es fundamental. En un diagrama entidad-relación, una entidad embebida podría representarse directamente dentro de otra. Por el contrario, los documentos referenciados se conectan a través de líneas indicando la relación.
Adoptar este enfoque flexible te permitirá optar por la mejor estrategia para cada tipo de relación considerando tus necesidades específicas. Las bases de datos documentales como MongoDB ofrecen esta dualidad de modos de relación, permitiendo elegir la opción más eficaz según el contexto y requerimientos de tus datos.
Explora este mundo lleno de posibilidades con entusiasmo. Estás en el camino correcto para dominar la tecnología y seguir ampliando tus horizontes en el mundo de las bases de datos. ¡Sigue aprendiendo!
Otro de los puntos a considerar para definir si embeber o referenciar es la performance de la consulta.
ejem: si tienes una entidad y tienen embebido un numero x de informacion al hacer la consulta a la base de datos, si tienes que consultar en una coleccion muy grande, es un delta de tiempo, luego otro delta asociado al manejo de la data que te regresa.
Mientras que si es referenciado, puedes traer por partes la informacion para ir construyendo sea lo que sea que necesiten las reglas del negocio.
Si bien esto entra dentro de las 3 preguntas que se hace para definir cual manera de modelado elegir, esta es una pregunta posterior a tu desicion.
Para realizar el modelamiento de datos manejamos 2 formas de realizarlo:
Embebida: Dentro de una coleccion registramos un documento que tenga otras subcoleciones.
Referenciada: Se realiza relacion con varios coleciones agregando un identificador unico.
Una de estas dos tecnicas de modelamiento se utilizara en base al uso que necesitemos. Pero una forma de poder abarcarlo es realizando algunas de estas preguntas:
Que tan frecuente es consultada la informacion
Que tan frecuente se actualiza la informacion
La informacion se consulta en conjunto o por partes ?
Embeber vs Referenciar
Embeber: Usar sub-documentos para realizar las relaciones, que esta un documento dentro de otro.
Mejora rendimiento en busqueda de muchos datos relacionados
Limitado a 1-1 y 1-N en una direccion
Cambios contenidos
Referenciar: Los documentos estan separados y se hacen referencia entre ellos con identificadores. En UML, se expresan con cajitas separadas y una cardinalidad.
Reduce el tamaño de la base de datos
No repetir datos
Actualizacion de datos unica para muchos
Permite 1-1, 1-N, N-1 y N-N
Preguntas para decidir cual
¿Que tan frecuente es consultada esa información?
¿Que tan frecuente se actualiza esa información?
¿La información se consulta en conjunto o por partes?
Que herramientas se puede utilizar para crear diagramas ER de MongoDb?
Podrías usar la extensión de VSCode de Draw io que trae muchas herramientas para hacer diagramas incluyendo de Bases de Datos basadas en documentos
Comparto estos apuntes (personales) que pueden ser de utilidad para comprender el tema de las relaciones en bd:
gracias por el aporte
¿En este caso, como se puede asegurar la integridad referencial?
¿Si yo tengo un documento A con una referencia a otro documento B, este otro documento B se puede eliminar sin tener en cuenta que ya está referenciado?
Este tema es muy importante, porque permite que integrar el modelo y hacerlo eficiente.
Algo Muy Importante que ayuda por asimilar esto <<Embeber vs Referenciar>> mediante un Diagrama ER y imaginar los documentos y subdocumentos , dejar de pensar en la forma tradicional de Bases de Datos Relacionales { SQL } para abrir un Nuevo paradigma de Db != SQl . si sigues pensando en SQl pierdes porque aqui ls colleciones funcionan de una forma diferente, si bien es cierto que existen muchas similituedes que son Analogias de Relaciones entre tablas SQl, Es mejor pensar en Documentos embebidos en ColLections de datos Mayores para hacder consultas a una entidad que tiene embebido documentos adentro tal como lo hemos hecho a lo largo del curso.
Embeber o referenciar
son las dos unicas dos formas de relacionar colecciones en mongodb
sub documentos = embeber
documentos separados = referencia
