En la lección anterior llegamos a una conclusión clara: BiblioRed necesita una base de datos. Pero "base de datos" no designa una sola cosa. Hay familias muy distintas entre sí, cada una con una forma propia de estructurar la información, nacida para resolver un problema concreto. Elegir mal en esta fase se paga caro: significa forzar durante años una herramienta a hacer algo para lo que no fue pensada.

Esta lección es un panorama: un mapa del territorio. No entraremos en el detalle de ninguna familia —eso corresponde al módulo 2 para las relacionales y al módulo 3 para NoSQL—, sino que buscamos que sepas qué existe, qué forma tiene cada opción y con qué criterios se elige. Al final aplicaremos esos criterios a BiblioRed y decidiremos, con argumentos, qué tecnología usaremos en cada parte del sistema.

1. Cómo se clasifican las bases de datos
2. Bases de datos relacionales (RDBMS)
3. Panorama NoSQL: las cuatro familias
4. Modelos históricos: jerárquico y en red
5. Otros modelos especializados
6. OLTP frente a OLAP
7. Tabla comparativa general
8. Un ejemplo de código por familia
9. Cómo elegir: criterios de decisión
10. Decisión aplicada a BiblioRed
11. Errores comunes y consejos
12. Ejercicios
13. Conclusión

Las bases de datos se pueden clasificar por varios ejes, y conviene no mezclarlos:

• Por modelo de datos: cómo se estructura la información. Es el eje principal (relacional, documental, clave-valor, columnar, grafo, jerárquico, en red, objetos).
• Por carga de trabajo: para qué se usa (OLTP, operaciones del día a día, frente a OLAP, análisis).
• Por arquitectura de despliegue: cliente-servidor frente a embebida; en un solo nodo frente a distribuida; autogestionada frente a servicio gestionado en la nube.
• Por ubicación del dato: en disco frente a en memoria.

Una misma base de datos ocupa una posición en cada eje. PostgreSQL es relacional, OLTP, cliente-servidor y en disco. SQLite es relacional, OLTP, embebida y en disco. Redis es clave-valor, en memoria y cliente-servidor. No son categorías excluyentes.

En esta lección recorreremos sobre todo el eje del modelo de datos, y cerraremos con OLTP/OLAP porque es la distinción que más decisiones de arquitectura provoca.

Son la familia dominante desde los años ochenta y el eje del curso.

Cómo estructuran los datos: en tablas formadas por filas y columnas. Cada tabla representa una entidad, cada fila una ocurrencia, y las tablas se conectan mediante claves (una columna de una tabla que apunta al identificador de otra). El esquema se define por adelantado: antes de guardar nada, se declara qué columnas hay y de qué tipo.

Qué garantizan: integridad estricta (el gestor rechaza los datos que violan las reglas), transacciones ACID (o todo o nada, incluso ante fallos) y un lenguaje de consulta estándar y potentísimo, SQL.

Para qué son buenas: cualquier dominio donde los datos tengan una estructura estable y bien conocida, donde las relaciones importen y donde la corrección no sea negociable. Banca, facturación, gestión de inventario, ERP, reservas... y bibliotecas.

Cuándo cuestan: cuando el esquema cambia constantemente, cuando el volumen exige repartirse entre cientos de máquinas, o cuando la forma natural del dato es muy jerárquica y anidada.

Productos representativos: PostgreSQL, MySQL/MariaDB, SQLite, Oracle Database, Microsoft SQL Server, IBM Db2.

En este curso, PostgreSQL será la referencia principal y SQLite la alternativa ligera para practicar. El modelo relacional formal y SQL son el contenido completo del módulo 2.

"NoSQL" es un nombre desafortunado —se entiende mejor como Not Only SQL— que agrupa sistemas surgidos a partir de 2007 con un rasgo común: renuncian a alguna garantía o rigidez del modelo relacional a cambio de flexibilidad de esquema o de capacidad de distribución. No son un modelo, sino cuatro familias muy distintas entre sí.

Aquí solo veremos qué son y para qué sirven. El detalle de cada familia, sus estructuras internas y sus operaciones son la lección 03-02, y cómo se modelan los datos en ellas, la 03-03.

Guardan documentos autocontenidos, típicamente en JSON o BSON, agrupados en colecciones. Cada documento puede tener campos distintos de sus vecinos, y puede contener estructuras anidadas (listas, objetos dentro de objetos).

