Transformar modelo entidad relacion a modelo logico

http://datosintensos.blogspot.com/

Transformación
Modelo ER a Relacional(Lógico)

http://en.wikipedia.org/wiki/Entity-relationship_model

JOSÉ CUARTAS BASES DE DATOS
Actualízate sobre gestión de información en http://datosintensos.blogspot.com/

Transformación Modelo ER a Relacional
Tres reglas básicas


Las tres reglas básicas para convertir un esquema en el modelo E/R al
relacional son las siguientes:
• Todo tipo de entidad se convierte en una relación.
• La tabla o relación toma el nombre de la entidad. Los atributos de la
entidad serán las columnas de la tabla y el atributo identificador principal
será la clave primaria. En caso de que se indique lo contrario los atributos
no identificadores podrán tomar valores nulos.

• Todo tipo de relación M:M (muchos a muchos) se transforma en una
relación.
• Las interrelaciones N:M se transforman en una tabla cuya clave primaria
será la concatenación de los atributos principales de las entidades que se
asocia; estos atributos serán claves foráneas que referencian a las
respectivas tablas donde son claves primarias. Los atributos de la
interrelación serán columnas de la tabla.


Tres reglas básicas


• Para todo tipo de relación 1:M se realiza lo que se denomina
propagación de clave (regla general), o se crea una nueva relación.
• Las interrelaciones 1:N o 1:1 se transforman propagando el atributo
identificador principal de la entidad que tiene cardinalidad máxima 1 a la
que tiene cardinalidad máxima N. Si la relación fuese 1:1 la propagación de
clave podría hacerse en cualquier sentido. El atributo propagado es una
clave foránea que referencia a la tabla con cardinalidad máxima de 1.


Tres reglas básicas- Ejemplo


Codigo Nombre_a
Nombre_e

EDITORIAL EDITA LIBRO ESCRIBE AUTOR
1 n n n

LIBRO( Código, Título, Idioma, …, Editorial)

AUTOR( Nombre_a, Nacionalidad, Institución)

ESCRIBE(Nombre_a, Código)

CLAVE FORÁNEA
EDITORIAL( Nombre_e, Dirección, Ciudad, País)


Reglas detalladas de Transformación
Transformación de Atributos de Entidades


• Cada atributo de una entidad se transforma en una columna de la tabla a
la que ha dado lugar la entidad.
• Teniendo en cuenta que existen atributos identificador principal, otros que
son identificadores alternativos (únicos) y el resto de los atributos que no
son identificadores – atributos no principales- se deben tener en la cuenta
las siguientes tres reglas:
• Atributos Identificadores Los atributos que son identificadores
principales pasan a formar la clave primaria de la tabla.

• Atributos Identificadores Alternativos Se les denomina mediante
un cláusula denomina UNIQUE.

• Atributos No Identificadores Se representan solo como columnas de
la tabla correspondiente, y se les define el dominio al que pertenece


Transformación de Atributos de Entidades


• Atributos Multivaluados El modelo relacional no permite dominios
multivaluados, ya que los datos deben ser atómicos, por consiguiente, deberá
crearse una nueva tabla cuyos únicos atributos ( y clave primaria ) será la
concatenación de la clave primaria de la entidad original y el atributo multivaluado.
• Se debe crear una clave foránea referenciado a la tabla primaria.

• Atributos Derivados No existe una representación directa. Por tanto, se
deben tratar como atributos normales, que pasarán a ser columnas de la tabla
correspondiente, en el mejor de los casos evitarlos.
• Se debe construir un disparador(trigger) que calcule el valor del atributo
derivado cada vez que se inserten o borren las ocurrencias de los atributos
que intervienen en el calculo y añadir las restricciones correspondientes.


Ejemplo de Transformación de atributos


Cod_PER Dirección

n
Télefono
Nombre PERSONA

Tipo_DI
DI

