1. Introducción y Contextualización

Bienvenido a uno de los temas más fundamentales y técnicamente exigentes del temario. Las bases de datos relacionales son la columna vertebral de todos los sistemas de información del SAS. Desde que un médico accede a la Historia Clínica Digital en Diraya, hasta que se genera una receta electrónica en Receta XXI, pasando por el análisis de datos en el Business Intelligence Corporativo… todo funciona sobre potentes sistemas gestores de bases de datos relacionales.

Este tema no es teórico ni abstracto: es pura aplicación práctica. Cada concepto que veremos aquí tiene su reflejo directo en los sistemas que gestionarás como Técnico Especialista del SAS. Y las preguntas de examen lo reflejan: normalización, arquitectura ANSI/SPARC, sentencias SQL, propiedades ACID, diferencias entre SGBD relacionales y NoSQL… son contenidos recurrentes en las convocatorias.

1.1. Objetivos de Aprendizaje

Al finalizar este tema, serás capaz de:

• Explicar el modelo relacional y sus fundamentos teóricos (Codd, 1970)
• Describir la arquitectura ANSI/SPARC de tres niveles aplicada a SGBD reales
• Diseñar bases de datos relacionales usando el modelo entidad-relación
• Aplicar las formas normales (1FN-5FN) para eliminar redundancias
• Dominar SQL: DDL, DML, DCL, TCL y consultas complejas
• Diferenciar SGBD relacionales de NoSQL (MongoDB, HBase)
• Conocer los principales SGBD comerciales (Oracle, SQL Server) y opensource (PostgreSQL, MariaDB)
• Comprender las propiedades ACID y su importancia en entornos sanitarios
• Trabajar con estándares de interoperabilidad (ODBC, JDBC, SQL:2016)

1.2. Esquema General del Tema

El tema sigue una progresión lógica desde los fundamentos teóricos hasta la aplicación práctica:

1. Teoría del modelo relacional: Definiciones, conceptos, álgebra relacional
2. Arquitectura: Niveles de abstracción, diccionario de datos, independencia
3. Diseño: Modelo E-R, transformación a tablas, claves
4. Normalización: Dependencias funcionales, formas normales 1FN-5FN
5. Manipulación: Álgebra y cálculo relacional, SQL práctico
6. Implementación: SGBD comerciales, opensource, comparativas
7. Aplicación SAS: Casos reales en sistemas corporativos

2. El Modelo Relacional: Fundamentos Teóricos

2.1. Orígenes e Historia

El modelo relacional fue propuesto por Edgar Frank Codd en 1970 en su artículo seminal «A Relational Model of Data for Large Shared Data Banks» publicado en Communications of the ACM. Codd, investigador de IBM, revolucionó la gestión de datos al proponer un modelo basado en la teoría matemática de relaciones (conjuntos) que permitía mayor independencia de datos y flexibilidad que los modelos anteriores (jerárquico y en red).

2.2. Conceptos Fundamentales

2.2.1. Relación (Tabla)

Una relación es un conjunto de tuplas (filas) que comparten los mismos atributos (columnas). Matemáticamente, es un subconjunto del producto cartesiano de los dominios de sus atributos. En términos prácticos: una tabla con filas y columnas donde cada celda contiene un valor atómico.

Propiedades de una relación:

• No hay filas duplicadas (cada tupla es única)
• El orden de las filas es irrelevante
• El orden de las columnas es irrelevante
• Cada atributo toma valores de un dominio específico
• Todos los valores son atómicos (no divisibles)

PACIENTES
---------------------------------------------------------------------------
| CIP        | DNI       | NOMBRE         | APELLIDOS      | FECHA_NAC  |
---------------------------------------------------------------------------
| 0001234567 | 12345678A | Juan           | García López   | 1985-03-15 |
| 0001234568 | 87654321B | María          | Pérez Ruiz     | 1992-07-22 |
| 0001234569 | 11223344C | Antonio        | Martín Sánchez | 1978-11-30 |
---------------------------------------------------------------------------

Características:
- CIP es la clave primaria (identifica unívocamente cada paciente)
- No hay dos filas idénticas
- Cada valor es atómico (no hay listas en una celda)
- El orden de las filas no tiene significado

2.2.2. Atributo y Dominio

Un atributo es una propiedad o característica de una entidad. Cada atributo tiene asociado un dominio, que es el conjunto de valores válidos que puede tomar. Por ejemplo:

• Atributo: EDAD → Dominio: Enteros entre 0 y 120
• Atributo: SEXO → Dominio: {‘H’, ‘M’, ‘O’}
• Atributo: FECHA_NACIMIENTO → Dominio: Fechas válidas en formato ISO 8601

2.2.3. Tupla (Fila o Registro)

Una tupla es una instancia específica de una relación: un conjunto ordenado de valores, uno por cada atributo. Representa un hecho del mundo real. En Diraya, cada fila de la tabla PACIENTES es una tupla que representa a un paciente concreto del SAS.

2.2.4. Claves

Las claves son fundamentales para identificar tuplas y establecer relaciones entre tablas:

2.3. Integridad Referencial

La integridad referencial garantiza que las relaciones entre tablas sean coherentes. Se implementa mediante claves foráneas que deben cumplir:

• Una clave foránea debe referenciar una clave primaria existente o ser NULL (si se permite)
• No se puede eliminar una tupla referenciada (o se propaga la eliminación en cascada)
• No se puede insertar una tupla con FK que no exista en la tabla referenciada

-- Tabla padre: PACIENTES
PACIENTES (CIP, DNI, NOMBRE, APELLIDOS)
PK: CIP

-- Tabla hija: RECETAS
RECETAS (ID_RECETA, CIP_PACIENTE, FECHA_PRESCRIPCION, MEDICAMENTO)
PK: ID_RECETA
FK: CIP_PACIENTE → PACIENTES.CIP

-- Integridad Referencial:
1. No se puede crear una receta con CIP_PACIENTE='9999999999' si ese CIP no existe
2. No se puede eliminar un paciente si tiene recetas asociadas (o se eliminan en cascada)
3. Si CIP_PACIENTE admite NULL, significa "receta sin paciente asignado" (raro en sanidad)

2.4. Restricciones de Integridad

El modelo relacional define varios tipos de restricciones para mantener la consistencia:

3. Arquitectura de SGBD: Modelo ANSI/SPARC

La arquitectura de tres niveles ANSI/SPARC (American National Standards Institute / Standards Planning And Requirements Committee) fue propuesta en 1975 para estandarizar la arquitectura de los sistemas de bases de datos. Define tres niveles de abstracción que proporcionan independencia de datos.

3.1. Los Tres Niveles de Abstracción

3.1.1. Nivel Externo (Vistas de Usuario)

Es el nivel más alto de abstracción. Define cómo ven los datos los diferentes grupos de usuarios. Cada vista es una "ventana" personalizada sobre la base de datos que muestra solo los datos relevantes para un usuario o aplicación específica.

Características:

• Múltiples vistas para diferentes usuarios
• Personalización según perfiles (médicos, enfermeros, administrativos)
• Seguridad: oculta datos sensibles a usuarios no autorizados
• Simplicidad: muestra solo los datos necesarios

-- Vista para MÉDICOS (nivel externo)
CREATE VIEW VISTA_MEDICO_PACIENTES AS
SELECT CIP, NOMBRE, APELLIDOS, FECHA_NACIMIENTO, 
       ALERGIAS, ANTECEDENTES, TRATAMIENTO_ACTUAL
FROM PACIENTES
WHERE MEDICO_ASIGNADO = CURRENT_USER;

-- Vista para FARMACIA (nivel externo)
CREATE VIEW VISTA_FARMACIA_RECETAS AS
SELECT R.ID_RECETA, P.CIP, P.NOMBRE, R.MEDICAMENTO, 
       R.POSOLOGIA, R.FECHA_PRESCRIPCION
FROM RECETAS R
JOIN PACIENTES P ON R.CIP_PACIENTE = P.CIP
WHERE R.ESTADO = 'ACTIVA';

-- Vista para DIRECCIÓN (nivel externo - datos agregados)
CREATE VIEW VISTA_ESTADISTICAS_DIRECCION AS
SELECT CENTRO, COUNT(*) AS TOTAL_PACIENTES, 
       AVG(EDAD) AS EDAD_MEDIA, 
       COUNT(CASE WHEN CRONICO='S' THEN 1 END) AS PACIENTES_CRONICOS
FROM PACIENTES
GROUP BY CENTRO;

3.1.2. Nivel Conceptual (Esquema Lógico)

Es el nivel intermedio que describe la estructura completa de la base de datos de forma independiente de cómo se almacena físicamente. Define:

• Todas las entidades (tablas) y sus atributos
• Relaciones entre entidades (claves foráneas)
• Restricciones de integridad (PK, FK, CHECK, UNIQUE)
• Vistas, índices, triggers, procedimientos almacenados
• Diccionario de datos (metadatos sobre la estructura)

Ejemplo de Diccionario de Datos en Oracle:

-- Consultar metadatos de tabla (Diccionario de Datos)
SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, DATA_LENGTH, NULLABLE
FROM USER_TAB_COLUMNS
WHERE TABLE_NAME = 'PACIENTES';

-- Consultar restricciones
SELECT CONSTRAINT_NAME, CONSTRAINT_TYPE, SEARCH_CONDITION
FROM USER_CONSTRAINTS
WHERE TABLE_NAME = 'PACIENTES';

Resultado:
CONSTRAINT_NAME       CONSTRAINT_TYPE  SEARCH_CONDITION
PK_PACIENTES          P (Primary Key)  -
FK_CENTRO             R (Foreign Key)  -
CHK_FECHA_NACIMIENTO  C (Check)        FECHA_NACIMIENTO < SYSDATE

3.1.3. Nivel Interno (Esquema Físico)

Es el nivel más bajo, describe cómo se almacenan físicamente los datos en los dispositivos de almacenamiento. Define:

• Estructuras de almacenamiento: ficheros, tablespaces (Oracle), filegroups (SQL Server)
• Organización de registros: secuencial, indexada, hash
• Índices: B-Tree, Bitmap, Hash, Full-Text
• Métodos de acceso: scan secuencial, acceso por índice
• Compresión, particionado de tablas
• Clustering, replicación física

-- Creación de Tablespace (almacenamiento físico)
CREATE TABLESPACE DIRAYA_DATA
DATAFILE '/oradata/diraya/diraya_data01.dbf' SIZE 10G AUTOEXTEND ON
MAXSIZE 100G;

-- Creación de tabla en ese tablespace
CREATE TABLE PACIENTES (
    CIP VARCHAR2(10) PRIMARY KEY,
    DNI VARCHAR2(9),
    NOMBRE VARCHAR2(50),
    APELLIDOS VARCHAR2(100)
)
TABLESPACE DIRAYA_DATA
STORAGE (INITIAL 1M NEXT 1M PCTINCREASE 0);

