UD08 · Prácticas

Antes de cada práctica, restaura EduGest ejecutando los scripts 01 y 02 del proyecto. Los números de filas afectadas que se indican suponen los datos originales.

Práctica 8.1 · Altas, cambios y bajas en EduGest

Objetivo

Insertar, modificar y borrar datos con SQL y con la herramienta gráfica, comprobando en cada paso el efecto de las restricciones y la necesidad de confirmar los cambios.

Desarrollo

Comprobación

Errores habituales

• Si la segunda sesión se queda colgada en el paso 5 o 6, es que intenta modificar una fila bloqueada por la primera sesión, que aún no ha hecho COMMIT. Lo estudiarás en la práctica 8.5.
• Cerrar SQL Developer con cambios pendientes muestra un aviso para confirmarlos o deshacerlos. Lee el aviso.

Práctica 8.2 · Copias, históricos e INSERT … SELECT

Objetivo

Guardar en tablas el resultado de consultas: copias de seguridad rápidas, tablas de histórico y tablas de resumen.

Desarrollo

Comprobación

Ampliación

¿Por qué la clave primaria de HISTORICO_NOTA incluye cod_ciclo? Piensa en el módulo 0484, que existe en DAM y en DAW.

Práctica 8.3 · Modificaciones con subconsultas

Objetivo

Escribir modificaciones que dependen de datos de otras tablas, comprobando antes y después las filas afectadas.

Enunciado

Ejecuta las tareas en orden sobre los datos originales. Para cada una escribe: (1) un SELECT que muestre las filas que se van a modificar, (2) la sentencia de modificación y (3) un SELECT de verificación. El número de filas afectadas debe coincidir con el indicado.

Comprobación

Práctica 8.4 · Laboratorio de transacciones

Objetivo

Comprobar experimentalmente el funcionamiento de COMMIT, ROLLBACK, SAVEPOINT, la confirmación implícita del DDL y la atomicidad de sentencia.

Preparación

CREATE TABLE cuenta (
    id_cuenta  CHAR(1)       CONSTRAINT pk_cuenta PRIMARY KEY,
    titular    VARCHAR2(50)  NOT NULL,
    saldo      NUMBER(12,2)  NOT NULL CONSTRAINT ck_cuenta_saldo CHECK (saldo >= 0)
);
INSERT INTO cuenta VALUES ('A', 'Asociación de alumnado', 1000);
INSERT INTO cuenta VALUES ('B', 'Viaje de fin de curso',   200);
INSERT INTO cuenta VALUES ('C', 'Cantina',                 50);
COMMIT;

Desarrollo

Ejecuta cada experimento y predice los saldos finales antes de consultar SELECT * FROM cuenta ORDER BY id_cuenta;.

Comprobación

Ampliación: la transferencia segura

Escribe la transferencia de 500 € de A a C como una transacción que no confirme nada si alguna de las dos actualizaciones no afecta exactamente a una fila. Usa SQL%ROWCOUNT en un bloque anónimo (adelanto de la UD09):

BEGIN
    UPDATE cuenta SET saldo = saldo - 500 WHERE id_cuenta = 'A';
    IF SQL%ROWCOUNT <> 1 THEN ROLLBACK; RAISE_APPLICATION_ERROR(-20001, 'Cuenta origen inexistente'); END IF;
    UPDATE cuenta SET saldo = saldo + 500 WHERE id_cuenta = 'Z';     -- cuenta inexistente
    IF SQL%ROWCOUNT <> 1 THEN ROLLBACK; RAISE_APPLICATION_ERROR(-20002, 'Cuenta destino inexistente'); END IF;
    COMMIT;
END;
/

Práctica 8.5 · Dos sesiones, un dato: concurrencia y bloqueos

Objetivo

Observar en directo los efectos de las distintas políticas de bloqueo y de los niveles de aislamiento.

Preparación

Usa la tabla CUENTA de la práctica 8.4 restaurada a A = 1000, B = 200, C = 50. Abre dos sesiones como EDUGEST: S1 y S2. En SQL Developer, abre la segunda hoja con Hoja de trabajo SQL no compartida (Ctrl+Mayús+N); si no, las dos hojas comparten sesión y no verás nada.

Experimento 1 · Las lecturas no se bloquean

Experimento 2 · Las escrituras sobre la misma fila esperan

Experimento 3 · La actualización perdida (en la aplicación)

Simulamos dos aplicaciones que leen el saldo, calculan el nuevo valor fuera de la base de datos y lo escriben:

El saldo final es 70: se ha perdido el ingreso de 30 de S1. Repite el experimento con las dos soluciones y comprueba que el saldo final es 100:

Experimento 4 · NOWAIT y WAIT

Experimento 5 · Interbloqueo

Experimento 6 · Informe consistente con READ ONLY

Comprobación

Práctica 8.6 · Carga de notas con MERGE

Contexto

El profesor de Bases de datos de DAM entrega las notas finales en un CSV. Algunas matrículas ya tenían nota (hay que actualizarla si ha cambiado) y se ha incorporado una alumna nueva que no estaba matriculada.

