Tema 5. Bases de datos no relacionales

Currículo: esta unidad cubre parte de los saberes básicos del Bloque B – Datos e Información (PRYC.2.B.2) correspondiente a 2º Bachillerato. Además, se evalúan los criterios que puedes encontrar al final de esta página.

Tabla de contenidos

• 1. El desafío de almacenar los datos
• 2. Big data: concepto y contexto
• 3. Volumen y variedad de los datos
• 4. Tipos de datos según su estructura
• 5. Introducción práctica a JSON
  • 5.1. Estructura básica de un archivo JSON
  • 5.2. Reglas fundamentales para escribir JSON correctamente
• 6. Introducción a las bases de datos NoSQL
• 7. Principales modelos de bases de datos NoSQL
• 8. Conceptos básicos en MongoDB
  • 8.1. Base de datos
  • 8.2. Colección
  • 8.3. Documento
• 9. Trabajando con MongoDB
  • 9.1. Crear la base de datos y la primera colección
  • 9.2. Insertar el primer documento
  • 9.3. Insertar un segundo documento con estructura distinta
  • 9.4. Tercer tipo de documento
  • 9.5. Consultas básicas
  • 9.6. Analizar la estructura de la colección
  • 9.7. Gestionar varias colecciones relacionadas

En la actualidad los datos son el elemento central de la mayoría de los sistemas digitales. Cada aplicación, plataforma o servicio que utilizamos a diario se apoya en la gestión de grandes cantidades de información, por lo que entender cómo se almacenan y se tratan los datos es fundamental para comprender cómo funciona el software moderno.

Las bases de datos no relacionales responden a estas nuevas necesidades, ofreciendo soluciones más flexibles y adaptadas a la realidad tecnológica actual. Su estudio nos permite acercarnos al funcionamiento real de las aplicaciones y ampliar nuestra visión sobre las herramientas que se utilizan en el desarrollo profesional de sistemas informáticos.

1. El desafío de almacenar los datos

Aunque muchas veces pase desapercibido, cuando abres Instagram o Spotify estás generando información. Cada like, cada comentario, cada canción que escuchas hasta el final o que saltas a los pocos segundos se convierte en un dato que la aplicación registra. Nuestro propósito en este tema es entender cómo se almacena y gestiona toda esa información para que el sistema funcione de manera eficiente.

Intentar almacenar toda esa información en tablas rígidas, con columnas fijas, como hemos estudiado en bases de datos relacionales, empieza a ser un problema cuando los datos cambian constantemente.

🚨 Estas bases de datos funcionan muy bien en contextos estables, como la gestión de notas de un instituto o un inventario sencillo, donde sabemos de antemano qué datos vamos a guardar y apenas cambian con el tiempo. Sin embargo, en aplicaciones modernas, donde cada semana se añaden nuevas funcionalidades, este modelo resulta poco flexible y muy difícil de escalar.

Por esta razón, la industria del software ha ido buscando alternativas más adaptadas a la realidad actual. Las bases de datos no relacionales nacen como respuesta a esta necesidad, permitiendo trabajar con información más diversa, cambiante y cercana a cómo realmente se generan los datos. 

2. Big data: concepto y contexto

Una vez que entendemos que vivimos rodeados de datos, el siguiente paso es poner nombre a una realidad que va mucho más allá de “mucha información”. El término big data aparece para describir situaciones en las que la cantidad de datos generados es tan grande y tan constante que ya no se pueden gestionar con herramientas tradicionales sin dificultades serias.

💡 Para que te hagas una idea más clara, piensa en WhatsApp durante un solo minuto a nivel mundial. En ese breve intervalo de tiempo se envían millones de mensajes, audios, imágenes y vídeos. A eso hay que añadir estados, reacciones, llamadas y registros internos del sistema. Todo eso son datos, y no se generan una vez al día, sino de forma continua, las veinticuatro horas. Aquí ya no hablamos solo de guardar información, sino de recogerla, almacenarla y poder utilizarla sin que el sistema colapse.

