Bases de DatosUnidad V Transformacin Modelo ER a Relacional - NormalizacinSergio Snchez Rios.Ingeniero en Informtica Licenciado en Informtica Docente Jornada Parcial Universidad Via del MarSergio Snchez

Transformacin Modelo ER a RelacionalTres reglas bsicasLas tres reglas bsicas para convertir un esquema en el modelo E/R al relacional son las siguientes:

1) Todo tipo de entidad se convierte en una relacin.

2) Todo tipo de relacin M:M (muchos a muchos) se transforma en una relacin.

3) Para todo tipo de relacin 1:M se realiza lo que se denomina propagacin de clave (regla general), o se crea una nueva relacin.

Sergio Snchez

Transformacin Modelo ER a RelacionalTres reglas bsicasDebido a que el modelo relacional no distingue entre entidades y relaciones, ambos conceptos deben representarse mediante relaciones. Esto implica una perdida de semntica con respecto al esquema E/R: Las relaciones M:M no se distinguen de las entidades (ambas se transforman en tablas). Las 1:M se suelen representar mediante una propagacin de clave, desapareciendo incluso el nombre de la relacin.

Sergio Snchez

Transformacin Modelo ER a RelacionalTres reglas bsicas - EjemploNombre_e Codigo Nombre_a

EDITORIAL 1

EDITA

LIBRO n n

ESCRIBE

AUTOR n

LIBRO( Cdigo, Ttulo, Idioma, , Editorial)

AUTOR( Nombre_a, Nacionalidad, Institucin) ESCRIBE(Nombre_a, Cdigo)

CLAVE AJENAEDITORIAL( Nombre_e, Direccin, Ciudad, Pas)Sergio Snchez

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de EntidadesCada tipo de entidad se convierte en una tabla.La tabla se llamar igual que el tipo de entidad de donde proviene.

Transformacin de Atributos de EntidadesCada 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-. Esta regla se divide en subreglas.Sergio Snchez

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de Atributos de Entidades

Atributos IdentificadoresLos atributos que son identificadores principales pasan a formar la clave primaria de la tabla.

Atributos Identificadores AlternativosSe les denomina mediante un clusula denomina UNIQUE.

Atributos No IdentificadoresSe representan solo como columnas de la tabla correspondiente.Sergio Snchez

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de Atributos de EntidadesCod_Prof Direccin

Nombre

PROFESOR

Tlefono

Materia DNI CREATE TABLE Profesor ( Cod_Prof Cdigo,

PROFESORCod_prof Nombre DNI Direccin Telfono Materia

Nombre Nombres, DNI DNIS, NOT NULL Direccin Lugares, Tlefono Nos_Telfono, Materia Materias, PRIMARY KEY (Cod_prof),Sergio Snchez

UNIQUE (DNI) );

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de Atributos de Entidades

Atributos MultivaluadosPuesto que el modelo relacional no permite dominios multivaluados, deber crearse una nueva tabla cuyos nicos atributos ( y clave primaria ) ser la concatenacin de la clave primaria de la entidad original y el atributo multivaluado. Adems, se debe crear una clave ajena referenciado a la tabla primaria.Cod_Prof

Persona ( dni, nombre, )Nombre

PROFESORn

CLAVE AJENA

Telefonos ( dni, nmero )Sergio Snchez

Tlefono

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de relaciones M:MUn tipo de relacin M:M se transforma en una tabla que tendr como clave primaria la concatenacin de las claves primarias (CP) de los tipos de entidades que asocia.Adems, cada uno de los atributos que forman la clave primaria de esta tabla tambin son claves ajenas que referencian a las tablas en que se han convertido las entidades relacionadas (claves primarias).Cod_prof

PROFESOR n

Modelo Relacional PROFESOR ( Cod_prof, .. )

IMPARTE

CURSO ( Cod_curso )

nCod_curso

IMPARTE ( Cod_curso, Cod_prof )Sergio Snchez

CURSO

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de relaciones 1:NExisten dos soluciones: Propagar la clave principal del tipo de entidad que tiene la cardinalidad mxima 1 a la que tiene N (propagacin de clave). Esta es la regla habitual. Transformar la relacin en una tabla como si se tratara de una relacin M:M; pero ahora la clave primaria de la tabla creada es slo la clave primaria de la tabla a la que le corresponde la cardinalidad n. La opcin b) se utiliza cuando: El nmero de ejemplares relacionados de la entidad que propaga su clave es muy pequeo y, por tanto, existiran muchos valores nulos en la clave propagada. Se prev que la relacin en un futuro se convertir en un tipo M:M La relacin tiene atributos propios y no es deseable propagarlos ( a fin de Sergio Snchez conservar la semntica ).

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de relaciones 1:N

