Claves primarias y foráneas en SQL: 6 casos resueltos

Las claves primarias y foráneas en SQL permiten comprobar si los datos respetan la identificación y las relaciones declaradas. Saber escribir un JOIN no basta para predecir si una inserción o un borrado será aceptado: esa decisión depende de las restricciones del esquema.

Esta práctica contiene seis casos originales ejecutados en SQLite 3.46.1, con operaciones aceptadas, errores esperados y comprobaciones del estado final. Todos los datos son ficticios. Utiliza una base de prácticas vacía y empieza cada caso con una preparación nueva; los resultados de un caso no se arrastran al siguiente.

El Pack Temario TAI 2027 desarrolla el modelo relacional y las claves. Este cuaderno complementa esa materia; no reproduce preguntas oficiales ni anuncia el programa de una convocatoria futura. Para practicar consultas sobre datos relacionados, utiliza también los ocho ejercicios SQL de JOIN, NULL y GROUP BY.

Qué distingue cada restricción

La referencia técnica es la documentación oficial de SQLite sobre claves foráneas y CREATE TABLE y restricciones. Las claves referenciadas no se limitan en general a una primaria: SQLite admite claves padre con la unicidad compatible que exige su documentación. Aquí utilizaremos primarias explícitas.

La configuración y algunos detalles varían entre motores. Las salidas de esta página están comprobadas en la versión de SQLite indicada; no se ha probado su ejecución en todos los gestores.

Preparación inicial para cada caso

Activa las claves foráneas en la conexión que vas a utilizar y fuera de una transacción abierta. Comprueba que la consulta del ajuste devuelve 1; escribir la declaración no sustituye esa comprobación.

PRAGMA foreign_keys = ON;
PRAGMA foreign_keys;

CREATE TABLE departamento (
  codigo TEXT NOT NULL PRIMARY KEY,
  nombre TEXT NOT NULL
);

CREATE TABLE persona (
  id TEXT NOT NULL PRIMARY KEY,
  nombre TEXT NOT NULL,
  dep_codigo TEXT,
  FOREIGN KEY (dep_codigo)
    REFERENCES departamento(codigo)
    ON DELETE RESTRICT
);

INSERT INTO departamento (codigo, nombre) VALUES
  ('D01', 'Archivo'),
  ('D02', 'Atencion'),
  ('D03', 'Soporte');

INSERT INTO persona (id, nombre, dep_codigo) VALUES
  ('E1', 'Ana', 'D01'),
  ('E2', 'Bruno', 'D01'),
  ('E3', 'Carla', 'D02');

Hay tres departamentos y tres personas. Ana y Bruno comparten departamento; Soporte no tiene ninguna persona asignada. dep_codigo no es único ni lleva NOT NULL.

Hemos escrito NOT NULL junto a las claves primarias para expresar el requisito de forma explícita. SQLite conserva excepciones históricas de nulabilidad para determinadas declaraciones de primaria; no conviene deducir el comportamiento de cualquier esquema solo por el nombre de la restricción.

En los casos con un error previsto, ejecuta esa sentencia por separado. Algunos clientes interrumpen un script al encontrar un error: después tendrás que ejecutar la consulta de comprobación de forma independiente.

Caso 1. Repetir una clave primaria

Con los datos iniciales, intenta insertar una persona con un identificador que ya existe:

INSERT INTO persona (id, nombre, dep_codigo)
VALUES ('E1', 'Otra persona', 'D02');

¿Se acepta por tener un nombre y un departamento distintos?

SELECT COUNT(*) AS personas FROM persona;

Caso 2. Referenciar un departamento inexistente

Vuelve al estado inicial y ejecuta:

INSERT INTO persona (id, nombre, dep_codigo)
VALUES ('E4', 'Diego', 'D99');

E4 no existe todavía. ¿Eso garantiza que la fila sea válida?

SELECT id FROM persona WHERE id = 'E4';

Caso 3. Una referencia que admite NULL

De nuevo con la preparación inicial, prueba esta variante:

INSERT INTO persona (id, nombre, dep_codigo)
VALUES ('E4', 'Diego', NULL);

¿Se rechaza por no existir un departamento cuyo código sea NULL?

