Implementación de un modelo E/R al modelo relacional
Una vez realizado el modelado para obtener el diagrama entidad-relación, es necesario seguir un conjunto de pasos para convertirlo en un modelo relacional. Las tres reglas generales para realizar esto son:
Las tres reglas para implementar un modelo E/R a un modelo relacional
A continuación, explicaremos detalladamente los pasos necesarios para esta derivación. Es necesario recordar que, de forma ideal, se debe mantener la semántica del modelo conceptual en el lógico. Desafortunadamente, no siempre es posible hacerlo. Las reglas específicas para derivar un modelo entidad-relación son:
a) Derivación de dominios: Deben crearse los dominios de todos los atributos. Para esto utilizamos la sentencia CREATE DOMAIN; por ejemplo:
| CREATE DOMAIN edo_civil AS CHAR(1)
CHECK (VALUE IN ('S', 'C'));
|
b) Derivación de entidades: Cada tipo de entidad se transforma en una relación o tabla. Para ello, utilizamos la sentencia CREATE TABLE.
(s. a.) (2013). Ejemplo de derivación de entidades [imagen]. Tomada de https://daumindex.wordpress.com/2013/03/18/reglas-de-transformacion-del-modelo-er-al-modelo-relacional-2/
c) Derivación de atributos: Todo atributo de una entidad se transforma en una columna de su relación correspondiente.
Atributos identificadores (claves o principales)
Se transforman en claves primarias. Para ello, se usa la restricción de integridad PRIMARY KEY; por ejemplo:
| cod_alumno INTEGER CONSTRAINT pk_cod_alumno PRIMARY KEY
|
Atributos identificadores alternativos (claves candidatas)
Se les aplica la restricción de integridad UNIQUE; por ejemplo:
| rfc CHAR(13) CONSTRAINT un_rfc UNIQUE
|
Atributos no identificadores (no clave, no principales)
Se les aplica la restricción de integridad de NOT NULL, sólo si es necesario; por ejemplo:
| nombre VARCHAR(30) NOT NULL
|
d) Derivación de interrelaciones:
La interrelación se transforma en una relación que tendrá como superclave los atributos identificadores —claves o principales— de las entidades que relaciona. Los atributos de la relación resultante —relación o tabla de interrelación— se convierten en llaves foráneas —claves ajenas—, mediante la restricción FOREIGN KEY. Para esta restricción, es necesario indicar la tabla padre y la llave primaria en esa tabla. Además, podemos indicar las restricciones de borrado y actualización en cascada; por ejemplo:
(
cod_curso INTEGER,
cod_profesor INTEGER,
PRIMARY KEY (cod_curso, cod_profesor), /*Primaria compuesta*/
CONSTRAINT fk_cod_curso FOREIGN KEY (cod_curso)
REFERENCES curso(cod_curso)
ON DELETE CASCADE
ON UPDATE CASCADE, /* Foránea con borrado y actualización en cascada*/
CONSTRAINT fk_cod_profesor FOREIGN KEY (cod_profesor)
REFERENCES profesor(cod_profesor)
ON DELETE CASCADE
ON UPDATE CASCADE /* Foránea con borrado y actualización en cascada*/)
|
Otro aspecto importante por derivar es la cardinalidad de las entidades participantes. Como sabemos, existen casos en los que hay restricciones de negocio que impiden que un determinado número de ejemplares de una entidad interactúe con ejemplares de otra entidad. En este caso, es necesario agregar una restricción de aserción. Desafortunadamente, no todos los manejadores de bases de datos incluyen esta posibilidad. En ese caso, debemos utilizar disparadores —triggers— de integridad; por ejemplo, supongamos que un curso sólo puede ser impartido por cuatro profesores, es decir, con cardinalidad (0,4). En ese caso, tendríamos que crear la siguiente aserción:
CREATE ASSERTION profesor_curso
CHECK NOT EXIST (SELECT COUNT(*)
FROM imparte
GROUP BY cod_curso
HAVING
COUNT(*)>=4);
|
La manera general de transformar esta interrelación consiste en propagar —pasar— el atributo identificador —clave o principal— de la entidad con cardinalidad 1 hacia la entidad con cardinalidad N. Como resultado, la interrelación se pierde; es decir, no se convierte en entidad como en el caso de N:M. El atributo propagado se convierte en llave foránea, para el cual debemos indicar si existe borrado en cascada. La cardinalidad de la interrelación también debe ser implementada como ya establecimos, esto es, utilizando restricciones de aserción o triggers. Adicionalmente, si la cardinalidad indica que el número de ejemplares puede ser 0, la llave foránea aceptará valores nulos. Si, por el contrario, indica que al menos un ejemplar debe estar relacionado con uno o más ejemplares —cardinalidad 1—, la llave foránea debe tener restricción de NOT NULL.
La ocurrencia de la entidad A puede relacionarse con varias ocurrencias de la entidad B
No hay regla fija para la transformación de esta interrelación. Lo más común es aplicar las interrelaciones N:M, aunque puede ser posible emplear las 1:N. Es importante notar que al usar éstas necesitamos decidir en qué dirección se propaga la llave primaria. Para resolverlo, podemos tomar en cuenta al menos dos aspectos:
•Pasar la llave primaria de una entidad fuerte a una débil es generalmente más conveniente.
•Pasar la llave primaria de la entidad con cardinalidad (1,1) a la entidad con cardinalidad (0,1) permite aplicar NOT NULL a la llave foránea.
e) Atributos de interrelaciones: Si la interrelación se transforma en relación, los atributos de la interrelación se convierten en columnas de la relación resultante. En caso de que se aplicase una propagación de identificador o clave, los atributos de la interrelación pasan en la misma dirección que dicha clave.
Sotorrío, Ó. (2010). La interrelación “tiene” se convierte en tabla [esquema]. Tomada de http://oscarsotorrio.com/post/2010/10/12/Transformacion-del-Modelo-ER-al-Modelo-Relacional.aspx
f) Otras restricciones: Podemos encontrar restricciones de valores posibles para un atributo. Para transformarlas al modelo relacional, utilizamos la restricción CHECK. Además, si el manejador de bases de datos no acepta creación de dominios, con el CHECK es posible restringir los valores de un dominio.
| Tipo de integridad |
Tipo de restricción |
Descripción |
|
Dominio |
DEFAULT |
Especifica el valor predeterminado de una columna. |
|
CHECK |
Especifica el valor permitido de una columna. |
|
FOREING KEY |
Especifica la columna en la que deben existir los valores. |
|
NULL |
Especifica si se permite NULL. |
|
Entidad |
PRIMARY KEY |
Identifica cada fila de manera única. |
|
UNIQUE |
Impide la duplicación de claves no principales. |
|
Referencia |
PRIMARY KEY |
Define columnas cuyo valor debe coincidir con la clave principal de esta tabla. |
|
PRIMARY KEY |
Especifica el valor permitido para una columna, basándose en el contenido de otra columna. |
g) Transformación de dependencias de existencia e identificación En este caso se realiza una propagación de identificador o clave, asegurándonos de poner en la llave foránea, si es necesaria, la restricción de borrado y actualización en cascada. Cuando se trate de una dependencia de identificación, la llave primaria propagada se combina con algún atributo de la entidad débil para formar una superclave.
Microsoft. (2007). Ejemplo de interfaz de DBMS para permitir actualizar o eliminar en cascada [imagen]. Tomada de https://support.office.com/es-es/article/Actualizar-los-datos-de-una-base-de-datos-5e90a80c-106d-4c55-996e-07d7200980ce
h) Derivación de tipos y subtipos: No hay una manera de conservar la semántica de los tipos y subtipos en el modelo relacional. Lo más recomendable es crear relaciones para cada supertipo y cada subtipo; después, propagar la clave principal del supertipo en cada relación de los subtipos. Esta clave propagada será, además de llave foránea, la llave primaria de cada subtipo. Finalmente, si queremos asegurarnos de que un tipo no pueda aparecer en varios subtipos, tendremos que usar disparadores que revisen que la clave del tipo no exista ya en algún subtipo.
(s. a.) (2013). Ejemplo de derivación de tipos y subtipos
[imagen]. Tomada de https://daumindex.wordpress.com/2013/03/18/reglas-de-transformacion-del-modelo-er-al-modelo-relacional-2/