• Sirven para: datos con estructura variable o jerárquica que se leen casi siempre completos: catálogos de producto, perfiles, contenidos editoriales, reseñas.
• Productos: MongoDB (nuestro ejemplo en el módulo 3), CouchDB, Amazon DocumentDB. PostgreSQL también almacena JSON con su tipo jsonb.

El modelo más simple posible: un diccionario gigante. Una clave única apunta a un valor, y el sistema apenas sabe nada de la estructura de ese valor.

• Sirven para: acceso extremadamente rápido por clave conocida. Cachés, sesiones de usuario, contadores, colas, límites de peticiones.
• Productos: Redis, Memcached, Amazon DynamoDB (en su uso más simple), etcd.

Organizan los datos por columnas en lugar de por filas, y se diseñan para repartirse entre muchos nodos. Permiten escrituras masivas y lecturas de rangos enormes.

• Sirven para: series de eventos de gran volumen, telemetría, historiales que crecen sin parar y se consultan por rangos.
• Productos: Apache Cassandra, HBase, ScyllaDB. (Ojo: el término "columnar" también se usa para almacenes analíticos como ClickHouse; el parentesco es real pero el propósito difiere.)

Modelan explícitamente nodos y relaciones entre ellos, y ambas cosas pueden tener propiedades. Recorrer relaciones es la operación barata.

• Sirven para: redes sociales, recomendaciones, detección de fraude, grafos de conocimiento, análisis de rutas. Todo aquello donde la pregunta interesante es "¿cómo se conecta A con B?".
• Productos: Neo4j, Amazon Neptune, ArangoDB.

Estos dos modelos precedieron al relacional y hoy prácticamente no se usan en proyectos nuevos, pero siguen vivos en sistemas heredados de banca, seguros y administración pública. El curso no volverá a tratarlos, así que conviene saber qué son.

Modelo jerárquico (años 60). Organiza los datos en una estructura de árbol: cada registro tiene un único padre y puede tener varios hijos. El acceso se hace navegando desde la raíz.

• Ventaja: muy rápido para consultas que siguen la jerarquía.
• Límite: un hijo no puede tener dos padres, así que las relaciones "muchos a muchos" obligan a duplicar datos. En BiblioRed, un libro escrito por dos autores ya rompe el modelo.
• Producto emblemático: IBM IMS.

Modelo en red (CODASYL, años 70). Generaliza el jerárquico permitiendo que un registro tenga varios padres, mediante punteros explícitos.

• Ventaja: representa muchos-a-muchos sin duplicar.
• Límite: el programador debe navegar manualmente por los punteros. Cambiar la estructura obliga a reescribir los programas.
• Producto emblemático: IDMS.

El problema común a ambos: no hay independencia de datos. La forma de acceder está soldada a la forma de almacenar. Esa es exactamente la carencia que atacó el modelo relacional, como veremos en la lección 01-03.

Familias que existen, que puedes encontrarte en la práctica y que este curso no vuelve a tratar.

Almacenan objetos tal como existen en un lenguaje de programación, con herencia y métodos incluidos, evitando la traducción entre objetos y tablas. Prometían mucho en los noventa y tuvieron adopción limitada: el ecosistema relacional era demasiado sólido y aparecieron los ORM, que resolvían el problema de forma menos radical. Productos: db4o, ObjectDB. PostgreSQL conserva rasgos objeto-relacionales (tipos definidos por el usuario, herencia de tablas).

No son un modelo, sino una arquitectura: el motor es una biblioteca que se enlaza dentro de la aplicación, sin proceso servidor ni red. La base de datos es un fichero local.

• Sirven para: aplicaciones de escritorio y móviles, dispositivos, formatos de fichero de aplicación, pruebas automatizadas y aprendizaje.
• Productos: SQLite (el más desplegado del mundo: está en cada móvil y cada navegador), DuckDB, LevelDB.

Usaremos SQLite en el curso precisamente por esto: permite practicar SQL real sin instalar ni administrar un servidor.

Mantienen todo el conjunto de datos en RAM, con persistencia en disco opcional. Ganan uno o dos órdenes de magnitud en latencia a cambio de estar limitadas por la memoria disponible y de asumir riesgo de pérdida si no persisten.

• Sirven para: cachés, rankings en tiempo real, sesiones, colas de trabajo.
• Productos: Redis, Memcached, SAP HANA (analítica en memoria).

Especializadas en datos indexados por tiempo que llegan de forma continua y casi nunca se modifican. Optimizan la compresión, la escritura secuencial y las consultas por ventana temporal, y suelen incorporar agregaciones y políticas de retención integradas.

• Sirven para: métricas de sistemas, sensores IoT, cotizaciones, consumo energético.
• Productos: InfluxDB, TimescaleDB (extensión de PostgreSQL), Prometheus.