El big data no está reservado únicamente a grandes empresas tecnológicas. También aparece en ámbitos muy cercanos. Por ejemplo:

En una plataforma educativa se registran accesos, tiempos de conexión, entregas de tareas, resultados de cuestionarios y patrones de estudio. Analizar esos datos permite detectar dificultades de aprendizaje o mejorar la organización de los contenidos.	En el deporte profesional ocurre algo parecido: sensores, estadísticas de juego y análisis de rendimiento generan tal cantidad de información que es imposible tratarla como se hacía hace unos años.

Es importante que se entienda que el big data no se define solo por el tamaño de los datos, sino por el cambio de escala. Pasamos de gestionar bases de datos “manejables” a trabajar con cantidades enormes de información que crecen sin parar y que proceden de fuentes muy distintas. En este contexto, las soluciones clásicas empiezan a mostrar límites claros, especialmente cuando los datos no siguen un formato único.

3. Volumen y variedad de los datos

Cuando hablamos de big data, hay dos ideas que aparecen de forma constante y que conviene entender bien desde el principio: el volumen y la variedad de los datos. Estas dos características explican por qué los sistemas actuales necesitan nuevas formas de almacenamiento de la información.

Por un lado, el volumen hace referencia a la enorme cantidad de datos que se generan. No se trata solo de que haya “muchos datos”, sino de que crecen de forma continua.

Cada segundo se crean nuevos perfiles, se suben vídeos, se registran ubicaciones, se guardan historiales de búsqueda o se almacenan partidas de videojuegos online.

Gestionar esa cantidad de información exige sistemas capaces de crecer sin necesidad de rehacer toda su estructura cada vez que el número de usuarios aumenta.

Por otro lado, está la variedad. No todos los datos son iguales ni tienen el mismo formato. En una misma aplicación podemos encontrar textos, números, imágenes, vídeos, audios, fechas, listas de elementos o incluso combinaciones de todo lo anterior.

Piensa en una red social: un usuario puede subir solo texto, otro añade imágenes, otro vídeos, otro incluye ubicación, etiquetas o enlaces.

Intentar que todos esos datos encajen exactamente en las mismas columnas de una tabla es forzar un modelo que no se adapta bien a la realidad.

4. Tipos de datos según su estructura

Antes de seguir avanzando, es importante que nos detengamos a reflexionar sobre qué tipo de datos manejan realmente las aplicaciones actuales. No toda la información se presenta de la misma forma ni se comporta igual, y esta diferencia es clave para entender por qué unas bases de datos funcionan mejor que otras según el contexto.

En primer lugar, hablamos de datos estructurados, que son los más sencillos de gestionar desde el punto de vista tradicional. Son datos que siguen una estructura fija, perfectamente definida, donde cada elemento ocupa siempre el mismo lugar. Un ejemplo muy cercano es una tabla de calificaciones del instituto: nombre del alumno, asignatura, nota y evaluación.

Todas las filas tienen las mismas columnas y sabemos exactamente qué tipo de dato va en cada una. Este tipo de información encaja muy bien en bases de datos relacionales.

Sin embargo, la realidad digital va mucho más allá. Aparecen los datos semiestructurados, que no siguen un esquema rígido, pero sí mantienen cierto orden interno. Un ejemplo muy habitual es un archivo JSON, como los que se usan en muchas aplicaciones web y móviles. Piensa en un perfil de usuario: algunos tienen foto, otros no; algunos añaden biografía, otros enlaces, otros solo un nombre. La información está organizada, pero no todos los registros tienen exactamente los mismos campos.

Por último, encontramos los datos no estructurados, que son los más abundantes hoy en día. Aquí entran imágenes, vídeos, audios, textos libres, mensajes de voz o publicaciones en redes sociales. Un comentario en TikTok, un audio de WhatsApp o un vídeo de YouTube no se pueden dividir fácilmente en columnas sin perder información o sentido. Aun así, estos datos son extremadamente valiosos y se utilizan para recomendaciones, análisis de comportamiento o personalización de contenidos.

