La estructura básica de un modelo de base de
datos relacional es la relación, su
representación consiste en una tabla con un conjunto de filas y columnas en el
que las columnas son los atributos y las filas (tuplas) son las ocurrencias de
la relación.
Además hay otro concepto importante llamado clave candidata de una relación que se
define como el conjunto de atributos (columnas) que definen univoca y mínimamente
cada fila (tupla).
En una relación pueden existir varias claves
candidatas, por ejemplo, en la relación:
Medicos
(Código, DNI, Nombre, Dirección, Teléfono, Sueldo, Comisión, …etc)
Se pueden elegir como claves candidatas, el Código, o el DNI, si una de ellas se elige como clave primaria, por ejemplo DNI,
entonces el resto (es esta caso el código) serán las claves alternativas.
Ningún atributo que forme parte de la clave primaria
de una relación puede tomar valor nulo, esto se llama “integridad de entidad”.
Otro tipo de clave, la clave ajena, consiste en un
conjunto de valores que coincidirán con los valores de la clave primaria de
otra relación (o de ella misma). Por ejemplo en la Figura 1. Se señalan las
claves ajenas que representa la relación Medicos.
Para las claves ajenas existe la regla de
“integridad referencial“, que establece que los valores de la clave ajena, deben
coincidir con los de la clave primaria a la que referencian o son nulos.
Es decir, para cada clave ajena se debe
especificar si esta puede o no tomar valores nulos, lo que determinará las
consecuencias de determinadas operaciones como modificación y borrado que se realicen sobre tuplas de la relación a la que se referencia. En función del tipo de
operación que vayamos a implementar tenemos las siguientes opciones:
Operación Restringida (Restrict): Si deseamos borrar o modificar n
tuplas
de la relación que contiene la clave primaria sólo se permitirá la
operación si no existen tuplas con la clave en la relación que contiene la
clave ajena. Es decir, para borrar una Especialidad
(Fig, 1) no debe haber ningún Médico
que esté trabajando en dicha Especilaidad,
si no, el sistema debe impedir el borrado.
Operación con transmisión en Cascada (Cascade): Si
queremos borrar o modificar n tuplas de la relación que contiene la clave
primaria referenciada entonces se producirá el borrado o modificación en
cascada de las tuplas de la relación que contiene la clave ajena. En otras
palabras, en el ejemplo la relación Especialidad,
se debe modificar también el código en todos los Médicos de la base de datos que trabajen en dicha Especialidad.
Operación con puesta a nulos (Set Null): Si
queremos borrar o modificar n tuplas de la relación que contiene la clave
primaria referenciada, tenemos que poner a Nulo los valores de las claves
ajenas de la relación que referencia.
Por ejemplo, al borrar una Especialidad, los Médicos que trabajan en la Especialidad
eliminada y que además se encuentran en la relación Médicos, se les debe colocar el atributo Cod_Esp a Nulo. Esta opción sólo es posible si el atributo que es
clave ajena permite tomar valores nulos.
Operación con puesta a valor por defecto (Set Default): Si
queremos borrar o modificar n tuplas de la relación que contiene la clave
primaria referenciada, es necesario poner el valor por defecto a la clave ajena
de la relación de referencia.
Operación que desencadena un procedimiento de usuario: En este caso, el
borrado o modificación de tuplas de la tabla referenciada pone en marcha un
procedimiento definido por el usuario.
Reglas de transformación
Para convertir un diagrama en el modelo E/R
al relacional tenemos que seguir los siguientes principios:
- Toda entidad se convierte en una relación.
Tomando como ejemplo el siguiente
esquema tendríamos:
- Toda interrelación
N:M se transforma en una relación. Y se propaga la clave de cada entidad a la
que apunta. La clave primaria serán las dos claves
primarias de las entidades que se asocian.
 |
