Modelos de bases de datos, claves y concurrencia: guía completa y actualizada (2025)

Las bases de datos son el corazón de la informática. Sin ellas no existirían la banca electrónica, las redes sociales ni los sistemas de información geográfica. A lo largo de las décadas han surgido diferentes modelos lógicos de bases de datos y, con ellos, numerosos retos en gestión de claves, transacciones y concurrencia. Esta entrada reúne los conceptos fundamentales que aparecen en los apuntes proporcionados y los pone al día con tendencias recientes como NoSQL, NewSQL, nuevas técnicas de bloqueo y control de versiones. Está escrita en español para un público que busca una explicación clara y visual.

Modelos lógicos de bases de datos

Un modelo lógico describe cómo se organiza la información y las reglas que permiten relacionar los datos. Los modelos clásicos (jerárquico, en red y relacional) siguen vigentes, pero en la actualidad conviven con modelos para datos no estructurados o muy conectados. La siguiente ilustración ofrece una vista conceptual de esta diversidad:

Modelo relacional

El modelo relacional organiza la información en tablas (relaciones) formadas por filas y columnas. Cada fila es una tupla y cada columna es un atributo. Las relaciones entre tablas se establecen mediante claves. Los sistemas gestores relacionales cumplen las propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) y usan SQL como lenguaje de consulta. En este modelo se hace énfasis en la integridad de los datos y la posibilidad de realizar consultas complejas. RDBMS ofrece un esquema estructurado, integridad ACID y un lenguaje estándar (SQL). Ejemplos populares son MySQL, PostgreSQL, Oracle y SQL Server.

Modelos jerárquico y en red

En los años sesenta y setenta surgieron los modelos jerárquico y en red (CODASYL). El modelo jerárquico organiza la información en árboles con un solo nodo raíz; cada registro tiene un único «padre» y uno o varios «hijos». Este esquema es eficaz para representar estructuras de organización o catálogos. El modelo en red amplía el jerárquico permitiendo relaciones muchos a muchos mediante conjuntos formados por un elemento propietario y varios miembros. Ambos modelos exigen conocer de antemano la estructura de navegación y se usan en sistemas legados.

Modelo orientado a objetos y multidimensional

El modelo orientado a objetos almacena datos como objetos con atributos y métodos. Permite herencia y encapsulación y está pensado para bases de datos complejas como multimedia o CAD. Los SGBD orientados a objetos utilizan lenguajes de consulta como OQL (Object Query Language), que es un estándar del Object Data Management Group. OQL adopta la sintaxis de SQL pero se aplica a objetos; su complejidad ha impedido una implementación completa y su uso ha influido en lenguajes posteriores.

Para aplicaciones analíticas se utiliza el modelo multidimensional, que almacena datos en cubos con dimensiones y medidas. Esta estructura facilita la generación de OLAP y cuadros de mando.

NoSQL y bases de datos especializadas

Las limitaciones de los RDBMS para datos no estructurados dieron lugar a la familia NoSQL. Según Estuary, las bases de datos NoSQL permiten almacenar datos en formatos de clave‑valor, documentos, columnas anchas o grafos, utilizan esquemas flexibles y escalan horizontalmente. Los principales tipos son:

Tipo de base de datos	Características clave	Casos de uso comunes
Documentales	Almacenan documentos JSON/BSON; soportan esquemas flexibles y consultas sobre campos; ejemplos: MongoDB,	Catálogos de productos, perfiles de usuarios, contenido web
Clave‑valor	Diccionarios de pares clave‑valor; rendimiento muy alto y baja latencia; ejemplos: Redis, DynamoDB	Cachés, sesiones web, tablas de puntuaciones
Grafos	Representan datos mediante nodos y aristas; optimizados para muchas relaciones; ejemplos: Neo4j, Amazon Neptune	Redes sociales, recomendaciones, detección de fraudes
Columnar	Almacenan datos por columnas en lugar de filas; optimizadas para consultas analíticas; ejemplos: ClickHouse, BigQuery	Almacenes de datos, análisis OLAP
Series temporales	Especializadas en datos con marca temporal; eficiencia en almacenamiento y funciones de agregación; ejemplos: InfluxDB, TimescaleDB	IoT, monitorización de sistemas, finanzas

