Tarea III: Resumen (Claves y cuestiones de diseño)

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

Si el conjunto de relaciones R tiene atributos, éstos son asignados al conjunto de entidades E; de esta manera se crea un atributo de identificación especial para E.
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

De manera conceptual se puede restringir el modelo E-R para incluir sólo conjuntos de relaciones binarias pero esta restricción no es muy recomendable.

• 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 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.