El problema aparece cuando intentamos tratar todos estos tipos de datos como si fueran iguales. Las bases de datos relacionales están pensadas principalmente para datos estructurados, y cuando se enfrentan a información semiestructurada o no estructurada, empiezan a mostrar claras limitaciones. Adaptar tablas para cubrir todos los posibles casos supone complejidad, rigidez y una gran cantidad de campos que muchas veces quedan vacíos.

5. Introducción práctica a JSON

En el apartado anterior hemos mencionado por primera vez JSON, pero ahora vamos a profundizar en él. JSON no es una base de datos ni un lenguaje de programación, sino un formato de intercambio de datos.

🫵 ¿Qué otros formatos de intercambio de datos conoces?

Su nombre proviene de JavaScript Object Notation, y su éxito se debe a que es muy sencillo de leer tanto por personas como por programas.

Uno de los motivos por los que MongoDB -la base de datos no relacional que vamos a estudiar- resulta tan intuitivo es precisamente porque almacena la información en documentos con estructura tipo JSON.

Por ejemplo, cuando una aplicación del tiempo te muestra la previsión meteorológica, lo más probable es que el servidor haya enviado un archivo JSON con datos como temperatura, humedad o velocidad del viento, parecido a este:

{
  "temperatura": "27ºC",
  "humedad": 20,
  "viento": 80.45,
  "alerta": false
}

Aquí vemos varios elementos importantes:

• Los datos se organizan en pares clave–valor.
• Las claves van siempre entre comillas dobles.
• Los valores pueden ser texto, números o valores booleanos.
• Todo el contenido está encerrado entre llaves {}.

5.1. Estructura básica de un archivo JSON

Un archivo JSON está formado por:

• Objetos, delimitados por llaves {}.
• Arrays (listas), delimitados por corchetes [].
• Pares clave–valor, separados por dos puntos :.
• Elementos separados por comas.

Veamos un ejemplo más completo:

{
  "nombre": "Álvaro",
  "edad": 18,
  "asignaturas": ["Programación", "Matemáticas", "Física"],
  "activo": true
}

Aquí aparece algo nuevo: un array. El campo “asignaturas” contiene una lista de valores entre corchetes.

Supongamos ahora que queremos representar la información de un jugador de un videojuego online:

{
  "usuario": "DarkCoder",
  "nivel": 27,
  "puntos": 15400,
  "logros": ["Primer torneo", "100 partidas jugadas"],
  "equipo": {
    "arma": "Espada láser",
    "escudo": "Escudo de energía",
    "mascota": "Dragón azul"
  }
}

Aquí podemos observar algo muy importante:

• Dentro de un objeto puede haber otro objeto.
• JSON permite estructuras anidadas.
• No todos los jugadores tendrían por qué tener exactamente los mismos campos.

Esta flexibilidad es clave para entender por qué JSON encaja tan bien con las bases de datos documentales.

5.2. Reglas fundamentales para escribir JSON correctamente

Para que un archivo JSON sea válido, debemos respetar ciertas normas estrictas:

1. Las claves siempre deben ir entre comillas dobles.
2. No puede haber coma después del último elemento.
3. Los valores de texto también deben ir entre comillas dobles.
4. Solo se permiten estos tipos de datos: texto (string), número, booleano (true o false), null, objeto, array.

Por ejemplo, esto sería incorrecto:

{
  nombre: "Ana",
  edad: 17,
}

Faltan comillas en la clave y sobra una coma final.

La versión correcta sería:

{
  "nombre": "Ana",
  "edad": 17
}

{
  "usuario": "NeoPlayer",
  "edad": 18,
  "pais": "España",
  "nivel": 12,
  "puntosTotales": 8450,
  "logros": [
    "Primera victoria",
    "100 enemigos derrotados",
    "Nivel 10 alcanzado"
  ],
  "configuracion": {
    "perfilPublico": true,
    "notificacionesActivadas": true
  },
  "ultimasPartidas": [
    {
      "fecha": "2026-02-10",
      "puntuacion": 1200,
      "duracionMinutos": 35
    },
    {
      "fecha": "2026-02-14",
      "puntuacion": 980,
      "duracionMinutos": 28
    }
  ]
}

