1. INTRODUCCIÓN Y CONCEPTO DE SGBD

Un Sistema de Gestión de Bases de Datos (SGBD) es un conjunto integrado de programas que permite definir, construir, manipular y compartir bases de datos entre múltiples usuarios y aplicaciones. Para comprender su importancia, imaginemos el escenario anterior a la existencia de SGBD, donde cada aplicación gestionaba sus propios archivos de datos. Este enfoque generaba múltiples problemas: redundancia de datos con la misma información duplicada en múltiples ubicaciones, inconsistencias cuando se actualizaba un dato en un lugar pero no en otros, dificultades para compartir información entre aplicaciones, ausencia de estándares de acceso, y falta de mecanismos integrados de seguridad y recuperación.

Los SGBD surgieron como solución a estos problemas en la década de 1960, evolucionando desde sistemas jerárquicos simples hasta los sofisticados sistemas relacionales, orientados a objetos y NoSQL que dominan el panorama actual. Un SGBD moderno actúa como intermediario entre los usuarios o aplicaciones y los datos físicamente almacenados, proporcionando una capa de abstracción que oculta los detalles de cómo se almacenan los datos físicamente en discos, cómo se estructuran los archivos, y cómo se optimizan los accesos.

1.1. Del fichero aislado al servicio de datos

Un SGBD completo proporciona múltiples funciones críticas que justifican su complejidad. La función de definición de datos permite a los administradores especificar qué tipos de datos se almacenarán, cómo se estructurarán mediante esquemas y relaciones, qué restricciones de integridad deben cumplirse, y qué índices se crearán para optimizar consultas. El lenguaje de definición de datos o DDL (Data Definition Language) materializa esta función mediante comandos como CREATE TABLE, ALTER TABLE y CREATE INDEX.

La función de manipulación de datos permite a usuarios y aplicaciones insertar nuevos datos, actualizar información existente, eliminar registros obsoletos, y consultar la base de datos para recuperar información según criterios específicos. El lenguaje de manipulación de datos o DML (Data Manipulation Language) proporciona comandos como INSERT, UPDATE, DELETE y el omnipresente SELECT para consultas. SQL (Structured Query Language) integra tanto DDL como DML en un lenguaje declarativo que permite expresar qué datos se desean sin especificar cómo obtenerlos.

La diferencia esencial entre una base de datos y un conjunto de ficheros no es meramente el formato. Un SGBD incorpora un modelo explícito, un catálogo con metadatos, lenguajes de definición y manipulación, un planificador de consultas, controles de autorización, mecanismos de concurrencia, registro de cambios y procedimientos de recuperación. Todo ello permite que múltiples aplicaciones compartan información sin conocer cómo se disponen físicamente las páginas, los bloques, los segmentos o las réplicas.

La abstracción tiene consecuencias organizativas. El dato deja de pertenecer exclusivamente al programa que lo creó y pasa a ser un recurso administrado. Para que esa promesa sea real deben existir responsables funcionales, reglas de calidad, semántica común, trazabilidad y acuerdos sobre disponibilidad y conservación. Un SGBD resuelve problemas técnicos, pero no sustituye el gobierno del dato ni corrige por sí solo definiciones ambiguas.

1.2. Objetivos de servicio

En un sistema corporativo se valoran simultáneamente corrección, rendimiento, disponibilidad, escalabilidad, mantenibilidad y auditabilidad. Estas cualidades pueden entrar en tensión. Aumentar el número de réplicas mejora lectura y continuidad, pero obliga a decidir cuándo y cómo convergen. Elevar el aislamiento reduce anomalías, aunque puede aumentar esperas o abortos. Crear índices acelera determinadas consultas, pero incrementa espacio, mantenimiento y coste de escritura.

La selección de un SGBD debe partir de la carga y de los invariantes: volumen, patrón de acceso, proporción de lectura y escritura, distribución geográfica, latencia admisible, recuperación, protección de datos, interoperabilidad, experiencia operativa y coste total. Elegir por moda o por una única prueba de rendimiento suele trasladar complejidad a la aplicación.

2. ARQUITECTURA Y COMPONENTES INTERNOS

2.1. Componentes lógicos

La arquitectura interna de un SGBD es compleja, comprendiendo múltiples componentes que cooperan para proporcionar sus funcionalidades. El procesador de consultas recibe consultas SQL, las analiza sintáctica y semánticamente, las optimiza eligiendo el plan de ejecución más eficiente entre múltiples alternativas, y genera código ejecutable. El gestor de almacenamiento maneja la interacción con el sistema operativo para leer y escribir datos en disco, gestiona el espacio en disco asignando y liberando páginas de datos, y mantiene índices actualizados.

El gestor de transacciones coordina transacciones concurrentes, implementa protocolos de control de concurrencia para evitar interferencias, mantiene logs de transacciones para recuperación, y garantiza las propiedades ACID que exploraremos en detalle posteriormente. El gestor de buffer mantiene una caché en memoria de páginas de datos frecuentemente accedidas, reduciendo accesos a disco que son órdenes de magnitud más lentos que accesos a memoria. El catálogo o diccionario de datos almacena metadatos sobre la estructura de la base de datos, incluyendo definiciones de tablas, vistas, índices, usuarios, privilegios y estadísticas utilizadas por el optimizador de consultas.

El procesador de consultas recibe una sentencia declarativa, comprueba nombres y tipos, la transforma en una representación interna, aplica reglas algebraicas, estima costes y produce un plan de ejecución. El optimizador decide, por ejemplo, si conviene un escaneo secuencial, un índice, una unión por bucles anidados, una unión hash o una ordenación. La calidad de la decisión depende del catálogo, de las estadísticas y de las estimaciones de cardinalidad.

El gestor de almacenamiento organiza páginas, extensiones, segmentos y archivos; coordina el buffer pool; administra espacio libre; y traduce operaciones lógicas a lecturas y escrituras. El gestor de transacciones delimita unidades de trabajo y coordina concurrencia y recuperación. El gestor de bloqueo o el subsistema MVCC controla visibilidad y conflictos. El gestor de log conserva la información necesaria para recuperación y durabilidad.

2.2. Catálogo y metadatos

El catálogo contiene definiciones de tablas, columnas, tipos, vistas, índices, restricciones, usuarios, privilegios, particiones y estadísticas. No es documentación externa: es información que el propio SGBD consulta para validar y ejecutar operaciones. En productos concretos puede denominarse diccionario de datos, catálogo del sistema o esquema de información.

Los metadatos técnicos deben relacionarse con metadatos de negocio. Saber que una columna es VARCHAR(20) no aclara si representa un identificador clínico, un código de centro o un estado administrativo. La semántica, el propietario, la procedencia, el ciclo de vida y las reglas de calidad deben documentarse en el marco de gobierno corporativo.

2.3. Arquitectura de despliegue

El SGBD puede ejecutarse embebido en una aplicación, como servidor independiente, en clúster, como servicio gestionado o distribuido entre varios centros. También puede separar nodos de cómputo y almacenamiento. Estas decisiones afectan a latencia, consistencia, tolerancia a fallos, operaciones de mantenimiento y modelo de seguridad.

3. MODELOS DE DATOS Y CRITERIOS DE ELECCIÓN

3.1. Qué aporta un modelo de datos

Un modelo de datos define las estructuras permitidas, las operaciones y las restricciones. El modelo relacional organiza la información en relaciones y se apoya en álgebra relacional y restricciones declarativas. El jerárquico y el de red representan recorridos predeterminados. El orientado a objetos conserva identidad y estructuras complejas. Los modelos NoSQL priorizan patrones concretos, distribución o flexibilidad mediante pares clave-valor, documentos, grafos o familias de columnas.

La clasificación no es absoluta. Un mismo producto puede admitir documentos JSON, grafos, búsqueda textual, vectores o extensiones espaciales junto a tablas. Por ello conviene distinguir el modelo principal, que determina la forma natural de organizar y consultar, de las capacidades accesorias. Añadir un tipo JSON a un SGBD relacional no lo convierte automáticamente en documental; del mismo modo, una API SQL sobre un almacén distribuido no le confiere todas las propiedades de un RDBMS clásico.

3.2. Esquema rígido, flexible y evolución

«Sin esquema» es una expresión engañosa. Todo dato consumido por una aplicación tiene forma y significado. En un sistema relacional el SGBD valida el esquema antes de almacenar; en muchos sistemas documentales la estructura puede variar y la validación se aplica en la aplicación, mediante reglas de colección o durante la lectura. Esa flexibilidad facilita evolución, pero puede desplazar errores y costes a etapas posteriores.

La decisión debe considerar qué invariantes pueden declararse, cómo se migran versiones, cómo se consulta el histórico y cómo se evita que documentos semánticamente equivalentes usen nombres o tipos diferentes. En información sanitaria, una flexibilidad sin control puede degradar interoperabilidad y calidad, por lo que es habitual combinar esquemas versionados, terminologías y validación.

3.3. Carga transaccional y analítica

Las cargas OLTP realizan muchas operaciones breves, selectivas y concurrentes, con baja latencia y fuerte atención a integridad. Las cargas analíticas escanean grandes volúmenes, agregan columnas y toleran procesos más largos. No existe un motor óptimo para ambos extremos. La separación entre sistema operacional y plataforma analítica evita que una explotación intensiva bloquee o degrade la actividad asistencial.

