Como ya sabrá, las bases de datos utilizan tablas para organizar la información. (Si no está familiarizado con los conceptos de la base de datos, lea ¿Qué es una base de datos?) Cada tabla consta de una serie de filas, cada una de las cuales corresponde a un solo registro de la base de datos. Entonces, ¿cómo las bases de datos mantienen en orden todos estos registros? Es a través del uso de llaves.
Llaves primarias
El primer tipo de clave que discutiremos es la clave principal. Cada tabla de base de datos debe tener una o más columnas designadas como clave principal. El valor que contiene esta clave debe ser único para cada registro en la base de datos.
Por ejemplo, supongamos que tenemos una tabla llamada Empleados que contiene información de personal para cada empleado de nuestra firma. Deberíamos seleccionar una clave principal adecuada que identifique de forma única a cada empleado. Tu primer pensamiento podría ser usar el nombre del empleado. Esto no funcionaría muy bien porque es posible que contrate a dos empleados con el mismo nombre. Una mejor opción podría ser usar un número de ID de empleado único que asigne a cada empleado cuando se los contrata. Algunas organizaciones optan por usar los Números de Seguro Social (o identificadores de gobierno similares) para esta tarea porque cada empleado ya tiene uno y se garantiza que son únicos. Sin embargo, el uso de los Números de Seguro Social para este propósito es altamente controvertido debido a preocupaciones de privacidad. (Si trabaja para una organización gubernamental, el uso de un Número de Seguro Social puede incluso ser ilegal según la Ley de Privacidad de 1974). Por esta razón, la mayoría de las organizaciones han cambiado al uso de identificadores únicos (ID de empleado, ID de estudiante, etc.) .) que no comparten estas preocupaciones de privacidad.
Una vez que decida una clave principal y configure la base de datos, el sistema de administración de la base de datos impondrá la singularidad de la clave. Si intenta insertar un registro en una tabla con una clave principal que duplica un registro existente, la inserción fallará.
La mayoría de las bases de datos también son capaces de generar sus propias claves primarias. Microsoft Access, por ejemplo, puede configurarse para usar el tipo de datos Autonumérico para asignar una ID única a cada registro en la tabla. Si bien es efectivo, esta es una mala práctica de diseño porque le deja un valor sin sentido en cada registro de la tabla. ¿Por qué no usar ese espacio para almacenar algo útil?
Llaves extranjeras
El otro tipo es la clave externa, que se utiliza para crear relaciones entre tablas. Las relaciones naturales existen entre las tablas en la mayoría de las estructuras de base de datos. Al regresar a nuestra base de datos de empleados, imagine que queremos agregar una tabla que contenga información del departamento a la base de datos. Esta nueva tabla podría denominarse Departamentos y contendría una gran cantidad de información sobre el departamento en su conjunto. También quisiéramos incluir información sobre los empleados en el departamento, pero sería redundante tener la misma información en dos tablas (Empleados y Departamentos). En su lugar, podemos crear una relación entre las dos tablas.
Supongamos que la tabla Departamentos utiliza la columna Nombre del departamento como clave principal. Para crear una relación entre las dos tablas, agregamos una nueva columna a la tabla Empleados llamada Departamento. Luego completamos el nombre del departamento al que pertenece cada empleado. También informamos al sistema de administración de la base de datos que la columna Departamento en la tabla Empleados es una clave externa que hace referencia a la tabla Departamentos. La base de datos aplicará la integridad referencial asegurando que todos los valores en la columna Departamentos de la tabla Empleados tengan entradas correspondientes en la tabla Departamentos.
Tenga en cuenta que no hay una restricción de unicidad para una clave externa. Podemos (y lo más probable es que tengamos) más de un empleado que pertenezca a un solo departamento. Del mismo modo, no es obligatorio que una entrada en la tabla Departamentos tenga alguna entrada correspondiente en la tabla Empleados. Es posible que tengamos un departamento sin empleados.
Para más información sobre este tema, lea Creación de claves externas.