Cuando estás trabajando con JSON puede que necesites realizar algunas comprobaciones o transformaciones como:

• Validarlo: para ver si está bien formado.
• Repararlo: para corregir de forma automática errores comunes.
• Minify: reduce todos los espacios y condensa todo el archivo en una sola línea (pesa menos el archivo pero se vuelve ilegible).
• Beautify: el contrario del anterior (se lee muy bien, pero pesa más).

Todas estas operaciones podemos realizarlas con multitud de herramientas online disponibles de manera gratuita. Yo te recomiendo JSONLint.

Si además, sueles trabajar con Visual Studio Code, te recomiendo que instales esta extensión:

6. Introducción a las bases de datos NoSQL

Una vez comprendidas las limitaciones que pueden aparecer al usar bases de datos tradicionales en ciertos contextos, es el momento de presentar la alternativa que da sentido a todo este tema: las bases de datos NoSQL. El término NoSQL no significa “sin SQL” en un sentido estricto, sino “not only SQL“, es decir, no solo SQL. Esto ya nos da una pista importante: no vienen a sustituir por completo a las bases de datos relacionales, sino a complementarlas allí donde estas no se adaptan bien.

Para que lo entiendas mejor, piensa en una aplicación de mensajería. Un mensaje puede ser solo texto, pero también puede incluir imágenes, audios, vídeos, emojis, respuestas o reacciones. Intentar que todos los mensajes tengan exactamente los mismos campos resulta inoperativo. En un modelo NoSQL, cada mensaje puede almacenar únicamente la información que necesita, sin rellenar campos innecesarios ni modificar estructuras globales.

Desde el punto de vista de la programación, esto supone una gran ventaja. El desarrollador puede evolucionar la aplicación de forma más rápida, añadiendo nuevas características sin tener que rediseñar por completo la base de datos.

En este punto es importante quedarse con una idea clara: las bases de datos NoSQL no son “mejores” en todos los casos, pero sí son más adecuadas para muchos de los problemas actuales de la computación.

7. Principales modelos de bases de datos NoSQL

Al igual que no todos los problemas informáticos son iguales, tampoco todas las bases de datos NoSQL funcionan del mismo modo. Cada modelo responde a una necesidad concreta del mundo real:

• Bases de datos documentales: muy similares a los objetos que ya conocéis de la programación. Este modelo resulta especialmente intuitivo porque permite agrupar en una sola estructura toda la información relacionada con un elemento. Por ejemplo, un usuario puede tener su nombre, su correo, sus preferencias y su historial en un único documento, sin necesidad de repartir esa información en varias tablas. Esto encaja muy bien con aplicaciones web, móviles y las plataformas digitales actuales. Sistema gestor de bases de datos de este tipo más popular: MongoDB↗.

• Bases de datos tipo clave–valor: a cada clave se le asocia un valor. Es un sistema extremadamente rápido y eficiente para ciertos usos concretos, como guardar sesiones de usuarios, configuraciones temporales o datos que deben recuperarse casi al instante. Aunque es sencillo, tiene un papel fundamental en muchas aplicaciones reales. Sistema gestor de bases de datos de este tipo más popular: Redis↗.

• Bases de datos orientadas a columnas: diseñadas para trabajar con enormes volúmenes de información donde no todos los registros tienen los mismos campos. Este modelo se utiliza mucho en sistemas de análisis masivo de datos, donde prima la eficiencia y el rendimiento frente a la estructura tradicional. Sistema gestor de bases de datos de este tipo más popular: Apache Cassandra↗.

• Bases de datos orientadas a grafos: especialmente útiles cuando lo más importante no son los datos en sí, sino las relaciones entre ellos. Redes sociales, recomendaciones de amigos, rutas o conexiones entre personas son ejemplos claros donde este modelo resulta muy potente. Sistema gestor de bases de datos de este tipo más popular: Neo4j↗.

