1. Introducción y Contextualización

Las bases de datos constituyen el activo más valioso de cualquier organización sanitaria moderna. En el contexto del Servicio Andaluz de Salud, los Sistemas de Gestión de Bases de Datos no son simplemente repositorios de información, sino la columna vertebral tecnológica que sostiene la prestación de servicios sanitarios a más de 8,4 millones de ciudadanos andaluces. Cada consulta médica, cada prescripción farmacéutica, cada prueba diagnóstica, cada ingreso hospitalario genera y consulta datos que deben estar disponibles con niveles de seguridad, integridad y disponibilidad que literalmente pueden marcar la diferencia entre la vida y la muerte.

Cuando un profesional sanitario accede a Diraya, el sistema corporativo de historia clínica digital del SAS, está realizando centenares de operaciones sobre bases de datos Oracle que almacenan más de 100 millones de episodios asistenciales. Estas operaciones deben cumplir propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) para garantizar que la información clínica sea siempre fiable, esté protegida ante fallos y sea accesible en tiempo real desde cualquiera de los más de 1.500 centros sanitarios del SSPA.

1.1. Marco Normativo y Regulatorio

La gestión de bases de datos en el ámbito sanitario público está sujeta a un marco regulatorio especialmente estricto que combina requisitos de seguridad, protección de datos y continuidad de servicio. El Esquema Nacional de Seguridad (ENS), actualizado por el Real Decreto 311/2022, establece los niveles de seguridad que deben cumplir los sistemas de información de las administraciones públicas, incluyendo medidas específicas para la gestión de bases de datos en entornos de alta criticidad.

El Reglamento General de Protección de Datos (RGPD) y la Ley Orgánica 3/2018 (LOPDGDD) imponen obligaciones específicas sobre el tratamiento de datos de salud, considerados categoría especial de datos personales conforme al artículo 9 del RGPD. Los SGBD que almacenan historias clínicas deben implementar medidas técnicas y organizativas que garanticen la confidencialidad, integridad y disponibilidad de estos datos, incluyendo cifrado en reposo y en tránsito, trazabilidad de accesos, y capacidad de respuesta ante ejercicio de derechos (acceso, rectificación, supresión, portabilidad).

1.2. Objetivos del Tema

Al finalizar el estudio de este tema, deberás ser capaz de comprender en profundidad los fundamentos teóricos y prácticos de los Sistemas de Gestión de Bases de Datos, aplicados específicamente al contexto sanitario del SAS. Esto incluye entender las diferentes arquitecturas de SGBD (centralizadas, distribuidas, federadas), los modelos de bases de datos (relacionales, no relacionales), los mecanismos de control de transacciones y concurrencia, y las estrategias de recuperación ante fallos.

Deberás dominar el modelo de referencia ANSI/SPARC y su aplicación en sistemas reales, comprender las propiedades ACID que garantizan la fiabilidad de las transacciones, conocer los principales SGBD comerciales y de código abierto utilizados en el SAS (Oracle, PostgreSQL, MariaDB, MongoDB), y ser capaz de analizar y resolver problemas de rendimiento, integridad y disponibilidad en bases de datos de sistemas críticos hospitalarios.

2. Sistemas de Gestión de Bases de Datos (SGBD)

2.1. Concepto y Definición

Un Sistema de Gestión de Bases de Datos (SGBD), también conocido por sus siglas en inglés DBMS (Database Management System), es un software especializado que actúa como interfaz entre las aplicaciones, los usuarios finales y las bases de datos. Su función principal es proporcionar un entorno que facilite y controle el almacenamiento, modificación y extracción de información de forma eficiente, segura y coherente.

Los SGBD no son simplemente programas para almacenar datos, sino sistemas complejos que implementan múltiples servicios críticos: gestión del espacio de almacenamiento, optimización de consultas, control de concurrencia para accesos simultáneos, gestión de transacciones para garantizar la consistencia, mecanismos de recuperación ante fallos, sistemas de seguridad y control de acceso, y herramientas de administración y monitorización.

2.2. Funciones y Componentes Principales

Los SGBD modernos se estructuran en varios componentes funcionales que trabajan coordinadamente para proporcionar servicios de gestión de datos. El procesador de consultas es el cerebro del sistema, responsable de analizar, optimizar y ejecutar las peticiones de los usuarios. Cuando un profesional sanitario busca el historial de un paciente en Diraya, el procesador de consultas analiza la solicitud SQL, genera un plan de ejecución óptimo considerando índices disponibles, estadísticas de distribución de datos y recursos del sistema, y coordina la recuperación de información de los ficheros de datos.

El gestor de almacenamiento controla la interacción con el sistema de ficheros del sistema operativo, gestionando la organización física de los datos en discos, la asignación de espacio, la creación y mantenimiento de índices, y la implementación de políticas de caché para minimizar accesos a disco. En bases de datos críticas como las de Diraya, este componente gestiona tablespaces Oracle distribuidos en sistemas de almacenamiento SAN de alta disponibilidad.

