No usar Claves Principales Compuestas.
Una definición de clave principal
puede ser:
Una característica (o varias) que
no se puede(n) repetir entre los miembros de una entidad/tabla y que no puede(n)
quedar vacía(s).
Si tenemos una tabla de personas, la clave principal podría
ser el DNI si suponemos que dos personas distintas no pueden tener el mismo
DNI, y que toda persona tiene un número de DNI.
La finalidad de la clave principal
es que a la hora de referirnos a un registro (por ejemplo poner en una tabla vehículos
datos del propietario), es suficiente con poner el valor de la clave principal
del propietario.
Como el DNI es la clave principal
de la tabla personas, será un campo que no estará vacío, y por tanto siempre
encontraremos un valor de DNI para referirnos a una persona concreta.
Como además ese campo no se
repite, al poner un valor de DNI en la tabla vehículos solo nos estamos refiriendo
a una persona, no hay posibilidad de confusión.
En ocasiones, no es fácil
encontrar una característica/campo que se pueda usar como clave principal.
Si seguimos con el ejemplo de una
tabla personas y estas personas son alumnos de una guardería que no tienen DNI,
no podemos usar este último como clave principal.
Como hemos visto al principio, la
clave principal puede ser una o más características, por tanto en el caso de
alumnos de una guardería podemos pensar en que la clave principal sea: DNI de
la madre, FechaNacimiento (para diferenciar a los hermanos), y Nombre (por si
tenemos mellizos y/o gemelos.
En este caso podemos decirle a
Access que estos tres campos son la clave principal, y Access lo entiende y
gestiona sin problemas pero yo NO soy partidario de hacerlo así.
Entre otros inconvenientes están
los siguientes:
o
Al
referirnos a una persona no es suficiente con un dato, tenemos que manejar 3,
por ejemplo para poner a los alumnos en una tabla donde guardemos alumno,
clase, etc.
o
Como
ya he indicado en otro artículo, en mis relaciones establezco integridad
referencial y actualización en cascada, y aunque hay quien sostiene que lo
hace, yo no se establecer estas dos propiedades en las relaciones de dos tablas
cuando tenemos una clave principal compuesta.
Como yo lo hago, y mi consejo para
estas situaciones es agregar un nuevo campo que sea la clave principal, este
nuevo campo puede ser un campo inventado, o puede ser un campo autonumérico que
a cada registro le asigna un número distinto.
Teniendo este nuevo campo como clave
principal, ya tenemos un solo dato que manejar cuando queramos referirnos a una
persona en otra tabla, y ya podemos establecer las propiedades integridad referencial
y actualización en cascada para las relaciones en las que intervenga la tabla AlumnosGuarderia.
Con todo esto nos queda un detalle
y es evitar la duplicidad de registros, es decir no poner dos veces al mismo
alumno en nuestra tabla.
Para esto, en el diseño de la
tabla añadimos un índice compuesto por los campos: DNI de la madre,
FechaNacimiento, y Nombre (que eran los candidatos a formar la clave principal)
y le decimos a Access que este índice ha de tener valores únicos.