Lo importante no es que memorices cada modelo en profundidad, sino comprender que cada tipo de base de datos NoSQL responde a un problema distinto muy concreto.

A partir de aquí, nos centraremos en uno de los modelos más utilizados y más accesibles para empezar: el modelo documental, con MongoDB como referencia.

8. Conceptos básicos en MongoDB

Nuestra base de datos no relacional de tipo documental, MongoDB, consta de tres piezas fundamentales: base de datos, colección y documento.

Si vienes del mundo relacional, es útil establecer un paralelismo inicial: en una base de datos tradicional tenemos base de datos → tablas → filas. En MongoDB tenemos base de datos → colecciones → documentos. La idea general es parecida, pero el funcionamiento interno es diferente y mucho más flexible.

8.1. Base de datos

Una base de datos en MongoDB es el contenedor principal de la información. Dentro de ella se almacenan varias colecciones.

Podemos imaginar una base de datos como el «espacio donde vive» toda la información de una aplicación concreta. Por ejemplo:

• Una aplicación de gestión de un instituto podría tener una base de datos llamada instituto.
• Una red social podría tener una base de datos llamada red_social.
• Una app de vídeos podría tener una base de datos llamada streamingApp.

Cada aplicación suele trabajar con su propia base de datos, lo que permite organizar y aislar la información.

8.2. Colección

Dentro de una base de datos encontramos colecciones.

Una colección agrupa documentos del mismo tipo o relacionados con una misma entidad.

Si seguimos con el ejemplo de una aplicación tipo Instagram, dentro de una base de datos podríamos tener:

• usuarios
• publicaciones
• comentarios
• mensajes

La diferencia importante respecto a una tabla relacional es que una colección no obliga a que todos sus documentos tengan exactamente la misma estructura. Pueden compartir muchos campos, pero no es obligatorio que sean idénticos.

8.3. Documento

El elemento más importante en MongoDB es el documento.

Un documento es la unidad básica de almacenamiento y está representado mediante una estructura tipo JSON. Es decir, está compuesto por pares clave–valor.

Por ejemplo, un documento dentro de la colección usuarios podría ser:

{
  "nombre": "Lucía",
  "edad": 17,
  "curso": "2º Bachillerato",
  "intereses": ["programacion", "videojuegos"]
}

Ese conjunto completo es un único documento.

Lo interesante es que otro documento de la misma colección podría tener campos adicionales:

{
  "nombre": "Carlos",
  "edad": 18,
  "curso": "2º Bachillerato",
  "intereses": ["musica", "deporte"],
  "cuentaVerificada": true
}

Y MongoDB no tendría ningún problema con ello.

Algo que debe de quedar claro para no confundirse, especialmente viniendo del estudio reciente de bases de datos relacionales, es que en una base de datos relacional, la estructura se define antes de insertar datos. En MongoDB, el documento define su propia estructura en el momento de almacenarse.

9. Trabajando con MongoDB

Antes de empezar a trabajar con documentos reales y comandos propios de MongoDB, necesitamos tener el sistema instalado y funcionando en nuestro equipo:

Ahora que tenemos un entorno de trabajo funcional, vamos a realizar un recorrido por los usos más comunes de este tipo de base de datos, apoyándonos en un proyecto tipo Netflix.

9.1. Crear la base de datos y la primera colección

En MongoDB una base de datos se materializa cuando creas una colección y guardas datos.

En Compass lo haremos de la siguiente manera.

Nos situamos en la pantalla principal y junto al nombre de nuestra conexión pulsamos sobre +:

Como nombre de la base de datos escribimos netflix y como nombre de la colección escribimos titulos. Cerramos pulsando en Create Database.

9.2. Insertar el primer documento

Siguiendo nuestro ejemplo, el primer documento representará una “serie” con datos anidados.

Entra en netflix → titulos y abre la pestaña Documents. Pulsa en + ADD DATA → Insert Document.

Pega un documento como este:

{
  "tipo": "serie",
  "titulo": "Stranger Things",
  "anioEstreno": 2016,
  "generos": ["ciencia ficcion", "misterio"],
  "clasificacionEdad": "16+",
  "disponible": true,
  "temporadas": [
    {
      "numero": 1,
      "episodios": 8,
      "duracionMediaMin": 50
    },
    {
      "numero": 2,
      "episodios": 9,
      "duracionMediaMin": 50
    }
  ],
  "reparto": [
    { "nombre": "Millie Bobby Brown", "rol": "Eleven" },
    { "nombre": "David Harbour", "rol": "Hopper" },
    { "nombre": "Finn Wolfhard", "rol": "Mike Wheeler" },
    { "nombre": "Caleb McLaughlin", "rol": "Lucas Sinclair" },
    { "nombre": "Gaten Matarazzo", "rol": "Dustin Henderson" },
    { "nombre": "Noah Schnapp", "rol": "Will Byers" },
    { "nombre": "Joe Keery", "rol": "Steve Harrington" }
  ],
  "rating": {
    "media": 8.7,
    "votos": 1200000
  }
}

Guarda (Insert). Compass añadirá automáticamente _id si no lo pones tú.

Lo importante aquí es que compruebes que un título no es “una fila con columnas fijas” de una tabla, sino un objeto que puede tener listas y objetos dentro.

9.3. Insertar un segundo documento con estructura distinta

Ahora vamos a aprovechar la gracia de NoSQL: que no todos los documentos tienen que ser idénticos.

Insertemos otro documento, pero esta vez una “película”:

{
  "tipo": "pelicula",
  "titulo": "Puñales por la espalda",
  "anioEstreno": 2019,
  "generos": ["thriller", "misterio"],
  "duracionMin": 130,
  "clasificacionEdad": "12+",
  "disponible": true,
  "rating": {
    "media": 7.9,
    "votos": 750000
  },
  "idiomasAudio": ["es", "en"],
  "subtitulos": ["es", "en", "fr"]
}

Fíjate en la idea que quiero que os quede: en la misma colección titulos, un documento de serie tiene temporadas, pero una película tiene duracionMin. Eso, en un modelo relacional rígido nos obligaría a inventar soluciones poco eficientes.

9.4. Tercer tipo de documento

Aunque no lo vayamos a usar inmediatamente, vamos a terminar de añadir nuestros tipos de documentos insertando un nuevo documento en la colección titulos, pero con una estructura ligeramente distinta, en este caso para un “documental”.

Entra en netflix → titulos y abre la pestaña Documents. Pulsa en + ADD DATA → Insert Document.

Pega un documento como este:

{
  "tipo": "documental",
  "titulo": "Nuestro planeta",
  "anioEstreno": 2019,
  "generos": ["naturaleza", "educacion"],
  "clasificacionEdad": "7+",
  "disponible": true,
  "temporadas": [
    {
      "numero": 1,
      "episodios": 8,
      "duracionMediaMin": 50
    }
  ],
  "narrador": "David Attenborough",
  "rating": {
    "media": 9.3,
    "votos": 300000
  }
}

Guarda (Insert). Compass añadirá automáticamente _id si no lo pones tú.

9.5. Consultas básicas

Ahora que ya hay datos, el objetivo es que no se queden en “he pegado un JSON“. Hay que buscar y filtrar.

En la pestaña Documents tienes una barra de filtro. Prueba estas consultas (tal cual) y tras cada una de ellas pulsa en el botón Find:

• Títulos de tipo serie: { tipo: "serie" }
• Títulos a partir de 2018: { anioEstreno: { $gte: 2018 } }
• Títulos con género misterio: { generos: "misterio" }

Aquí ya aparecen operadores de MongoDB como $gte, que es lenguaje propio de consulta. Esto es MongoDB “de verdad”, solo que con interfaz.

Además, si no encuentras la sintaxis para una consulta determinada, siempre puedes usar la IA integrada, escribir qué necesitas y que la IA te sugiera la consulta:

Usa la IA como una ayuda, NUNCA como tu opción prioritaria ya que en muchas ocasiones introduce errores que no sabrás identificar si no dominas la sintaxis.

