Tema 34. El modelo relacional. Definiciones y conceptos básicos. Arquitectura. Diseño. Normalización. Manipulación: álgebra y cálculo relacional. Modelo entidad– relación. El lenguaje SQL. Normas y estándares para la interoperabilidad entre gestores de bases de datos relacionales. Principales SGBD comerciales. SGBD de código abierto.

1. El modelo relacional

🎯 Idea clave

• El modelo relacional es un paradigma teórico que organiza la información en relaciones, implementadas como tablas en los sistemas gestores.
• Fue formulado por Edgar F. Codd para separar la representación lógica de los datos de su almacenamiento físico.
• Su principal ventaja es la independencia de datos, que reduce la dependencia entre programas y la estructura interna de almacenamiento.
• Permite manipular la información mediante operaciones formales y declarativas, sin necesidad de conocer la estructura física.
• Es la base de los sistemas de gestión de bases de datos relacionales (RDBMS) utilizados en entornos corporativos, incluidos los sanitarios.
• Aunque existen modelos alternativos (NoSQL), el modelo relacional sigue siendo el estándar dominante en sistemas transaccionales.

📚 Desarrollo

Origen y fundamento teórico. El modelo relacional fue propuesto por Edgar F. Codd como un marco formal para organizar y manipular datos. Su objetivo era resolver la dependencia entre los programas y la estructura física de almacenamiento, un problema común en los sistemas jerárquicos y en red. La base matemática del modelo —álgebra y cálculo relacional— permite operaciones precisas y declarativas, donde el usuario especifica qué datos desea obtener sin necesidad de describir cómo acceder a ellos.

Representación práctica. En la implementación de los sistemas gestores, las relaciones del modelo relacional se materializan como tablas compuestas por filas y columnas. Cada tabla representa un conjunto de hechos del mismo tipo, cada fila (o tupla) corresponde a una ocurrencia concreta de esos hechos, y cada columna (o atributo) describe una propiedad estable de esas ocurrencias. Esta estructura formalizada garantiza coherencia y facilita la consulta y manipulación de la información.

Independencia de datos. Una de las contribuciones más significativas del modelo relacional es la separación entre el nivel lógico y el nivel físico. Los programas y usuarios interactúan con una representación abstracta de los datos, sin necesidad de conocer su organización interna en ficheros, índices o páginas. Esto permite modificar la estructura física sin afectar a las aplicaciones, mejorando la flexibilidad y reduciendo los costes de mantenimiento.

Lenguaje declarativo. El modelo relacional introdujo el uso de lenguajes declarativos, como SQL, para interactuar con los datos. A diferencia de los modelos anteriores, que exigían navegar explícitamente mediante punteros, el modelo relacional permite expresar consultas en términos de qué información se desea, dejando al sistema gestor la tarea de determinar cómo obtenerla. Esta abstracción simplifica el desarrollo de aplicaciones y mejora la productividad.

Ventajas frente a otros modelos. Comparado con los modelos jerárquico y en red, el modelo relacional ofrece mayor independencia de datos, una base matemática sólida y un lenguaje de acceso más intuitivo. Mientras que los modelos anteriores requerían conocimientos técnicos sobre la estructura física, el modelo relacional permite consultas flexibles basadas en valores, no en punteros. Esta característica lo hace especialmente adecuado para entornos multiusuario y aplicaciones complejas.

Aplicación en entornos sanitarios. El modelo relacional es el estándar en sistemas de información sanitarios, como los del Servicio Andaluz de Salud (SAS), debido a su capacidad para garantizar la integridad y coherencia de los datos. Su estructura formalizada y sus mecanismos de control de integridad son esenciales para gestionar información crítica, como historiales clínicos, pacientes o recursos hospitalarios.

Relación con los RDBMS. El modelo relacional es el marco teórico que sustenta los sistemas gestores de bases de datos relacionales (RDBMS), como Oracle, PostgreSQL o SQL Server. Estos productos implementan el modelo con distintos grados de fidelidad, pero todos comparten los principios de representación tabular, operaciones relacionales y control de integridad. Una hoja de cálculo, aunque visualmente similar, no cumple con los requisitos formales del modelo relacional.

🧩 Elementos esenciales

• Modelo relacional: Paradigma teórico que organiza datos en relaciones, con base matemática en álgebra y cálculo relacional.
• Relación: Estructura lógica central del modelo, implementada como tabla en los RDBMS.
• Tupla: Cada fila de una tabla, que representa una ocurrencia concreta de los hechos descritos.
• Atributo: Cada columna de una tabla, que describe una propiedad de las tuplas.
• Dominio: Conjunto de valores admisibles para un atributo.
• Esquema: Descripción formal de la estructura de una relación, incluyendo atributos y restricciones.
• Instancia: Contenido concreto de una relación en un momento dado.
• Clave primaria: Atributo o conjunto de atributos que identifica de forma unívoca cada tupla en una relación.
• Clave ajena: Atributo o conjunto de atributos que establece una relación entre tablas, garantizando integridad referencial.
• NULL: Valor especial que representa la ausencia de dato en un atributo.
• Restricciones: Reglas que el RDBMS aplica para preservar la integridad y coherencia de los datos.
• Independencia de datos: Principio que separa la representación lógica de los datos de su almacenamiento físico.

🧠 Recuerda

• El modelo relacional fue formulado por Edgar F. Codd para resolver la dependencia entre programas y almacenamiento físico.
• Su base matemática (álgebra y cálculo relacional) permite operaciones formales y declarativas.
• Las relaciones se implementan como tablas en los RDBMS, con filas (tuplas) y columnas (atributos).
• La independencia de datos es una de sus principales ventajas, al separar el nivel lógico del físico.
• El lenguaje SQL es el estándar para interactuar con bases de datos relacionales de forma declarativa.
• El modelo relacional es el fundamento de los sistemas gestores de bases de datos (RDBMS) utilizados en entornos corporativos y sanitarios.
• Las claves primarias y ajenas son esenciales para garantizar la integridad referencial.
• Aunque existen modelos alternativos (NoSQL), el modelo relacional sigue siendo dominante en sistemas transaccionales.

2. Definiciones y conceptos básicos

🎯 Idea clave

• Una base de datos relacional organiza la información mediante relaciones, implementadas en la práctica como tablas.
• La relación es la estructura lógica fundamental del modelo relacional, basada en conceptos matemáticos de conjuntos.
• Cada tabla representa una clase de hechos del mundo real, donde las filas son ocurrencias concretas y las columnas propiedades estables.
• El esquema de relación define la estructura estable (nombre y atributos con sus dominios), mientras que la instancia es el conjunto de tuplas en un momento dado.
• Los atributos son las columnas de una relación, asociadas a dominios que determinan los valores admisibles.
• Las tuplas son las filas de una relación, representando registros lógicos identificables mediante claves.

📚 Desarrollo

Concepto de base de datos relacional. Una base de datos relacional es un conjunto organizado de datos estructurados según el modelo relacional. Su objetivo es representar información mediante relaciones, que en la práctica se implementan como tablas. Cada tabla describe una clase de hechos del mundo real, como pacientes, diagnósticos o tratamientos, y cada fila representa una ocurrencia concreta de esa clase. Esta organización permite gestionar datos de forma lógica, estable y consultable, evitando la dependencia de ficheros aislados vinculados a programas específicos.

Relación como estructura fundamental. La relación es el concepto central del modelo relacional, definido matemáticamente como un subconjunto del producto cartesiano de un conjunto de dominios. Una relación tiene dos componentes: la intensión o esquema, que describe su estructura (nombre y lista de atributos con sus dominios), y la extensión o instancia, que es el conjunto de tuplas presentes en un momento determinado. El esquema permanece estable, mientras que la instancia varía con operaciones como inserciones, actualizaciones o borrados.

Propiedades formales de las relaciones. Las relaciones cumplen cuatro propiedades derivadas de su naturaleza matemática: no existen tuplas duplicadas, el orden de las tuplas es irrelevante, el orden de los atributos no afecta a la relación (se referencian por nombre) y todos los valores de atributo son atómicos. Estas propiedades garantizan coherencia y predictibilidad en el tratamiento de los datos. Sin embargo, en implementaciones prácticas como SQL, una tabla puede no cumplir todas estas propiedades si no se definen restricciones adecuadas, como claves primarias.

Dominios y atributos. Un dominio es un conjunto de valores atómicos del mismo tipo, como enteros, fechas o cadenas de texto, que define los valores posibles para un atributo. Los dominios pueden ser predefinidos o creados por el usuario con restricciones específicas. Los atributos son las columnas de una relación, cada una asociada a un dominio. Permiten referenciar la información por nombre, haciendo que la relación sea independiente del orden de las columnas. La precisión en la definición de dominios evita incoherencias, como almacenar fechas en formato texto libre.

Tuplas y claves. Una tupla es cada fila de una relación, correspondiente a un registro lógico que asocia valores a los atributos. Desde el punto de vista formal, una tupla debe ser distinguible de las demás para garantizar la correcta gestión de la información. Esta identificación se logra mediante claves candidatas, que son conjuntos mínimos de atributos que identifican de manera única cada tupla. De entre las claves candidatas, se elige una como clave primaria, que no puede contener valores nulos y debe permanecer estable para servir como referencia principal de las filas.

