Tema 33. 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.

Tema específico de Técnico/a Especialista en Informática

1. Los sistemas de gestión de bases de datos (SGBD)

🎯 Idea clave

  • El SGBD es el software especializado que permite definir, crear, almacenar, consultar, modificar, proteger, administrar y recuperar bases de datos, actuando como intermediario entre los datos físicos y las aplicaciones o usuarios.
  • La base de datos es el conjunto organizado de datos, mientras que el SGBD es el sistema que gobierna esos datos y habilita su gestión controlada y compartida.
  • El SGBD aporta servicios esenciales como lenguaje de definición y manipulación, control de integridad, seguridad, concurrencia, transacciones, recuperación y administración mediante catálogo o diccionario de datos.
  • Resuelve los problemas críticos del modelo tradicional de ficheros independientes: redundancia, inconsistencia, dificultad de acceso, falta de aislamiento, ausencia de control de concurrencia y carencia de mecanismos de seguridad y recuperación.
  • Constituye la pieza nuclear de la arquitectura de información en organizaciones complejas como el Servicio Andaluz de Salud, soportando sistemas críticos como Diraya, Receta XXI y las plataformas de información sanitaria.

📚 Desarrollo

Definición fundamental. Un sistema de gestión de bases de datos (SGBD), denominado en inglés Database Management System (DBMS), es el software especializado que permite definir, crear, almacenar, consultar, modificar, proteger, administrar y recuperar bases de datos. Actúa como capa intermedia entre los usuarios o aplicaciones y los datos almacenados físicamente en el sistema de ficheros, abstrayendo a los programas del detalle físico del almacenamiento.

Separación de conceptos. Es crucial distinguir entre la base de datos, que es el conjunto organizado y estructurado de datos relacionados, y el SGBD, que es el software que la administra y gobierna. Una tabla, un fichero de datos o un repositorio documental no constituyen por sí solos un SGBD; este incorpora servicios de lenguaje, control, seguridad, concurrencia, transacciones, recuperación, metadatos y administración que transforman el almacenamiento en un recurso gestionado, coherente y seguro.

Solución a limitaciones históricas. La finalidad esencial del SGBD es resolver los problemas que surgían con el modelo tradicional de ficheros independientes: la redundancia e inconsistencia de datos, la dificultad de acceso, la falta de aislamiento entre usuarios concurrentes, la inexistencia de control de concurrencia y la ausencia de mecanismos de seguridad y recuperación ante fallos del sistema.

Funciones principales. El SGBD aporta funciones de definición de datos mediante lenguajes DDL, manipulación mediante DML, control de concurrencia para accesos simultáneos, gestión de transacciones con propiedades ACID, mecanismos de recuperación ante errores, seguridad mediante control de accesos y auditoría, integridad de datos, control de redundancia, diccionario de datos centralizado y optimización de consultas.

Relevancia en el ámbito sanitario. En organizaciones complejas como el Servicio Andaluz de Salud, los SGBD constituyen una de las piezas más relevantes de la arquitectura de información, sirviendo de sustrato para sistemas críticos como Diraya, Receta XXI, sistemas de citación, departamentales de laboratorio, de imagen médica, administrativos, económicos y plataformas de información sanitaria, garantizando la disponibilidad y protección de la información esencial.

Componentes arquitectónicos. Un SGBD integra componentes como el parser de consultas, el optimizador, el motor de ejecución, y gestores especializados de buffer, almacenamiento físico, transacciones, bloqueos, registros de log para recuperación, seguridad y copias de seguridad, además de estructuras físicas como tablas, índices de diversos tipos, vistas materializadas y particiones de datos.

Marco tecnológico y tipologías. El lenguaje estándar SQL sigue la norma ISO/IEC 9075, contemplando DDL, DML, DCL y TCL, mientras que el acceso se facilita mediante APIs como ODBC, JDBC y ADO.NET, o mediante ORMs como Hibernate, Entity Framework o SQLAlchemy. Existen diversas tipologías que incluyen sistemas relacionales, NoSQL documentales, de clave-valor, columnares y de grafos, así como variantes OLTP, OLAP, embebidos, en memoria y distribuidos.

🧩 Elementos esenciales

  • SGBD vs BD: El SGBD es el software gestor, mientras que la base de datos es el conjunto organizado de datos que administra; no son sinónimos.
  • Problemas resueltos: Elimina la redundancia e inconsistencia propias de los ficheros independientes tradicionales, centralizando la gestión.
  • Servicios fundamentales: Proporciona lenguaje, integridad, seguridad, concurrencia, transacciones, recuperación y catálogo mediante diccionario de datos.
  • Capa de abstracción: Separa los programas aplicativos del detalle físico del almacenamiento, facilitando la independencia lógica y física.
  • Transacciones ACID: Garantiza Atomicidad, Consistencia, Aislamiento y Durabilidad en las operaciones sobre la base de datos.
  • SQL estándar: Utiliza el lenguaje SQL conforme a la norma ISO/IEC 9075 con sus sublenguajes DDL, DML, DCL y TCL.
  • APIs de conexión: Soporta ODBC, JDBC y ADO.NET para la conectividad estandarizada con aplicaciones cliente.
  • ORMs: Permite el mapeo objeto-relacional mediante herramientas como Hibernate, Entity Framework o SQLAlchemy.
  • Componentes internos: Incluye parser, optimizador, motor de ejecución y gestores de buffer, transacciones, bloqueos, log y seguridad.
  • Estructuras físicas: Gestiona tablas, índices B-tree, hash, bitmap y full-text, vistas materializadas y particiones de datos.
  • Tipos de sistemas: Existen relacionales, NoSQL documentales, clave-valor, columnares, de grafos, OLTP, OLAP, embebidos e in-memory.

🧠 Recuerda

  • El SGBD es el software, la BD es el contenido; nunca son la misma cosa.
  • Un fichero o tabla sueltos no constituyen un SGBD sin los servicios de gestión y control.
  • El SGBD resuelve los problemas de redundancia y falta de concurrencia de los sistemas de ficheros antiguos.
  • Proporciona independencia lógica y física respecto a los datos almacenados.
  • Las transacciones deben cumplir las propiedades ACID para garantizar la integridad de la información.
  • Utiliza SQL como lenguaje estándar según la norma ISO/IEC 9075.
  • En el SAS, soporta sistemas críticos como Diraya, Receta XXI y plataformas de información sanitaria.
  • El diccionario de datos es un componente esencial del catálogo que administra el SGBD.
  • Los índices mejoran el rendimiento pero deben gestionarse internamente por el motor del SGBD.
  • La recuperación ante fallos se apoya en los registros de log redo y undo para garantizar la consistencia.

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