-- Índice B-Tree sobre DNI (acceso rápido por DNI)
CREATE INDEX IDX_PACIENTES_DNI ON PACIENTES(DNI)
TABLESPACE DIRAYA_INDEX;

-- Particionado por rango (mejora rendimiento)
CREATE TABLE CITAS (
    ID_CITA NUMBER PRIMARY KEY,
    CIP_PACIENTE VARCHAR2(10),
    FECHA_CITA DATE,
    CENTRO VARCHAR2(50)
)
PARTITION BY RANGE (FECHA_CITA) (
    PARTITION CITAS_2023 VALUES LESS THAN (TO_DATE('2024-01-01','YYYY-MM-DD')),
    PARTITION CITAS_2024 VALUES LESS THAN (TO_DATE('2025-01-01','YYYY-MM-DD')),
    PARTITION CITAS_2025 VALUES LESS THAN (MAXVALUE)
);

3.2. Independencia de Datos

La arquitectura de tres niveles proporciona dos tipos de independencia de datos, fundamentales para la evolución de los sistemas:

3.2.1. Independencia Lógica

Capacidad de modificar el esquema conceptual sin cambiar los esquemas externos (vistas) ni las aplicaciones. Por ejemplo:

• Añadir una nueva tabla al esquema conceptual
• Añadir un atributo a una tabla existente
• Crear una nueva restricción de integridad

-- Cambio en el nivel conceptual:
ALTER TABLE PACIENTES ADD (ALERGIAS_FARMACOLOGICAS VARCHAR2(500));

-- Las vistas existentes siguen funcionando sin modificación:
CREATE VIEW VISTA_MEDICO_BASICA AS
SELECT CIP, NOMBRE, APELLIDOS, FECHA_NACIMIENTO
FROM PACIENTES
WHERE MEDICO_ASIGNADO = CURRENT_USER;

-- Nueva vista para médicos que necesitan ver alergias:
CREATE VIEW VISTA_MEDICO_ALERGIAS AS
SELECT CIP, NOMBRE, APELLIDOS, ALERGIAS_FARMACOLOGICAS
FROM PACIENTES
WHERE MEDICO_ASIGNADO = CURRENT_USER;

3.2.2. Independencia Física

Capacidad de modificar el esquema interno (físico) sin cambiar el esquema conceptual ni las aplicaciones. Por ejemplo:

• Cambiar la organización de ficheros (añadir un nuevo datafile)
• Crear o eliminar índices para mejorar rendimiento
• Cambiar la ubicación física de los datos (migrar a otro disco)
• Modificar métodos de acceso (cambiar de B-Tree a Hash)

-- 1. Crear nuevo datafile en SSD
ALTER TABLESPACE DIRAYA_DATA 
ADD DATAFILE '/ssd/diraya/diraya_data02.dbf' SIZE 20G;

-- 2. Mover datos del datafile antiguo al nuevo (online)
ALTER DATABASE DATAFILE '/oradata/diraya/diraya_data01.dbf' OFFLINE;
-- ...proceso de migración física...

-- 3. Las consultas SQL siguen funcionando igual:
SELECT * FROM PACIENTES WHERE CIP = '0001234567';
-- El optimizador usa automáticamente el nuevo almacenamiento

3.3. Arquitectura de SGBD Modernos

Los SGBD actuales implementan la arquitectura ANSI/SPARC con componentes adicionales:

4. Diseño de Bases de Datos: Modelo Entidad-Relación

El modelo entidad-relación (E-R) propuesto por Peter Chen en 1976 es una herramienta gráfica para diseñar bases de datos relacionales. Permite modelar el mundo real mediante entidades, atributos y relaciones, facilitando la comunicación entre analistas, diseñadores y usuarios.

4.1. Conceptos del Modelo E-R

4.1.1. Entidades

Una entidad es un objeto distinguible del mundo real sobre el que se desea almacenar información. Ejemplos en el SAS:

• PACIENTE: Persona que recibe asistencia sanitaria
• MÉDICO: Profesional sanitario
• CITA: Encuentro programado entre paciente y médico
• CENTRO_SALUD: Instalación sanitaria

Una entidad se representa gráficamente como un rectángulo con el nombre de la entidad en su interior.

4.1.2. Atributos

Los atributos son propiedades que describen una entidad. Se clasifican en:

• Simples: No divisibles (NOMBRE, EDAD)
• Compuestos: Divisibles en partes (DIRECCION → CALLE, NUMERO, CP, CIUDAD)
• Monovaluados: Un solo valor (FECHA_NACIMIENTO)
• Multivaluados: Conjunto de valores (TELEFONOS: {666111222, 955123456})
• Derivados: Se calculan a partir de otros (EDAD se deriva de FECHA_NACIMIENTO)

Los atributos se representan como óvalos conectados a la entidad. El atributo clave (identificador único) se subraya.

4.1.3. Relaciones

Una relación es una asociación entre dos o más entidades. Se representa como un rombo conectado a las entidades relacionadas.

Cardinalidad de Relaciones:

4.2. Transformación del Modelo E-R a Tablas Relacionales

Una vez diseñado el modelo E-R, se transforma al modelo relacional mediante reglas estándar:

4.2.1. Regla 1: Entidades → Tablas

Cada entidad se convierte en una tabla. Los atributos de la entidad se convierten en columnas. El identificador único (clave) se convierte en clave primaria.

-- Entidad PACIENTE
PACIENTE (CIP, DNI, NOMBRE, APELLIDOS, FECHA_NACIMIENTO, SEXO, DIRECCION)
PK: CIP

CREATE TABLE PACIENTES (
    CIP VARCHAR(10) PRIMARY KEY,
    DNI VARCHAR(9) UNIQUE,
    NOMBRE VARCHAR(50) NOT NULL,
    APELLIDOS VARCHAR(100) NOT NULL,
    FECHA_NACIMIENTO DATE NOT NULL,
    SEXO CHAR(1) CHECK (SEXO IN ('H','M','O')),
    DIRECCION VARCHAR(200)
);

4.2.2. Regla 2: Relaciones 1:1 → Clave Foránea

Se añade la clave primaria de una entidad como clave foránea en la otra (o viceversa). Se elige la entidad con participación total.

-- Relación 1:1: PACIENTE - HISTORIA_CLINICA
PACIENTES (CIP, DNI, NOMBRE, ...)
HISTORIAS_CLINICAS (ID_HC, CIP_PACIENTE, FECHA_APERTURA, ...)

-- CIP_PACIENTE es FK que referencia PACIENTES.CIP
-- Cada HC pertenece a un único paciente
-- Cada paciente tiene una única HC

CREATE TABLE HISTORIAS_CLINICAS (
    ID_HC INTEGER PRIMARY KEY,
    CIP_PACIENTE VARCHAR(10) UNIQUE NOT NULL,
    FECHA_APERTURA DATE,
    FOREIGN KEY (CIP_PACIENTE) REFERENCES PACIENTES(CIP)
);

4.2.3. Regla 3: Relaciones 1:N → Clave Foránea en el Lado N

Se añade la clave primaria del lado "1" como clave foránea en el lado "N".

-- Relación 1:N: MÉDICO atiende PACIENTES
MEDICOS (ID_MEDICO, DNI, NOMBRE, ESPECIALIDAD, ...)
PACIENTES (CIP, DNI, NOMBRE, ID_MEDICO_ASIGNADO, ...)

-- ID_MEDICO_ASIGNADO es FK en PACIENTES que referencia MEDICOS

CREATE TABLE MEDICOS (
    ID_MEDICO INTEGER PRIMARY KEY,
    DNI VARCHAR(9) UNIQUE,
    NOMBRE VARCHAR(100) NOT NULL,
    ESPECIALIDAD VARCHAR(50)
);

CREATE TABLE PACIENTES (
    CIP VARCHAR(10) PRIMARY KEY,
    DNI VARCHAR(9) UNIQUE,
    NOMBRE VARCHAR(50) NOT NULL,
    ID_MEDICO_ASIGNADO INTEGER,
    FOREIGN KEY (ID_MEDICO_ASIGNADO) REFERENCES MEDICOS(ID_MEDICO)
);

4.2.4. Regla 4: Relaciones N:M → Tabla Intermedia

Se crea una nueva tabla con las claves primarias de ambas entidades como claves foráneas. La clave primaria de la tabla intermedia suele ser la combinación de ambas FK.

-- Relación N:M: PACIENTES - TRATAMIENTOS
PACIENTES (CIP, DNI, NOMBRE, ...)
TRATAMIENTOS (ID_TRATAMIENTO, NOMBRE_TRATAMIENTO, DESCRIPCION, ...)

-- Tabla intermedia: PACIENTES_TRATAMIENTOS
PACIENTES_TRATAMIENTOS (CIP, ID_TRATAMIENTO, FECHA_INICIO, FECHA_FIN, DOSIS)

CREATE TABLE TRATAMIENTOS (
    ID_TRATAMIENTO INTEGER PRIMARY KEY,
    NOMBRE_TRATAMIENTO VARCHAR(100) NOT NULL,
    DESCRIPCION VARCHAR(500)
);

CREATE TABLE PACIENTES_TRATAMIENTOS (
    CIP VARCHAR(10),
    ID_TRATAMIENTO INTEGER,
    FECHA_INICIO DATE NOT NULL,
    FECHA_FIN DATE,
    DOSIS VARCHAR(100),
    PRIMARY KEY (CIP, ID_TRATAMIENTO),
    FOREIGN KEY (CIP) REFERENCES PACIENTES(CIP),
    FOREIGN KEY (ID_TRATAMIENTO) REFERENCES TRATAMIENTOS(ID_TRATAMIENTO)
);

4.3. Entidades Débiles

Una entidad débil es aquella que no puede existir sin una entidad fuerte relacionada. Su clave primaria está formada por:

• La clave primaria de la entidad fuerte (FK)
• Un discriminador parcial (atributo propio)

-- HISTORIA_CLINICA (entidad fuerte)
HISTORIAS_CLINICAS (ID_HC, CIP_PACIENTE, FECHA_APERTURA)

-- EPISODIO_HC (entidad débil)
-- Depende de HISTORIA_CLINICA: sin HC no hay episodios
EPISODIOS_HC (ID_HC, NUMERO_EPISODIO, FECHA, DIAGNOSTICO, TRATAMIENTO)

-- La PK de EPISODIO_HC es compuesta: (ID_HC, NUMERO_EPISODIO)
-- ID_HC es FK que referencia HISTORIAS_CLINICAS
-- NUMERO_EPISODIO es el discriminador parcial (1º episodio, 2º episodio...)

