TEMA 72

Los Sistemas de Gestión de Bases de Datos

SGBD, Arquitecturas, NoSQL, Transacciones y Control de Concurrencia

1. Introducción a los Sistemas de Gestión de Bases de Datos

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. Funciones Fundamentales de un SGBD

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.

1.2. Componentes de un SGBD

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.

2. Modelos de Datos y Arquitecturas

2.1. Bases de Datos Centralizadas

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 backups, actualizaciones de software, tunning 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 workloads entre múltiples máquinas.

2.2. Bases de Datos Distribuidas

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.

2.3. Bases de Datos Federadas

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 reporting 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.

3. Bases de Datos No Relacionales (NoSQL)

3.1. Introducción al Movimiento NoSQL

El término NoSQL, que originalmente significaba «No SQL» pero ha evolucionado a interpretarse como «Not Only SQL», emergió a finales de la década de 2000 como respuesta a las limitaciones de las bases de datos relacionales tradicionales para ciertos casos de uso específicos característicos de aplicaciones web a gran escala. Empresas como Google, Amazon y Facebook enfrentaban desafíos que los SGBD relacionales tradicionales no abordaban eficientemente: necesidad de escalar horizontalmente a través de miles de servidores commodity, requerimientos de disponibilidad extremadamente alta sacrificando consistencia fuerte, y esquemas de datos flexibles que evolucionan rápidamente sin migr- aciones de esquema costosas.

Es crucial entender que NoSQL no representa un rechazo completo de las bases de datos relacionales ni de SQL como lenguaje, sino el reconocimiento de que el modelo relacional con su énfasis en consistencia ACID fuerte y esquemas rígidos no es óptimo para todos los escenarios. El teorema CAP, formulado por Eric Brewer, establece que un sistema distribuido puede garantizar simultáneamente solo dos de tres propiedades: Consistencia (todos los nodos ven los mismos datos al mismo tiempo), Disponibilidad (toda petición recibe una respuesta sobre si tuvo éxito o falló), y Tolerancia a Particiones (el sistema continúa operando aunque se pierdan mensajes entre nodos). Las bases de datos relacionales tradicionales priorizan consistencia sobre disponibilidad, mientras muchos sistemas NoSQL hacen la elección inversa.

3.2. Bases de Datos 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 frecuentemente almacenan datos completamente en memoria RAM para minimizar latencia, persistiendo a disco asíncronamente o usando estructuras como log-structured merge trees que optimizan escrituras.

Sistema	Características Principales	Casos de Uso Típicos	Empresas Destacadas
Redis	En memoria, estructuras de datos ricas (listas, sets, hashes), pub/sub, persistencia opcional	Caché, sesiones de usuario, colas de mensajes, leaderboards	Twitter, GitHub, Snapchat
Memcached	En memoria, extremadamente simple, orientado a caché distribuida	Caché de base de datos, caché de resultados de consultas	Facebook, Wikipedia, YouTube
Amazon DynamoDB	Servicio gestionado, escalabilidad automática, baja latencia garantizada	Aplicaciones serverless, gaming, IoT, e-commerce	Amazon, Lyft, Samsung
Riak	Distribuido, alta disponibilidad, resolución de conflictos mediante vector clocks	Almacenamiento de sesiones, perfiles de usuario	Comcast, NHS

3.3. Bases de Datos 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 arrays, proporcionando flexibilidad que el modelo relacional rígido no ofrece fácilmente.

MongoDB es el sistema documental más popular, 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.

// Ejemplo de documento MongoDB
{
    "_id": ObjectId("507f1f77bcf86cd799439011"),
    "nombre": "Juan García",
    "email": "juan@example.com",
    "edad": 35,
    "direccion": {
        "calle": "Av. Principal 123",
        "ciudad": "Madrid",
        "codigo_postal": "28001"
    },
    "telefonos": [
        {"tipo": "movil", "numero": "+34600123456"},
        {"tipo": "trabajo", "numero": "+34910234567"}
    ],
    "intereses": ["tecnología", "deportes", "música"],
    "fecha_registro": ISODate("2023-01-15T10:30:00Z")
}

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.

3.4. Bases de Datos de Grafos

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 traversan múltiples niveles de relaciones.

Neo4j es el sistema de grafos más popular, 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.

