Acciones de Integridad Referencial en Cascada

La Integridad Referencial es una de las reglas fundamentales del modelo relacional: garantiza que una clave foránea (FK) en una tabla hija siempre apunte a una clave primaria (PK) existente y válida en la tabla padre, o bien sea NULL.

Sin embargo, en un sistema en producción surge una pregunta crítica: ¿qué debe hacer el motor de base de datos cuando se intenta modificar o eliminar una fila de la tabla padre que ya tiene filas hijas asociadas?

1. Cláusulas Desencadenantes: ON DELETE y ON UPDATE #

En SQL, al definir una restricción de clave foránea (FOREIGN KEY) dentro de una instrucción CREATE TABLE o ALTER TABLE, se especifican dos políticas de comportamiento independientes:

1CREATE TABLE PEDIDOS (
2    id_pedido INT PRIMARY KEY,
3    id_cliente INT,
4    fecha DATE,
5    FOREIGN KEY (id_cliente) REFERENCES CLIENTES(id_cliente)
6        ON DELETE RESTRICT
7        ON UPDATE CASCADE
8);

• ON DELETE: Determina qué ocurre en las filas hijas si se ejecuta un DELETE sobre la fila referenciada en la tabla padre.
• ON UPDATE: Determina qué ocurre en las filas hijas si se ejecuta un UPDATE sobre el valor de la clave primaria en la tabla padre.

2. Las 4 Acciones de Integridad Referencial #

3. Análisis Detallado de Cada Acción #

A. RESTRICT y NO ACTION (Protección Estricta) #

Es la política más segura para evitar pérdidas accidentales de datos.

• Ejemplo: Si intentamos borrar un CLIENTE que tiene 5 PEDIDOS registrados, la base de datos lanza un error de violación de clave foránea y detiene la transacción.
• Diferencia sutil: En motores SQL avanzados (como PostgreSQL), NO ACTION permite diferir la comprobación al final de la transacción (DEFERRABLE INITIALLY DEFERRED), mientras que RESTRICT valida inmediatamente.

1FOREIGN KEY (id_cliente) REFERENCES CLIENTES(id_cliente)
2    ON DELETE RESTRICT;

B. CASCADE (Propagación Automática) #

Muy útil para entidades dependientes o relaciones de composición fuerte (entidades débiles).

• Ejemplo idóneo (Facturas y Líneas de Factura): Si se elimina una FACTURA, es totalmente coherente y deseable que se eliminen automáticamente todas sus LINEAS_FACTURA asociadas.

1CREATE TABLE LINEAS_FACTURA (
2    id_factura INT,
3    num_linea INT,
4    producto VARCHAR(100),
5    importe DECIMAL(10,2),
6    PRIMARY KEY (id_factura, num_linea),
7    FOREIGN KEY (id_factura) REFERENCES FACTURAS(id_factura)
8        ON DELETE CASCADE
9        ON UPDATE CASCADE
10);

WARNING
Peligro en producción: Usar ON DELETE CASCADE en tablas maestras críticas (ej. CLIENTES) puede provocar el borrado masivo e irreversible de cientos de miles de pedidos, facturas e historiales contables con una simple sentencia DELETE FROM CLIENTES WHERE id = 5;.

C. SET NULL (Preservación con Desvinculación) #

Se aplica cuando la entidad hija puede existir de forma independiente sin estar vinculada a un padre específico.

• Ejemplo (Empleados y Departamentos): Si se disuelve un DEPARTAMENTO, los empleados no deben ser despedidos/borrados; simplemente su campo id_depto pasa temporalmente a NULL hasta que sean reasignados.

1CREATE TABLE EMPLEADOS (
2    id_empleado INT PRIMARY KEY,
3    nombre VARCHAR(100),
4    id_depto INT NULL,
5    FOREIGN KEY (id_depto) REFERENCES DEPARTAMENTOS(id_depto)
6        ON DELETE SET NULL
7        ON UPDATE CASCADE
8);

D. SET DEFAULT (Reasignación Automática) #

• Ejemplo: Si se elimina un USUARIO que era redactor de artículos, los posts no se borran ni quedan en nulo, sino que se reasignan automáticamente al usuario genérico del sistema (id_usuario = 1 - Administrador).

1CREATE TABLE ARTICULOS (
2    id_articulo INT PRIMARY KEY,
3    titulo VARCHAR(200),
4    id_autor INT DEFAULT 1,
5    FOREIGN KEY (id_autor) REFERENCES USUARIOS(id_usuario)
6        ON DELETE SET DEFAULT
7);

4. Cuadro Guía de Decisiones en Diseño Lógico #

1¿Qué ocurre al eliminar una fila de la tabla PADRE?
2│
3├── ¿Los registros hijos carecen de sentido sin el padre? (Entidad Débil / Composición)
4│   └── ➔ ON DELETE CASCADE (ej. Pedido -> Líneas de Pedido)
5│
6├── ¿Los registros hijos deben preservarse obligatoriamente por valor legal o histórico?
7│   └── ➔ ON DELETE RESTRICT (ej. Cliente -> Facturas Emitidas)
8│
9├── ¿El hijo puede sobrevivir desvinculado del padre?
10│   └── ➔ ON DELETE SET NULL (ej. Empleado -> Departamento)
11│
12└── ¿El hijo debe pasar a una categoría o usuario de respaldo?
13    └── ➔ ON DELETE SET DEFAULT (ej. Tareas asignadas -> Usuario Soporte General)