Cod_prof

PROFESOR n

Modelo Relacional

PROFESOR ( Cod_prof, .., Cod_dep )PERTENECE

DEPARTAMENTO (Cod_dep, )1Cod_dep

DEPARTAMENTO

Sergio Snchez

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de relaciones 1:1Una relacin de tipo 1:1 es un caso particular de una relacin 1:N, por lo que se puede aplicar las dos opciones ya comentadas: crear una nueva tabla o realizar propagacin de clave, en este caso la propagacin se puede hacer en ambos sentidos)

Los criterios para aplicar una u otra regla y para propagar la clave se basan: Las cardinalidades mnimas.

Recoger la mayor cantidad de semntica posible. Evitar los valores nulos o aumentar la eficiencia.

Sergio Snchez

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de relaciones 1:1Si las entidades que se asocian poseen cardinalidades (0,1), suele ser conveniente transformar la relacin 1:1 en una tabla.Cod_Hombre

HOMBRE (0,1)

Modelo Relacional

MATRIMONIO (Cod_Hombre, Cod_Mujer)MATRIMONIO

HOMBRE ( Cod_Hombre )(0,1)Cod_Mujer

MUJER ( Cod_Mujer )Clave AlternativaSergio Snchez

MUJER

UNIQUE, NOT NULL

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de relaciones 1:1Si las entidades que participan en la interrelacin 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_prof

PROFESOR (1,1)

Modelo Relacional

PROFESOR ( Cod_prof )RESPONSABLE

DEPARTAMENTO ( Cod_dep, Cod_prof )(0,1)Cod_dep

DEPARTAMENTO

Clave AjenaSergio Snchez

NOT NULL

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de relaciones 1:1En 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 ms frecuentes y prioritarios a los datos de las tablas.

Sergio Snchez

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de atributos de relacionesSi la relacin se transforma en una tabla, todos sus atributos pasan a ser columnas de la tabla.En caso de que la relacin se transforme mediante propagacin de clave, sus atributos migran junto a la clave a la tabla correspondiente.Cod_prof

PROFESOR 1,n

Modelo Relacional PROFESOR ( Cod_prof, ..)

Nro_Horas

IMPARTE

IMPARTE ( Cod_prof, Cod_curso, Num_Hora )1,nCod_curso

CURSO

CURSO ( Cod_curso, )Sergio Snchez

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin Existencia. de Dependencias en Identificacin y en

La manera de transformar una relacin de este tipo es utilizar el mecanismo de propagacin de clave, creando una clave ajena, con nulos no permitidos, en la tabla de la entidad dependiente, con la caracterstica de obligar a una modificacin y un borrado en cascada.

Adems, en el caso de dependencia en identificacin la clave primaria de la tabla en la que se ha transformado la entidad dbil debe estar formada por la concatenacin de las claves de las dos entidades participantes.Cod_Curso

CURSO

Modelo Relacional

CURSO ( Cd_Curso, . )TIENE

EDICION ( Cd_edicion, Cod_curso, .)Clave Ajena NOT NULL On Delete Cascade On Update Cascada.

Sergio Snchez

Cod_Edicin

EDICION

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de Generalizacin (tipos y subtipos)Existen tres soluciones de transformacin al modelo relacional:a) Englobar todos los atributos de la entidad y sus subtipos en una sola tabla. En general, se debe adoptar esta solucin cuando los subtipos se diferencien en muy pocos atributos 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 es la solucin adecuada cuando existen muchos atributos distintos entre los subtipos y se quieren mantener de todas maneras los atributos comunes a todos ellos en una tabla. c) Considerar tablas distintas para cada subtipo, que contengan, adems de los atributos propios, los atributos comunes. Se elegir esta opcin cuando se den las mismas condiciones anteriores.Sergio Snchez

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de Generalizacin (tipos y subtipos)Ejemplo:PROFESOR

Ao_doc Materia_docDOCTOR NO DOCTOR