🎯 Idea clave

  • Las bases de datos centralizadas almacenan toda la información en un único nodo, ofreciendo simplicidad y coherencia natural pero limitándose al escalado vertical.
  • Las arquitecturas distribuidas reparten los datos entre múltiples nodos para lograr escalabilidad horizontal, continuidad geográfica y tolerancia a fallos.
  • Las bases federadas proporcionan una visión unificada de sistemas heterogéneos y autónomos sin migrar físicamente los datos, actuando como capa de integración transparente.
  • Los sistemas NoSQL surgieron para satisfacer necesidades de escala web, renunciando a las propiedades ACID para ganar flexibilidad de esquema y escalabilidad horizontal.
  • Los cinco modelos NoSQL se diferencian por su unidad básica de datos: pares opacos en clave-valor, documentos JSON, objetos con herencia, nodos y aristas, o familias de columnas.
  • Cada modelo NoSQL está optimizado para patrones de acceso específicos, desde el almacenamiento en caché hasta el análisis de relaciones complejas.

📚 Desarrollo

Arquitectura centralizada. Las bases centralizadas utilizan un único SGBD que almacena todos los datos en un nodo, proporcionando simplicidad y coherencia natural. Su principal limitación reside en el escalado vertical, mitigable mediante clusters de alta disponibilidad como Oracle RAC, SQL Server Always On o PostgreSQL Patroni.

Arquitectura distribuida. Distribuyen la información entre varios nodos con transparencia para el usuario, permitiendo escalabilidad horizontal, continuidad geográfica y latencia local. Se clasifican por homogeneidad y soportan fragmentación horizontal, vertical o mixta, así como replicación y diferentes niveles de consistencia.

Teoremas de consistencia. Estas bases gestionan el equilibrio entre consistencia, disponibilidad y tolerancia a particiones mediante el teorema CAP (Brewer 2000) y su extensión PACELC (Abadi 2010), aplicables a sistemas como Spanner, CockroachDB, YugabyteDB, Cassandra, MongoDB con sharding o CitusDB.

Arquitectura federada. Proporciona una vista integrada y unificada de múltiples bases de datos autónomas y heterogéneas sin migrar físicamente los datos. Cada nodo conserva su propio SGBD, esquema y administración, mientras el sistema federado actúa como intermediario de consultas mediante un esquema global.

Características federadas. Se distinguen por heterogeneidad de nodos, autonomía local, transparencia de acceso e integración de metadatos. En sistemas de información sanitaria permiten combinar datos de atención primaria, hospitalaria, laboratorio y radiología sin modificar los sistemas originales.

Marco NoSQL. Surgieron a finales de la primera década del siglo XXI impulsados por las necesidades de escala de grandes plataformas web. Renuncian a las propiedades ACID para ganar escalabilidad horizontal y flexibilidad de esquema, siguiendo generalmente el modelo BASE y diseñándose para clusters de hardware estándar.

Modelo clave-valor. Almacenan pares clave-valor opacos donde el valor es transparente para el sistema. Ofrecen velocidad extrema y son ideales para caché, aunque no soportan consultas internas sobre el contenido del valor. Representativos: Redis, DynamoDB, Memcached, Riak y etcd.

Modelo documental. Utilizan documentos semiestructurados en formato JSON o BSON como unidades autónomas, permitiendo campos anidados y arrays sin esquema rígido. Son especialmente adecuados para estándares sanitarios como HL7 FHIR. Ejemplos: MongoDB, CouchDB, DocumentDB y Cosmos DB.

Modelos restantes. Los orientados a objetos persisten objetos con herencia y métodos permitiendo mapeo directo con POO, aunque presentan baja adopción masiva. Los de grafos utilizan nodos y aristas con propiedades para relaciones complejas, empleando estándares como ISO 39075 GQL. Los columnares organizan datos por familias de columnas, optimizando analítica y compresión pero penalizando escrituras OLTP intensas.

🧩 Elementos esenciales

  • Base centralizada: Sistema con un único nodo que almacena todos los datos, caracterizado por la simplicidad y la coherencia natural.
  • Escalado vertical: Limitación de las bases centralizadas que se mitiga mediante clusters de alta disponibilidad como Oracle RAC o SQL Server Always On.
  • Base distribuida: Arquitectura que distribuye datos entre varios nodos permitiendo escalabilidad horizontal y transparencia para el usuario.
  • Fragmentación: Técnica de distribución de datos que puede ser horizontal, vertical o mixta según el criterio de división.
  • Teorema CAP: Principio que establece el equilibrio inevitable entre Consistencia, Disponibilidad y Tolerancia a particiones en sistemas distribuidos.
  • Base federada: Sistema que proporciona visión unificada de múltiples SGBD heterogéneos y autónomos sin migración física de datos.
  • Autonomía local: Propiedad de las bases federadas donde cada nodo mantiene su propia administración, esquema y SGBD independiente.
  • Schema-less: Característica de los sistemas NoSQL que permite esquemas flexibles o sin esquema fijo.
  • Modelo BASE: Paradigma alternativo a ACID en NoSQL que prioriza la disponibilidad básica, estado suave y consistencia eventual.
  • Clave-valor: Modelo NoSQL basado en pares clave-valor opacos optimizado para velocidad extrema y caché.
  • Documental: Modelo que almacena datos como documentos JSON/BSON semiestructurados con esquema flexible.
  • Grafos: Modelo basado en nodos y aristas con propiedades, especializado en relaciones complejas y redes.

🧠 Recuerda

  • Las bases centralizadas escalan verticalmente con límites físicos.
  • Las distribuidas permiten escalabilidad horizontal añadiendo nodos.
  • CAP y PACELC rigen el comportamiento de las bases distribuidas ante particiones.
  • En federadas, los datos permanecen en sus sistemas originales; no hay migración física.
  • NoSQL significa "Not Only SQL" y prioriza flexibilidad sobre rigidez relacional.
  • Los sistemas NoSQL optimizan patrones de acceso específicos sacrificando consultas ad hoc arbitrarias.
  • Clave-valor no permite consultas internas sobre el valor, solo acceso directo por clave.
  • Documentales utilizan JSON/BSON y son adecuadas para estándares sanitarios como FHIR.
  • Grafos utilizan el estándar ISO 39075 GQL desde 2024.
  • Columnares optimizan la analítica y compresión pero penalizan la escritura OLTP intensa.

3. Motores de indexación

🎯 Idea clave

  • Los índices son estructuras auxiliares que aceleran las consultas evitando el recorrido completo de las tablas.
  • El índice B-tree es el tipo más universal y el que se crea por defecto en la mayoría de SGBD relacionales.
  • Los índices hash optimizan búsquedas por igualdad exacta pero no soportan rangos ni ordenaciones.
  • Los índices bitmap resultan eficientes para columnas de baja cardinalidad en entornos analíticos.
  • Los motores independientes como Apache Lucene o Elasticsearch permiten búsquedas full-text y vectoriales avanzadas.
  • El mantenimiento de índices implica un coste que ralentiza las operaciones de escritura.