CREATE TABLE EPISODIOS_HC (
    ID_HC INTEGER,
    NUMERO_EPISODIO INTEGER,
    FECHA DATE NOT NULL,
    DIAGNOSTICO VARCHAR(500),
    TRATAMIENTO VARCHAR(500),
    PRIMARY KEY (ID_HC, NUMERO_EPISODIO),
    FOREIGN KEY (ID_HC) REFERENCES HISTORIAS_CLINICAS(ID_HC)
        ON DELETE CASCADE  -- Si se elimina la HC, se eliminan sus episodios
);

5. Normalización: Eliminación de Redundancias y Anomalías

La normalización es un proceso de diseño que organiza las tablas de una base de datos para reducir redundancias y dependencias no deseadas, evitando así anomalías de actualización, inserción y eliminación. Se basa en la teoría de dependencias funcionales.

5.1. Dependencias Funcionales

Una dependencia funcional X → Y (se lee "X determina funcionalmente a Y") significa que conociendo el valor de X, podemos determinar unívocamente el valor de Y.

Ejemplo: En la tabla PACIENTES:

• CIP → NOMBRE (conociendo el CIP, determinamos el nombre del paciente)
• CIP → APELLIDOS, FECHA_NACIMIENTO, DIRECCION
• DNI → NOMBRE (el DNI también determina al paciente)

Tipos de dependencias funcionales:

• Dependencia funcional completa: Y depende de todo X, no de parte de X
• Dependencia funcional parcial: Y depende solo de parte de X (cuando X es compuesto)
• Dependencia funcional transitiva: X → Y y Y → Z, entonces X → Z (pero Z no depende directamente de X)

-- Tabla NO normalizada: CITAS_PACIENTES
CITAS_PACIENTES (ID_CITA, CIP, NOMBRE_PACIENTE, DIRECCION_PACIENTE, 
                 FECHA_CITA, ID_MEDICO, NOMBRE_MEDICO, ESPECIALIDAD)

Dependencias funcionales identificadas:
1. ID_CITA → CIP, FECHA_CITA, ID_MEDICO  (la cita determina paciente, fecha y médico)
2. CIP → NOMBRE_PACIENTE, DIRECCION_PACIENTE  (el paciente determina su nombre y dirección)
3. ID_MEDICO → NOMBRE_MEDICO, ESPECIALIDAD  (el médico determina su nombre y especialidad)

Dependencias TRANSITIVAS problemáticas:
- ID_CITA → CIP → NOMBRE_PACIENTE  (la cita determina el nombre del paciente transitivamente)
- ID_CITA → ID_MEDICO → NOMBRE_MEDICO  (la cita determina el nombre del médico transitivamente)

Problemas (anomalías):
- REDUNDANCIA: El NOMBRE_PACIENTE se repite en todas las citas del mismo paciente
- ANOMALÍA DE ACTUALIZACIÓN: Si cambia el nombre de un paciente, hay que actualizar N filas
- ANOMALÍA DE INSERCIÓN: No puedo insertar un médico si no tiene citas asignadas
- ANOMALÍA DE ELIMINACIÓN: Si elimino la última cita de un paciente, pierdo sus datos

5.2. Formas Normales

Las formas normales son niveles progresivos de normalización. Cada forma normal cumple las restricciones de la anterior más restricciones adicionales:

5.2.1. Primera Forma Normal (1FN)

Definición: Una tabla está en 1FN si todos los atributos contienen valores atómicos (no hay listas, conjuntos ni atributos compuestos).

-- Tabla NO en 1FN (violación: atributo multivaluado TELEFONOS)
PACIENTES_MAL
CIP         NOMBRE        TELEFONOS                    ALERGIAS
----------  ------------  ---------------------------  --------------------------
0001234567  Juan García   666111222, 955123456         Penicilina, Ibuprofeno
0001234568  María Pérez   677333444                    Ninguna

Problema: TELEFONOS es un atributo multivaluado (lista de teléfonos)
Problema: ALERGIAS es un atributo multivaluado (lista de alergias)

-- Solución: Convertir a 1FN (atributos atómicos)
PACIENTES
CIP         NOMBRE        
----------  ------------
0001234567  Juan García   
0001234568  María Pérez   

TELEFONOS_PACIENTE
CIP         TELEFONO
----------  -----------
0001234567  666111222
0001234567  955123456
0001234568  677333444

ALERGIAS_PACIENTE
CIP         ALERGIA
----------  -----------
0001234567  Penicilina
0001234567  Ibuprofeno

5.2.2. Segunda Forma Normal (2FN)

Definición: Una tabla está en 2FN si está en 1FN y no tiene dependencias funcionales parciales (todos los atributos no clave dependen de la clave primaria completa, no de parte de ella).

-- Tabla NO en 2FN (clave compuesta: CIP, ID_CITA)
CITAS_DETALLES (CIP, ID_CITA, FECHA_CITA, NOMBRE_PACIENTE, DIRECCION_PACIENTE)

Dependencias funcionales:
- (CIP, ID_CITA) → FECHA_CITA  (OK: dependencia completa)
- CIP → NOMBRE_PACIENTE        (MAL: dependencia parcial)
- CIP → DIRECCION_PACIENTE     (MAL: dependencia parcial)

Problema: NOMBRE_PACIENTE y DIRECCION_PACIENTE dependen solo de CIP (parte de la PK)
Consecuencia: Redundancia (el nombre se repite en todas las citas del paciente)

-- Solución: Descomponer en dos tablas
CITAS (CIP, ID_CITA, FECHA_CITA)
PACIENTES (CIP, NOMBRE_PACIENTE, DIRECCION_PACIENTE)

Ahora está en 2FN:
- En CITAS: FECHA_CITA depende de la clave completa (CIP, ID_CITA)
- En PACIENTES: NOMBRE y DIRECCION dependen de la clave completa (CIP)

5.2.3. Tercera Forma Normal (3FN)

Definición: Una tabla está en 3FN si está en 2FN y no hay dependencias funcionales transitivas entre atributos no clave.

-- Tabla NO en 3FN (tiene dependencia transitiva)
PACIENTES (CIP, NOMBRE, DIRECCION, CODIGO_POSTAL, CIUDAD, PROVINCIA)

Dependencias funcionales:
- CIP → NOMBRE, DIRECCION, CODIGO_POSTAL  (OK: dependen de la clave)
- CODIGO_POSTAL → CIUDAD, PROVINCIA       (PROBLEMA: dependencia transitiva)

Dependencia transitiva:
CIP → CODIGO_POSTAL → CIUDAD
CIP → CODIGO_POSTAL → PROVINCIA

Problema: CIUDAD y PROVINCIA dependen transitivamente de CIP a través de CODIGO_POSTAL
Consecuencia: Si hay 1000 pacientes en Sevilla 41001, "Sevilla" se repite 1000 veces

-- Solución: Descomponer eliminando la dependencia transitiva
PACIENTES (CIP, NOMBRE, DIRECCION, CODIGO_POSTAL)
FOREIGN KEY (CODIGO_POSTAL) REFERENCES CODIGOS_POSTALES(CODIGO_POSTAL)

CODIGOS_POSTALES (CODIGO_POSTAL, CIUDAD, PROVINCIA)

Ahora está en 3FN:
- PACIENTES: Todos los atributos dependen directamente de CIP
- CODIGOS_POSTALES: CIUDAD y PROVINCIA dependen directamente de CODIGO_POSTAL

5.3. Ventajas y Desventajas de la Normalización

6. Manipulación de Datos: Álgebra y Cálculo Relacional

El modelo relacional proporciona dos lenguajes formales para manipular datos:

• Álgebra Relacional: Lenguaje procedimental (especifica CÓMO obtener el resultado)
• Cálculo Relacional: Lenguaje declarativo (especifica QUÉ resultado obtener)

Ambos lenguajes son equivalentes en potencia expresiva (teorema de Codd). SQL se basa principalmente en el cálculo relacional, pero incluye elementos del álgebra.

6.1. Álgebra Relacional

El álgebra relacional consta de un conjunto de operadores que toman una o dos relaciones como entrada y producen una nueva relación como salida.

6.1.1. Operadores Unarios (sobre una sola relación)

PACIENTES (CIP, NOMBRE, APELLIDOS, EDAD, CIUDAD)

-- Selección: Pacientes mayores de 65 años
σ_EDAD>65 (PACIENTES)

Equivalente SQL:
SELECT * FROM PACIENTES WHERE EDAD > 65;

-- Proyección: Solo CIP y NOMBRE
π_CIP,NOMBRE (PACIENTES)

Equivalente SQL:
SELECT CIP, NOMBRE FROM PACIENTES;

-- Combinación de operadores: Nombre de pacientes mayores de 65
π_NOMBRE (σ_EDAD>65 (PACIENTES))

Equivalente SQL:
SELECT NOMBRE FROM PACIENTES WHERE EDAD > 65;

6.1.2. Operadores Binarios (sobre dos relaciones)

PACIENTES (CIP, NOMBRE, APELLIDOS)
CITAS (ID_CITA, CIP, FECHA, ID_MEDICO)

-- Join Natural: Pacientes con sus citas
PACIENTES ⋈ CITAS

Equivalente SQL:
SELECT P.CIP, P.NOMBRE, P.APELLIDOS, C.ID_CITA, C.FECHA, C.ID_MEDICO
FROM PACIENTES P
NATURAL JOIN CITAS C;

-- O explícitamente:
SELECT P.CIP, P.NOMBRE, P.APELLIDOS, C.ID_CITA, C.FECHA, C.ID_MEDICO
FROM PACIENTES P
INNER JOIN CITAS C ON P.CIP = C.CIP;

-- Join con condición: Pacientes con citas en 2025
σ_FECHA>='2025-01-01' (PACIENTES ⋈ CITAS)

Equivalente SQL:
SELECT P.CIP, P.NOMBRE, C.FECHA
FROM PACIENTES P
INNER JOIN CITAS C ON P.CIP = C.CIP
WHERE C.FECHA >= '2025-01-01';

6.2. Cálculo Relacional

El cálculo relacional es un lenguaje declarativo basado en la lógica de predicados. Existen dos variantes:

• Cálculo Relacional de Tuplas: Variables son tuplas completas
• Cálculo Relacional de Dominios: Variables son valores de atributos

SQL está basado en el cálculo relacional de tuplas. La sintaxis general es:

{ t | P(t) }

Donde:
- t es una variable de tupla
- P(t) es un predicado (condición lógica) sobre t
- El resultado son todas las tuplas t que satisfacen P(t)

-- Cálculo Relacional de Tuplas:
-- Pacientes mayores de 65 años
{ t | t ∈ PACIENTES ∧ t.EDAD > 65 }