// Encontrar recomendaciones de amigos basadas en intereses comunes
MATCH (usuario:Persona {nombre: "Ana"})-[:AMIGO_DE]->(amigo)-[:AMIGO_DE]->(recomendacion)
WHERE NOT (usuario)-[:AMIGO_DE]->(recomendacion)
  AND (recomendacion)-[:INTERESADO_EN]->(:Interes)<-[:INTERESADO_IN]-(usuario)
RETURN recomendacion.nombre, COUNT(*) as intereses_comunes
ORDER BY intereses_comunes DESC
LIMIT 10

3.5. Bases de Datos Columnares

Las bases de datos columnares almacenan datos por columnas en lugar de por filas, optimizando para cargas de trabajo analíticas que típicamente procesan subconjuntos de columnas sobre grandes volúmenes de filas. Mientras que las bases de datos orientadas a filas tradicionales almacenan todos los valores de una fila juntos físicamente en disco, las columnares almacenan todos los valores de una columna juntos, proporcionando ventajas significativas para consultas analíticas que agregan o filtran por columnas específicas sin necesitar todas las columnas de cada fila.

Los beneficios del almacenamiento columnar incluyen mejor compresión ya que valores de una columna tienden a ser más similares entre sí permitiendo algoritmos de compresión más eficientes, reducción de I/O al leer solo las columnas necesarias para una consulta en lugar de filas completas, mejor utilización de caché CPU por la localidad de datos columnar, y vectorización eficiente donde operaciones se aplican a múltiples valores de una columna simultáneamente aprovechando instrucciones SIMD de procesadores modernos.

Apache Cassandra, aunque frecuentemente clasificado como clave-valor, utiliza internamente almacenamiento columnar con su modelo de wide-column donde cada fila puede tener millones de columnas dinámicas. Cassandra está diseñado para escalabilidad masiva distribuyendo datos mediante particionamiento consistente hash entre miles de nodos, priorizando disponibilidad y tolerancia a particiones sobre consistencia fuerte según el teorema CAP, implementando consistencia eventual configurable.

3.6. 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 mapping 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.

4. Motores de Indexación

4.1. Conceptos Fundamentales de Indexación

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.

4.2. Árboles B 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 traversando la lista enlazada de hojas sin necesidad de recorrer el árbol desde la raíz.

4.3. Tablas Hash

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 array, 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 overhead 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 tradeoff.

4.4. Índices Bitmap

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.

5. El Modelo de Referencia ANSI

5.1. Arquitectura de Tres Esquemas

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.

5.2. Independencia de Datos

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 tunning continuo sin impacto en desarrollo de software.

5.3. Mappings entre Niveles

Los mappings o correspondencias entre niveles traducen peticiones y datos entre niveles de abstracción. El mapping conceptual-interno traduce consultas expresadas en términos del esquema conceptual a operaciones de acceso físico, determinando qué índices utilizar, cómo traversar estructuras de datos, y en qué orden acceder a archivos. El optimizador de consultas del SGBD es responsable de este mapping, generando planes de ejecución eficientes.

El mapping 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 automáticamente expande la consulta sobre la vista a una consulta sobre las tablas base. Por ejemplo, si una vista define un join de tres tablas con ciertos filtros, cualquier consulta SELECT sobre la vista se traduce a un SELECT apropiado sobre las tablas subyacentes incorporando los joins y filtros de la definición de la vista.

6. Monitor de Transacciones y Propiedades ACID

6.1. Concepto de Transacción

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.

6.2. Propiedades 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 formalizadas por Andreas Reuter y Theo Härder en 1983 y se han convertido en el estándar de oro para sistemas transaccionales.

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 (rollback) automáticamente. La implementación de atomicidad requiere mantener un log de transacciones que registra todas las modificaciones antes de aplicarlas a la base de datos real, permitiendo deshacer cambios si la transacción aborta.

La Consistencia garantiza que una transacción transforma la base de datos de un estado consistente a otro estado consistente, preservando todas las restricciones de integridad declaradas. Es responsabilidad tanto del SGBD verificar restricciones automáticamente como de los programadores de aplicaciones escribir transacciones que mantengan invariantes de negocio. Por ejemplo, en un sistema de inventario, una transacción que vende productos debe decrementar el stock, y el SGBD debe verificar que el stock resultante no sea negativo si existe tal restricción.