📚 Desarrollo

Definición y propósito. Un índice constituye una estructura de datos auxiliar diseñada para localizar filas sin necesidad de recorrer la tabla completa. Si bien acelera significativamente las operaciones de lectura, introduce una penalización en las escrituras, ya que cada inserción, actualización o borrado requiere la actualización sincronizada de la estructura indexada.

Índice B-tree. Es el motor de indexación más extendido en sistemas relacionales, empleado por defecto en PostgreSQL, Oracle, SQL Server y MySQL. Su estructura jerárquica mantiene todas las hojas a la misma profundidad mediante operaciones automáticas de división y fusión, garantizando tiempos de acceso logarítmicos uniformes para búsquedas exactas, rangos y ordenaciones.

Índices hash y bitmap. Los índices hash aplican funciones de dispersión que transforman claves en valores hash para acceso directo de complejidad O(1), resultando óptimos para igualdad exacta pero inutilizables para consultas de rango. Los índices bitmap representan cada valor distinto mediante mapas de bits, resultando especialmente eficientes para columnas con baja cardinalidad y combinaciones lógicas complejas en entornos de data warehouse.

Índices especializados. Existen índices funcionales que indexan el resultado de expresiones sobre columnas, útiles para búsquedas case-insensitive. Los índices compuestos abarcan múltiples columnas donde el orden definido resulta determinante para las consultas. También existen índices parciales sobre subconjuntos de filas, índices únicos para garantizar integridad, e índices cubrientes que incluyen columnas adicionales para evitar accesos a la tabla base.

Motores externos y arquitecturas avanzadas. Apache Lucene y sus derivados como Elasticsearch u OpenSearch implementan búsquedas full-text mediante tokenización, normalización, stemming y algoritmos de ranking como BM25. PostgreSQL ofrece estructuras específicas como GIN, GiST, SP-GiST, BRIN y BLOOM, además de índices vectoriales para embeddings mediante pgvector. Las arquitecturas distribuidas emplean sharding para particionamiento y réplicas para alta disponibilidad con consistencia eventual.

Coste y mantenimiento. Los índices se almacenan físicamente en páginas o bloques junto con las estadísticas que alimentan al optimizador de consultas. El diseño físico debe equilibrar la frecuencia de consultas frente a las operaciones de modificación, evitando la sobreindexación que genera contención y degradación del rendimiento en entornos de alta concurrencia.

🧩 Elementos esenciales

  • B-tree: estructura balanceada por defecto en los principales SGBD relacionales, ideal para igualdad, rangos y ordenación.
  • Propiedad de balanceo: garantiza que todos los nodos hoja se encuentren a la misma profundidad desde la raíz.
  • Nodos enlazados: los nodos hoja se conectan mediante listas doblemente enlazadas para permitir recorridos de rango eficientes.
  • Índice hash: proporciona acceso O(1) para igualdad exacta pero no admite operaciones de rango ni ordenación.
  • Índice bitmap: representa valores mediante mapas de bits, optimizando consultas sobre columnas de baja cardinalidad.
  • Índice funcional: indexa el resultado de funciones o expresiones aplicadas sobre columnas.
  • Índice compuesto: abarca varias columnas donde el orden de definición determina su eficacia para las consultas.
  • Índice único: impide la existencia de valores duplicados garantizando la integridad referencial.
  • Índice cubriente: incluye columnas adicionales mediante INCLUDE para evitar búsquedas en la tabla principal.
  • Lucene: biblioteca base de Java para motores de búsqueda full-text como Elasticsearch o Solr.
  • Estadísticas: histogramas y datos de selectividad utilizados por el optimizador para elegir planes de ejecución eficientes.

🧠 Recuerda

  • El B-tree es el índice por defecto y más versátil en bases de datos relacionales.
  • Los índices aceleran las lecturas pero generan sobrecarga en escrituras.
  • El hash es O(1) para igualdad exacta pero inútil para rangos.
  • El bitmap es ideal para columnas con pocos valores distintos y combinaciones lógicas.
  • Los índices funcionales permiten buscar por transformaciones como LOWER() o SUBSTR().
  • Los motores independientes se apoyan en Lucene para búsquedas full-text avanzadas.
  • El mantenimiento regular de estadísticas es esencial para el optimizador.
  • Evitar la sobreindexación en tablas sometidas a alta frecuencia de modificaciones.
  • Los índices espaciales y vectoriales requieren estructuras específicas como R-tree o HNSW.
  • Las operaciones de división y fusión mantienen automáticamente el balanceo del árbol.

4. El modelo de referencia ANSI

🎯 Idea clave

  • La arquitectura ANSI/SPARC establece tres niveles de abstracción para separar la visión de usuario, la estructura lógica global y el almacenamiento físico.
  • Propuesta en 1975 por el comité SPARC del American National Standards Institute, sirve como marco conceptual de referencia para los SGBD.
  • El nivel externo contempla múltiples vistas de usuario, mientras que los niveles conceptual e interno son únicos para cada base de datos.
  • La independencia física permite modificar el almacenamiento sin alterar el esquema conceptual.
  • La independencia lógica garantiza que cambios en el esquema conceptual no afecten a las vistas externas.
  • Los mapeos entre niveles son los mecanismos que materializan estas independencias y relacionan las distintas representaciones de los datos.

📚 Desarrollo

Marco histórico y normativo. El modelo de referencia ANSI, conocido técnicamente como ANSI/X3/SPARC, fue propuesto en 1975 por el Standards Planning And Requirements Committee del American National Standards Institute. Este marco conceptual establece la arquitectura fundamental que siguen los sistemas gestores de bases de datos modernos, aunque cada producto comercial la implemente con distinto grado de explicitación.

Tres niveles de abstracción. La arquitectura distingue tres esquemas diferenciados: el nivel externo o de usuario, el nivel conceptual y el nivel interno o físico. El término "esquema" en este contexto describe una representación formal de la base de datos desde una perspectiva específica, y no debe confundirse con el uso de "schema" en productos actuales como simple espacio de nombres o contenedor de objetos.

Nivel externo y vistas. El nivel externo corresponde a la visión particular que cada usuario o aplicación tiene de la base de datos. Soporta múltiples esquemas externos simultáneos, cada uno adaptado a necesidades específicas y mostrando solo un subconjunto lógico relevante de los datos disponibles, lo que facilita el principio de mínimo privilegio en seguridad.

Nivel conceptual global. El nivel conceptual constituye el esquema lógico global e integrado de toda la base de datos. Define las entidades, relaciones, restricciones y semántica de los datos, representando la visión única del administrador de base de datos sobre la organización informativa completa y actuando como interfaz entre las vistas externas y el almacenamiento físico.