Grado y cardinalidad. El grado de una relación es el número de atributos que la componen, es decir, su cantidad de columnas. La cardinalidad, en cambio, es el número de tuplas presentes en un instante determinado, equivalente al número de filas. Estos conceptos son fundamentales para entender la estructura y el volumen de datos en una relación. Mientras el grado define la complejidad estructural, la cardinalidad refleja la cantidad de información almacenada en un momento dado.

Atomicidad y Primera Forma Normal. El modelo relacional clásico exige que cada valor almacenado en una celda sea atómico, es decir, indivisible desde la perspectiva del sistema. Esto no impide que existan datos complejos, pero sí requiere que cada unidad de información se almacene en el nivel adecuado para su consulta, validación y relación. Esta condición es la base de la Primera Forma Normal, que garantiza que las relaciones sean coherentes y manipulables mediante operaciones bien definidas.

Equivalencia terminológica. Aunque el modelo relacional emplea términos matemáticos como relación, tupla, atributo y dominio, en la práctica cotidiana de las bases de datos se utilizan equivalentes más intuitivos: tabla, fila (o registro), columna (o campo) y tipo de dato. Esta dualidad terminológica es relevante para opositores, ya que ambos conjuntos de términos aparecen en documentación técnica y exámenes. La precisión conceptual es clave, pero también lo es reconocer los sinónimos prácticos.

🧩 Elementos esenciales

• Base de datos relacional: Conjunto organizado de datos estructurados según el modelo relacional, implementado mediante tablas.
• Relación: Estructura lógica fundamental del modelo relacional, definida matemáticamente como un subconjunto del producto cartesiano de dominios.
• Esquema de relación: Definición estructural de una relación, incluyendo su nombre y la lista de atributos con sus dominios.
• Instancia de relación: Conjunto concreto de tuplas que contiene una relación en un momento dado, variable en el tiempo.
• Atributo: Columna de una relación, asociada a un dominio que determina los valores admisibles.
• Dominio: Conjunto de valores atómicos del mismo tipo, predefinido o creado por el usuario, que restringe los valores de un atributo.
• Tupla: Fila de una relación, correspondiente a un registro lógico que asocia valores a los atributos.
• Clave candidata: Conjunto mínimo de atributos que identifica de manera única cada tupla en una relación.
• Clave primaria: Clave candidata elegida como referencia principal de las tuplas, que no admite valores nulos y debe ser estable.
• Grado: Número de atributos de una relación, equivalente a su cantidad de columnas.
• Cardinalidad: Número de tuplas presentes en una relación en un instante determinado, equivalente a su cantidad de filas.
• Atomicidad: Propiedad que exige que cada valor de atributo sea indivisible desde la perspectiva del sistema, base de la Primera Forma Normal.

🧠 Recuerda

• Una base de datos relacional organiza la información en relaciones, implementadas como tablas en la práctica.
• La relación es un concepto matemático con propiedades formales: no duplicados, orden irrelevante y valores atómicos.
• El esquema de una relación define su estructura estable, mientras que la instancia varía con las operaciones sobre los datos.
• Los atributos son columnas asociadas a dominios, que determinan los valores válidos y evitan incoherencias.
• Las tuplas son filas identificables mediante claves, fundamentales para la gestión unívoca de la información.
• El grado se refiere al número de atributos, y la cardinalidad al número de tuplas en un momento dado.
• La atomicidad garantiza que cada valor sea indivisible, condición esencial para la coherencia del modelo.
• Los términos matemáticos (relación, tupla, atributo) tienen equivalentes prácticos (tabla, fila, columna).
• Una tabla SQL puede no cumplir todas las propiedades formales de una relación si no se definen restricciones adecuadas.
• La clave primaria es una clave candidata estable y no nula, elegida como referencia principal de las tuplas.

3. Arquitectura

🎯 Idea clave

• La arquitectura de un sistema de gestión de bases de datos relacional (RDBMS) define cómo se organizan sus componentes para almacenar, procesar y proteger la información.
• Se estructura en dos planos complementarios: el lógico, que define relaciones y reglas, y el físico, que gestiona el almacenamiento y acceso a los datos.
• La arquitectura ANSI/SPARC establece tres niveles de abstracción (externo, conceptual e interno) para garantizar independencia de datos.
• Los componentes funcionales del RDBMS incluyen módulos para procesamiento de consultas, control de transacciones, seguridad y recuperación.
• La arquitectura permite separar la visión del usuario de los detalles técnicos de almacenamiento, facilitando la evolución del sistema.
• Su diseño busca equilibrar rendimiento, disponibilidad y seguridad en entornos multiusuario como los del Servicio Andaluz de Salud.

📚 Desarrollo

Definición de arquitectura relacional. La arquitectura de una base de datos relacional es la organización técnica y lógica que permite gestionar datos estructurados en tablas de forma controlada. No se limita al diseño de tablas o al lenguaje SQL, sino que abarca capas, componentes, mecanismos de acceso, control de concurrencia, gestión transaccional, almacenamiento físico, seguridad y recuperación. Su objetivo es garantizar que los datos puedan consultarse, modificarse y protegerse de manera eficiente en entornos complejos.

Planos de la arquitectura. El modelo relacional distingue dos planos fundamentales. El plano lógico define relaciones, atributos, dominios, claves, restricciones y operaciones relacionales, respondiendo a qué datos existen y qué reglas deben cumplir. El plano físico y operativo gestiona ficheros, índices, memoria, procesos, sesiones y mecanismos de recuperación, determinando cómo el sistema ejecuta las operaciones manteniendo rendimiento y seguridad. Esta separación es clave para entender la robustez del modelo.

Arquitectura ANSI/SPARC. El marco de referencia conceptual para los sistemas gestores de bases de datos es la arquitectura ANSI/SPARC, que establece tres niveles de abstracción. El nivel externo corresponde a las vistas de usuario, adaptadas a necesidades específicas. El nivel conceptual define el esquema global de la base de datos, incluyendo entidades, relaciones y restricciones. El nivel interno gestiona la representación física en disco, como estructuras de almacenamiento e índices. Esta separación garantiza independencia lógica y física de los datos.

Independencia de datos. La arquitectura ANSI/SPARC proporciona dos tipos de independencia. La independencia lógica asegura que los cambios en el esquema conceptual no afecten a las vistas externas de los usuarios. La independencia física permite modificar el almacenamiento o la indexación sin alterar el esquema conceptual. Esta característica reduce el acoplamiento entre aplicaciones y almacenamiento, facilitando la evolución tecnológica sin reescribir la lógica asistencial o administrativa.

Componentes funcionales. Un RDBMS incluye módulos especializados para distintas funciones. El procesador de consultas interpreta y optimiza las peticiones SQL. El gestor de almacenamiento maneja el acceso a ficheros y páginas en disco. El control de transacciones asegura la atomicidad, consistencia, aislamiento y durabilidad (ACID) de las operaciones. El gestor de seguridad implementa permisos y autenticación. El gestor de recuperación restaura la base de datos tras fallos. Estos componentes trabajan de forma coordinada para garantizar fiabilidad.

Funcionamiento general. Cuando un usuario o aplicación envía una consulta, el RDBMS la procesa en varias fases. Primero, el analizador sintáctico verifica la corrección del SQL. Luego, el optimizador determina el plan de ejecución más eficiente. El gestor de ejecución coordina el acceso a los datos, aplicando bloqueos y controles de concurrencia. Finalmente, los resultados se devuelven al cliente. Este flujo ilustra cómo la arquitectura distribuye responsabilidades para manejar consultas complejas en entornos multiusuario.

Aplicación en entornos sanitarios. En el Servicio Andaluz de Salud, la arquitectura relacional soporta sistemas críticos como la historia clínica electrónica. La separación de niveles permite adaptar vistas para distintos perfiles (médicos, administrativos, pacientes) sin modificar el esquema global. La independencia física facilita escalar el almacenamiento o migrar a nuevos sistemas sin afectar a las aplicaciones. La gestión transaccional asegura que operaciones como la actualización de citas o informes se realicen de forma consistente y segura.

🧩 Elementos esenciales

• Plano lógico: Define relaciones, atributos, claves y restricciones, determinando la estructura conceptual de los datos.
• Plano físico: Gestiona el almacenamiento en disco, índices, páginas y mecanismos de acceso para optimizar el rendimiento.
• Nivel externo (ANSI/SPARC): Vistas personalizadas para usuarios o aplicaciones, adaptadas a necesidades específicas.
• Nivel conceptual (ANSI/SPARC): Esquema global que describe entidades, relaciones y reglas de integridad de la base de datos.
• Nivel interno (ANSI/SPARC): Representación física de los datos, incluyendo ficheros, índices y estructuras de almacenamiento.
• Independencia lógica: Los cambios en el esquema conceptual no afectan a las vistas externas de los usuarios.
• Independencia física: Las modificaciones en el almacenamiento no alteran el esquema conceptual ni las aplicaciones.
• Procesador de consultas: Módulo encargado de interpretar, optimizar y ejecutar las peticiones SQL.
• Gestor de almacenamiento: Controla el acceso a los datos en disco, gestionando ficheros y páginas.
• Control de transacciones: Asegura que las operaciones cumplan las propiedades ACID (atomicidad, consistencia, aislamiento, durabilidad).
• Gestor de seguridad: Implementa mecanismos de autenticación, autorización y protección de datos.
• Gestor de recuperación: Restaura la base de datos tras fallos, utilizando registros de transacciones y copias de seguridad.