El Aislamiento garantiza que transacciones concurrentes ejecutando simultáneamente no interfieren mutuamente, produciendo resultados como si las transacciones hubieran ejecutado secuencialmente en algún orden. Diferentes niveles de aislamiento permiten tradeoffs entre consistencia y rendimiento, como exploraremos en la sección de control de concurrencia.

La Durabilidad garantiza que una vez que una transacción se confirma exitosamente con COMMIT, sus cambios son permanentes y sobreviven a fallos subsecuentes del sistema incluyendo crashes de software o hardware. Esto se implementa asegurando que antes de confirmar, todos los cambios se persisten en almacenamiento no volátil, típicamente escribiendo registros de log a disco con técnicas de write-ahead logging.

6.3. Estados de una Transacción

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, pero estos cambios son tentative y no visibles a otras transacciones. El estado parcialmente comprometido se alcanza cuando la última operación se ha ejecutado pero aún no se ha confirmado durablemente, un estado transitorio mientras el SGBD finaliza la escritura de logs.

El estado comprometido se alcanza cuando la transacción completa exitosamente y COMMIT se procesa, haciendo los cambios permanentes y visibles a otras transacciones. El estado fallido se alcanza cuando se determina que la transacción no puede proceder normalmente, ya sea porque una operación falló, se violó una restricción de integridad, o el sistema detectó un deadlock. El estado abortado se alcanza después de que la transacción fallida se ha revertido completamente, deshaciendo todos sus cambios y devolviendo la base de datos al estado previo a la transacción.

7. Control de Concurrencia

7.1. Problemas de Concurrencia

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, potencialmente tomando decisiones basadas en información inválida. Por ejemplo, la transacción T1 decrementa un inventario, T2 lee el inventario decrementado y decide no ordenar más producto, luego T1 aborta restaurando el inventario original, pero T2 ya tomó su decisión basándose en el valor incorrecto.

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 que los datos permanecen estables durante una transacción. Por ejemplo, una transacción genera un reporte calculando estadísticas que requieren múltiples lecturas de las mismas filas, pero los valores cambian entre lecturas porque otras transacciones están actualizando concurrentemente, resultando en un reporte inconsistente.

La lectura fantasma (phantom read) es similar a la lectura no repetible pero se refiere a conjuntos de filas en lugar de valores individuales. Una transacción ejecuta una consulta que devuelve un conjunto de filas satisfaciendo cierta condición, luego otra transacción inserta, actualiza o elimina filas de manera que cambia qué filas satisfacen la condición, y cuando la primera transacción reejecutra la misma consulta, obtiene un conjunto de filas diferente. Las filas que aparecen o desaparecen se denominan "fantasmas".

La pérdida de actualización (lost update) ocurre cuando dos transacciones leen el mismo valor, calculan nuevos valores basándose en el valor leído, y escriben sus resultados, con el resultado de que la última escritura sobrescribe la primera perdiendo su actualización. Por ejemplo, dos empleados intentan reservar el último asiento disponible en un vuelo simultáneamente, ambos leen que hay un asiento disponible, ambos decrementan a cero asientos disponibles, resultando en dos reservas para un solo asiento.

7.2. Niveles de Aislamiento

El estándar SQL define cuatro niveles de aislamiento que representan diferentes tradeoffs entre consistencia y rendimiento, permitiendo a aplicaciones elegir el nivel apropiado según sus requerimientos. Niveles de aislamiento más fuertes previenen más anomalías pero requieren más bloqueos reduciendo concurrencia.

Nivel de Aislamiento	Lectura Sucia	Lectura No Repetible	Lectura Fantasma	Uso Típico
READ UNCOMMITTED	Posible	Posible	Posible	Estadísticas aproximadas, dashboards no críticos
READ COMMITTED	No posible	Posible	Posible	Aplicaciones web típicas, navegación de datos
REPEATABLE READ	No posible	No posible	Posible	Reportes consistentes, análisis de datos
SERIALIZABLE	No posible	No posible	No posible	Transacciones financieras, auditoría, integridad crítica

READ UNCOMMITTED es el nivel más débil, permitiendo que una transacción vea cambios no confirmados de otras transacciones, arriesgando lecturas sucias. Este nivel es raramente apropiado excepto para situaciones donde se requiere rendimiento máximo y los datos son informativos pero no críticos para decisiones. READ COMMITTED garantiza que una transacción solo ve cambios confirmados, previniendo lecturas sucias, y es el nivel por defecto en muchos SGBD siendo apropiado para la mayoría de aplicaciones web donde cada petición HTTP es una transacción corta.