4. BASES DE DATOS CENTRALIZADAS Y DISTRIBUIDAS

4.1. Arquitectura centralizada

Las bases de datos centralizadas representan el modelo arquitectónico más simple y tradicional, donde toda la base de datos reside físicamente en un único servidor. Este servidor ejecuta el SGBD y almacena todos los datos, mientras los clientes se conectan remotamente para realizar operaciones. La arquitectura centralizada fue dominante durante décadas y sigue siendo apropiada para muchos escenarios actuales, particularmente cuando el volumen de datos es manejable por un único servidor y la mayoría de usuarios se encuentran geográficamente concentrados.

Las ventajas de la centralización son significativas. La administración es simplificada al tener un único punto de gestión para copias de seguridad, actualizaciones de software, ajuste de rendimiento y aplicación de políticas de seguridad. La consistencia de datos es más fácil de garantizar al no existir réplicas que puedan divergir. El coste es potencialmente menor al requerir invertir en un único servidor en lugar de infraestructura distribuida. Las consultas que requieren unir datos de múltiples tablas ejecutan más eficientemente al no necesitar comunicación de red.

Sin embargo, las limitaciones son también evidentes. La escalabilidad está limitada por la capacidad máxima de un único servidor, un límite físico que eventualmente se alcanza. La disponibilidad es vulnerable a un único punto de fallo, donde un problema en el servidor hace inaccesible toda la base de datos. La latencia puede ser alta para usuarios geográficamente distantes del servidor. El rendimiento está limitado por los recursos de un único sistema, sin capacidad de paralelizar cargas de trabajo entre múltiples máquinas.

Centralizada no significa necesariamente «sin alta disponibilidad». Puede existir un primario con réplica de espera, almacenamiento redundante y conmutación, pero el servicio conserva un punto lógico de coordinación. Sus ventajas son semántica sencilla, transacciones locales, menor coste de coordinación y administración más directa. Sus límites aparecen cuando el volumen, la distancia, la disponibilidad requerida o la soberanía del dato obligan a repartir carga y copias.

4.2. Distribución, fragmentación y transparencia

Las bases de datos distribuidas abordan las limitaciones de la centralización distribuyendo los datos a través de múltiples servidores físicamente separados, frecuentemente en ubicaciones geográficas diferentes, pero presentando al usuario la ilusión de una única base de datos lógica. Esta distribución puede realizarse mediante fragmentación donde diferentes subconjuntos de datos residen en diferentes nodos, replicación donde copias completas o parciales se mantienen en múltiples ubicaciones para mejorar disponibilidad y rendimiento, o una combinación de ambas estrategias.

La fragmentación puede ser horizontal, donde diferentes filas de una tabla residen en diferentes nodos, típicamente particionando por rangos de una clave o mediante hash. Por ejemplo, una tabla de clientes podría fragmentarse geográficamente con clientes europeos en un servidor europeo y clientes americanos en un servidor americano. La fragmentación también puede ser vertical, donde diferentes columnas de una tabla residen en diferentes nodos, útil cuando diferentes aplicaciones requieren diferentes subconjuntos de atributos.

La fragmentación horizontal distribuye filas según una clave o predicado; la vertical separa columnas conservando un identificador que permita reconstruir; y la mixta combina ambas. Una fragmentación correcta debe ser completa, permitir reconstrucción y controlar solapamientos. En la práctica se habla de particionamiento o sharding cuando los fragmentos se asignan a nodos.

La replicación mantiene copias para lectura, cercanía o continuidad. Puede ser síncrona, cuando la confirmación espera a varias copias; asíncrona, cuando se confirma antes de que todas se actualicen; primaria-réplica; o multi-primaria. Cada opción define ventanas de pérdida, conflictos, latencia y comportamiento durante fallos.

4.3. Transparencias y costes

Una base distribuida aspira a ocultar ubicación, fragmentación y replicación, de modo que el usuario formule una operación global. Esa transparencia nunca elimina el coste físico. Una unión entre particiones, una transacción que toca varios nodos o un cambio de líder requiere mensajes, consenso o coordinación. El optimizador distribuido debe considerar transferencia de datos y paralelismo, no solo E/S local.

5. BASES DE DATOS FEDERADAS Y VIRTUALIZACIÓN

5.1. Concepto y autonomía

Las bases de datos federadas representan un enfoque diferente a la integración de múltiples bases de datos, donde sistemas de bases de datos heterogéneos y autónomos cooperan para proporcionar una vista integrada sin necesariamente compartir un esquema común o repositorio centralizado. Cada base de datos participante mantiene su autonomía, continuando operando independientemente y siendo gestionada localmente, mientras el sistema federado proporciona capacidad de consultar a través de múltiples bases de datos con cierta transparencia.

El sistema federado mantiene un esquema global que integra los esquemas locales de las bases de datos participantes, mapeando conceptos entre ellos. Cuando un usuario emite una consulta contra el esquema global, el sistema la descompone en consultas contra las bases de datos locales apropiadas, las ejecuta, y combina los resultados. Los niveles de acoplamiento pueden variar desde federaciones fuertemente acopladas con esquema global detallado y transacciones distribuidas, hasta federaciones débilmente acopladas que proporcionan meramente capacidad de consulta federada sin garantías transaccionales.

Las bases de datos federadas son particularmente valiosas en escenarios de fusiones y adquisiciones donde múltiples organizaciones necesitan integrar sus sistemas de información existentes sin reemplazarlos completamente, en organizaciones grandes con bases de datos departamentales que necesitan capacidad de elaboración de informes consolidado, y en escenarios de integración de aplicaciones empresariales donde diferentes aplicaciones mantienen sus propias bases de datos pero requieren intercambio de información.

Una federación integra fuentes que pueden haber sido diseñadas, adquiridas y administradas de forma independiente. Las fuentes conservan autonomía sobre esquema, seguridad, disponibilidad y evolución. El sistema federado ofrece una vista mediada mediante conectores, envoltorios, traducciones y un catálogo global. Por ello, el problema principal no es mover bytes, sino reconciliar semántica, identificadores, tipos, unidades y reglas.

5.2. Acoplamiento y heterogeneidad

En una federación fuertemente acoplada se define un esquema global y las fuentes se mapean a él. En una federación débil o una arquitectura de virtualización, las consultas se componen sobre fuentes con menor integración previa. La heterogeneidad puede ser sintáctica —distintos protocolos o tipos—, estructural —tablas frente a documentos— o semántica —el mismo término con significados diferentes—.

Los adaptadores traducen dialectos y capacidades; el mediador descompone la consulta; y el optimizador decide qué filtros y proyecciones puede empujar a cada origen. Si una fuente no soporta una operación, el motor debe ejecutarla después de recuperar datos. Esto puede producir transferencias masivas y resultados sensibles a cambios simultáneos en los orígenes.

5.3. Federación frente a integración física

La federación es adecuada para consulta integrada, transición o acceso a sistemas que no pueden consolidarse. No siempre es la solución para explotación intensiva. Un almacén corporativo o un repositorio analítico replica y transforma datos para obtener rendimiento, historia y calidad controlada. La virtualización privilegia actualidad y evita duplicación, pero depende de cada fuente y puede carecer de una instantánea coherente global.

6. NOSQL: CLAVE-VALOR Y DOCUMENTALES

6.1. Significado y motivación

El término NoSQL agrupa familias de bases de datos cuyo modelo principal no es el relacional clásico; se interpreta habitualmente como «Not Only SQL». Su expansión se produjo con cargas web y distribuidas que exigían escalado horizontal, alta disponibilidad, modelos flexibles o recorridos especializados que no siempre encajaban de forma natural en un único esquema relacional. Empresas como Google, Amazon y Facebook enfrentaban desafíos que los SGBD relacionales tradicionales no abordaban eficientemente: necesidad de escalar horizontalmente, mantener servicio ante fallos parciales, elegir modelos de consistencia adecuados a cada caso y admitir estructuras que evolucionan con rapidez. Estas motivaciones no implican que todo sistema NoSQL sacrifique consistencia ni que un SGBD relacional sea incapaz de escalar.

NoSQL no representa un rechazo completo de las bases de datos relacionales ni de SQL, sino el reconocimiento de que un único modelo no optimiza todos los escenarios. En sistemas replicados, CAP obliga a decidir cómo responder cuando existe una partición de red: preservar una visión linealizable puede exigir rechazar o retrasar operaciones, mientras mantener disponibilidad puede requerir aceptar divergencia temporal y reconciliar. No puede clasificarse a todos los SGBD relacionales como CP ni a todos los NoSQL como AP; las garantías dependen de arquitectura, configuración y operación.

El término NoSQL se interpreta habitualmente como Not Only SQL. No implica ausencia de consultas, esquema, transacciones o consistencia, sino que agrupa sistemas que no adoptan el modelo relacional como única abstracción. Sus diseños suelen optimizar escalado horizontal, baja latencia, disponibilidad, estructuras agregadas o patrones de acceso concretos.

La contrapartida es que muchas operaciones que un SGBD relacional ofrece de forma general —uniones, restricciones entre entidades, consultas ad hoc o transacciones multiobjeto— pueden ser limitadas, costosas o delegadas en la aplicación. La elección debe partir del patrón de acceso, no de una oposición simplista entre «SQL antiguo» y «NoSQL moderno».