🧠 Recuerda

• La arquitectura relacional no se limita a tablas o SQL, sino que abarca componentes técnicos y lógicos para gestionar datos.
• Los dos planos (lógico y físico) permiten separar la definición de los datos de su implementación técnica.
• La arquitectura ANSI/SPARC con sus tres niveles (externo, conceptual e interno) es la base de la independencia de datos.
• La independencia lógica y física facilita la evolución del sistema sin afectar a usuarios o aplicaciones.
• Los módulos funcionales (procesador de consultas, gestor de almacenamiento, control de transacciones) trabajan coordinadamente.
• En entornos sanitarios como el SAS, la arquitectura soporta sistemas críticos con requisitos de seguridad y disponibilidad.
• La separación de niveles permite adaptar vistas para distintos perfiles sin modificar el esquema global.
• La gestión transaccional es clave para garantizar la consistencia de operaciones en entornos multiusuario.

4. Diseño

🎯 Idea clave

• El diseño de una base de datos relacional es un proceso sistemático que transforma necesidades de información en una estructura de datos coherente, íntegra y mantenible.
• Su objetivo principal es garantizar la calidad estructural del sistema, evitando redundancias, inconsistencias y dificultades de mantenimiento.
• Se estructura en tres fases sucesivas: diseño conceptual, diseño lógico y diseño físico, cada una con un nivel de abstracción distinto.
• Un buen diseño facilita la evolución del sistema y permite implementar requisitos de seguridad, protección de datos e interoperabilidad.
• En el ámbito sanitario, como en el SAS, el diseño debe considerar finalidades asistenciales, administrativas, docentes e investigadoras con reglas de acceso diferenciadas.
• La calidad del diseño depende del criterio con el que se definan estructuras, relaciones y restricciones, más que de herramientas de modelado.

📚 Desarrollo

Proceso metodológico. El diseño de una base de datos relacional es una actividad técnica y metodológica que conecta los procesos reales de una organización con una representación formal de datos. No se limita a crear tablas, sino que implica decidir qué hechos del dominio deben persistir, cómo se agrupan en relaciones, qué atributos describen cada relación y qué restricciones impiden estados inválidos. Este proceso es fundamental para el Técnico Especialista en Informática del SAS, ya que debe participar en el diseño, revisión y mantenimiento de esquemas de bases de datos sanitarias.

Fases del diseño. El diseño se desarrolla en tres fases diferenciadas: conceptual, lógico y físico. El diseño conceptual identifica entidades, atributos y relaciones sin considerar detalles físicos. El diseño lógico transforma estas entidades en tablas, claves y restricciones. Finalmente, el diseño físico aborda aspectos de almacenamiento, índices, particiones y despliegue según el gestor de bases de datos elegido. Esta secuencia evita confundir necesidades funcionales con decisiones técnicas prematuras.

Requisitos de calidad. Un diseño deficiente produce bases de datos con redundancias, inconsistencias y rendimiento deficiente. En cambio, un diseño sólido garantiza la integridad de los datos, facilita su mantenimiento y proporciona una base estable para implementar requisitos de seguridad y protección de datos. En entornos sanitarios, como el SAS, esto es crítico debido a la sensibilidad de la información y la necesidad de interoperabilidad entre sistemas.

Traducción de requisitos. El diseño convierte requisitos de información, inicialmente expresados en términos organizativos, en una estructura de datos preparada para su implantación en un sistema gestor de bases de datos relacional (RDBMS). No se trata solo de representar datos, sino de incorporar reglas, proteger la integridad y considerar la explotación futura del sistema. La claridad y la capacidad de evolución son objetivos clave en esta fase.

Enfoque en el dominio. El diseño relacional exige comprender el dominio de aplicación para modelar correctamente las entidades y sus relaciones. En el SAS, por ejemplo, es necesario distinguir entre información asistencial, administrativa, profesional y económica, ya que cada una puede tener reglas de acceso y conservación distintas. Esta diferenciación es esencial para garantizar la disponibilidad y la trazabilidad de los datos.

Herramientas y criterio. Aunque las herramientas de modelado pueden asistir en el proceso de diseño, la calidad final depende del criterio con el que se definan las estructuras, relaciones y restricciones. Un buen diseño debe evitar duplicidades innecesarias, ambigüedades semánticas y dependencias ocultas que generen anomalías en las operaciones de inserción, modificación o borrado.

Impacto en la explotación. Un diseño bien estructurado permite consultar y actualizar la información de manera eficiente, sin comprometer la coherencia de los datos. En sistemas sanitarios, esto es especialmente relevante para garantizar la continuidad asistencial y la correcta gestión de la información clínica, como en el caso del sistema Diraya del SAS.

🧩 Elementos esenciales

• Diseño conceptual: Fase inicial en la que se identifican entidades, atributos y relaciones sin considerar detalles físicos.
• Diseño lógico: Transformación de las entidades conceptuales en tablas, claves y restricciones, adaptadas al modelo relacional.
• Diseño físico: Decisiones sobre almacenamiento, índices, particiones y despliegue según el gestor de bases de datos elegido.
• Requisitos funcionales: Describen qué debe almacenar y permitir hacer el sistema, como operaciones de consulta o actualización.
• Requisitos no funcionales: Condiciones de calidad como rendimiento, disponibilidad, seguridad y escalabilidad.
• Entidades: Objetos o hechos relevantes del dominio, como pacientes, profesionales o centros sanitarios.
• Atributos: Propiedades que describen las entidades, como nombre, fecha de nacimiento o número de historia clínica.
• Relaciones: Asociaciones entre entidades, como la relación entre un paciente y sus episodios asistenciales.
• Cardinalidad: Indica cuántas ocurrencias de una entidad pueden participar en una relación (uno a uno, uno a muchos, muchos a muchos).
• Claves primarias: Identificadores únicos de cada registro en una tabla.
• Claves ajenas: Campos que permiten relacionar tablas entre sí, garantizando la coherencia de los datos.
• Restricciones: Reglas que impiden estados inválidos en la base de datos, como valores nulos o duplicados.

🧠 Recuerda

• El diseño de una base de datos relacional es un proceso sistemático que conecta requisitos con una estructura de datos implementable.
• Las tres fases del diseño (conceptual, lógico y físico) permiten abordar el problema en niveles de abstracción distintos.
• Un buen diseño evita redundancias, inconsistencias y dificultades de mantenimiento.
• En entornos sanitarios, el diseño debe considerar finalidades asistenciales, administrativas y de investigación con reglas diferenciadas.
• La calidad del diseño depende del criterio en la definición de estructuras, relaciones y restricciones.
• El diseño conceptual se centra en el dominio, mientras que el diseño físico aborda aspectos técnicos del gestor.
• Las claves primarias y ajenas son fundamentales para garantizar la integridad y las relaciones entre tablas.
• Un diseño sólido facilita la evolución del sistema y la implementación de requisitos de seguridad y protección de datos.

5. Normalización

🎯 Idea clave

• La normalización es un proceso formal de análisis y descomposición de relaciones en bases de datos relacionales para eliminar redundancias y anomalías.
• Su objetivo principal es preservar la semántica de los datos y garantizar la integridad mediante estructuras libres de problemas de actualización.
• Las formas normales son condiciones sucesivas que una relación debe cumplir, ordenadas jerárquicamente desde la 1FN hasta la 5FN.
• Cada forma normal elimina tipos específicos de redundancia y anomalías, construyendo sobre los requisitos de las anteriores.
• El núcleo práctico de la normalización en oposiciones se centra en las formas normales 1FN, 2FN, 3FN y BCNF.
• Las formas normales 4FN y 5FN abordan problemas más específicos y complejos, pero son menos frecuentes en la práctica cotidiana.

📚 Desarrollo

Definición y propósito. La normalización es el proceso sistemático de organizar las tablas de una base de datos relacional para minimizar la redundancia y mejorar la integridad de los datos. Fue desarrollada por E. F. Codd junto al modelo relacional y ampliada por otros autores como Raymond Boyce y William W. Armstrong. Su finalidad es evitar que una misma información aparezca duplicada sin necesidad, lo que debilita la consistencia del sistema y genera anomalías en operaciones de inserción, actualización y eliminación.

Jerarquía de formas normales. Las formas normales son condiciones progresivas que una relación debe satisfacer, cada una construyendo sobre los requisitos de la anterior. La secuencia establecida es: 1FN ⊂ 2FN ⊂ 3FN ⊂ BCNF ⊂ 4FN ⊂ 5FN. Cada nivel elimina un tipo específico de redundancia o anomalía, garantizando un diseño más robusto y libre de inconsistencias. El cumplimiento de una forma normal implica automáticamente el cumplimiento de todas las anteriores.

Primera Forma Normal (1FN). Una relación está en 1FN cuando todos sus atributos son atómicos, es decir, no contienen grupos repetitivos ni valores compuestos. Cada celda de la tabla debe almacenar un único valor, evitando listas o estructuras anidadas. Esta forma normal elimina problemas derivados de atributos multivaluados y garantiza que cada dato sea accesible individualmente mediante consultas relacionales.