REPEATABLE READ garantiza que si una transacción lee un valor, las relecturas subsecuentes verán el mismo valor incluso si otras transacciones están modificando concurrentemente, previniendo lecturas no repetibles pero aún permitiendo lecturas fantasma. SERIALIZABLE es el nivel más fuerte, garantizando aislamiento completo como si las transacciones ejecutaran secuencialmente, previniendo todas las anomalías pero con potencial impacto significativo en rendimiento y concurrencia.

7.3. Técnicas de Control de Concurrencia

Los SGBD implementan control de concurrencia mediante dos familias principales de técnicas: protocolos basados en bloqueos (pesimistas) que previenen conflictos antes de que ocurran, y protocolos basados en timestamps o versiones (optimistas) que detectan y resuelven conflictos cuando ocurren.

Los protocolos basados en bloqueos requieren que transacciones adquieran bloqueos sobre datos antes de accederlos. Un bloqueo compartido (shared lock o read lock) permite que múltiples transacciones lean el mismo dato concurrentemente pero previene que cualquier transacción lo modifique. Un bloqueo exclusivo (exclusive lock o write lock) otorga a una transacción acceso exclusivo para modificar el dato, previniendo que otras transacciones lean o escriban hasta que se libere el bloqueo.

El protocolo de bloqueo de dos fases (two-phase locking o 2PL) es el algoritmo estándar que garantiza serializabilidad. En la fase de crecimiento, la transacción adquiere bloqueos pero no libera ninguno. En la fase de encogimiento, la transacción libera bloqueos pero no adquiere nuevos. Esta disciplina garantiza que el schedule de ejecución es equivalente a algún orden secuencial de transacciones. El bloqueo estricto de dos fases libera todos los bloqueos solo al commit o abort, simplificando recuperación al garantizar que ninguna otra transacción lee datos modificados hasta que se confirmen.

8. Bloqueos y Deadlocks

8.1. Granularidad de Bloqueos

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 (bloque físico de disco conteniendo múltiples registros), o un registro individual. La granularidad apropiada involucra tradeoffs entre overhead de bloqueo y concurrencia. Bloqueos de grano grueso como nivel de tabla son simples de gestionar con bajo overhead, pero limitan severamente concurrencia al bloquear grandes cantidades de datos. Bloqueos de grano fino como nivel de registro permiten alta concurrencia al bloquear solo datos específicamente accedidos, pero incrementan overhead al necesitar gestionar muchos bloqueos pequeños.

El bloqueo multi-granular permite que transacciones bloqueen a diferentes granularidades simultáneamente, utilizando bloqueos de intención que indican que una transacción intenta bloquear a granularidad más fina dentro de un objeto. Por ejemplo, antes de bloquear una fila, la transacción adquiere un bloqueo de intención sobre la tabla contenedora, permitiendo que el sistema detecte conflictos eficientemente sin examinar todos los bloqueos de grano fino.

8.2. Deadlocks

Un deadlock ocurre cuando dos o más transacciones están esperando mutuamente por bloqueos que las otras mantienen, formando un ciclo de espera del que ninguna puede progresar. Por ejemplo, la transacción T1 bloquea el recurso A y solicita el recurso B, mientras simultáneamente T2 bloquea B y solicita A. Ambas transacciones están permanentemente bloqueadas esperando que la otra libere su recurso.

Los SGBD manejan deadlocks mediante prevención o detección. La prevención de deadlocks impone restricciones que hacen imposible que se forme un ciclo de espera, por ejemplo, requiriendo que las transacciones adquieran todos sus bloqueos al inicio en un orden predeterminado. Sin embargo, esto no es práctico para transacciones interactivas donde no se conocen de antemano todos los datos que se accederán.

La detección de deadlocks permite que se formen pero los detecta periódicamente mediante construcción de un grafo de espera donde nodos representan transacciones y aristas representan relaciones de espera. Un ciclo en este grafo indica deadlock. Una vez detectado, el sistema debe romper el deadlock eligiendo una transacción víctima para abortar, liberando sus bloqueos y permitiendo que otras progresen. La víctima se elige basándose en criterios como la transacción que ha ejecutado menos trabajo o que tiene menor prioridad.

