Claves primarias y foráneas en bases de datos

Una clave primaria es una columna, o en algunos casos una combinación de columnas, que identifica de forma única a cada fila de una tabla en una base de datos relacional. Para cumplir su función, una clave primaria debe respetar dos reglas fundamentales: sus valores no pueden repetirse, de modo que cada fila tenga un valor distinto que la distinga de todas las demás, y no pueden estar vacíos, de modo que toda fila tenga necesariamente su identificador. Gracias a estas dos propiedades, la clave primaria permite referirse a un registro concreto sin ninguna ambigüedad, lo que es esencial para localizar, actualizar, borrar o relacionar filas con precisión. La práctica más habitual y recomendada es usar como clave primaria una columna de identificador numérico, a menudo llamada id, que la propia base de datos va asignando de forma automática e incremental a cada fila nueva, porque es un valor simple, estable y que no significa nada en el mundo real. Aunque en teoría se podría usar como clave primaria algún dato real que no se repita, como un número de documento, conviene evitar aquellos datos que podrían cambiar con el tiempo, como un correo electrónico o un teléfono, porque si la clave primaria cambia, habría que actualizar todas las referencias a ella en otras tablas, lo que es engorroso y propenso a errores. Por eso se prefiere un identificador artificial, sin significado y permanente. La clave primaria es, en esencia, el documento de identidad de cada registro dentro de su tabla.

Una clave foránea es una columna de una tabla que guarda el valor de la clave primaria de otra tabla, con lo que establece una relación entre ambas. Su propósito es conectar registros de tablas distintas de forma coherente y sin duplicar información. El ejemplo clásico que ilustra el concepto es el de una tabla de clientes y una tabla de pedidos: cada cliente tiene su identificador único como clave primaria en la tabla de clientes, y en la tabla de pedidos, cada pedido incluye una columna que guarda el identificador del cliente que lo realizó; esa columna es la clave foránea, porque apunta a la clave primaria de la tabla de clientes. De este modo, cada pedido queda vinculado a un cliente concreto sin necesidad de repetir en la tabla de pedidos todos los datos del cliente, como su nombre, correo y dirección, que se guardan una sola vez en la tabla de clientes y se referencian cuando hacen falta. Esta forma de relacionar tablas mediante claves foráneas tiene grandes ventajas: reduce la duplicación de datos, evita incoherencias derivadas de tener la misma información copiada en muchos sitios, y refleja de manera natural las relaciones del mundo real, como que un cliente puede tener muchos pedidos. Además, al declarar formalmente una clave foránea, la base de datos puede hacer cumplir la integridad de esa relación, garantizando por ejemplo que no exista un pedido que apunte a un cliente inexistente. Las claves foráneas son, por tanto, el mecanismo que da al modelo relacional su capacidad de conectar información distribuida en varias tablas.

La integridad referencial es el conjunto de reglas que garantizan que las relaciones entre tablas, establecidas mediante claves foráneas, se mantengan siempre coherentes, y es una de las grandes ventajas del modelo de bases de datos relacional. Cuando se declara formalmente una clave foránea, la base de datos asume la responsabilidad de hacer cumplir dos garantías fundamentales. La primera es que no se puede crear ni modificar un registro cuya clave foránea apunte a algo que no existe: por ejemplo, la base de datos rechazará un pedido cuyo identificador de cliente no corresponda a ningún cliente real de la tabla de clientes, evitando así los llamados datos huérfanos, que son registros que hacen referencia a algo inexistente. La segunda garantía es el control sobre el borrado y la actualización de los registros referenciados: si se intenta borrar un cliente que todavía tiene pedidos asociados, la base de datos actúa según lo que se haya configurado, pudiendo impedir el borrado mientras existan pedidos, poner a vacío la referencia en los pedidos, o borrar en cascada también esos pedidos. La enorme importancia de la integridad referencial radica en que estas reglas se aplican en la propia base de datos, y no se dejan libradas a que la aplicación las respete correctamente en todo momento. Esto significa que aunque la aplicación tenga un error o haya varias aplicaciones distintas accediendo a los mismos datos, la base de datos seguirá impidiendo las incoherencias, actuando como una última línea de defensa que mantiene los datos consistentes pase lo que pase.

