Todo lo que hemos construido en este módulo —el esquema, los datos, los JOIN, los informes— se apoya en una suposición que hasta ahora hemos dado por buena: que cuando prestamos dice socio_id = 14, existe un socio 14. Si esa suposición falla, los JOIN pierden filas en silencio, los recuentos mienten y los informes de la lección anterior dejan de ser fiables sin que nadie se dé cuenta.

La integridad referencial es la garantía de que eso no ocurra. Es la tercera regla del modelo relacional, la enunciamos en la lección 02-01 y la hemos estado usando de forma implícita desde que escribimos REFERENCES en el CREATE TABLE. Ahora toca dominarla: cómo se declara, qué comprueba exactamente el gestor, qué debe pasar cuando se borra la fila de la que otras dependen, cómo detectar el daño que ya existe y —una advertencia que puede ahorrarte meses de desconcierto— por qué SQLite no protege absolutamente nada si no se lo pides.

Con esta lección cerramos el módulo 2. Al terminarla, BiblioRed no solo tendrá datos correctos: tendrá un esquema que impide activamente que dejen de serlo.

1. Filas huérfanas: de dónde vienen y qué rompen
2. Declarar una clave ajena
3. Qué comprueba el gestor y cuándo
4. Las acciones referenciales ON DELETE y ON UPDATE
5. Las cinco opciones, comparadas
6. Elegir la acción correcta en BiblioRed
7. El esquema final de BiblioRed con sus acciones referenciales
8. Claves ajenas compuestas
9. Restricciones diferibles
10. SQLite: PRAGMA foreign_keys = ON
11. Detectar y limpiar filas huérfanas
12. ¿Validar en la aplicación o en la base de datos?
13. Errores comunes y consejos
14. Ejercicios
15. Conclusión

Una fila huérfana es una fila cuya clave ajena apunta a algo que no existe. En la hoja de cálculo de BiblioRed que diagnosticamos en la lección 01-01 había tres formas de crearlas, y las tres ocurrían a diario:

1. Teclear un número de socio inventado. Nadie comprobaba nada: si el bibliotecario escribía 77 en lugar de 17, la fila se guardaba tan contenta.
2. Borrar una fila de la que dependían otras. Cuando un socio se daba de baja, alguien eliminaba su línea de la pestaña "Socios"; sus quince préstamos históricos seguían en la pestaña "Préstamos", apuntando al vacío.
3. Renumerar. Al reordenar la hoja de socios, los números cambiaban y todas las referencias anteriores pasaban a señalar a otra persona. Este es el peor de los tres, porque no deja huella: la fila no queda huérfana, queda mal adoptada.

Qué rompe exactamente una fila huérfana:

• Los INNER JOIN la eliminan sin avisar. El informe de préstamos por sucursal de la lección 02-05 simplemente devolvería menos de lo que hay. Y como no hay error, nadie lo investiga.
• Los LEFT JOIN la conservan con NULL, lo que produce informes con huecos que alguien tendrá que explicar.
• Los totales no cuadran entre sí. COUNT(*) FROM prestamos da 4.312 y la suma de los préstamos por socio da 4.298. Y a partir de ahí, la confianza en la base de datos se evapora.

La integridad referencial convierte esas tres formas de crear huérfanos en errores inmediatos, en el momento exacto en que se intentan. Ese es su valor: el problema aparece cuando se puede arreglar, no seis meses después.

Ya lo hicimos en la lección 02-02; ahora con detalle.

Compacta y suficiente para casos simples. El gestor genera un nombre automático para la restricción, del estilo socios_sucursal_id_fkey.

Es la que usamos en BiblioRed, por tres razones:

1. Es obligatoria para claves ajenas compuestas (apartado 8).
2. Permite nombrarla. Cuando salte el error, el mensaje dirá fk_socios_sucursal, no socios_sucursal_id_fkey.
3. Permite eliminarla y recrearla con ALTER TABLE ... DROP CONSTRAINT fk_socios_sucursal, que es justo lo que haremos en el apartado 7.

Al ejecutarlo, PostgreSQL valida todas las filas existentes. Si alguna es huérfana, la operación falla entera:

Es exactamente lo que quieres: la restricción no se activa hasta que los datos estén limpios. El apartado 11 enseña a limpiarlos.

La columna a la que apunta una clave ajena debe tener clave primaria o una restricción UNIQUE. No se puede referenciar una columna cualquiera:

Y tiene sentido: si la columna referenciada pudiera repetirse, "apuntar a la fila con apellido Alsina" sería ambiguo. Por eso ejemplares.libro_id puede apuntar tanto a libros.libro_id (clave primaria) como a libros.isbn (clave alternativa UNIQUE), aunque lo primero es lo sensato.

Una clave ajena impone comprobaciones a las dos tablas, no solo a la hija. Este es el cuadro completo:

Comprobémoslo sobre biblioredb. Primero, desde el lado hijo:

Ahora desde el lado padre:

Y el caso del NULL, que sí se permite:

Una clave ajena nula no apunta a nada, y eso es válido. La regla de integridad referencial habla de valores no nulos. Si quieres que la referencia sea obligatoria, hay que añadir NOT NULL: es una decisión de diseño independiente. En BiblioRed, prestamos.socio_id es NOT NULL (no existe un préstamo sin socio) mientras que libros.autor_id no lo es (sí existen obras sin autor catalogado).

Deshacemos la inserción de prueba:

Hasta aquí, el gestor se ha limitado a prohibir. Pero prohibir no siempre es lo que quieres. Si BiblioRed retira un título entero del catálogo, tener que borrar antes sus ejemplares uno a uno es absurdo: lo natural es que se vayan con él.

Las acciones referenciales dicen qué debe hacer el gestor con las filas hijas cuando la fila padre se borra o cambia de clave:

Son dos cláusulas independientes:

• ON DELETE: qué hacer cuando se borra la fila padre.
• ON UPDATE: qué hacer cuando cambia el valor de la clave primaria de la fila padre.

Si no escribes ninguna, se aplica NO ACTION, el comportamiento por defecto del estándar (el que hemos visto en el apartado anterior).

Para experimentar sin tocar BiblioRed, creamos dos tablas de usar y tirar:

Estado inicial: tres ítems, dos categorías.

Los ítems A y B han desaparecido. El DELETE sobre una fila ha borrado tres filas en total, y solo la primera aparece en el mensaje. Esa es la naturaleza del CASCADE: es potente y es silencioso.

Ahora probemos SET NULL:

El ítem sobrevive; solo pierde su referencia. Limpiamos el laboratorio:

En el 99 % de los casos se comportan igual: ambas impiden la operación. La diferencia es cuándo se comprueba:

• RESTRICT comprueba inmediatamente, en cuanto se ejecuta la fila del DELETE.
• NO ACTION comprueba al final de la instrucción, y además puede diferirse hasta el COMMIT si la restricción se declaró DEFERRABLE (apartado 9).

Consecuencia práctica: RESTRICT no se puede diferir nunca. Si prevés necesitar restricciones diferibles, usa NO ACTION. En BiblioRed usaremos RESTRICT donde queremos una prohibición explícita y visible en el CREATE TABLE, porque documenta la intención mejor que dejar el hueco vacío.

La idea es "si desaparece la sucursal de este ejemplar, asígnalo a la sucursal 1". El problema es evidente: si algún día alguien borra la sucursal 1, la acción falla y el DELETE se bloquea de forma difícil de diagnosticar. Existe, hay que conocerla, y en la práctica se usa muy poco. Nota: las cláusulas DEFAULT se estudian a fondo en la lección 04-04.

La pregunta que hay que hacerse para cada clave ajena es siempre la misma:

Si desaparece la fila padre, ¿la fila hija sigue teniendo sentido por sí sola?

• Si no tiene sentido y no vale nada → CASCADE.
• Si no tiene sentido pero es valiosa (histórico, contabilidad, auditoría) → RESTRICT.
• Si sí tiene sentido sin la referencia → SET NULL.

Apliquémoslo a las ocho claves ajenas de BiblioRed.