Segunda Forma Normal (2FN). Para cumplir la 2FN, una relación debe estar en 1FN y, además, todos sus atributos no clave deben depender funcionalmente de la clave primaria completa. Esto es especialmente relevante en relaciones con claves primarias compuestas, donde se evitan dependencias parciales que generan redundancias. La 2FN elimina anomalías derivadas de atributos que dependen solo de una parte de la clave, asegurando que cada dato esté vinculado al conjunto completo de atributos que lo identifican.

Tercera Forma Normal (3FN). Una relación está en 3FN si cumple la 2FN y no existen dependencias transitivas entre atributos no clave. Esto significa que un atributo no clave no puede depender de otro atributo no clave, sino únicamente de la clave primaria. La 3FN evita redundancias causadas por datos maestros embebidos en tablas operativas, como almacenar información de un departamento dentro de una tabla de empleados cuando esta ya existe en una tabla independiente.

Forma Normal de Boyce-Codd (BCNF). La BCNF refuerza la 3FN al exigir que todo determinante de una dependencia funcional no trivial sea una superclave. Esto resuelve anomalías residuales que pueden persistir en relaciones con múltiples claves candidatas solapadas. La BCNF es más estricta que la 3FN y garantiza que no existan dependencias funcionales que no estén directamente relacionadas con la clave primaria o candidatas.

Formas normales avanzadas (4FN y 5FN). La Cuarta Forma Normal (4FN) aborda las dependencias multivaluadas, que surgen cuando un atributo puede tener múltiples valores independientes asociados a la clave, generando productos cartesianos artificiales. Una relación está en 4FN si está en BCNF y no contiene dependencias multivaluadas no triviales. La Quinta Forma Normal (5FN) es el nivel más alto de normalización y se aplica cuando una relación no puede descomponerse en relaciones más pequeñas sin pérdida de información. Ambas formas normales son relevantes en contextos teóricos y casos específicos, pero su aplicación práctica es menos frecuente en entornos empresariales.

Beneficios y limitaciones. La normalización reduce significativamente las redundancias y las anomalías de actualización, mejorando la calidad y consistencia de los datos. Sin embargo, este proceso puede aumentar la complejidad de las consultas al requerir más operaciones de unión (JOIN) entre tablas. El equilibrio entre normalización y rendimiento es clave en el diseño de bases de datos, especialmente en sistemas con altos volúmenes de transacciones o consultas complejas.

🧩 Elementos esenciales

• Normalización: Proceso de reorganización de tablas para minimizar redundancias y mejorar la integridad de los datos.
• Formas normales: Condiciones sucesivas (1FN a 5FN) que una relación debe cumplir para garantizar ausencia de anomalías.
• 1FN: Atributos atómicos y sin grupos repetitivos; elimina valores compuestos y multivaluados.
• 2FN: Sin dependencias parciales de la clave primaria compuesta; elimina redundancias por atributos que dependen de parte de la clave.
• 3FN: Sin dependencias transitivas entre atributos no clave; evita redundancias por datos maestros embebidos.
• BCNF: Todo determinante de dependencia funcional no trivial es superclave; resuelve anomalías con claves candidatas solapadas.
• 4FN: Sin dependencias multivaluadas no triviales; elimina productos cartesianos artificiales entre atributos independientes.
• 5FN: Sin dependencias de unión no triviales; evita descomposiciones adicionales sin pérdida de información.
• Dependencia funcional: Relación en la que el valor de un atributo determina el valor de otro.
• Dependencia multivaluada: Situación en la que un atributo determina múltiples valores independientes de otros atributos.
• Anomalías: Problemas de inserción, actualización o eliminación derivados de redundancias en el diseño.
• Descomposición: División de una relación en tablas más pequeñas para cumplir con una forma normal específica.

🧠 Recuerda

• La normalización es un proceso clave en el diseño lógico de bases de datos relacionales.
• Cada forma normal elimina un tipo específico de redundancia o anomalía.
• La jerarquía de formas normales es acumulativa: cumplir una implica cumplir todas las anteriores.
• Las formas normales 1FN, 2FN, 3FN y BCNF son las más relevantes en la práctica cotidiana.
• La 4FN y la 5FN abordan problemas más complejos y son menos frecuentes en entornos empresariales.
• La normalización mejora la integridad de los datos pero puede aumentar la complejidad de las consultas.
• El equilibrio entre normalización y rendimiento es esencial en el diseño de bases de datos.
• Las dependencias funcionales y multivaluadas son conceptos clave para entender las formas normales.
• La BCNF es más estricta que la 3FN y resuelve anomalías residuales con claves candidatas.
• La descomposición sin pérdida de información es un principio fundamental en la normalización avanzada.

6. Manipulación: álgebra y cálculo relacional

🎯 Idea clave

• El álgebra relacional es un lenguaje procedimental que especifica la secuencia de operaciones necesarias para obtener un resultado a partir de relaciones.
• El cálculo relacional es un lenguaje declarativo que define las condiciones que deben cumplir las tuplas o valores del resultado, sin detallar el procedimiento.
• Ambos enfoques son equivalentes en expresividad y constituyen la base teórica del lenguaje SQL.
• Las operaciones fundamentales del álgebra relacional incluyen selección, proyección, unión, diferencia, producto cartesiano y renombramiento.
• Las operaciones derivadas, como el join o la división, facilitan consultas complejas y son esenciales en la práctica.
• SQL incorpora extensiones al álgebra relacional básica, como agregación, ordenación y manejo de valores NULL.

📚 Desarrollo

Carácter procedimental del álgebra relacional. El álgebra relacional se define como un lenguaje procedimental porque el usuario debe especificar no solo qué datos desea obtener, sino también el procedimiento concreto —una secuencia de operaciones— para alcanzarlos. Cada operación toma una o varias relaciones como entrada y produce una nueva relación como salida, lo que permite encadenar transformaciones de manera lógica y sistemática.

Cierre relacional y composición. Una propiedad fundamental del álgebra relacional es el cierre relacional, que garantiza que el resultado de cualquier operación es siempre una relación. Esta característica permite componer operaciones de forma anidada, utilizando el resultado de una operación como entrada de la siguiente. Este principio es clave para construir consultas complejas y entender cómo se manipulan los datos en sistemas relacionales.

Operaciones fundamentales. El álgebra relacional se basa en seis operaciones fundamentales: selección (σ), que filtra filas según una condición; proyección (π), que selecciona columnas específicas; unión (∪), que combina tuplas de relaciones compatibles; diferencia (−), que devuelve tuplas presentes en una relación pero no en otra; producto cartesiano (×), que combina todas las tuplas de dos relaciones; y renombramiento (ρ), que asigna nuevos nombres a atributos o relaciones. Estas operaciones son suficientes para expresar cualquier consulta relacional.

Operaciones derivadas. Aunque las operaciones fundamentales bastan para la expresividad, el álgebra relacional incluye operaciones derivadas que simplifican consultas frecuentes. Entre ellas destacan el join natural (⋈), que combina relaciones basándose en atributos comunes; el theta-join (⋈_θ), que permite condiciones de combinación arbitrarias; y la división (÷), que responde a consultas del tipo "para todos". El join es la operación más utilizada en la práctica, ya que permite recomponer información distribuida en múltiples tablas.

Enfoque declarativo del cálculo relacional. A diferencia del álgebra, el cálculo relacional adopta un enfoque declarativo, centrado en describir las propiedades que deben cumplir los datos del resultado. No se especifica cómo obtenerlos, sino qué condiciones deben satisfacer. Esta orientación lo acerca a la lógica de predicados y facilita la formulación de consultas complejas sin preocuparse por los detalles operativos. El cálculo relacional se divide en dos variantes: el cálculo de tuplas, que usa variables sobre filas, y el cálculo de dominios, que usa variables sobre valores de atributos.

Equivalencia expresiva. Tanto el álgebra relacional como el cálculo relacional son relacionalmente completos, lo que significa que pueden expresar cualquier consulta que el otro pueda formular. Esta equivalencia teórica es fundamental, ya que garantiza que SQL, al basarse en estos modelos, puede implementar cualquier consulta relacional. Sin embargo, SQL va más allá al incorporar extensiones prácticas, como funciones de agregación (SUM, AVG, COUNT), ordenación (ORDER BY) o manejo de valores NULL.

Limitaciones del álgebra relacional básica. Aunque el álgebra relacional es relacionalmente completa, presenta limitaciones en escenarios prácticos. No incluye operaciones de agregación, aritmética sobre atributos, ordenación de resultados ni manejo de valores NULL. Tampoco soporta consultas recursivas, como el recorrido de jerarquías. SQL resuelve estas carencias mediante extensiones específicas, como GROUP BY, expresiones aritméticas en SELECT o WITH RECURSIVE, lo que lo convierte en un lenguaje más versátil para el desarrollo de aplicaciones reales.

Relación con SQL. Las equivalencias entre el álgebra relacional y SQL son directas: WHERE equivale a la selección (σ), SELECT columnas a la proyección (π), UNION a la unión (∪), EXCEPT a la diferencia (−), y JOIN al join natural (⋈). Comprender estas correspondencias ayuda a interpretar las consultas SQL desde una perspectiva teórica y a optimizar su rendimiento, ya que los sistemas gestores de bases de datos (SGBD) aplican transformaciones algebraicas para ejecutarlas de manera eficiente.