6.2. Almacenes clave-valor

Las bases de datos clave-valor representan el modelo NoSQL más simple conceptualmente, almacenando datos como pares donde cada valor es accesible mediante una clave única. La clave es típicamente una cadena o número que identifica unívocamente un elemento de datos, mientras el valor puede ser cualquier objeto, desde cadenas simples hasta objetos binarios complejos, documentos JSON, o estructuras serializadas. El SGBD trata el valor como opaco, sin interpretar su estructura interna, delegando toda lógica de negocio a la aplicación.

Las operaciones básicas son extremadamente simples: GET para recuperar un valor dada una clave, PUT para almacenar o actualizar un valor asociado a una clave, y DELETE para eliminar una entrada. Esta simplicidad permite implementaciones extremadamente eficientes optimizadas para lecturas y escrituras de baja latencia a escala masiva. Las bases de datos clave-valor pueden mantener datos en memoria para reducir la latencia para minimizar latencia, persistiendo a disco asíncronamente o usando estructuras como log-structured merge trees que optimizan escrituras.

El acceso principal es clave → valor. La clave suele determinar partición y localización. El valor puede ser opaco para el motor o pertenecer a tipos nativos con operaciones atómicas. Son apropiados para cachés, sesiones, contadores, configuración, colas o estados recuperables por identificador. Las consultas por atributos internos requieren índices secundarios, módulos adicionales o un modelo distinto.

Debe diferenciarse caché de sistema de registro. Una caché puede admitir expiración y pérdida reconstruible; una fuente autoritativa necesita persistencia, copia, recuperación y garantías de escritura acordes con el dato. El hecho de que un producto permita persistir no convierte cualquier configuración de caché en base corporativa.

6.3. Bases documentales

Las bases de datos documentales evolucionan el modelo clave-valor permitiendo que los valores sean documentos estructurados, típicamente en formato JSON, BSON o XML, donde el SGBD comprende la estructura interna del documento y permite consultar y actualizar partes específicas sin necesidad de recuperar o reescribir el documento completo. Un documento puede contener estructuras anidadas complejas con objetos embebidos y matrices, proporcionando flexibilidad que el modelo relacional rígido no ofrece fácilmente.

MongoDB es un SGBD documental ampliamente utilizado, almacenando documentos en formato BSON (Binary JSON) que extiende JSON con tipos de datos adicionales como fechas y datos binarios. Los documentos se organizan en colecciones, análogas a tablas relacionales pero sin requerir esquema fijo. Cada documento en una colección puede tener estructura diferente, facilitando evolución de esquema sin migraciones complejas. MongoDB proporciona un lenguaje de consulta rico que permite filtrar documentos por valores de campos incluyendo campos anidados, proyectar subconjuntos de campos, ordenar resultados, y realizar agregaciones complejas mediante un pipeline de transformaciones.

{
  "_id": "paciente-123",
  "nombre": "Ana",
  "contactos": [
    {"tipo": "movil", "valor": "+34 600 000 000"}
  ],
  "direccion": {
    "municipio": "Sevilla",
    "codigo_postal": "41001"
  }
}

CouchDB adopta un enfoque diferente, enfatizando replicación multi-master donde múltiples instancias pueden aceptar escrituras que luego se sincronizan, siendo especialmente adecuado para aplicaciones offline-first que necesitan funcionar sin conectividad continua. CouchDB expone toda funcionalidad mediante APIs RESTful HTTP, permitiendo interacción desde cualquier lenguaje o plataforma sin drivers especializados.

La unidad de atomicidad natural suele ser el documento. Embebiendo datos que se modifican juntos se reducen uniones y transacciones distribuidas. Referenciar documentos evita duplicación, pero reintroduce coordinación. El diseño debe decidir entre embeber y referenciar según cardinalidad, tamaño, ciclo de vida y patrón de lectura.

Los documentos necesitan índices sobre campos, rutas o matrices. Un índice multiclave puede generar varias entradas por documento; un índice textual tokeniza y normaliza; y un índice compuesto depende del orden de campos. La flexibilidad no elimina la necesidad de controlar tamaño, nombres, tipos y versiones.

7. BASES DE DATOS DE GRAFOS Y DE OBJETOS

7.1. Grafos de propiedades y recorridos

Las bases de datos de grafos están optimizadas para almacenar y consultar datos que forman naturalmente grafos, donde las relaciones entre entidades son tan importantes como las entidades mismas. El modelo de datos consiste en nodos que representan entidades con propiedades clave-valor asociadas, y aristas que representan relaciones entre nodos también con propiedades. Esta estructura nativa de grafo contrasta con representar grafos en bases de datos relacionales mediante tablas de unión, lo cual requiere múltiples joins que se vuelven ineficientes para consultas que recorren múltiples niveles de relaciones.

Neo4j es un SGBD de grafos ampliamente utilizado, utilizando el lenguaje Cypher para consultas que expresa patrones de grafo de forma declarativa e intuitiva. Por ejemplo, encontrar amigos de amigos que también gustan de un interés específico se expresa naturalmente en Cypher de forma que refleja la estructura del grafo.

MATCH (p:Persona {id: $id})-[:CONOCE]->(amigo)-[:CONOCE]->(candidato)
WHERE candidato <> p
  AND NOT (p)-[:CONOCE]-(candidato)
RETURN candidato, count(*) AS conexiones_comunes
ORDER BY conexiones_comunes DESC

En un grafo de propiedades, nodos y relaciones tienen identidad, etiquetas y propiedades. La ventaja aparece cuando la pregunta depende de la topología: caminos, vecindad, comunidades, dependencias, recomendaciones o fraude. El coste de una consulta se relaciona con el subgrafo recorrido, mientras que en una representación relacional puede crecer el número de auto-uniones.

El modelado debe evitar nodos superconectados, relaciones ambiguas y propiedades duplicadas sin regla. También debe decidir dirección, tipo de relación y temporalidad. Un grafo no sustituye automáticamente a un modelo relacional: informes tabulares, agregaciones masivas o transacciones contables pueden seguir siendo más naturales en otros motores.

7.2. Bases de datos de objetos

Las bases de datos de objetos almacenan objetos directamente como se definen en lenguajes de programación orientados a objetos, eliminando la necesidad de correspondencia objeto-relacional. Un objeto en la base de datos preserva su identidad, estado (valores de atributos) y comportamiento (métodos), junto con relaciones con otros objetos incluyendo herencia y composición. Este enfoque reduce significativamente el impedance mismatch entre el modelo de objetos de la aplicación y el modelo de datos persistido.

Sin embargo, las bases de datos de objetos nunca alcanzaron adopción mayoritaria por varias razones. La falta de estándares ampliamente aceptados, con múltiples sistemas incompatibles y el estándar ODMG que llegó tarde, fragmentó el mercado. La integración con SQL, el lenguaje de consulta de facto para bases de datos, fue problemática. El rendimiento para ciertos tipos de consultas, particularmente agregaciones sobre grandes conjuntos de datos, frecuentemente era inferior a bases de datos relacionales optimizadas. El ecosistema de herramientas, experiencia de desarrolladores y materiales educativos favorecía fuertemente bases de datos relacionales establecidas.

La persistencia transparente reduce código de correspondencia objeto-relacional, pero aumenta el acoplamiento entre lenguaje, clases y almacenamiento. La evolución de clases, la consulta entre agregados, la interoperabilidad y la independencia tecnológica resultan críticas. Los estándares ODMG influyeron en el área, aunque no alcanzaron la universalidad de SQL.

Conviene distinguir una base orientada a objetos de un SGBD objeto-relacional. Este último conserva tablas y SQL, pero incorpora tipos complejos, herencia, colecciones o métodos. También debe distinguirse del uso de un ORM: un ORM mapea objetos a un modelo relacional; no cambia por sí mismo el motor subyacente.

8. BASES DE DATOS DE FAMILIAS DE COLUMNAS Y ALMACENAMIENTO COLUMNAR

8.1. Dos conceptos que no deben confundirse

La expresión «base columnar» se usa para dos familias diferentes. Un almacén orientado a columnas dispone físicamente juntos los valores de cada columna y está optimizado para analítica. Un almacén de familias de columnas o wide-column organiza filas particionadas, con columnas agrupadas y potencialmente dispersas, y está orientado a distribución y consultas por clave de partición. Cassandra y HBase pertenecen a la segunda familia; motores analíticos como ClickHouse o Vertica representan la primera.

8.2. Almacenamiento columnar analítico

Al almacenar juntos valores del mismo atributo, el motor lee solo las columnas solicitadas, comprime secuencias homogéneas y ejecuta operaciones vectorizadas. Es muy eficaz para sumar, filtrar o agrupar millones de filas sobre pocas columnas. Las técnicas incluyen diccionario, run-length encoding, bit packing, zone maps y ejecución por lotes.

La escritura fila a fila puede ser menos eficiente porque una fila afecta a varios segmentos. Muchos motores reciben lotes, buffers o estructuras delta que después compactan. Por ello, el almacenamiento columnar es habitual en OLAP, data warehouses y réplicas analíticas, mientras que el almacenamiento por filas favorece operaciones OLTP que leen o modifican registros completos.

8.3. Wide-column y diseño por consulta