Por qué borrar un socio no debe arrastrar su histórico de préstamos. Un préstamo es un hecho ocurrido: el 5 de marzo de 2026 salió un ejemplar por la puerta y volvió el 2 de abril con 1,40 € de recargo. Ese hecho no deja de haber ocurrido porque la persona se dé de baja.

Si pusiéramos CASCADE, dar de baja a un socio destruiría estadísticas históricas —préstamos por año, títulos más prestados, recaudación— que la dirección usa para decidir compras. Es destrucción de información contable disfrazada de limpieza.

Con RESTRICT, el intento de borrado falla, y eso obliga a resolver la pregunta de negocio de verdad: no se borran los socios, se marcan como inactivos (activo = FALSE, como Ramón Etxebarri). Es lo que se llama borrado lógico, y es la práctica correcta para cualquier entidad con historial.

Por qué borrar un libro sí debe arrastrar sus ejemplares. Aquí la relación es de composición: un ejemplar es una copia física de un libro. EJ-3081 no es "un objeto que casualmente está asociado a El mapa del tiempo"; es un ejemplar de El mapa del tiempo. Sin el libro, la fila no significa nada: sería un objeto sin título, sin autor y sin ISBN.

Si el título desaparece del catálogo, mantener sus quince ejemplares sería conservar basura referencial. CASCADE es la acción correcta.

Y aquí ocurre algo interesante. Intentemos borrar un libro que sí tiene préstamos:

El CASCADE de ejemplares intenta borrar los ejemplares 1, 2 y 3… pero el RESTRICT de prestamos.ejemplar_id lo impide:

La cascada se detiene al chocar con una restricción. Es exactamente el comportamiento deseado: se puede retirar del catálogo un título que nunca se prestó, pero no uno con historial. El esquema hace cumplir una regla de negocio real sin que nadie la haya programado en ninguna aplicación.

La asimetría entre prestamos (RESTRICT) y reservas (CASCADE) es el corazón del razonamiento: el préstamo es historia y la reserva es futuro. La historia se conserva; el futuro que ya no puede ocurrir se descarta.

Todas nuestras claves primarias son subrogadas y, por definición, nunca cambian de valor (lección 02-01). Así que ON UPDATE CASCADE no se va a activar jamás. ¿Por qué ponerlo entonces?

Es un seguro barato. Si algún día hay que renumerar identificadores durante una migración o una fusión de dos catálogos, la propagación será automática en lugar de un guion manual propenso a errores. No cuesta nada y evita un desastre improbable pero grave. En un esquema con claves naturales (donde la clave sí puede corregirse) el ON UPDATE CASCADE deja de ser un seguro y pasa a ser imprescindible.

Este es el entregable de la lección. Sustituimos las ocho claves ajenas que creamos en 02-02 por sus versiones con acciones referenciales. Ejecútalo sobre tu biblioredb:

Comprobación:

Y una comprobación de que las reglas se aplican de verdad:

Aquí aparece por primera vez una utilidad práctica de las transacciones: probar una operación destructiva y deshacerla. BEGIN abre la transacción, ROLLBACK la anula por completo. Es el contenido de la lección 06-01; de momento, úsalo como red de seguridad.

SQLite no admite ALTER TABLE ... ADD CONSTRAINT. Para añadir acciones referenciales hay que recrear las tablas con la definición completa. En un CREATE TABLE de SQLite se escribe igual:

Y siempre, siempre, PRAGMA foreign_keys = ON;. Lo vemos en el apartado 10.

Si la clave primaria de la tabla padre es compuesta (varias columnas), la clave ajena que la referencia también tiene que serlo, con las columnas en el mismo orden.

Imagina que BiblioRed decide catalogar la ubicación física exacta de cada ejemplar. Los estantes se numeran dentro de cada sucursal: hay un estante A-12 en Centro y otro A-12 en Norte, y no son el mismo. La clave primaria natural es entonces la pareja:

Y ejemplares la referenciaría así:

Tres reglas que hay que conocer:

