Unidad 5 TransformacióN Er A Relacional NormalizacióN

Sergio Sánchez

Bases de DatosUnidad V

Transformación Modelo ER a Relacional - Normalización

Sergio Sánchez Rios.

Ingeniero en Informática – Licenciado en Informática

Docente Jornada Parcial Universidad Viña del Mar

Sergio Sánchez

Transformación Modelo ER a RelacionalTres reglas básicas

Las tres reglas básicas para convertir un esquema en el modelo E/R al relacional son las siguientes:

1) Todo tipo de entidad se convierte en una relación.

2) Todo tipo de relación M:M (muchos a muchos) se transforma en una relación.

3) 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.

Sergio Sánchez

Transformación Modelo ER a RelacionalTres reglas básicas

Debido a que el modelo relacional no distingue entre entidades y relaciones, ambos conceptos deben representarse mediante relaciones. Esto implica una perdida de semántica 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 propagación de clave, desapareciendo incluso el nombre de la relación.

Sergio Sánchez

Transformación Modelo ER a RelacionalTres reglas básicas - Ejemplo

EDITORIAL LIBRO AUTOREDITA ESCRIBE

1 n n n

Nombre_eCodigo Nombre_a

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

EDITORIAL( Nombre_e, Dirección, Ciudad, País)

AUTOR( Nombre_a, Nacionalidad, Institución)

ESCRIBE(Nombre_a, Código)

CLAVE AJENA

Sergio Sánchez

Transformación Modelo ER a RelacionalReglas detalladas de Transformación

Transformación de Entidades

Cada tipo de entidad se convierte en una tabla.

La tabla se llamará igual que el tipo de entidad de donde proviene.

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-.

Esta regla se divide en subreglas.

Sergio Sánchez



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.

Sergio Sánchez



PROFESOR

Dirección

Télefono

Materia

Cod_Prof

Nombre

DNI

Cod_prof Nombre DNI Dirección Teléfono Materia

PROFESOR

CREATE TABLE Profesor (

Cod_Prof Código,

Nombre Nombres,

DNI DNIS, NOT NULL

Dirección Lugares,

Télefono Nos_Teléfono,

Materia Materias,

PRIMARY KEY (Cod_prof),

UNIQUE (DNI) );

Sergio Sánchez



Atributos Multivaluados

Puesto que el modelo relacional no permite dominios multivaluados, 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.

Además, se debe crear una clave ajena referenciado a la tabla primaria.

PROFESOR

Télefono

Cod_Prof

Nombre

n

Persona ( dni, nombre, ……)

Telefonos ( dni, número )

CLAVE AJENA

Sergio Sánchez


Transformación de relaciones M:M

Un tipo de relación M:M se transforma en una tabla que tendrá como clave primaria la concatenación de las claves primarias (CP) 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 ajenas que referencian a las tablas en que se han convertido las entidades relacionadas (claves primarias).

PROFESOR

CURSO

IMPARTE

n

n

Cod_prof

Cod_curso

Modelo Relacional

PROFESOR ( Cod_prof, ….. )

CURSO ( Cod_curso )

IMPARTE ( Cod_curso, Cod_prof )

Sergio Sánchez


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 ).

Sergio Sánchez


Transformación de relaciones 1:N

PROFESOR

DEPARTAMENTO

PERTENECE

n

1

Cod_prof

Cod_dep

Modelo Relacional

PROFESOR ( Cod_prof, ….., Cod_dep )

DEPARTAMENTO (Cod_dep, … )

Sergio Sánchez


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.

Sergio Sánchez



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

HOMBRE

MUJER

MATRIMONIO

(0,1)

(0,1)

Cod_Hombre

Cod_Mujer

Modelo Relacional

MATRIMONIO (Cod_Hombre, Cod_Mujer)

HOMBRE ( Cod_Hombre )

MUJER ( Cod_Mujer )

Clave Alternativa

UNIQUE, NOT NULL

Sergio Sánchez



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.

Modelo Relacional

PROFESOR ( Cod_prof )

DEPARTAMENTO ( Cod_dep, Cod_prof )

PROFESOR

DEPARTAMENTO

RESPONSABLE

(1,1)

(0,1)

Cod_prof

Cod_dep Clave Ajena

NOT NULL

Sergio Sánchez



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.

Sergio Sánchez


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.

PROFESOR

CURSO

IMPARTE

1,n

1,n

Cod_prof

Cod_curso

Nro_Horas

Modelo Relacional

PROFESOR ( Cod_prof, …..)

IMPARTE ( Cod_prof, Cod_curso, Num_Hora )

CURSO ( Cod_curso, …)

Sergio Sánchez


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.

CURSO

EDICION

TIENE

Cod_Curso

Cod_Edición

Modelo Relacional

CURSO ( Cód_Curso, …. )

EDICION ( Cód_edicion, Cod_curso, ….)

Clave Ajena – NOT NULL – On Delete Cascade – On Update Cascada.

Sergio Sánchez


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. En general, se debe adoptar esta solución 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 solución 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, además de los atributos propios, los atributos comunes. Se elegirá esta opción cuando se den las mismas condiciones anteriores.

Sergio Sánchez



Ejemplo:

PROFESOR

DOCTOR NO DOCTOR

Año_doc

Materia_doc

Sergio Sánchez



Ejemplo:

Transformación

Opción a) PROFESOR (Cod_prof, nombre, ….., tipo, Año_doc, Materia_doc,..)