Nivel interno y físico. El nivel interno describe la representación física real en el soporte de almacenamiento, incluyendo estructuras de disco, índices, páginas, bloques, tablespaces, métodos de acceso y rutas de almacenamiento. Es el único nivel que interactúa directamente con el hardware y el sistema operativo, y su gestión y optimización corresponden específicamente al DBA.

Independencia de datos. La arquitectura garantiza dos tipos de independencia: la física, que permite cambiar el almacenamiento o los índices sin modificar el esquema conceptual, y la lógica, que posibilita alterar el esquema conceptual sin rehacer las vistas externas o las aplicaciones. Esta separación reduce el acoplamiento, facilita la evolución tecnológica y permite mejorar el rendimiento sin reescribir la lógica asistencial.

🧩 Elementos esenciales

  • ANSI/X3/SPARC: denominación técnica completa del modelo de referencia establecido en 1975 por el American National Standards Institute.
  • Nivel externo: vistas particulares de usuarios o aplicaciones sobre subconjuntos lógicos de la base de datos, implementables mediante sentencias VIEW en SQL.
  • Nivel conceptual: esquema lógico global único que define entidades, relaciones, restricciones y semántica para toda la organización.
  • Nivel interno: descripción física del almacenamiento en disco, incluyendo índices, organización de archivos, compresión y cifrado físico.
  • Esquema vs schema: en el modelo ANSI, "esquema" es un nivel de abstracción; en productos comerciales, "schema" suele ser un contenedor lógico de objetos.
  • Mapeos entre niveles: mecanismos que relacionan los esquemas externos con el conceptual y este con el interno, permitiendo la correspondencia entre abstracciones.
  • Independencia física: capacidad de modificar el nivel interno, índices o almacenamiento sin afectar al esquema conceptual.
  • Independencia lógica: posibilidad de alterar el esquema conceptual sin modificar las vistas externas o reescribir aplicaciones.
  • Mnemotecnia ECI: secuencia Externo-Conceptual-Interno para recordar el orden descendente de los tres niveles de abstracción.
  • Gestión del DBA: el administrador de bases de datos controla el nivel interno, decidiendo sobre índices, particionado físico y parámetros de almacenamiento.

🧠 Recuerda

  • La arquitectura ANSI/SPARC data de 1975 y fue propuesta por el comité SPARC como marco conceptual de referencia.
  • Existen múltiples esquemas externos pero solo uno conceptual y uno interno por base de datos.
  • El nivel externo se centra en las vistas de usuario, el conceptual en la estructura lógica global y el interno en el almacenamiento físico.
  • La independencia física protege al esquema conceptual de cambios en el hardware, disco o índices.
  • La independencia lógica aisla a las aplicaciones de modificaciones en la estructura global de datos.
  • Un índice B-Tree, una organización en montículo o un tablespace son elementos del nivel interno, no del conceptual.
  • El DBA gestiona el esquema interno y conceptual, pero no define las vistas externas individuales.
  • Los SGBD actuales implementan esta arquitectura aunque con diferente grado de explicitación en sus interfaces.
  • Los mapeos entre niveles son los responsables técnicos de mantener la independencia de datos.
  • El principio de mínimo privilegio en seguridad de la información se relaciona directamente con el nivel externo.

5. Monitor de transacciones

🎯 Idea clave

  • El monitor de transacciones gobierna la ejecución de unidades de trabajo garantizando coherencia, recuperabilidad y seguridad de los efectos sobre los recursos gestionados.
  • En su acepción interna opera como subsistema coordinador del SGBD que integra mecanismos de control, registro y planificación para sustentar las propiedades ACID.
  • En arquitecturas distribuidas actúa como middleware transaccional que coordina recursos heterogéneos mediante protocolos como la confirmación en dos fases.
  • Controla el ciclo de vida completo incluyendo inicio, ejecución, confirmación definitiva, anulación y recuperación ante fallos del sistema.
  • Resulta imprescindible en entornos multiusuario y críticos donde múltiples operaciones sobre datos relacionados deben confirmarse o deshacerse como un todo único.

📚 Desarrollo

Definición y delimitación conceptual. El monitor de transacciones constituye el componente software encargado de gobernar la ejecución de unidades de trabajo transaccionales, asegurando que sus efectos sobre los datos y recursos implicados resulten coherentes, recuperables y seguros. Su función trasciende la mera observación de métricas para abarcar el control activo del ciclo vital completo.

Naturaleza de subsistema coordinador. En el ámbito interno de un SGBD, este monitor no se materializa como un módulo aislado y uniforme, sino que se distribuye entre diversos componentes internos que cooperan mediante mecanismos de control, estructuras de registro, planificación de operaciones y políticas de visibilidad. Actúa como articulador entre la lógica funcional, la consistencia de datos y la fiabilidad operativa del sistema gestor.

Garantía de propiedades transaccionales. Su misión esencial consiste en materializar las propiedades ACID, delimitando la unidad de trabajo, garantizando su tratamiento atómico, regulando la convivencia con otras transacciones concurrentes y preservando la coherencia hasta la finalización. Coordina específicamente el gestor de bloqueos y el gestor de log para mantener el aislamiento y la durabilidad ante fallos.

Extensión a middleware transaccional. En arquitecturas empresariales complejas, el concepto abarca el middleware transaccional o TP monitor, componente que coordina transacciones distribuidas entre múltiples recursos heterogéneos como bases de datos, sistemas de mensajería y servicios aplicativos. Utiliza protocolos como la confirmación en dos fases (2PC) para mantener la atomicidad global cuando una operación afecta a diversos subsistemas.

Gestión operativa integral. Además de controlar los estados de begin, commit y rollback, proporciona servicios de naming para localización de recursos, enrutamiento de peticiones, transformación de protocolos, balanceo de carga entre instancias y gestión de pools de conexiones. También asume responsabilidades de seguridad, autorización y supervisión de la actividad transaccional en entornos de alta concurrencia.

Relevancia en sistemas sanitarios críticos. Resulta especialmente significativo en entornos como el Servicio Andaluz de Salud, donde múltiples aplicaciones, bases de datos departamentales y sistemas heterogéneos deben colaborar diariamente. En estos contextos, el monitor asegura que procesos clínicos y administrativos que modifican información sensible no generen estados intermedios inconsistentes ante interrupciones o errores.

Capacidades de recuperación. Incorpora mecanismos para retomar transacciones interrumpidas por fallos, marcar operaciones dudosas que requieren resolución manual mediante heurísticas, y aplicar reversión total o parcial mediante savepoints. Estas capacidades resultan imprescindibles para recuperar situaciones correctas cuando se producen errores durante la ejecución de secuencias complejas.