Además de NoSQL existe la tendencia NewSQL, que combina la consistencia de los sistemas relacionales con la escalabilidad horizontal de NoSQL. Las bases de datos NewSQL ofrecen soporte completo de SQL y transacciones ACID, escalando de forma distribuida. Ejemplos son Google Cloud Spanner y CockroachDB.

Otros modelos y consideraciones

En el diseño conceptual también encontramos modelos como entidad‑relación (ER) y modelo físico. El diagrama ER describe entidades, atributos y relaciones; su objetivo es captar los requisitos del negocio antes de implementar el esquema físico. También existen modelos semiestructurados (por ejemplo XML o JSON) y bases de datos orientadas a objetos que combinan tablas y objetos.

Claves y relaciones

Las claves permiten identificar de forma única las filas de una tabla y establecer relaciones entre ellas. Según el portal Guru99, una clave candidata es un conjunto mínimo de atributos que identifica de manera única cada tupla; una tabla puede tener varias claves candidatas y la clave primaria es aquella elegida como identificador principal. Las claves alternativas son las candidatas no seleccionadas como primarias, mientras que las claves compuestas contienen más de un atributo. La clave foránea enlaza una tabla con otra al contener valores que aparecen en la clave primaria de la tabla referenciada.

Superclave – Conjunto de atributos que puede identificar filas de forma única; toda clave candidata es una superclave pero puede contener atributos redundantes. Clave sustituta – Identificador artificial generado por el sistema cuando no existe una clave natural.

Esquemas, cardinalidad y grado

Un esquema de relación nombra la tabla e indica sus atributos (p. ej., Clientes(DNI, Nombre, Apellido)). La cardinalidad de una tabla es el número de tuplas (filas), mientras que el grado es el número de atributos (columnas). Las relaciones pueden ser de uno a uno, uno a muchos o muchos a muchos, conceptos que se representan gráficamente en un diagrama ER.

Elementos de un Sistema Gestor de Bases de Datos (SGBD)

Un SGBD es un conjunto de programas que gestionan la creación, consulta y mantenimiento de bases de datos. Sus principales componentes son:

• Motor de almacenamiento: Interactúa con el sistema de archivos para almacenar y recuperar datos.
• Procesador de consultas: Convierte las instrucciones de alto nivel (SQL) en operaciones de bajo nivel. Incluye un analizador, planificador y optimizador para elegir la mejor estrategia de ejecución.
• Lenguaje de consulta: SQL es el estándar para bases de datos relacionales; otros modelos emplean MQL, OQL o APIs específicas.
• Catálogo/metadata: Contiene la definición de tablas, vistas, índices y permisos. Permite que los usuarios consulten el esquema usando el propio SGBD.
• Gestor de transacciones: Controla el acceso concurrente a los datos, aplica los mecanismos de bloqueo y mantiene la integridad. Implementa propiedades ACID y ofrece funciones como commit y rollback.
• Administrador de copias de seguridad y registro (log manager): Mantiene un registro de las operaciones para permitir la recuperación ante fallos.

Concurrencia y bloqueo

En un sistema multiusuario, varias transacciones pueden acceder a la misma base de datos de forma concurrente. Sin mecanismos adecuados podrían producirse inconsistencias. La concurrencia se refiere a la capacidad del SGBD para permitir que múltiples usuarios lean y actualicen datos al mismo tiempo de forma segura.

Tipos de bloqueo

Un bloqueo impide que otras transacciones accedan a un recurso hasta que el bloqueo se libera. La granularidad se aplica a diferentes unidades (tabla, página, fila). Existen diferentes modos:

• Bloqueo compartido (S): Las transacciones pueden leer el recurso, pero nadie puede modificarlo. Este tipo de bloqueo se utiliza en consultas SELECT.
• Bloqueo exclusivo (X): Otorga control total sobre el recurso; la transacción puede leer y escribir, impidiendo que otras transacciones lean el mismo elemento.
• Bloqueos implícitos y explícitos: Los implícitos los gestiona automáticamente el SGBD; los explícitos se solicitan mediante comandos como SELECT ... FOR UPDATE.