Un sistema wide-column distribuye particiones mediante una clave. Dentro de una partición, claves de clustering ordenan filas. El diseño se orienta a consultas conocidas: cada consulta eficiente debe poder localizar una partición o un conjunto acotado. La desnormalización y las tablas específicas por consulta son habituales porque las uniones generales no forman parte del modelo principal.

La replicación y el nivel de consistencia pueden configurarse por operación. En un quorum, la relación entre factor de replicación, réplicas requeridas para escritura y réplicas requeridas para lectura determina la probabilidad de observar la última versión. Sin embargo, consistencia configurable no elimina los límites de distribución ni garantiza semántica serializable para cualquier operación.

9. CONSISTENCIA Y TRANSACCIONES DISTRIBUIDAS

9.1. CAP correctamente interpretado

El teorema CAP formaliza que, en un sistema replicado sometido a una partición de red, no se pueden garantizar simultáneamente consistencia linealizable y disponibilidad para todas las operaciones. La tolerancia a particiones no es una función que se marque voluntariamente: si la red puede dividirse, el sistema debe decidir cómo responde. Un diseño CP puede rechazar o retrasar operaciones para preservar una única versión; un diseño AP puede responder y reconciliar después.

9.2. Consistencia fuerte, eventual y causal

La consistencia linealizable hace que cada operación parezca ocurrir instantáneamente entre su invocación y respuesta. La serializabilidad ordena transacciones como alguna ejecución secuencial, pero no impone por sí sola orden de tiempo real; la serializabilidad estricta combina ambos requisitos. La consistencia causal conserva relaciones causa-efecto, y la eventual garantiza que, sin nuevas actualizaciones, las réplicas convergerán.

«Eventual» no significa aleatoria ni incorrecta. Debe definirse cómo se versiona, propaga y resuelve conflicto. Last-write-wins depende de relojes y puede perder actualizaciones. Los relojes vectoriales, versiones, CRDT u operaciones conmutativas permiten estrategias más explícitas. En datos clínicos, una reconciliación silenciosa que descarte información puede ser inaceptable.

9.3. Commit distribuido y consenso

El two-phase commit coordina una transacción entre participantes. En la fase de preparación, cada participante asegura que podrá confirmar; en la fase de decisión, el coordinador ordena confirmar o abortar. Garantiza atomicidad, pero puede quedar bloqueado si el coordinador falla en un momento crítico. No debe confundirse con el protocolo de bloqueo de dos fases, que regula adquisición y liberación de bloqueos.

Los algoritmos de consenso, como familias Paxos o Raft, permiten acordar un valor o un líder pese a fallos bajo determinadas hipótesis. Consenso y commit resuelven problemas relacionados pero distintos. En arquitecturas de microservicios se usan patrones de saga, eventos y compensaciones para evitar una transacción global larga. La compensación no es un rollback físico: es una nueva operación de negocio que revierte o neutraliza efectos.

10. MOTORES Y ESTRUCTURAS DE INDEXACIÓN

10.1. Función y coste

Los índices son estructuras de datos auxiliares que optimizan el acceso a registros en una base de datos, funcionando análogamente a los índices de libros que permiten localizar rápidamente información específica sin necesidad de leer todo el contenido. Sin índices, una consulta que busca registros que satisfagan cierta condición requiere un escaneo completo de la tabla examinando cada registro secuencialmente, una operación cuyo tiempo crece linealmente con el tamaño de la tabla. Con un índice apropiado, la misma búsqueda puede ejecutarse en tiempo logarítmico o incluso constante, reduciendo dramáticamente el tiempo de respuesta.

Sin embargo, los índices no son gratuitos. Cada índice consume espacio de almacenamiento adicional, típicamente proporcional al tamaño de la columna o columnas indexadas multiplicado por el número de filas. Las operaciones de modificación de datos deben actualizar todos los índices relevantes además de los datos base, incrementando el tiempo de ejecución de INSERT, UPDATE y DELETE. La elección de qué columnas indexar requiere balance: indexar columnas frecuentemente utilizadas en condiciones de búsqueda mejora rendimiento de consultas, pero indexar todo degrada rendimiento de modificaciones sin beneficio proporcional.

El optimizador usa estadísticas de distribución, número de valores distintos, histogramas y correlación para estimar selectividad. Un índice existente no garantiza que vaya a usarse: si la consulta devuelve gran parte de la tabla, el escaneo secuencial puede ser más barato. Las estadísticas obsoletas producen planes deficientes, por lo que mantenimiento y observación forman parte de la indexación.

10.2. B-tree y B+

Los árboles B y su variante B+ son las estructuras de índice más utilizadas en bases de datos relacionales por sus características que los hacen ideales para almacenamiento secundario. Un árbol B es un árbol balanceado donde cada nodo puede contener múltiples claves y punteros, típicamente ajustado para que un nodo ocupe exactamente una página de disco. Esta propiedad minimiza el número de accesos a disco necesarios para localizar una clave, ya que cada nivel del árbol requiere solo una lectura de disco.

La estructura de un árbol B garantiza que permanece balanceado con todas las hojas al mismo nivel, asegurando que el tiempo de búsqueda es predecible y logarítmico en el número de claves. Las operaciones de inserción y eliminación mantienen automáticamente el balance mediante división de nodos que se llenan más allá de su capacidad o fusión de nodos que quedan por debajo del umbral mínimo de ocupación. El factor de ramificación, el número de hijos que puede tener cada nodo interno, es típicamente alto (cientos), resultando en árboles de poca altura incluso para bases de datos con millones o miles de millones de registros.

Los árboles B+ son una variante donde solo las hojas contienen punteros a los registros de datos reales, mientras los nodos internos contienen únicamente claves utilizadas para navegación. Además, las hojas están enlazadas secuencialmente formando una lista, facilitando recorridos ordenados eficientes. Esta estructura es particularmente ventajosa para consultas de rango que recuperan múltiples registros consecutivos según el orden del índice, ya que después de localizar el primer registro, los subsecuentes se obtienen recorrendo la lista enlazada de hojas sin necesidad de recorrer el árbol desde la raíz.

En los SGBD comerciales, la denominación exacta y la implementación varían, pero la familia B-tree es la opción general para igualdad, rangos, orden y prefijos compatibles. Un índice compuesto se ordena por sus columnas en la secuencia definida; por ello, el orden importa. Un índice que comienza por (centro_id, fecha) puede favorecer filtros por centro y por centro más fecha, pero no necesariamente una búsqueda solo por fecha.

10.3. Hash, bitmap e índices especializados

Las tablas hash proporcionan acceso de tiempo constante promedio a registros basándose en igualdad de clave, siendo ideales para búsquedas exactas pero no soportando eficientemente búsquedas de rango o ordenamiento. Una función hash mapea cada valor de clave a una posición en un matriz, denominada bucket, donde se almacena el puntero al registro. Las funciones hash buscan distribuir claves uniformemente entre buckets para minimizar colisiones donde múltiples claves mapean al mismo bucket.

Las colisiones se manejan mediante diversas técnicas. El encadenamiento almacena múltiples entradas que mapean al mismo bucket en una lista enlazada, simple de implementar pero con posible degradación de rendimiento si las listas crecen largas. El direccionamiento abierto busca el siguiente bucket disponible según alguna secuencia de prueba cuando el bucket objetivo está ocupado, eliminando sobrecoste de punteros pero complicando eliminaciones y potencialmente causando clustering primario.

Las tablas hash son particularmente valiosas para índices de claves primarias donde las búsquedas son predominantemente por igualdad exacta. Sin embargo, su incapacidad de soportar consultas de rango, ordenamiento, o búsquedas de prefijo limita su aplicabilidad general. Los SGBD frecuentemente implementan hash indexes como opción que los administradores pueden elegir cuando las características de acceso de una aplicación hacen apropiado el compromiso.

Los índices bitmap son especializados para columnas con baja cardinalidad, es decir, columnas que toman solo un pequeño número de valores distintos relativo al número de filas. Ejemplos típicos incluyen género (masculino/femenino), estado civil (soltero/casado/divorciado/viudo), o categoría de producto. Para cada valor distinto de la columna, se mantiene un bitmap con un bit por fila en la tabla, donde el bit está en 1 si la fila tiene ese valor y 0 en caso contrario.

Las ventajas de los índices bitmap son múltiples. El espacio es muy eficiente para columnas de baja cardinalidad, ya que el bitmap puede comprimirse significativamente. Las consultas con múltiples condiciones sobre columnas indexadas con bitmaps se evalúan eficientemente mediante operaciones bitwise AND, OR y NOT sobre los bitmaps correspondientes. Por ejemplo, encontrar clientes masculinos casados mayores de treinta años simplemente requiere AND de tres bitmaps. Las operaciones bitwise son extremadamente rápidas en hardware moderno, ejecutándose a nivel de instrucciones de máquina sobre múltiples bits simultáneamente.

Los índices invertidos asocian términos o elementos con las filas o documentos que los contienen. Son apropiados para texto, matrices y documentos compuestos. Los índices espaciales y estructuras como R-tree aceleran intersección, proximidad y contención geométrica. Los índices por bloques o resúmenes de rango son compactos para tablas muy grandes cuando existe correlación entre orden físico y valor.

10.4. LSM, filtros y amplificación