🧩 Elementos esenciales

• Álgebra relacional: Lenguaje procedimental que define operaciones sobre relaciones para obtener resultados mediante secuencias de transformaciones.
• Cálculo relacional: Lenguaje declarativo basado en condiciones lógicas que describen las propiedades del resultado, sin especificar el procedimiento.
• Operaciones fundamentales: Selección (σ), proyección (π), unión (∪), diferencia (−), producto cartesiano (×) y renombramiento (ρ).
• Operaciones derivadas: Join natural (⋈), theta-join (⋈_θ), intersección (∩), división (÷) y semijoin (⋉).
• Cierre relacional: Propiedad que garantiza que el resultado de cualquier operación es siempre una relación, permitiendo la composición de operaciones.
• Cálculo de tuplas: Variante del cálculo relacional que utiliza variables sobre filas y cuantificadores existenciales (∃) y universales (∀).
• Cálculo de dominios: Variante del cálculo relacional que utiliza variables sobre valores de atributos y es la base de lenguajes como QBE.
• Completud relacional: Capacidad de un lenguaje para expresar cualquier consulta formulable en álgebra o cálculo relacional.
• Extensiones de SQL: Funciones de agregación (SUM, AVG, COUNT), ordenación (ORDER BY), manejo de NULL y recursión (WITH RECURSIVE).
• Equivalencias SQL: WHERE ≡ σ, SELECT columnas ≡ π, UNION ≡ ∪, EXCEPT ≡ −, JOIN ≡ ⋈.
• Optimización en SGBD: Los sistemas gestores aplican heurísticas algebraicas, como el push-down de selecciones y proyecciones, para mejorar el rendimiento de las consultas.

🧠 Recuerda

• El álgebra relacional es procedimental; el cálculo relacional es declarativo.
• Ambos son equivalentes en expresividad y constituyen la base teórica de SQL.
• Las seis operaciones fundamentales del álgebra son selección, proyección, unión, diferencia, producto cartesiano y renombramiento.
• El join es la operación derivada más utilizada en la práctica.
• SQL extiende el álgebra relacional con agregación, ordenación y manejo de NULL.
• WHERE en SQL equivale a la selección (σ) del álgebra relacional.
• El cálculo de tuplas usa variables sobre filas; el cálculo de dominios, sobre valores de atributos.
• Un lenguaje es relacionalmente completo si puede expresar cualquier consulta del álgebra relacional.
• La división (÷) responde a consultas del tipo "para todos".
• Los SGBD optimizan consultas aplicando transformaciones algebraicas.

7. Modelo entidad– relación

🎯 Idea clave

• El modelo entidad-relación es una técnica de modelado conceptual de datos que representa elementos relevantes de un dominio y sus asociaciones.
• Su objetivo principal es comprender la realidad antes de traducirla a estructuras relacionales como tablas o claves.
• Se sitúa en la fase conceptual del diseño de bases de datos, sin sustituir al modelo relacional ni a la normalización.
• Permite identificar objetos, propiedades, relaciones y restricciones estructurales del dominio analizado.
• Facilita la comunicación entre analistas y prepara el diseño lógico posterior.
• Las relaciones en este modelo expresan vínculos significativos entre entidades, anticipando cómo se enlazarán las tablas futuras.

📚 Desarrollo

Modelado conceptual. El modelo entidad-relación se utiliza para representar de manera estructurada y comprensible los elementos clave de un dominio de información. Su valor no radica en la implementación inmediata, sino en servir como herramienta de análisis para entender la realidad antes de diseñar el esquema relacional. Este enfoque evita errores de diseño al clarificar qué objetos son relevantes y cómo se relacionan.

Fase de diseño. Este modelo pertenece a la fase conceptual o de alto nivel del diseño de bases de datos. No compite con el modelo relacional, que tiene su propia lógica, ni con técnicas como la normalización o el lenguaje SQL. Su misión es ofrecer una representación semántica clara del dominio, definiendo entidades, atributos, relaciones y restricciones estructurales que deben respetarse.

Entidades y relaciones. Las entidades representan tipos de objetos relevantes dentro del dominio, como pacientes, profesionales o centros sanitarios. Las relaciones, por su parte, expresan vínculos significativos entre estas entidades, como la adscripción de un paciente a un centro o la pertenencia de un profesional a una unidad. Estos vínculos no son meras conexiones gráficas, sino asociaciones con significado propio en el dominio.

Preparación para el modelo relacional. Una relación bien definida en el modelo entidad-relación facilita la transición al modelo relacional. Al anticipar cómo se enlazarán las futuras tablas, este modelo ayuda a evitar ambigüedades y redundancias en el diseño lógico. Por ejemplo, una relación entre "paciente" y "centro" puede traducirse posteriormente en una clave ajena en la tabla de pacientes.

Herramienta de comunicación. El modelo entidad-relación actúa como un puente entre los requisitos funcionales y el diseño técnico. Permite a analistas, desarrolladores y usuarios compartir una visión común del dominio, reduciendo malentendidos y asegurando que el sistema final refleje las necesidades reales. Su representación gráfica simplifica la discusión de aspectos complejos.

Restricciones estructurales. Además de definir entidades y relaciones, este modelo permite especificar restricciones que deben cumplirse en el dominio. Estas restricciones, como la cardinalidad de las relaciones o la obligatoriedad de ciertos atributos, se traducirán posteriormente en reglas de integridad en el modelo relacional.

Ejemplo en entornos sanitarios. En una organización sanitaria, el modelo entidad-relación puede representar entidades como usuarios, episodios, profesionales, centros, citas o informes. Las relaciones entre ellas, como "un profesional atiende a un paciente" o "un centro gestiona citas", permiten estructurar la información de manera coherente y evitar duplicidades.

🧩 Elementos esenciales

• Entidad: Objeto relevante del dominio, como un paciente, un profesional o un centro sanitario.
• Atributo: Propiedad de una entidad, como el nombre de un paciente o el código de un centro.
• Relación: Vínculo significativo entre entidades, como "adscripción" entre paciente y centro.
• Cardinalidad: Indica cuántas instancias de una entidad pueden asociarse con instancias de otra, como uno a muchos o muchos a muchos.
• Restricción estructural: Regla que define condiciones obligatorias, como la unicidad de un atributo o la obligatoriedad de una relación.
• Diagrama entidad-relación: Representación gráfica del modelo, donde las entidades son rectángulos, los atributos óvalos y las relaciones rombos.
• Fase conceptual: Etapa del diseño donde se aplica este modelo, previa al diseño lógico y físico.
• Dominio de información: Ámbito específico que se modela, como la gestión sanitaria o la administración de citas.
• Esquema semántico: Descripción de las entidades, atributos, relaciones y restricciones del dominio.
• Preparación para el modelo relacional: Función del modelo entidad-relación de anticipar la estructura de tablas y claves.

🧠 Recuerda

• El modelo entidad-relación es una herramienta de análisis, no de implementación.
• Su objetivo es comprender el dominio antes de diseñar la base de datos relacional.
• Las entidades representan objetos relevantes y las relaciones sus vínculos significativos.
• Este modelo facilita la comunicación entre analistas y usuarios.
• Las restricciones definidas aquí se traducirán en reglas de integridad en el modelo relacional.
• Se sitúa en la fase conceptual del diseño de bases de datos.
• Una relación bien definida anticipa cómo se enlazarán las tablas en el modelo relacional.
• Es útil para evitar redundancias y ambigüedades en el diseño.
• Su representación gráfica simplifica la discusión de aspectos complejos.
• No sustituye al modelo relacional, sino que lo prepara.

8. El lenguaje SQL

🎯 Idea clave

• SQL es el lenguaje estándar para la definición, manipulación y control de bases de datos relacionales, utilizado en la mayoría de sistemas gestores.
• Su naturaleza declarativa permite especificar qué datos se desean obtener, sin detallar el procedimiento de ejecución.
• Fue desarrollado por IBM en los años 70 y estandarizado por ANSI e ISO, con revisiones periódicas que incorporan nuevas funcionalidades.
• SQL no es sinónimo del modelo relacional, sino el instrumento práctico para interactuar con sistemas que implementan sus principios.
• Incluye extensiones que superan las limitaciones del álgebra relacional básica, como agregación, ordenación y tratamiento de valores NULL.
• Su dominio es esencial en oposiciones, donde se valora la comprensión de su función y relación con la teoría relacional.

📚 Desarrollo

Origen y estandarización. SQL (Structured Query Language) fue desarrollado originalmente por IBM en la década de 1970 bajo el nombre SEQUEL, como parte del proyecto System R. En 1986, fue adoptado como estándar internacional por ANSI (SQL-86) e ISO (1987), iniciando una serie de revisiones que han incorporado mejoras significativas. Entre las versiones más relevantes destacan SQL-92 (SQL-2), SQL:1999 (SQL-3, con procedimientos almacenados y tipos de datos objeto) y SQL:2003 (con soporte para XML y funciones de ventana). La versión más ampliamente soportada en la actualidad es SQL:2003/SQL:2008, aunque los principales SGBDR como Oracle, SQL Server y PostgreSQL han incorporado características de versiones posteriores.