- Las relaciones de tipo 1:N hay que convertirlas
con “propagación de clave”. La clave primaria de la
entidad con cardinalidad 1 pasa a la tabla de la entidad cuya cardinalidad es N
(La entidad a la que apunta la flecha en el esquema E/R).
Si las relaciones de
cardinalidades máximas son distintas de 1 o n la regla para convertirla consiste
en propagar tantas veces la clave de una entidad como cardinalidad haya en la
otra entidad.
Esta regla es útil si la
cardinalidad es un número pequeño, o si
la cardinalidad máxima y la mínima son iguales, y garantiza evitar los
valores nulos.
Para la relación Medico-Medico:
Para la interrelación pertenece de
Medico-Especialidad:
- Para relaciones que asocian entidades con cardinalidades
(0,1), la relación 1:1 se transforma en una relación, además de las dos
relaciones que representan cada una de las entidades. Por ejemplo, si tenemos
la asociación Matrimonio entre las
entidades Hombre y Mujer, que se transforma en una relación,
evitando así los valores nulos que aparecerían en caso de propagar la clave de
la entidad Mujer a la tabla Hombre o viceversa, ya que como muestran
las cardinalidades ni todos los hombres ni todas las mujeres se encuentran
casados.
-Si una de las entidades de la relación tiene
cardinalidades (0,1), y en la otra la cardinalidad es (1,1), conviene propagar
la clave de la entidad con cardinalidades (1,1) a la tabla resultante de la
entidad de cardinalidades (0,1). En la figura 2, tenemos una relación que contiene
el médico que es responsable de una especialidad, suponiendo que un médico pueda
ser como máximo de una especialidad y que cada especialidad debe tener un
responsable –pero sólo uno -. En este caso propagamos la clave de Medico a la tabla de Especialidad, de este modo evitamos valores
nulos, y captando más semántica – recogemos la cardinalidad mínima 1, que en
caso de proceder con la propagación en sentido contrario no podríamos captar
directamente-.
Como esto ya se ha hecho por la relación 1:N
Pertenece, no hay cambios en el modelo.
-En el caso de que ambas entidades tengan
cardinalidades (1,1), podemos propagar la clave de cualquiera de ellas a la
tabla resultante de la otra, pero hay que determinar si los accesos
serán frecuentes o prioritarios a los datos de las tablas, si es así conviene
propagar las dos claves. Sin embargo, esto introduce redundancias que deben ser
controladas por medio de restricciones.
En
resumen: en las relaciones 1:1 existen tres
posibilidades: Si la cardinalidad es (0,1) en ambas entidades, se crea tabla.
Mientras que si la cardinalidad de una es (0,1) y de la otra es (1,1) se suele
pasar la clave primaria de (1,1) a la de (0,1). Si la cardinalidad de ambas es
(1,1) se pasa la clave de cualquiera de ellas a la otra.
Para la interrelación responsable Medico-Especialidad
Las dependencias en existencia y en
identificación no pertenecen al modelo relacional. En el ejemplo de la figura 2
vemos la manera de transformar una
dependencia en existencia propagando la
clave, para ello creamos una clave ajena, con nulos no permitidos, en la
relación de la entidad dependiente, y tiene como característica la de obligar a
una modificación y un borrado en cascada. Además si la dependencia es en
identificación, la clave primaria de la relación de la entidad débil tiene que
estar formada por la concatenación de las claves de las dos entidades
participantes en la relación.
En cuanto a los tipos y subtipos, no son
objetos que se puedan representar explícitamente en el modelo relacional
estándar. Si tenemos una Entidad y sus subtipos son posibles varias soluciones
de transformación en el modelo relacional, pero hay que tener en cuenta la
subsiguiente pérdida de semántica dependiendo de la estrategia elegida.
Tenemos varias opciones:
Opción a:
Englobar todos los atributos de entidad y sus subtipos en una sola relación, En
general, adoptaremos esta solución cuando los subtipos se diferencien en muy
pocos atributos y las relaciones que los asocian con el resto de entidades
del esquema sean las mismas para todos los subtipos.
Por ejemplo podemos considerar mínima la
diferencia entre un investigador y un traumatólogo desde el punto de vista de
ser médicos de un hospital (figura 3). Debido a esto, la mejor solución para
este caso sería la creación de una sola tabla que contenga todos los atributos
del supertipo y de los subtipos, añadiendo un atributo adicional que le indique
el tipo de médico que realiza –el atributo discriminante de la jerarquía-. Por
otra parte se tendrán que especificar las restricciones semánticas
correspondientes que obliguen a que los médicos que sean investigadores no
puedan tener consulta (Que Consulta
sea nulo).
Opción b:
Crear una relación para el supertipo y tantas relaciones como subtipos haya,
con sus atributos correspondientes. Ésta es la solución adecuada cuando
existen muchos atributos distintos entre los subtipos, se quieren mantener de
todas maneras los atributos comunes a todos ellos en una relación. Igual que en
la opción anterior, habrá que crear las restricciones oportunas.
Opción c:
Considerar relaciones distintas para cada subtipo que contengan además
atributos comunes. Elegiremos esta opción cuando se den las mismas
condiciones que en el caso anterior (muchos atributos distintos) y los accesos
realizados sobre los datos de los distintos subtipos afecten casi siempre a
atributos comunes.
Podemos elegir una estrategia u otra
dependiendo de si es la semántica o la eficiencia la que prima para el diseñador
en un momento determinado.
Ejemplo sencillo
Continuando con el ejemplo sencillo, el
esquema E/R obtenido en el post anterior: El modelo E/R y el diagrama de estructura de datos era el siguiente:
Ahora lo pasaremos a un modelo relacional,
teniendo en cuenta que teníamos pendiente una posible redundancia en una
interrelación.
Paso1. Convertimos las entidades en
relaciones:
Hospital (strId_HOS, Nombre, Direccion, Telefono)
Médico (strId_MED, Nombre, Especialidad)
Paciente (strId_PAC, Nombre, Direccion, Fecha Nac)
Sala (Nº de Camas, strId_SAL)
Paso 2. Convertimos las interrelaciones N:M
Paso 3. Convertimos las
relaciones 1:N
Propagamos las claves
Paso 4. Consideramos el caso Especial 1:5
como si fuera un 1:N por lo que tenemos
O considerando la regla 1:N cuando N es
pequeño (en este caso 5) podríamos hacer
Sala (strId_SAL, Nº de
Camas, strId_HOS, strId_PAC1, strId_PAC2, strId_PAC3 strId_PAC4, strId_PAC5)
En este caso concreto lo desestimaremos por
dos motivos:
1º Por que debería ser variable entre 1 y 5
dependiendo del valor Nº de Camas
2º Por evitar dejar los campos a nulos
Finalmente la posible interrelación
redundante no se elimina pues solamente
añade un campo al paciente con el cual podemos identificar en que sala se
encuentra.
El modelo de Base de Datos quedaría del
siguiente modo.
No hay comentarios:
Publicar un comentario