Curso BD (05-1) Normalizacion1

El término normalización se refiere a la manera en que los atributos son agrupados en los esquemas de relaciones de una base de datos, a fin de evitar anomalías y problemas que pueden ocurrir con los datos. JU

AN

ING

EN

IER

IA

M

4500

Cuando se agrupa atributos para formar un esquema de relación, buscaremos que exista un significado asociado a los atributos escogidos.

La semántica especifica que relación hay entre los valores de los atributos de una fila.

Cuanto más fácil sea explicar la semántica de la relación, mejor será el diseño del esquema correspondiente.

EJEMPLO :

El significado del esquema de relación empleado es sencillo : cada fila representa a un empleado, con valores para su código, nombre, fecha de nacimiento, sexo, sueldo y para el número de departamento al que pertenece (numDep). El atributo numDep es una clave foránea que representa un vínculo implícito entre empleado y departamento, es decir un empleado pertenece a un departamento.

numDep nom codJefefe fechIniJefe

DEPARTAMENTO

codEm nom fechNac direc sexo suel numDep

EMPLEADO

Son problemas que se presentan en el manejo de los datos, ocasionados por un mal diseño de la base de datos. Estas anomalías pueden clasificarse en :

Anomalías de Inserción

Anomalías de Eliminación

Anomalías de Modificación

Aquí vemos un mal diseño, donde hay datos de empleado y de departamento juntos.

codEm nom fechNac direc suel nDep nomDep codJefe

EMPLEADO

100 Soler Ana 10-06-65 Flores 129 3400 5 Ingeniería 800

200 Alva Juan 19-03-67 Valles 722 6200 5 Ingeniería 800

250 Jobe Alan 11-09-69 Mar 1824 3600 4 Ventas 900

300 Vall Kate 05-02-75 Jaén 181 2400 4 Ventas 900

800 Com Ivan 15-03-72 Grau 485 7600 5 Ingeniería 999

900 Kori Rony 07-12-59 Lomas 18 7200 4 Ventas 999

999 Pita Inés 25-03-72 Liz 1151 9500 1 Gerencia 999

Datos del empleado

Datos del departamento

A continuación veremos mediante dos casos, los problemas derivados con la inserción :

INSERCIóN DE UN NUEVO EMPLEADO : Al insertar un nuevo empleado, debemos también incluir los atributos del departamento al que pertenece, en caso el empleado todavía no sea asignado a ningún departamento colocaremos nulos.El problema que puede presentarse es cuando ingresemos mal los datos del departamento de algún empleado. Así tendremos empleados que trabajan en el mismo departamento, donde la información del departamento es inconsistente.


EMPLEADO








350 More Ann 15-11-75 Onda 156 3500 5 Ventas 800

malmal

INSERCIóN DE UN NUEVO DEPARTAMENTO : cuando se inserta un nuevo departamento, debemos tener en cuenta que todavía no tiene empleados . Por tanto debemos colocar valores nulos en los atributos de empleado

Un problemaUn problema es que la clave primaria codEm del empleado no puede ser nulaOtra anomalíaOtra anomalía es que al querer eliminar un departamento se eliminarán tambien los empleados.


EMPLEADO








7 Finanzas 950

nulosnulos Nuevo Nuevo departamentodepartamento

Este problema se relaciona con el segundo caso de anomalía de inserción. Por ejemplo, si en un departamento trabajan tres empleados y estos deciden renunciar, como es natural debemos eliminarlos de la relación, ocurrirá entonces que se perderá toda la información de ese departamento.


EMPLEADO













Ventas

Ventas

Ventas

En el ejemplo dado, si alteramos el valor de alguno de los atributos de un departamento ( por ejemplo el código del jefe de Ingeniería de Ana soler )



950

Nos veríamos obligados a actualizar todas las tuplas de todos los empleados del departamento de Ingeniería. De lo contrario la base de datos se tornaría inconsistente.

SOLUCION A LAS ANOMALIAS SOLUCION A LAS ANOMALIAS : Descomponer la relación, separando la parte que es responsable de la generación de las anomalías. En este ejemplo serían los atributos del departamento que pasarían a formar una nueva relación :

numDep nomDep codJefefe

DEPARTAMENTO

codEm nom fechNac direc suel nDep

EMPLEADO

Asegurarse de crear el vínculo necesario :

FK - PK

Fue Edgar F. Codd quien en 1972 propuso el proceso de normalización, así cualquier esquema de relación se puede someter a una serie de pruebas para certificar si pertenece o no a cierta forma normal, que originalmente fueron tres : primera, segunda y tercera formas normales.