Opción b) PROFESOR (Cod_prof, Nombre, ….)

DOCTOR (Cod_prof, …… )

NO_DOCTOR (Cod_prof, …..)

Opción c) DOCTOR (Cod_prof, Nombre, ……, Año_doc, ….)

NO_DOCTOR ( Cod_prof, Nombre, ……)

Sergio Sánchez



Aunque es posible elegir cualquiera de las tres estrategias para la transformación de un tipo y sus subtipos al modelo relacional,

desde un punto de vista exclusivamente semántico la opción b es la mejor.

desde el punto de vista de la eficiencia deberá tenerse en cuenta que:

Opción a: el acceso a una fila que refleje toda la información de una determinada entidad es mucho más rápido (no hace falta combinar varias tablas).

Opción b: la menos eficiente aunque es la mejor desde un punto de vista exclusivamente semántico.

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. Esta solución es la que pierde más semántica.

Sergio Sánchez



Se deberá elegir una estrategia u otra dependiendo de que sea la semántica o la eficiencia la que prime para el usuario en un momento determinado.

Sergio Sánchez


Transformación de 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. Además 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 añadir las restricciones correspondientes.

Sergio Sánchez

Transformación Modelo ER a RelacionalEjercicios

Transforme a modelo relacional los ejercicios que fueron resueltos por ustedes en la Tarea de Modelo E/R

Ejercicio 1

Ejercicio 2

Sergio Sánchez

Normalización Modelo Relacional

La normalización 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 aún se puede reducir u optimizar de alguna manera.

Los problemas tales como la redundancia que ocurren cuando se abarrotan demasiados datos en un sola relación son llamados anomalías. Los principales tipos son:

Redundancia: la información se repite innecesariamente en muchas tuplas.

Anomalías de actualización: cuando al cambiar la información en una tupla se descuida el actualizarla en otra.

Anomalías de eliminación: si un conjunto de valores llegan a estar vacíos y se llega a perder información relacionada como un efecto de la eliminación.

Sergio Sánchez

Normalización Modelo RelacionalPrimera Forma Normal 1FN

Una relación está en primera forma normal si todo atributo contiene un valor atómico (valor unitario).

Es decir, cada atributo tiene un solo valor para cada ocurrencia de la entidad. Ningún atributo tendría valores repetidos o que conforman un grupo.

Ejemplos:

Persona (cedula, nombre, apellido, sexo, teléfono, dirección )

Los primeros cinco atributos son atómicos, lo que implica que esta relación Persona esta en 1FN.

Estudiante ( cedula, nombre, apellido, escuela, materias, notas )

Los primeros cuatro atributos son atómicos, pero también es claro que los dos últimos no están en 1FN.Para convertirla a 1FN se proyecta en dos relaciones, obteniendo:

Estudiante (cedula, apellido, nombre, escuela)

Cursa (cedula, materia, nota )

Sergio Sánchez

Normalización Modelo RelacionalSegunda Forma Normal 2FN

Una relación está en segunda forma normal si y solo si:

La relación 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á relación 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á relación no está en 2FN, pues hay un atributo no clave (dirProv) que depende de una parte de la clave.

Sergio Sánchez

Normalización Modelo RelacionalSegunda Forma Normal 2FN

Ejemplo:

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á relación está en 2FN.

Sergio Sánchez

Normalización Modelo RelacionalTercera Forma Normal 3FN

Una relación está en tercera forma normal si y solo si:

La relación 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 Sánchez

Normalización Modelo RelacionalTercera Forma Normal 3FN

Ejemplo:

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 Sánchez

Normalización Modelo RelacionalForma Normal de Boyce-Codd (FNBC)

Dependencias Funcionales (FD)

En el diseño de esquemas de bases de datos el concepto de dependencia funcional (functional dependency) es vital para eliminar "redundancia", otros factores sería el manejo de dependencias multivaluadas y las restricciones de integridad referencial.

Una dependencia funcional en una relación 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 también con otro atributo B" . Esta FD se escribiría 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 más de un atributo.

A1, A2, ……, An B1; A1, A2, ……, An B2 ; ….. ; A1, A2, ……, An Bn

Sergio Sánchez



Ejemplo:

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

(title, year) length; (title, year) filmType; (title, year) studiName; (title, year) starName

Sergio Sánchez



Quizás las dependencias funcionales más evidentes sean las llaves.

Decimos que un conjunto { A1, A2,....An } es una llave de un relación si:

Esos atributos determinan funcionalmente a "todos" los demás atributos de una relación. No hay un subconjunto de { A1, A2,....An } que determine funcionalmente a "todos" los demás atributos (incluyendo al resto del conjunto { A1, A2,....An })

Sergio Sánchez


Definición FNBC

Una relación 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 codMat

Sergio Sánchez


Definición 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 Sánchez

Bibliografía

“Introducción a los Sistemas de Base de Datos”, C. J. Date, Prentice Hall – Séptima Edición, 2001.

“Bases de Datos Relacionales”, Matilde Celma Giménez & Juan Casamayor & Laura Mota, Prentice Hall, 2003.

Cátedra “Introducción a las bases de datos”, Profesor L. Marti, Universidad de Valparaíso, 2004.

Unidad 5 TransformacióN Er A Relacional NormalizacióN

Technology

Transcript of Unidad 5 TransformacióN Er A Relacional NormalizacióN