Diccionario de datos esquema conceptual
VALORES RESTRICCIONES
ENTIDAD ATRIBUTOS DOMINIOS DESCRIPCION
DEFECTO VALORES
PERSONA <DESCRIPCION DE LA ENTIDAD PERSONA>
Cod_PER Numerico {Digito}8 Números autoincrementales NOT NULL, PK
AUTOINCREMENTO
DI Cadena(20) {Digito}8 Número de identificación del UNIQUE
documento
Tipo_DI Cadena(4) {Letra} Tipo de documento NA CC, TI,NA Chequeos de
valores permitidos
Direccion Cadena(40) {Digito} + Dirección de ubicación NA
{Letra}
Nombre Cadena(30) {Letra} NOT NULL


Ejemplo de Transformación de atributos
Diccionario de datos esquema conceptual


DEFECTO VALORES
TELEFONO <DESCRIPCION DE LA ENTIDAD TELEFONO>
Cod_PER Numerico {Digito}8 Números relaionados con PK ,FK
Cod_PER AUTOINCREMENTO
Numero Cadena(14) {Digito} + Número de teléfono PK
{Símbolos}
[<EL ATRIBUTO Cod_PER ES UNA CLAVE FORANEA CON LA ENTIDAD PERSONA]
[<LOS ATRIBUTOS Cod_PER y Numero SON LA CLAVE PRIMARIA]

CREATE TABLE persona CREATE TABLE telefono
( cod_per INTEGER PRIMARY KEY, ( cod_per INTEGER,
nombre VARCHAR(30) NOT NULL, numero VARCHAR(14),
“DI” VARCHAR(20) UNIQUE, CONSTRAINT “PK_telefono”
“tipo_DI” VARCHAR(4) , PRIMARY KEY(cod_per, numero),
Direccion VARCHAR(40)„, CONSTRAINT FK_telefono_persona
CONSTRAINT “CK_tipo_DI” FOREIGN KEY (universidad)
CHECK ( “tipo_DI” IN („CC', „TI„, „NA„ )) REFERENCES “persona”(cod_per)
); );

JOSÉ CUARTAS
Actualízate sobre gestión de información DATOS
BASES DE en http://datosintensos.blogspot.com/



Transformación de relaciones M:M
Un tipo de relación M:M se transforma en una tabla que tendrá como clave
primaria COMPUESTA las claves primarias (PK) de los tipos de entidades
que asocia.
Además, cada uno de los atributos que forman la clave primaria de esta tabla
también son claves foráneas que referencian a las tablas en que se han
convertido las entidades relacionadas (claves primarias).

Cod_EMP EMPLEADO Modelo Relacional

n EMPLEADO( Cod_EMP, ….. )

ADJUNTO PROYECTO( Cod_proyec )

n
ADJUNTO( Cod_proyec, Cod_EMP )
Cod_proyec PROYECTO

JOSÉ CUARTAS



DEFECTO VALORES
EMPLEADO <DESCRIPCION DE LA ENTIDAD EMPLEADO>
Cod_EMP Numerico {Digito}8 Números PK
, AUTOINCREMENT
O
….. ………. …………… ……….. …… ….. ……….

DEFECTO VALORES
PROYECTO <DESCRIPCION DE LA ENTIDAD EMPLEADO>
Cod_proyec Numerico {Digito}8 Números PK ,
AUTOINCREMENTO
….. ………. …………… ……….. …… ….. ……….

DEFECTO VALORES
ADJUNTO <DESCRIPCION DE LA ENTIDAD EMPLEADO>
Cod_proyec Numerico {Digito}8 Números PK ,FK
Cod_EMP Numerico {Digito}8 Números PK ,FK

[<EL ATRIBUTO Cod_proyec ES UNA CLAVE FORANEA CON LA ENTIDAD PROYECTO]
[<EL ATRIBUTO Cod_EMP ES UNA CLAVE FORANEA CON LA ENTIDAD EMPLEADO]
[<LOS ATRIBUTOS Cod_EMP y Cod_proyec SON LA CLAVE PRIMARIA COMPUESTA]

JOSÉ CUARTAS



CREATE TABLE EMPLEADO CREATE TABLE PROYECTO
( Cod_EMP INTEGER PRIMARY KEY, ( Cod_proyec INTEGER PRIMARY KEY,
………., ……….,
………., ……….,
………. ……….
); );

CREATE TABLE ADJUNTO
(Cod_EMP INTEGER,
Cod_proyec INTEGER,
CONSTRAINT “PK_ADJUNTO” PRIMARY KEY( Cod_EMP , Cod_proyec),
CONSTRAINT FK_adjunto_proyecto FOREIGN KEY (Cod_proyec) REFERENCES “PROYECTO”(cod_proyec),
CONSTRAINT FK_adjunto_empleado FOREIGN KEY (Cod_EMP) REFERENCES “EMPLEADO”(cod_EMP)
);

JOSÉ CUARTAS



Transformación de relaciones 1:N
Existen dos soluciones:
 Propagar la clave principal del tipo de entidad que tiene la
cardinalidad máxima 1 a la que tiene N (propagación de clave). Esta
es la regla habitual.
 Transformar la relación en una tabla como si se tratara de una
relación M:M; pero ahora la clave primaria de la tabla creada es sólo
la clave primaria de la tabla a la que le corresponde la cardinalidad n.
La opción b) se utiliza cuando:
 El número de ejemplares relacionados de la entidad que propaga su clave es
muy pequeño y, por tanto, existirían muchos valores nulos en la clave
propagada.
 Se prevé que la relación en un futuro se convertirá en un tipo M:M
 La relación tiene atributos propios y no es deseable propagarlos ( a fin
de conservar la semántica ).
JOSÉ CUARTAS



Transformación de relaciones 1:N

Cod_emp
EMPLEADO

n
Modelo Relacional
EMPLEADO( Cod_emp, ….., Cod_dep )

PERTENECE

DEPARTAMENTO (Cod_dep, … )
1

Cod_dep
DEPARTAMENTO

JOSÉ CUARTAS



Transformación de relaciones 1:1

Una relación de tipo 1:1 es un caso particular de una relación 1:N, por lo que
se puede aplicar las dos opciones ya comentadas: crear una nueva tabla o
realizar propagación de clave, en este caso la propagación se puede hacer
en ambos sentidos)