🧩 Elementos esenciales

  • Subsistema coordinador: Se distribuye entre varios componentes internos del SGBD más que como módulo aislado, articulando la función transaccional mediante cooperación de mecanismos internos.
  • Ciclo de vida transaccional: Gobierna el inicio, asociación a sesiones, acceso a recursos, control de concurrencia, validación, confirmación, cancelación y recuperación posterior.
  • Protocolo 2PC: En sistemas distribuidos, coordina la confirmación entre múltiples recursos transaccionales mediante el protocolo de confirmación en dos fases para mantener atomicidad global.
  • Visibilidad y aislamiento: Aplica reglas que impiden a otras transacciones observar estados intermedios inaceptables durante la ejecución de operaciones en curso.
  • Recuperación ante fallos: Permite retomar transacciones interrumpidas, marcar operaciones dudosas y ejecutar rollback total o parcial cuando se producen errores o interrupciones.
  • Gestión de bloqueos y log: Coordina activamente con el gestor de bloqueos y el gestor de log para garantizar la consistencia y posibilitar la recuperación tras fallos.
  • Servicios de naming y enrutamiento: Proporciona localización de recursos por nombre lógico, enrutamiento de peticiones y transformación de protocolos en entornos heterogéneos.
  • Balanceo y pools: Gestiona el balanceo de carga entre instancias y mantiene pools de conexiones para optimizar el rendimiento en entornos de alta demanda.

🧠 Recuerda

  • No es un módulo uniforme aislado, sino un subsistema coordinador distribuido en componentes del SGBD.
  • Garantiza ACID mediante la coordinación entre gestor de bloqueos, gestor de log y políticas de visibilidad.
  • En sentido estricto se identifica con el gestor transaccional interno del motor de base de datos.
  • En sentido amplio designa el middleware que coordina transacciones distribuidas entre sistemas heterogéneos.
  • Evita estados intermedios que no representen correctamente la operación pretendida.
  • Utiliza el protocolo 2PC para mantener atomicidad cuando una transacción afecta a múltiples recursos.
  • Sus orígenes se remontan a sistemas mainframe de los años setenta como IBM CICS.
  • Resulta crítico en sistemas sanitarios donde operaciones clínicas y administrativas requieren máxima fiabilidad.

6. Control de concurrencia

🎯 Idea clave

  • El control de concurrencia es el conjunto de principios, reglas y mecanismos que permite a un SGBD gestionar el acceso simultáneo de múltiples transacciones a los mismos datos sin comprometer la consistencia del sistema ni la corrección de los resultados.
  • Su objetivo fundamental es garantizar la serializabilidad, es decir, que la ejecución concurrente sea equivalente a alguna ejecución secuencial válida, preservando las propiedades ACID, especialmente el aislamiento y la consistencia.
  • Se distingue claramente del control de acceso o seguridad, ya que no determina qué usuario puede operar, sino cómo se coordinan las operaciones simultáneas de distintos usuarios sobre datos compartidos.
  • Las principales técnicas incluyen bloqueos, control multiversión, marcas de tiempo, versionado de filas y protocolos de serialización, que los SGBD combinan según los niveles de aislamiento configurados.
  • Constituye una función estructural y no opcional en sistemas multiusuario, siendo particularmente crítico en entornos OLTP de alta carga como los sistemas de información sanitaria.
  • La documentación oficial de los motores modernos confirma que se articulan técnicas diversas para equilibrar aislamiento, rendimiento y capacidad de trabajo simultáneo.

📚 Desarrollo

Definición y naturaleza. El control de concurrencia es el conjunto de principios, reglas y mecanismos mediante los cuales un sistema de gestión de bases de datos permite que varias transacciones operen simultáneamente sobre los mismos datos sin comprometer la consistencia del sistema ni la corrección de los resultados. En entornos corporativos reales, múltiples sesiones, procesos y servicios acceden de forma solapada a la información, haciendo imprescindible esta función estructural que armoniza el acceso concurrente con la preservación de la coherencia de los datos.

Problemas que resuelve. Sin una regulación adecuada, la actividad simultánea podría generar resultados contradictorios, pérdida de actualizaciones, visualización de estados intermedios impropios o consolidación de efectos incompatibles entre sí. La gestión correcta evita las anomalías de concurrencia que surgen cuando transacciones que leen y escriben los mismos datos se ejecutan simultáneamente sin coordinación, garantizando que el sistema produzca resultados correctos y predecibles.

Distinción conceptual. El control de concurrencia no debe confundirse con el control de acceso o seguridad. Mientras el control de acceso determina qué usuario puede realizar qué operación sobre determinados objetos, el control de concurrencia determina cómo se coordinan las operaciones de distintos usuarios cuando afectan a los mismos datos al mismo tiempo. Son funciones complementarias pero claramente diferenciadas dentro de la arquitectura del SGBD.

Fundamento teórico. La referencia teórica clásica es la serializabilidad, es decir, la aspiración a que la ejecución concurrente sea equivalente a una ejecución en serie válida de esas mismas transacciones. Sobre esta base, los SGBD articulan diferentes niveles de aislamiento que gradúan las garantías ofrecidas, permitiendo equilibrar el grado de protección contra las interferencias con la capacidad de procesamiento paralelo del sistema.

Técnicas principales. Los mecanismos concretos incluyen el bloqueo de recursos, que impide accesos incompatibles mediante reservas temporales; el control multiversión, que gestiona versiones de filas para lecturas consistentes sin bloquear escrituras; el uso de marcas de tiempo; y la detección de conflictos o anomalías de serialización. La granularidad de estos mecanismos varía desde bloqueos de filas individuales hasta bloqueos de tablas completas, dependiendo del motor y la operación.

Protocolos clásicos. El protocolo de bloqueo en dos fases constituye una regla fundamental para obtener serializabilidad: durante la fase creciente la transacción adquiere bloqueos y durante la fase decreciente los libera, sin adquirir nuevos bloqueos después de iniciar la liberación. Su variante estricta mantiene los bloqueos de escritura hasta la confirmación o reversión de la transacción, facilitando la recuperación ante fallos.

Contexto crítico. La correcta gestión de la concurrencia es especialmente vital en sistemas OLTP de alta carga, como los sistemas de información sanitaria donde decenas o cientos de usuarios modifican datos de pacientes simultáneamente. Los motores modernos no sacrifican la consistencia en favor de la eficiencia, sino que articulan técnicas combinadas para lograr ambos objetivos simultáneamente.

