Bases de datos nosql

1. Estructura de los Documentos

En las bases de datos documentales, la unidad de almacenamiento es un documento que se representa generalmente en JSON o BSON (Binary JSON en MongoDB).

📌 Ejemplo de documento JSON en una base de datos documental:

1{
2  "nombre": "Ana",
3  "edad": 25,
4  "email": "ana@email.com",
5  "direccion": {
6    "calle": "Av. Central",
7    "ciudad": "Madrid"
8  }
9}

👉 Un documento puede contener datos anidados, lo que permite organizar la información sin necesidad de varias tablas.

Diferencia con bases SQL

En SQL, tendríamos dos tablas para separar la dirección:

Tabla usuarios

idnombreedademail
1Ana25ana@email.com

Tabla direcciones

idusuario_idcalleciudad
11Av. CentralMadrid

En NoSQL documental, todo está dentro de un solo documento sin necesidad de joins.


2. Normalización vs. Desnormalización

En bases documentales, podemos optar por dos estrategias para organizar los datos:

📌 Normalización (Referencias)

  • Similar a las bases SQL
  • Separamos datos en documentos diferentes y usamos una referencia (ID)
  • Útil cuando los datos son repetitivos o cambian con frecuencia

📌 Ejemplo: Un pedido que referencia un usuario por su ID:

1{
2  "pedido_id": "123",
3  "usuario_id": "abc123",
4  "total": 50.99
5}

El usuario se almacena en otro documento separado:

1{
2  "id": "abc123",
3  "nombre": "Ana",
4  "email": "ana@email.com"
5}

🟢 Ventaja: Evita duplicación de datos
🔴 Desventaja: Se requieren múltiples consultas para obtener toda la información


📌 Desnormalización (Embedding)

  • Se almacena toda la información dentro del mismo documento
  • Útil cuando los datos no cambian mucho y se usan juntos con frecuencia

📌 Ejemplo: Un pedido con todos los datos del usuario embebidos:

1{
2  "pedido_id": "123",
3  "usuario": {
4    "nombre": "Ana",
5    "email": "ana@email.com"
6  },
7  "total": 50.99
8}

🟢 Ventaja: Consultas más rápidas (no se necesita buscar en varias colecciones)
🔴 Desventaja: Se pueden duplicar datos en varios documentos

👉 ¿Cuándo usar normalización y cuándo desnormalización?

  • Si los datos cambian con frecuencia → Usar referencias
  • Si los datos se consultan juntos siempre → Usar embedding

3. Relaciones en Bases Documentales

Aunque NoSQL documental no tiene joins como SQL, sí permite manejar relaciones entre documentos de dos maneras:

📌 1. Relación Uno a Muchos (Embedding)

Ejemplo: Un usuario con varias direcciones en el mismo documento.

1{
2  "nombre": "Carlos",
3  "email": "carlos@email.com",
4  "direcciones": [
5    {
6      "calle": "Calle Mayor",
7      "ciudad": "Barcelona"
8    },
9    {
10      "calle": "Gran Vía",
11      "ciudad": "Madrid"
12    }
13  ]
14}

📌 Ideal cuando las direcciones no se comparten con otros usuarios


📌 2. Relación Uno a Muchos (Referencias)

Ejemplo: Un usuario con direcciones separadas en otra colección.

Colección usuarios

1{
2  "id": "user123",
3  "nombre": "Carlos",
4  "email": "carlos@email.com"
5}

Colección direcciones

1{
2  "usuario_id": "user123",
3  "calle": "Calle Mayor",
4  "ciudad": "Barcelona"
5}

📌 Ideal cuando las direcciones pueden pertenecer a varios usuarios


4. Estrategias para Optimizar el Modelado

✔️ Usar documentos pequeños:

  • No almacenar información innecesaria dentro de un documento.

✔️ Elegir bien entre embedding y referencias:

  • Embedding para consultas rápidas.
  • Referencias para evitar datos repetidos.

✔️ Usar índices para mejorar la búsqueda:

  • Si buscamos frecuentemente por email, conviene crear un índice en él.