El gestor de transacciones garantiza que las operaciones sobre la base de datos cumplan las propiedades ACID, coordinando el inicio, ejecución y finalización de transacciones. Gestiona logs de transacciones (redo logs y undo logs en Oracle) que permiten deshacer operaciones en caso de fallo y rehacer operaciones confirmadas tras una recuperación. Este componente es crítico en entornos hospitalarios donde una transacción puede involucrar el registro simultáneo de un acto asistencial, la actualización del estado del paciente, la petición de pruebas diagnósticas y la generación de prescripciones.

2.3. Lenguajes de Bases de Datos

Los SGBD relacionales utilizan SQL (Structured Query Language) como lenguaje estándar para la definición, manipulación y control de datos. SQL se divide en varios sublenguajes especializados. El DDL (Data Definition Language) permite definir la estructura de la base de datos mediante sentencias como CREATE, ALTER y DROP para crear y modificar tablas, índices, vistas y otros objetos del esquema.

El DML (Data Manipulation Language) proporciona operaciones para consultar y modificar datos mediante sentencias SELECT, INSERT, UPDATE y DELETE. El DCL (Data Control Language) controla permisos y accesos mediante GRANT y REVOKE. El TCL (Transaction Control Language) gestiona transacciones con COMMIT, ROLLBACK y SAVEPOINT.

2.4. Ventajas de Utilizar un SGBD

La adopción de SGBD profesionales en organizaciones sanitarias como el SAS ofrece ventajas fundamentales frente a sistemas de ficheros tradicionales. La independencia de datos permite modificar la estructura física o lógica de la base de datos sin afectar a las aplicaciones que la utilizan. Si el SAS decide migrar de discos HDD a almacenamiento SSD NVMe, las aplicaciones sanitarias no requieren modificación alguna porque el SGBD abstrae la capa física.

El control de redundancia evita duplicación innecesaria de información. En el sistema BDU, cada ciudadano tiene un identificador único (NUHSA – Número Único de Historia de Salud de Andalucía) que relaciona toda su información demográfica, administrativa y asistencial sin necesidad de replicar datos en múltiples sistemas. La integridad de datos se garantiza mediante restricciones declarativas (claves primarias, foráneas, checks) que el SGBD verifica automáticamente antes de cada modificación.

El control de concurrencia permite que cientos de profesionales sanitarios accedan simultáneamente a Diraya sin que se produzcan inconsistencias. El SGBD coordina bloqueos y aislamiento de transacciones para que, por ejemplo, dos médicos que consultan simultáneamente el mismo paciente vean información coherente, y si uno prescribe un medicamento mientras el otro registra una alergia, el sistema gestiona correctamente la secuencia de actualizaciones.

Los mecanismos de recuperación protegen contra pérdidas de información ante fallos hardware, software o humanos. Oracle implementa logs de transacciones en discos redundantes que permiten recuperar la base de datos al último estado consistente. En 2023, cuando un fallo eléctrico afectó al CPD principal del SAS, el sistema se recuperó automáticamente sin pérdida de datos gracias a los mecanismos REDO y UNDO del SGBD.

3. Modelos y Arquitecturas de SGBD

3.1. Bases de Datos Centralizadas

En una arquitectura centralizada, toda la información y el procesamiento residen en un único sistema. Este modelo ofrece simplicidad administrativa, control centralizado de seguridad y facilidad para garantizar la consistencia de datos. Sin embargo, presenta limitaciones de escalabilidad y constituye un único punto de fallo. En el SAS, algunos sistemas departamentales como aplicaciones de gestión económica de centros de atención primaria utilizan bases de datos centralizadas PostgreSQL alojadas en servidores locales.

3.2. Bases de Datos Distribuidas

Los sistemas distribuidos fragmentan los datos y/o el procesamiento entre múltiples nodos geográficamente dispersos. La fragmentación horizontal divide tablas por filas según algún criterio, por ejemplo, almacenando los registros de pacientes de cada provincia en servidores locales. La fragmentación vertical divide por columnas, separando información clínica sensible en servidores de alta seguridad mientras datos demográficos básicos residen en sistemas más accesibles.

La replicación mantiene copias sincronizadas de datos en múltiples ubicaciones para mejorar disponibilidad y rendimiento. El sistema Receta XXI del SAS replica información de prescripciones farmacéuticas entre el servidor central y servidores provinciales, permitiendo que las farmacias dispensen medicamentos incluso si la conexión con el CPD central falla temporalmente.

3.3. Bases de Datos Federadas

Los sistemas federados integran múltiples bases de datos preexistentes, heterogéneas y autónomas, ofreciendo una vista unificada sin fusionarlas físicamente. Existen dos modelos principales: fuertemente acoplados, donde un administrador global controla la creación y acceso a los sistemas componente, y débilmente acoplados, donde los usuarios son responsables de crear y mantener las federaciones mediante vistas.

3.4. Bases de Datos No Relacionales (NoSQL)

Las bases de datos NoSQL surgieron para atender necesidades que los SGBD relacionales tradicionales no cubrían eficientemente: escalabilidad horizontal masiva, esquemas flexibles, y alto rendimiento en operaciones de lectura/escritura simples. En el SAS, MongoDB se utiliza para almacenar logs de aplicaciones y telemetría de dispositivos IoMT (Internet of Medical Things) donde el volumen de datos y la variabilidad del esquema dificultan el uso de bases relacionales tradicionales.