🧩 Elementos esenciales

  • Serializabilidad: propiedad que establece que la ejecución concurrente debe producir el mismo resultado que alguna ejecución secuencial válida de las mismas transacciones.
  • Anomalías de concurrencia: resultados incorrectos o estados inconsistentes que aparecen cuando múltiples transacciones acceden simultáneamente a los mismos datos sin coordinación adecuada.
  • Control de acceso vs. concurrencia: el primero regula quién puede acceder a qué recursos; el segundo coordina cómo se ejecutan operaciones simultáneas sobre datos compartidos.
  • Bloqueos: técnica de reserva temporal sobre recursos que impide accesos incompatibles, pudiendo ser compartidos para lecturas concurrentes o exclusivos para modificaciones.
  • Control multiversión (MVCC): mecanismo que gestiona versiones de filas para permitir lecturas consistentes sin bloquear escrituras concurrentes ni interferir con transacciones activas.
  • Niveles de aislamiento: configuraciones que gradúan las garantías de aislamiento entre transacciones, desde lecturas no confirmadas hasta serialización estricta.
  • Two-phase locking: protocolo clásico que divide la adquisición y liberación de bloqueos en fases creciente y decreciente para garantizar la serializabilidad de las ejecuciones.
  • Granularidad: nivel de detalle del bloqueo, que puede aplicarse a filas, páginas, tablas o esquemas, afectando directamente al paralelismo posible y al coste de gestión.
  • Función estructural: el control de concurrencia es inherente al SGBD y no una mejora opcional, siendo imprescindible para la integridad en entornos multiusuario.
  • Entornos críticos: especialmente relevante en sistemas OLTP de alta concurrencia como los sistemas de información sanitaria del Servicio Andaluz de Salud.

🧠 Recuerda

  • El control de concurrencia es el marco general que gobierna las interferencias entre transacciones; los bloqueos son solo una de las técnicas utilizadas dentro de ese marco.
  • Busca siempre la equivalencia con una ejecución en serie válida, conocida como propiedad de serializabilidad.
  • No confundir con control de acceso: uno coordina operaciones temporales simultáneas, el otro autoriza a usuarios sobre objetos.
  • Es una función estructural obligatoria del SGBD, no un componente opcional que pueda desactivarse.
  • Los sistemas modernos combinan bloqueos, versionado de filas y otras estrategias según el nivel de aislamiento configurado.
  • Liberar bloqueos demasiado pronto puede producir inconsistencias, mientras que mantenerlos demasiado tiempo reduce la concurrencia efectiva.
  • La granularidad de los mecanismos determina el equilibrio entre máxima concurrencia y sobrecarga administrativa del sistema.
  • En sistemas sanitarios de alta carga, una gestión deficiente puede comprometer gravemente la integridad de los datos de pacientes.

7. Bloqueos

🎯 Idea clave

  • Los bloqueos son mecanismos de control de concurrencia que reservan temporalmente recursos de la base de datos para impedir accesos incompatibles entre transacciones simultáneas.
  • Su función esencial consiste en proteger la coherencia de los datos y garantizar el aislamiento de las transacciones dentro del modelo ACID.
  • El SGBD puede aplicar bloqueos sobre diversos recursos, desde filas individuales hasta tablas completas, índices o particiones, dependiendo de la granularidad necesaria.
  • Existen modos específicos como los bloqueos compartidos, exclusivos y los bloqueos de intención que optimizan la gestión jerárquica de recursos.
  • Aunque coexisten con técnicas modernas como el versionado de filas y el control multiversión, los bloqueos siguen siendo una herramienta nuclear en la arquitectura de motores como PostgreSQL, Oracle, MySQL y SQL Server.
  • La gestión de bloqueos implica resolver conflictos de compatibilidad y prevenir problemas como la contención excesiva y los interbloqueos entre transacciones.

📚 Desarrollo

Definición fundamental. Un bloqueo es un mecanismo de protección temporal mediante el cual el SGBD reserva un recurso específico para una transacción activa, limitando o condicionando el acceso concurrente de otras operaciones mientras dura la dependencia sobre dicho recurso. Esta reserva actúa como una guarda que coordina el acceso simultáneo.

Función dentro del control de concurrencia. La finalidad del bloqueo no es impedir la simultaneidad, sino permitirla sin que aparezcan resultados incorrectos, pérdidas de actualización o estados intermedios incompatibles con las reglas del sistema. El gestor de bloqueos decide qué accesos son compatibles y cuáles deben esperar, materializando la política de aislamiento del SGBD.

Protección de la integridad. Cuando varias transacciones intentan leer o modificar los mismos datos en momentos solapados, los bloqueos impiden que se produzcan fenómenos no deseados como lecturas sucias, lecturas no repetibles o lecturas fantasma. Sin este mecanismo, una transacción podría sobrescribir el trabajo de otra u observar estados intermedios impropios.

Granularidad de los recursos. El recurso bloqueado puede ser de distinta naturaleza y tamaño: una fila concreta, una clave de índice, un rango de claves, una página de datos, una tabla completa, una partición o incluso un objeto de catálogo. La elección del nivel de granularidad afecta directamente al rendimiento y al grado de concurrencia alcanzable.

Bloqueos de intención. En entornos con acceso a múltiples niveles de granularidad, los SGBD implementan bloqueos de intención sobre nodos superiores del árbol jerárquico para evitar verificaciones ineficientes. Estos incluyen el modo IS (Intention Shared), IX (Intention Exclusive) y SIX (Shared + Intention Exclusive), que informan sobre la intención de adquirir bloqueos en niveles inferiores.

Matriz de compatibilidad y gestión. La coexistencia de diferentes bloqueos sobre el mismo recurso o recursos relacionados se rige por una matriz de compatibilidad que determina qué combinaciones pueden progresar simultáneamente. El sistema debe gestionar no solo la concesión de bloqueos, sino también sus conflictos, retención y liberación, abordando problemas como la contención y los interbloqueos.

🧩 Elementos esenciales

  • Reserva temporal: el bloqueo constituye una protección momentánea sobre un recurso durante la ejecución de una transacción.
  • Recursos bloqueables: filas, claves de índice, rangos de claves, páginas, tablas, particiones, objetos de catálogo y recursos lógicos definidos por la aplicación.
  • Modos de bloqueo: existen modos generales como compartido y exclusivo, además de modos especializados según el producto concreto.
  • Bloqueos de intención: mecanismos IS, IX y SIX que se aplican en niveles superiores de la jerarquía para optimizar la verificación de compatibilidad.
  • Granularidad jerárquica: estructura que va desde la base de datos completa hasta las filas individuales, permitiendo diferentes niveles de protección.
  • Matriz de compatibilidad: conjunto de reglas que determina qué tipos de bloqueos pueden coexistir sobre el mismo recurso sin generar conflictos.
  • Interferencias evitadas: prevención de lecturas sucias, lecturas no repetibles y lecturas fantasma mediante el aislamiento garantizado por los bloqueos.
  • Problemas asociados: la utilización de bloqueos puede generar contención entre transacciones e interbloqueos que requieren gestión específica por parte del SGBD.
  • Coexistencia con MVCC: en motores modernos, los bloqueos funcionan junto con técnicas de multiversionado y versionado de filas, sin haber sido sustituidos por estas.