1. El orden importa. FOREIGN KEY (a, b) REFERENCES t (x, y) empareja a con x y b con y. Invertirlos crea una restricción distinta y probablemente absurda.
2. La forma de tabla es obligatoria. Una restricción que afecta a dos columnas no cabe en la declaración de una sola.
3. Cuidado con los NULL parciales. Por defecto (MATCH SIMPLE, el comportamiento estándar), si alguna de las columnas es NULL, la restricción no se comprueba en absoluto. Es decir: un ejemplar con sucursal_id = 2 y codigo_estante = NULL pasaría la validación aunque no exista tal estante. Si quieres exigir que estén las dos o ninguna, hay que escribir MATCH FULL.

Una observación de diseño: en el ejemplo anterior hay un ON DELETE SET NULL sobre una clave ajena compuesta de la que sucursal_id forma parte… y sucursal_id es NOT NULL en ejemplares. Eso hace que la acción falle en la práctica. Es un buen recordatorio de que las claves ajenas compuestas son más delicadas de lo que parecen, y una de las razones de peso a favor de las claves subrogadas simples. Estas decisiones de modelado se tratan a fondo en el módulo 4.

Estas tablas son ilustrativas: no las crees en biblioredb, no forman parte del esquema del curso.

Por defecto, las claves ajenas se comprueban inmediatamente, al ejecutar cada instrucción. Eso plantea un problema en tres situaciones reales:

1. Referencias circulares. Si la tabla A referencia a B y B referencia a A, no se puede insertar la primera fila de ninguna de las dos.
2. Cargas masivas en orden arbitrario. Un volcado de datos que inserta prestamos antes que socios fallará, aunque al terminar todo sea coherente.
3. Intercambios. Cambiar dos filas de identificador entre sí pasa por un estado intermedio inválido.

La solución del estándar es declarar la restricción diferible: sus comprobaciones se posponen hasta el COMMIT de la transacción.

Tres modos posibles:

Con la restricción diferida, esto funciona:

Si al llegar al COMMIT la coherencia no se hubiera restablecido, la transacción entera se anula.

Cuatro advertencias:

• RESTRICT nunca se puede diferir. Solo NO ACTION admite DEFERRABLE. Es la diferencia práctica entre ambas que anunciábamos en el apartado 5.
• Las restricciones diferidas consumen más memoria, porque el gestor debe recordar todas las comprobaciones pendientes hasta el COMMIT.
• El error aparece al confirmar, no en la instrucción culpable, lo que dificulta el diagnóstico.
• SQLite solo admite DEFERRABLE INITIALLY DEFERRED, y únicamente si las claves ajenas están activadas.

Consejo: no las uses por defecto. Son una herramienta para casos concretos —cargas masivas, migraciones, referencias circulares—, no una comodidad general. Deshaz el experimento completo si lo has probado, para que biblioredb vuelva a su estado del apartado 7:

Esta es probablemente la advertencia más importante de la lección, y la más fácil de pasar por alto.

SQLite acepta la sintaxis REFERENCES, la almacena en el esquema, la muestra en .schema… y NO LA APLICA, salvo que se active explícitamente en cada conexión.

Por compatibilidad con versiones antiguas, las claves ajenas están desactivadas por defecto. El resultado es un esquema que parece protegido y no lo está:

Ni error, ni aviso: una fila huérfana recién creada, referida a un socio 77 que no existe. Ahora con la comprobación activada:

Lo que hay que saber:

• Es por conexión, no por base de datos. Cada vez que abres sqlite3 o cada vez que tu aplicación abre una conexión, hay que ejecutarlo de nuevo. No se guarda en el fichero.
• No se puede activar dentro de una transacción: si lo intentas, se ignora en silencio.
• Las bibliotecas de acceso a datos no siempre lo hacen por ti. Algunos ORM y controladores lo activan automáticamente; otros no. Compruébalo tú.
• Ponlo como primera línea de todos tus guiones .sql.

Y una herramienta de diagnóstico específica, muy útil cuando heredas un fichero:

Cada línea es una violación existente: tabla, rowid de la fila culpable, tabla padre e índice de la clave ajena. Sin argumentos revisa toda la base de datos. Es lo primero que hay que ejecutar al recibir una base SQLite ajena.