Enunciado

1. Crea el fichero notas_0484_dam.csv con este contenido:

   NIA,NOTA
   10450037,5.25
   10450074,5
   10450111,8
   10450148,7
   10452001,6.5

2. Crea la tabla de carga carga_notas_0484 (nia CHAR(8), nota NUMBER(4,2)) e impórtala con el asistente de SQL Developer (clic derecho → Importar datos).

3. Escribe un MERGE que, para cada fila del CSV, actualice la nota de la matrícula del curso 2025-26 en el módulo 0484 de DAM solo si es distinta.

4. Para el NIA 10452001, que no tiene matrícula de 2025-26, el MERGE no debe hacer nada: escribe una consulta que lo detecte como incidencia.

5. Ejecuta el MERGE dos veces. ¿Cuántas filas se fusionan cada vez?

Comprobación

• La primera ejecución fusiona 3 filas (la de 10450111 ya tenía un 8) y la segunda, 0.
• La consulta de incidencias devuelve el NIA 10452001.

MERGE INTO matricula m
USING (SELECT c.nota, mt.id_matricula
       FROM   carga_notas_0484 c
              JOIN alumno a     ON a.nia = c.nia
              JOIN matricula mt ON mt.id_alumno = a.id_alumno
              JOIN modulo mo    ON mo.id_modulo = mt.id_modulo
       WHERE  mo.codigo = '0484' AND mo.cod_ciclo = 'DAM' AND mt.curso_academico = '2025-26') o
ON (m.id_matricula = o.id_matricula)
WHEN MATCHED THEN UPDATE SET m.nota_final = o.nota
                  WHERE m.nota_final IS NULL OR m.nota_final <> o.nota;

Práctica 8.7 · Reto: guion de promoción de curso

Objetivo

Diseñar un guion transaccional que realiza una tarea compleja de forma segura, verificable y repetible.

Contexto

Ha terminado el curso 2025-26 y jefatura de estudios debe preparar el curso 2026-27 para el alumnado de primer curso. Las reglas son:

1. Promociona a segundo el alumnado de primero con como máximo un módulo pendiente. Un módulo está pendiente si su nota de 2025-26 es menor que 5 o está sin calificar.
2. Al alumnado que promociona se le cambia el grupo al de segundo de su ciclo (1DAM → 2DAM…) y se le matricula en todos los módulos de segundo de su ciclo, en primera convocatoria.
3. Todo el alumnado de primero (promocione o no) se matricula en 2026-27 de sus módulos pendientes, con la convocatoria siguiente a la que tenía.
4. Fecha de matrícula: 10 de septiembre de 2026.

Enunciado

Escribe promocion_2026_27.sql con esta estructura:

WHENEVER SQLERROR EXIT SQL.SQLCODE ROLLBACK
SPOOL promocion_2026_27.log

-- 0. Comprobaciones previas (no modifican nada)
--    · ¿Ya existen matrículas de 2026-27? Si existen, el guion no debe ejecutarse.
--    · Listado del alumnado que promociona y del que no.

-- 1. Matrículas de módulos pendientes (regla 3)
-- 2. Matrículas de segundo curso (regla 2) — ¡antes de cambiar el grupo!
-- 3. Cambio de grupo (regla 2)

-- 4. Verificaciones: recuentos esperados
-- 5. COMMIT
SPOOL OFF

Comprobación

Con los datos originales de EduGest, tu guion debe obtener exactamente:

• Ejecutar el guion por segunda vez no cambia nada (se detiene en las comprobaciones previas).
• Si provocas un error a mitad (por ejemplo, cambiando el nombre de una tabla), no queda ningún cambio aplicado.
• Explicas por qué el alumnado de 1ASIR que promociona no recibe matrículas de segundo (pista: consulta qué módulos de ASIR existen) y qué debería hacer el centro.

DECLARE
    v_n NUMBER;
BEGIN
    SELECT COUNT(*) INTO v_n FROM matricula WHERE curso_academico = '2026-27';
    IF v_n > 0 THEN
        RAISE_APPLICATION_ERROR(-20100, 'Ya existen ' || v_n || ' matrículas de 2026-27');
    END IF;
END;
/

Proyecto EduGest · UD08: guiones de mantenimiento

Enunciado

1. Datos de 2026-27. Ejecuta tu guion de promoción (práctica 8.7) y añade un guion alta_nuevo_alumnado.sql que dé de alta a diez alumnos nuevos de primero con sus matrículas, en una sola transacción.
2. Baja lógica. Añade a ALUMNO una columna fecha_baja y escribe el guion que da de baja a un alumno sin borrar su expediente. Modifica las vistas de la UD05 para que no muestren al alumnado dado de baja.
3. Política de concurrencia. En 08-transacciones.md, decide y justifica la estrategia de bloqueo (pesimista u optimista) para tres operaciones de la aplicación: poner notas, matricular y registrar faltas.
4. Integridad. Revisa tu catálogo de restricciones (UD03-UD05): ¿alguna puede implementarse con una restricción diferida o con un guion transaccional? Documenta qué queda para la UD09.

Comprobación