Transformación del Modelo E/R al Modelo Relacional
En el diseño de base de datos lo más difícil y sujeto a la interpretación del
desarrollador es construir un buen modelo entidad-relación que
represente fielmente el problema. Sin embargo, la transformación de este
al modelo relacional es casi mecánico y se basa en unas pocas reglas que
ahora veremos.
Transformación de entidades débiles
Todas las entidades del modelo E/R se convierten en tablas en el modelo
relacional. Las entidades débiles también se transforman en tablas pero su
clave primaria se compone de la unión de su clave propia con la clave
primaria de la entidad fuerte a la que pertenece.
TREN
PK idTren
Peso
Longitud
Tipo
VelocidadMax
Transformación de las relaciones (1:1)
- Mismo Primary Key
Si las dos identidades tienen la misma clave, se transforman en única
tabla que contendrá este identificador como clave primaria y los atributos
de ambas entidades.
CONDUCTOR
- Diferente Primary Key
Cuando tienen diferente clave, cada entidad se convierte en una tabla con
su identificador como clave primaria y como clave ajena el identificador de
la otra entidad.
- Cardinalidad Mínima Cero
Si alguna de las entidades participa con cardinalidad mínima igual a cero
se añade una tabla intermedia cuyo identificador se forma por las claves
primarias de las otras dos tablas y se le añaden los atributos de la relación
cuando los haya.
Transformación de relaciones (1:N) o (N:1)
- Cardinalidad Mínima Uno
Si en la relación la entidad que participa con cardinalidad máxima igual a
uno, lo hace también con cardinalidad mínima igual a uno, cada entidad se
transforma en una tabla con su respectiva clave primaria. La tabla, que
participa con caridnalidad N, tendrá como clave ajena la clave primaria de
la otra tabla, así como los atributos de la relación.
- Cardinalidad Mínima Cero
En este caso cada entidad se transforma en una tabla con su respectiva
clave primaria. Se añade otra tabla que representa la relación, cuya clave
primaria será la clave primaria de la tabla con cardinalidad N. Y tendrá
como clave ajena la clave primaria de la tabla con cardinalidad uno.
Transformación de las relaciones (N:M)
Cada entidad se transforma en una tabla con su respectiva clave primaria.
Se añade una tabla para la relación con los atributos de esta y como clave
primaria la composición de las claves de las otras entidades.
Transformación de las relaciones N-arias
En este tipo de relaciones intervienen 3 o N entidades.
Al transformarlo al modelo relacional podemos separar cada una de las
relaciones y tratarlas por separado.
De este modo, podemos aplicar las relaciones (1:1), (1:N) o (N:M) según
los casos como hemos visto anteriormente. En el ejemplo que nos ocupa
tendríamos las siguientes tres tablas.
Transformación de relaciones reflexivas
En este tipo de relaciones hay que suponer que se trata de una relación
binaria normal en la que las dos entidades son iguales. A partir de aquí,
aplicar las reglas de las relaciones (1:1), (1:N) o (N:M).
Tener en cuenta que sólo será necesaria una tabla “Persona”, pues los
datos estarían guardados ahí. La clave primaria de “Persona_CasadaCon”
incluiría dos instancias de la clave primaria de “Persona”.
Jerarquías
La descomposición de una entidad en varios subtipos es una necesidad
muy habitual en el diseño de bases de datos. Se denomina “supertipo” a
la entidad que se va a descomponer y se denomina “subtipo” a las
entidades en las que se descompone el “supertipo”. Juntos o por
separado, los supertipos y subtipos pueden participar en relaciones con
otras entidades de la base de datos.
COCHE
ES_UN TIPO
NUEVO VIEJO
En el mundo real se pueden identificar varias jerarquías de entidades, en
las que se muestra gráficamente el concepto “es-un”, por ejemplo
“Nuevo” y “Viejo” es-un “Coche”, es decir “Coche”, que tendrá atributos
comunes, se descompone en los subtipos “Nuevo” y “Viejo” que tendrán
sus propios atributos. Asimismo, la jerarquía puede tener sus propios
atributos “discriminantes” (p.e. Tipo de coche), que permitirán distinguir
una característica del supertipo, desarrollada en un subtipo u otro.
Otra característica muy importante de esta clase de interrelaciones es la
herencia de los atributos ya que, en principio, todo atributo del supertipo
pasa a ser un atributo de los subtipos.
La representación gráfica de las jerarquías se realiza, como se ha mostrado
en el ejemplo anterior, mediante un triángulo invertido, con la base
paralela al rectángulo que representa el supertipo y conectando a éste y a
los subtipos. Si la división en subtipos viene determinada en función de los
valores de un “atributo discriminante”, éste se representará asociado al
triángulo que representa la relación.
En el triángulo se representará una letra u otra en función de lo siguiente:
1) Jerarquía Parcial: Algunos datos incluidos en el supertipo no aparecen
en ningún subtipo, por existir más opciones (subtipos) de las hemos
considerado en el diseño de nuestra base de datos.
a) d, si los subtipos son disjuntos: Un dato del supertipo sólo puede
aparecer en un único subtipo (Vehículo es-un Turismo o Camión
d porque sólo puede ser un subtipo).
b) O, si los subtipos pueden solaparse (no disjuntos): Un dato del
supertipo puede aparecer en más de un subtipo (Persona es-un
Estudia o Trabaja O porque puede ser un estudiante que además
trabaje).
2) Jerarquía Total: Todos los datos incluidos en el supertipo tienen que
aparecer en algún subtipo, por no existir más opciones. Es obligatorio
el uso del “atributo discriminante”, pues todos los datos han de tener
correspondencia en algún subtipo.
a) La presencia de una jerarquía total se representa con una doble
línea entre el supertipo y el triángulo.
3) Uniones o categorías: En este caso no se divide el supertipo en
subtipos, sino que se define un subtipo como la unión de dos
supertipos.
a) U el caso de uniones, llamadas también categorías: Hay varios
supertipos que se unen en un solo subtipo (Persona_Física y
Persona_Jurídica es-un Declarante_IRPF U porque a la hora de
hacer la declaración del IRPF se puede ser una persona -física- o una
empresa -persona jurídica-).
Transformación de la jerarquía al Modelo Relacional
Existen varias posibilidades que deben ser evaluadas por el diseñador a fin
de elegir la que mejor se ajuste a los requisitos. Las opciones para tratar la
transformación de la jerarquía al modelo lógico de datos son:
Opción a: Consiste en crear una tabla para el supertipo que tenga
de clave primaria su identificador y una tabla para cada uno de los
subtipos que tengan el identificador del supertipo como clave ajena.
Esta solución es apropiada cuando los subtipos tienen muchos
atributos distintos y se quieren conservar los atributos comunes en
una tabla sola. También se deben implantar las restricciones y
aserciones adecuadas. Es la solución que mejor conserva la
semántica.
Opción b: Se crea una tabla para cada subtipo, los atributos
comunes aparecen en todos los subtipos y la clave primaria para
cada tabla es el identificador del supertipo.
Esta opción mejora la eficiencia en los accesos a todos los atributos
de un subtipo, sean los comunes al supertipo o los específicos.
Será necesario el control de la integridad de los datos guardados
pues se pueden dar redundancias.
Opción c: Agrupar en una sola tabla todos los atributos de la
entidad supertipo y de los subtipos. La clave primaria de esta tabla
es el identificador de la entidad. Se añade un atributo que indique a
qué subtipo pertenece cada ocurrencia (el atributo discriminante de
la jerarquía). Esta solución puede aplicarse cuando los subtipos se
diferencien en pocos atributos y las relaciones entre los subtipos y
otras entidades sean las mismas. Para el caso de que la jerarquía
sea total, el atributo discriminante no podrá́ tomar valor nulo (ya
que toda ocurrencia pertenece a alguna de las entidades subtipo).