Posteriormente Boyce y Codd replantearon la tercera forma normal que se conoce hoy como Boice - Codd Norm Form ( BCNF). La segunda y tercera formas se fundamentan en el concepto de dependencias funcionales.

Después se formularon la cuarta y quinta forma normal, basados en dependencias multivaluadas y dependencias de reunión.

Se implementó para prohibir atributos compuestos, multivaluados y sus combinaciones. Entonces debemos evitar grupos repetitivos de datos.

EJEMPLO :EJEMPLO :

numDep nomDep codJefefe lugaresDep

DEPARTAMENTO

Un departamento puede estar distribuido en varios lugares. Por ejemplo el Departamento de Ingeniería ( numDep=5) puede tener oficinas en Cuzco y Tacna (lugaresDep)

numDep nomDep codJefefe lugaresDep

5 Ingeniería 400 Tacna

5 Ingeniería 400 Cuzco

4 Administración 200 Trujillo

El atributo multivaluado obliga a replicar la información del departamento,

generando redundancia. Esta solución ya esta en 1FN , pero no es aceptable

porque genera anomalías de modificación.

Para este ejemplo el esquema

departamento no esta en

1FN

Grupo Grupo repetitivorepetitivo

LA SOLUCIÓN :LA SOLUCIÓN :

Es eliminar de la relación departamento el atributo lugaresDep ( grupo repetitivo) que viola la 1FN y colocarlo en otra relación aparte que llamaríamos lugares_depa . Esta nueva relación tendría como atributos : la clave primaria de la relación departamento ( para asegurar el vínculo entre estas dos relaciones ) y lugarDep ( contiene los nombres de los lugares )

La clave primaria de esta nueva relación es la combinación :

{ numDep , lugarDep }

DEPARTAMENTO


numDep lugarDep

LUGARES_DEPA


5 Ingeniería 400

4 Administración 200

DEPARTAMENTO

numDep lugarDep

4 Trujillo

5 Tacna

5 Cuzco

LUGARES_DEPA

EJEMPLO :EJEMPLO :

OBRERO

codObr nom fechNac direc jornal codJefe oficio añosExp

Se tiene el esquema OBRERO. Cada obrero puede tener mas de un oficio, así, el obrero Jorge Huamaní es carpintero, albañil y pintor y posee 3, 8 y 2 años de experiencia en esos oficios.Esto quiere decir que los atributos oficio y añosExp forman una unidad multivaluada, con lo que se esta violando la 1FNDicho de otro modo {oficio, añosExp} ocurren varias veces en una tupla. De esta forma la tupla ya no es plana.

Grupo Grupo repetitivorepetitivo

OBRERO

codObr nom fechNac direc jornal codJefe oficio añosExp

300 Huamaní Jorge 10-05-67 Surco 25 800 carpintero 3

300 Huamaní Jorge 10-05-67 Surco 25 800 albañil 3

300 Huamaní Jorge 10-05-67 Surco 25 800 pintor 2

350 Sulca Américo 22-11-70 Comas 30 900 electrónico 5

SOLUCION :SOLUCION :

Es eliminar el grupo repetitivo {oficio, añosExp} de la relación obrero, que viola la 1FN y colocarlo en otra relación aparte que llamaríamos habilidades . Esta nueva relación tendría como atributos : la clave primaria codObr de la relación obrero ( para asegurar el vínculo entre estas dos relaciones ) , además de oficio y añosExp.La clave primaria de la nueva relación habilidadeshabilidades estaría conformada por :

{ codObr , oficio }

OBRERO

codObr nom fechNac direc jornal codJefe

codObrcodObr oficiooficio añosExp

HABILIDADES

Sea el esquema de relación R :

R (( A1 , A2 , A3 , . . . Ak , Ak+1 , . . . Am , Am+1 , . . . At , At+1 , . . . An-1 , An ))

x yY los subconjuntos

Se dice que Y depende funcionalmentedepende funcionalmente de X , ó que X determina Y

x y

Si y solo si , cada valor de X tiene asociado en todo momento un únicoun único valor de Y

ó que X implica Yimplicante

implicado

EJEMPLO : EJEMPLO : Tenemos la relación :

LIBRO ( cod_Lib, titulo, editorial )

Se puede decir que el código de un libro determina su título.

GRAFICAMENTE : GRAFICAMENTE : Podemos mostrar gráficamente la dependencia funcional :

Cod_Lib

Cod_Lector

Titulo , editorial

Fech_prestamo , fecha_devol

nombre , direc , fono

determina

determina

determina