Activar las claves ajenas impide crear huérfanos nuevos. No arregla los que ya existen: de hecho, PostgreSQL se negará a crear la restricción mientras queden. Necesitamos detectarlos y limpiarlos primero.

Reproduzcamos el escenario real: BiblioRed importa los préstamos históricos de la hoja de cálculo a una tabla intermedia sin restricciones, que es como se hacen todas las migraciones.

Es el patrón anti-join de la lección 02-04, aplicado a la auditoría de datos.

La misma pregunta con NOT EXISTS, que es igual de válida y algo más legible:

Y el resumen para la reunión de proyecto, con lo aprendido en 02-05:

Dos tercios de las filas tienen problemas. Ese es el dato con el que se va a hablar con la dirección.

La regla de oro: nunca borres huérfanos sin guardarlos antes. Puede que la información que falta esté en otro sitio, y una vez borrada no vuelve.

Fíjate en el detalle: el INSERT ... SELECT con INNER JOIN importa únicamente las filas que emparejan. Las huérfanas se quedan fuera por construcción, sin necesidad de un WHERE que filtrarlas. Es el uso deliberado de una propiedad del INNER JOIN que en otros contextos era un peligro.

Ahora limpiamos el experimento para dejar biblioredb como estaba (los dos préstamos importados tendrían los identificadores 13 y 14):

Es una discusión recurrente en los equipos de desarrollo, y merece una respuesta razonada.

El argumento a favor de la aplicación: los mensajes de error son mejores ("Ese socio no existe, ¿quieres darlo de alta?" en lugar de un texto en inglés sobre fk_prestamos_socio), se valida antes de llegar a la base de datos, y con un ORM las relaciones ya están descritas en el código.

El argumento a favor de la base de datos, que es el decisivo:

1. La base de datos no es solo tuya. A lo largo de su vida, biblioredb recibirá escrituras de la aplicación web, del proceso nocturno de importación, del guion que alguien ejecuta desde psql a las once de la noche, de la herramienta de administración gráfica y de la migración de dentro de tres años. Cada uno de esos caminos tendría que reimplementar las mismas validaciones. Uno de ellos no lo hará.
2. Los datos duran más que el código. Las aplicaciones se reescriben cada cinco o siete años; los datos se conservan décadas. Una regla que solo vive en el código desaparece con él.
3. La concurrencia. Comprobar en la aplicación "¿existe el socio 14?" y después insertar el préstamo deja una ventana entre ambas operaciones. Si en ese intervalo otra sesión borra al socio 14, la comprobación era inútil. La base de datos verifica dentro de la operación, con los bloqueos adecuados. Este razonamiento se desarrolla en las lecciones 06-01 y 06-02.
4. Las operaciones masivas no pasan por la aplicación. Un UPDATE de 40.000 filas se ejecuta en SQL. Ninguna validación del código lo ve.

La conclusión no es "una u otra", sino las dos, en capas:

La aplicación valida para la persona: mensajes útiles, formularios que guían, errores detectados antes de enviar. La base de datos valida para los datos: es la última línea de defensa, la que nadie puede saltarse, la que sigue ahí cuando la aplicación cambie.

Un caso práctico: BiblioRed valida en el formulario web que el correo tenga formato de correo (eso la base de datos no lo comprueba bien), y la base de datos garantiza que sea UNIQUE y que el sucursal_id exista (eso la aplicación no puede garantizarlo de forma fiable). Cada capa hace lo que sabe hacer.

Nota final: las restricciones CHECK —que verifican condiciones sobre los valores, como "el estado debe ser uno de estos cuatro" o "la fecha de devolución no puede ser anterior a la de préstamo"— son la otra gran herramienta de validación en la base de datos. Se tratan a fondo en la lección 04-04, junto con DEFAULT y los criterios de elección de tipos.