9.6. Analizar la estructura de la colección

Ahora viene una herramienta realmente potente para nuestros datos.

En la colección titulos, cambia a la pestaña Schema.

Pulsa Analyze Schema (si lo solicita). Compass analizará los documentos existentes y generará un resumen estadístico de los campos.

Lo que verás:

• Lista de campos detectados (tipo, titulo, anioEstreno, temporadas, duracionMin, narrador, etc.).
• Tipo de dato detectado para cada campo (String, Number, Array, Object, Boolean).
• Porcentaje de documentos que contienen cada campo.

Este punto es clave para que terminemos de entender cómo funcionan las bases de datos no relacionales:

MongoDB no impone el esquema, pero puede inferirlo a partir de los datos reales.

Por ejemplo:

• temporadas aparecerá en series y documentales.
• duracionMin solo aparecerá en películas.
• narrador solo en documentales.
• reparto solo en series.

Y eso se ve visualmente, sin necesidad de teoría abstracta.

9.7. Gestionar varias colecciones relacionadas

Hasta ahora teníamos la base de datos netflix y la colección titulos.

Vamos a añadir dos colecciones nuevas: usuarios y valoraciones.

El objetivo será modelar una situación real bastante común como:

• Un título puede tener muchas valoraciones.
• Un usuario puede ver muchos títulos.
• Un usuario puede valorar muchos títulos.

En Compass:

netflix → Create Collection → nombre: usuarios

Insertamos algunos documentos:

{
  "nombre": "Laura",
  "email": "laura@email.com",
  "pais": "España",
  "tipoCuenta": "premium",
  "anioRegistro": 2022
}

{
  "nombre": "Daniel",
  "email": "daniel@email.com",
  "pais": "Portugal",
  "tipoCuenta": "basica",
  "anioRegistro": 2024
}

Guarda y observa los _id generados automáticamente.
Esos identificadores serán fundamentales.

Ahora creamos otra colección:

netflix → Create Collection → nombre: valoraciones

Aquí es donde empieza lo interesante: vamos a crear documentos que relacionen usuarios con títulos.

Unos documentos de valoraciones podrían ser:

{
  "usuarioId": ObjectId("ID_DEL_USUARIO_LAURA"),
  "tituloId": ObjectId("ID_DEL_TITULO_STRANGER_THINGS"),
  "puntuacion": 9,
  "comentario": "Muy recomendable",
  "fecha": 2026
}

Aquí estamos usando referencias cruzadas:

• usuarioId apunta a un documento en la colección usuarios.
• tituloId apunta a un documento en la colección titulos.

Esto es el equivalente conceptual a una clave foránea en bases de datos relacionales, pero en MongoDB no se impone automáticamente. Somos nosotros quienes diseñamos esa relación.

Tenemos ahora tres colecciones: titulos, usuarios y valoraciones.

De esta manera hemos modelado situaciones reales como:

• Un usuario puede tener muchas valoraciones.
• Un título puede recibir muchas valoraciones.
• Cada documento en valoraciones conecta un usuario con un título.

Este patrón se llama modelo con referencias.

Ahora podemos hacer consultas más útiles aprovechando que tenemos relaciones.

Por ejemplo:

Buscar todas las valoraciones de un usuario concreto.

En valoraciones, filtro:

{ usuarioId: ObjectId("ID_USUARIO_LAURA") }

Buscar todas las valoraciones de un título concreto.

En valoraciones, filtro:

{ tituloId: ObjectId("ID_STRANGER_THINGS") }

Al finalizar este tema, es importante que tomes conciencia de que las bases de datos no relacionales no son simplemente “otra tecnología más”, sino una respuesta coherente a la evolución del mundo digital. Hemos pasado de trabajar con datos perfectamente ordenados en tablas rígidas a enfrentarnos a información masiva, diversa y cambiante, generada constantemente por aplicaciones que utilizamos a diario. Saber elegir, modelar con criterio y justificar nuestras decisiones técnicas es, en definitiva, lo que marca la diferencia entre programar y comprender realmente la computación.