Título oficial del programa: Los sistemas de gestión de bases de datos (SGBD). Modelos y arquitecturas: bases de datos centralizadas y distribuidas, bases de datos federadas, bases de datos no relacionales: clave valor, documentales, de objetos, grafos, columnares. Motores de indexación. El modelo de referencia ANSI. Monitor de transacciones. Control de concurrencia. Bloqueos. Recuperación de errores. Integridad.
Definición y propósito. Un Sistema de Gestión de Bases de Datos (SGBD), o Database Management System (DBMS), es un conjunto de programas diseñados para gestionar grandes volúmenes de información de forma centralizada. Su objetivo es proporcionar un entorno seguro y eficiente para almacenar, organizar, manipular y recuperar datos, superando las limitaciones de los sistemas de ficheros tradicionales, como la redundancia, la inconsistencia y la dificultad de acceso concurrente.
Intermediación entre datos y usuarios. El SGBD funciona como una capa intermedia entre los datos físicos almacenados y los usuarios o aplicaciones que requieren interactuar con ellos. Esta abstracción permite que los usuarios trabajen con los datos sin necesidad de conocer su ubicación física o su estructura interna, facilitando la independencia lógica y física. Por ejemplo, un cambio en la ubicación de los datos en disco no afecta a las aplicaciones que los consultan.
Funcionalidades clave. Entre las funciones esenciales de un SGBD destacan la definición de datos (mediante lenguajes como DDL), la manipulación de datos (con lenguajes como DML o SQL), el control de acceso (autenticación, autorización y auditoría), la gestión de transacciones (para garantizar propiedades ACID) y la recuperación ante fallos (mediante backups y logs de transacciones). Además, incorpora mecanismos de control de concurrencia para evitar inconsistencias cuando múltiples usuarios acceden simultáneamente a los mismos datos.
Modelos de datos. Los SGBD se clasifican según el modelo de datos que soportan. El modelo relacional es el más extendido en entornos empresariales y sanitarios, organizando los datos en tablas interrelacionadas mediante claves primarias y foráneas. Otros modelos incluyen los NoSQL (clave-valor, documentales, columnares o grafos), los objeto-relacionales (que combinan características de ambos) y los NewSQL, que buscan escalabilidad horizontal sin renunciar a las garantías ACID.
Componentes internos. Un SGBD está compuesto por varios subsistemas, como el motor de la base de datos (optimizador de consultas y gestor de transacciones), el diccionario de datos (que almacena metadatos sobre la estructura de la base de datos), y los subsistemas DDL, DML, DCL y TCL. Estos componentes trabajan de forma coordinada para garantizar la coherencia, disponibilidad y seguridad de los datos.
Seguridad y protección. La seguridad en un SGBD es crítica, especialmente en entornos como el sanitario, donde se manejan datos sensibles. Los SGBD implementan mecanismos como el cifrado (en tránsito y en reposo), la autenticación y autorización (mediante roles y permisos), la auditoría (registro de accesos) y el enmascaramiento de datos (data masking). Estos controles aseguran que solo los usuarios autorizados puedan acceder a la información y que las operaciones queden registradas para su trazabilidad.
Alta disponibilidad y recuperación. Para garantizar la continuidad del servicio, los SGBD incorporan técnicas como el clustering (agrupación de servidores para distribuir la carga) y la replicación (copias síncronas o asíncronas de los datos en diferentes nodos). Estos mecanismos permiten recuperar el sistema ante fallos, minimizando el tiempo de inactividad y asegurando la disponibilidad de los datos en todo momento.
Aplicación en el SAS. En el contexto del Servicio Andaluz de Salud, los SGBD son fundamentales para gestionar sistemas críticos como la historia clínica electrónica, la gestión de pacientes o la facturación. Su capacidad para garantizar la integridad transaccional, soportar usuarios concurrentes y proteger información sensible los convierte en una herramienta indispensable para la administración fiable de datos persistentes.
Has leído la base del tema. En la demo puedes convertirlo en preguntas justificadas de Técnico/a Especialista en Informática y repasar tus fallos.
Probar demo gratis con preguntas de este temaBases de datos centralizadas. En este modelo, todos los datos residen en un único servidor o nodo, lo que simplifica la administración, el control de acceso y la coherencia de los datos. Este enfoque es común en entornos donde la escalabilidad no es un requisito crítico, como sistemas departamentales o aplicaciones con volúmenes de datos moderados. Sin embargo, presenta limitaciones en términos de disponibilidad, ya que un fallo en el servidor central puede dejar inaccesible toda la base de datos. Además, el rendimiento puede degradarse bajo cargas elevadas de usuarios concurrentes.
Bases de datos distribuidas. En contraste, las bases de datos distribuidas reparten los datos entre múltiples nodos interconectados, lo que permite mejorar la disponibilidad, la tolerancia a fallos y el rendimiento. Este modelo es esencial en entornos donde los datos deben estar accesibles desde diferentes ubicaciones geográficas, como en el caso de sistemas sanitarios regionales. La distribución puede ser horizontal (particionamiento de tablas) o vertical (división por funciones o departamentos). No obstante, la gestión de la consistencia y la sincronización entre nodos añade complejidad, requiriendo mecanismos como réplicas, protocolos de consenso o transacciones distribuidas.
Bases de datos federadas. Este modelo integra múltiples bases de datos independientes bajo una capa lógica unificada, permitiendo consultas globales sin necesidad de migrar o modificar los sistemas originales. Cada base de datos federada mantiene su autonomía, esquema y gestión, mientras que un middleware o capa de federación se encarga de traducir y dirigir las consultas a los sistemas subyacentes. Este enfoque es útil en entornos heterogéneos, como la integración de sistemas sanitarios con diferentes SGBD, aunque puede presentar desafíos en términos de rendimiento y consistencia semántica.
Modelos no relacionales (NoSQL). Diseñados para superar las limitaciones de los modelos relacionales en escenarios de alta escalabilidad o datos no estructurados, los SGBD NoSQL se clasifican en varios tipos. El modelo clave-valor almacena pares de identificadores únicos y datos asociados, siendo ideal para cachés o sesiones de usuario. El modelo documental gestiona datos en formato JSON o XML, permitiendo estructuras flexibles y jerárquicas, útiles para historiales clínicos o catálogos. El modelo columnar organiza los datos por columnas en lugar de filas, optimizando consultas analíticas y almacenamiento en sistemas como Apache Cassandra. El modelo de grafos representa relaciones complejas entre entidades, como redes sociales o rutas de derivación sanitaria, utilizando nodos, aristas y propiedades. Finalmente, el modelo orientado a objetos almacena datos como objetos, integrando atributos y métodos, aunque su adopción es menos extendida.
Arquitecturas híbridas y NewSQL. En entornos modernos, es común combinar diferentes modelos y arquitecturas para aprovechar sus ventajas. Por ejemplo, un sistema sanitario puede emplear bases de datos relacionales para datos estructurados (como registros administrativos) y NoSQL para datos no estructurados (como imágenes médicas o logs). Además, los sistemas NewSQL buscan combinar las garantías ACID de los modelos relacionales con la escalabilidad horizontal de los NoSQL, siendo relevantes en aplicaciones que requieren transacciones distribuidas y alto rendimiento, como la gestión de citas o inventarios en tiempo real.
Aplicación en el Servicio Andaluz de Salud (SAS). En el SAS, la elección de modelos y arquitecturas responde a necesidades específicas de los sistemas de información. Por ejemplo, la historia clínica electrónica Diraya podría emplear una arquitectura distribuida para garantizar acceso desde cualquier centro sanitario, combinando nodos locales con réplicas para alta disponibilidad. Los sistemas de citas o farmacia hospitalaria podrían optar por modelos centralizados o distribuidos según su criticidad y volumen de datos. Además, la integración de sistemas heterogéneos podría requerir enfoques federados, mientras que el almacenamiento de datos no estructurados (como informes médicos) podría beneficiarse de modelos documentales o clave-valor.
Criterios de selección. La elección entre modelos y arquitecturas depende de factores como el tipo de datos, los requisitos de escalabilidad, la necesidad de consistencia y las restricciones de rendimiento. Las bases de datos centralizadas son adecuadas para entornos controlados con baja concurrencia, mientras que las distribuidas son esenciales en sistemas críticos con alta disponibilidad. Los modelos NoSQL son ideales para datos no estructurados o semiestructurados, y las bases de datos federadas facilitan la integración de sistemas legacy sin migrar datos. En el SAS, estos criterios se alinean con normativas como la Ley 41/2002, que exige integridad y accesibilidad de la historia clínica, y el Esquema Nacional de Seguridad (ENS), que impone requisitos de disponibilidad y protección de datos.
SELECT, pero pueden ralentizar operaciones de escritura como INSERT, UPDATE o DELETE.Definición y propósito. Un motor de indexación es un subsistema de los sistemas de gestión de bases de datos (SGBD) que crea, mantiene y gestiona estructuras de datos denominadas índices. Estas estructuras optimizan el rendimiento de las operaciones de consulta al permitir la recuperación eficiente de información sin examinar cada registro de una tabla. En el contexto del Servicio Andaluz de Salud (SAS), donde se manejan grandes volúmenes de datos clínicos y administrativos, los motores de indexación son fundamentales para garantizar tiempos de respuesta adecuados en aplicaciones críticas como la historia clínica electrónica o la gestión de citas.
Estructura y funcionamiento. Un índice funciona como un mapa auxiliar que establece una correspondencia entre los valores de una o varias columnas (claves de indexación) y las ubicaciones físicas de los registros en el almacenamiento. Esta estructura permite localizar datos mediante algoritmos avanzados, como árboles balanceados (B-tree) o funciones hash, en lugar de realizar escaneos secuenciales (full table scans). Por ejemplo, en una tabla de pacientes, un índice sobre la columna id_paciente permite localizar rápidamente un registro sin recorrer toda la tabla.
Tipos de índices. Los motores de indexación soportan diversos tipos de índices, cada uno optimizado para escenarios específicos. Los índices B-tree son los más comunes y se utilizan para consultas de igualdad, rangos y ordenaciones. Los índices hash son eficientes para búsquedas exactas, pero no soportan rangos ni ordenaciones. Los índices bitmap son ideales para columnas con baja cardinalidad, como sexo o estado_civil, aunque su actualización es costosa. En entornos sanitarios, también se emplean índices de texto completo para búsquedas en campos de texto largo, como historiales clínicos, e índices compuestos para consultas que filtran por múltiples columnas, como fecha y id_centro.
Impacto en el rendimiento. Los índices mejoran significativamente el rendimiento de las consultas SELECT, especialmente en tablas grandes, al reducir el número de registros que deben examinarse. Sin embargo, esta optimización tiene un coste: las operaciones de escritura (INSERT, UPDATE, DELETE) se ralentizan, ya que el SGBD debe actualizar tanto los datos como los índices asociados. En el SAS, se recomienda crear índices en columnas frecuentemente utilizadas en cláusulas WHERE, JOIN o ORDER BY, como id_paciente, fecha_cita o código_diagnóstico (CIE-10-ES), para optimizar búsquedas en historias clínicas.
Índices en bases de datos NoSQL. Los motores de indexación en bases de datos NoSQL presentan particularidades según el modelo de datos. En MongoDB, se utilizan índices B-tree para consultas de igualdad y rangos, así como índices geoespaciales para datos de ubicación. Cassandra emplea LSM-trees para índices primarios, mientras que los índices secundarios son menos eficientes y no soportan consultas con IN o OR. Elasticsearch, basado en Apache Lucene, utiliza índices invertidos para búsquedas de texto completo, permitiendo tokenizar y normalizar texto mediante analizadores específicos.
Índices en data warehouses sanitarios. En el contexto del SAS, los data warehouses se utilizan para analizar indicadores de salud pública, como la prevalencia de enfermedades o el consumo de recursos. Estos sistemas requieren índices optimizados para consultas analíticas. Por ejemplo, los índices bitmap son útiles para acelerar consultas sobre columnas con baja cardinalidad, como grupo_edad, mientras que los índices BRIN (Block Range Index) son eficientes en tablas ordenadas físicamente por fecha, como registros de ingresos hospitalarios.
Optimizador de consultas y selección de índices. El optimizador de consultas del SGBD decide en tiempo de compilación si utilizar un índice y cuál emplear, basándose en estadísticas sobre la distribución de los datos almacenadas en el catálogo del sistema. Este componente estima el coste de distintos planes de ejecución y elige el de menor coste estimado. Sin embargo, un índice puede existir en el catálogo y no ser utilizado si el optimizador determina que un escaneo completo es más eficiente, por ejemplo, cuando la consulta devuelve una alta proporción de filas o las estadísticas están desactualizadas. Por ello, es fundamental mantener las estadísticas actualizadas mediante comandos como ANALYZE en PostgreSQL o DBMS_STATS en Oracle.
sexo o estado_civil, aunque su actualización es costosa.id_paciente.ANALYZE o DBMS_STATS.SELECT, pero ralentizan las operaciones de escritura.WHERE, JOIN o ORDER BY.Origen y propósito. El modelo de referencia ANSI/SPARC fue desarrollado en la década de 1970 por el American National Standards Institute (ANSI) y el Standards Planning And Requirements Committee (SPARC) como marco conceptual para estandarizar la estructura de los SGBD. Aunque no se convirtió en un estándar formal, su arquitectura en tres niveles se consolidó como modelo de referencia fundamental en el diseño de bases de datos, influyendo en la mayoría de los SGBD comerciales.
Niveles de abstracción. La arquitectura ANSI/SPARC establece tres niveles de abstracción: externo, conceptual e interno. Cada nivel cumple una función específica y se relaciona con los demás mediante mecanismos de mapeo. Esta separación permite que los cambios en un nivel no afecten a los otros, garantizando flexibilidad y escalabilidad en los sistemas de información.
Nivel externo. Este nivel representa la interfaz entre los usuarios o aplicaciones y la base de datos. Consiste en un conjunto de vistas o esquemas externos que describen cómo perciben los datos los diferentes grupos de usuarios. Cada vista puede adaptarse a las necesidades específicas de un usuario o aplicación, ocultando información irrelevante o sensible. Por ejemplo, un médico podría acceder a una vista con historiales clínicos, mientras que un administrativo vería solo datos de facturación.
Nivel conceptual. El nivel conceptual define el esquema lógico global de la base de datos, incluyendo entidades, relaciones, restricciones y semántica. Es independiente del hardware y del almacenamiento físico, y su gestión corresponde al administrador de la base de datos (DBA). Este nivel actúa como puente entre las vistas externas y el almacenamiento interno, asegurando la coherencia y la integridad de los datos.
Nivel interno. El nivel interno describe cómo se almacenan físicamente los datos en el soporte de almacenamiento, como discos magnéticos o SSDs. Incluye elementos como estructuras de ficheros, índices, tamaños de bloque, rutas de acceso y parámetros de compresión o cifrado. Este nivel es el único que tiene relación directa con el hardware y el sistema operativo, y su optimización es clave para el rendimiento del SGBD.
Independencia de datos. La arquitectura ANSI/SPARC persigue dos tipos de independencia de datos: lógica y física. La independencia lógica permite modificar el esquema conceptual sin afectar a las vistas externas, mientras que la independencia física permite cambiar el almacenamiento interno sin alterar el esquema conceptual. Estos principios reducen el acoplamiento entre niveles y facilitan la evolución tecnológica sin reescribir la lógica de las aplicaciones.
Aplicación en el SAS. En el Servicio Andaluz de Salud (SAS), sistemas como Diraya, ClicSalud+ y la prescripción electrónica siguen este modelo. Por ejemplo, Diraya utiliza vistas externas para médicos, un esquema conceptual con entidades clínicas y un nivel interno con índices en el número de historia clínica (NHC). Esta arquitectura facilita el cumplimiento de normativas como el RGPD y la LOPDGDD, garantizando seguridad y eficiencia en el acceso a los datos.
CREATE VIEW.Definición y alcance. El monitor de transacciones, también denominado gestor de transacciones o Transaction Manager, es un componente fundamental de los Sistemas de Gestión de Bases de Datos (SGBD). Su ámbito de actuación se centra en la coordinación de transacciones, entendidas como unidades lógicas de trabajo indivisibles que agrupan una o más operaciones sobre los datos. Este componente no debe confundirse con otros módulos del SGBD, como el gestor de almacenamiento o el optimizador de consultas, ya que su función es exclusiva de la supervisión transaccional.
Propiedades ACID. El monitor de transacciones garantiza el cumplimiento de las propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad), esenciales para la fiabilidad de los datos. La atomicidad asegura que una transacción se ejecute en su totalidad o no se ejecute en absoluto, evitando estados intermedios inconsistentes. La consistencia garantiza que la base de datos pase de un estado válido a otro, respetando las restricciones definidas. El aislamiento impide que transacciones concurrentes interfieran entre sí, mientras que la durabilidad asegura que los cambios confirmados persistan incluso ante fallos del sistema.
Ciclo de vida de una transacción. El monitor de transacciones controla cada fase del ciclo de vida de una transacción: inicio, ejecución, confirmación (commit) o reversión (rollback). Al iniciar una transacción, el monitor registra su comienzo en el transaction log y asigna los recursos necesarios. Durante la ejecución, supervisa las operaciones para detectar posibles conflictos o errores. Si todas las operaciones se completan correctamente, el monitor confirma la transacción (commit), aplicando los cambios de forma permanente. En caso de error, revierte la transacción (rollback), deshaciendo todos los cambios realizados hasta ese momento.
Control de concurrencia. Para evitar interferencias entre transacciones simultáneas, el monitor de transacciones implementa mecanismos de control de concurrencia, como el gestor de bloqueos y los niveles de aislamiento. El gestor de bloqueos administra los bloqueos sobre los recursos (tablas, filas, etc.) para evitar conflictos, mientras que los niveles de aislamiento definen el grado de visibilidad de los datos entre transacciones. Los niveles más comunes, ordenados de menor a mayor restricción, son: Read Uncommitted, Read Committed, Repeatable Read y Serializable.
Recuperación ante fallos. El monitor de transacciones incluye un gestor de recuperación que restaura la base de datos a un estado consistente tras un fallo. Para ello, utiliza el transaction log, donde se registran todas las operaciones antes de aplicarlas a la base de datos (Write-Ahead Logging). En caso de fallo, el gestor de recuperación rehace las operaciones confirmadas y deshace las no confirmadas, garantizando la integridad de los datos. Este mecanismo es crítico en entornos como el Servicio Andaluz de Salud (SAS), donde la fiabilidad de los sistemas de información sanitaria es prioritaria.
Transacciones distribuidas. En entornos distribuidos, donde una transacción puede afectar a múltiples nodos, el monitor de transacciones emplea protocolos como el Two-Phase Commit (2PC). Este protocolo coordina la confirmación o reversión de la transacción en todos los nodos involucrados, asegurando que todos apliquen los cambios o ninguno lo haga. Este enfoque es esencial para sistemas interoperables, como los utilizados en el SAS para el intercambio de datos entre Atención Primaria y Hospitalaria.
Aplicación en el SAS. En el Servicio Andaluz de Salud (SAS), el monitor de transacciones es un componente crítico en sistemas como la Historia Clínica Electrónica (HCE) o el Sistema de Gestión de Pacientes (HIS). Garantiza que operaciones como el registro de diagnósticos, la prescripción de medicamentos o la asignación de citas se ejecuten de forma atómica y consistente, evitando inconsistencias en los datos clínicos. Además, en sistemas como Diraya, asegura que operaciones como ingresos, altas o facturación se completen correctamente o se reviertan en caso de error.
Marco normativo y técnico. El monitor de transacciones se enmarca en el modelo de referencia ANSI/SPARC para arquitecturas de bases de datos, específicamente en la capa de gestión de transacciones (nivel lógico). Este modelo establece tres niveles de abstracción: externo (vistas de los usuarios), conceptual (esquema lógico global) e interno (estructura física de almacenamiento). El monitor de transacciones opera principalmente en el nivel conceptual, coordinando las operaciones lógicas que afectan al esquema global de la base de datos.
Definición y propósito. El control de concurrencia es el conjunto de mecanismos que un Sistema de Gestión de Bases de Datos (SGBD) implementa para gestionar el acceso simultáneo de múltiples usuarios o procesos a los datos. Su finalidad es preservar la integridad y la consistencia de la base de datos, evitando que operaciones concurrentes generen resultados incorrectos o inconsistentes. Este control es esencial en entornos multiusuario, como los sistemas sanitarios, donde múltiples aplicaciones o usuarios acceden y modifican datos críticos de forma simultánea.
Anomalías de concurrencia. Cuando no existe un control adecuado, pueden producirse anomalías como lecturas sucias (una transacción lee datos modificados por otra que aún no ha confirmado), actualizaciones perdidas (dos transacciones modifican el mismo dato sin coordinación), lecturas no repetibles (una transacción obtiene resultados distintos al repetir una consulta) o lecturas fantasma (aparecen filas nuevas que cumplen una condición durante la ejecución de una transacción). Estas anomalías violan la propiedad de aislamiento y pueden comprometer la fiabilidad de los datos.
Modelo ACID y aislamiento. El control de concurrencia está estrechamente ligado a la propiedad de aislamiento del modelo ACID, que garantiza que las transacciones se ejecuten de forma aislada unas de otras. El objetivo es que el resultado de las transacciones concurrentes sea equivalente al que se obtendría si se ejecutaran de forma secuencial. Este principio se formaliza mediante el concepto de serializabilidad, que asegura que el plan de ejecución (schedule) de las transacciones sea equivalente a algún orden serial de las mismas, preservando así la consistencia de los datos.
Mecanismos de control. Los SGBD emplean principalmente dos mecanismos para gestionar la concurrencia: los bloqueos y el control de concurrencia multiversión (MVCC). Los bloqueos impiden que dos operaciones incompatibles actúen simultáneamente sobre los mismos recursos, utilizando bloqueos compartidos para lecturas y exclusivos para escrituras. Por su parte, el MVCC mantiene versiones históricas de los datos, permitiendo que las lecturas accedan a instantáneas consistentes sin bloquear las escrituras, lo que mejora la concurrencia en entornos con alta demanda de consultas.
Niveles de aislamiento SQL. El estándar SQL define cuatro niveles de aislamiento que gradúan el equilibrio entre consistencia y concurrencia: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ y SERIALIZABLE. Cada nivel determina qué anomalías se permiten y cuáles se evitan. Por ejemplo, READ UNCOMMITTED permite lecturas sucias, mientras que SERIALIZABLE evita todas las anomalías, garantizando la máxima consistencia pero reduciendo la concurrencia. El nivel predeterminado varía según el SGBD y su configuración.
Bloqueos granulares. Los SGBD permiten aplicar bloqueos a distintos niveles de granularidad para equilibrar concurrencia y sobrecarga. Los bloqueos pueden ser de tabla (afectan a toda la tabla), de página (afectan a un bloque de datos en disco), de fila (afectan a una única fila) o de predicado (bloquean filas que cumplen una condición). Los bloqueos de fila ofrecen la máxima concurrencia, pero conllevan una mayor sobrecarga de gestión, mientras que los bloqueos de tabla son más restrictivos pero menos costosos en términos de recursos.
Modos de bloqueo. Los bloqueos pueden ser de tres tipos principales: compartidos (S), exclusivos (X) y de actualización (U). Los bloqueos compartidos permiten lecturas concurrentes pero bloquean escrituras, mientras que los exclusivos bloquean tanto lecturas como escrituras. Los bloqueos de actualización se utilizan para evitar interbloqueos (deadlocks) en operaciones de lectura-modificación, ya que se convierten en exclusivos al realizar la escritura. La compatibilidad entre bloqueos determina si una transacción puede adquirir un bloqueo sobre un recurso que ya está bloqueado por otra.
Definición y propósito. Los bloqueos son mecanismos lógicos que controlan el acceso simultáneo a recursos compartidos en una base de datos, como filas, páginas, tablas o índices. Su objetivo principal es evitar conflictos que puedan comprometer la integridad de los datos, actuando como semáforos que regulan qué transacciones pueden acceder a un recurso y en qué condiciones. Este control es esencial para implementar los niveles de aislamiento definidos en el estándar SQL, como Read Committed o Serializable.
Granularidad de los bloqueos. Los SGBD permiten bloqueos a distintos niveles para equilibrar concurrencia y sobrecarga. El bloqueo de tabla afecta a toda la tabla y es útil para operaciones masivas, pero reduce la concurrencia. El bloqueo de página actúa sobre un bloque de datos en disco, siendo menos restrictivo. El bloqueo de fila se aplica a una única fila, ofreciendo máxima concurrencia pero con mayor sobrecarga de gestión. También existe el bloqueo de predicado, que bloquea filas que cumplen una condición específica, utilizado en niveles de aislamiento altos.
Modos de bloqueo básicos. Los modos de bloqueo determinan qué operaciones pueden realizarse sobre un recurso mientras el bloqueo está activo. El bloqueo compartido (S) permite lecturas concurrentes pero bloquea escrituras, siendo compatible con otros bloqueos S. El bloqueo exclusivo (X) bloquea tanto lecturas como escrituras, impidiendo que otras transacciones accedan al recurso en cualquier modo. El bloqueo de actualización (U) se utiliza para evitar deadlocks en operaciones de lectura-modificación, convirtiéndose en X cuando se realiza la escritura.
Compatibilidad entre bloqueos. La compatibilidad entre modos de bloqueo se representa mediante matrices que indican qué combinaciones pueden coexistir. Por ejemplo, un bloqueo S es compatible con otro S, pero incompatible con un X. Esta compatibilidad es fundamental para evitar conflictos y garantizar que las transacciones no interfieran entre sí. Los SGBD verifican estas reglas antes de conceder un bloqueo, haciendo que las transacciones esperen si el recurso está bloqueado en un modo incompatible.
Bloqueos de intención. En entornos con alta concurrencia y acceso a múltiples niveles de granularidad, los SGBD implementan bloqueos de intención para optimizar la gestión. Estos bloqueos se aplican sobre nodos de nivel superior (como tablas) e indican la intención de adquirir bloqueos en niveles inferiores (como filas). Los principales son IS (Intention Shared), IX (Intention Exclusive) y SIX (Shared + Intention Exclusive), que permiten al SGBD verificar eficientemente si un bloqueo es posible sin explorar todos los bloqueos de niveles inferiores.
Bloqueos implícitos y explícitos. Los SGBD adquieren bloqueos de forma implícita durante la ejecución de sentencias SQL. Por ejemplo, las sentencias SELECT pueden adquirir bloqueos S según el nivel de aislamiento, mientras que INSERT, UPDATE y DELETE adquieren bloqueos X sobre las filas afectadas. Además, los usuarios pueden solicitar bloqueos explícitos mediante sentencias como SELECT ... FOR UPDATE, que adquiere un bloqueo X sobre las filas seleccionadas, o LOCK TABLE, que bloquea una tabla completa en un modo específico.
Patrones de uso. Los bloqueos son fundamentales en patrones como read-modify-write, donde una transacción lee un dato, lo procesa y lo actualiza. En estos casos, el uso de SELECT ... FOR UPDATE previene que otras transacciones modifiquen las filas bloqueadas hasta que la transacción actual finalice con COMMIT o ROLLBACK. Este mecanismo garantiza la coherencia en operaciones críticas, como la actualización de registros médicos o financieros.
SELECT ... FOR UPDATE o LOCK TABLE.SELECT ... FOR UPDATE es clave en patrones read-modify-write para evitar inconsistencias.Definición y objetivo. La recuperación de errores en sistemas de gestión de bases de datos (SGBD) es el conjunto de mecanismos diseñados para restaurar la consistencia e integridad de los datos tras la ocurrencia de fallos. Su finalidad es garantizar que, tras un incidente, la base de datos vuelva a un estado coherente, minimizando la pérdida de información y asegurando las propiedades ACID (atomicidad, consistencia, aislamiento y durabilidad) de las transacciones. Este proceso es crítico en entornos como el Servicio Andaluz de Salud (SAS), donde la disponibilidad y fiabilidad de los datos son prioritarias.
Tipos de fallos. Los fallos que afectan a un SGBD se clasifican en tres categorías. El fallo de transacción ocurre por errores lógicos o explícitos (como un ROLLBACK), requiriendo el undo de cambios no confirmados. El fallo del sistema, provocado por cortes de suministro o errores del sistema operativo, implica la pérdida de datos en memoria volátil y exige redo (reaplicar cambios confirmados) y undo (deshacer no confirmados). El fallo de medio, como un daño físico en el almacenamiento, requiere restaurar la base de datos desde backups y aplicar redo desde el último backup hasta el punto de fallo.
Write-Ahead Logging (WAL). Este principio técnico es fundamental para la recuperación. Establece que los registros del log deben escribirse en almacenamiento estable antes de que los cambios en los datos se confirmen en disco. Implementado en SGBD como PostgreSQL, Oracle y SQL Server, el WAL asegura que, en caso de fallo, los cambios puedan reconstruirse a partir de los registros almacenados. Esto evita la pérdida de transacciones confirmadas y garantiza la durabilidad.
Checkpoints. Son operaciones periódicas que sincronizan los datos en memoria con los almacenados en disco, reduciendo el tiempo necesario para la recuperación. Configurables mediante parámetros como checkpoint_timeout en PostgreSQL o LOG_CHECKPOINT_INTERVAL en Oracle, los checkpoints marcan un punto de referencia desde el cual se pueden reaplicar o deshacer cambios durante la recuperación. Su frecuencia y configuración impactan directamente en el rendimiento y la eficiencia del proceso.
Algoritmo ARIES. Este algoritmo, ampliamente utilizado en SGBD modernos, estructura la recuperación en tres fases. La fase de análisis identifica las transacciones activas y las páginas sucias (modificadas pero no escritas en disco) en el momento del fallo. La fase de redo reaplica los cambios confirmados desde el último checkpoint, asegurando que todas las transacciones completadas se reflejen en la base de datos. Finalmente, la fase de undo deshace los cambios de las transacciones no confirmadas, restaurando la consistencia.
Técnicas alternativas y complementarias. Además del WAL y ARIES, existen técnicas como Shadow Paging, que mantiene dos versiones de las páginas de datos (actual y sombra) para simplificar la recuperación. Sin embargo, esta técnica presenta limitaciones en escalabilidad y concurrencia. Otras herramientas complementarias incluyen los savepoints, que permiten deshacer parcialmente una transacción sin abortarla por completo, y el flashback de Oracle, que facilita la recuperación a un estado anterior sin necesidad de backups. El Point-in-Time Recovery (PITR) combina backups y logs para restaurar la base de datos a un momento específico en el pasado.
Replicación y alta disponibilidad. Para minimizar el impacto de los fallos, los SGBD incorporan técnicas de replicación como streaming replication en PostgreSQL o Data Guard en Oracle. Estas herramientas mantienen copias sincronizadas de la base de datos en servidores secundarios, permitiendo una recuperación casi instantánea ante fallos. En entornos críticos como el SAS, estas soluciones son esenciales para garantizar la continuidad del servicio y la protección de datos sensibles.
checkpoint_timeout impacta en el rendimiento y eficiencia de la recuperación.CHECK y acciones referenciales como CASCADE o SET NULL.Definición y propósito. La integridad en un Sistema de Gestión de Bases de Datos (SGBD) se refiere al conjunto de mecanismos, reglas y restricciones que aseguran que los datos sean precisos, coherentes y fiables. Su objetivo es evitar que la información pierda significado, se corrompa o se vuelva inconsistente, garantizando que los datos almacenados reflejen correctamente la realidad que representan. A diferencia de la seguridad, que protege contra accesos no autorizados, la integridad se centra en la validez estructural y semántica de los datos.
Tipos de integridad. El modelo relacional define tres categorías principales de integridad. La integridad de dominio valida que los valores de un atributo pertenezcan al dominio definido, incluyendo restricciones de tipo de dato, rango o formato. La integridad de entidad asegura que cada registro sea único mediante claves primarias, impidiendo valores nulos en los atributos que las componen. La integridad referencial garantiza que las relaciones entre tablas sean consistentes, evitando referencias huérfanas mediante claves foráneas y acciones como CASCADE, SET NULL o RESTRICT.
Mecanismos de implementación. Los SGBD implementan la integridad mediante restricciones declarativas en SQL. Las claves primarias (PRIMARY KEY) aseguran la unicidad de cada registro, mientras que las claves foráneas (FOREIGN KEY) mantienen relaciones válidas entre tablas. Las restricciones CHECK permiten definir condiciones lógicas para validar valores, y NOT NULL evita que un atributo tenga valores nulos. Además, las acciones referenciales (ON DELETE, ON UPDATE) determinan el comportamiento del sistema ante modificaciones o eliminaciones en tablas relacionadas.
Integridad y transacciones. Las propiedades ACID de las transacciones son esenciales para preservar la integridad en entornos concurrentes. La atomicidad garantiza que una transacción se ejecute completamente o no se ejecute, evitando estados intermedios inválidos. La consistencia asegura que una transacción lleve la base de datos de un estado válido a otro, cumpliendo todas las restricciones de integridad. El aislamiento impide que transacciones concurrentes interfieran entre sí, mientras que la durabilidad asegura que los cambios realizados por una transacción se mantengan incluso ante fallos del sistema.
Integridad semántica y avanzada. Además de las restricciones básicas, los SGBD permiten definir reglas semánticas mediante triggers o procedimientos almacenados. Estos mecanismos avanzados validan condiciones específicas del negocio, como la coherencia entre fechas o la unicidad de valores en columnas no primarias (UNIQUE). La auditoría también contribuye a la integridad, registrando cambios para mantener la validez y significado de los datos a lo largo del tiempo.
Riesgos y consideraciones. La falta de integridad puede generar datos inconsistentes, relaciones inválidas o pérdida de información crítica. Por ejemplo, una clave foránea mal gestionada puede crear registros huérfanos, mientras que una restricción de dominio insuficiente puede permitir valores incorrectos. Los SGBD deben equilibrar la rigidez de las restricciones con la flexibilidad operativa, ya que restricciones excesivas pueden limitar la funcionalidad del sistema.
Ejemplo práctico. En una base de datos sanitaria, la integridad referencial asegura que un paciente no pueda ser eliminado si tiene citas registradas, a menos que se defina una acción CASCADE que elimine automáticamente sus citas. La integridad de dominio garantiza que un campo como "fecha de nacimiento" solo acepte valores válidos, mientras que NOT NULL evita que atributos críticos, como el nombre del paciente, queden sin registrar.
CASCADE, SET NULL o RESTRICT.PRIMARY KEY): Identificador único de cada registro en una tabla, compuesto por uno o más atributos.FOREIGN KEY): Atributo que referencia la clave primaria de otra tabla, manteniendo la coherencia entre relaciones.CHECK: Valida condiciones lógicas en los valores de un atributo, como rangos o formatos específicos.NOT NULL: Evita que un atributo tenga valores nulos, garantizando que siempre contenga un dato.UNIQUE: Asegura que los valores de una columna no se repitan, aunque no sea clave primaria.ON DELETE, ON UPDATE): Definen el comportamiento del SGBD ante modificaciones o eliminaciones en tablas relacionadas.CASCADE, SET NULL, RESTRICT) determinan cómo se gestionan las dependencias entre tablas.CHECK, NOT NULL y UNIQUE validan valores y evitan datos inválidos o duplicados.Practica este tema de Técnico/a Especialista en Informática con test por tema SAS, preguntas justificadas por tema y simulacros tipo examen. No son preguntas oficiales del SAS: son práctica privada de OposAs para estudiar con criterio.
Acceder a la demoHas visto un tema abierto completo. En la demo puedes comprobar cómo encajan el temario, las preguntas justificadas y los simulacros dentro de OposAs.
Qué vas a probar
La idea no es solo leer un tema: es estudiar con continuidad y comprobar cómo se relaciona con el resto de herramientas.
Verás explicaciones de la correcta y de las incorrectas para estudiar con más criterio, no solo para memorizar.
Con tu nombre y tu email, eliges categoría y te enviamos el acceso por correo sin compromiso.
Solo tu email, tu nombre y apellidos (si quieres), elige categoría y prueba antes de decidir. Es gratis.
El acceso llega por email. Si usas Hotmail, Outlook, Live, MSN o Yahoo, revisa tambien Spam o Correo no deseado.
Despues de pulsar, mira tu correo. El enlace dura 1 hora.
Revisa tambien Spam o Correo no deseado.
Hemos enviado el enlace a . Abrelo antes de 1 hora. Si usas Hotmail, Outlook, Live, MSN o Yahoo, mira primero en Correo no deseado.
Estos son los requisitos principales para Técnico/a Especialista en Informática. OposAs resume los requisitos principales para orientarte; la convocatoria oficial vigente es siempre la referencia válida.
FP2 Rama Informática, Módulo Profesional Nivel 3, Técnico Superior en Administración de Sistemas Informáticos o Técnico Superior en Desarrollo de Aplicaciones Informáticas.
La convocatoria contempla equivalencia con tres años de funciones de la categoría en centros sanitarios del Sistema Nacional de Salud.
Contrasta el resumen antes de inscribirte.
Consulta siempre la convocatoria oficial vigente antes de inscribirte.
Fuera del código también hay música, discos y radio. La misma forma de hacer las cosas: con alma, pasión y criterio.
OposAs nació preparando una oposición del SAS y se ha convertido en una forma de practicar test, corregir fallos y estudiar con explicaciones claras.
OposAs está pensado para practicar test y aprender mientras corriges, sin tragarte textos interminables antes de empezar. Cuando fallas, la justificación te ayuda a entender la correcta y, sobre todo, las incorrectas: ahí suele estar el aprendizaje.
No hay una empresa detrás. Hay una persona que construyó desde cero una herramienta para que estudiar no se convierta en algo pesado, sino en un proceso más claro, practicable y llevadero.
De opositor a opositor, Serafín.