• Olvidar PRAGMA foreign_keys = ON en SQLite. El esquema parece correcto y no protege nada. Es la trampa número uno de esta lección, y hay que repetirlo en cada conexión.
• Poner ON DELETE CASCADE por comodidad. "Así no da errores al borrar" es la peor razón posible. Un DELETE sobre una fila puede llevarse miles encadenadas, sin aviso y sin papelera.
• Borrar entidades con historial. Los socios, los clientes, los productos vendidos no se borran: se marcan como inactivos. RESTRICT es tu aliado precisamente porque te obliga a plantearte esa decisión.
• Confundir RESTRICT con NO ACTION. Se comportan igual salvo en un detalle decisivo: RESTRICT no admite diferimiento.
• Usar SET NULL sobre una columna NOT NULL. PostgreSQL rechaza la definición; en otros gestores el error aparece más tarde, al intentar el borrado.
• Creer que una clave ajena nula es un error. No lo es: NULL significa "no apunta a nadie". Si la referencia debe ser obligatoria, añade NOT NULL.
• Dejar las restricciones sin nombre. El día que tengas que hacer DROP CONSTRAINT, tendrás que ir a buscar el nombre automático en el catálogo.
• Referenciar una columna sin UNIQUE. El gestor lo rechaza, y con razón: la referencia sería ambigua.
• Borrar huérfanos sin guardarlos. Muévelos siempre a una tabla de cuarentena antes. Lo que se borra no vuelve.
• Confiar solo en la validación de la aplicación. Habrá otro camino de escritura. Siempre lo hay.
• Consejo: documenta la acción referencial elegida con un comentario en el CREATE TABLE. Dentro de dos años, "¿por qué esto es RESTRICT y aquello CASCADE?" será una pregunta real, y la respuesta es una decisión de negocio, no técnica.
• Consejo: cuando heredes una base de datos, ejecuta antes que nada la auditoría de huérfanos de cada clave ajena (o PRAGMA foreign_key_check en SQLite). Te dirá en treinta segundos con qué calidad de datos estás trabajando.

BiblioRed quiere añadir tres tablas nuevas. Para cada clave ajena, decide ON DELETE y justifica la elección en una frase.

1. resenas (resena_id, socio_id, libro_id, texto, puntuacion, fecha): reseñas escritas por los socios sobre los libros.
2. multas (multa_id, prestamo_id, importe, fecha_emision, pagada): sanciones económicas derivadas de un préstamo.
3. eventos (evento_id, sucursal_id, titulo, fecha): actividades culturales organizadas por cada sucursal.
4. inscripciones (inscripcion_id, evento_id, socio_id, fecha_inscripcion): socios apuntados a esos eventos.

Con el esquema final del apartado 7 y el juego de datos del curso, di qué ocurre con cada instrucción y cuántas filas se ven afectadas en total.

1. DELETE FROM autores WHERE autor_id = 8; (Marina Escolá, sin obras)
2. DELETE FROM autores WHERE autor_id = 4; (Óscar Barreda, dos obras)
3. DELETE FROM libros WHERE libro_id = 339; (Memoria del Ensanche, 1 ejemplar sin préstamos)
4. DELETE FROM libros WHERE libro_id = 331; (El mapa del tiempo, 3 ejemplares, 4 préstamos, 2 reservas)
5. DELETE FROM socios WHERE socio_id = 20; (Elena Roig, sin préstamos ni reservas)
6. DELETE FROM socios WHERE socio_id = 16; (Nuria Bastos, 2 préstamos, 1 reserva)
7. DELETE FROM sucursales WHERE sucursal_id = 4; (Este, 1 socio, 2 ejemplares)

BiblioRed ha recibido de otra biblioteca un fichero con socios para incorporar. Créalo como tabla intermedia:

1. Escribe una consulta que detecte las filas cuya sucursal_id no existe.
2. Escribe una consulta que detecte las filas cuyo email ya está en uso por un socio actual.
3. Escribe un informe de auditoría con una columna diagnostico que clasifique cada fila.
4. Importa únicamente las filas válidas y comprueba cuántas entraron. Después, deja biblioredb como estaba.

Solución 1

El patrón que emerge: hechos económicos e históricos → RESTRICT; intenciones y elementos accesorios → CASCADE; contenido con valor propio → SET NULL.

Solución 2