Naturaleza declarativa. SQL se caracteriza por ser un lenguaje declarativo, lo que significa que el usuario especifica qué datos desea obtener o modificar, sin necesidad de detallar cómo debe ejecutarse la operación. Esta tarea recae en el optimizador del sistema gestor de bases de datos, que determina el plan de ejecución más eficiente en función de estadísticas, índices, cardinalidades y coste estimado. Esta característica lo diferencia de los lenguajes procedimentales y facilita su aprendizaje, aunque el rendimiento de las consultas depende también del conocimiento de aspectos como claves, índices y volumen de datos.

Ámbito de aplicación. SQL no se limita a ser un lenguaje de consulta, sino que abarca la definición de estructuras (DDL), la manipulación de datos (DML), el control de acceso (DCL) y el control transaccional (TCL). Permite crear tablas, índices y vistas, insertar, actualizar y eliminar datos, gestionar permisos y garantizar la atomicidad de las transacciones. Esta amplitud funcional lo convierte en el instrumento central para interactuar con bases de datos relacionales, tanto para usuarios como para administradores y aplicaciones.

Relación con la teoría relacional. SQL se basa en los fundamentos del álgebra relacional y el cálculo relacional, aunque no se confunde con ellos. Mientras el álgebra relacional es un lenguaje procedimental que especifica operaciones sobre relaciones, SQL adopta un enfoque declarativo, similar al cálculo relacional. Esta equivalencia teórica explica por qué SQL puede expresarse de forma declarativa y, al mismo tiempo, traducirse internamente a operaciones optimizadas sobre relaciones. Sin embargo, SQL supera las limitaciones del álgebra relacional básica al incorporar funciones de agregación, ordenación, agrupación y tratamiento de valores NULL.

Extensiones y expresividad. El álgebra relacional básica, propuesta por Codd, es relacionalmente completa pero presenta limitaciones prácticas. SQL resuelve estas carencias mediante extensiones como funciones de agregación (SUM, AVG, COUNT, MIN, MAX), ordenación (ORDER BY), agrupación (GROUP BY, HAVING), subconsultas, lógica trivaluada para valores NULL y expresiones de tabla comunes recursivas (WITH RECURSIVE, introducidas en SQL:1999). Estas mejoras lo convierten en un lenguaje más expresivo, capaz de abordar consultas complejas como jerarquías recursivas o cálculos aritméticos sobre atributos.

Equivalencias con el álgebra relacional. SQL mantiene una correspondencia directa con las operaciones del álgebra relacional, lo que facilita la comprensión de su funcionamiento. Por ejemplo, la cláusula WHERE equivale a la selección (σ), SELECT (columnas) a la proyección (π), UNION a la unión (∪), EXCEPT a la diferencia (−) y JOIN a la operación de join (⋈). Estas equivalencias permiten traducir consultas entre ambos marcos teóricos y destacan la influencia del álgebra relacional en el diseño de SQL.

Importancia en oposiciones. En el ámbito de las oposiciones, especialmente para categorías técnicas como Técnico Especialista en Informática, SQL ocupa un lugar central. No se exige memorizar todas las variantes sintácticas de cada SGBDR, sino comprender su papel dentro del ecosistema relacional, sus tipos de operaciones, su organización general y su relación con la teoría previa. También es relevante conocer la tensión entre el estándar común y las extensiones propietarias de productos como Oracle, PostgreSQL o SQL Server, así como su capacidad para soportar la vida completa de una base de datos relacional.

🧩 Elementos esenciales

• Lenguaje estándar: SQL es el lenguaje universal para interactuar con bases de datos relacionales, reconocido por ANSI e ISO.
• Declarativo: El usuario especifica el resultado deseado, no el procedimiento de ejecución, que es determinado por el optimizador del SGBDR.
• Versiones: Desde SQL-86 hasta SQL:2019, con SQL:2003/SQL:2008 como versiones más soportadas en la actualidad.
• Ámbito funcional: Incluye definición (DDL), manipulación (DML), control de acceso (DCL) y control transaccional (TCL).
• Relación con el álgebra relacional: SQL se basa en sus conceptos, pero añade extensiones como agregación, ordenación y tratamiento de NULL.
• Equivalencias clave: WHERE ≡ σ (selección), SELECT columnas ≡ π (proyección), UNION ≡ ∪, EXCEPT ≡ −, JOIN ≡ ⋈.
• Expresividad: Supera al álgebra relacional básica con funciones de agregación, GROUP BY, ORDER BY y recursión.
• Valores NULL: SQL introduce lógica trivaluada para manejar información ausente, algo no contemplado en el álgebra relacional clásica.
• Optimización: El rendimiento de las consultas depende de índices, claves, joins y volumen de datos, no solo de la sintaxis.
• Estándar vs. extensiones: Existe un núcleo común, pero cada SGBDR incorpora funcionalidades propias.
• Relevancia en oposiciones: Se valora la comprensión conceptual más que la memorización de sintaxis específica.

🧠 Recuerda

• SQL es el lenguaje práctico para interactuar con bases de datos relacionales, no un sinónimo del modelo relacional.
• Su naturaleza declarativa lo diferencia de los lenguajes procedimentales como el álgebra relacional.
• Fue estandarizado por ANSI e ISO, con revisiones periódicas que incorporan nuevas funcionalidades.
• Incluye operaciones de definición, manipulación, control de acceso y transaccionalidad.
• Se basa en el álgebra y el cálculo relacional, pero los supera en expresividad con agregación, ordenación y recursión.
• Las equivalencias con el álgebra relacional (WHERE ≡ σ, SELECT ≡ π, etc.) son clave para entender su funcionamiento.
• El optimizador del SGBDR determina el plan de ejecución, por lo que el rendimiento depende de índices y estructura de datos.
• En oposiciones, se prioriza la comprensión de su papel y relación con la teoría relacional sobre la sintaxis detallada.
• Cada SGBDR implementa el estándar SQL con extensiones propias, lo que genera diferencias entre productos.
• SQL es relacionalmente completo y esencial para el trabajo con bases de datos en entornos profesionales.

9. Normas y estándares para la interoperabilidad entre gestores de bases de datos relacionales

🎯 Idea clave

• La interoperabilidad entre gestores de bases de datos relacionales se sustenta en normas y estándares que garantizan el acceso uniforme a distintos sistemas.
• El lenguaje SQL, definido por la norma ISO/IEC 9075, actúa como base común para la comunicación con bases de datos relacionales.
• ODBC y JDBC son interfaces estandarizadas que permiten a las aplicaciones acceder a múltiples SGBD sin modificar su código fuente.
• La especificación CLI (Call Level Interface), integrada en la norma ISO/IEC 9075, proporciona un marco para la interoperabilidad a nivel de llamadas.
• Los metadatos estandarizados, como los definidos en INFORMATION_SCHEMA, facilitan la consulta de estructuras de bases de datos de forma homogénea.
• La combinación de SQL, interfaces de acceso y metadatos estandarizados permite la interoperabilidad en entornos heterogéneos.

📚 Desarrollo

Base normativa del lenguaje SQL. La norma ISO/IEC 9075 establece el marco formal del lenguaje SQL, proporcionando una sintaxis y semántica comunes para la definición, manipulación y control de datos en sistemas relacionales. Esta norma actúa como referencia obligada para los SGBD, asegurando que las consultas y operaciones básicas sean compatibles entre distintos gestores. La estandarización del lenguaje elimina barreras técnicas y facilita la migración de aplicaciones entre plataformas.

Interfaces de acceso estandarizadas. ODBC (Open Database Connectivity) y JDBC (Java Database Connectivity) son las dos interfaces principales que permiten a las aplicaciones interactuar con múltiples SGBD mediante una API común. ODBC, desarrollado inicialmente por Microsoft y posteriormente estandarizado, utiliza un gestor de controladores que carga dinámicamente el driver específico del SGBD, traduciendo las llamadas genéricas a instrucciones nativas. JDBC, por su parte, cumple una función similar en el ecosistema Java, ofreciendo una capa de abstracción que independiza el código de la aplicación del gestor subyacente.

Especificación CLI y su integración. La especificación CLI (Call Level Interface), incluida en la parte 3 de la norma ISO/IEC 9075, define un conjunto de funciones para el acceso a bases de datos a nivel de llamadas. ODBC se basa en esta especificación, lo que garantiza su alineación con un estándar internacional. La CLI proporciona un modelo de interacción uniforme, permitiendo que aplicaciones escritas en distintos lenguajes (C, C++, Python, etc.) accedan a SGBD heterogéneos sin necesidad de adaptar el código fuente a cada sistema.

Metadatos estandarizados. El estándar INFORMATION_SCHEMA, definido en la norma SQL, ofrece un esquema de metadatos que describe la estructura de las bases de datos de forma homogénea. Este esquema incluye vistas como TABLES, COLUMNS o SCHEMATA, que permiten a las aplicaciones consultar información sobre tablas, columnas, restricciones y otros objetos sin depender de extensiones propietarias. La disponibilidad de metadatos estandarizados simplifica el desarrollo de herramientas de administración, consulta y reporting que deben operar sobre distintos SGBD.

