En esta sesión explicaré los elementos esenciales que sostienen cualquier base de datos relacional: las claves y la integridad referencial en SQL. Antes de hablar de JOINs o de consultas más avanzadas, es fundamental entender cómo se relacionan las tablas entre sí y qué mecanismos garantizan que los datos permanezcan coherentes.
Explicaré:
- qué es una clave primaria (PK)
- qué es una clave foránea (FK)
- cómo funcionan las reglas de integridad referencial
- qué significan acciones como CASCADE, RESTRICT y SET NULL
Para ilustrar estos conceptos usaré un modelo maestro–detalle muy sencillo, compuesto por dos tablas que pueden ejecutarse en cualquier gestor SQL moderno (PostgreSQL, MySQL, SQL Server u Oracle). La idea es que el ejemplo sea universal, claro y fácil de reproducir.
Con estos fundamentos en su lugar, estaremos listos para avanzar hacia los distintos tipos de JOIN en las siguientes sesiones.
1. Claves primarias (Primary Keys)
Una clave primaria (PK) es el identificador único de cada fila en una tabla. Es el punto de partida del modelo relacional porque permite distinguir un registro de otro sin ambigüedad. Antes de continuar daré un ejemplo sencillo: si en la tabla Cliente existe un registro cuya cédula es 37 y el nombre es Pedro, supondremos sin pérdida de generalidad que la cédula es la clave primaria, ya que identifica de manera única a cada cliente. Aunque puede haber clientes con el mismo nombre (Pedro, en este caso), sus cédulas no pueden ser las mismas. Además, la cédula debe tener algún valor (no puede ser nula) y no debería cambiar (esto se conoce como estabilidad de la clave). En otras palabras, la cédula cumple con las propiedades que exige una clave primaria dentro del modelo relacional.
Propiedades esenciales
- Unicidad: no se repite.
- No nula: siempre debe tener valor.
- Estable: no debería cambiar en el tiempo.
- Índice implícito: todos los motores crean un índice para optimizar búsquedas.
Ejemplo universal (funciona en cualquier gestor)
CREATE TABLE Cliente (
Cedula INT PRIMARY KEY, -- Al definirse como clave primaria cumple con las condiciones de no nulidad y unicidad
Nombre VARCHAR(100) NOT NULL
);
Este ejemplo es deliberadamente simple para que funcione en PostgreSQL, MySQL, SQL Server y Oracle.
2. Claves foráneas (Foreign Keys)
Una clave foránea (FK) conecta una tabla con otra. Es la columna que “apunta” a la clave primaria de otra tabla y garantiza que la relación sea válida. Antes de continuar daré el siguiente ejemplo: si tenemos una tabla Pedido donde cada registro representa una compra realizada por un cliente, necesitaremos una forma de indicar a quién pertenece cada pedido. Para eso usamos una clave foránea (FK) que referencia a la clave primaria de la tabla Cliente. En este caso, recoirdemos que la clave primaria de Cliente es el campo Cedula.
Supongamos que en la tabla Pedido existe un registro cuyo número de pedido es 101 y que el campo Cedula contiene el valor 37. Ese valor 37 no identifica al pedido, sino que apunta a la cédula de la tabla Cliente.
Decimos entonces que Cedula en la tabla Pedido es una clave foránea, porque su función es enlazar este pedido con el registro correspondiente en la tabla Cliente. La FK garantiza que solo podamos registrar pedidos asociados a un cliente, evitando inconsistencias como pedidos “huérfanos” o referencias a cédulas inexistentes.
Para qué sirve
- Asegura que no existan registros huérfanos.
- Mantiene la coherencia entre maestro y detalle.
- Permite que los JOINs tengan sentido lógico.
Ejemplo universal
CREATE TABLE Pedido (
Pedido INT PRIMARY KEY,
Cedula INT NOT NULL,
Fecha DATE NOT NULL,
FOREIGN KEY (Cedula) REFERENCES Cliente(Cedula) -- Esta Cédula "apunta" a la Cédula de la tabla Cliente
);
Aquí nace la relación 1 → N: un cliente puede tener muchos pedidos, pero cada pedido pertenece a un solo cliente.
3. Reglas de integridad referencial en SQL: CASCADE, RESTRICT, SET NULL
Las reglas de integridad referencial en SQL definen qué ocurre en la tabla detalle cuando cambia el maestro. Acá hay algo que aclarar: cuando indico que algo “cambia” en la tabla maestro, me refiero exclusivamente a eliminar un registro o alterar el valor de la clave primaria. Eventos como cambiar el nombre del cliente o cualquier otro campo distinto a la clave primaria no afecta la relación entre Cliente y Pedido.
ON DELETE CASCADE
CASCADE indica que al eliminar el registro maestro eliminará todos los registros relacionados en la tabla de los detalles. En nuestro caso, al borrar un registro de la tabla Cliente, borrará todos sus pedidos.
ON DELETE CASCADE
ON DELETE RESTRICT / NO ACTION
Siguiendo con nuestro ejemplo, esta instrucción impide borrar un registro de la tabla Clientesi tiene registros asociados en la tabla Pedido. Es importante indicatr que el programador no tiene que hacer ninguna validación para que esto se ejecute, sino que solo debe indicarlo. Esto es parte de la integridad referencial en SQL.
ON DELETE RESTRICT
ON DELETE SET NULL
En este caso, y usando nuestras tablas, cuando se borra un registro de la tabla Cliente los pedidos permanecen, pero la clave foránea en la tabla Pedido se actualiza a NULL. Para que esto sea posible la clave foránea debe permitir el valor NULL, esto se establece al definir el campo Cedula en la tabla Pedido.
ON DELETE SET NULL
Estas reglas están presentes en todos los motores modernos, aunque con ligeras variaciones en su denominación. Para ilustrar los tres casos, al final de este artículo se incluye un enlace a un repositorio desde el cual puede descargarse un script, que abarcan estos escenarios de restricciones de integridad.
4. Inserción de datos para probar las reglas de integridad referencial en SQL
Poblamos las tablas para ver la relación en acción.
INSERT INTO Cliente (Cedula, Nombre)
VALUES
(1, 'Ana'),
(2, 'Luis'),
(3, 'María');
INSERT INTO Pedido (Pedido, Cedula, Fecha)
VALUES
(101, 1, '2024-01-10'),
(102, 1, '2024-01-12'),
(103, 2, '2024-02-01');
5. Probando la Integridad referencial en SQL
Ejemplos que muestran cómo se comporta el modelo cuando la clave foránea está en modo RESTRICT (comportamiento por defecto en la mayoría de los gestores).
Insertar un pedido con una cédula inexistente → no permitido
Intentamos registrar un pedido para un cliente que no existe:
INSERT INTO Pedido (Pedido, Cedula, Fecha)
VALUES (201, 999, '2024-03-01');
Resultado esperado: El gestor rechaza la operación porque 999 no existe en la tabla Cliente. La clave foránea impide crear un pedido “huérfano”.
Borrar un cliente con pedidos asociados → no permitido
Ahora intentamos borrar al cliente:
DELETE FROM Cliente
WHERE Cedula = 1; -- El cliente 1 tiene los pedidos 101 y 102
Resultado esperado: El gestor no permite borrar el cliente porque tiene pedidos asociados. La regla RESTRICT protege la integridad del modelo maestro–detalle.
Borrar un cliente sin pedidos → permitido
Insertamos un cliente sin pedidos:
INSERT INTO Cliente (Cedula, Nombre)
VALUES (55, 'Luis');
Ahora intentamos borrarlo:
DELETE FROM Cliente
WHERE Cedula = 55;
Resultado esperado: La operación sí se permite, porque ningún pedido depende de ese cliente.
Con esto queda demostrada la función esencial de la integridad referencial: evitar datos huérfanos, inconsistentes o imposibles dentro del modelo relacional. Puedes bajar este script para hacer distintas pruebas de eliminación, inserción y actualización.
Imagen de Diva Plavalaguna – pexels.com


Pingback: El error oculto de NOT IN con NULL en SQL: explicación completa - sqlenvivo.com