Los criterios para aplicar una u otra regla y para propagar la clave se basan:
 Las cardinalidades mínimas.
 Recoger la mayor cantidad de semántica posible.
 Evitar los valores nulos o aumentar la eficiencia.

JOSÉ CUARTAS



Si las entidades que se asocian poseen cardinalidades (0,1), suele ser
conveniente transformar la relación 1:1 en una tabla.

Cod_Hombre
HOMBRE
Modelo Relacional
(0,1)

MATRIMONIO (Cod_Hombre, Cod_Mujer)

MATRIMONIO
HOMBRE ( Cod_Hombre )

(0,1)
MUJER ( Cod_Mujer )

Cod_Mujer
MUJER Clave Alternativa
UNIQUE, NOT NULL



Si las entidades que participan en la interrelación poseen cardinalidades
(0,1) y (1,1), conviene propagar la clave de la entidad con cardinalidades
(1,1) a la tabla resultante de la entidad con cardinalidad.

Cod_emp
EMPLEADO
Modelo Relacional
(1,1)

EMPLEADO (Cod_emp)

RESPONSABLE

DEPARTAMENTO ( Cod_dep, Cod_emp)

(0,1)

Cod_dep
Clave Ajena
DEPARTAMENTO
NOT NULL



En el caso de que ambas entidades presenten cardinalidad (1,1), se puede
propagar la clave de cualquiera de ellas a la tabla resultante de la otra,
teniendo en cuenta en este caso los accesos más frecuentes y prioritarios a
los datos de las tablas.

JOSÉ CUARTAS