3.4.1. Bases de Datos Clave-Valor

Almacenan pares clave-valor simples, optimizadas para recuperación rápida mediante claves únicas. Redis se emplea en el SAS como caché distribuida para sesiones de usuario en aplicaciones web sanitarias, reduciendo latencia y carga sobre las bases de datos Oracle principales. Una sesión de Diraya almacena en Redis información temporal del usuario autenticado, evitando consultas repetidas a la base de datos principal para cada petición HTTP.

3.4.2. Bases de Datos Documentales

Almacenan documentos JSON, XML o BSON con estructura variable. MongoDB es el SGBD documental más popular. En proyectos piloto del SAS, se ha evaluado MongoDB para almacenar formularios clínicos dinámicos donde cada especialidad médica requiere campos diferentes, algo complejo de modelar en esquemas relacionales rígidos.

3.4.3. Bases de Datos de Grafos

Optimizadas para modelar y consultar relaciones complejas entre entidades. Neo4j podría utilizarse en el SAS para analizar redes de contacto en epidemiología, relaciones entre síntomas y diagnósticos en sistemas de apoyo a la decisión clínica, o trazabilidad de interacciones farmacológicas considerando principios activos, patologías y genética del paciente.

3.4.4. Bases de Datos Columnares

Almacenan datos por columnas en lugar de por filas, optimizando consultas analíticas que agregan pocas columnas sobre millones de registros. Apache HBase y Cassandra son ejemplos. En el data warehouse de InfoWeb del SAS, se evalúa tecnología columnar para acelerar consultas OLAP sobre indicadores sanitarios que agregan datos de años de actividad asistencial.

3.4.5. Motores de Indexación

Elasticsearch es un motor de búsqueda y análisis distribuido basado en Apache Lucene. Permite indexar grandes volúmenes de documentos y realizar búsquedas de texto completo con alta velocidad. En el SAS, Elasticsearch se utiliza en el proyecto de Historia Clínica Digital para permitir búsquedas textuales avanzadas en informes clínicos, pudiendo localizar instantáneamente todos los pacientes que mencionan un síntoma específico o un tratamiento concreto en sus historiales.

4. El Modelo de Referencia ANSI/SPARC

4.1. Arquitectura de Tres Niveles

El modelo ANSI/SPARC, propuesto por el American National Standards Institute y el Standards Planning and Requirements Committee en 1975, define una arquitectura conceptual de tres niveles para los Sistemas de Gestión de Bases de Datos. Este modelo establece una separación clara entre cómo los usuarios ven los datos, cómo se representan lógicamente, y cómo se almacenan físicamente, permitiendo independencia entre estas capas.

4.2. Nivel Externo o de Vistas

El nivel externo define múltiples vistas personalizadas de la base de datos, adaptadas a las necesidades específicas de diferentes grupos de usuarios. En Diraya, un médico de familia ve una vista que incluye información clínica completa del paciente, antecedentes, alergias, tratamientos y pruebas diagnósticas. Un profesional de farmacia hospitalaria accede a una vista restringida que muestra únicamente prescripciones validadas, stocks de medicamentos y posibles interacciones, sin acceso a información clínica sensible que no sea necesaria para su función.

Las vistas proporcionan seguridad mediante restricción de acceso, presentan datos de forma comprensible para cada perfil profesional, y simplifican consultas complejas encapsulando lógica en definiciones de vista. Una vista puede combinar información de múltiples tablas mediante joins, aplicar filtros específicos, calcular campos derivados, y ocultar columnas confidenciales.

4.3. Nivel Conceptual o Lógico

El nivel conceptual describe la estructura completa de la base de datos para toda la organización, independientemente de cómo se almacenen físicamente los datos. Define todas las entidades, sus atributos, relaciones entre entidades, restricciones de integridad, y reglas de negocio. En el modelo relacional, este nivel corresponde al esquema de la base de datos expresado en DDL (Data Definition Language).

En Diraya, el esquema conceptual incluye tablas como PACIENTES (con campos NUHSA, nombre, fecha de nacimiento, SIP, domicilio), EPISODIOS_ASISTENCIALES (con claves foráneas a pacientes, profesionales y centros sanitarios), PRESCRIPCIONES (relacionadas con episodios y catálogos de medicamentos), y ALERGIAS (con relaciones hacia pacientes y principios activos). Este esquema define claves primarias, foráneas, restricciones de unicidad, checks, y triggers que implementan lógica de negocio.

4.4. Nivel Interno o Físico

El nivel interno especifica cómo se almacenan físicamente los datos en dispositivos de almacenamiento. Define la organización de archivos (heap, secuencial, hash, B-tree), métodos de acceso, estructuras de índices, algoritmos de compresión, técnicas de cifrado, y estrategias de almacenamiento en caché. En Oracle, este nivel se gestiona mediante tablespaces que agrupan datafiles, segmentos para tablas e índices, extents como unidades de asignación de espacio, y bloques como unidad mínima de I/O.