8.3. Control de Concurrencia Optimista

El control de concurrencia optimista asume que los conflictos son raros, permitiendo que transacciones ejecuten sin adquirir bloqueos pero validando al commit que no hubo conflictos. Durante ejecución, la transacción lee datos libremente y acumula escrituras en un buffer privado. Al commit, se valida verificando que los datos leídos no fueron modificados por otras transacciones que confirmaron durante la ejecución. Si la validación tiene éxito, las escrituras buffereadas se aplican atómicamente; si falla, la transacción aborta y típicamente se reintenta.

Este enfoque funciona bien en workloads con baja contención donde la mayoría de transacciones acceden datos diferentes, evitando overhead de bloqueos y nunca causando deadlocks. Sin embargo, en escenarios de alta contención donde muchas transacciones acceden los mismos datos, las tasas de abort pueden ser altas, degradando rendimiento significativamente debido a trabajo desperdiciado en transacciones que eventualmente abortan.

9. Recuperación de Errores

9.1. Tipos de Fallos

Los sistemas de bases de datos deben ser resilientes ante diversos tipos de fallos que pueden comprometer integridad de datos. Los fallos de transacción ocurren cuando una transacción individual no puede completar debido a errores lógicos como violaciones de restricciones de integridad, división por cero, o excepciones no manejadas en lógica de aplicación. Los fallos de sistema resultan de crashes del SGBD o sistema operativo por bugs de software, cortes de energía, o fallos de hardware volátil como memoria RAM. Estos fallos pierden el contenido de memoria volátil pero datos en disco persisten.

Los fallos de medios involucran pérdida o corrupción de datos en almacenamiento persistente debido a fallos de disco, corrupción de filesystem, o desastres físicos como fuego o inundación. Estos son los fallos más severos requiriendo restauración desde backups. Los SGBD deben garantizar que independientemente del tipo de fallo, una vez que una transacción confirma, sus cambios persisten, y transacciones no confirmadas no dejan efectos parciales.

9.2. Write-Ahead Logging

El protocolo de write-ahead logging (WAL) es la técnica fundamental que garantiza atomicidad y durabilidad. Bajo WAL, antes de que cualquier modificación de dato se escriba a su ubicación permanente en la base de datos, un registro de log describiendo la modificación debe escribirse a un log persistente en disco. Este log contiene información suficiente para rehacer la operación durante recuperación después de un crash (redo) y para deshacerla durante abort de transacción (undo).

Cada entrada de log típicamente contiene el ID de transacción, el ID del objeto modificado (página, registro), el valor anterior del objeto (before-image), y el valor nuevo del objeto (after-image). Al confirmar una transacción, un registro de commit se escribe al log y se fuerza a disco con operación de flush, garantizando durabilidad. Solo después que el registro de commit persiste en disco se considera la transacción comprometida y se devuelve confirmación al cliente.

Durante recuperación después de un crash, el sistema lee el log desde un checkpoint reciente. Las transacciones con registros de commit en el log deben rehacerse aplicando sus modificaciones (operaciones redo), ya que aunque confirmaron, sus cambios pueden no haberse escrito completamente a la base de datos antes del crash. Las transacciones sin registros de commit deben deshacerse (operaciones undo) aplicando sus before-images, eliminando cualquier cambio parcial que alcanzó la base de datos.

9.3. Checkpoints

El log de transacciones crece indefinidamente a medida que se ejecutan transacciones, y recuperar desde el inicio del log después de cada crash sería prohibitivamente lento para logs grandes. Los checkpoints son puntos en el tiempo donde el sistema fuerza todas las páginas modificadas en memoria a disco y registra en el log qué transacciones están activas. Durante recuperación, el sistema solo necesita procesar el log desde el último checkpoint, ignorando entradas anteriores.

Los checkpoints pueden ser inconsistentes (fuzzy checkpoints) donde el sistema continúa procesando transacciones durante el checkpoint, o consistentes donde todas las transacciones se suspenden. Los fuzzy checkpoints son preferibles en sistemas de producción al no interrumpir servicio, aunque complican ligeramente la lógica de recuperación. El intervalo de checkpoints representa un tradeoff: checkpoints frecuentes aceleran recuperación pero causan overhead de I/O durante operación normal; checkpoints infrecuentes minimizan overhead operacional pero ralentizan recuperación.

9.4. Backups y Recuperación ante Fallos de Medios