Capas complementarias de interoperabilidad. La interoperabilidad no se limita al lenguaje SQL o a las interfaces de acceso, sino que requiere la combinación de múltiples capas. Mientras SQL proporciona la sintaxis común para las operaciones, ODBC y JDBC facilitan la conexión desde aplicaciones, y los metadatos estandarizados permiten descubrir la estructura de los datos. Esta arquitectura en capas asegura que cada componente cumpla una función específica, evitando solapamientos y garantizando la coherencia en entornos con múltiples SGBD.

Ventajas de la estandarización. La adopción de normas y estándares como ISO/IEC 9075, ODBC o JDBC ofrece ventajas clave: independencia del gestor, reutilización de herramientas, integración de entornos heterogéneos y reducción de costes de desarrollo. Las aplicaciones pueden cambiar de SGBD con modificaciones mínimas en el código, siempre que se eviten dependencias de funciones propietarias. Además, los estándares facilitan la creación de soluciones multiplataforma, como las aplicaciones sanitarias basadas en Java que operan en el Servicio Andaluz de Salud.

Limitaciones y consideraciones. Aunque los estándares proporcionan un marco robusto para la interoperabilidad, su alcance no es absoluto. Las diferencias en la implementación de SQL entre gestores, el uso de extensiones propietarias o la dependencia de comportamientos específicos del motor pueden requerir adaptaciones. Por ello, el diseño de aplicaciones debe priorizar el uso de funcionalidades estandarizadas y evitar características no portables para maximizar la compatibilidad entre sistemas.

🧩 Elementos esenciales

• ISO/IEC 9075: Norma internacional que define el lenguaje SQL, incluyendo sintaxis, semántica y operaciones básicas para bases de datos relacionales.
• CLI (Call Level Interface): Especificación integrada en ISO/IEC 9075 que establece funciones para el acceso a bases de datos a nivel de llamadas, base de ODBC.
• ODBC (Open Database Connectivity): API estándar para acceso a SGBD desde aplicaciones, que utiliza un gestor de controladores para traducir llamadas genéricas a instrucciones nativas.
• JDBC (Java Database Connectivity): API estándar para acceso a bases de datos desde aplicaciones Java, con drivers específicos para cada SGBD.
• INFORMATION_SCHEMA: Esquema de metadatos estandarizado que describe la estructura de las bases de datos mediante vistas como TABLES o COLUMNS.
• Drivers ODBC/JDBC: Módulos específicos de cada SGBD que traducen las llamadas de la API estándar a instrucciones comprensibles por el gestor.
• DSN (Data Source Name): Configuración nombrada que agrupa parámetros de conexión (servidor, base de datos, usuario) para simplificar el acceso mediante ODBC.
• Tipos de drivers JDBC: Clasificación en cuatro tipos (JDBC-ODBC Bridge, Native API, Network Protocol, Pure Java), siendo el Tipo 4 el más utilizado por su portabilidad.
• Independencia del gestor: Capacidad de una aplicación para operar con distintos SGBD sin modificar su código, gracias al uso de interfaces estandarizadas.
• Metadatos estandarizados: Información estructurada sobre la base de datos (tablas, columnas, restricciones) accesible de forma homogénea en distintos SGBD.
• Interoperabilidad en capas: Combinación de SQL, interfaces de acceso (ODBC/JDBC) y metadatos para garantizar la compatibilidad entre sistemas heterogéneos.
• Limitaciones de los estándares: Dependencia de implementaciones específicas, extensiones propietarias o comportamientos no estandarizados que pueden requerir adaptaciones.

🧠 Recuerda

• La norma ISO/IEC 9075 es la base del lenguaje SQL y garantiza la compatibilidad sintáctica entre SGBD.
• ODBC y JDBC permiten acceder a múltiples gestores desde una misma aplicación sin modificar el código.
• La especificación CLI, integrada en ISO/IEC 9075, es el fundamento técnico de ODBC.
• INFORMATION_SCHEMA proporciona metadatos estandarizados para consultar la estructura de las bases de datos.
• Los drivers ODBC/JDBC traducen las llamadas genéricas a instrucciones específicas del SGBD.
• El DSN en ODBC simplifica la configuración de conexiones agrupando parámetros técnicos.
• JDBC Tipo 4 es el driver más utilizado por su implementación en Java puro y su portabilidad.
• La interoperabilidad requiere evitar dependencias de funciones propietarias o comportamientos no estandarizados.
• Los estándares facilitan la migración entre SGBD y la integración de entornos heterogéneos.
• La combinación de SQL, interfaces de acceso y metadatos estandarizados es clave para la interoperabilidad real.

10. Principales SGBD comerciales

🎯 Idea clave

• Los Sistemas Gestores de Bases de Datos Relacionales (SGBDR) comerciales son productos propietarios con soporte técnico, garantías contractuales y funcionalidades avanzadas para entornos empresariales críticos.
• Oracle Database, Microsoft SQL Server e IBM Db2 son los principales SGBDR comerciales, cada uno con características técnicas y ecosistemas diferenciados.
• Estos sistemas destacan por su alta disponibilidad, seguridad robusta y capacidades de escalado, esenciales en organizaciones como el Servicio Andaluz de Salud (SAS).
• La elección de un SGBD comercial depende de requisitos funcionales, arquitectura existente, presupuesto y necesidades de integración, no de rankings absolutos.
• Aunque comparten rasgos comunes como el uso de SQL, cada producto incorpora extensiones propietarias (PL/SQL, T-SQL, SQL PL) que condicionan su portabilidad.
• Su uso en entornos profesionales conlleva mayor coste y complejidad, pero también garantías de soporte y continuidad evolutiva.

📚 Desarrollo

Definición y alcance. Un Sistema Gestor de Bases de Datos comercial es un producto distribuido bajo licencia empresarial, respaldado por un proveedor que ofrece soporte técnico, contratos de mantenimiento, herramientas de administración certificadas y responsabilidades contractuales. Aunque algunos tienen ediciones gratuitas o núcleos de código abierto, lo definitorio es la existencia de un ecosistema profesional con garantías de servicio y ciclo de vida definido.

Orientación empresarial. Estos sistemas están diseñados para sostener procesos críticos en organizaciones complejas, como administraciones públicas o entidades financieras. Implementan el modelo relacional y el lenguaje SQL, pero incorporan extensiones propias para gestionar JSON, XML, grafos o analítica avanzada. Su robustez en control transaccional, seguridad y continuidad los diferencia de soluciones más ligeras.

Principales productos. Los SGBDR comerciales más relevantes en el ámbito profesional son Oracle Database, Microsoft SQL Server e IBM Db2. Oracle destaca por su orientación convergente y multimodelo, siendo el principal SGBD utilizado en el SAS, especialmente en sistemas como DIRAYA. SQL Server, por su parte, está integrado en el ecosistema Microsoft y es frecuente en entornos híbridos o en la nube Azure. Db2, aunque menos extendido en el SAS, sigue siendo referencia en mainframes y workloads mixtos transaccionales y analíticos.

Alta disponibilidad y plataformas. Cada producto ofrece mecanismos avanzados de alta disponibilidad: Oracle con RAC (Real Application Clusters) y Data Guard, SQL Server con Always On Availability Groups, e IBM Db2 con pureScale y HADR. En cuanto a plataformas, Oracle y Db2 soportan múltiples sistemas operativos (Linux, Windows, Unix), mientras que SQL Server está más ligado a entornos Windows, aunque también opera en Linux.

Integración y uso en el SAS. En el Servicio Andaluz de Salud, Oracle Database es el SGBD comercial predominante, utilizado en sistemas críticos que gestionan datos de millones de ciudadanos. SQL Server tiene un uso más puntual, limitado a sistemas departamentales, mientras que Db2 y otros productos como SAP HANA tienen una presencia marginal o específica en áreas como la gestión ERP.

Ventajas e inconvenientes. Entre las ventajas de estos sistemas destacan el soporte empresarial, herramientas maduras de administración y capacidades avanzadas de seguridad. Sin embargo, su uso implica mayor coste económico, dependencia del proveedor y complejidad operativa, especialmente en despliegues grandes. Además, el aprovechamiento de extensiones propietarias puede reducir la portabilidad entre sistemas.

Enfoque para oposiciones. Para el estudio de oposiciones, es clave reconocer el posicionamiento técnico de cada SGBD comercial, sus características diferenciales y su relevancia en entornos profesionales. No se trata de memorizar catálogos de ediciones o mensajes comerciales, sino de entender su papel en la gestión de datos críticos y su adaptación a necesidades organizativas.

🧩 Elementos esenciales

• SGBD comercial: Producto con licencia empresarial, soporte profesional y ciclo de vida definido, orientado a entornos críticos.
• Oracle Database: SGBDR de Oracle Corp., líder en cargas corporativas críticas, con lenguaje PL/SQL y alta disponibilidad mediante RAC y Data Guard.
• Microsoft SQL Server: SGBDR de Microsoft, integrado en su ecosistema, con lenguaje T-SQL y alta disponibilidad mediante Always On Availability Groups.
• IBM Db2: SGBDR de IBM, especializado en mainframes y workloads mixtos, con lenguaje SQL PL y alta disponibilidad mediante pureScale.
• SAP HANA: Plataforma relacional comercial con enfoque in-memory, capaz de integrar OLTP y OLAP mediante SQLScript.
• Alta disponibilidad: Mecanismos como RAC (Oracle), Always On (SQL Server) o pureScale (Db2) para garantizar continuidad en entornos críticos.
• Lenguajes propietarios: Extensiones como PL/SQL (Oracle), T-SQL (SQL Server) o SQL PL (Db2) que amplían SQL estándar.
• Uso en el SAS: Oracle Database es el principal SGBD comercial, mientras que SQL Server y Db2 tienen presencia puntual o marginal.
• Ventajas: Soporte empresarial, herramientas maduras, seguridad avanzada y orientación a entornos críticos.
• Inconvenientes: Mayor coste, dependencia del proveedor, complejidad operativa y menor portabilidad.
• Integración cloud: Todos los principales SGBD comerciales ofrecen opciones de despliegue en nube pública, híbrida o multicloud.
• Enfoque opositor: Priorizar el reconocimiento de características técnicas y posicionamiento, no detalles comerciales o ediciones específicas.