Los árboles LSM convierten escrituras aleatorias en escrituras secuenciales: acumulan cambios en memoria, los vuelcan a tablas inmutables y compactan niveles. Favorecen ingestión, pero introducen amplificación de escritura, lecturas entre varios componentes y costes de compactación. Los filtros Bloom permiten descartar con rapidez archivos que con certeza no contienen una clave; pueden dar falsos positivos, nunca falsos negativos si están correctamente implementados.

10.5. Motores de indexación y búsqueda

Un motor de búsqueda como los basados en Lucene construye índices invertidos, analiza texto, calcula relevancia y ofrece agregaciones. El proceso incluye tokenización, normalización, filtros lingüísticos y segmentación. Suele ser casi en tiempo real: un documento confirmado en el sistema fuente puede tardar un intervalo en ser visible en búsqueda.

El índice de búsqueda no debe convertirse sin diseño explícito en la única fuente de verdad. Las reindexaciones, cambios de analizador y pérdida de segmentos exigen poder reconstruirlo desde un sistema autoritativo. La sincronización puede realizarse mediante eventos, captura de cambios o procesos por lotes, con controles de idempotencia y retraso.

CREATE INDEX idx_cita_centro_fecha
ON cita (centro_id, fecha);

EXPLAIN
SELECT fecha, estado
FROM cita
WHERE centro_id = 42
  AND fecha >= DATE '2026-08-01';

11. MODELO DE REFERENCIA ANSI/X3/SPARC

11.1. Tres niveles

El modelo de referencia ANSI-SPARC, desarrollado en 1975 por el comité de estándares ANSI (American National Standards Institute) y el grupo SPARC (Standards Planning and Requirements Committee), define una arquitectura de tres niveles para sistemas de bases de datos que proporciona independencia de datos, un principio fundamental que separa cómo se definen, almacenan y visualizan los datos. Esta arquitectura de tres esquemas distingue el nivel externo, el nivel conceptual y el nivel interno, cada uno con propósito y audiencia distintos.

El nivel externo o de vistas define múltiples vistas de usuario que representan diferentes perspectivas de la base de datos adaptadas a necesidades de grupos de usuarios específicos. Cada vista puede incluir un subconjunto de los datos, presentar los datos en formato diferente al almacenado físicamente, derivar datos calculados a partir de datos base, u ocultar detalles de complejidad irrelevantes para usuarios particulares. Por ejemplo, un departamento de ventas podría tener una vista que muestra solo información de clientes y órdenes relevante para su función, mientras el departamento de contabilidad tiene una vista diferente enfocada en facturación y pagos.

El nivel conceptual o lógico describe la estructura completa de toda la base de datos para la comunidad de usuarios, independiente de consideraciones de almacenamiento físico. El esquema conceptual especifica qué entidades existen, qué atributos tienen, qué relaciones existen entre entidades, y qué restricciones de integridad deben mantenerse. En bases de datos relacionales, el esquema conceptual define las tablas, sus columnas con tipos de datos, claves primarias y foráneas, y restricciones como NOT NULL, UNIQUE, o CHECK. Este nivel representa «qué» datos se almacenan sin especificar «cómo».

El nivel interno o físico describe cómo se almacenan físicamente los datos en medios de almacenamiento, incluyendo estructuras de archivos utilizadas, organización de registros dentro de páginas, índices implementados con sus estructuras de datos específicas, clustering de registros relacionados, y técnicas de compresión aplicadas. Este nivel está oculto a usuarios y aplicaciones, siendo dominio exclusivo del SGBD y sus administradores.

El informe ANSI/X3/SPARC de 1975 propuso este marco como arquitectura de referencia. Su terminología tuvo una influencia duradera, aunque no debe confundirse con el estándar SQL ni afirmarse que todos los SGBD implementan literalmente cada nivel. Es un modelo para razonar sobre separación y dependencias.

11.2. Independencia física y lógica

La arquitectura de tres esquemas facilita dos tipos de independencia de datos que son objetivos fundamentales del diseño de SGBD. La independencia de datos lógica es la capacidad de cambiar el esquema conceptual sin necesidad de cambiar esquemas externos o reescribir programas de aplicación. Ejemplos incluyen añadir nuevas tablas para nuevas funcionalidades, añadir columnas a tablas existentes para información adicional, o modificar restricciones de integridad. Siempre que las vistas existentes puedan derivarse del esquema conceptual modificado, las aplicaciones continúan funcionando sin cambios.

La independencia de datos física es la capacidad de cambiar el esquema interno sin modificar el esquema conceptual o externo. Ejemplos incluyen reorganizar archivos de datos para mejorar rendimiento, crear o eliminar índices para optimizar consultas específicas, cambiar entre diferentes estructuras de almacenamiento, o mover datos a dispositivos de almacenamiento diferentes. Estas optimizaciones mejoran rendimiento sin requerir cambios en aplicaciones, permitiendo ajuste continuo sin impacto en desarrollo de software.

La independencia física suele ser más alcanzable: cambiar organización de archivos, añadir índices, mover particiones o modificar compresión no debería alterar la interfaz lógica. La independencia lógica es más difícil, porque retirar o redefinir entidades puede afectar a vistas y programas. Las vistas, capas de compatibilidad y APIs versionadas reducen el impacto, pero no eliminan una ruptura semántica.

11.3. Correspondencias entre esquemas

Las correspondencias entre niveles traducen peticiones y datos entre niveles de abstracción. La correspondencia conceptual-interna traduce consultas expresadas en términos del esquema conceptual a operaciones de acceso físico, determinando qué índices utilizar, cómo recorrer estructuras de datos y en qué orden acceder a archivos. El optimizador de consultas del SGBD participa en este proceso generando planes de ejecución eficientes.

La correspondencia externo-conceptual traduce consultas sobre vistas a consultas sobre el esquema conceptual base. Cuando un usuario consulta una vista que deriva información de múltiples tablas o calcula valores, el SGBD expande la consulta sobre la vista a operaciones sobre las estructuras subyacentes. Por ejemplo, si una vista define una unión de tres tablas con determinados filtros, una consulta SELECT sobre la vista se transforma en una consulta equivalente sobre las tablas base incorporando las uniones y predicados definidos.

La correspondencia externo-conceptual traduce una vista de usuario al modelo global. La conceptual-interna traduce operaciones y estructuras lógicas a registros, páginas e índices. El procesador de consultas y el catálogo materializan gran parte de estas correspondencias en los SGBD modernos.

12. MONITOR DE TRANSACCIONES Y PROPIEDADES ACID

12.1. Unidad lógica de trabajo

Una transacción es una unidad lógica de trabajo que puede comprender múltiples operaciones de base de datos pero se trata como una unidad atómica indivisible. La transacción completa se ejecuta exitosamente alcanzando un nuevo estado consistente, o falla completamente sin efectos persistentes dejando la base de datos en su estado previo. Este concepto de atomicidad es fundamental para mantener integridad de datos en presencia de concurrencia y fallos.

Consideremos un ejemplo clásico de transferencia bancaria donde se transfieren cien euros de la cuenta A a la cuenta B. Esta operación conceptualmente simple requiere dos actualizaciones de base de datos: restar cien de la cuenta A e incrementar cien en la cuenta B. Es imperativo que ambas operaciones sucedan o ninguna suceda. Si el sistema falla después de restar de A pero antes de incrementar B, se habrían perdido cien euros. Si solo B se incrementa sin decrementar A, se habría creado dinero de la nada. La transacción garantiza que esta secuencia de operaciones es atómica.

Las transacciones se delimitan explícitamente mediante comandos BEGIN TRANSACTION para iniciar, COMMIT para confirmar exitosamente y persistir cambios, o ROLLBACK para abortar y deshacer todos los cambios. Algunas bases de datos operan en modo autocommit donde cada sentencia SQL individual se trata como transacción implícita que se confirma automáticamente si tiene éxito.

BEGIN;
UPDATE cuenta SET saldo = saldo - 100.00 WHERE cuenta_id = 10;
UPDATE cuenta SET saldo = saldo + 100.00 WHERE cuenta_id = 20;
COMMIT;

La transacción debe ser corta, determinista y reintentable cuando el motor pueda abortarla por conflicto. Mantenerla abierta durante interacción humana retiene versiones, memoria o bloqueos y aumenta el riesgo de espera. En aplicaciones con pool de conexiones, es imprescindible devolver la conexión con estado limpio y no confundir transacción de aplicación con sesión.

12.2. ACID

El acrónimo ACID describe cuatro propiedades que las transacciones deben garantizar para mantener integridad de datos: Atomicidad, Consistencia, Aislamiento y Durabilidad. Estas propiedades fueron formuladas de manera clásica en la literatura de procesamiento transaccional y constituyen una referencia fundamental para los sistemas de bases de datos.

La Atomicidad garantiza que una transacción es una unidad indivisible de trabajo: toda se completa o nada se completa. Si cualquier operación dentro de la transacción falla, todas las operaciones previas deben deshacerse mediante rollback. La implementación de atomicidad se apoya en mecanismos de registro y recuperación que permiten revertir cambios cuando una transacción aborta.

La Consistencia garantiza que una transacción transforma la base de datos de un estado consistente a otro estado consistente, preservando las restricciones de integridad declaradas y los invariantes que la propia lógica transaccional debe respetar. Es responsabilidad tanto del SGBD verificar restricciones automáticamente como de los programadores escribir transacciones correctas. Por ejemplo, en un sistema de inventario, una transacción que vende productos debe decrementar el stock y el SGBD puede verificar que el stock resultante no sea negativo si existe una restricción que así lo establezca.