Se recomienda usar un identificador artificial, es decir, un número sin significado en el mundo real que la base de datos asigna automáticamente, como clave primaria, en lugar de emplear un dato real, por varias razones prácticas relacionadas con la estabilidad y la simplicidad. La razón principal es la estabilidad: una clave primaria idealmente nunca debería cambiar, porque su valor se propaga como clave foránea a todas las tablas que referencian ese registro, de modo que si la clave primaria cambiara, habría que actualizar simultáneamente todas esas referencias en otras tablas, una operación compleja, costosa y propensa a errores. Los datos del mundo real, en cambio, tienden a cambiar: una persona puede cambiar de correo electrónico, de teléfono, de apellido o incluso, en algunos contextos, de número de documento, lo que los hace poco adecuados como identificadores permanentes. Un identificador artificial, al no significar nada, no tiene ningún motivo para cambiar nunca, lo que lo hace perfectamente estable. Otras ventajas incluyen la simplicidad y la eficiencia, ya que un identificador numérico corto es cómodo de manejar, ocupa poco espacio y es rápido de comparar e indexar, frente a datos reales que pueden ser largos o compuestos. También aporta uniformidad, porque todas las tablas siguen el mismo patrón sencillo. Conviene matizar que esto no significa que no se puedan tener también columnas con datos reales únicos, como un correo, sobre las que se apliquen restricciones de unicidad para evitar duplicados; simplemente, esos datos no se usan como la clave primaria que identifica y referencia el registro, papel que se reserva para el identificador artificial estable.

Los datos huérfanos son registros que contienen una referencia a otro registro que ya no existe, es decir, una clave foránea que apunta a una clave primaria inexistente. El nombre resulta muy descriptivo: son como hijos que han quedado sin su padre. Un ejemplo típico sería un pedido cuya columna de identificador de cliente apunta a un cliente que ha sido borrado de la tabla de clientes; ese pedido queda huérfano, porque hace referencia a un cliente que ya no se puede encontrar, lo que genera una incoherencia en la base de datos y puede provocar errores o resultados confusos cuando se intenta consultar la información relacionada. Los datos huérfanos son precisamente uno de los problemas que la integridad referencial está diseñada para evitar. Cuando las claves foráneas se declaran correctamente y la base de datos hace cumplir la integridad referencial, la aparición de datos huérfanos se vuelve imposible, porque la base de datos impide de entrada que se cree una referencia a algo inexistente y controla qué ocurre con los registros dependientes cuando se borra o modifica el registro al que apuntan. En cambio, cuando las relaciones no se declaran formalmente y se confía únicamente en que la aplicación gestione bien los borrados, es fácil que un descuido, un error de programación o una operación manual dejen registros huérfanos, deteriorando poco a poco la coherencia de los datos. Por eso, evitar los datos huérfanos es una de las motivaciones centrales para definir correctamente las claves y aprovechar las garantías de integridad que ofrece el modelo relacional.

RESTRICT, SET NULL y CASCADE son las opciones que determinan cómo debe comportarse la base de datos ante el borrado o la actualización de un registro que está siendo referenciado por claves foráneas de otras tablas, y se configuran al definir la clave foránea. La opción RESTRICT, que suele ser el comportamiento más conservador y a menudo el predeterminado, impide la operación mientras existan registros que dependan del que se quiere borrar o modificar; por ejemplo, no permitiría borrar un cliente que todavía tiene pedidos asociados, obligando a resolver primero esos pedidos, lo que protege contra borrados accidentales de datos con dependencias. La opción SET NULL hace que, al borrar el registro referenciado, la clave foránea en los registros dependientes se ponga a vacío; siguiendo el ejemplo, al borrar un cliente, sus pedidos se conservarían pero su columna de identificador de cliente quedaría vacía, indicando que ya no están asociados a ningún cliente, lo que es útil cuando los registros dependientes deben sobrevivir aunque pierdan su vínculo. La opción CASCADE hace que la operación se propague en cascada a los registros dependientes; al borrar un cliente, se borrarían automáticamente también todos sus pedidos, lo que es cómodo cuando los dependientes no tienen sentido sin el registro principal, pero debe usarse con cuidado porque puede eliminar más datos de los que se pretendía si no se es plenamente consciente del alcance de la cascada. La elección entre estas opciones depende de la lógica de negocio y de qué debe ocurrir con los datos relacionados, y es una decisión de diseño importante que conviene tomar de forma consciente para cada relación.