Clave primaria y clave foránea: diferencias y ejemplos para GSI

La clave primaria identifica de forma única cada fila de una tabla; la clave foránea exige que una referencia sea válida respecto a los datos de la tabla referenciada. Para distinguirlas al preparar Gestión de Sistemas e Informática (GSI), plantea dos preguntas: «¿qué identifica este registro?» y «¿a qué registro apunta?». Una columna puede participar en ambas funciones.

En esta guía trabajarás con un caso inventado de departamentos y empleados. La propuesta es dibujar las relaciones, predecir qué operaciones se aceptarían y justificar tu respuesta. Los ejemplos SQL están planteados para PostgreSQL; cuando aparece una particularidad de otro gestor, se indica expresamente. Son ejercicios didácticos originales, no preguntas oficiales de examen.

Clave primaria y clave foránea: comparación rápida

Aspecto	Clave primaria	Clave foránea
Función	Identificar una fila.	Controlar una referencia.
Repeticiones	No admite duplicar la combinación completa.	Puede repetirse si no hay otra restricción que lo impida.
Valores nulos	No los admite en sus columnas en PostgreSQL.	Depende de NOT NULL y de las reglas de correspondencia.
Composición	Una o varias columnas.	Una o varias columnas.
Ejemplo	El identificador de un empleado.	El departamento al que pertenece.

La documentación de restricciones de PostgreSQL explica estas reglas. También aclara que una referencia puede apuntar a una clave primaria o a otras columnas que cumplan los requisitos de unicidad del gestor. Por tanto, evita memorizar que una clave foránea «siempre apunta a la primaria».

Un ejemplo SQL para entender la relación

Imagina una organización con departamentos. Cada empleado pertenece obligatoriamente a uno de ellos. El nombre del departamento puede cambiar, pero queremos conservar un identificador con el que relacionarlo con sus empleados.

CREATE TABLE departamento (
    id_departamento INTEGER PRIMARY KEY,
    nombre VARCHAR(80) NOT NULL
);

CREATE TABLE empleado (
    id_empleado INTEGER PRIMARY KEY,
    nombre VARCHAR(80) NOT NULL,
    id_departamento INTEGER NOT NULL,
    FOREIGN KEY (id_departamento)
        REFERENCES departamento (id_departamento)
);

Lee el código de arriba abajo y dibuja una flecha desde empleado.id_departamento hasta departamento.id_departamento. La flecha representa la referencia, no el orden en que tienes que consultar las tablas.

Comprueba el diseño con cuatro operaciones

Partimos de tablas vacías y añadimos el departamento 7, llamado Soporte. Después, razona estas operaciones por separado:

Añadir a Ana, empleada 101, al departamento 7: encaja con el diseño.
Añadir a Luis, empleado 102, al departamento 7: también; dos empleados pueden compartir departamento.
Añadir a Eva, empleada 103, al departamento 99: falla si ese departamento no existe.
Añadir otra persona con identificador de empleado 101: falla porque ese identificador ya está ocupado.

Antes de mirar las soluciones, cambia los números y repite el razonamiento sobre papel. Por ejemplo, crea primero el departamento 99: ¿qué operación dejaría de fallar? Después elimina mentalmente la declaración NOT NULL de la referencia y plantea qué significaría admitir un empleado sin departamento asignado. La sintaxis y las condiciones de estas restricciones se pueden comprobar en la referencia oficial de CREATE TABLE de PostgreSQL.

Una clave compuesta sigue siendo una sola clave

Considera ahora una tabla de inscripciones a talleres. Decides identificar cada inscripción mediante la pareja (id_persona, id_taller). Escribe estas tres filas en una hoja: (12, 3), (12, 4) y (15, 3).

Las tres parejas son distintas. Una segunda inscripción (12, 3) repetiría la identificación completa. Este ejercicio ayuda a separar «se repite una columna» de «se repite la clave». Microsoft explica esa diferencia en su documentación de claves primarias y foráneas de SQL Server.