El Aislamiento busca que las transacciones concurrentes no produzcan interferencias incompatibles con el nivel de aislamiento elegido. En el nivel más fuerte, una ejecución concurrente debe ser equivalente a alguna ejecución serial. Niveles inferiores permiten determinados fenómenos a cambio de mayor concurrencia.

La Durabilidad garantiza que, una vez confirmado un COMMIT, los cambios sobreviven a fallos posteriores contemplados por el modelo de recuperación. Habitualmente se apoya en almacenamiento no volátil y técnicas de write-ahead logging antes de considerar confirmada la operación.

La consistencia de ACID no significa que el SGBD conozca todas las reglas de negocio. Garantiza que las reglas declaradas y la lógica de la transacción se respeten; una transacción puede confirmar datos semánticamente erróneos si ninguna restricción los detecta. El aislamiento tampoco implica siempre serialización completa: el nivel elegido determina anomalías permitidas.

12.3. Estados y puntos de salvaguarda

Una transacción progresa a través de varios estados durante su ciclo de vida. El estado activo es el estado inicial donde la transacción está ejecutando sus operaciones. Mientras está activa, la transacción lee y escribe datos según las reglas de visibilidad del SGBD. El estado parcialmente comprometido se alcanza conceptualmente cuando la última operación se ha ejecutado pero aún falta completar la confirmación durable.

El estado comprometido se alcanza cuando la transacción completa exitosamente y COMMIT se procesa. El estado fallido se alcanza cuando se determina que la transacción no puede continuar normalmente, ya sea porque una operación falló, se violó una restricción de integridad o el sistema detectó un conflicto que obliga a abortar. El estado abortado se alcanza después de revertir los efectos de la transacción fallida conforme al mecanismo de recuperación.

Un SAVEPOINT permite deshacer una parte sin abortar toda la transacción. No equivale a una copia de seguridad ni a un checkpoint de recuperación. Las transacciones preparadas de un commit distribuido constituyen otro concepto: han asegurado recursos y esperan una decisión global.

12.4. Funciones del monitor de transacciones

El monitor recibe solicitudes, establece contexto, asigna recursos, coordina participantes, aplica límites, registra actividad y decide confirmación o aborto. En entornos clásicos puede incluir un TP monitor que administra sesiones, colas, procesos y balanceo entre aplicaciones y gestores de recursos. Dentro del SGBD, el gestor transaccional colabora con planificador, control de concurrencia, buffer y recuperación.

En una operación distribuida, el coordinador debe conocer participantes y protocolo de commit. En una arquitectura de servicios, el límite transaccional debe coincidir con la propiedad del dato siempre que sea posible. Extender ACID a múltiples servicios independientes aumenta acoplamiento y reduce disponibilidad.

13. CONTROL DE CONCURRENCIA, AISLAMIENTO Y MVCC

13.1. Anomalías

Cuando múltiples transacciones ejecutan concurrentemente accediendo y modificando los mismos datos, pueden surgir anomalías que violan el aislamiento y comprometen la consistencia de la base de datos. Es crucial entender estos problemas para apreciar la necesidad y complejidad de los mecanismos de control de concurrencia.

La lectura sucia (dirty read) ocurre cuando una transacción lee datos modificados por otra transacción que aún no ha confirmado. Si la segunda transacción posteriormente aborta, la primera habrá leído datos que nunca deberían haber existido en un estado confirmado, potencialmente tomando decisiones basadas en información inválida.

La lectura no repetible (non-repeatable read) ocurre cuando una transacción lee el mismo dato dos veces y obtiene valores diferentes porque otra transacción modificó y confirmó el dato entre las dos lecturas. Esto viola la expectativa de estabilidad de una lectura dentro de determinados niveles de aislamiento.

La lectura fantasma (phantom read) se refiere a conjuntos de filas: una transacción ejecuta una consulta que devuelve filas que satisfacen un predicado, otra transacción inserta, elimina o modifica filas afectando a dicho predicado y, al repetir la primera consulta, aparecen o desaparecen filas.

La pérdida de actualización (lost update) ocurre cuando dos transacciones leen un mismo estado y sus escrituras posteriores hacen que una actualización sobrescriba indebidamente a la otra. Es una anomalía especialmente relevante en operaciones de reserva, contadores o modificación de estados compartidos.

También debe considerarse el write skew: dos transacciones leen una condición común y actualizan filas distintas, dejando violado un invariante que no estaba materializado en una única fila. Puede ocurrir bajo aislamiento por instantánea aunque no haya actualización perdida. Evitarlo exige serializable, bloqueo explícito, restricción materializada o rediseño.

13.2. Niveles de aislamiento

El estándar SQL define niveles de aislamiento que representan distintos compromisos entre aislamiento y concurrencia. La implementación exacta y los fenómenos adicionales que pueden aparecer dependen del SGBD, por lo que las aplicaciones críticas deben conocer el comportamiento concreto del producto.

READ UNCOMMITTED es el nivel más permisivo. READ COMMITTED garantiza que no se lean escrituras no confirmadas y es común en muchos sistemas. REPEATABLE READ busca estabilizar las lecturas realizadas dentro de la transacción. SERIALIZABLE exige que el efecto observable sea equivalente a alguna ejecución secuencial de las transacciones, aunque el motor puede lograrlo con bloqueos, serialización optimista, SSI u otros mecanismos.

La denominación de un nivel no basta para deducir toda la implementación. Un motor puede usar bloqueos, MVCC o snapshot isolation y ofrecer garantías adicionales. Las aplicaciones deben consultar documentación, probar escenarios y gestionar errores de serialización mediante reintento de la transacción completa.

13.3. Bloqueos, marcas temporales y validación

Los SGBD implementan control de concurrencia mediante varias familias de técnicas. Los protocolos basados en bloqueos previenen determinadas interferencias reservando recursos; los basados en marcas temporales imponen un orden lógico; el control optimista permite avanzar y valida antes de confirmar; y MVCC administra múltiples versiones visibles según la instantánea.

Un bloqueo compartido permite lecturas compatibles entre varias transacciones, mientras que un bloqueo exclusivo protege una modificación frente a accesos incompatibles. Las matrices exactas de compatibilidad dependen de los modos de bloqueo del producto.

El protocolo de bloqueo de dos fases (two-phase locking o 2PL) presenta una fase de crecimiento en la que se adquieren bloqueos y una fase de decrecimiento en la que se liberan. Bajo las hipótesis apropiadas, 2PL produce planificaciones conflict-serializable. Variantes como strict 2PL retienen determinados bloqueos hasta la confirmación o aborto y simplifican la recuperación.

El orden por marcas temporales asigna prioridad lógica y rechaza operaciones incompatibles con ese orden; al no esperar por bloqueos, evita ciclos de espera, aunque puede abortar y reiniciar. El control optimista ejecuta sin bloquear y valida al final; funciona bien cuando los conflictos son raros. Cuando son frecuentes, el coste de reintentos puede superar al pesimista.

13.4. MVCC

El control multiversión mantiene varias versiones y determina cuál es visible según la instantánea. Los lectores pueden no bloquear a escritores y viceversa, mejorando concurrencia. Sin embargo, las versiones antiguas ocupan espacio y deben limpiarse cuando ninguna transacción las necesita. Una transacción de larga duración puede impedir la reutilización y producir crecimiento.

MVCC no elimina todos los bloqueos. Las escrituras concurrentes sobre la misma fila, los cambios de esquema, las restricciones o los bloqueos explícitos siguen generando esperas. Tampoco garantiza por sí solo serializabilidad: depende de reglas de visibilidad y detección de conflictos.

14. BLOQUEOS, GRANULARIDAD E INTERBLOQUEOS

14.1. Modos y granularidad

Los bloqueos pueden aplicarse a diferentes niveles de granularidad en la jerarquía de datos: toda la base de datos, un archivo o tablespace, una tabla, una página o una fila. La granularidad apropiada implica compromisos entre sobrecoste de gestión y concurrencia. Los bloqueos de grano grueso son más simples de administrar, pero reducen la concurrencia. Los de grano fino permiten que más transacciones trabajen simultáneamente, aunque el SGBD debe gestionar un número mayor de bloqueos.

El bloqueo multi-granular permite que transacciones bloqueen a distintas granularidades simultáneamente utilizando bloqueos de intención. Estos indican que una transacción mantiene o pretende mantener bloqueos de menor granularidad dentro de una estructura superior, facilitando la comprobación de compatibilidad.

Un bloqueo compartido permite lecturas compatibles; uno exclusivo protege una modificación. Los bloqueos de intención anuncian bloqueos más finos dentro de una jerarquía y permiten comprobar compatibilidad sin recorrer todas las filas. Algunos motores pueden escalar muchos bloqueos finos a uno grueso para reducir sobrecarga, sacrificando concurrencia.

14.2. Protocolo de dos fases

En 2PL existe una fase creciente, donde se adquieren bloqueos y no se liberan, y una decreciente, donde se liberan y no se adquieren nuevos. Variantes estrictas mantienen ciertos bloqueos hasta COMMIT o ROLLBACK, evitando que otras transacciones dependan de escrituras no confirmadas. El uso de bloqueos puede producir interbloqueos cuando varias transacciones esperan recursos en órdenes incompatibles.