Equivalente SQL:
SELECT * FROM PACIENTES WHERE EDAD > 65;

-- Cálculo Relacional: Nombres de pacientes con citas en 2025
{ t.NOMBRE | t ∈ PACIENTES ∧ ∃c (c ∈ CITAS ∧ c.CIP = t.CIP ∧ c.FECHA >= '2025-01-01') }

Explicación:
- t es una tupla de PACIENTES
- ∃c significa "existe una tupla c"
- c es una tupla de CITAS
- El predicado establece que c.CIP = t.CIP (join) y la fecha es 2025

Equivalente SQL:
SELECT DISTINCT P.NOMBRE
FROM PACIENTES P
WHERE EXISTS (
    SELECT 1 FROM CITAS C
    WHERE C.CIP = P.CIP AND C.FECHA >= '2025-01-01'
);

-- O con JOIN:
SELECT DISTINCT P.NOMBRE
FROM PACIENTES P
INNER JOIN CITAS C ON P.CIP = C.CIP
WHERE C.FECHA >= '2025-01-01';

7. El Lenguaje SQL: Standard Query Language

SQL (Structured Query Language) es el lenguaje estándar para gestionar bases de datos relacionales. Fue desarrollado por IBM en los años 70 (proyecto System R) y estandarizado por ANSI/ISO desde 1986. La versión actual es SQL:2016, aunque la mayoría de SGBD implementan SQL:2011 con extensiones propias.

7.1. Características de SQL

• Declarativo: Describes QUÉ resultado quieres, no CÓMO obtenerlo
• Basado en conjuntos: Opera sobre conjuntos de tuplas, no tuplas individuales
• No sensible a mayúsculas: SELECT = select = SeLeCt (por convención, palabras clave en mayúsculas)
• Estandarizado: SQL ANSI/ISO, pero cada SGBD tiene dialectos propios
• Multiparadigma: Incluye DDL, DML, DCL, TCL

7.2. Categorías de Sentencias SQL

7.3. DDL: Data Definition Language

7.3.1. CREATE TABLE

-- Crear tabla PACIENTES en Diraya
CREATE TABLE PACIENTES (
    CIP VARCHAR(10) PRIMARY KEY,
    DNI VARCHAR(9) UNIQUE NOT NULL,
    NOMBRE VARCHAR(50) NOT NULL,
    APELLIDOS VARCHAR(100) NOT NULL,
    FECHA_NACIMIENTO DATE NOT NULL,
    SEXO CHAR(1) CHECK (SEXO IN ('H', 'M', 'O')),
    DIRECCION VARCHAR(200),
    CODIGO_POSTAL VARCHAR(5),
    TELEFONO VARCHAR(15),
    EMAIL VARCHAR(100),
    FECHA_ALTA DATE DEFAULT CURRENT_DATE,
    MEDICO_ASIGNADO INTEGER,
    CONSTRAINT FK_MEDICO FOREIGN KEY (MEDICO_ASIGNADO) 
        REFERENCES MEDICOS(ID_MEDICO) ON DELETE SET NULL,
    CONSTRAINT CHK_FECHA_NACIMIENTO CHECK (FECHA_NACIMIENTO < CURRENT_DATE),
    CONSTRAINT CHK_EMAIL CHECK (EMAIL LIKE '%@%.%')
);

-- Crear índice para acelerar búsquedas por DNI
CREATE INDEX IDX_PACIENTES_DNI ON PACIENTES(DNI);

-- Crear índice compuesto para búsquedas por apellidos y nombre
CREATE INDEX IDX_PACIENTES_NOMBRE ON PACIENTES(APELLIDOS, NOMBRE);

7.3.2. ALTER TABLE

-- Añadir columna
ALTER TABLE PACIENTES ADD COLUMN ALERGIAS VARCHAR(500);

-- Modificar tipo de datos
ALTER TABLE PACIENTES ALTER COLUMN TELEFONO TYPE VARCHAR(20);

-- Añadir restricción
ALTER TABLE PACIENTES ADD CONSTRAINT UQ_EMAIL UNIQUE (EMAIL);

-- Eliminar columna
ALTER TABLE PACIENTES DROP COLUMN DIRECCION;

7.3.3. DROP y TRUNCATE

-- Eliminar tabla (estructura y datos)
DROP TABLE PACIENTES_TEMPORAL;

-- Eliminar tabla si existe (evita error)
DROP TABLE IF EXISTS PACIENTES_TEMPORAL;

-- Vaciar tabla (elimina datos, conserva estructura)
TRUNCATE TABLE LOG_ACCESOS;
-- TRUNCATE es más rápido que DELETE FROM porque no registra cada fila eliminada

7.4. DML: Data Manipulation Language

7.4.1. SELECT (Consultas)

-- Consulta básica
SELECT CIP, NOMBRE, APELLIDOS FROM PACIENTES;

-- Consulta con filtro
SELECT * FROM PACIENTES WHERE EDAD > 65;

-- Consulta con múltiples condiciones
SELECT * FROM PACIENTES 
WHERE EDAD > 65 AND CIUDAD = 'Sevilla';

-- Consulta con operadores lógicos y LIKE
SELECT * FROM PACIENTES 
WHERE (EDAD > 65 OR CRONICO = 'S') 
AND APELLIDOS LIKE 'García%';

-- Consulta con ORDER BY
SELECT * FROM PACIENTES 
ORDER BY APELLIDOS, NOMBRE;

-- Consulta con LIMIT (PostgreSQL) o TOP (SQL Server)
SELECT * FROM PACIENTES 
ORDER BY FECHA_NACIMIENTO DESC 
LIMIT 10;  -- Los 10 pacientes más jóvenes

-- Consulta con funciones agregadas
SELECT COUNT(*) AS TOTAL_PACIENTES FROM PACIENTES;
SELECT AVG(EDAD) AS EDAD_MEDIA FROM PACIENTES;
SELECT MAX(FECHA_NACIMIENTO) AS PACIENTE_MAS_JOVEN FROM PACIENTES;

-- Consulta con GROUP BY
SELECT CIUDAD, COUNT(*) AS TOTAL_PACIENTES
FROM PACIENTES
GROUP BY CIUDAD
ORDER BY TOTAL_PACIENTES DESC;

-- WHERE: Filtra pacientes individuales antes de agrupar
SELECT CIUDAD, COUNT(*) AS TOTAL_PACIENTES
FROM PACIENTES
WHERE EDAD > 65  -- Filtra FILAS (pacientes mayores de 65)
GROUP BY CIUDAD;

-- HAVING: Filtra grupos de pacientes después de agrupar
SELECT CIUDAD, COUNT(*) AS TOTAL_PACIENTES
FROM PACIENTES
GROUP BY CIUDAD
HAVING COUNT(*) > 1000;  -- Filtra GRUPOS (ciudades con >1000 pacientes)

-- Combinación de WHERE y HAVING
SELECT CIUDAD, AVG(EDAD) AS EDAD_MEDIA
FROM PACIENTES
WHERE FECHA_ALTA >= '2023-01-01'  -- Solo pacientes dados de alta desde 2023
GROUP BY CIUDAD
HAVING AVG(EDAD) > 50;  -- Solo ciudades con edad media >50

Orden de ejecución SQL:
1. FROM (tablas)
2. WHERE (filtrar filas)
3. GROUP BY (agrupar)
4. HAVING (filtrar grupos)
5. SELECT (proyección)
6. ORDER BY (ordenar)
7. LIMIT/TOP (limitar resultados)

7.4.2. Joins (Consultas Multi-Tabla)

-- INNER JOIN: Solo pacientes con citas
SELECT P.CIP, P.NOMBRE, P.APELLIDOS, C.FECHA_CITA
FROM PACIENTES P
INNER JOIN CITAS C ON P.CIP = C.CIP_PACIENTE;

-- LEFT JOIN: Todos los pacientes, con o sin citas
SELECT P.CIP, P.NOMBRE, C.FECHA_CITA
FROM PACIENTES P
LEFT JOIN CITAS C ON P.CIP = C.CIP_PACIENTE;

-- RIGHT JOIN: Todas las citas (incluso si el paciente no existe - raro)
SELECT P.NOMBRE, C.FECHA_CITA
FROM PACIENTES P
RIGHT JOIN CITAS C ON P.CIP = C.CIP_PACIENTE;

-- FULL OUTER JOIN: Todos los pacientes y todas las citas
SELECT P.NOMBRE, C.FECHA_CITA
FROM PACIENTES P
FULL OUTER JOIN CITAS C ON P.CIP = C.CIP_PACIENTE;

-- Join de 3 tablas: Pacientes, Citas, Médicos
SELECT P.NOMBRE AS PACIENTE, M.NOMBRE AS MEDICO, C.FECHA_CITA
FROM PACIENTES P
INNER JOIN CITAS C ON P.CIP = C.CIP_PACIENTE
INNER JOIN MEDICOS M ON C.ID_MEDICO = M.ID_MEDICO
WHERE C.FECHA_CITA >= CURRENT_DATE
ORDER BY C.FECHA_CITA;

-- Self-Join: Pacientes que comparten médico
SELECT P1.NOMBRE AS PACIENTE1, P2.NOMBRE AS PACIENTE2, P1.MEDICO_ASIGNADO
FROM PACIENTES P1
INNER JOIN PACIENTES P2 ON P1.MEDICO_ASIGNADO = P2.MEDICO_ASIGNADO
WHERE P1.CIP < P2.CIP;  -- Evita duplicados (A-B y B-A)

7.4.3. INSERT, UPDATE, DELETE

-- INSERT: Insertar nuevo paciente
INSERT INTO PACIENTES (CIP, DNI, NOMBRE, APELLIDOS, FECHA_NACIMIENTO, SEXO)
VALUES ('0001234567', '12345678A', 'Juan', 'García López', '1985-03-15', 'H');

-- INSERT múltiple
INSERT INTO PACIENTES (CIP, DNI, NOMBRE, APELLIDOS, FECHA_NACIMIENTO, SEXO)
VALUES 
    ('0001234568', '87654321B', 'María', 'Pérez Ruiz', '1992-07-22', 'M'),
    ('0001234569', '11223344C', 'Antonio', 'Martín Sánchez', '1978-11-30', 'H');

-- INSERT desde consulta
INSERT INTO PACIENTES_CRONICOS (CIP, NOMBRE, PATOLOGIA)
SELECT CIP, NOMBRE, 'Diabetes'
FROM PACIENTES
WHERE DIAGNOSTICO_PRINCIPAL = 'E11';

-- UPDATE: Actualizar datos
UPDATE PACIENTES
SET TELEFONO = '955123456', EMAIL = 'juan.garcia@email.com'
WHERE CIP = '0001234567';