Aquí se dice que titulo depende funcionalmente de codLibtitulo depende funcionalmente de codLib

Este concepto de dependencia funcional también nos dice que el titulo es una información acerca del libro o también que para algún código de libro existe un único título que le corresponde.

EJEMPLO : EJEMPLO : Veamos las DFDF en el siguiente esquema de relación :

codEmp numProy nomEmp nomProy lugarProy

EMP_PROY

codEmp nomEmp

numProy { nomProy , lugarProy }Se lee :Se lee :

EMP_PROY ( codEmp, numProy, nomEmp, nomProy, lugarProy )

El valor del número de proyecto ( numProy ) determina de manera única el nombre del proyecto ( nomProy ) y su lugar ( lugarProy ).

El valor de código del empleado ( codEmp ) determina de manera única el nombre de ese empleado ( nomEmp ). Para un codEmp existe un único nombre de empleado.

EJEMPLO : EJEMPLO : Veamos las DFDF en este otro esquema de relación :

codEmp nomEmp fechNac direc numDep nomDep codJefe

EMP_DEPTO

codEmp { nomEmp , fechNac , direc }

numDep { nomDep , codJefe }

EMP_DEPTO ( codEmp, nomEmp, fechNac, direc, numDep, nomDep. codJefe )

EJEMPLO : EJEMPLO : Veamos cuando no existe dependencia funcional :

PROFESOR CURSO TEXTOBASE

Canales Julio Algoritmos II Cairo

Canales Julio Base de Datos Korth

Arias Freud Visual Basic Joyanes

Pacheco Rosa Leng. Prog I Vasquez

DICTAR

Se puede decir que profesor determina funcionalmente curso ?

RESPUESTA : RESPUESTA :

El hecho de que Canales Julio dicta Algoritmos II así como Base de Datos nos lleva a concluir que profesor no determina funcionalmente curso

EJEMPLO : EJEMPLO : Veamos cuando no existe dependencia funcional :

Código de empleado (codEmp) no es funcionalmente dependiente de sueldo, porque mas de un empleado podría tener el mismo sueldo

codEmp numProy nomEmp sueldo nomProy fechFin

EMPLE-PROY

codEmp no es funcionalmente dependiente de numProy, ya que mas de un empleado puede trabajar para el mismo proyecto

EMP_PROY ( codEmp, numProy, nomEmp, sueldo, nomProy, fechFin )

Pero fecha de fin de proyecto ( fechFin) si es funcionalmente dependiente de número de proyecto (numProy)

x y

Una simple dependencia funcional se define así :

Si X es un subconjunto de dos atributos : X ( X1 , X2 )

Se dice que Y tiene dependencia funcional completa de X si depende funcionalmente de X pero no depende de X1 ni de X2 , esto es :

x y

x1 y

x2 y

Lo que se representa como :

x y

Conocida también

como TOTAL

EJEMPLO : EJEMPLO : Veamos las DFDF en el siguiente esquema de relación :

codEmp numProy horas nomEmp nomProy lugarProy

EMP_PROY

codEmp nomEmp

numProy { nomProy , lugarProy }

La combinación de valores de ( codEmp ) y ( numProy ) determinan de manera única el número de horas ( horas ) que el empleado trabaja en un proyecto cada semana. Ni código de empleado, ni tampoco número de proyecto, determinan por si solos, las horas trabajadas, ya que un empleado puede tener diferentes horas trabajadas en diferentes proyectos, asi como un proyecto tiene diversas horas de trabajo de diferentes empleados. Por tanto, respecto al atributo HORAS tenemos una dependencia funcional completa :

{ codEmp , numProy } horas

Dependencia funcional completa

Dependencia funcional parcial

Dependencias funcionales parciales

EJEMPLO : EJEMPLO : Analizemos el siguiente esquema de relación :

codLibcodLib codLectorcodLector titulo editorial nombre direc fono fechPrest

PRESTAR

Dado un código de libro ( codLib ) y un código de lector ( codLector ) existe una única fecha de préstamo ( fechPrest ) para ese libro. Ni código de libro, ni tampoco código de lector, determinan por si solos, la fecha de préstamo, ya que un libro se puede prestar en diversas fechas, asi como un lector puede recibir libros prestados en diferentes fechas. Por tanto, tenemos una dependencia funcional completa :

{ codLib , codLector } fechPrest

PRESTAR ( codLib, codLector, titulo, editorial, nombre, direc, fono, fechPrest )


EJEMPLO : EJEMPLO : Indique gráficamente las dependencias funcionales del siguiente esquema de relación :