🧠 Recuerda

  • Los bloqueos son mecanismos clásicos pero actuales, esenciales en la arquitectura de los principales motores de bases de datos.
  • Su objetivo es hacer el sistema correcto, no ralentizarlo, ordenando accesos incompatibles.
  • Protegen el estado de los recursos mientras una transacción mantiene dependencias sobre ellos.
  • La granularidad determina el equilibrio entre seguridad y rendimiento del sistema concurrente.
  • Los bloqueos de intención permiten verificar eficientemente la posibilidad de acceso sin explorar todos los niveles inferiores.
  • La compatibilidad entre diferentes modos de bloqueo se define mediante matrices específicas que rigen la simultaneidad permitida.
  • Forman parte integral del control de concurrencia y contribuyen a preservar el aislamiento transaccional.
  • Su gestión incluye la detección y resolución de interbloqueos para evitar bloqueos permanentes entre transacciones.
  • En entornos multiusuario, constituyen la herramienta nuclear para coordinar el acceso concurrente sin comprometer la integridad de los datos.

8. Recuperación de errores

🎯 Idea clave

  • La recuperación de errores es el conjunto de mecanismos técnicos y procedimentales que permiten restaurar un estado consistente y operativo de la base de datos tras una interrupción, pérdida de datos o error lógico.
  • Este proceso se fundamenta en las propiedades ACID, con especial incidencia en la atomicidad y la durabilidad de las transacciones.
  • El registro de transacciones o write-ahead log (WAL) constituye el pilar técnico sobre el que se construyen las operaciones de deshacer (undo) y rehacer (redo).
  • Los fallos se clasifican fundamentalmente en fallos de transacción, que afectan a operaciones individuales, y fallos de sistema, que impactan al conjunto del SGBD.
  • Los checkpoints o puntos de control reducen drásticamente el tiempo necesario para la recuperación al sincronizar periódicamente el estado de la base de datos.

📚 Desarrollo

Definición y alcance. La recuperación de errores comprende el conjunto de estrategias orientadas a devolver la base de datos a un estado correcto y utilizable después de producirse una caída del proceso, un corte eléctrico, una corrupción de ficheros o una operación humana incorrecta. Su objetivo no se limita a volver a arrancar el sistema, sino a garantizar que la información recupere su coherencia y que el servicio pueda reanudarse con la menor pérdida posible.

Propiedades ACID vinculadas. La recuperación garantiza dos propiedades fundamentales de las transacciones. La atomicidad exige que una transacción se aplique por completo o no deje ningún efecto parcial, de modo que las operaciones no confirmadas deben deshacerse tras un fallo. La durabilidad asegura que, una vez confirmada una transacción mediante commit, sus efectos persistirán incluso si el sistema falla inmediatamente después.

Taxonomía de fallos. Los fallos de transacción afectan a una o varias operaciones individuales sin provocar la caída del sistema completo, derivando de errores lógicos, violaciones de integridad, interbloqueos (deadlocks) detectados por el sistema o cancelaciones explícitas por timeout. Los fallos del sistema, como caídas del sistema operativo, cortes de suministro eléctrico o errores irrecuperables del propio SGBD, impactan al conjunto del motor pero no dañan el almacenamiento secundario, perdiéndose únicamente el contenido de la memoria principal.

Mecanismos técnicos centrales. El funcionamiento se apoya en el registro de transacciones, también denominado write-ahead log (WAL), un fichero secuencial donde el SGBD anota todas las operaciones antes de modificar los datos definitivamente en disco. Esta técnica de escritura anticipada posibilita reconstruir el estado consistente mediante la reversión de cambios no confirmados (undo) y la reaplicación de cambios confirmados pero no volcados físicamente (redo).

Fases del proceso de recuperación. Tras un fallo del sistema, el procedimiento consta típicamente de tres etapas. Durante la fase de análisis, el sistema lee el log desde el último checkpoint para identificar las transacciones activas en el momento del fallo. En la fase redo, se aplican nuevamente todas las operaciones de las transacciones confirmadas cuyos efectos aún no habían sido escritos en los ficheros de datos. Finalmente, en la fase undo, se revierten las operaciones pertenecientes a transacciones que no habían sido confirmadas.

Puntos de control y distinción conceptual. El checkpoint es un momento determinado en el que el SGBD escribe en disco todos los cambios pendientes en el buffer de memoria y registra en el log que los datos están sincronizados, reduciendo así el alcance temporal del archivo de log a analizar. Es esencial distinguir entre restaurar, que significa reponer archivos desde una copia de seguridad, y recuperar, que implica reconstruir el estado correcto aplicando o revirtiendo cambios hasta alcanzar el punto deseado.

🧩 Elementos esenciales

  • Write-Ahead Logging (WAL): técnica mediante la cual el SGBD registra en un archivo secuencial todas las operaciones de una transacción antes de modificar los datos definitivamente en disco, garantizando la posibilidad de reconstrucción ante fallos.
  • Undo: mecanismo que revierte las operaciones de las transacciones que no habían sido confirmadas en el momento del fallo, eliminando efectos parciales y garantizando la atomicidad.
  • Redo: operación que reaplica los cambios de las transacciones confirmadas cuyos efectos no se habían volcado físicamente a los ficheros de datos, asegurando la durabilidad.
  • Checkpoint: punto de sincronización en el que el sistema escribe en disco todos los cambios pendientes del buffer de memoria, reduciendo el tiempo necesario para la recuperación al acotar el análisis del log.
  • Fallos de transacción: incidencias que afectan a operaciones individuales por errores lógicos, violaciones de restricciones, detección de interbloqueos o expiración de tiempo máximo, gestionables mediante rollback sin reinicio del sistema.
  • Fallos de sistema: interrupciones que afectan al conjunto del SGBD como caídas del sistema operativo, cortes eléctricos o fallos de hardware en memoria principal, que requieren reinicio y aplicación de técnicas undo y redo.
  • Monitor de transacciones: componente del SGBD responsable de gestionar automáticamente los fallos de transacción, realizando el rollback correspondiente de forma transparente para el resto de usuarios.
  • Rollback: operación de deshacer una transacción completa cuando se detectan errores lógicos, condiciones de error o cancelaciones explícitas por parte del usuario o aplicación.
  • Diferencia restaurar-recuperar: restaurar implica reponer archivos desde una copia de seguridad, mientras que recuperar significa reconstruir el estado válido aplicando o revirtiendo cambios registrados en el log hasta el punto deseado.

