3. Diseño lógico: la transformación del modelo ER al modelo relacional
3. Diseño lógico: la transformación del modelo ER al modelo relacional Dataprix 30 September, 2009 - 09:44En este apartado trataremos el diseño lógico de una base de datos relacional. Partiremos del resultado de la etapa del diseño conceptual expresado mediante el modelo ER y veremos cómo se puede transformar en una estructura de datos del modelo relacional.
3.1. Introducción a la transformación de entidades e interrelaciones
3.1. Introducción a la transformación de entidades e interrelaciones Dataprix 30 September, 2009 - 09:52Los elementos básicos del modelo ER son las entidades y las interre-
laciones:
a) Las entidades, cuando se traducen al modelo relacional, originan re-
laciones.
b) Las interrelaciones, en cambio, cuando se transforman, pueden dar
lugar a claves foráneas de alguna relación ya obtenida o pueden dar
lugar a una nueva relación.
Los elementos básicos del modelo ER son las entidades y las interrelaciones:
a) Las entidades, cuando se traducen al modelo relacional, originan relaciones.
b) Las interrelaciones, en cambio, cuando se transforman, pueden dar lugar a claves foráneas de alguna relación ya obtenida o pueden dar lugar a una nueva relación.En el caso de las interrelaciones, es necesario tener en cuenta su grado y su conectividad para poder decidir cuál es la transformación adecuada:
1) Las interrelaciones binarias 1:1 y 1:N dan lugar a claves foráneas.
2) Las interrelaciones binarias M:N y todas las n-arias se traducen en nuevas relaciones.
| Encontraréis la tabla de las transformaciones en el subapartado 3.10. de esta unidad; en el subapartado 3.11. veremos el ejemplo de aplicación. |
En los subapartados siguientes explicaremos de forma más concreta las transformaciones necesarias para obtener un esquema relacional a partir de un modelo ER. Más adelante proporcionamos una tabla que resume los aspectos más importantes de cada una de las transformaciones para dar una visión global sobre ello. Finalmente, describimos su aplicación en un ejemplo.
3.2. Transformación de entidades
3.2. Transformación de entidades Dataprix 30 September, 2009 - 10:03Empezaremos el proceso transformando todas las entidades de un modelo ER adecuadamente. Cada entidad del modelo ER se transforma en una relación del modelo relacional. Los atributos de la entidad serán atributos de la relación y, de forma análoga, la clave primaria de la entidad será la clave primaria de la relación.Ejemplo de transformación de una entidad
Según esto, la entidad de la figura del margen se transforma en la relación que tenemos a continuación:
EMPLEADO(DNI, NSS, nombre, apellido, sueldo)
Una vez transformadas todas las entidades en relaciones, es preciso transformar todas las interrelaciones en las que intervienen estas entidades.
| Veremos las transformaciones de las interrelaciones binarias en el siguiente subapartado. |
Si una entidad interviene en alguna interrelación binaria 1:1 o 1:N, puede ser necesario añadir nuevos atributos a la relación obtenida a partir de la entidad. Estos atributos formarán claves foráneas de la relación.
3.3. Transformacion de interrelaciones binarias
3.3. Transformacion de interrelaciones binarias Dataprix 30 September, 2009 - 10:31Para transformar una interrelación binaria es necesario tener en cuenta su conectividad, y si las entidades son obligatorias u opcionales en la interrelación.
3.3.1. Conectividad 1:1
3.3.1. Conectividad 1:1 Dataprix 30 September, 2009 - 10:52Nuestro punto de partida es que las entidades que intervienen en la interrelación 1:1 ya se han transformado en relaciones con sus correspondientes atributos.
Entonces sólo será necesario añadir a cualquiera de estas dos relaciones
una clave foránea que referencie a la otra relación.Ejemplo de transformación de una interrelación binaria 1:1
Para la interrelación de la figura anterior, tenemos dos opciones de transformación:
• Primera opción:
• Segunda opción:
Ambas transformaciones nos permiten saber en qué ciudad hay una delegación, y qué delegación tiene una ciudad. De este modo, reflejan correctamente el significado de la interrelación situación del modelo ER.
En la primera transformación, dado que una delegación está situada en una sola ciudad, el atributo nombre-ciudad tiene un único valor para cada valor de la clave primaria {nombre-del}. Observad que, si pudiese tener varios valores, la solución no sería correcta según la teoría relacional.
En la segunda transformación, teniendo en cuenta que una ciudad tiene una sola delegación, el atributo nombre-del también toma un solo valor para cada valor de la clave primaria {nombre-ciudad}.
También es necesario tener en cuenta que, en las dos transformaciones, la clave foránea que se les añade se convierte en una clave alternativa de la relación porque no admite valores repetidos. Por ejemplo, en la segunda transformación no puede haber más de una ciudad con la misma delegación; de este modo, nombre-del debe ser diferente para todas las tuplas de CIUDAD.
3.3.2. Conectividad 1:N
3.3.2. Conectividad 1:N Dataprix 30 September, 2009 - 10:58
Partimos del hecho de que las entidades que intervienen en la interrelación 1:N ya se han trasformado en relaciones con sus correspondientes atributos. En este caso sólo es necesario añadir en la relación correspondiente a la entidad del lado N, una clave foránea que referencie la otra relación.Ejemplo de transformación de una interrelación binaria 1:N
La interrelación de la figura anterior se transforma en:
DESPACHO(desp, ...)
EMPLEADO(emp, ..., desp)
donde {desp}referencia DESPACHOEsta solución nos permite saber en qué despacho está asignado cada empleado, y también nos permite consultar, para cada despacho, qué empleados hay. Es decir, refleja correctamente el significado de la interrelación asignación.
Teniendo en cuenta que un empleado está asignado a un único despacho, el atributo desp tiene un valor único para cada valor de la clave primaria {emp}. Si hubiésemos puesto la clave foránea {emp} en la relación DESPACHO, la solución habría sido incorrecta, porque emp habría tomado varios valores, uno para cada uno de los distintos empleados que pueden estar asignados a un despacho.
3.3.3. Conectividad M:N
3.3.3. Conectividad M:N Dataprix 30 September, 2009 - 11:05Una interrelación M:N se transforma en una relación. Su clave primaria
estará formada por los atributos de la clave primaria de las dos entidades interrelacionadas. Los atributos de la interrelación serán atributos de la nueva relación.
Ejemplo de transformación de una interrelación binaria M:N.png)
La interrelación de la figura anterior se transforma en:
ESTUDIANTE(est, ...)
ASIGNATURA(asig, ...)
EVALUACIÓN(est,asig, nota)
donde {est} referencia ESTUDIANTE
y {asig} referencia ASIGNATURAObservad que la clave de evaluacion debe constar tanto de la clave de estudiante como de la clave de asignatura para identificar completamente la relación.
La solución que hemos presentado refleja correctamente la interrelación evaluación y su atributo nota. Permite saber, para cada estudiante, qué notas obtiene de las varias asignaturas y, para cada asignatura, qué notas tienen los diferentes estudiantes de aquella asignatura.
En el caso M:N no podemos utilizar claves foráneas para transformar la interrelación, porque obtendríamos atributos que necesitarían tomar varios valores, y esto no se permite en el modelo relacional.
3.3.4. Influencia de la pendencia de existencia en la transformacion de las interrelaciones binarias
3.3.4. Influencia de la pendencia de existencia en la transformacion de las interrelaciones binarias Dataprix 30 September, 2009 - 11:14La dependencia de existencia, o más concretamente, el hecho de que alguna de las entidades sea opcional en una interrelación se debe tener en cuenta al hacer la transformación de algunas relaciones binarias 1:1 y 1:N.
Si una de las entidades es opcional en la interrelación, y la transformación ha consistido en poner una clave foránea en la relación que corresponde a la otra entidad, entonces esta clave foránea puede tomar valores nulos.Ejemplo de transformación de una entidad opcional en la interrelación
En el ejemplo siguiente, la entidad departamento es opcional en dirección y, por lo tanto, puede haber empleados que no sean directores de ningún departamento.
En principio, hay dos opciones de transformación:
• Primera opción:
DEPARTAMENTO(dep, ..., emp-dir)
donde {emp-dir} referencia EMPLEADO
EMPLEADO(emp, ...)• Segunda opción:
DEPARTAMENTO(dep, ...)
EMPLEADO(emp, ..., dep)
donde {dep} referencia DEPARTAMENTO
y dep puede tomar valores nulosLa segunda transformación da lugar a una clave foránea que puede tomar valores nulos (porque puede haber empleados que no son directores de ningún departamento). Entonces será preferible la primera transformación, porque no provoca la aparición de valores nulos en la clave foránea y, de este modo, nos ahorra espacio de almacenamiento.
En las interrelaciones 1:N, el hecho de que la entidad del lado 1 sea opcional también provoca que la clave foránea de la transformación pueda tener valores nulos. En este caso, sin embargo, no se pueden evitar estos valores nulos porque hay una única transformación posible.
3.4. Transformacion de interrelaciones ternarias
3.4. Transformacion de interrelaciones ternarias Dataprix 30 September, 2009 - 11:19La transformación de las interrelaciones ternarias presenta similitudes importantes con la transformación de las binarias M:N. No es posible representar la interrelación mediante claves foráneas, sino que es necesario usar una nueva relación. Para que la nueva relación refleje toda la información que modeliza la interrelación, es necesario que contenga las claves primarias de las tres entidades interrelacionadas y los atributos de la interrelación.
Así pues, la transformación de una interrelación ternaria siempre da lugar a una nueva relación, que tendrá como atributos las claves primarias de las tres entidades interrelacionadas y todos los atributos que tenga la interrelación. La clave primaria de la nueva relación depende de la conectividad de la interrelación.A continuación analizaremos cuál debe ser la clave primaria de la nueva relación según la conectividad. Empezaremos por el caso M:N:P y acabaremos con el caso 1:1:1.
3.4.1. Conectividad M:N:P
3.4.1. Conectividad M:N:P Dataprix 30 September, 2009 - 11:26Cuando la conectividad de la interrelación es M:N:P, la relación que se obtiene de su transformación tiene como clave primaria todos los atributos que forman las claves primarias de las tres entidades interrelacionadas.Ejemplo de transformación de una interrelación ternaria M:N:P
Analizaremos la transformación con un ejemplo:
La interrelación anterior se transforma en:
ESTUDIANTE(est, ...)
ASIGNATURA(asig, ...)
SEMESTRE(sem, ...)
EVALUACIÓN-SEMESTRAL(est, asig, sem, nota)
donde {est} referencia ESTUDIANTE,
{asig} referencia ASIGNATURA
y {sem} referencia SEMESTREPara identificar completamente la relación, la clave debe constar de la clave de estudiante, de la clave de asignatura y de la clave de semestre. Si nos faltase una de las tres, la clave de la relación podría tener valores repetidos. Consideremos, por ejemplo, que no tuviésemos la clave de semestre. Dado que semestre está conectada con “muchos” en la interrelación, puede haber estudiantes que han sido evaluados de una misma asignatura en más de un semestre. Entonces, para estos casos habría valores repetidos en la clave de la relación EVALUACION-SEMESTRAL.
Observad que, del mismo modo que es necesaria la clave de semestre, también lo son la de estudiante y la de asignatura.
3.4.2. Conectividad M:N:1
3.4.2. Conectividad M:N:1 Dataprix 30 September, 2009 - 11:33Cuando la conectividad de la interrelación es M:N:1, la relación que se obtiene de su transformación tiene como clave primaria todos los atributos que forman las claves primarias de las dos entidades de los lados de la interrelación etiquetados con M y con N.Ejemplo de transformación de una interrelación ternaria M:N:1
Lo ilustraremos con un ejemplo:
Esta interrelación refleja los destinos que se dan a los maestros de escuela en los diferentes cursos. El 1 que figura en el lado de escuela significa que un maestro no puede ser destinado a más de una escuela en un mismo curso. El ejemplo de la figura se transforma en:
MAESTRO(código-maestro, ...)
CURSO(código-curso, ...)
ESCUELA(código-esc, ...)
DESTINO(código-maestro, código-curso, código-esc)
donde {código-maestro} referencia MAESTRO
{código-curso} referencia CURSO
y {código-esc} referencia ESCUELANo es necesario que la clave incluya código-esc para identificar completamente la relación. Si se fijan un maestro y un curso, no puede haber más de una escuela de destino y, por lo tanto, no habrá claves repetidas.
3.4.3. Conectividad N:1:1
3.4.3. Conectividad N:1:1 Dataprix 30 September, 2009 - 11:55Cuando la conectividad de la interrelación es N:1:1, la relación que se consigue de su transformación tiene como clave primaria los atributos que forman la clave primaria de la entidad del lado N y los atributos que
forman la clave primaria de cualquiera de las dos entidades que están conectadas con 1.Así pues, hay dos posibles claves para la relación que se obtiene. Son dos claves candidatas entre las cuales el diseñador deberá escoger la primaria.
Ejemplo de transformación de una interrelación ternaria N:1:1
Veamos un ejemplo de ello:
1) Una posible transformación es la siguiente:
HORA-SEMANAL(código-hora, ...)
AULA(código-aula, ...)
ASIGNATURA(asig, ...)
CLASE (código-hora, código-aula, asig, duración)
donde {código-hora} referencia HORA-SEMANAL,
{código-aula} referencia AULA
y {asig} referencia ASIGNATURAEn este caso, la clave, a pesar de no incluir el atributo asig, identifica completamente la relación porque para una hora-semanal y un aula determinadas hay una única asignatura de la que se hace clase a esa hora y en esa aula.
2) La segunda transformación posible es esta otra:
HORA-SEMANAL(código-hora, ...)
AULA(código-aula, ...)
ASIGNATURA(asig, ...)
CLASE (código-hora, código-aula, asig, duración)
donde {código-hora} referencia HORA-SEMANAL,
{código-aula} referencia AULA
y {asig} referencia ASIGNATURAAhora la clave incluye el atributo asig y, en cambio, no incluye el atributo código-aula. La relación también queda completamente identificada porque, para una asignatura y hora-semanal determinadas, de aquella asignatura se da clase en una sola aula a aquella hora.
3.4.4. Conectividad 1:1:1
3.4.4. Conectividad 1:1:1 Dataprix 30 September, 2009 - 12:07Cuando la conectividad de la interrelación es 1:1:1, la relación que se obtiene de su transformación tiene como clave primaria los atributos que forman la clave primaria de dos entidades cualesquiera de las tres interrelacionadas.Así pues, hay tres claves candidatas para la relación.
Ejemplo de transformación de una interrelación ternaria 1:1:1
Veamos un ejemplo de ello:
| Hemos considerado que ... |
| ... , si dos estudiantes presentan un mismo proyecto de fin de carrera, el tribunal será necesariamente diferente. |
Esta interrelación registra información de defensas de proyectos de fin de carrera. Intervienen en ella el estudiante que presenta el proyecto, el proyecto presentado y el tribunal evaluador.
La transformación del ejemplo anterior se muestra a continuación:
TRIBUNAL(trib, ...)
ESTUDIANTE(est, ...)
PROYECTO-FIN-CARRERA(pro, ...)Para la nueva relación DEFENSA, tenemos las tres posibilidades siguientes:
• Primera opción:
DEFENSA(trib, est, pro, fecha-defensa)
donde {trib} referencia TRIBUNAL,
{est} referencia ESTUDIANTE
y {pro} referencia PROYECTO-FIN-CARRERA• Segunda opción:
DEFENSA(trib, pro, est, fecha-defensa)
donde {trib} referencia TRIBUNAL,
{est} referencia ESTUDIANTE
y {pro} referencia PROYECTO-FIN-CARRERA• Tercera opción:
DEFENSA(est, pro, trib, fecha-defensa)
donde {trib} referencia TRIBUNAL,
{est} referencia ESTUDIANTE
y {pro} referencia PROYECTO-FIN-CARRERAEn los tres casos, es posible comprobar que la clave identifica completamente la relación si se tiene en cuenta la conectividad de la interrelación defensa.
3.5. Transformacion de interrelaciones n-arias
3.5. Transformacion de interrelaciones n-arias Dataprix 30 September, 2009 - 14:26La transformación de las interrelaciones n-arias se puede ver como una generalización de lo que hemos explicado para las ternarias.
En todos los casos, la transformación de una interrelación n-aria consistirá en la obtención de una nueva relación que contiene todos los atributos que forman las claves primarias de las n entidades interrelacionadas y todos los atributos de la interrelación.Podemos distinguir los casos siguientes:
a) Si todas las entidades están conectadas con “muchos”, la clave primaria de la nueva relación estará formada por todos los atributos que forman las claves de las n entidades interrelacionadas.
b) Si una o más entidades están conectadas con “uno”, la clave primaria de la nueva relación estará formada por las claves de n – 1 de las entidades interrelacionadas, con la condición de que la entidad, cuya clave no se ha incluido, debe ser una de las que está conectada con “uno”.
3.6. Transformacion de interrelaciones
3.6. Transformacion de interrelaciones Dataprix 30 September, 2009 - 14:43Las transformaciones de las interrelaciones recursivas son similares a las que hemos visto para el resto de las interrelaciones.
De este modo, si una interrelación recursiva tiene conectividad 1:1 o 1:N, da lugar a una clave foránea, y si tiene conectividad M:N o es n-aria, origina una nueva relación.Mostraremos la transformación de algunos ejemplos concretos de interrelaciones recursivas para ilustrar los detalles de la afirmación anterior.
Ejemplo de transformación de una interrelación recursiva binaria 1:1
La interrelación de la figura anterior es recursiva, binaria y tiene conectividad 1:1. Las interrelaciones 1:1 originan una clave foránea que se pone en la relación correspondiente a una de las entidades interrelacionadas. En nuestro ejemplo, sólo hay una entidad interrelacionada, la entidad persona. Entonces, la clave foránea deberá estar en la relación PERSONA. Esta clave foránea deberá referenciar a la misma relación para que refleje una interrelación entre una ocurrencia de persona y otra ocurrencia de persona. Así, obtendremos:
PERSONA (código-per, ..., código-conyuge)
donde {código-conyuge} referencia PERSONA
y código-conyuge admite valores nulosLa clave foránea {código-conyuge} referencia la relación PERSONA a la que pertenece.
Conviene tener en cuenta que, en casos como éste, los atributos de la clave foránea no pueden tener los mismos nombres que los atributos de la clave primaria que referencian porque, según la teoría relacional, una relación no puede tener nombres de atributos repetidos.
Ejemplo de transformación de una interrelación recursiva M:N
Veamos a continuación un ejemplo en el que interviene una interrelación recursiva y con conectividad M:N.
Las interrelaciones M:N se traducen en nuevas relaciones que tienen como clave primaria las claves de las entidades interrelacionadas.
En nuestro ejemplo, la interrelación vincula ocurrencias de persona con otras ocurrencias de persona. En este caso, la clave primaria de la nueva relación estará formada por la clave de la entidad persona dos veces. Convendrá dar nombres diferentes a todos los atributos de la nueva relación. De este modo, la traducción del ejemplo anterior será:
PERSONA (código-per, ...)
AMISTAD (código-per, código-per-amiga)
donde {código-per} referencia PERSONA
y {código-per-amiga} referencia PERSONAEjemplo de transformación de una interrelación recursiva n-aria N:1:1
Finalmente, analizaremos un ejemplo en el que la interrelación recursiva es n-aria:
La anterior interrelación boda es recursiva, ternaria y tiene conectividad N:1:1. Las interrelaciones N:1:1 originan siempre una nueva relación que contiene, además de los atributos de la interrelación, todos los atributos que forman la clave primaria de las tres entidades interrelacionadas.
En nuestro ejemplo, la interrelación asocia ocurrencias de persona con otras ocurrencias de persona y con ocurrencias de fecha. Entonces, la clave de persona tendrá que figurar dos veces en la nueva relación, y la clave de fecha, solo una.
La clave primaria de la relación que se obtiene para interrelaciones N:1:1 está formada por la clave de la entidad del lado N y por la clave de una de las entidades de los lados 1.
En nuestro ejemplo, en los dos lados 1 de la interrelación tenemos la misma entidad: persona. La clave primaria estará formada por la clave de la entidad fecha y por la clave de la entidad persona.
Según todo esto, la transformación será la siguiente:
PERSONA(código-per, ...)
FECHA(fecha-bod, ...)
BODA (fecha-bod, código-per, código-conyuge)
donde {fecha-bod} referencia FECHA,
{código-per} referencia PERSONA
y {código-conyuge} referencia PERSONA3.7. Transformacion de entidades debiles
3.7. Transformacion de entidades debiles Dataprix 30 September, 2009 - 14:49Las entidades débiles se traducen al modelo relacional igual que el resto de entidades, con una pequeña diferencia. Estas entidades siempre están en el lado N de una interrelación 1:N que completa su identificación.
Así pues, la clave foránea originada por esta interrelación 1:N debe formar parte de la clave primaria de la relación correspondiente a la entidad débil.Ejemplo de transformación de entidad débil
Lo explicaremos con un ejemplo:
Este ejemplo se transforma tal y como se muestra a continuación:
EDIFICIO(nombre, dirección)
DESPACHO(nombre, número, superficie)
donde {nombre} referencia EDIFICIOObservad que la clave foránea {nombre} forma parte también de la clave primaria de DESPACHO. Si no fuese así, y la clave primaria contuviese sólo el atributo número, los despachos no quedarían totalmente identificados, teniendo en cuenta que puede haber despachos situados en edificios diferentes que tengan el mismo número.
3.8. Transformacion de la generalizacion/especializacion
3.8. Transformacion de la generalizacion/especializacion Dataprix 30 September, 2009 - 15:00Cada una de las entidades superclase y subclase que forman parte de una generalización/especialización se transforma en una relación:
a) La relación de la entidad superclase tiene como clave primaria la clave de la entidad superclase y contiene todos los atributos comunes.
b) Las relaciones de las entidades subclase tienen como clave primaria la clave de la entidad superclase y contienen los atributos específicos
de la subclase.
Ejemplo de transformación de la generalización/especialización
Veamos un ejemplo (consultad el gráfico en la página siguiente) que contiene una generalización/especialización y, también, una interrelación M:N en la que interviene una de las entidades subclase. Este ejemplo se traduce al modelo relacional como se indica a continuación:
EMPLEADO(DNI, nombre, dirección, teléfono)
DIRECTIVO(DNI, coche)
donde {DNI} referencia EMPLEADO
ADMINISTRATIVO (DNI, antigüedad)
donde {DNI} referencia EMPLEADO
TÉCNICO (DNI, título)
donde {DNI} referencia EMPLEADO
PROYECTO(pro, ...)
TRABAJA(DNI, pro, superficie)
donde {DNI} referencia TÉCNICO
y {pro} referencia PROYECTO
Conviene observar que los atributos comunes se han situado en la relación EMPLEADO y que los atributos específicos se han situado en la relación de su entidad subclase. De este modo, coche está en DIRECTIVO, título en TÉCNICO y antigüedad en ADMINISTRATIVO.
Por otro lado, la interrelación específica para los empleados técnicos denominada trabaja se transforma en la relación TRABAJA. Observad que esta relación tiene una clave foránea que referencia sólo a los empleados técnicos, y no a los empleados directivos o administrativos.
3.9. Transformacion de entidades asociativas
3.9. Transformacion de entidades asociativas Dataprix 30 September, 2009 - 15:09Una entidad asociativa tiene su origen en una interrelación. En consecuencia, sucede que la transformación de la interrelación originaria es, al mismo tiempo, la transformación de la entidad asociativa.Ejemplo de transformación de una entidad asociativa
Veamos un ejemplo, que incluye una entidad asociativa interrelacionada con otra entidad:
La transformación del ejemplo anterior será:
CIUDAD(nombre-ciudad, ...)
VIAJE(id-viaje, ...)
RECORRIDO (nombre-ciudad, id-viaje)
donde {nombre-ciudad} referencia CIUDAD
e {id-viaje} referencia VIAJE
CLIENTE {código-cliente, ...}
REPARTO(nombre-ciudad, id-viaje, código-cliente, paq-car, paq-desc)
donde {nombre-ciudad, id-viaje} referencia RECORRIDO
y {código-cliente} referencia CLIENTETal y como se puede observar, la traducción de la interrelación recorrido es, al mismo tiempo, la traducción de su entidad asociativa.
La relación REPARTO nos ilustra la transformación de una interrelación en la que participa una entidad asociativa. Puesto que se trata de una interrelación M:N entre recorrido y ciudad, una parte de la clave primaria de REPARTO referencia la clave de RECORRIDO, y el resto, la clave de CIUDAD.
3.10. Resumen de la transformacion del modelo ER al modelo relacional
3.10. Resumen de la transformacion del modelo ER al modelo relacional Dataprix 30 September, 2009 - 15:13La tabla que mostramos a continuación resume los aspectos más básicos de las transformaciones que hemos descrito en las secciones anteriores, con el objetivo de presentar una visión rápida de los mismos:
3.11. Ejemplo: base de datos del personal de una entidad bancaria
3.11. Ejemplo: base de datos del personal de una entidad bancaria Dataprix 30 September, 2009 - 15:27En este apartado aplicaremos las transformaciones que hemos explicado en el caso práctico de la base de datos del personal de una entidad bancaria. Antes hemos presentado el diseño conceptual de esta base
| Hemos presentado el diseño conceptual de la base de datos del personal de la entidad bancaria en el subapartado 2.3 de esta unidad didáctica. |
de datos. A continuación, veremos su transformación al modelo relacional.
Empezaremos por transformar todas las entidades en relaciones y todas las interrelaciones 1:1 y 1:N en claves foráneas de estas relaciones.
EMPLEADO(código-empleado, DNI, NSS, nombre, apellido, nombre-
categ, central, ciudad-res)
donde {nombre-categ} referencia CATEGORÍA,
{central} referencia CENTRAL-SINDICAL,
el atributo central admite valores nulos
y {ciudad-res} referencia CIUDAD
FIJO(código-empleado, antigüedad)
donde {código-empleado} referencia EMPLEADO
TEMPORAL(código-empleado, fecha-inicio-cont, fecha-final-cont)
donde {código-empleado} referencia EMPLEADO
CIUDAD(nombre-ciudad, número-hab)
AGENCIA(nombre-ciudad, nombre-agencia, dirección, teléfono)
donde {nombre-ciudad} referencia CIUDAD
TÍTULO(nombre-título)
CATEGORÍA(nombre-categoría, sueldo-base, hora-extra)
CENTRAL-SINDICAL(central, cuota)
TIPO-PRÉSTAMO(código-préstamo, tipo-interés, período-vigencia)
FECHA(fecha)Observad que, en la transformación de la generalización/especialización correspondiente a la entidad empleado, hemos situado los atributos comunes a la relación EMPLEADO y los atributos específicos se han situado en las relaciones FIJO y TEMPORAL.
En la relación AGENCIA, el atributo nombre-ciudad es una clave foránea y al mismo tiempo forma parte de la clave primaria porque agencia es una entidad débil que requiere la interrelación situacion para ser identificada.
Veamos ahora las relaciones que se obtienen a partir de la transformación de las interrelaciones binarias y n-arias:
TITULACIÓN(código-empleado, nombre-título)
donde {código-empleado} referencia EMPLEADO
y {nombre-título} referencia TÍTULO
TRASLADO(código-empleado, fecha, nombre-ciudad, nombre-agencia,
fecha-fin)
donde {código-empleado} referencia EMPLEADO,
{nombre-ciudad, nombre-agencia} referencia AGENCIA
y {fecha} referencia FECHA
PETICIÓN(código-empleado, código-préstamo, fecha, concedido/no)
donde {código-empleado) referencia FIJO
{código-préstamo} referencia TIPO-PRÉSTAMO
y {fecha} referencia FECHAPara elegir las claves primarias adecuadas, se ha tenido en cuenta la conectividad de las interrelaciones.