Las decisiones del nivel interno impactan directamente en el rendimiento. En bases de datos críticas del SAS, las tablas de pacientes se organizan con hash clustering por NUHSA para acceso directo, los índices B-tree aceleran búsquedas por apellidos y fechas, las tablas históricas emplean compresión avanzada OLTP para reducir espacio sin penalizar rendimiento, y el cifrado TDE (Transparent Data Encryption) protege datafiles en disco cumpliendo requisitos ENS y RGPD.

4.5. El Diccionario de Datos

El diccionario de datos (data dictionary o metadatos) almacena información sobre la estructura de la base de datos: definiciones de tablas, columnas, tipos de datos, restricciones, índices, vistas, usuarios, permisos, y estadísticas. El SGBD consulta el diccionario constantemente para validar consultas, verificar permisos, y optimizar planes de ejecución.

En Oracle, el diccionario de datos se implementa mediante vistas sobre tablas internas (DBA_TABLES, DBA_INDEXES, DBA_USERS, DBA_TAB_COLUMNS). Estas vistas permiten a los administradores consultar la estructura completa del sistema, generar scripts de replicación de esquemas, analizar uso de espacio, y auditar permisos.

4.6. Independencia de Datos

La arquitectura de tres niveles proporciona dos tipos de independencia fundamentales. La independencia lógica permite modificar el esquema conceptual (añadir tablas, columnas o relaciones) sin afectar vistas existentes ni aplicaciones, siempre que los cambios sean compatibles. Si el SAS decide añadir un campo de geolocalización a la tabla de centros sanitarios en Diraya, las aplicaciones que consultan nombre y dirección seguirán funcionando sin modificación.

La independencia física permite cambiar la organización física del almacenamiento sin modificar el esquema conceptual ni las aplicaciones. Si el equipo de sistemas decide migrar tablespaces Oracle de discos HDD a SSD NVMe, o reorganizar índices para mejorar rendimiento, las aplicaciones sanitarias no requieren cambio alguno porque el SGBD mantiene la abstracción lógica de los datos independiente de su representación física.

5. Monitor de Transacciones y Propiedades ACID

5.1. Concepto de Transacción

Una transacción es una unidad lógica de trabajo compuesta por una secuencia de operaciones sobre la base de datos que deben ejecutarse de forma atómica: o todas se completan exitosamente, o ninguna tiene efecto. Las transacciones son fundamentales para mantener la consistencia en entornos donde múltiples usuarios modifican concurrentemente la misma base de datos.

5.2. Propiedades ACID

Las transacciones deben cumplir cuatro propiedades fundamentales conocidas por el acrónimo ACID: Atomicidad, Consistencia, Aislamiento (Isolation) y Durabilidad. Estas propiedades garantizan la fiabilidad y corrección de las operaciones sobre la base de datos incluso en presencia de fallos, accesos concurrentes y errores del sistema.

5.2.1. Atomicidad

La atomicidad garantiza que todas las operaciones de una transacción se ejecutan completamente o ninguna tiene efecto. No existen estados intermedios visibles externamente. Si una transacción que actualiza cinco tablas falla en la cuarta operación, el SGBD deshace automáticamente las tres primeras operaciones ya realizadas, dejando la base de datos en el estado anterior al inicio de la transacción.

Oracle implementa atomicidad mediante undo segments que almacenan las versiones anteriores de los datos modificados. Si una transacción ejecuta ROLLBACK o el sistema detecta un error, Oracle utiliza la información de undo para revertir todos los cambios. Los undo segments también proporcionan consistencia de lectura, permitiendo que consultas vean instantáneas coherentes de datos incluso mientras otras transacciones los modifican.

5.2.2. Consistencia

La consistencia asegura que una transacción lleva la base de datos de un estado válido a otro estado válido, manteniendo todas las restricciones de integridad, reglas de negocio y relaciones entre datos. Si una transacción viola una restricción de clave primaria, foránea, check, o trigger, el SGBD la rechaza automáticamente antes de confirmarla.

En Diraya, existe una restricción que impide prescribir medicamentos a pacientes con alergias conocidas a sus principios activos. Si un médico intenta prescribir penicilina a un paciente con alergia registrada a beta-lactámicos, un trigger verifica la incompatibilidad y cancela la transacción antes de que la prescripción se registre, manteniendo la consistencia del sistema.

5.2.3. Aislamiento (Isolation)

El aislamiento garantiza que las operaciones de transacciones concurrentes no interfieren entre sí. Cada transacción debe ejecutarse como si fuera la única operando sobre la base de datos. El SGBD implementa diferentes niveles de aislamiento que balancean consistencia y rendimiento:

• READ UNCOMMITTED: Permite lecturas sucias (dirty reads), donde una transacción puede leer datos modificados por otra transacción no confirmada. Es el nivel menos restrictivo y de mayor rendimiento, pero arriesgado en entornos críticos.
• READ COMMITTED: Evita lecturas sucias, garantizando que solo se leen datos confirmados. Es el nivel por defecto en Oracle y PostgreSQL.
• REPEATABLE READ: Garantiza que si una transacción lee un dato dos veces, obtiene el mismo valor, evitando lecturas no repetibles (non-repeatable reads).
• SERIALIZABLE: El nivel más restrictivo, garantiza que transacciones concurrentes producen el mismo resultado que si se ejecutaran secuencialmente. Evita anomalías phantom reads pero puede reducir concurrencia.