Sergio Snchez

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de Generalizacin (tipos y subtipos)Ejemplo:Transformacin Opcin a) PROFESOR (Cod_prof, nombre, .., tipo, Ao_doc, Materia_doc,..) Opcin b) PROFESOR (Cod_prof, Nombre, .) DOCTOR (Cod_prof, ) NO_DOCTOR (Cod_prof, ..) Opcin c) DOCTOR (Cod_prof, Nombre, , Ao_doc, .) NO_DOCTOR ( Cod_prof, Nombre, )Sergio Snchez

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de Generalizacin (tipos y subtipos)Aunque es posible elegir cualquiera de las tres estrategias para la transformacin de un tipo y sus subtipos al modelo relacional, desde un punto de vista exclusivamente semntico la opcin b es la mejor. desde el punto de vista de la eficiencia deber tenerse en cuenta que: Opcin a: el acceso a una fila que refleje toda la informacin de una determinada entidad es mucho ms rpido (no hace falta combinar varias tablas). Opcin b: la menos eficiente aunque es la mejor desde un punto de vista exclusivamente semntico. Opcin c: Con esta solucin 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. Esta solucin es la que pierde ms semntica.Sergio Snchez

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de Generalizacin (tipos y subtipos)Se deber elegir una estrategia u otra dependiendo de que sea la semntica o la eficiencia la que prime para el usuario en un momento determinado.

Sergio Snchez

Transformacin Modelo ER a RelacionalReglas detalladas de TransformacinTransformacin de atributos derivadosNo existe una representacin directa. Por tanto, se deben tratar como atributos normales, que pasarn a ser columnas de la tabla correspondiente. Adems se deber, construir un disparador 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 aadir las restricciones correspondientes.

Sergio Snchez

Transformacin Modelo ER a Relacional EjerciciosTransforme a modelo relacional los ejercicios que fueron resueltos por ustedes en la Tarea de Modelo E/R Ejercicio 1 Ejercicio 2

Sergio Snchez

Normalizacin Modelo RelacionalLa normalizacin es un concepto de las bases de datos relacionales, pero sus principios se aplican al modelamiento de datos conceptuales. Una vez creadas las tablas hay que verificarlas y revisar si an se puede reducir u optimizar de alguna manera. Los problemas tales como la redundancia que ocurren cuando se abarrotan demasiados datos en un sola relacin son llamados anomalas. Los principales tipos son:Redundancia: la informacin se repite innecesariamente en muchas tuplas. Anomalas de actualizacin: cuando al cambiar la informacin en una tupla se descuida el actualizarla en otra. Anomalas de eliminacin: si un conjunto de valores llegan a estar vacos y se llega a perder informacin relacionada como un efecto de la eliminacin.

Sergio Snchez

Normalizacin Modelo RelacionalPrimera Forma Normal 1FNUna relacin est en primera forma normal si todo atributo contiene un valor atmico (valor unitario). Es decir, cada atributo tiene un solo valor para cada ocurrencia de la entidad. Ningn atributo tendra valores repetidos o que conforman un grupo. Ejemplos: Persona (cedula, nombre, apellido, sexo, telfono, direccin )Los primeros cinco atributos son atmicos, lo que implica que esta relacin Persona esta en 1FN. Estudiante ( cedula, nombre, apellido, escuela, materias, notas ) Los primeros cuatro atributos son atmicos, pero tambin es claro que los dos ltimos no estn en 1FN.Para convertirla a 1FN se proyecta en dos relaciones, obteniendo: Estudiante (cedula, apellido, nombre, escuela) Cursa (cedula, materia, nota )Sergio Snchez

Normalizacin Modelo RelacionalSegunda Forma Normal 2FNUna relacin est en segunda forma normal si y solo si: La relacin esta en 1FN

Todo atributo que no pertenece a una clave no puede depender de una parte de esa clave.

Ejemplo: Proveedor ( codProv, codArt, dirProv, precio ) Est relacin esta en 1FN, pero dado lo siguiente: (codProv, codArt ) precio (precio depende de la clave primaria por completo ), (codProv) dirProv (dirProv solo depende de una parte de la clave codProv). Por lo tanto est relacin no est en 2FN, pues hay un atributo no clave (dirProv) que depende de una parte de la clave.Sergio Snchez

Normalizacin Modelo RelacionalSegunda Forma Normal 2FNEjemplo:

Proveedor ( codProv, codArt, dirProv, precio )Para normalizar se proyecta en dos relaciones: Proveedor (codProv, dirProv) ProveeArticulos (codProv, codArt, precio) Carro ( placa, marca, modelo, color) Est relacin est en 2FN.

Sergio Snchez

Normalizacin Modelo RelacionalTercera Forma Normal 3FNUna relacin est en tercera forma normal si y solo si:

La relacin est en 2FN. Todo atributo que no pertenece a la clave no depende de un atributo que no es clave.

Ejemplo: Carro (placa, marca, modelo, color) Est en 2FN, pero no en tercera forma normal, ya que el atributo marca depende del modelo y este no es parte de la clave primaria. Para normalizar se proyecta en dos relaciones. Carro (placa, modelo, color) ModelosDeCarros ( modelo, marca)Sergio Snchez

Normalizacin Modelo RelacionalTercera Forma Normal 3FNEjemplo:

Orden ( id_orden, fecha, id_cliente, nombre_cliente )Est en 2FN pero no en 3FN, ya que el nombre del cliente depende del id_cliente que no es una clave primaria. Para normalizar se propaga de la siguiente forma: Cliente ( id_cliente, nombre_cliente )

Orden ( id_orden, id_cliente, fecha )

Un esquema normalizado hasta 3FN debe cumplir con el juramento siguiente: Jura usted que cada columna de cada fila depende: De la clave (1FN). De toda la clave (2FN). Nada mas que de la clave (3FN).Sergio Snchez

Normalizacin Modelo RelacionalForma Normal de Boyce-Codd (FNBC)Dependencias Funcionales (FD)

En el diseo de esquemas de bases de datos el concepto de dependencia funcional (functional dependency) es vital para eliminar "redundancia", otros factores sera el manejo de dependencias multivaluadas y las restricciones de integridad referencial.Una dependencia funcional en una relacin R es una enunciado de la forma "si dos tuplas de R concuerdan en los atributos A1,A2,...An (tienen los mismos valores para cada atributo), entonces deben concordar tambin con otro atributo B" . Esta FD se escribira como A1,A2,....An --> B y se dice que "A1, A2,....An determina funcionalmente a B". Si por otro lado un conjunto de atributos A1,A2...An determina funcionalmente a ms de un atributo. A1, A2, , An B1; A1, A2, , An B2 ; .. ; A1, A2, , An BnSergio Snchez

Normalizacin Modelo RelacionalForma Normal de Boyce-Codd (FNBC)Dependencias Funcionales (FD)

Ejemplo:Movies(title, year, length, filmType, studioName, starName)

(title, year) length; (title, year) filmType; (title, year) studiName; (title, year) starNameSergio Snchez

Normalizacin Modelo RelacionalForma Normal de Boyce-Codd (FNBC)Dependencias Funcionales (FD) Quizs las dependencias funcionales ms evidentes sean las llaves. Decimos que un conjunto { A1, A2,....An } es una llave de un relacin si:Esos atributos determinan funcionalmente a "todos" los dems atributos de una relacin. No hay un subconjunto de { A1, A2,....An } que determine funcionalmente a "todos" los dems atributos (incluyendo al resto del conjunto { A1, A2,....An })

Sergio Snchez

Normalizacin Modelo RelacionalForma Normal de Boyce-Codd (FNBC)Definicin FNBC Una relacin esta en FNBC si y solo si las solas dependencias funcionales elementales son aquellas dentro de las cuales una clave determina un atributo. Ejemplo: Examen (cedEst, codMat, cedProf, nota ) Dependencias Funcionales (cedEst, codMat) cedProf (cedEst, codMat) nota cedProf codMatSergio Snchez

Normalizacin Modelo RelacionalForma Normal de Boyce-Codd (FNBC)Definicin FNBC Ejemplo: Est en 3FN no esta FNBC. Para resolver el problema se proyecta para que cumpla con la FNBC: Examen ( cedEst, codMat, nota ) Dicta ( codMat, cedProf ) No se preserva la DFE (cedEst, codMat ) cedProf

Sergio Snchez

Bibliografa Introduccin a los Sistemas de Base de Datos, C. J. Date, Prentice Hall Sptima Edicin, 2001. Bases de Datos Relacionales, Matilde Celma Gimnez & Juan Casamayor & Laura Mota, Prentice Hall, 2003.

Ctedra Introduccin a las bases de datos, Profesor L. Marti, Universidad de Valparaso, 2004.

Sergio Snchez