El protocolo de dos fases (2PL) garantiza la serializabilidad. Una transacción pasa por una fase de crecimiento, en la que puede adquirir nuevos bloqueos pero no liberar ninguno, y una fase de contracción, en la que sólo libera bloqueos y no puede adquirir nuevos. Si todas las transacciones cumplen 2PL, las ejecuciones concurrentes son equivalentes a algún orden serial. Sin embargo, el protocolo puede provocar deadlocks y reducir la concurrencia.

Optimización y nuevas técnicas

Los sistemas modernos introducen mejoras para reducir la contención. Microsoft SQL Server 2023 incorporó el bloqueo optimizado (optimized locking), un mecanismo que minimiza la memoria utilizada y el número de bloqueos necesarios para escrituras concurrentes. Con este modo, los bloqueos de fila y página se liberan inmediatamente después de modificar cada fila, manteniendo sólo un bloqueo de identificador de transacción (TID) hasta el final. Esta técnica disminuye la necesidad de escalar bloqueos y reduce los conflictos entre transacciones.

Otra alternativa es el control de concurrencia multiversión (MVCC), ampliamente utilizado en PostgreSQL, MySQL/InnoDB y bases analíticas modernas. MVCC permite que lectores y escritores trabajen sobre versiones distintas de los datos. En lugar de bloquear registros, cada actualización genera una nueva versión de la fila, de modo que los lectores ven una instantánea consistente del momento en que comenzaron. Esta técnica ofrece:

• Concurrencia sin bloqueos y rendimiento predecible para cargas mixtas.
• Lecturas estables para transacciones de larga duración.
• Reducción de deadlocks y contención.

Su coste radica en el almacenamiento de múltiples versiones y en la necesidad de procesos de limpieza (vacuum). MVCC es apropiado para aplicaciones con muchas consultas concurrentes y análisis en tiempo real.

Problemas de concurrencia e niveles de aislamiento

Al permitir la concurrencia pueden ocurrir fenómenos no deseados:

• Lectura sucia (dirty read): una transacción lee datos modificados por otra que aún no se ha confirmado; si la transacción que modifica se revierte, se obtiene un valor inexistente.
• Lectura no repetible (non‑repeatable read): una transacción vuelve a leer una fila que ha sido modificada por otra transacción entre lecturas.
• Lectura fantasma (phantom read): una transacción ve filas nuevas o eliminadas que no existían en una lectura anterior.

El estándar SQL define niveles de aislamiento que determinan qué anomalías se permiten. La siguiente tabla resume la relación entre niveles e inconsistencias permitidas según Microsoft:

Nivel de aislamiento	Lectura sucia	Lectura no repetible	Lectura fantasma
Read Uncommitted (Lectura no comprometida)	Sí	Sí	Sí
Read Committed (Lectura comprometida)	No	Sí	Sí
Repeatable Read (Lectura repetible)	No	No	Sí
Serializable	No	No	No

La opción Serializable proporciona el aislamiento más estricto: todas las lecturas y escrituras se ordenan como si se ejecutaran en serie; sin embargo, reduce la concurrencia y requiere más bloqueos. Muchos SGBD ofrecen niveles intermedios, como Snapshot Isolation, que evitan lecturas sucias y no repetibles mediante MVCC, manteniendo cierto grado de concurrencia.

Deadlocks y gestión de transacciones

Un deadlock (interbloqueo) ocurre cuando dos o más transacciones se bloquean mutuamente esperando recursos que la otra posee. Los SGBD modernos detectan automáticamente los deadlocks mediante grafos de espera y abortan una transacción para liberar recursos. Para minimizarlos se recomienda:

• Acceder a las tablas en el mismo orden en todas las transacciones.
• Mantener las transacciones lo más cortas posible.
• Utilizar niveles de aislamiento adecuados y técnicas como MVCC o bloqueo optimizado.

Lenguajes de consulta y sublenguajes SQL

El término SQL engloba varias subcategorías de instrucciones que cumplen funciones distintas:

Sub‑lenguaje	Propósito	Ejemplos
DDL (Data Definition Language)	Define la estructura de la base de datos	CREATE TABLE, ALTER TABLE, DROP TABLE
DML (Data Manipulation Language)	Manipula datos existentes	SELECT, INSERT, UPDATE, DELETE
DCL (Data Control Language)	Gestiona permisos y seguridad	GRANT, REVOKE
TCL (Transaction Control Language)	Controla transacciones	COMMIT, ROLLBACK, SAVEPOINT
DQL (Data Query Language)	Consulta datos mediante SELECT, aplicando cláusulas como WHERE, GROUP BY, HAVING y ORDER BY

Otros lenguajes incluyen QBE (Query By Example), un lenguaje gráfico introducido por IBM en los años setenta. Permite realizar consultas rellenando plantillas visuales; el sistema traduce la plantilla a SQL. QBE fue el primer lenguaje de consultas gráfico y ha influido en interfaces como Microsoft Access. Para bases de datos orientadas a objetos existe OQL, un estándar inspirado en SQL que permite consultas sobre objetos; su complejidad ha limitado su adopción.

Niveles de abstracción e independencia

Un SGBD se organiza en tres niveles de abstracción:

• Nivel externo (o de vistas): define diferentes perspectivas o vistas para cada grupo de usuarios. Permite restringir el acceso a determinadas columnas o filas.
• Nivel conceptual (o lógico): describe la estructura global de la base de datos (tablas, relaciones, restricciones) sin detallar cómo se almacena físicamente. La independencia lógica permite modificar el esquema conceptual sin afectar a las aplicaciones.
• Nivel interno (o físico): especifica cómo se almacenan realmente los datos, los índices y los métodos de acceso. La independencia física permite cambiar la representación interna sin alterar el modelo conceptual.

La separación entre estos niveles facilita el mantenimiento y la seguridad, ya que los cambios en un nivel no afectan a los demás.

Reglas de Codd

Edgar F. Codd propuso en 1985 trece reglas (numeradas de 0 a 12) para definir lo que debía cumplir un sistema de bases de datos relacional.

1. Regla de la información: toda la información (incluidos los metadatos) debe representarse como valores en tablas.
2. Regla del acceso garantizado: cada dato debe ser accesible mediante una combinación de nombre de tabla, clave primaria y nombre de columna.
3. Tratamiento sistemático de nulos: los valores NULL deben tratarse de manera uniforme y distinta a las cadenas vacías.
4. Catálogo activo en línea: la descripción de la base de datos debe almacenarse en el mismo formato relacional y ser accesible con el mismo lenguaje de consulta.
5. Lenguaje de datos completo: el sistema debe soportar un lenguaje completo que permita definición, manipulación y control de datos.
6. Independencia física y lógica: los cambios en el almacenamiento físico o en el esquema lógico no deben afectar a las aplicaciones.
7. Regla de no subversión: si el sistema ofrece una interfaz de bajo nivel, esta no debe permitir evitar las reglas de integridad ni comprometer la seguridad.

La mayoría de los SGBD comerciales cumplen algunas de estas reglas pero no todas; por ejemplo, muchos sistemas no almacenan sus catálogos de metadatos en formato puramente relacional.

Conclusión

La gestión de bases de datos es un campo en constante evolución. Los modelos clásicos —relacional, jerárquico, en red— siguen siendo fundamentales, pero conviven con modelos orientados a objetos, multidimensionales, NoSQL y NewSQL. La elección de un modelo depende de la naturaleza de los datos y del tipo de aplicación: estructuras fuertemente relacionadas requieren bases de datos relacionales; datos semiestructurados o altamente conectados se benefician de modelos de documentos o grafos; sistemas globales y de alta concurrencia pueden optar por soluciones NewSQL.

El control de la concurrencia es esencial para mantener la coherencia en entornos multiusuario. Los mecanismos tradicionales de bloqueo y los niveles de aislamiento proporcionan garantías estrictas pero pueden reducir la escalabilidad; las mejoras como el bloqueo optimizado y MVCC buscan equilibrar consistencia y rendimiento. Conocer estas técnicas permite diseñar bases de datos más seguras y eficientes.

Finalmente, las claves y las reglas de Codd nos recuerdan que una buena base de datos se apoya tanto en un diseño lógico cuidadoso como en normas de integridad. La comprensión de estos principios, junto con las tendencias emergentes, ayudará a los desarrolladores y administradores a crear aplicaciones robustas y adaptadas a los desafíos de 2025 y más allá.