5.2.4. Durabilidad

La durabilidad asegura que una vez confirmada una transacción mediante COMMIT, sus efectos son permanentes incluso ante fallos del sistema. Oracle implementa durabilidad mediante redo logs que registran todos los cambios confirmados. Si el servidor sufre un fallo eléctrico segundos después de que un médico confirme una prescripción, al reiniciar la base de datos Oracle utiliza los redo logs para recuperar la transacción confirmada, garantizando que la prescripción no se pierde.

Los redo logs se escriben en discos redundantes (generalmente en configuración RAID 1) antes de confirmar la transacción al usuario. Esta política de write-ahead logging garantiza que incluso ante fallo de disco, existe una copia de seguridad de las transacciones confirmadas que permite recuperación completa.

5.3. Monitor de Transacciones

El monitor de transacciones (Transaction Processing Monitor) es un componente del SGBD que coordina y supervisa la ejecución de transacciones, gestionando su inicio, progreso y finalización. En arquitecturas distribuidas, el monitor coordina transacciones que involucran múltiples bases de datos mediante protocolos de commit distribuido como 2PC (Two-Phase Commit).

Oracle Transaction Monitor mantiene información de estado de cada transacción activa en estructuras de memoria (SGA – System Global Area) y coordina bloqueos, escrituras de logs, y confirmación de transacciones. En configuraciones RAC, el monitor sincroniza transacciones entre múltiples instancias Oracle que acceden a la misma base de datos, resolviendo conflictos de bloqueo y garantizando consistencia mediante mecanismos de cache fusion.

6. Control de Concurrencia y Bloqueos

6.1. Problemas de Concurrencia

Cuando múltiples transacciones acceden simultáneamente a los mismos datos, pueden surgir anomalías que comprometen la consistencia. La pérdida de actualizaciones ocurre cuando dos transacciones leen el mismo dato, lo modifican y lo escriben, resultando en que la segunda sobrescribe la primera sin considerar sus cambios. La lectura sucia permite que una transacción lea datos modificados por otra no confirmada que posteriormente hace ROLLBACK, basando decisiones en información inconsistente.

La lectura no repetible sucede cuando una transacción lee el mismo dato dos veces obteniendo valores diferentes porque otra transacción lo modificó entre lecturas. Los phantom reads aparecen cuando una transacción ejecuta la misma consulta dos veces y obtiene diferentes conjuntos de resultados porque otra transacción insertó o eliminó filas que cumplen la condición de búsqueda.

6.2. Mecanismos de Control de Concurrencia

Los SGBD emplean dos estrategias principales para controlar concurrencia: pesimista (basada en bloqueos) y optimista (basada en validación). El control pesimista asume que los conflictos son frecuentes y bloquea recursos preventivamente. El control optimista asume que los conflictos son raros y permite que transacciones procedan libremente, validando al final si hubo conflictos y deshaciendo la transacción en caso afirmativo.

6.3. Bloqueos (Locks)

Los bloqueos son mecanismos que restringen el acceso concurrente a recursos (filas, tablas, páginas) para coordinar transacciones. Existen dos tipos fundamentales: bloqueos compartidos (shared locks o S-locks) permiten que múltiples transacciones lean simultáneamente un dato pero no lo modifiquen, y bloqueos exclusivos (exclusive locks o X-locks) otorgan acceso exclusivo para modificación, impidiendo que otras transacciones lean o escriban el dato bloqueado.

Oracle utiliza una estrategia de bloqueo menos restrictiva que otros SGBD: implementa consistencia de lectura mediante versionado multiversión (MVCC – Multiversion Concurrency Control), permitiendo que lecturas no bloqueen escrituras ni escrituras bloqueen lecturas. Cuando una transacción modifica una fila, Oracle almacena la versión anterior en undo segments y otorga un bloqueo exclusivo sobre la fila. Otras transacciones que consultan esa fila obtienen la versión anterior desde undo, viendo una instantánea consistente sin esperar a que finalice la transacción modificadora.

6.4. Granularidad de Bloqueos

Los bloqueos pueden aplicarse a diferentes niveles de granularidad. Los bloqueos de fila ofrecen máxima concurrencia bloqueando solo registros específicos, pero generan overhead de gestión cuando se bloquean muchas filas. Los bloqueos de tabla son más eficientes administrativamente pero reducen concurrencia significativamente. Los bloqueos de página son un compromiso intermedio, bloqueando grupos de filas almacenadas en la misma página física.

Oracle soporta bloqueos a nivel de fila por defecto, evitando escaladas automáticas a bloqueos de tabla que reducirían concurrencia. Si una transacción modifica 100.000 filas, Oracle mantiene bloqueos individuales sobre cada fila sin consolidarlos en un bloqueo de tabla, aunque esto consume más recursos de memoria en el pool de locks del SGA.