🧠 Recuerda

  • La recuperación de errores es el mecanismo práctico que materializa las propiedades de atomicidad y durabilidad de las transacciones ACID.
  • El write-ahead logging exige que toda operación quede registrada en el log antes de modificarse el dato definitivo en disco.
  • Los checkpoints aceleran la recuperación al reducir la porción del log que debe analizarse tras un fallo.
  • La operación undo se aplica siempre a transacciones no confirmadas, mientras que redo se aplica a transacciones confirmadas pero no volcadas.
  • Los fallos de transacción se resuelven mediante rollback sin necesidad de reiniciar el sistema completo.
  • Los fallos de sistema requieren un reinicio controlado con las fases de análisis, redo y undo.
  • El monitor de transacciones gestiona automáticamente los fallos de transacción, haciendo transparente la recuperación para otros usuarios concurrentes.
  • La durabilidad garantiza que una transacción confirmada persistirá incluso ante fallos inmediatos posteriores al commit.
  • Restaurar es recuperar archivos desde backup; recuperar es reconstruir el estado válido de la base de datos utilizando el log.

9. Integridad

🎯 Idea clave

  • La integridad es una propiedad esencial del modelo relacional que garantiza la coherencia y validez de los datos en todo momento.
  • El modelo relacional define tres categorías fundamentales: integridad de dominio, integridad de entidad e integridad referencial.
  • La integridad de dominio exige que cada atributo almacene valores válidos dentro de su dominio definido, evitando errores de captura.
  • La integridad de entidad establece que la clave primaria debe identificar unívocamente cada fila sin admitir valores nulos.
  • La integridad referencial asegura que las claves foráneas apunten a filas existentes, permitiendo las acciones CASCADE, SET NULL, SET DEFAULT o RESTRICT.
  • La integridad semántica implementa reglas de negocio complejas mediante triggers y procedimientos almacenados cuando las restricciones declarativas resultan insuficientes.

📚 Desarrollo

Definición de restricciones. Las restricciones de integridad son condiciones que deben satisfacer los datos permanentemente para garantizar su coherencia y validez en el sistema gestor.

Integridad de dominio. Esta categoría exige que los valores almacenados pertenezcan al dominio definido para cada atributo, comprendiendo el tipo de dato, el rango de valores admisibles y las restricciones adicionales. En SQL se implementa mediante tipos de datos, la restricción NOT NULL, la cláusula CHECK para condiciones arbitrarias y los valores DEFAULT.

Integridad de entidad. Establece que ningún atributo que forme parte de la clave primaria puede tomar valor nulo, ya que esta clave identifica unívocamente cada tupla. Sin esta regla, una fila carecería de identificador, dificultando su actualización, borrado o auditoría. Esta restricción afecta exclusivamente a relaciones base, no a vistas.

Integridad referencial. Garantiza que una clave foránea apunte a una fila existente en la relación referenciada, salvo que se permita explícitamente el valor nulo. Esta regla evita referencias huérfanas. Las acciones ante violaciones incluyen CASCADE para propagar cambios, SET NULL para establecer nulos, SET DEFAULT para asignar valores por defecto y RESTRICT o NO ACTION para impedir la operación.

Integridad semántica. Engloba las reglas de negocio o lógica del dominio que trascienden las restricciones estructurales simples. Cuando las validaciones implican consultar otras tablas, realizar cálculos complejos o ejecutar lógica multi-paso, se emplean triggers y procedimientos almacenados.

Mecanismo de triggers. Los triggers son procedimientos que el SGBD ejecuta automáticamente ante eventos INSERT, UPDATE o DELETE. Pueden ejecutarse BEFORE (modificando valores o abortando), AFTER (registrando auditorías o actualizando tablas relacionadas) o INSTEAD OF (reemplazando la operación, especialmente en vistas). Su granularidad puede ser FOR EACH ROW (por fila afectada) o FOR EACH STATEMENT (por sentencia).

🧩 Elementos esenciales

  • Integridad de dominio: Condición que exige que los valores pertenezcan al conjunto definido por el tipo, rango y restricciones del atributo.
  • Restricción CHECK: Mecanismo SQL que permite especificar condiciones arbitrarias que los valores deben satisfacer para ser válidos.
  • Restricción NOT NULL: Impide que un atributo almacene valores nulos, exigiendo siempre un valor del dominio.
  • Integridad de entidad: Regla que prohíbe valores nulos en claves primarias para garantizar la identificación unívoca de cada tupla.
  • Clave primaria: Identificador único de cada fila que implica automáticamente restricciones NOT NULL y UNIQUE.
  • Integridad referencial: Garantía de que los valores de claves foráneas existen como claves primarias en la tabla referenciada o son nulos.
  • Acción CASCADE: Propagación automática de operaciones de borrado o actualización a las tuplas referenciantes.
  • Acción SET NULL: Colocación a nulo de la clave foránea en las tuplas referenciantes ante una violación referencial.
  • Integridad semántica: Conjunto de reglas de negocio complejas que reflejan el funcionamiento real de la organización.
  • Trigger BEFORE: Procedimiento ejecutado antes de la operación que puede modificar valores entrantes o abortar la transacción.
  • Trigger AFTER: Procedimiento ejecutado después de confirmar la operación, útil para auditorías y mantenimiento de tablas derivadas.
  • Granularidad de fila: Modo FOR EACH ROW donde el trigger se ejecuta una vez por cada fila afectada por la operación.

🧠 Recuerda

  • La integridad de dominio evita ambigüedades semánticas mediante tipos de datos y restricciones CHECK.
  • Una clave primaria nula impide identificar la tupla, vulnerando la integridad de entidad.
  • Las referencias huérfanas se evitan mediante integridad referencial y acciones compensatorias bien definidas.
  • CASCADE propaga los cambios eliminando o actualizando las filas dependientes automáticamente.
  • SET NULL conserva las filas referenciantes anulando temporalmente la relación.
  • RESTRICT impide la operación que generaría la violación, protegiendo la consistencia referencial.
  • Los triggers permiten implementar validaciones que involucran múltiples tablas o cálculos complejos.
  • BEFORE puede filtrar datos inválidos antes de su inserción; AFTER registra cambios confirmados.
  • INSTEAD OF reemplaza la operación original, facilitando la actualización de vistas.
  • Las restricciones de integridad deben mantenerse en todo momento, no solo durante la carga inicial de datos.

Prueba la demo si quieres ver el resto

Has 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

Una demo pensada para decidir con criterio

Temario, test y simulacro conectados

La idea no es solo leer un tema: es estudiar con continuidad y comprobar cómo se relaciona con el resto de herramientas.

Preguntas justificadas

Verás explicaciones de la correcta y de las incorrectas para estudiar con más criterio, no solo para memorizar.

Acceso rápido

Con tu nombre y tu email, eliges categoría y te enviamos el acceso por correo sin compromiso.

Gratis Sin compromiso Acceso por email

Solicita ya tu acceso Demo

Sólo tu email, tu nombre y apellidos (si quieres), elige categoría y prueba antes de decidir. Es gratis.

Acceso solicitado

Revisa tu correo y también spam.

En tienes el enlace para terminar el autoregistro.

Ábrelo antes de 1 hora.

OposAs