14.3. Detección, prevención y resolución

Un deadlock ocurre cuando dos o más transacciones están esperando mutuamente recursos que las otras mantienen, formando un ciclo del que ninguna puede progresar. Por ejemplo, T1 mantiene A y espera B mientras T2 mantiene B y espera A.

Los SGBD pueden manejar interbloqueos mediante prevención, evitación, detección y resolución. La prevención impone reglas para impedir determinadas condiciones; la detección permite que el ciclo llegue a formarse y lo identifica después. Un mecanismo habitual de detección utiliza un grafo de espera donde los nodos son transacciones y una arista T1 → T2 indica que T1 espera un recurso retenido por T2. Un ciclo evidencia un interbloqueo bajo ese modelo.

La prevención incluye adquirir recursos en orden global, limitar esperas o usar reglas basadas en la antigüedad de las transacciones, como wait-die y wound-wait. Un timeout no demuestra que exista deadlock: puede abortar una espera larga sin ciclo. Cuando se detecta un ciclo, el motor elige una víctima, revierte su trabajo y libera recursos.

14.4. Diseño de aplicaciones

El control de concurrencia optimista asume que los conflictos son relativamente infrecuentes. Permite realizar trabajo y, antes de confirmar, valida que los datos relevantes no hayan cambiado de forma incompatible. Si la validación tiene éxito, confirma; si falla, aborta y normalmente reintenta la unidad de trabajo.

Este enfoque funciona bien en cargas con baja contención porque evita el coste de mantener bloqueos prolongados. En escenarios de alta contención puede desperdiciar trabajo debido a numerosos abortos y reintentos.

Las transacciones deben acceder a tablas y filas en un orden coherente, evitar operaciones externas durante el commit y mantener lotes razonables. El tratamiento correcto de un deadlock es abortar una víctima y reintentar toda la unidad de trabajo de forma idempotente. Repetir solo la última sentencia puede violar la lógica porque la instantánea y las decisiones anteriores ya no son válidas.

15. RECUPERACIÓN DE ERRORES, LOG Y COPIAS

15.1. Tipos de fallo

Los sistemas de bases de datos deben ser resilientes ante diversos tipos de fallos. Los fallos de transacción afectan a una unidad de trabajo concreta por errores lógicos, violaciones de restricciones o conflictos. Los fallos de sistema incluyen caídas del proceso, del sistema operativo o pérdida de memoria volátil. Los fallos de medio afectan al almacenamiento persistente y pueden requerir restauración desde copias o réplicas adecuadamente protegidas.

También existen fallos de comunicación, errores humanos, corrupción lógica y fallos regionales. La alta disponibilidad resuelve indisponibilidad de componentes, pero puede replicar una eliminación o corrupción. Por eso se combinan redundancia, log, copias inmutables, pruebas de restauración y procedimientos operativos.

15.2. Write-ahead logging

WAL establece que la información de log necesaria para recuperar una modificación debe llegar a almacenamiento estable antes que la página de datos correspondiente. Para declarar durabilidad, el registro de commit requerido debe persistirse conforme a la política del motor. Esta separación permite modificar páginas en memoria y escribirlas después sin perder la capacidad de rehacer cambios confirmados.

No todos los logs guardan una imagen anterior y posterior completa. Pueden registrar operaciones lógicas, cambios físicos o fisiológicos, identificadores de página y secuencias. Algunos motores usan log de redo junto con undo separado o versiones MVCC. Lo esencial es que el algoritmo disponga de información suficiente para restaurar un estado correcto.

ARIES organiza la recuperación en análisis, redo y undo. El análisis reconstruye el estado al fallo; redo repite acciones desde un punto seguro, incluso algunas de transacciones luego abortadas; y undo revierte transacciones perdedoras mediante registros compensatorios. La idempotencia del redo permite aplicar de nuevo una acción sin duplicar su efecto cuando la página ya contiene una versión igual o posterior.

15.3. Checkpoints y recuperación tras caída

Un checkpoint limita el trabajo que debe examinarse, registra posiciones y estado y coordina el avance del log. En un checkpoint difuso no se detiene toda la actividad ni se garantiza que todas las páginas sucias queden escritas en ese instante. El motor conserva metadatos que permiten iniciar la recuperación en una posición adecuada y completar redo.

Checkpoints demasiado frecuentes generan picos de E/S; demasiado espaciados alargan recuperación y aumentan el log necesario. El ajuste debe alinearse con RTO, capacidad de almacenamiento y carga. El log también puede archivarse para recuperación a un punto en el tiempo y alimentar réplicas o captura de cambios, pero cada uso tiene requisitos de retención y seguridad.

15.4. Copias, PITR y pruebas

Los mecanismos de recuperación basados en logs protegen principalmente frente a fallos transaccionales o del sistema, pero para pérdida de almacenamiento, corrupción extensa, error humano o necesidad de regresar a un estado anterior se requieren copias de seguridad y una estrategia de recuperación.

Una copia completa captura el conjunto de datos necesario para una restauración de base. Las copias incrementales almacenan cambios respecto a un punto anterior definido por la tecnología, mientras las diferenciales suelen referirse a cambios desde una copia completa de referencia. La terminología exacta y el procedimiento de restauración dependen del producto, por lo que deben seguirse los mecanismos soportados por el SGBD.

Para recuperar hasta un punto posterior a la copia base, el sistema puede restaurar dicha copia y reproducir los logs archivados hasta una posición o instante determinado. El objetivo de punto de recuperación (RPO) expresa cuánta pérdida de datos es admisible y el objetivo de tiempo de recuperación (RTO) cuánto tiempo puede estar indisponible el servicio.

Una copia válida debe ser coherente con el log y con el método del SGBD. Copiar archivos abiertos sin mecanismo soportado puede producir un conjunto imposible de recuperar. La recuperación a un punto en el tiempo restaura una copia base y reproduce log hasta una marca temporal o posición anterior al incidente.

La réplica no es una copia de seguridad: replica con rapidez errores lógicos, borrados y cifrado malicioso. Las copias deben estar separadas, protegidas, inventariadas y probadas. Una prueba verifica no solo que el archivo existe, sino que la aplicación arranca, las restricciones son correctas, los usuarios autorizados acceden y los tiempos cumplen objetivos.

16. INTEGRIDAD, CALIDAD Y GOBIERNO DEL DATO

16.1. Restricciones declarativas

Las restricciones de integridad son reglas que definen qué estados de la base de datos son válidos, garantizando que los datos almacenados satisfacen requisitos estructurales y de negocio declarados. Los SGBD relacionales permiten expresar distintos tipos de restricciones como parte del esquema y verificarlas automáticamente.

Las restricciones de dominio especifican qué valores son permitidos para un atributo. El tipo de dato es la restricción de dominio más básica. Restricciones adicionales incluyen NOT NULL para impedir nulos cuando no son admisibles, DEFAULT para proporcionar un valor predeterminado y CHECK para validar expresiones sobre los datos.

Las restricciones de clave garantizan unicidad y proporcionan mecanismos de referencia. Una clave primaria PRIMARY KEY identifica unívocamente cada fila e implica ausencia de nulos en sus componentes. UNIQUE declara unicidad conforme a la semántica del estándar y del producto. Una clave foránea FOREIGN KEY exige que los valores referenciados correspondan a una clave candidata válida de la relación de destino, con el tratamiento de NULL sujeto a la definición de la restricción.

CREATE TABLE Clientes (
    cliente_id INTEGER PRIMARY KEY,
    nombre VARCHAR(100) NOT NULL,
    email VARCHAR(100) UNIQUE,
    edad INTEGER CHECK (edad >= 18),
    fecha_registro DATE DEFAULT CURRENT_DATE
);

CREATE TABLE Pedidos (
    pedido_id INTEGER PRIMARY KEY,
    cliente_id INTEGER NOT NULL,
    fecha_pedido DATE NOT NULL,
    total DECIMAL(10,2) CHECK (total >= 0),
    FOREIGN KEY (cliente_id) REFERENCES Clientes(cliente_id)
        ON DELETE RESTRICT
        ON UPDATE CASCADE
);

La integridad de entidad exige que cada fila sea identificable; la referencial evita referencias huérfanas; la de dominio limita valores; y las reglas de negocio expresan invariantes más complejos. Las restricciones declarativas son preferibles a validaciones duplicadas en cada aplicación porque se aplican a todos los caminos de escritura que pasan por el SGBD.

16.2. Acciones referenciales

Las restricciones de clave foránea pueden especificar acciones referenciales que determinan qué sucede cuando se modifica o elimina una fila referenciada. ON DELETE CASCADE propaga la eliminación a las filas dependientes; SET NULL elimina la referencia cuando el modelo lo permite; y RESTRICT o NO ACTION impiden o posponen una operación incompatible según la semántica aplicable.

CASCADE debe usarse cuando la dependencia semántica lo justifica y su alcance es comprendido. En una jerarquía extensa puede eliminar muchas filas y bloquear recursos. SET NULL exige que la columna admita nulos y que la ausencia de relación sea válida. Las diferencias exactas entre RESTRICT y NO ACTION pueden depender del soporte de restricciones diferibles y del producto.

16.3. Triggers, aserciones y lógica de aplicación