Las más recientes. Almacenan vectores de alta dimensión (embeddings) que representan el significado de textos, imágenes o audio, y su operación característica es la búsqueda por similitud: dado un vector, encontrar los más parecidos. No buscan coincidencias exactas, sino proximidad semántica.

• Sirven para: búsqueda semántica, recomendación por contenido, sistemas que recuperan documentos relevantes para alimentar a un modelo de lenguaje.
• Productos: Pinecone, Milvus, Qdrant, Weaviate, y la extensión pgvector de PostgreSQL.

Su irrupción, muy reciente, la situaremos históricamente en la lección 01-03.

Esta distinción no va de modelo de datos sino de carga de trabajo, y explica por qué muchas organizaciones tienen dos bases de datos con los mismos datos.

• OLTP (Online Transaction Processing): el sistema operativo del día a día. Muchísimas operaciones pequeñas y concurrentes: registrar un préstamo, dar de alta un socio, actualizar un estado. Prioriza la latencia baja por operación y la integridad transaccional. Se diseña normalizado (módulo 5).
• OLAP (Online Analytical Processing) y data warehouse: el sistema de análisis. Pocas consultas, pero enormes: agregar millones de filas por dimensiones. Prioriza el rendimiento de lectura masiva. Se diseña desnormalizado (lección 05-04), a menudo con almacenamiento columnar.

BiblioRed empezará solo con OLTP. Si dentro de unos años dirección quiere cuadros de mando sobre una década de historial, se planteará copiar periódicamente los datos a un almacén analítico. Es una evolución normal, no un fracaso del diseño inicial.

El objetivo de este apartado es puramente visual: que veas la diferencia de forma entre los modelos. No hace falta entender la sintaxis todavía; cada una se explica en su módulo.

Los datos del préstamo están repartidos en tablas y se recomponen al consultar:

Lo relevante para esta lección: el dato del socio vive en socios, el del libro en libros, y la consulta los junta bajo demanda. Cada hecho está escrito una sola vez. La sintaxis completa de SELECT y JOIN llega en las lecciones 02-03 y 02-04.

La misma información, pero autocontenida en un documento:

Diferencias de forma que ya puedes apreciar:

• No hay tablas ni columnas: hay campos, y pueden anidarse (libro.titulo).
• etiquetas es una lista dentro del propio documento. En el modelo relacional eso exigiría una tabla aparte.
• Otro documento de la misma colección podría tener campos distintos (por ejemplo, uno con spoiler: true) sin que nadie se queje. Eso es el esquema flexible.
• El precio de esa comodidad es que el título del libro se repite en cada reseña. Cuándo compensa pagarlo es justo lo que se estudia en la lección 03-03.

Aquí no hay consultas: hay acceso directo por clave. No se puede preguntar "dame todas las sesiones de la sucursal norte" sin recorrerlo todo, porque el sistema no sabe qué hay dentro del valor. A cambio, cada operación tarda microsegundos.

Lo característico: las flechas son parte de la consulta. -[:LEYO]-> es una relación explícita almacenada, no una unión calculada. Preguntas de tipo "quién se conecta con quién a través de qué" se expresan de forma directa; en SQL exigirían varios JOIN encadenados y se complican mucho cuando la profundidad es variable.

Esta es la parte que de verdad importa en un proyecto. Los criterios, en orden de peso práctico:

1. ¿Qué forma tienen los datos? ¿Estructura estable y bien conocida, o variable de un registro a otro? ¿Plana o profundamente anidada?
2. ¿Qué preguntas vas a hacer? Este criterio decide más que el anterior. Si las consultas cruzan cinco entidades y agregan, quieres relacional. Si siempre lees un objeto entero por su identificador, un documental o un clave-valor bastan.
3. ¿Cuánto importa la integridad? Si un dato incorrecto tiene consecuencias legales o económicas, quieres un sistema que las impida por construcción.
4. ¿Qué volumen y qué crecimiento? Millones de filas no son problema para PostgreSQL. Cientos de terabytes distribuidos geográficamente sí exigen otra cosa.
5. ¿Cambiará el esquema a menudo? Un esquema que cambia cada semana sufre en un modelo rígido.
6. ¿Qué sabe el equipo y qué puede operar? Un sistema distribuido mal administrado es peor que uno sencillo bien administrado. Es un criterio infravalorado y decisivo.

Y dos reglas prácticas que ahorran muchos disgustos:

• Por defecto, relacional. Es la opción con más herramientas, más documentación, más gente que la conoce y más garantías. Hay que justificar apartarse de ella, no al revés.
• No es una decisión única. Un sistema puede usar PostgreSQL para lo transaccional, Redis para caché y MongoDB para contenidos. Se llama persistencia políglota y es el tema de la lección 08-03.

Este diagrama es una simplificación deliberada: sirve como primera aproximación, no como veredicto.

Apliquemos los criterios a nuestro caso, parte por parte.

Socios, libros, ejemplares, autores, préstamos, reservas y sucursales forman un dominio clásicamente relacional:

• La estructura es estable: un socio tiene siempre los mismos datos; un préstamo, también.
• Las relaciones son el corazón del sistema: un préstamo carece de sentido sin un socio y un ejemplar.
• La integridad es crítica: no puede existir un préstamo de un ejemplar inexistente, ni el mismo ejemplar prestado dos veces a la vez.
• Hace falta concurrencia con transacciones: cuatro mostradores prestando a la vez del mismo fondo.
• El volumen es modesto: 12.000 socios y unos cientos de miles de préstamos al año son cifras que PostgreSQL maneja sin despeinarse.

Decisión: PostgreSQL para todo el núcleo, y SQLite como entorno equivalente para practicar. Es lo que construiremos en los módulos 2, 4 y 5.

Las reseñas que los lectores dejan sobre los libros, y la ficha enriquecida del catálogo (sinopsis, portadas, premios, etiquetas libres, enlaces externos), tienen otro perfil:

• Estructura variable: unas reseñas tienen puntuación, otras solo texto; unas fichas tienen premios, otras no.
• Se leen enteras y de golpe, para pintar una página; no se cruzan con cinco tablas.
• La integridad es menos crítica: una reseña con un campo raro no rompe nada.
• Encajan de forma natural con listas anidadas (etiquetas, ediciones, enlaces).

Decisión: MongoDB para reseñas, catálogo enriquecido y registro de actividad. Es lo que trabajaremos en el módulo 3 y en el caso de estudio 08-02.

Ninguna de estas piezas se implementará en el curso, pero conviene que veas el mapa completo: un sistema real acaba combinando varias tecnologías, cada una donde aporta.

• Elegir NoSQL porque "es moderno". NoSQL no es una versión mejorada de lo relacional; es un conjunto de compromisos distintos. Si tus datos son estructurados y relacionales, usar un documental te obligará a reimplementar a mano la integridad que el RDBMS te regalaba.
• Creer que NoSQL significa "sin esquema". Significa que el esquema no lo impone la base de datos; sigue existiendo, pero ahora vive en el código de tu aplicación, disperso y sin validar. Es más libertad y más responsabilidad.
• Elegir por el volumen que imaginas tener, no por el que tendrás. La mayoría de proyectos que adoptan sistemas distribuidos "por si crecemos" nunca alcanzan el volumen que los justificaba, y pagan la complejidad desde el primer día. PostgreSQL aguanta muchísimo más de lo que la gente supone.
• Confundir el modelo con el producto. PostgreSQL es relacional, pero almacena JSON (jsonb), vectores (pgvector) y series temporales (TimescaleDB). Las fronteras entre familias son cada vez más porosas; a menudo la respuesta correcta es "extiende tu relacional" en lugar de "añade otro sistema".
• Ignorar el coste operativo. Cada tecnología nueva significa monitorización, copias de seguridad, actualizaciones y alguien que sepa arreglarla a las tres de la madrugada. Añadir un sistema debe compensar ese coste con claridad.
• Consejo: cuando dudes entre dos opciones, escribe las cinco consultas más frecuentes que hará tu aplicación y comprueba cuál las expresa de forma más natural. El modelo de datos se elige por las preguntas, no por la forma de almacenar.

Para cada necesidad de BiblioRed, indica qué familia de bases de datos es la más adecuada y justifica en una o dos frases:

1. Registrar que la socia 14 se lleva el ejemplar 3081 el 18/04/2026 y garantizar que ese ejemplar no puede prestarse simultáneamente en otra sucursal.
2. Guardar el "carrito de reserva" temporal de un usuario en la web, que caduca a los 20 minutos si no lo confirma.
3. Almacenar fichas de catálogo donde unos libros tienen premios y adaptaciones cinematográficas y otros solo título y sinopsis.
4. Responder a "¿qué socios están conectados con Marta a través de dos o menos libros compartidos?".
5. Guardar cada evento de temperatura y humedad de los cuatro sensores de la sala de fondo antiguo, uno por minuto, durante años.
6. Producir un informe anual con préstamos por sucursal, género y franja de edad de los últimos ocho años.