6.5. Deadlocks (Interbloqueos)

Un deadlock ocurre cuando dos o más transacciones esperan mutuamente recursos bloqueados por las otras, creando un ciclo de espera infinito. Por ejemplo, la transacción T1 bloquea la fila A y solicita la fila B, mientras T2 bloquea la fila B y solicita la fila A. Ninguna puede progresar porque cada una espera un recurso retenido por la otra.

Los SGBD detectan deadlocks mediante grafos de espera que representan dependencias entre transacciones. Cuando se detecta un ciclo, el sistema elige una víctima (usualmente la transacción con menor costo de reversión) y la aborta mediante ROLLBACK, liberando sus bloqueos y permitiendo que otras transacciones progresen. Oracle detecta deadlocks automáticamente cada 3 segundos y registra información detallada en el alert.log para análisis posterior.

6.6. Estrategias de Prevención de Deadlocks

Para minimizar deadlocks, se pueden adoptar varias estrategias. Ordenamiento de acceso a recursos: Si todas las transacciones acceden a tablas/filas en el mismo orden, se eliminan ciclos de espera. Timeouts de bloqueo: Configurar límites de tiempo para espera de bloqueos, abortando transacciones que excedan el umbral. Bloqueos optimistas: En lugar de bloquear preventivamente, verificar al final de la transacción si hubo conflictos. Reducción de duración de transacciones: Transacciones más cortas retienen bloqueos menos tiempo, reduciendo probabilidad de conflictos.

7. Recuperación de Errores e Integridad

7.1. Tipos de Fallos

Los sistemas de bases de datos deben ser resilientes ante diversos tipos de fallos. Los fallos de transacción ocurren cuando una transacción no puede completarse debido a errores lógicos (violación de restricciones, deadlock, timeout) o solicitudes explícitas de ROLLBACK. Los fallos del sistema resultan de caídas del software del SGBD, del sistema operativo, o pérdidas de energía que provocan pérdida de contenido de memoria volátil pero no afectan discos.

Los fallos de medios son los más graves, involucrando daños físicos en discos que causan pérdida permanente de datos. Estos fallos requieren restauración desde backups y aplicación de logs de transacciones para recuperar el estado más reciente posible de la base de datos.

7.2. Técnicas de Recuperación

Los SGBD implementan recuperación mediante write-ahead logging (WAL): antes de modificar datos en disco, se escriben registros de log que describen los cambios. Los logs de transacciones incluyen información de UNDO (para revertir cambios de transacciones no confirmadas) y REDO (para rehacer cambios de transacciones confirmadas). Tras un fallo del sistema, el proceso de recuperación automática lee los logs y ejecuta operaciones UNDO y REDO necesarias para restaurar consistencia.

Oracle implementa recuperación mediante redo logs (circulares, sobrescriben cuando se llenan) que registran todos los cambios y archived redo logs (copia permanente de redo logs llenos) que permiten recuperación point-in-time. El parámetro ARCHIVE LOG MODE determina si Oracle guarda archived logs, habilitando recuperación completa ante fallos de medios.

7.3. Estrategias de Backup y Restore

Las copias de seguridad son fundamentales para recuperación ante fallos de medios. Los backups completos copian toda la base de datos, siendo la base de cualquier estrategia de recuperación pero consumiendo tiempo y espacio. Los backups incrementales copian solo bloques modificados desde el último backup (incremental o completo), reduciendo tiempo y espacio pero requiriendo múltiples archivos para restauración.

Oracle RMAN (Recovery Manager) es la herramienta estándar para backup y recovery en Oracle. RMAN gestiona backups completos e incrementales, verifica integridad de backups, implementa compresión y cifrado, y automatiza restauración y recuperación. En el SAS, las bases de datos críticas como Diraya ejecutan backups RMAN diarios incrementales de nivel 1 y un backup completo semanal de nivel 0, con retención de 30 días de archived logs para recovery point objetivo de 1 hora.

7.4. Alta Disponibilidad con Oracle Data Guard

Oracle Data Guard proporciona disaster recovery y alta disponibilidad manteniendo una o más bases de datos standby sincronizadas con la base de datos primaria mediante aplicación continua de redo logs. Existen dos modos: physical standby (réplica física exacta, aplicando redo a nivel de bloque) y logical standby (réplica lógica mediante SQL, permitiendo acceso de solo lectura simultáneo).

7.5. Integridad de Datos

La integridad garantiza corrección y consistencia de datos mediante restricciones y reglas de negocio. La integridad de entidad requiere que cada tabla tenga clave primaria única y no nula, identificando inequívocamente cada fila. La integridad referencial mantiene coherencia entre tablas relacionadas mediante claves foráneas, evitando huérfanos (filas con referencias a registros inexistentes).

La integridad de dominio restringe valores permitidos en columnas mediante tipos de datos, restricciones CHECK, y valores por defecto. La integridad semántica o de negocio implementa reglas específicas de la organización mediante triggers, procedimientos almacenados, y restricciones complejas.