PROGRAM(codProgramador, codModulo, nomProgramador, nomModulo, horasTrab )

RESPUESTA : RESPUESTA :

codProgramador codModulo nomProgramador nomModulo horasTrab

PROGRAM




Es aquel atributo que forma parte de cualquier clave primaria o es clave candidata de una relación.

EMP_PROY

Atributos NO

PRIMOSAtributo PRIMO

Atributo PRIMO


Clave primaria

Un esquema de relación esta en segunda forma normal , si esta en primera forma normal y todo atributo no primotodo atributo no primo posee una dependencia funcional completacompleta de la clave primaria de la relación.

EJEMPLO : EJEMPLO : El siguiente esquema representa un mal diseño, el cual si bien no tiene atributos compuestos ni grupos repetitivos y por tanto esta en 1FN , sin embargosin embargo no esta en 2FN.

El atributo no primo nomEmp viola la 2FN debido a que su dependencia funcional de la clave primaria es solo parcial. Es decir, depende funcionalmente solo parcialmente de la clave primaria ( solo de codEmp ).


EMP_PROY

Clave primaria


nomEmp

NOTA :NOTA : el único atributo no primo que tiene dependencia funcional completa es horas

NOTA :NOTA : el único atributo no primo que tiene dependencia funcional completa es horas

El atributo no primo nomProy viola la 2FN debido a que su dependencia funcional de la clave primaria es solo parcial. Es decir, depende funcionalmente solo parcialmente de la clave primaria ( solo de numProy ).


EMP_PROY

Clave primaria


nomProy

El atributo no primo lugarProy viola la 2FN debido a que su dependencia funcional de la clave primaria es solo parcial. Es decir, depende funcionalmente solo parcialmente de la clave primaria ( solo de numProy ).


EMP_PROY

Clave primaria


lugarProy


EMP_PROYDependencias funcionales parciales

lugarProynomProy

ESTO SE ACOSTUMBRA GRAFICAR ASI :

SOLUCION : SOLUCION :

Como el esquema de relación no esta en 2FN, debemos normalizar a varias relaciones en 2FN en las que los atributos no primos originales presenten una dependencia funcional total respecto a las nuevas claves primarias formadas :

EMP_PROY

soluciónsolución


Identificadas las dependencias, quedan definidas las nuevas relaciones

codEmp numProy horas

HORAS_TRAB

codEmp nomEmp

EMPLE

numProy numProy lugarProy

PROYEC

EJERCICIO : EJERCICIO :

Una empresa comercializadora posee varias sucursales en diversas ciudades del país. Donde cada sucursal es identificada por su código de sucursal.

Cada sucursal tiene su staff de empleados, a los cuales se les reconoce por un código de empleado en la sucursal , el cual siempre empieza con el número 100.Lo que significa que para distinguir a un empleado de otro es necesario conocer el código de la sucursal y el código que el empleado tenga en la sucursal. Es importante registrar el DNI , la hora de ingreso al trabajo y el nombre de la sucursal.

codigoDeSucursal codigoEnSucursal DNI nom sueldo horaIngre nomSucursal

EMPLEADO

Atributo primo

Atributos no primos

Clave primaria

Entonces se pide normalizar el siguiente esquema de relación :

( Clave candidata )

Aquí de hecho están combinados datos de sucursal y datos de empleado. Descartando el atributo primo DNI, por que presenta la propiedad de unicidad ( clave candidata ) , nos centraremos en los atributos no primos : sueldo, horaIngre y nomSucursal.

SOLUCIÓN : SOLUCIÓN :

Datos de sucursal : horaIngre , nomSucursal

Datos de empleado : DNI , sueldo

1.1. Construyendo esquema para la sucursal :

codigoDeSucursal horaIngre nomSucursal

sucursal Ya esta en 1FN ( no hay grupos repetitivos ) y esta en 2FN ya que no hay clave múltiple. Por tanto horaIngre y nomSucursal dependen totalmente de la clave primaria

El sueldo de un empleado no depende únicamente del código del empleado en la sucursal, porque como ya sabemos estos códigos se repiten en cada sucursal. Por tanto :

2.2. Construyendo esquema para el empleado :

{codigoDeSucursal , codigoEnSucursal} sueldo

En consecuencia :

Ya esta en 1FN y en 2FN

codigoDeSucursal codigoEnSucursal DNI sueldo

EMPLEADO

EMPLEADOcodigoDeSucursal horaIngre nomSucursal

SUCURSAL

codigoDeSucursal codigoEnSucursal DNI sueldo

Documents

Curso BD (05-1) Normalizacion1