También existen referencias compuestas: deben relacionar las columnas correspondientes de ambos lados. La documentación oficial de SQLite sobre claves foráneas ofrece una explicación de este caso. Para practicar, dibuja dos casillas unidas por una llave en cada tabla y conecta la pareja completa. Así podrás detectar una referencia incompleta sin depender de recordar una definición literal.

Qué ocurre al borrar una fila referenciada

Vuelve al departamento 7, que tiene empleados. No concluyas que al borrarlo desaparecerán automáticamente sus empleados: hay que leer la acción definida para la referencia.

ON DELETE CASCADE: en PostgreSQL elimina también las filas que lo referencian.
ON DELETE SET NULL: intenta dejar la referencia a nulo; una columna declarada NOT NULL impediría ese resultado.
Sin indicar acción: PostgreSQL utiliza NO ACTION; en nuestro ejemplo, la eliminación del departamento con empleados fallaría.

Estos comportamientos están descritos en la referencia de CREATE TABLE enlazada antes. Como ejercicio de diseño, escribe qué información querrías conservar al cerrar un departamento. Después compara tu decisión con cada alternativa. No elijas CASCADE solo porque hace que una sentencia deje de dar error.

Tres confusiones que puedes resolver con un dibujo

Confundir una referencia con una restricción de unicidad

Vuelve a las fichas de Ana y Luis: ambos señalan la misma ficha de departamento. Esa imagen permite recordar por qué compartir destino no equivale a compartir identidad. Cuando estudies otro esquema, empieza por asignar un color a cada identidad y otro a las flechas.

Dar por hecho que una clave foránea crea un índice

En SQL Server, declarar una clave foránea no crea automáticamente un índice en sus columnas, según la documentación de Microsoft citada. Separa en tus apuntes la regla que protege los datos y la estructura que puede ayudar a localizar filas. No extrapoles detalles de implementación sin comprobar el gestor.

Probar el ejemplo en otro motor sin revisar sus condiciones

SQLite documenta que la aplicación debe habilitar la comprobación de claves foráneas por conexión mediante PRAGMA foreign_keys = ON, cuando existe soporte para ellas. Si experimentas con ese motor, revisa esa condición antes de interpretar que una inserción aceptada demuestra que tu razonamiento era correcto.

Un reto breve para practicar sin mirar los apuntes

Tapa el ejemplo SQL y responde. Concédete un punto por la respuesta y otro por explicarla con una fila concreta; es una regla de este ejercicio, no una puntuación oficial.

¿Pueden Ana y Luis pertenecer al departamento 7?
¿Puede haber dos empleados distintos con identificador 101?
¿Qué tendrías que hacer antes de asignar a Eva al departamento 99?

Soluciones: sí, comparten una referencia; no, duplicarían la clave primaria; y crear previamente el departamento 99, manteniendo las condiciones del ejemplo. Si dudas, reconstruye el esquema antes de repetir las respuestas.

Este pequeño juego puede servirte para pasar de leer a comprobar lo aprendido. Para ampliar la práctica, PreparaGSI ofrece tests, flashcards y audio-podcasts. Puedes combinar esos formatos en tu preparación y usar este esquema en tus propios apuntes como referencia. Si necesitas organizar las tarjetas de repaso, consulta la guía de flashcards para oposiciones GSI.

Preguntas frecuentes

¿Una tabla puede tener varias claves primarias?

No en PostgreSQL: puede tener una clave primaria formada por varias columnas. «Compuesta» describe su composición, no un conjunto de claves primarias independientes.

¿Una clave foránea puede admitir NULL?

Puede, según su definición. En nuestro ejemplo no se admite porque la columna incluye NOT NULL. Lee siempre el esquema completo.

¿Cómo compruebo que he entendido la diferencia?

Inventa una fila válida y otra inválida, señala la restricción que decide cada caso y explica qué cambio alteraría el resultado. Si puedes hacerlo sin copiar la definición, tienes una comprobación concreta de tu comprensión.

Si te apetece alternar formatos durante el estudio, puedes explorar PreparaGSI y practicar con tests, flashcards y audio-podcasts a tu ritmo.