En Diraya, la integridad referencial garantiza que toda prescripción (tabla PRESCRIPCIONES) referencia un episodio asistencial existente (tabla EPISODIOS) mediante clave foránea, y todo episodio referencia un paciente válido (tabla PACIENTES) mediante NUHSA. Si se intenta eliminar un paciente con episodios asociados, la restricción de clave foránea lo impide a menos que se configure ON DELETE CASCADE, que eliminaría en cascada todos los datos relacionados (comportamiento peligroso en entornos sanitarios donde la preservación de historiales es obligación legal).

8. Bases de Datos NoSQL en Profundidad

8.1. Teorema CAP y Trade-offs

El teorema CAP (Consistency, Availability, Partition tolerance), propuesto por Eric Brewer, establece que un sistema distribuido solo puede garantizar simultáneamente dos de las siguientes tres propiedades: Consistencia (todos los nodos ven los mismos datos al mismo tiempo), Disponibilidad (toda petición recibe respuesta sobre éxito o fallo), y Tolerancia a particiones (el sistema continúa operando a pesar de particionamiento de red entre nodos).

Los SGBD relacionales tradicionales priorizan CP (Consistency + Partition tolerance), sacrificando disponibilidad ante particiones de red para mantener consistencia. Los sistemas NoSQL suelen priorizar AP (Availability + Partition tolerance), permitiendo inconsistencias temporales mediante consistencia eventual para mantener disponibilidad ante fallos de red.

8.2. Bases de Datos Orientadas a Objetos

Las bases de datos orientadas a objetos (BDOO) almacenan objetos directamente, soportando herencia, encapsulamiento, polimorfismo y relaciones complejas sin necesidad de mapping objeto-relacional. Aunque los SGBD relacionales dominan el mercado, BDOO tienen ventajas en aplicaciones con modelos de dominio complejos, como sistemas de información geográfica (GIS) o CAD.

8.3. OLAP y Data Warehousing

Los sistemas OLAP (Online Analytical Processing) optimizan consultas analíticas complejas sobre grandes volúmenes históricos de datos, contrastando con sistemas OLTP (Online Transaction Processing) optimizados para transacciones cortas y frecuentes. Los sistemas OLAP organizan datos en estructuras multidimensionales (cubos) que permiten análisis rápido mediante operaciones de drill-down, roll-up, slice y dice.

Existen tres arquitecturas OLAP principales. MOLAP (Multidimensional OLAP) almacena datos precalculados en estructuras multidimensionales propietarias, ofreciendo máximo rendimiento pero consumiendo más espacio. ROLAP (Relational OLAP) almacena datos en tablas relacionales, generando consultas SQL dinámicamente, consumiendo menos espacio pero con rendimiento inferior. HOLAP (Hybrid OLAP) combina ambos enfoques, almacenando agregaciones en MOLAP y detalle en ROLAP.

8.4. Herramientas ETL

Los procesos ETL (Extract, Transform, Load) extraen datos de múltiples fuentes heterogéneas, los transforman aplicando reglas de limpieza, validación, agregación y enriquecimiento, y los cargan en un data warehouse para análisis. En el SAS, Oracle Data Integrator (ODI) extrae datos de Diraya, BDU, sistemas de gestión económica y recursos humanos, transformándolos en un modelo dimensional unificado en InfoWeb.

8.5. Big Data y Hadoop

Apache Hadoop es un framework de procesamiento distribuido para grandes volúmenes de datos (Big Data). El componente central es HDFS (Hadoop Distributed File System), que almacena archivos grandes fragmentados y replicados en múltiples nodos commodity hardware. MapReduce proporciona el modelo de programación para procesamiento paralelo distribuido.

9. SGBD Comerciales y Open Source en el SAS

9.1. Oracle Database

Oracle Database es el SGBD relacional líder del mercado enterprise, utilizado extensivamente en el SAS para sistemas críticos. Oracle 19c, la versión Long Term Support actual, proporciona alta disponibilidad mediante RAC, disaster recovery con Data Guard, gestión automática de almacenamiento con ASM, particionamiento avanzado de tablas, compresión de datos, cifrado transparente (TDE), y herramientas de monitorización como AWR y ASH (Active Session History).

9.2. PostgreSQL

PostgreSQL es el SGBD relacional open source más avanzado, ofreciendo características enterprise como transacciones ACID completas, integridad referencial, triggers complejos, procedimientos almacenados en múltiples lenguajes (PL/pgSQL, Python, Perl), vistas materializadas, índices avanzados (B-tree, Hash, GiST, GIN, BRIN), soporte JSON nativo, full-text search, y replicación streaming.

9.3. MariaDB y MySQL

MariaDB es un fork de MySQL creado por los desarrolladores originales tras la adquisición de MySQL por Oracle. Ambos SGBD son ampliamente utilizados en aplicaciones web por su simplicidad, rendimiento y licencia open source. En el SAS, MySQL/MariaDB se emplean en aplicaciones departamentales, sistemas de gestión de contenidos (CMS) y portales web no críticos.

9.4. MongoDB