-- UPDATE con subconsulta
UPDATE PACIENTES
SET MEDICO_ASIGNADO = (SELECT ID_MEDICO FROM MEDICOS WHERE ESPECIALIDAD = 'Medicina Familiar' LIMIT 1)
WHERE MEDICO_ASIGNADO IS NULL;

-- DELETE: Eliminar registros
DELETE FROM CITAS
WHERE FECHA_CITA < '2023-01-01' AND ESTADO = 'CANCELADA';

-- DELETE con subconsulta
DELETE FROM PACIENTES
WHERE CIP IN (SELECT CIP FROM PACIENTES_BAJA WHERE FECHA_BAJA < '2020-01-01');

7.5. Transacciones y Propiedades ACID

Una transacción es un conjunto de operaciones SQL que se ejecutan como una unidad atómica. O se completan todas con éxito (COMMIT) o se deshacen todas (ROLLBACK).

-- Inicio de transacción
BEGIN TRANSACTION;

-- 1. Registrar la consulta
INSERT INTO CONSULTAS (ID_CONSULTA, CIP_PACIENTE, ID_MEDICO, FECHA, MOTIVO)
VALUES (NEXTVAL('seq_consultas'), '0001234567', 12345, CURRENT_DATE, 'Revisión anual');

-- 2. Actualizar historia clínica
UPDATE HISTORIAS_CLINICAS
SET ULTIMA_CONSULTA = CURRENT_DATE, 
    NUMERO_CONSULTAS = NUMERO_CONSULTAS + 1
WHERE CIP_PACIENTE = '0001234567';

-- 3. Generar prescripciones si hay tratamiento
INSERT INTO PRESCRIPCIONES (ID_PRESCRIPCION, ID_CONSULTA, MEDICAMENTO, POSOLOGIA)
VALUES (NEXTVAL('seq_prescripciones'), CURRVAL('seq_consultas'), 'Ibuprofeno 600mg', '1 cada 8h');

-- 4. Registrar en log de auditoría (ENS)
INSERT INTO LOG_AUDITORIA (USUARIO, ACCION, TABLA, REGISTRO_AFECTADO, FECHA)
VALUES (CURRENT_USER, 'INSERT', 'CONSULTAS', CURRVAL('seq_consultas'), CURRENT_TIMESTAMP);

-- Si todo va bien: confirmar
COMMIT;

-- Si hay algún error: deshacer todo
-- ROLLBACK;

Propiedades ACID en este ejemplo:
- ATOMICITY: Las 4 operaciones se ejecutan completamente o no se ejecuta ninguna
- CONSISTENCY: Se respetan todas las FK (CIP_PACIENTE debe existir, ID_MEDICO debe existir)
- ISOLATION: Otro médico no ve la consulta hasta que se hace COMMIT
- DURABILITY: Después del COMMIT, aunque se caiga el servidor, la consulta está registrada

7.6. Niveles de Aislamiento

El estándar SQL define cuatro niveles de aislamiento que equilibran consistencia y concurrencia:

8. Interoperabilidad y Estándares de Conexión

La interoperabilidad entre diferentes SGBD es crucial en entornos heterogéneos como el SAS, donde coexisten Oracle (Diraya), PostgreSQL (BPS), MySQL (aplicaciones departamentales) y SQL Server (algunas aplicaciones legacy).

8.1. Estándares de Conectividad

8.1.1. ODBC (Open Database Connectivity)

ODBC es un estándar definido por Microsoft para acceso a bases de datos. Proporciona una API común que permite a las aplicaciones conectarse a diferentes SGBD usando un driver específico.

Arquitectura ODBC:

import pyodbc

# Configurar DSN (Data Source Name) en odbc.ini
# [DIRAYA_PROD]
# Driver = /usr/lib/oracle/21/client64/lib/libsqora.so
# Server = diraya-db.sspa.juntadeandalucia.es
# Port = 1521
# Database = DIRAYA

# Conectar a Diraya usando ODBC
conexion = pyodbc.connect(
    'DSN=DIRAYA_PROD;'
    'UID=usuario_consultas;'
    'PWD=contraseña_segura'
)

cursor = conexion.cursor()

# Consultar pacientes del centro
cursor.execute("""
    SELECT CIP, NOMBRE, APELLIDOS, EDAD
    FROM PACIENTES
    WHERE CENTRO_SALUD = 'CS001' AND EDAD > 65
""")

# Procesar resultados
for row in cursor.fetchall():
    print(f"CIP: {row.CIP}, Paciente: {row.NOMBRE} {row.APELLIDOS}, Edad: {row.EDAD}")

cursor.close()
conexion.close()

8.1.2. JDBC (Java Database Connectivity)

JDBC es el estándar de Java para acceso a bases de datos. Es similar a ODBC pero está diseñado específicamente para Java y es multiplataforma.

import java.sql.*;