SELECT id, nombre, dep_codigo
FROM persona
WHERE id = 'E4';

Caso 4. Borrar un padre con RESTRICT

Recupera el estado inicial. El departamento D01 tiene a Ana y Bruno. Intenta borrarlo:

DELETE FROM departamento WHERE codigo = 'D01';

Predice qué ocurre con el departamento y con sus dos personas.

SELECT codigo FROM departamento WHERE codigo = 'D01';
SELECT COUNT(*) AS dependientes
FROM persona
WHERE dep_codigo = 'D01';

Caso 5. Borrado en cascada con otras tablas

Parte de una base recién preparada. Crea estas tablas adicionales, cuya relación utiliza CASCADE, y ejecuta el borrado indicado:

CREATE TABLE departamento_casc (
  codigo TEXT NOT NULL PRIMARY KEY
);
CREATE TABLE persona_casc (
  id TEXT NOT NULL PRIMARY KEY,
  dep_codigo TEXT NOT NULL,
  FOREIGN KEY (dep_codigo)
    REFERENCES departamento_casc(codigo)
    ON DELETE CASCADE
);
INSERT INTO departamento_casc VALUES ('D01'), ('D02');
INSERT INTO persona_casc VALUES
  ('C1', 'D01'), ('C2', 'D01'), ('C3', 'D02');

DELETE FROM departamento_casc WHERE codigo = 'D01';

¿Qué filas permanecen?

SELECT codigo FROM departamento_casc ORDER BY codigo;
SELECT id, dep_codigo FROM persona_casc ORDER BY id;

Caso 6. Una referencia compuesta debe coincidir como pareja

Empieza de nuevo y crea estas tablas adicionales:

CREATE TABLE sesion (
  anio INT NOT NULL,
  turno TEXT NOT NULL,
  PRIMARY KEY (anio, turno)
);
CREATE TABLE inscripcion (
  id TEXT NOT NULL PRIMARY KEY,
  anio INT NOT NULL,
  turno TEXT NOT NULL,
  FOREIGN KEY (anio, turno) REFERENCES sesion(anio, turno)
);
INSERT INTO sesion VALUES (2026, 'A'), (2027, 'B');

Ahora intenta insertar:

INSERT INTO inscripcion VALUES ('X1', 2026, 'B');

El año 2026 y el turno B aparecen en la tabla padre. ¿Es suficiente?

INSERT INTO inscripcion VALUES ('X2', 2026, 'A');
SELECT id, anio, turno FROM inscripcion ORDER BY id;

Resumen de estados comprobados

Para corregirte, escribe restricción, dato que la incumple y estado posterior. Un mensaje de error sin comprobar las tablas deja incompleta la explicación. Una operación aceptada también exige revisar qué filas ha cambiado.

Si quieres estudiar cómo esas relaciones afectan a las consultas, continúa con los ejercicios de JOIN, recuentos y NULL. El Pack Temario TAI 2027 desarrolla la materia dentro de una preparación más amplia; consulta su índice y las bases que correspondan a tu proceso.

Preguntas frecuentes

¿Una clave primaria tiene que ser una sola columna?

No. Puede estar formada por varias columnas. En el sexto caso, la identificación y la referencia utilizan la combinación de año y turno.

¿Una clave foránea tiene que ser única en la tabla hija?

No. En la preparación de esta guía, Ana y Bruno comparten el código D01. La clave de persona es su identificador, no el código del departamento.

¿Una clave foránea permite NULL?

Depende del esquema y del motor. En el tercer caso de SQLite, la columna dep_codigo admite NULL y la inserción se acepta. Añadir una restricción NOT NULL impediría esa ausencia.

¿RESTRICT y CASCADE hacen lo mismo al borrar?

No. En estos casos, RESTRICT impide borrar el padre con dependientes. ON DELETE CASCADE permite el borrado y elimina también las filas hijas relacionadas con ese padre.

¿Estos casos están probados en todos los gestores SQL?

No. Se han ejecutado en SQLite 3.46.1 con claves foráneas activadas. Son seis ejercicios originales de práctica, no preguntas oficiales ni una validación de todos los motores.