Observación importante sobre los casos 4, 6 y 7: el fallo es atómico. Aunque la cascada hubiera empezado a borrar filas antes de chocar con el RESTRICT, todo se deshace: la instrucción es una unidad. Eso lo garantizan las transacciones, tema de la lección 06-01.

Solución 3

Nota: la fila 6 no viola ninguna clave ajena —NULL es una referencia válida— pero sí violaría el NOT NULL de socios.sucursal_id. Son dos restricciones distintas y ambas hay que auditarlas.

Entran Rosa Cabanes y Amina Bakri. El INNER JOIN con sucursales descarta por construcción las filas 2, 5 y 6, y el NOT EXISTS descarta la 4.

Cerramos el módulo con las garantías que hacen que todo lo anterior siga siendo cierto con el paso del tiempo:

• Una fila huérfana es una clave ajena que apunta a algo inexistente. Nacía a diario en la hoja de cálculo de BiblioRed por tecleo, por borrados y por renumeraciones, y su daño es silencioso: los INNER JOIN la eliminan sin avisar y los totales dejan de cuadrar.
• Una clave ajena se declara en forma de columna o, mejor, de tabla con nombre propio (CONSTRAINT fk_...), y solo puede referenciar columnas con PRIMARY KEY o UNIQUE. Al añadirla con ALTER TABLE, el gestor valida todas las filas existentes.
• El gestor comprueba en el INSERT y el UPDATE de la tabla hija, y en el DELETE y el UPDATE de la clave primaria de la tabla padre. Una clave ajena nula es legal: si la referencia debe ser obligatoria, hay que añadir NOT NULL.
• Las cinco acciones referenciales —NO ACTION, RESTRICT, CASCADE, SET NULL y SET DEFAULT— definen qué ocurre con las hijas cuando desaparece el padre. RESTRICT no admite diferimiento; esa es su única diferencia real con NO ACTION.
• El criterio de elección en BiblioRed: el préstamo es historia (RESTRICT) y la reserva es futuro (CASCADE); el ejemplar es una parte del libro (CASCADE) y el libro sobrevive a la ficha de su autor (SET NULL). Un socio no se borra: se marca como inactivo.
• Las claves ajenas compuestas exigen la forma de tabla, respetan el orden de las columnas y, con MATCH SIMPLE, no se comprueban si alguna columna es nula.
• Las restricciones diferibles (DEFERRABLE INITIALLY DEFERRED) posponen la comprobación al COMMIT, y sirven para referencias circulares, cargas masivas e intercambios. No son una comodidad general.
• SQLite no aplica las claves ajenas si no se activa PRAGMA foreign_keys = ON, en cada conexión. PRAGMA foreign_key_check audita una base entera.
• Los huérfanos que ya existen se detectan con el patrón LEFT JOIN ... IS NULL (o NOT EXISTS), se clasifican con CASE WHEN, se guardan en cuarentena y solo entonces se descartan. Un INSERT ... SELECT con INNER JOIN importa por construcción únicamente lo válido.
• Y la conclusión de fondo: se valida en las dos capas. La aplicación valida para la persona; la base de datos es la última línea de defensa, porque habrá otros caminos de escritura, porque los datos duran más que el código y porque solo el gestor puede verificar dentro de la operación, sin ventanas de concurrencia.

Con esto termina el módulo 2. Has recorrido el camino completo del mundo relacional: la teoría del modelo y sus reglas de integridad, el lenguaje SQL y la creación del esquema, el CRUD sobre una tabla, la reunión de varias tablas con JOIN y subconsultas, el resumen con agregados y agrupaciones, y las garantías referenciales que lo sostienen. biblioredb ya no es una base vacía: es un sistema de información con siete tablas, datos coherentes, informes de gestión y defensas propias. En el módulo 3, Bases de Datos No Relacionales, cambiamos de mundo: veremos qué es NoSQL, qué familias existen, cómo se modelan los datos cuando no hay esquema fijo ni claves ajenas que los protejan —y qué se gana y qué se pierde en ese trato—. BiblioRed viene con nosotros: sus reseñas y su registro de actividad son, como decidimos en la lección 01-02, el caso de uso perfecto para MongoDB.