Transformación de atributos de relaciones
Si la relación se transforma en una tabla, todos sus atributos pasan a ser
columnas de la tabla.
En caso de que la relación se transforme mediante propagación de clave,
sus atributos migran junto a la clave a la tabla correspondiente.

Modelo Relacional
Cod_prof PROFESOR
1,n
PROFESOR ( Cod_prof, …..)

Nro_Horas IMPARTE

IMPARTE ( Cod_prof, Cod_curso, Num_Hora
1,n
)

Cod_curso CURSO
CURSO ( Cod_curso, …)
JOSÉ CUARTAS



Transformación de Dependencias en Identificación y en Existencia.
La manera de transformar una relación de este tipo es utilizar el mecanismo
de propagación de clave, creando una clave ajena, con nulos no permitidos,
en la tabla de la entidad dependiente, con la característica de obligar a una
modificación y un borrado en cascada.
Además, en el caso de dependencia en identificación la clave primaria de la
tabla en la que se ha transformado la entidad débil debe estar formada por la
concatenación de las claves de las dos entidades participantes.

Cod_Curso CURSO Modelo Relacional
CURSO ( Cód_Curso, …. )
EDICION ( Cód_edicion, Cod_curso, ….)
TIENE

Clave Ajena – NOT NULL – On Delete
Cascade – On Update Cascada.
Cod_Edición EDICION



Transformación de Generalización (tipos y subtipos)
Existen tres soluciones de transformación al modelo relacional:
a) Englobar todos los atributos de la entidad y sus subtipos en una sola
tabla. Esta solución se utiliza cuando la cantidad de atributos de subtipos se
diferencien muy poco y las relaciones que los asocian con el resto de las
entidades del esquema sean las mismas para todos (o casi todos) los
subtipos.
b) Crear una tabla para el supertipo y tantas tablas como subtipos
haya, con sus atributos correspondientes. Esta solución es adecuada
cuando existen muchos atributos distintos entre los subtipos y se desea
mantener los atributos comunes a todos ellos en una misma tabla.
c) Considerar tablas distintas para cada subtipo, que contengan, además
de los atributos propios, los atributos comunes. Se elegirá esta opción
cuando se den las mismas condiciones anteriores.

JOSÉ CUARTAS



Ejemplo:

EMPLEADO

Rol

Tipo_inge

INGENIERO SECRETARIA

JOSÉ CUARTAS



Ejemplo:
Transformación
Opción a) EMPLEADO (Cod_emp, nombre, ….., tipo, Tipo_inge, Rol,..)

Opción b) EMPLEADO (Cod_emp, Nombre, ….)
INGENIERO (Cod_emp, …… )
SECRETARIA (Cod_emp, …..)

Opción c) INGENIERO (Cod_emp, Nombre, ……, Tipo_inge, ….)
SECRETARIA (Cod_emp, Nombre, ……)

JOSÉ CUARTAS



Se puede elegir cualquiera de las tres estrategias para la transformación de un
tipo y sus subtipos al modelo relacional,
 desde lo semántico la opción b es la mejor.
 desde la eficiencia deberá tenerse en cuenta que:
 Opción a: el acceso a una fila es mas rápido a nivel operativo del motor (no hace falta
combinar varias tablas).
 Opción b: la menos eficiente aunque es la mejor desde el mundo semántico, esta opción
puede mejorar el desempeño creando una vista materializada que refleje la opción a.
 Opción c: Con esta solución se aumenta la eficiencia ante determinadas consultas ( las que
afectan a todos los atributos, tanto comunes como propios, de un subtipo) pero se
disminuye ante otras.

Cual estrategia elegir depende de lo que le interese al USUARIO generalmente es la INMEDIATEZ

JOSÉ CUARTAS

Transformar modelo entidad relacion a modelo logico

Más contenido relacionado

La actualidad más candente

Similar a Transformar modelo entidad relacion a modelo logico

Más de josecuartas

Último

Transformar modelo entidad relacion a modelo logico