public class ConsultaBPS {
    public static void main(String[] args) {
        String url = "jdbc:postgresql://bps-db.sspa.juntadeandalucia.es:5432/bps_prod";
        String usuario = "usuario_consultas";
        String password = "contraseña_segura";
        
        try {
            // Cargar driver JDBC de PostgreSQL
            Class.forName("org.postgresql.Driver");
            
            // Conectar a BPS
            Connection conexion = DriverManager.getConnection(url, usuario, password);
            
            // Preparar consulta
            String sql = "SELECT cip, dni, nombre, apellidos FROM pacientes WHERE provincia = ?";
            PreparedStatement stmt = conexion.prepareStatement(sql);
            stmt.setString(1, "Sevilla");
            
            // Ejecutar consulta
            ResultSet rs = stmt.executeQuery();
            
            // Procesar resultados
            while (rs.next()) {
                System.out.println("CIP: " + rs.getString("cip") + 
                                 ", Paciente: " + rs.getString("nombre") + " " + rs.getString("apellidos"));
            }
            
            // Cerrar recursos
            rs.close();
            stmt.close();
            conexion.close();
            
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

8.1.3. ADO.NET (Microsoft)

ADO.NET es la tecnología de Microsoft para acceso a datos desde aplicaciones .NET (C#, VB.NET). Proporciona proveedores específicos para SQL Server, Oracle, PostgreSQL, etc.

8.1.4. OCI (Oracle Call Interface)

OCI es la API nativa de Oracle para acceso a bases de datos Oracle desde C/C++. Es más eficiente que ODBC para aplicaciones que solo trabajan con Oracle.

8.2. Estándares SQL

El estándar SQL ha evolucionado desde 1986:

• SQL-86/SQL-87: Primera estandarización (ANSI/ISO)
• SQL-89: Integridad referencial
• SQL-92 (SQL2): Mayor madurez, ampliamente implementado
• SQL:1999 (SQL3): Triggers, procedimientos almacenados, recursividad
• SQL:2003: XML, ventanas (window functions), secuencias
• SQL:2008: Mejoras en window functions, TRUNCATE
• SQL:2011: Datos temporales, mejoras en window functions
• SQL:2016: JSON, pattern matching, polimorfismo

8.3. Database Links y Bases de Datos Federadas

-- En servidor central de Diraya, crear database link a BD de hospital
CREATE DATABASE LINK DIRAYA_HOSPITAL_SEVILLA
CONNECT TO usuario_replicacion IDENTIFIED BY password_seguro
USING '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=diraya-hosp-sev.sspa.local)(PORT=1521))
       (CONNECT_DATA=(SERVICE_NAME=DIRAYA_HOSP)))';

-- Consultar datos del hospital remoto desde central
SELECT CIP, NOMBRE, APELLIDOS, ULTIMA_CONSULTA
FROM PACIENTES@DIRAYA_HOSPITAL_SEVILLA
WHERE CENTRO = 'HOSPITAL_VIRGEN_DEL_ROCIO';

-- Join entre tabla local y tabla remota
SELECT L.CIP, L.NOMBRE, R.DIAGNOSTICO, R.FECHA
FROM PACIENTES L
INNER JOIN EPISODIOS@DIRAYA_HOSPITAL_SEVILLA R ON L.CIP = R.CIP
WHERE R.FECHA >= SYSDATE - 30;

Ventajas del Database Link:
- Acceso transparente a datos remotos (como si fueran locales)
- Soporta transacciones distribuidas (two-phase commit)
- Útil para consolidación de datos de múltiples centros
- Permite ETL distribuido (extraer datos de hospitales a BI Central)

8.3.1. Bases de Datos Federadas

Una base de datos federada permite consultar datos de múltiples SGBD heterogéneos como si fueran una sola base de datos. Se distinguen dos tipos:

9. Principales SGBD Comerciales

Los SGBD comerciales son productos propietarios desarrollados por grandes empresas tecnológicas. Se caracterizan por soporte profesional, herramientas avanzadas de administración, optimizaciones de rendimiento y cumplimiento de estándares.

9.1. Oracle Database

Oracle es el SGBD relacional líder del mercado empresarial. Desarrollado por Oracle Corporation desde 1979, es la base de datos más utilizada en sistemas críticos de misión.

Características principales:

• Alta disponibilidad: Oracle RAC (Real Application Clusters), Data Guard
• Escalabilidad: Particionado, paralelismo masivo (MPP)
• Seguridad: TDE (cifrado transparente), VPD (políticas de seguridad a nivel fila), audit avanzado
• Rendimiento: Optimizador basado en costes, índices avanzados (B-Tree, Bitmap, Function-based)
• PL/SQL: Lenguaje procedural potente
• Herramientas: Enterprise Manager, AWR (Automatic Workload Repository), ASH (Active Session History)

-- 2 nodos Oracle RAC (activo-activo)
Nodo 1: diraya-rac01.sspa.local (192.168.10.11)
Nodo 2: diraya-rac02.sspa.local (192.168.10.12)

-- SAN compartido (cabina EMC VNX)
ASM Disk Group: +DATA (10 TB RAID 10)
ASM Disk Group: +FRA (5 TB RAID 10, Fast Recovery Area)

-- Configuración alta disponibilidad
Oracle Clusterware: Gestión automática de failover
Oracle Data Guard: Réplica standby en CPD secundario (Granada)
RMAN: Backups incrementales diarios a cinta LTO-9

-- Rendimiento
AWR Reports: Análisis automático cada hora
SQL Tuning Advisor: Optimización de consultas lentas
Table Partitioning: HISTORICO_CONSULTAS particionado por mes
Compression: HCC (Hybrid Columnar Compression) en datos históricos

-- Seguridad (ENS MEDIO)
TDE (Transparent Data Encryption): Cifrado de tablespaces sensibles
VPD (Virtual Private Database): Políticas de seguridad a nivel fila
Audit: Registro de accesos a datos de salud (RGPD)

9.2. Microsoft SQL Server

SQL Server es el SGBD de Microsoft, integrado con el ecosistema Windows Server. Popular en entornos corporativos que utilizan tecnologías Microsoft.

Características principales:

• Integración con Windows: Active Directory, Windows Authentication
• T-SQL: Transact-SQL (extensiones procedimentales de Microsoft)
• Herramientas: SQL Server Management Studio (SSMS), Integration Services (SSIS - ETL)
• Alta disponibilidad: Always On Availability Groups, Failover Clustering
• BI integrado: Analysis Services (OLAP), Reporting Services (SSRS)

9.3. IBM Db2

Db2 es el SGBD de IBM, históricamente fuerte en entornos mainframe (z/OS) pero también disponible para Linux, Unix y Windows.

Características principales:

• Rendimiento en mainframe: Optimizado para z/OS, procesamiento masivo de transacciones
• Compatibilidad SQL: Alta adherencia al estándar SQL
• Compresión: Compresión de datos avanzada (ahorro de espacio)
• Replicación: Q Replication, SQL Replication

Uso en el SAS: No se utiliza actualmente. IBM Db2 es más común en sector financiero y grandes corporaciones con infraestructura mainframe.

9.4. Comparativa SGBD Comerciales

10. SGBD de Código Abierto (Open Source)

Los SGBD de código abierto son alternativas a los SGBD comerciales con licencias libres (GNU GPL, BSD, Apache). Ofrecen ventajas de coste, flexibilidad y comunidad activa, pero con menor soporte comercial (aunque existen empresas que ofrecen soporte profesional).

10.1. PostgreSQL

PostgreSQL es el SGBD open source más avanzado y completo. Desarrollado desde 1986 en la Universidad de Berkeley, es conocido por su robustez, cumplimiento de estándares SQL y extensibilidad.

Características principales:

• Cumplimiento SQL: Mayor adherencia al estándar SQL que cualquier otro SGBD
• ACID completo: Transacciones robustas, MVCC (Multi-Version Concurrency Control)
• Tipos de datos avanzados: JSON, JSONB, XML, Arrays, Hstore, PostGIS (geoespacial)
• Extensibilidad: Funciones propias en múltiples lenguajes (PL/pgSQL, Python, Perl, Java)
• Rendimiento: Índices GiST, GIN, BRIN; particionado nativo; paralelismo de consultas
• Replicación: Streaming replication, logical replication
• Licencia: PostgreSQL License (similar a BSD, muy permisiva)

-- Configuración alta disponibilidad BPS
Servidor maestro: bps-master.sspa.local (192.168.20.10)
Servidor réplica: bps-replica.sspa.local (192.168.20.11)

-- Replicación streaming síncrona (datos críticos)
postgresql.conf (master):
wal_level = replica
synchronous_commit = on
synchronous_standby_names = 'bps-replica'
max_wal_senders = 10

-- Conexión aplicaciones a través de HAProxy (failover transparente)
haproxy.cfg:
frontend postgres
    bind *:5432
    default_backend postgres_backend

backend postgres_backend
    option tcp-check
    server bps-master 192.168.20.10:5432 check
    server bps-replica 192.168.20.11:5432 check backup

-- Si cae el master, HAProxy redirige automáticamente al replica
-- Patroni promueve el replica a master en <30 segundos

10.2. MySQL y MariaDB

MySQL es el SGBD open source más popular del mundo (aunque propiedad de Oracle desde 2010). MariaDB es un fork de MySQL creado por los desarrolladores originales para mantener la independencia.

Características principales:

• Simplicidad: Fácil instalación y administración
• Rendimiento web: Optimizado para aplicaciones web (LAMP stack: Linux, Apache, MySQL, PHP)
• Motores de almacenamiento: InnoDB (transaccional, defecto), MyISAM (rápido, sin transacciones)
• Replicación: Master-Slave, Master-Master, Group Replication (MySQL 8)
• Licencia MySQL: GPL + licencia comercial dual
• Licencia MariaDB: GPL puro

10.3. SQLite

SQLite es un SGBD embebido (sin proceso servidor). La base de datos completa está en un solo fichero. Es el SGBD más desplegado del mundo (smartphones, navegadores, aplicaciones embebidas).

Características principales:

• Embebido: Sin servidor, la librería se enlaza con la aplicación
• Ligero: Librería de ~600 KB
• Autocontenido: BD completa en un solo fichero portable
• Transacciones ACID: Soporta transacciones completas
• Licencia: Dominio público (sin licencia, totalmente libre)

Uso en el SAS: Aplicaciones móviles (ClicSalud+ app en Android/iOS), cachés locales en estaciones de trabajo.

10.4. Comparativa SGBD Open Source vs Comerciales

11. Aplicación Práctica en el SAS

El modelo relacional y los SGBD son la base tecnológica de todos los sistemas de información del SAS. Entender esta arquitectura es fundamental para tu trabajo como Técnico Especialista.

11.1. Arquitectura de Bases de Datos del SAS

11. Conclusiones: El Modelo Relacional en la Sanidad Digital

Vale, ya hemos recorrido todo el camino del modelo relacional, desde las ideas originales de Codd hasta los sistemas concretos que tenemos hoy en día en el SAS. Déjame recapitular lo más importante, porque en un examen de oposición no vas a tener tiempo de recordar cada detalle, pero sí necesitas tener muy claras las ideas clave.

11.1. Ideas Fundamentales que Debes Dominar

11.2. Retos Actuales y Futuros

El modelo relacional lleva 50 años siendo el estándar, pero no está exento de desafíos. Algunas tendencias que debes conocer (podrían aparecer en preguntas de "futuro" o "tendencias"):

• NoSQL y Bases de Datos Multimodelo: MongoDB, Cassandra, Neo4j... Para datos no estructurados, grafos, series temporales. En el SAS, se están explorando bases de datos de grafos para redes de derivaciones entre centros sanitarios.
• NewSQL: Bases de datos que combinan la escalabilidad de NoSQL con las garantías ACID del modelo relacional (CockroachDB, Google Spanner). Todavía no están en el SAS, pero podrían llegar.
• Data Lakes y Big Data: Hadoop, Spark, data lakes... Para análisis masivos de datos sanitarios (BI Corporativo, Machine Learning). Coexisten con bases de datos relacionales tradicionales.
• Bases de Datos en la Nube (DBaaS): Amazon RDS, Azure SQL Database, Google Cloud SQL... El SAS está explorando cloud híbrido (Plan de Transformación Digital 2022-2027).
• Bases de Datos como Código (IaC): Terraform, Ansible, Kubernetes operators... Gestionar bases de datos como infraestructura como código (automatización, reproducibilidad).

A pesar de estos avances, el modelo relacional sigue siendo el corazón de los sistemas de información sanitarios. La historia clínica digital, la gestión de citas, las recetas electrónicas... todo se basa en bases de datos relacionales. Y esto no va a cambiar a corto plazo.

11.3. Aplicabilidad Directa en tu Puesto TFA-STI

Cuando apruebes la oposición (y la vas a aprobar, confía en mí) y te incorpores como Técnico Especialista en Informática en el SAS, el modelo relacional va a ser tu pan de cada día:

• Soporte a aplicaciones clínicas: Diraya, InterSAS, BPS... todas usan bases de datos relacionales. Necesitarás entender cómo funcionan para diagnosticar problemas.
• Gestión de incidencias: "Diraya va lento" → Probablemente un problema de consultas SQL mal optimizadas o índices faltantes.
• Proyectos de migración: Migrar de Oracle a PostgreSQL (tendencia actual en el SAS) requiere entender profundamente el modelo relacional y SQL.
• Seguridad y cumplimiento normativo: RGPD, ENS... Necesitas saber cómo se gestionan los permisos (GRANT/REVOKE), cómo se auditan los accesos, cómo se encriptan los datos.
• Diseño de nuevas aplicaciones: Si participas en el desarrollo de nuevas herramientas (ej: portal de analíticas), necesitarás diseñar el modelo de datos (modelo E-R, normalización, SQL).

El modelo relacional no es "materia de examen". Es la base de tu trabajo diario. Cuanto mejor lo entiendas, más efectivo serás en tu puesto.

11.4. Estrategia de Estudio para Este Tema

Este tema es FUNDAMENTAL. No es de los que puedes estudiar por encima. Te recomiendo:

1. Domina las definiciones formales: Relación, tupla, atributo, dominio, clave primaria, clave foránea, dependencia funcional... Memoriza las definiciones exactas.
2. Practica normalización: Coge tablas desnormalizadas y normalízalas. Identifica dependencias funcionales, lleva a 1FN, 2FN, 3FN. Es una habilidad mecánica que se mejora con práctica.
3. Escribe SQL a mano: No uses herramientas visuales. Escribe consultas SELECT con JOINs, GROUP BY, HAVING... a mano. En el examen no tendrás un IDE.
4. Estudia los SGBD del SAS: Oracle (versión 19c en Diraya), PostgreSQL (versión 15 en BPS), MariaDB. Conoce sus características, ventajas, casos de uso.
5. Repasa preguntas de exámenes anteriores: Este tema cae SIEMPRE. Mira las preguntas de 2019, 2023, 2025... Identifica patrones.

Tiempo de estudio estimado: 2 semanas (10-15 horas). Es un tema denso, pero estructurado. No lo dejes para el final.

12. Mapa Conceptual ASCII

Aquí tienes un diagrama que resume visualmente toda la estructura del tema. Úsalo para repasos rápidos:

╔════════════════════════════════════════════════════════════════════════════╗
║                         TEMA 34: MODELO RELACIONAL                         ║
║                         Bases de Datos Relacionales                        ║
╚════════════════════════════════════════════════════════════════════════════╝

┌─────────────────────────────────────────────────────────────────────────────┐
│ 1. CONCEPTOS FUNDAMENTALES (Edgar Codd, 1970)                             │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   Relación (Tabla)                  Tupla (Fila)           Atributo (Col.) │
│   ┌─────────────┐                   ┌──────────┐           ┌──────────┐   │
│   │ PACIENTES   │◄──────────────────┤ Registro │◄──────────┤ Campo    │   │
│   └─────────────┘                   └──────────┘           └──────────┘   │
│         │                                                                   │
│         ├─── Grado (nº de atributos)                                       │
│         └─── Cardinalidad (nº de tuplas)                                   │
│                                                                             │
│   Dominio: Conjunto de valores válidos para un atributo                    │
│   Esquema: Estructura lógica (tabla + atributos + restricciones)           │
│   Instancia: Datos concretos en un momento dado                            │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ 2. ARQUITECTURA ANSI-SPARC (3 niveles de abstracción)                     │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌─────────────────────────────────────────────────────────────────────┐ │
│   │ NIVEL EXTERNO (Vistas - Lo que ven los usuarios)                    │ │
│   │  • Vista médicos: SELECT nombre, CIP FROM pacientes WHERE ...       │ │
│   │  • Vista enfermeras: SELECT CIP, alergias FROM pacientes WHERE ...  │ │
│   └─────────────────────────────────────────────────────────────────────┘ │
│                         ▲                                                   │
│                         │ Independencia lógica de datos                     │
│                         ▼                                                   │
│   ┌─────────────────────────────────────────────────────────────────────┐ │
│   │ NIVEL CONCEPTUAL (Esquema lógico completo)                          │ │
│   │  • Todas las tablas: PACIENTES, CITAS, MEDICOS, PRESCRIPCIONES...   │ │
│   │  • Relaciones (claves foráneas): CITAS.CIP → PACIENTES.CIP          │ │
│   │  • Restricciones: NOT NULL, UNIQUE, CHECK...                         │ │
│   └─────────────────────────────────────────────────────────────────────┘ │
│                         ▲                                                   │
│                         │ Independencia física de datos                     │
│                         ▼                                                   │
│   ┌─────────────────────────────────────────────────────────────────────┐ │
│   │ NIVEL INTERNO (Almacenamiento físico)                               │ │
│   │  • Ficheros: /data/oracle/diraya/pacientes01.dbf                    │ │
│   │  • Índices: CREATE INDEX idx_cip ON pacientes(CIP)                  │ │
│   │  • Particiones: PARTITION BY RANGE (fecha_alta)                     │ │
│   └─────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ 3. DISEÑO: MODELO ENTIDAD-RELACIÓN → MODELO RELACIONAL                    │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ENTIDADES (Rectángulos)         RELACIONES (Rombos)                      │
│   ┌──────────┐                    ◇──────────◇                             │
│   │ PACIENTE │─────────1:N────────│ TIENE     │─────────N:1──────┐        │
│   └──────────┘                    ◇──────────◇                   │        │
│                                                                   ▼        │
│                                                           ┌──────────┐     │
│                                                           │   CITA   │     │
│                                                           └──────────┘     │
│                                                                             │
│   TRANSFORMACIÓN A TABLAS:                                                 │
│   • Entidades → Tablas (PACIENTES, CITAS)                                  │
│   • Relaciones 1:N → Clave foránea en tabla N (CITAS.CIP → PACIENTES.CIP) │
│   • Relaciones N:M → Tabla intermedia                                      │
│   • Atributos multivaluados → Tabla separada                               │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ 4. NORMALIZACIÓN (Eliminar redundancias)                                  │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   Tabla SIN normalizar (0FN):                                              │
│   ┌─────────────────────────────────────────────────────────────────────┐ │
│   │ CIP  | Nombre | Alergias          | Tel1  | Tel2  | Centro | Ciudad││ │
│   ├─────────────────────────────────────────────────────────────────────┤ │
│   │ 123  | Ana    | Penicilina,Polen  | 666.. | 777.. | H.Rocío | Sev. ││ │
│   └─────────────────────────────────────────────────────────────────────┘ │
│   Problemas: Atributos multivaluados, dependencias transitivas...          │
│                                                                             │
│   1FN (Atributos atómicos):                                                │
│   ┌──────────────────┐       ┌────────────────┐                           │
│   │ PACIENTES        │       │ ALERGIAS       │                           │
│   │ CIP (PK)         │◄──────│ CIP (FK)       │                           │
│   │ Nombre           │       │ Alergia        │                           │
│   │ Centro           │       └────────────────┘                           │
│   │ Ciudad           │                                                     │
│   └──────────────────┘                                                     │
│                                                                             │
│   2FN (Depende de TODA la clave):                                          │
│   ┌──────────────────┐       ┌────────────────┐                           │
│   │ PACIENTES        │       │ TELEFONOS      │                           │
│   │ CIP (PK)         │◄──────│ CIP (FK)       │                           │
│   │ Nombre           │       │ NumeroTel (PK) │                           │
│   │ CentroID (FK) ───┼───┐   └────────────────┘                           │
│   └──────────────────┘   │                                                 │
│                          │   ┌────────────────┐                           │
│                          └──►│ CENTROS        │                           │
│                              │ CentroID (PK)  │                           │
│                              │ Nombre         │                           │
│                              │ Ciudad         │                           │
│                              └────────────────┘                           │
│                                                                             │
│   3FN (Sin dependencias transitivas): Ya alcanzada en el diseño anterior   │
│   (Ciudad depende de Centro, no directamente de Paciente)                  │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ 5. MANIPULACIÓN: ÁLGEBRA RELACIONAL (Operaciones teóricas)                │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   Operaciones Fundamentales:                                               │
│   • Selección (σ):        σ_condición(R) → Filtrar filas                  │
│   • Proyección (π):       π_atributos(R) → Seleccionar columnas           │
│   • Producto cartesiano (×): R × S → Todas las combinaciones              │
│   • Unión (∪):            R ∪ S → Unir resultados                          │
│   • Diferencia (-):       R - S → En R pero no en S                        │
│   • Join (⨝):             R ⨝_condición S → Unir tablas con condición     │
│                                                                             │
│   Ejemplo:                                                                  │
│   π_nombre,apellido(σ_ciudad='Sevilla'(PACIENTES ⨝ CENTROS))              │
│   = Nombres de pacientes de centros en Sevilla                             │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ 6. SQL: LENGUAJE DE CONSULTA ESTÁNDAR (ISO/IEC 9075)                      │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   DDL (Definición):        DML (Manipulación):    DCL (Control):           │
│   • CREATE TABLE           • SELECT               • GRANT                  │
│   • ALTER TABLE            • INSERT               • REVOKE                 │
│   • DROP TABLE             • UPDATE                                        │
│   • CREATE INDEX           • DELETE               TCL (Transacciones):     │
│                                                    • COMMIT                 │
│   Ejemplo DDL:                                    • ROLLBACK               │
│   CREATE TABLE Pacientes (                        • SAVEPOINT              │
│     CIP CHAR(10) PRIMARY KEY,                                              │
│     Nombre VARCHAR(50) NOT NULL,                                           │
│     FechaNac DATE,                                                         │
│     CONSTRAINT chk_fecha CHECK (FechaNac < SYSDATE)                        │
│   );                                                                        │
│                                                                             │
│   Ejemplo DML:                                                              │
│   SELECT p.Nombre, c.Fecha                                                 │
│   FROM Pacientes p                                                         │
│   INNER JOIN Citas c ON p.CIP = c.CIP                                      │
│   WHERE c.Fecha >= SYSDATE                                                 │
│   ORDER BY c.Fecha;                                                        │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ 7. INTEGRIDAD Y RESTRICCIONES                                             │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌──────────────────────────────────────────────────────────────────┐    │
│   │ Integridad de Entidad (Entity Integrity)                        │    │
│   │  → Clave primaria NOT NULL + UNIQUE                              │    │
│   │    CIP CHAR(10) PRIMARY KEY                                      │    │
│   └──────────────────────────────────────────────────────────────────┘    │
│                                                                             │
│   ┌──────────────────────────────────────────────────────────────────┐    │
│   │ Integridad Referencial (Referential Integrity)                  │    │
│   │  → Clave foránea apunta a registro existente                     │    │
│   │    FOREIGN KEY (CIP) REFERENCES Pacientes(CIP)                   │    │
│   │      ON DELETE CASCADE / RESTRICT / SET NULL                     │    │
│   └──────────────────────────────────────────────────────────────────┘    │
│                                                                             │
│   ┌──────────────────────────────────────────────────────────────────┐    │
│   │ Integridad de Dominio (Domain Integrity)                        │    │
│   │  → Valores dentro del dominio permitido                          │    │
│   │    CHECK (Edad BETWEEN 0 AND 150)                                │    │
│   └──────────────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ 8. TRANSACCIONES ACID (Garantías de fiabilidad)                           │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐    │
│   │ ATOMICITY   │  │ CONSISTENCY │  │ ISOLATION   │  │ DURABILITY  │    │
│   │  Todo o     │  │  Estado     │  │  Transacc.  │  │  COMMIT →   │    │
│   │  nada       │  │  válido     │  │  aisladas   │  │  Persiste   │    │
│   └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘    │
│                                                                             │
│   Ejemplo en Diraya (Prescripción):                                        │
│   BEGIN TRANSACTION;                                                        │
│     INSERT INTO Prescripciones (...);      -- 1. Registrar receta          │
│     UPDATE HistoriaClinica SET ...;        -- 2. Actualizar historia       │
│     INSERT INTO RecetaXXI (...);           -- 3. Enviar a farmacia         │
│   COMMIT;  -- Si algo falla → ROLLBACK (todo se deshace)                   │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ 9. SGBD EN EL SAS                                                          │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   COMERCIALES:                  OPEN SOURCE:                               │
│   ┌──────────────┐              ┌──────────────┐                          │
│   │ Oracle 19c   │              │ PostgreSQL15 │                          │
│   │ • Diraya     │              │ • BPS        │                          │
│   │ • InterSAS   │              │ • Catálogos  │                          │
│   │ • Nódulo     │              └──────────────┘                          │
│   └──────────────┘              ┌──────────────┐                          │
│   ┌──────────────┐              │ MariaDB 10   │                          │
│   │ SQL Server   │              │ • Intranets  │                          │
│   │ • Apps .NET  │              │ • Portales   │                          │
│   └──────────────┘              └──────────────┘                          │
│                                                                             │
│   DECISIÓN: Oracle (críticos) / PostgreSQL (importantes) / MariaDB (dept.) │
└─────────────────────────────────────────────────────────────────────────────┘

╔════════════════════════════════════════════════════════════════════════════╗
║ EXAMEN: Preguntas clave esperadas                                         ║
║  1. ¿Qué es una relación/tupla/atributo/dominio? (definiciones exactas)   ║
║  2. Arquitectura ANSI-SPARC (3 niveles + independencia de datos)          ║
║  3. Normalización: llevar tabla de 0FN a 3FN paso a paso                  ║
║  4. SQL: interpretar consulta con JOINs, GROUP BY, subconsultas           ║
║  5. ACID: definir cada propiedad + ejemplo en sanidad                     ║
║  6. SGBD: clasificar como comercial/open source (Oracle, PostgreSQL...)   ║
║  7. Integridad referencial: ON DELETE CASCADE vs RESTRICT                 ║
║  8. Modelo E-R: transformar diagrama a tablas relacionales                ║
╚════════════════════════════════════════════════════════════════════════════╝
        

13. Cuestionario de Preguntas Tipo Test

Aquí tienes 30 preguntas tipo test basadas en exámenes reales del SAS. El nivel de dificultad es similar al que encontrarás en la oposición. Todas las preguntas están acompañadas de su respuesta correcta y una breve explicación.

Instrucciones: Intenta responder todas las preguntas sin mirar las respuestas. Luego, comprueba tus resultados. Un opositor bien preparado debería acertar al menos 24/30 (80%).

14. Estrategia de Estudio para Este Tema

Este tema es fundamental y recurrente en la oposición. No es de los que puedes estudiar por encima. El modelo relacional es la base de la mayoría de sistemas de información del SAS, y las preguntas sobre él aparecen en prácticamente todos los exámenes.

14.1. Planificación Temporal

Tiempo de estudio recomendado: 12-15 horas distribuidas en 2 semanas

14.2. Técnicas de Memorización

Este tema combina teoría formal (definiciones, propiedades) con práctica (SQL, normalización). Necesitas estrategias diferentes para cada parte:

Para Definiciones y Conceptos Teóricos:

• Tarjetas Anki: Crea tarjetas con preguntas-respuestas.
  • Anverso: "¿Qué es una relación en el modelo relacional?"
  • Reverso: "Un subconjunto del producto cartesiano de dominios"
• Acrónimos y Mnemotécnicos:
  • ACID: Atomicidad, Consistencia, Aislamiento (I), Durabilidad
  • 3 niveles ANSI: Externo, Conceptual, Interno (ECI = "es como imprescindible")
• Mapas Mentales: Dibuja un mapa mental con el modelo relacional en el centro y ramas para: definiciones, arquitectura, diseño, normalización, SQL, SGBD. Usa colores y dibujos para facilitar la memoria visual.

Para Normalización y SQL (Habilidades Prácticas):

• Práctica Mecánica: Normalizar tablas es una habilidad mecánica. Coge 10 tablas desnormalizadas y normalízalas paso a paso (0FN → 1FN → 2FN → 3FN). Repite hasta que lo hagas automáticamente.
• Escribir SQL a Mano: No uses herramientas gráficas. Escribe consultas SELECT con JOINs, GROUP BY, HAVING, subconsultas... a mano en papel. En el examen no tendrás un IDE.
• Explicar en Voz Alta: Coge una consulta SQL compleja y explícala en voz alta paso a paso: "Primero une PACIENTES con CITAS mediante un INNER JOIN en CIP, luego filtra por fecha >= hoy, luego agrupa por especialidad...". Esto refuerza la comprensión.

Para SGBD del SAS:

• Tabla Resumen: Crea una tabla con los sistemas del SAS y sus SGBD:

  Sistema	SGBD	Criticidad
  Diraya	Oracle 19c	Crítico
  BPS	PostgreSQL 15	Importante
  Intranets	MariaDB 10	Departamental
  ClicSalud+ App	SQLite	Embebido

• Memoriza esta tabla. Es pregunta segura en el examen.

14.3. Errores Comunes a Evitar

1. Confundir proyección (π) con selección (σ): Proyección selecciona COLUMNAS, selección filtra FILAS. No las confundas.
2. Pensar que 1FN permite atributos multivaluados: ¡NO! La 1FN exige atributos atómicos. Si tienes "Alergias: Penicilina, Polen", NO está en 1FN.
3. Creer que UNIQUE permite múltiples NULL: Depende del SGBD. SQL estándar permite múltiples NULL en columnas UNIQUE, pero algunos SGBD (SQL Server antiguo) no. En el examen, asume el estándar (permite NULL).
4. Mezclar dependencias parciales (2FN) con transitivas (3FN): Parcial = depende de PARTE de la clave compuesta. Transitiva = depende de otro atributo no clave (A → B → C).
5. Confundir INNER JOIN con LEFT JOIN: INNER devuelve solo coincidencias. LEFT devuelve TODAS las filas de la tabla izquierda (con NULL si no hay coincidencia).
6. Olvidar que ON DELETE CASCADE borra en cascada: Si borras un paciente con ON DELETE CASCADE en CITAS, se borran TODAS sus citas. Si no quieres eso, usa RESTRICT.

14.4. Conexión con Otros Temas del Temario

Este tema NO está aislado. Se conecta con:

• Tema 33: Sistemas de Gestión de Bases de Datos (SGBD): Profundiza en arquitecturas, motores, transacciones. El Tema 34 (modelo relacional) es la base teórica, el Tema 33 es la implementación práctica.
• Tema 35-38: Seguridad (ENS, RGPD): Las restricciones de integridad, los permisos (GRANT/REVOKE), la auditoría de accesos... todo se implementa en bases de datos relacionales.
• Tema 42: Sistemas de Información del SAS: Diraya, BPS, InterSAS... todos usan bases de datos relacionales. Entender el modelo relacional te ayuda a entender cómo funcionan estos sistemas.
• Tema 14-20: Desarrollo de Software: Si participas en desarrollo de aplicaciones (Tema 18-20), necesitarás diseñar modelos de datos (E-R → Relacional → SQL).

Cuando estudies estos temas, recuerda lo aprendido en el Tema 34. Todo está interconectado.

14.5. Recursos Adicionales de Estudio

Además de este tema, te recomiendo:

• Libros de Bases de Datos:
  • "Fundamentos de Bases de Datos" (Elmasri & Navathe) - Capítulos 3-9 (modelo relacional, normalización, SQL)
  • "Database System Concepts" (Silberschatz, Korth, Sudarshan) - Capítulos 2-7
• Documentación Oficial:
  • Oracle 19c Documentation (docs.oracle.com) - SQL Language Reference
  • PostgreSQL 15 Documentation (postgresql.org) - Tutorial, SQL Language
• Ejercicios Prácticos:
  • SQLZoo (sqlzoo.net) - Tutoriales interactivos de SQL
  • LeetCode Database (leetcode.com/problemset/database/) - Problemas de SQL con soluciones
• Preguntas de Exámenes Anteriores del SAS:
  • Examen TFA-STI 2019 (preguntas 15-18, 22-25 sobre bases de datos)
  • Examen TFA-STI 2023 (preguntas 12-16, 20-23 sobre SQL y normalización)

14.6. Consejo Final

El modelo relacional es la base de TODO lo que harás como Técnico Especialista en Informática en el SAS. No lo estudies solo para aprobar el examen. Entiéndelo de verdad, practica SQL, normaliza tablas, diseña modelos de datos. Cuanto mejor lo domines, más efectivo serás en tu trabajo diario.

Y recuerda: la oposición es una maratón, no un sprint. Este tema requiere 12-15 horas de estudio repartidas en 2 semanas. No intentes aprenderlo todo en un día. Dedica tiempo cada día, repasa regularmente, y llegarás al examen con confianza.

¡Adelante! La plaza está más cerca de lo que crees. 💪

15. Referencias Normativas y Bibliográficas

15.1. Estándares Internacionales

• ISO/IEC 9075:2023 - SQL (Structured Query Language): Estándar internacional del lenguaje SQL. Partes 1-14 (Foundation, SQL/Foundation, SQL/CLI, SQL/PSM, SQL/MED, SQL/OLB, SQL/Schemata, SQL/JRT, SQL/XML, SQL/MDA, SQL/PGQ, SQL/PROP, SQL/RPR, SQL/MDA).
• ISO/IEC 2382-8:1998 - Database Management Systems: Vocabulario de sistemas de gestión de bases de datos.
• ANSI-SPARC Architecture (1975): Arquitectura de tres niveles para sistemas de bases de datos (estándar de facto, no formal).

15.2. Bibliografía Técnica de Referencia

• Codd, E.F. (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM, 13(6), 377-387. [Artículo fundacional del modelo relacional]
• Elmasri, R., & Navathe, S. (2015). "Fundamentos de Sistemas de Bases de Datos" (7ª ed.). Pearson Education. [Capítulos 3-9: Modelo relacional, diseño, normalización, SQL]
• Silberschatz, A., Korth, H.F., & Sudarshan, S. (2019). "Database System Concepts" (7th ed.). McGraw-Hill. [Capítulos 2-7: Introducción, modelo relacional, SQL, diseño]
• Date, C.J. (2003). "An Introduction to Database Systems" (8th ed.). Addison-Wesley. [Referencia clásica, muy completa]
• Connolly, T., & Begg, C. (2014). "Database Systems: A Practical Approach" (6th ed.). Pearson. [Enfoque práctico con casos de estudio]

15.3. Documentación de SGBD

• Oracle Database 19c Documentation: docs.oracle.com
  • SQL Language Reference
  • Database Concepts
  • Administrator's Guide
• PostgreSQL 15 Documentation: postgresql.org/docs/15/
  • Tutorial
  • SQL Language
  • Server Administration
• MariaDB 10 Documentation: mariadb.com/kb/en/
  • SQL Statements
  • Built-in Functions
  • Optimization and Tuning

15.4. Normativa y Estrategias del SAS

• Plan de Transformación Digital del SSPA 2022-2027: Estrategia de migración a cloud híbrido, modernización de sistemas, adopción de tecnologías open source.
• Política de Seguridad de Tecnologías de la Información y Comunicaciones del SAS: Incluye requisitos de seguridad para bases de datos (cifrado, control de acceso, auditoría).
• Catálogo de Servicios TIC del SAS: Incluye servicios de bases de datos gestionadas (Oracle, PostgreSQL).
• Esquema Nacional de Seguridad (ENS) - RD 311/2022: Medidas de seguridad aplicables a bases de datos (control de acceso, auditoría, cifrado, copias de seguridad).
• RGPD (Reglamento UE 2016/679) y LOPDGDD (LO 3/2018): Protección de datos de salud (categoría especial) en bases de datos.

15.5. Recursos Online

• SQLZoo: sqlzoo.net - Tutoriales interactivos de SQL
• W3Schools SQL Tutorial: w3schools.com/sql/
• PostgreSQL Tutorial: postgresqltutorial.com
• Oracle Live SQL: livesql.oracle.com - Entorno SQL online de Oracle
• Database Design Tutorial: vertabelo.com/blog/database-design-tutorial/

15.6. Artículos y Publicaciones Relevantes

• Codd, E.F. (1974). "Recent Investigations in Relational Data Base Systems". Proceedings of IFIP Congress, 1017-1021.
• Bernstein, P.A. (1976). "Synthesizing Third Normal Form Relations from Functional Dependencies". ACM TODS, 1(4), 277-298.
• Fagin, R. (1977). "Multivalued Dependencies and a New Normal Form for Relational Databases". ACM TODS, 2(3), 262-278. [Sobre 4FN]
• Gray, J., & Reuter, A. (1992). "Transaction Processing: Concepts and Techniques". Morgan Kaufmann. [Referencia sobre ACID y transacciones]

16. Etiquetas SEO y Palabras Clave

Palabras clave principales para este tema:

Long-tail keywords (frases de búsqueda específicas):