2.3 Clave
Es
necesario tener una forma de especificar cómo las entidades dentro de un conjunto
de entidades y las relaciones dentro de un conjunto de relaciones son distinguibles.
Los valores de los atributos de una entidad deben ser tales que permitan identificar
unívocamente a la entidad. Una clave permite identificar un conjunto de atributos
suficiente para distinguir las entidades entre sí. Las claves también ayudan a identificar
unívocamente a las relaciones y así a distinguir las relaciones entre sí.
2.3.1 Conjuntos de entidades
Una
superclave es un conjunto de uno o más atributos que, tomados colectivamente, permiten
identificar de forma única una entidad en el conjunto de entidades. Por ejemplo,
el atributo id-cliente del conjunto de entidades cliente es suficiente para distinguir
una entidad cliente de las otras. Así, id-cliente es una superclave. El
atributo nombre-cliente de cliente no es una superclave, porque varias personas
podrían tener el mismo nombre. Tales superclaves mínimas se llaman claves
candidatas.
Una
clave (primaria, candidata y superclave) es una propiedad del conjunto de entidades.
Dos entidades individuales en el conjunto no pueden tener el mismo valor en sus
atributos clave al mismo tiempo. La designación de una clave representa una
restricción en el desarrollo del mundo real que se modela. La clave primaria se
debería elegir de manera que sus atributos nunca cambien. Por ejemplo, el campo
dirección de una persona no debería formar parte de una clave primaria, porque probablemente
cambiará.
2.3.2 Conjuntos de relaciones.
La
clave primaria de un conjunto de entidades permite distinguir entre las
diferentes entidades del conjunto. Se necesita un mecanismo similar para
distinguir entre las diferentes relaciones de un conjunto de relaciones. Sea R
un conjunto de relaciones que involucra los conjuntos de entidades E1, E2,…,
En. Sea clave-primaria (Ei) el conjunto de atributos que forma la clave
primaria para el conjunto de entidades Ei.
La
composición de la clave primaria para un conjunto de relaciones depende de la estructura
de los atributos asociados al conjunto de relaciones R.
Si
el conjunto de relaciones R no tiene atributos asociados, entonces el conjunto
de atributos: clave-primaria(E1) ∪
clave-primaria(E2) ∪… ∪ clave-primaria(En) describe
una relación individual en el conjunto R.
Si
el conjunto de relaciones R tiene atributos a1, a2,…, am asociados a él,
entonces el conjunto de atributos clave-primaria(E1) ∪ clave-primaria(E2) ∪… ∪ clave- primaria(En) ∪ {a1, a2,…,am} describe una
relación individual en el conjunto R. En el caso de que los nombres de
atributos de las claves primarias no sean únicos en todos los conjuntos de
entidades, los atributos se renombran para distinguirlos; el nombre del
conjunto de entidades combinado con el atributo formaría un nombre único. La
estructura de la clave primaria para el conjunto de relaciones depende de la
correspondencia de cardinalidades asociada al conjunto de relaciones. Para relaciones
uno a uno se puede usar cualquier clave primaria. Para las relaciones no binarias,
si no hay restricciones de cardinalidad, entonces la superclave es la única clave
candidata, y se elige como clave primaria. La elección de la clave primaria es más
complicada si aparecen restricciones de cardinalidad.
2.4 Cuestiones de diseño
Los conceptos entre
entidades y relaciones pueden definirse de diferentes formas debido a la imprecisión
en la percepción de sus conceptos. A continuación se exploran las cuestiones básicas
de diseño de un esquema de base de datos E-R.
2.4.1 Uso de entidades o atributos
Tomaremos como ejemplo el
conjunto de entidades empleado con
sus respectivos atributos nombre-empleado
y número-teléfono definiremos la
manera mas adecuada de usar ya sea entidades separadas o atributos del mismo
conjunto de entidades.
Así podemos deducir que el
conjunto de entidades empleado queda
con el atributo nombre-empleado, el
conjunto de entidades teléfono con
los atributos número-teléfono y ubicación (del teléfono) y la relación empleado-teléfono que establece la relación
entre empleados y los teléfonos que tienen.
Por la parte de la entidad teléfono el echo de ser una identidad por si misma con sus
atributos propios número-teléfono y ubicación nos permite facilitar el
modelado de la información que puede almacenar permitiendo así que a un
empleado le podamos asignar uno, varios o ningún teléfono a través del atributo
número-teléfono que marcaremos como
multivalorado.
Caso contrario para la
entidad empleado resulta
inconveniente definir a su atributo nombre-empleado
como una entidad por si misma puesto que el empleado solo tiene un nombre
que lo identifica, así pues es adecuado tener a nombre-empleado simplemente como atributo de la entidad empleado.
De esto podemos concluir que la constitución de
un conjunto de entidades y un atributo dependerán puntualmente de las
necesidades en el mundo real para las que se esté modelando y la semántica asociada
al atributo en cuestión.
Un error común es usar la
clave primaria de un conjunto de entidades como un atributo de otro conjunto de
entidades, ya que lo correcto en ves de esto es usar una relación que
especifique la interacción entre ambos conjuntos de entidades.
Otro error similar es
designar a los atributos de la clave primaria de los conjuntos de entidades
relacionados como atributos del conjunto de relaciones debido a que los
atributos de la clave primaria van implícitos en la relación.
2.4.2 Uso de conjuntos de entidades o conjuntos relacionales
No siempre es claro cual de
estos conjuntos es más conveniente de utilizar. Partiremos del ejemplo de que
un préstamo debe modelarse como entidad. Alternativo a esto planteemos la
alternativa de modelar préstamo no como entidad sino como una relación entre
clientes y sucursales con los atributos descriptivos número-préstamo e importe y
cada préstamo será la relación entre un cliente y una sucursal.
La alternativa es
satisfactoria si cada préstamo se relaciona solo con un cliente y una sucursal
pero resulta problemático si varios clientes comparten un préstamo. Para esto implicaría
que para cada cliente debiéramos de aplicarles el mismo valor en los atributos número-préstamo e importe en su relación con la sucursal.
Esto representa 2 problemas principales;
el primero que los mismos datos deben ser almacenados varias veces
desperdiciando espacio de almacenamiento; y segundo que la actualización de
datos nos da el riesgo de que dichos valores se modifiquen siendo que debieran tener
el mismo valor.
En este caso entonces
resulta conveniente aplicar la teoría de
la normalización para evitar los inconvenientes ya planteados de dicha
alternativa.
Meramente como una posible guía
para determinar la conveniencia de usar conjuntos de entidades o de relaciones
es designar un conjunto de relaciones para describir una acción que ocurre
entre entidades; este mismo enfoque resulta útil para discernir entre si un
atributo es mas conveniente si se usa como relación o no.
2.4.3. Conjuntos de relaciones binarias o n-arias
Las relaciones en las bases de datos son generalmente binarias. Algunas relaciones que parecen no ser binarias podrían ser representadas de una mejor manera realizando varias relaciones binarias. Por ejemplo, uno podría crear una relación ternaria padres, que relaciona un hijo con su padre y su madre. De esta manera, dicha relación podría ser representada por dos relaciones binarias padre y madre, relacionando un hijo con su padre y su madre por separado.
Siempre es posible remplazar un conjunto de relaciones no binarias (n-aria, para n > 2) por un número de diferentes conjuntos de relaciones binarias.
Para simplificar mas lo son las relaciones binarias, considérese el conjunto de relaciones abstracto R, ternario (n = 3), y los conjuntos de entidades A, B, y C. Se sustituye el conjunto de relaciones R por un conjunto de entidades E y se crean tres conjuntos de relaciones:
- RA, relacionando E y A
- RB, relacionando E y B
- RC, relacionando E y C
Para cada relación (ai,bi,ci) del conjunto de relaciones R, se crea una nueva entidad ei en el conjunto de entidades E. Entonces, en cada uno de los tres nuevos conjuntos de relaciones, se inserta un nuevo miembro como sigue:
- (ei,ai) en RA
- (ei,bi) en RB
- (ei,ci) en RC
• Un atributo de identificación puede haber sido creado para el conjunto de entidades para representar el conjunto de relaciones. Este atributo, con los conjuntos de relaciones extra necesarios, incrementa la complejidad del diseño y los requisitos de almacenamiento.
• Un conjunto de relaciones n-arias muestra que varias entidades participan en una relación simple.
• Podría no haber una forma de traducir restricciones en la relación ternaria en restricciones sobre relaciones binarias. Por ejemplo, considérese una restricción que dice que R es varios a uno de A, B a C; es decir, cada par de entidades de A y B se asocia con a lo sumo una entidad C. Esta restricción no se puede expresar usando restricciones de cardinalidad sobre los conjuntos de relaciones RA, RB y RC.
• Un conjunto de relaciones n-arias muestra que varias entidades participan en una relación simple.
• Podría no haber una forma de traducir restricciones en la relación ternaria en restricciones sobre relaciones binarias. Por ejemplo, considérese una restricción que dice que R es varios a uno de A, B a C; es decir, cada par de entidades de A y B se asocia con a lo sumo una entidad C. Esta restricción no se puede expresar usando restricciones de cardinalidad sobre los conjuntos de relaciones RA, RB y RC.
Un conjunto de relaciones se puede dividir en relaciones binarias creando nuevos conjuntos de entidades sin embargo, no sería muy natural.
2.4.4. Ubicación de los atributos de las relaciones
La razón de cardinalidad de una relación puede afectar a los atributos de una relación. Los atributos de los conjuntos de relaciones uno a uno o uno a varios pueden estar asociados con uno de los conjuntos de entidades participantes, en lugar de con el conjunto de relaciones.
Cada entidad participa en una relación con a lo sumo un ejemplar. Los atributos de un conjunto de relaciones uno a varios se pueden colocar sólo en el conjunto de entidades de la parte «varios» de la relación. Para los conjuntos de entidades uno a uno, los atributos de la relación se pueden asociar con cualquiera de las entidades participantes. La decisión de diseño de dónde colocar los atributos descriptivos en tales casos (como un atributo de la relación o de la entidad) podría reflejar las características de la empresa que se modela.
El diseñador puede mantener un atributo para expresar de manera explicita que ocurre un acceso en el punto de interacción entre un conjunto de entidades.
La elección de la colocación de los atributo es más clara para los conjuntos de relaciones varios a varios.
Cuando un atributo se determina mediante la combinación de los conjuntos de entidades participantes, en lugar de por cada entidad por separado, ese atributo debe estar asociado con el conjunto de relaciones varios a varios.