Las aserciones del estándar SQL permiten conceptualmente expresar restricciones generales sobre el estado de la base de datos, aunque su soporte práctico en productos comerciales es limitado. Los triggers, por su parte, son acciones que se ejecutan automáticamente ante determinados eventos como INSERT, UPDATE o DELETE.

Los triggers permiten implementar reglas complejas, mantener información derivada o registrar cambios, pero deben usarse con prudencia. La lógica implícita puede dificultar depuración, introducir recursión, aumentar la duración de las transacciones y producir interacciones complejas con concurrencia.

Una regla crítica debe documentarse, observarse y probarse con concurrencia, no solo con casos secuenciales.

CREATE TABLE cita (
  cita_id BIGINT PRIMARY KEY,
  paciente_id BIGINT NOT NULL,
  fecha_hora TIMESTAMP NOT NULL,
  estado VARCHAR(20) NOT NULL,
  CONSTRAINT ck_cita_estado
    CHECK (estado IN ('PROGRAMADA', 'ATENDIDA', 'CANCELADA'))
);

16.4. Integridad no es seguridad ni calidad

Integridad de base de datos describe estados válidos y modificaciones controladas. Seguridad añade autenticación, autorización, cifrado, segregación y auditoría. Calidad incorpora exactitud, completitud, actualidad, unicidad y coherencia semántica. Un valor puede cumplir tipo y clave foránea y seguir siendo clínicamente incorrecto; por eso se necesitan validaciones de origen, reconciliación y responsables.

En sistemas asistenciales del SAS, errores de identidad, duplicados, estados incompatibles o referencias rotas pueden afectar continuidad y explotación. El diseño debe combinar claves estables, restricciones, transacciones, trazabilidad, controles de acceso y procedimientos de corrección. La base de datos no debe permitir que una corrección destruya la evidencia histórica necesaria para auditoría.

16.5. Operación y observabilidad

El gobierno operativo monitoriza latencia, bloqueos, abortos, crecimiento, retraso de réplica, uso de índices, errores de restricción, tamaño del log y éxito de copias. Las alertas deben relacionarse con objetivos de servicio. Un aumento de deadlocks puede indicar un cambio de patrón; un retraso de réplica afecta lecturas; estadísticas obsoletas degradan planes; y una transacción larga puede retener versiones.

17. APLICACIÓN EN EL SAS, OPERACIÓN E IDEAS CLAVE

17.1. El SGBD como infraestructura transversal del SSPA

En el Servicio Andaluz de Salud, las bases de datos no deben entenderse como un producto aislado, sino como una infraestructura transversal que sostiene sistemas asistenciales, administrativos, logísticos, de recursos humanos, integración, portales y explotación de información. Un registro de paciente, una cita, una petición diagnóstica, un episodio, una orden de suministro o una incidencia de soporte terminan materializándose en estructuras persistentes que deben conservar identidad, trazabilidad, integridad y disponibilidad. El técnico A2 no necesita memorizar qué motor concreto utiliza cada subsistema si esa información no está documentada y vigente; sí debe comprender qué requisitos condicionan el diseño y la operación: transacciones cortas, claves estables, restricciones, índices adecuados, recuperación probada, seguridad, monitorización y procedimientos de cambio.

En sanidad, además, el dato tiene una vida útil mucho más larga que una pantalla o una versión de aplicación. Un cambio de interfaz puede desplegarse en días, mientras que la información clínica y administrativa debe seguir siendo interpretable, trazable y coherente durante años. Esto refuerza el valor de la independencia de datos de ANSI/SPARC, de los contratos de esquema, de la documentación de metadatos y de la separación entre modelo lógico y detalles físicos. Añadir un índice, mover una partición o sustituir almacenamiento no debería obligar a alterar el significado de un episodio o de un identificador corporativo.

17.2. Patrones operativos que debes reconocer

Los patrones OLTP de alta concurrencia requieren especial cuidado con el tamaño de las transacciones, el orden de acceso a recursos y el nivel de aislamiento. Una transacción que mantiene bloqueos mientras espera una respuesta de usuario o de un servicio externo amplía artificialmente la ventana de contención. En cambio, una operación bien delimitada valida sus precondiciones, modifica el mínimo conjunto de datos, confirma o revierte y devuelve la conexión al pool en un estado conocido. Cuando el motor puede abortar por deadlock o conflicto de serialización, la aplicación debe poder reintentar la unidad lógica completa, no únicamente la última sentencia.

Los sistemas de lectura intensiva pueden utilizar réplicas, cachés o índices especializados, pero esas optimizaciones introducen semántica adicional. Una réplica asíncrona puede presentar retraso; una caché puede contener una versión anterior; un índice invertido puede actualizarse con otra cadencia que la base transaccional. Por eso el diseño debe dejar claro cuál es la fuente autoritativa y qué grado de obsolescencia tolera cada operación. Consultar un catálogo informativo admite compromisos distintos a confirmar una prescripción, una cita o un movimiento económico.

En integración entre aplicaciones, una base federada, una vista, un enlace entre bases o una capa de virtualización pueden simplificar el acceso, pero también crean dependencias remotas. El fallo de una fuente, un cambio de esquema o una consulta distribuida costosa puede propagarse a consumidores que parecían independientes. En arquitecturas modernas suele ser preferible definir contratos de servicio y propiedad clara del dato, reservando el acceso directo entre bases para casos controlados, gobernados y observables.

17.3. Seguridad, integridad y trazabilidad

La seguridad del SGBD complementa, pero no sustituye, la integridad. La autenticación responde a quién accede; la autorización, a qué puede hacer; el cifrado, a cómo se protege la confidencialidad; la auditoría, a qué ocurrió; y las restricciones, a qué estados son válidos. En un entorno sanitario estas capas deben combinarse. Dar a una cuenta técnica privilegios excesivos para «evitar errores» elimina barreras que precisamente limitan el impacto de un defecto o una credencial comprometida. Del mismo modo, almacenar un valor cifrado no impide que sea semánticamente incorrecto o que viole una clave foránea.

La trazabilidad exige conservar suficiente evidencia para reconstruir cambios significativos. No equivale a guardar indefinidamente cualquier log técnico: deben definirse finalidad, contenido, acceso y conservación. Desde la perspectiva del SGBD, son relevantes la identificación de la transacción, las operaciones realizadas, los errores de restricción, los abortos, los bloqueos prolongados y los eventos de recuperación. Desde la perspectiva funcional, se necesitan además responsables, motivo de corrección y reglas para no destruir el histórico que deba preservarse.

17.4. Disponibilidad y recuperación verificable

En servicios críticos, la disponibilidad no se diseña únicamente añadiendo nodos. Debes diferenciar alta disponibilidad de copia de seguridad y de recuperación ante desastres. La alta disponibilidad intenta reducir la interrupción ante fallos de componentes; la copia conserva puntos recuperables frente a borrado, corrupción o error lógico; la recuperación ante desastres define cómo reconstruir el servicio cuando falla un ámbito completo. Una réplica puede propagar inmediatamente un borrado incorrecto, mientras una copia versionada permite retroceder a un estado anterior.

Los objetivos RPO y RTO ayudan a convertir necesidades de negocio en decisiones técnicas. El RPO expresa cuánta información se acepta perder como máximo, medido en tiempo respecto al último punto recuperable; el RTO expresa cuánto puede durar la indisponibilidad antes de restablecer el servicio. No existe una tecnología universal que garantice ambos objetivos sin coste. Una estrategia madura combina WAL o redo, checkpoints, copias completas e incrementales cuando proceda, replicación, procedimientos de restauración y pruebas periódicas.

17.5. Ideas clave para el repaso

Para resolver preguntas tipo test, organiza el tema en pares que suelen confundirse. Centralizado significa coordinación principal en un único sistema; distribuido reparte datos o procesamiento bajo un sistema lógico; federado integra fuentes que conservan autonomía. Particionar divide el conjunto de datos; replicar mantiene copias. Wide-column describe un modelo distribuido por familias de columnas; columnar analítico describe organización física orientada a escaneos y agregaciones.

En transacciones, recuerda ACID, pero entiende cada letra. Atomicidad evita resultados parciales; consistencia conserva las reglas declaradas y los invariantes de la transacción; aislamiento controla lo que unas transacciones pueden observar de otras; durabilidad protege lo confirmado frente a fallos. 2PL es un protocolo de bloqueo para serializabilidad; 2PC es un protocolo de confirmación distribuida. MVCC gestiona versiones para reducir conflictos de lectura, pero no elimina todos los bloqueos ni todas las anomalías.

En indexación, un B-tree/B+ tree es la respuesta habitual para igualdad y rangos ordenados; hash favorece igualdad exacta, no recorridos por rango; un índice invertido asocia términos con documentos; Bloom descarta con seguridad ciertos ausentes pero puede producir falsos positivos. En recuperación, WAL exige registrar la información necesaria antes de que las páginas de datos dependientes se consideren persistidas; el checkpoint acorta el trabajo de recuperación, no sustituye al log; y backup, réplica y snapshot no son sinónimos.

18. MAPA CONCEPTUAL

El mapa debe leerse como un sistema de compromisos. El modelo determina operaciones naturales; la arquitectura determina coordinación y fallos; los índices condicionan acceso; las transacciones e integridad protegen invariantes; y recuperación y gobierno permiten sostener el servicio durante todo el ciclo de vida.