MongoDB es el SGBD NoSQL documental líder, almacenando datos en documentos BSON (Binary JSON) con esquema flexible. Proporciona escalabilidad horizontal mediante sharding automático, alta disponibilidad con replica sets, consultas ricas incluyendo agregaciones, índices secundarios, y búsqueda geoespacial. En el SAS, MongoDB se evalúa para casos de uso con datos semiestructurados como logs de aplicaciones, telemetría de dispositivos IoMT, y formularios clínicos con estructura variable por especialidad.

9.5. Microsoft SQL Server

SQL Server es el SGBD relacional de Microsoft, integrado profundamente con el ecosistema Windows y Azure. Ofrece alta disponibilidad mediante AlwaysOn Availability Groups, análisis in-database con servicios de integración (SSIS), análisis (SSAS) y reporting (SSRS), y soporte nativo de procedimientos almacenados .NET CLR. Aunque menos prevalente en el SAS que Oracle, SQL Server se utiliza en algunas aplicaciones desarrolladas sobre plataforma Microsoft.

10. Casos Prácticos del SAS

10.1. Optimización de Rendimiento en Diraya

10.2. Implementación de Disaster Recovery

-- Primaria: Habilitar FORCE LOGGING
ALTER DATABASE FORCE LOGGING;

-- Primaria: Configurar parámetros Data Guard
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(diraya_prod,diraya_dr)';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=diraya_dr ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=diraya_dr';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

-- Standby: Habilitar REAL TIME APPLY
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
                    

10.3. Migración de Base de Datos Legacy

10.4. Diseño de Base de Datos para Nuevo Sistema

-- Tabla de Centros Sanitarios
CREATE TABLE centros (
    id_centro NUMBER PRIMARY KEY,
    nombre VARCHAR2(200) NOT NULL,
    codigo_centro VARCHAR2(10) UNIQUE NOT NULL,
    provincia VARCHAR2(50),
    tipo_centro VARCHAR2(20) CHECK (tipo_centro IN ('CS', 'HOSPITAL', 'DCCU'))
);

-- Tabla de Profesionales
CREATE TABLE profesionales (
    id_profesional NUMBER PRIMARY KEY,
    cnp VARCHAR2(15) UNIQUE NOT NULL,
    nombre_completo VARCHAR2(200) NOT NULL,
    especialidad VARCHAR2(100),
    id_centro NUMBER REFERENCES centros(id_centro)
);

-- Tabla de Agendas
CREATE TABLE agendas (
    id_agenda NUMBER PRIMARY KEY,
    id_profesional NUMBER REFERENCES profesionales(id_profesional),
    fecha DATE NOT NULL,
    hora_inicio TIMESTAMP NOT NULL,
    hora_fin TIMESTAMP NOT NULL,
    duracion_cita NUMBER DEFAULT 10, -- minutos
    estado VARCHAR2(20) CHECK (estado IN ('ACTIVA', 'BLOQUEADA', 'CANCELADA')),
    CONSTRAINT uk_agenda UNIQUE (id_profesional, fecha, hora_inicio)
);

-- Tabla de Citas
CREATE TABLE citas (
    id_cita NUMBER PRIMARY KEY,
    nuhsa VARCHAR2(20) NOT NULL,
    id_agenda NUMBER REFERENCES agendas(id_agenda),
    fecha_solicitud TIMESTAMP DEFAULT SYSTIMESTAMP,
    motivo VARCHAR2(500),
    estado VARCHAR2(20) CHECK (estado IN ('SOLICITADA', 'CONFIRMADA', 'ANULADA', 'ATENDIDA', 'NO_ACUDE')),
    fecha_confirmacion TIMESTAMP,
    fecha_anulacion TIMESTAMP,
    usuario_anulacion VARCHAR2(50)
);

-- Tabla de Auditoría
CREATE TABLE auditoria_citas (
    id_auditoria NUMBER PRIMARY KEY,
    id_cita NUMBER REFERENCES citas(id_cita),
    accion VARCHAR2(50),
    usuario VARCHAR2(100),
    fecha TIMESTAMP DEFAULT SYSTIMESTAMP,
    ip_origen VARCHAR2(45),
    datos_anteriores CLOB,
    datos_nuevos CLOB
);

-- Índices para optimización
CREATE INDEX idx_citas_nuhsa ON citas(nuhsa);
CREATE INDEX idx_citas_agenda ON citas(id_agenda);
CREATE INDEX idx_citas_estado ON citas(estado);
CREATE INDEX idx_agendas_prof_fecha ON agendas(id_profesional, fecha);
CREATE INDEX idx_auditoria_fecha ON auditoria_citas(fecha);
                    

11. Cuestionario de 30 Preguntas (Exámenes Reales SAS)

⚠️ IMPORTANTE: Todas estas preguntas están extraídas de exámenes reales del SAS de los años 2019, 2023 y 2025 (OEP Libre, Promoción Interna, Técnico Titulado Medio, Agencia Sanitaria). Son el mejor material de estudio porque reflejan exactamente el nivel y el enfoque que encontrarás en tu examen. Estudia cada pregunta a fondo, comprendiendo no solo la respuesta correcta sino también por qué las otras opciones son incorrectas.