🧠 Recuerda

• Los SGBD comerciales son productos empresariales con soporte, garantías y ciclo de vida definido.
• Oracle Database, Microsoft SQL Server e IBM Db2 son los principales SGBDR comerciales.
• Oracle es el más utilizado en el SAS, especialmente en sistemas críticos como DIRAYA.
• Cada SGBD tiene extensiones propietarias (PL/SQL, T-SQL, SQL PL) que condicionan su uso.
• La alta disponibilidad es una característica clave, con soluciones como RAC, Always On o pureScale.
• Estos sistemas son robustos pero complejos, con mayor coste y dependencia del proveedor.
• En oposiciones, importa el posicionamiento técnico, no memorizar catálogos de productos.
• SAP HANA destaca por su enfoque in-memory y capacidad de integrar OLTP y OLAP.
• La elección de un SGBD comercial depende de requisitos funcionales, arquitectura y presupuesto.
• Su uso en entornos profesionales conlleva ventajas en soporte y seguridad, pero también inconvenientes en coste y portabilidad.

11. SGBD de código abierto

🎯 Idea clave

• Los SGBD de código abierto son sistemas gestores de bases de datos relacionales cuyo código fuente es accesible y modificable, promoviendo la transparencia y la independencia tecnológica.
• PostgreSQL destaca como motor objeto-relacional de alta extensibilidad, ideal para entornos corporativos y administraciones públicas como el SAS.
• MariaDB y MySQL son opciones relevantes para aplicaciones web, con diferencias en licencias y modelos de replicación.
• SQLite ofrece un enfoque embebido, sin servidor, adecuado para aplicaciones locales o móviles.
• La elección del SGBD debe ajustarse al patrón de uso, priorizando interoperabilidad, escalabilidad y cumplimiento de estándares abiertos.
• En el ámbito sanitario, estos sistemas facilitan la integración de datos clínicos y administrativos bajo marcos normativos como el Esquema Nacional de Interoperabilidad.

📚 Desarrollo

Definición y alcance. Los Sistemas Gestores de Bases de Datos (SGBD) de código abierto son herramientas que permiten almacenar, gestionar y recuperar datos de forma estructurada, con la particularidad de que su código fuente es público y modificable. En el contexto del Servicio Andaluz de Salud (SAS), estos sistemas son clave para garantizar la independencia tecnológica y el cumplimiento de normativas como el Esquema Nacional de Interoperabilidad, que exige el uso de estándares abiertos en las administraciones públicas.

PostgreSQL: potencia y extensibilidad. PostgreSQL es un SGBD objeto-relacional que combina alta conformidad con el estándar SQL, soporte completo para transacciones ACID y un modelo de control de concurrencia multiversión (MVCC). Su arquitectura cliente-servidor, junto con capacidades avanzadas como replicación lógica y extensiones como PostGIS, lo hacen idóneo para entornos corporativos y proyectos que requieren alta disponibilidad y manejo de datos complejos. En el SAS, su uso está alineado con la necesidad de sistemas robustos y escalables para gestionar información sanitaria crítica.

MariaDB y MySQL: compatibilidad y ecosistema web. MariaDB, derivado de MySQL y con licencia GPLv2, mantiene compatibilidad con este último pero incorpora mejoras como el motor de almacenamiento Aria y replicación síncrona multi-maestro mediante Galera Cluster. MySQL, por su parte, ofrece un modelo de licencia dual (GPL y comercial) y un ecosistema ampliamente adoptado en aplicaciones web. Ambos son relevantes en el SAS para sistemas que requieren escalabilidad horizontal y compatibilidad con entornos LAMP, aunque su elección debe considerar las diferencias en licencias y capacidades de replicación.

SQLite: simplicidad y embebido. SQLite se diferencia radicalmente de los anteriores al ser un motor SQL embebido, sin proceso servidor separado y con almacenamiento en un único fichero. Su diseño autocontenido, dominio público y soporte transaccional lo hacen ideal para aplicaciones locales, móviles o entornos de pruebas. En el SAS, puede emplearse en soluciones que no requieren alta concurrencia o administración centralizada, como herramientas de diagnóstico o sistemas de caché.

Licencias y modelos de desarrollo. Las licencias de estos SGBD varían significativamente: PostgreSQL utiliza una licencia permisiva estilo MIT, MariaDB y MySQL emplean GPLv2 (con opción comercial para MySQL), mientras que SQLite es de dominio público. Esta diversidad influye en su adopción, especialmente en entornos públicos donde se priorizan licencias que eviten dependencias de proveedores. El modelo de desarrollo comunitario de estos proyectos garantiza actualizaciones continuas y adaptación a estándares abiertos, un requisito crítico en el ámbito sanitario.

Interoperabilidad y estándares. La interoperabilidad entre SGBD de código abierto se sustenta en el uso de interfaces estándar como JDBC y ODBC, así como en el cumplimiento del núcleo del estándar SQL. En el SAS, esto permite integrar sistemas heterogéneos, migrar datos entre plataformas y garantizar la portabilidad de las aplicaciones. Además, la adopción de formatos de intercambio como CSV, JSON o Parquet facilita la transferencia de datos entre sistemas clínicos, administrativos y de laboratorio, alineándose con los objetivos de la Estrategia de Salud Digital de Andalucía.

Criterios de selección en el SAS. La elección de un SGBD de código abierto en el SAS debe considerar factores como el patrón de uso (transaccional, analítico o embebido), los requisitos de alta disponibilidad, la escalabilidad y la compatibilidad con estándares sanitarios como HL7 o SNOMED CT. PostgreSQL es preferible para sistemas corporativos con alta carga transaccional, mientras que MariaDB o MySQL son adecuados para aplicaciones web. SQLite, por su parte, se reserva para escenarios con necesidades de almacenamiento local o pruebas.

🧩 Elementos esenciales

• PostgreSQL: SGBD objeto-relacional de servidor con alta conformidad SQL, extensibilidad y soporte para transacciones ACID y MVCC.
• MariaDB: Derivado de MySQL con licencia GPLv2, compatible con entornos web y replicación síncrona multi-maestro mediante Galera Cluster.
• MySQL: SGBD relacional con licencia dual (GPL/comercial), ampliamente adoptado en aplicaciones web y con ecosistema LAMP.
• SQLite: Motor SQL embebido, sin servidor, almacenamiento en fichero único y dominio público, ideal para aplicaciones locales o móviles.
• Licencias: PostgreSQL (permisiva), MariaDB y MySQL (GPLv2), SQLite (dominio público), con implicaciones en la dependencia de proveedores.
• Replicación: PostgreSQL (streaming + lógica), MariaDB (Galera Cluster), MySQL (Group Replication), SQLite (no aplica).
• Alta disponibilidad: PostgreSQL (Patroni), MariaDB (Galera Cluster), MySQL (InnoDB Cluster), SQLite (no aplicable).
• Extensibilidad: PostgreSQL (alta, con PostGIS, FDW), MariaDB (media-alta, con ColumnStore), MySQL (media), SQLite (baja).
• Casos de uso: PostgreSQL (corporativo), MariaDB/MySQL (web), SQLite (embebido, pruebas).
• Interoperabilidad: Basada en estándares SQL, JDBC/ODBC y formatos de intercambio como CSV, JSON o Parquet.
• Estándares sanitarios: Integración con HL7, SNOMED CT, CIE-10 y LOINC para interoperabilidad semántica en el SAS.
• Normativa aplicable: Esquema Nacional de Interoperabilidad y Estrategia de Salud Digital de Andalucía 2024-2028.

🧠 Recuerda

• Los SGBD de código abierto promueven la independencia tecnológica y el cumplimiento de estándares abiertos en administraciones públicas.
• PostgreSQL es la opción más robusta para entornos corporativos y datos complejos en el SAS.
• MariaDB y MySQL son adecuados para aplicaciones web, con diferencias en licencias y capacidades de replicación.
• SQLite es ideal para almacenamiento local o embebido, sin necesidad de servidor.
• La elección del SGBD debe alinearse con el patrón de uso y los requisitos de interoperabilidad.
• Las licencias varían: permisivas (PostgreSQL), GPL (MariaDB/MySQL) o dominio público (SQLite).
• La interoperabilidad en el SAS se basa en estándares SQL, JDBC/ODBC y formatos de intercambio abiertos.
• La Estrategia de Salud Digital de Andalucía prioriza el uso de estándares abiertos para garantizar la integración de sistemas sanitarios.