Se te da esta información sobre un ejemplar de BiblioRed:

El ejemplar con código EJ-3081 corresponde al libro "El mapa del tiempo" (ISBN 9788401339097), está en la sucursal Norte, en estado "bueno", y se adquirió el 12/01/2024.

1. Represéntalo como filas de tablas relacionales (dibuja las tablas implicadas y sus columnas, con datos).
2. Represéntalo como un único documento JSON.
3. Explica qué ventaja e inconveniente tiene cada representación si BiblioRed tuviera 40.000 ejemplares.

Una responsable de BiblioRed ha leído que "las bases de datos relacionales no escalan" y propone hacer todo el sistema en MongoDB, incluidos socios y préstamos. Redacta una respuesta breve (5-8 líneas) que: (a) reconozca en qué tiene parte de razón, (b) explique por qué el núcleo debe ser relacional en este caso concreto y (c) proponga dónde sí encaja MongoDB en BiblioRed.

Solución 1

Solución 2

(1) Representación relacional — tres tablas:

(2) Representación documental:

(3) Comparación con 40.000 ejemplares:

• Relacional: el título y el ISBN se escriben una sola vez por obra, aunque haya seis copias. Corregir una errata en el título es una única actualización. A cambio, mostrar la ficha de un ejemplar exige unir tres tablas.
• Documental: leer la ficha completa es una sola operación, muy rápida. A cambio, el título se repite en los 40.000 documentos: corregir la errata implica actualizar todos los ejemplares de esa obra, y si el proceso falla a medias quedan documentos con el título viejo y otros con el nuevo.

Esa tensión entre duplicar para leer rápido y normalizar para mantener coherencia es una de las decisiones centrales del diseño de datos. Se estudia a fondo en las lecciones 03-03 y 05-04.

Solución 3

Respuesta modelo:

Tienes razón en que el escalado horizontal es más sencillo en sistemas como MongoDB, diseñados desde el principio para repartirse entre muchos nodos, y en que un esquema flexible acelera el desarrollo cuando los datos cambian de forma a menudo. Ahora bien, ese problema no es el nuestro: 12.000 socios y unos cientos de miles de préstamos anuales están muy lejos del límite de un único servidor PostgreSQL. Lo que sí es nuestro problema —lo vimos en la hoja de cálculo actual— es la integridad: necesitamos que sea imposible prestar dos veces el mismo ejemplar o registrar un préstamo de un socio inexistente. Un RDBMS garantiza eso por construcción con claves ajenas y transacciones; en MongoDB tendríamos que programarlo a mano en cada punto de la aplicación, y bastaría con olvidarlo una vez para reintroducir el caos que queremos eliminar. Mi propuesta es usar PostgreSQL para el núcleo (socios, ejemplares, préstamos, reservas) y MongoDB donde de verdad aporta: reseñas de lectores, catálogo enriquecido y registro de actividad, que son datos de estructura variable y con exigencias de integridad mucho menores.

En esta lección hemos levantado el mapa completo del territorio:

• Las bases de datos se clasifican por modelo de datos, carga de trabajo, arquitectura de despliegue y ubicación del dato, ejes independientes que se combinan.
• Las relacionales siguen siendo la opción por defecto: estructura estable, relaciones explícitas, integridad garantizada y SQL.
• NoSQL agrupa cuatro familias distintas —documentales, clave-valor, columnares y de grafos— que cambian garantías o rigidez por flexibilidad y capacidad de distribución.
• Existen además modelos históricos (jerárquico y en red), especializados (objetos, embebidas, en memoria, series temporales, vectoriales) y la distinción de carga OLTP frente a OLAP.
• La elección se hace por las preguntas que harás, no por la moda: forma del dato, consultas previstas, exigencia de integridad, volumen real, estabilidad del esquema y capacidad del equipo.
• Para BiblioRed hemos decidido con argumentos: PostgreSQL (y SQLite para practicar) en el núcleo transaccional, y MongoDB para reseñas, catálogo enriquecido y actividad.

Hemos visto qué hay disponible hoy. Falta entender por qué el panorama tiene esta forma: por qué el modelo relacional desplazó a los que había antes, por qué SQL se convirtió en un estándar universal y qué presiones concretas hicieron aparecer NoSQL cuarenta años después. Eso es la lección 01-03, Historia y Evolución de las Bases de Datos, y no es una lección de fechas: entender qué problema resolvió cada generación es la mejor forma de saber cuándo conviene cada una.