Durante mis años como ingeniero he trabajado en unas cuantas compañías de tecnologías de la información y de desarrollo de sistemas de información. Durante este período he trabajado desde un programador "raso" hasta la dirección de proyectos de software y claro está muchas veces he tenido que modelar bases de datos para muchos sistemas.
Ahora que interpreto un papel diferente,esta vez como profesor universitario, una de las asignaturas que imparto es justamente "Bases de datos", para lo cual me he propuesto en fortalecer principalmente las habilidades para el diseño de las bases de datos de mis alumnos. Es justo en una de estas clases donde un alumno plantea la cuestión que es objetivo de este post.
 |
| Image courtesy of suphakit73 - FreeDigitalPhotos.net |
Quizá para muchos esta cuestión tiene poco de cuestión, ya que los mecanismos y reglas que permiten que la información que almacenamos en nuestras bases de datos sean consistentes, permiten dar respuesta a esto, sin embargo, planteada la cuestión aparecieron con ella algunos planteamientos "necios" y es por esto que escribo esta entrada para intentar zanjar la discusión.
Llaves compuestas Vs. Llaves exógenas
Antes de realizar una comparativa entre las 2 es justo explicar que significa cada una.Llaves primarias (Primary Keys):
La llave primara es un atributo o un conjunto de atributos que por si mismos son únicos dentro de un conjunto de representaciones o instancias de una entidad y por ende sirven para identificar de forma univoca dicha representación de cualquier otra.
Un ejemplo de una llave primaria puede ser el número de documento de identificación de una persona puesto que este dato es exclusivo para la persona dueña de él y ninguna otra persona podrá tener un número igual. Si tuviéramos una tabla en una base de datos donde se almacene la información de las personas, cada registro de esta tabla (instancia de la entidad) se diferenciaría de los demás, al menos, porque el número de documento es diferente.
Llaves compuestas:
Como se mencionó anteriormente una llave primaria, o en otras palabras los atributos que identifican de forma univoca una instancia de una entidad de sus semejantes, puede ser la combinación de más de un atributo. Este caso es muy frecuente cuando se crean tablas intermedias debido a una relación "Muchos a muchos" en un modelo entidad relación.
Por ejemplo, Supongamos que es necesario almacenar la nota final de cada alumno para cada una de las asignaturas que ha tomado. En tal caso tendremos lo siguiente:
Para llevar este modelo a una base de datos se requiere una tabla intermedia que relacione el alumno con la materia. Es importante hacer énfasis en que un alumno solo puede tener una nota final para cada materia, esto significa que según la naturaleza de nuestra información la llave natural de esta nueva tabla es la la combinación de las llaves del alumno y de la materia, puesto que un alumno no puede tener más de una nota para la misma materia. Así pues se la nueva tabla tendrá una llave compuesta por las 2 columnas cuya combinación es irrepetible y por tanto identifica de forma univoca cada instancia (registro) de las demás, quedando así:
Como se puede ver, la tabla notas tiene la llave primaria compuesta, de esta forma cada alumno solo podrá tener una nota final por cada asignatura.
Llaves exógenas:
El término exónego hace referencia a que los datos allí almacenados no hacen parte directa de la entidad que van a identificar, es decir, que es un valor obtenido de forma externa a la entidad misma. En otras palabras, es crear un dato que se pretenda irrepetible y asignarlo como llave primaria de una tabla. Esto tiene utilidad cuando no logramos encontrar un atributo o un conjunto de ellos que permita identificar de forma univoca cada instancia de la entidad.
Sin embargo, y es esta la cuestión planteada en clase, algunos diseñadores usan un id (genérico), normalmente un número consecutivo auto-generado, para identificar cada fila o registro de una tabla intermedia como la planteada en el punto inmediatamente anterior (Notas).
Bajo este criterio el modelo quedaría así:
Como se puede ver, la tabla notas tiene la llave primaria exógena, ya que se creo un atributo llamado "id_nota" para guardar un valor arbitrario que identifica cada registro del cruce de un alumno con cada materia para almacenar la nota.
Pero entonces...
Se debe recordar que se definió que un alumno solo puede tener una única nota final por cada materia, por tal motivo quién modele la base de datos no debería permitir que aun alumno tenga más que una nota por cada materia.
Si se usa una llave exógena estaríamos permitiendo de forma implícita que un alumno pueda tener más de una nota para la misma materia, ya que no existe una restricción que impida que la combinación entre alumno y materia se repita y por tanto tendríamos algo así:
Como se puede evidenciar en la columna "id_nota" no hay datos repetidos ya que la restricción de la llave primaria lo impide, sin embargo, se permite que el alumno con documento 10 tenga 2 notas para la materia 5, esto por supuesto es una incongruencia en nuestra información.
Sin embargo, y es esta la cuestión planteada en clase, algunos diseñadores usan un id (genérico), normalmente un número consecutivo auto-generado, para identificar cada fila o registro de una tabla intermedia como la planteada en el punto inmediatamente anterior (Notas).
Bajo este criterio el modelo quedaría así:
Como se puede ver, la tabla notas tiene la llave primaria exógena, ya que se creo un atributo llamado "id_nota" para guardar un valor arbitrario que identifica cada registro del cruce de un alumno con cada materia para almacenar la nota.
Pero entonces...
¿Si tanto llaves compuestas como exógenas permiten identificar de forma univoca cada registro, por cuál nos inclinamos?
Si bien es cierto que las 2 formas permiten identificar de forma univoca cada instancia de las entidades o en otras palabras cada registro de una tabla, es necesario considerar un punto que es irrebatible y que afecta directamente la congruencia y consistencia de nuestros datos. Para explicar de forma clara en que consiste la inconsistencia usemos el mismo ejemplo anterior.Se debe recordar que se definió que un alumno solo puede tener una única nota final por cada materia, por tal motivo quién modele la base de datos no debería permitir que aun alumno tenga más que una nota por cada materia.
Si se usa una llave exógena estaríamos permitiendo de forma implícita que un alumno pueda tener más de una nota para la misma materia, ya que no existe una restricción que impida que la combinación entre alumno y materia se repita y por tanto tendríamos algo así:
Como se puede evidenciar en la columna "id_nota" no hay datos repetidos ya que la restricción de la llave primaria lo impide, sin embargo, se permite que el alumno con documento 10 tenga 2 notas para la materia 5, esto por supuesto es una incongruencia en nuestra información.
Por otro lado, si se usa una llave compuesta esta incongruencia en nuestra información no puede existir ya que la llave natural, es decir lo que no se puede repetir, se está usando explícitamente como llave primaria de la tabla y por tanto tendríamos algo así:
Como se puede evidenciar el alumno 10 aparece más de una vez (una por cada materia), de igual manera la materia, sin embargo la combinación de las dos solo existe una vez ya que la llave primaria compuesta así lo exige.
Claro, algunos dirán que el problema de la incongruencia de la información que permiten las llaves exógenas se pueden solucionar de otras formas, por ejemplo el uso de una llave única (UK) adicional compuesta de las columnas que no se pueden repetir, pero esto no deja de ser una tontería ya para eso se define la UK como PK. Alguno otro dirá que eso lo puede controlar el software, y que puedo decir: POS SI!! igual que una puerta cerrada evita que se entren los ladrones y todo irá bien hasta que alguien se deje una ventana abierta.
Dicho lo anterior, está claro que se debe usar lo que llamo "llave natural", es decir, aquella que es parte propia de la entidad en lugar de un dato exógeno. Esta "filosofía" no solo aplica para las tablas intermedias, sino que también se debería aplicar a cualquier entidad y dejar la fea costumbre de poner un campo llamado "id" a cuanta tabla veamos (Cosas que algunos hacen ya de forma instintiva y casi diría que irracional).
Dedicado a mi amigo J.P.