Los mecanismos de recuperación basados en logs protegen contra fallos de transacciones y crashes de sistema, pero no contra pérdida o corrupción de la base de datos en disco. La protección requiere backups periódicos que copian la base de datos completa o incrementalmente a almacenamiento separado, idealmente en ubicación física diferente para proteger contra desastres.

Un backup completo copia toda la base de datos, proporcionando un punto de restauración completo pero requiriendo tiempo y espacio significativos para bases de datos grandes. Los backups incrementales copian solo datos que cambiaron desde el último backup, siendo más rápidos y compactos pero requiriendo múltiples backups para restauración completa. Los backups diferenciales copian cambios desde el último backup completo, ofreciendo balance entre complejidad de restauración y eficiencia de backup.

Para recuperar desde fallo de medios, el sistema restaura el backup más reciente, luego aplica logs de transacciones generados después del backup para roll-forward, reproduciendo todas las transacciones confirmadas y alcanzando el estado más reciente posible. El objetivo de punto de recuperación (RPO - Recovery Point Objective) especifica cuánta pérdida de datos es aceptable, determinando frecuencia de backups, mientras el objetivo de tiempo de recuperación (RTO - Recovery Time Objective) especifica cuánto downtime es aceptable, influyendo en la arquitectura de backup y restauración.

10. Integridad de Datos

10.1. Restricciones de Integridad

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 de negocio y permanecen consistentes. Los SGBD relacionales soportan múltiples tipos de restricciones que pueden declararse como parte del esquema y se verifican 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, por ejemplo, declarar una columna como INTEGER restringe a números enteros. Restricciones adicionales incluyen NOT NULL para prevenir valores ausentes, DEFAULT para proporcionar valores automáticos, y CHECK para validar valores contra expresiones arbitrarias como CHECK (edad >= 18).

Las restricciones de clave garantizan unicidad de filas y proporcionan mecanismo para referenciarlas. Una clave primaria (PRIMARY KEY) identifica unívocamente cada fila, automáticamente implica NOT NULL y crea un índice único. Una clave candidata (UNIQUE) también garantiza unicidad pero puede ser null. Una clave foránea (FOREIGN KEY) establece relación referencial entre tablas, garantizando que valores en la columna de clave foránea existen en la columna de clave primaria de la tabla referenciada.

-- Ejemplo de restricciones de integridad en SQL
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
);

10.2. Acciones Referenciales

Las restricciones de clave foránea pueden especificar acciones referenciales que determinan qué sucede cuando se intenta modificar o eliminar una fila referenciada por otras filas. ON DELETE RESTRICT previene eliminación de una fila si existen referencias, manteniendo integridad referencial forzando que las referencias se eliminen primero. ON DELETE CASCADE propaga la eliminación automáticamente a todas las filas referenciantes, útil cuando las filas dependientes no tienen significado sin la fila padre.

ON DELETE SET NULL establece las claves foráneas referenciantes a NULL cuando se elimina la fila referenciada, apropiado cuando la relación es opcional. ON UPDATE CASCADE propaga cambios en la clave primaria referenciada a todas las claves foráneas referenciantes, manteniendo consistencia automáticamente. Sin embargo, cambiar claves primarias es generalmente desaconsejado, siendo mejor utilizar claves surrogadas inmutables.

10.3. Aserciones y Triggers

Las aserciones son restricciones generales que pueden expresar condiciones arbitrarias sobre el estado de la base de datos completa, no limitadas a una tabla o fila individual. Por ejemplo, una aserción podría especificar que el número total de plazas reservadas en todos los vuelos no excede la capacidad total de la flota. Aunque soportadas por el estándar SQL, las aserciones son raramente implementadas en SGBD comerciales por su overhead computacional.

Los triggers son procedimientos que se ejecutan automáticamente en respuesta a eventos específicos de base de datos como INSERT, UPDATE o DELETE sobre una tabla. Los triggers permiten implementar restricciones complejas, mantener datos derivados, auditar cambios, o sincronizar datos entre tablas. Sin embargo, deben usarse juiciosamente ya que pueden ocultar lógica de negocio haciéndola difícil de depurar, y triggers complejos pueden impactar significativamente rendimiento.

11. Mapa Conceptual de SGBD

12. Preguntas de Evaluación (25 Preguntas)

13. Referencias Bibliográficas y Recursos