curso bd (05-1) normalizacion
DESCRIPTION
Curso BD (05-1) NormalizacionTRANSCRIPT
-
El trmino normalizacin 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 anomalas y
problemas que pueden ocurrir con los
datos.
M
-
Cuando agrupamos atributos para formar un
esquema de relacin, buscaremos que exista un
significado asociado a los atributos escogidos.
La semntica especifica que relacin hay entre los
valores de los atributos de una fila.
Cuanto mas fcil sea explicar la semntica de la
relacin , mejor ser el diseo del esquema
correspondiente.
-
EJEMPLO :
El significado del esquema de relacin empleado es sencillo :
cada fila representa a un empleado, con valores para su
cdigo, nombre, fecha de nacimiento, sexo, sueldo y para el
nmero de departamento al que pertenece ( nDep ). El
atributo nDep es una clave fornea que representa un vnculo
implcito entre empleado y departamento, es decir un
empleado pertenece a un departamento.
numDep nom codJefefe fechIniJefe
DEPARTAMENTO
codEm nom fechNac direc sexo suel nDep
EMPLEADO
-
Son problemas que se presentan en el manejo de los datos,
ocasionados por un mal diseo de la base de datos. Estas
anomalas pueden clasificarse en :
Anomalas de Insercin
Anomalas de Eliminacin
Anomalas de Modificacin
-
Aqu vemos un mal diseo, 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 Ingeniera 800
200 Alva Juan 19-03-67 Valles 722 6200 5 Ingeniera 800
250 Jobe Alan 11-09-69 Mar 1824 3600 4 Ventas 900
300 Vall Kate 05-02-75 Jan 181 2400 4 Ventas 900
800 Com Ivan 15-03-72 Grau 485 7600 5 Ingeniera 999
900 Kori Rony 07-12-59 Lomas 18 7200 4 Ventas 999
999 Pita Ins 25-03-72 Liz 1151 9500 1 Gerencia 999
Datos del
empleado
Datos del
departamento
A continuacin veremos mediante dos casos, los problemas
derivados con la insercin :
-
INSERCIN DE UN NUEVO EMPLEADO : Al insertar un nuevo empleado, debemos tambin incluir los atributos del departamento al que
pertenece, en caso el empleado todava no sea asignado a ningn departamento colocaremos nulos.
El problema que puede presentarse es cuando ingresemos mal los datos del
departamento de algn empleado. As tendremos empleados que trabajan en el
mismo departamento, donde la informacin del departamento es inconsistente.
codEm nom fechNac direc suel nDep nomDep codJefe
EMPLEADO
100 Soler Ana 10-06-65 Flores 129 3400 5 Ingeniera 800
200 Alva Juan 19-03-67 Valles 722 6200 5 Ingeniera 800
250 Jobe Alan 11-09-69 Mar 1824 3600 4 Ventas 900
300 Vall Kate 05-02-75 Jan 181 2400 4 Ventas 900
800 Com Ivan 15-03-72 Grau 485 7600 5 Ingeniera 999
900 Kori Rony 07-12-59 Lomas 18 7200 4 Ventas 999
999 Pita Ins 25-03-72 Liz 1151 9500 1 Gerencia 999
350 More Ann 15-11-75 Onda 156 3500 5 Ventas 800
mal
-
INSERCIN DE UN NUEVO DEPARTAMENTO : cuando se inserta un nuevo departamento, debemos tener en cuenta que todava no tiene empleados .
Por tanto debemos colocar valores nulos en los atributos de empleado
Un problema es que la clave primaria codEm del empleado no puede ser nula
Otra anomala es que al querer eliminar un departamento se eliminarn tambien
los empleados.
codEm nom fechNac direc suel nDep nomDep codJefe
EMPLEADO
100 Soler Ana 10-06-65 Flores 129 3400 5 Ingeniera 800
200 Alva Juan 19-03-67 Valles 722 6200 5 Ingeniera 800
250 Jobe Alan 11-09-69 Mar 1824 3600 4 Ventas 900
300 Vall Kate 05-02-75 Jan 181 2400 4 Ventas 900
800 Com Ivan 15-03-72 Grau 485 7600 5 Ingeniera 999
900 Kori Rony 07-12-59 Lomas 18 7200 4 Ventas 999
999 Pita Ins 25-03-72 Liz 1151 9500 1 Gerencia 999
7 Finanzas 950
nulosNuevo
departamento
-
Este problema se relaciona con el segundo caso de anomala de insercin.
Por ejemplo, si en un departamento trabajan tres empleados y estos deciden
renunciar, como es natural debemos eliminarlos de la relacin, ocurrir
entonces que se perder toda la informacin de ese departamento.
codEm nom fechNac direc suel nDep nomDep codJefe
EMPLEADO
100 Soler Ana 10-06-65 Flores 129 3400 5 Ingeniera 800
200 Alva Juan 19-03-67 Valles 722 6200 5 Ingeniera 800
250 Jobe Alan 11-09-69 Mar 1824 3600 4 Ventas 900
300 Vall Kate 05-02-75 Jan 181 2400 4 Ventas 900
800 Com Ivan 15-03-72 Grau 485 7600 5 Ingeniera 999
900 Kori Rony 07-12-59 Lomas 18 7200 4 Ventas 999
999 Pita Ins 25-03-72 Liz 1151 9500 1 Gerencia 999
codEm nom fechNac direc suel nDep nomDep codJefe
100 Soler Ana 10-06-65 Flores 129 3400 5 Ingeniera 800
200 Alva Juan 19-03-67 Valles 722 6200 5 Ingeniera 800
800 Com Ivan 15-03-72 Grau 485 7600 5 Ingeniera 999
999 Pita Ins 25-03-72 Liz 1151 9500 1 Gerencia 999
Ventas
Ventas
Ventas
-
En el ejemplo dado, si alteramos el valor de alguno de los atributos de un
departamento ( por ejemplo el cdigo del jefe de Ingeniera de Ana soler )
codEm nom fechNac direc suel nDep nomDep codJefe
100 Soler Ana 10-06-65 Flores 129 3400 5 Ingeniera 800
950
Nos veramos obligados a actualizar todas las tuplas de todos los empleados
del departamento de Ingeniera. De lo contrario la base de datos se tornara
inconsistente.
SOLUCION A LAS ANOMALIAS : Descomponer la relacin, separando la
parte que es responsable de la generacin de las anomalas. En este ejemplo
seran los atributos del departamento que pasaran a formar una nueva
relacin :
numDep nomDep codJefefe
DEPARTAMENTO
codEm nom fechNac direc suel nDep
EMPLEADO
Asegurarse de crear
el vnculo necesario :
FK - PK
-
Fue Edgar F. Codd quien en 1972 propuso el proceso de
normalizacin, as cualquier esquema de relacin 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.
Despus se formularon la cuarta y quinta forma normal,
basados en dependencias multivaluadas y dependencias
de reunin.
-
Se implement para prohibir atributos compuestos, multivaluados y sus
combinaciones. Entonces debemos evitar grupos repetitivos de datos.
EJEMPLO :
numDep nomDep codJefefe lugaresDep
DEPARTAMENTO
Un departamento puede estar distribuido en varios lugares.
Por ejemplo el Departamento de Ingeniera ( numDep=5)
puede tener oficinas en Cuzco y Tacna (lugaresDep)
numDep nomDep codJefefe lugaresDep
5 Ingeniera 400 Tacna
5 Ingeniera 400 Cuzco
4 Administracin 200 Trujillo
El atributo multivaluado obliga a replicar
la informacin del departamento,
generando redundancia. Esta solucin
ya esta en 1FN , pero no es aceptable
porque genera anomalas de
modificacin.
Para este
ejemplo el
esquema
departamento
no esta en
1FN
Grupo
repetitivo
-
LA SOLUCION :
Es eliminar de la relacin departamento el atributo lugaresDep ( grupo repetitivo) que viola la 1FN y colocarlo en otra relacin aparte que
llamaramos lugares_depa . Esta nueva relacin tendra como atributos : la
clave primaria de la relacin departamento ( para asegurar el vnculo entre
estas dos relaciones ) y lugarDep ( contiene los nombres de los lugares )
La clave primaria de esta nueva relacin es la combinacin :
{ numDep , lugarDep }
DEPARTAMENTO
numDep nomDep codJefefe
numDep lugarDep
LUGARES_DEPA
numDep nomDep codJefefe
5 Ingeniera 400
4 Administracin 200
DEPARTAMENTO
numDep lugarDep
4 Trujillo
5 Tacna
5 Cuzco
LUGARES_DEPA
-
EJEMPLO :
OBRERO
codObr nom fechNac direc jornal codJefe oficio aosExp
Se tiene el esquema OBRERO. Cada obrero puede tener mas de un oficio,
as, el obrero Jorge Huaman es carpintero, albail y pintor y posee 3, 8 y 2
aos de experiencia en esos oficios.
Esto quiere decir que los atributos oficio y aosExp forman una unidad
multivaluada, con lo que se esta violando la 1FN
Dicho de otro modo {oficio, aosExp} ocurren varias veces en una tupla. De
esta forma la tupla ya no es plana. Grupo
repetitivo
OBRERO
codObr nom fechNac direc jornal codJefe oficio aosExp
300 Huaman Jorge 10-05-67 Surco 25 800 carpintero 3
300 Huaman Jorge 10-05-67 Surco 25 800 albail 3
300 Huaman Jorge 10-05-67 Surco 25 800 pintor 2
350 Sulca Amrico 22-11-70 Comas 30 900 electrnico 5
-
SOLUCION :
Es eliminar el grupo repetitivo {oficio, aosExp} de la relacin obrero, que
viola la 1FN y colocarlo en otra relacin aparte que llamaramos
habilidades . Esta nueva relacin tendra como atributos : la clave primaria
codObr de la relacin obrero ( para asegurar el vnculo entre estas dos
relaciones ) , adems de oficio y aosExp.
La clave primaria de la nueva relacin habilidades estara conformada por :
{ codObr , oficio }
OBRERO
codObr nom fechNac direc jornal codJefe
codObr oficio aosExp
HABILIDADES
-
Sea el esquema de relacin 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 funcionalmente de X , que X determina Y
x y
Si y solo si , cada valor de X tiene asociado en todo momento un nico valor de Y
que X implica Yimplicante
implicado
-
EJEMPLO : Tenemos la relacin :
LIBRO ( cod_Lib, titulo, editorial )
Se puede decir que el
cdigo de un libro
determina su ttulo.
GRAFICAMENTE : Podemos mostrar grficamente 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 codLib
Este concepto de dependencia funcional tambin nos dice que el titulo es
una informacin acerca del libro o tambin que para algn cdigo de
libro existe un nico ttulo que le corresponde.
-
EJEMPLO : Veamos las DF en el siguiente esquema de relacin :
codEmp numProy nomEmp nomProy lugarProy
EMP_PROY
codEmp nomEmp
numProy { nomProy , lugarProy }Se lee :
EMP_PROY ( codEmp, numProy, nomEmp, nomProy, lugarProy )
El valor del nmero de proyecto ( numProy ) determina de manera nica el
nombre del proyecto ( nomProy ) y su lugar ( lugarProy ).
El valor de cdigo del empleado ( codEmp ) determina de manera nica el
nombre de ese empleado ( nomEmp ). Para un codEmp existe un nico
nombre de empleado.
-
EJEMPLO : Veamos las DF en este otro esquema de relacin :
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 : 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 :
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 : Veamos cuando no existe dependencia funcional :
Cdigo de empleado (codEmp) no es funcionalmente dependiente de
sueldo, porque mas de un empleado podra 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 nmero 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
tambin
como TOTAL
-
EJEMPLO : Veamos las DF en el siguiente esquema de relacin :
codEmp numProy horas nomEmp nomProy lugarProy
EMP_PROY
codEmp nomEmp
numProy { nomProy , lugarProy }
La combinacin de valores de ( codEmp ) y ( numProy ) determinan de
manera nica el nmero de horas ( horas ) que el empleado trabaja en un
proyecto cada semana. Ni cdigo de empleado, ni tampoco nmero 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 : Analizemos el siguiente esquema de relacin :
codLib codLector titulo editorial nombre direc fono fechPrest
PRESTAR
Dado un cdigo de libro ( codLib ) y un cdigo de lector ( codLector )
existe una nica fecha de prstamo ( fechPrest ) para ese libro. Ni cdigo
de libro, ni tampoco cdigo de lector, determinan por si solos, la fecha de
prstamo, 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 )
Dependencia funcional completa
-
EJEMPLO : Indique grficamente las dependencias funcionales del
siguiente esquema de relacin :
PROGRAM(codProgramador, codModulo, nomProgramador, nomModulo, horasTrab )
RESPUESTA :
codProgramador codModulo nomProgramador nomModulo horasTrab
PROGRAM
Dependencia funcional completa
Dependencia funcional parcial
Dependencia funcional parcial
-
Es aquel atributo que forma parte de cualquier clave primaria o es clave
candidata de una relacin.
EMP_PROY
Atributos
NO
PRIMOSAtributo
PRIMO
Atributo
PRIMO
codEmp numProy horas nomEmp nomProy lugarProy
Clave primaria
-
Un esquema de relacin esta en segunda forma normal , si esta en
primera forma normal y todo atributo no primo posee una
dependencia funcional completa de la clave primaria de la relacin.
EJEMPLO : El siguiente esquema representa un mal diseo, el cual si
bien no tiene atributos compuestos ni grupos repetitivos y
por tanto esta en 1FN , sin 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 ).
codEmp numProy horas nomEmp nomProy lugarProy
EMP_PROY
Clave primaria
Dependencia funcional parcial
nomEmp
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 ).
codEmp numProy horas nomEmp nomProy lugarProy
EMP_PROY
Clave primaria
Dependencia funcional parcial
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 ).
codEmp numProy horas nomEmp nomProy lugarProy
EMP_PROY
Clave primaria
Dependencia funcional parcial
lugarProy
codEmp numProy horas nomEmp nomProy lugarProy
EMP_PROYDependencias funcionales parciales
lugarProynomProy
ESTO SE ACOSTUMBRA GRAFICAR ASI :
-
SOLUCION :
Como el esquema de relacin 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
solucin
codEmp numProy horas nomEmp nomProy lugarProy
Identificadas las dependencias,
quedan definidas las nuevas relaciones
codEmp numProy horas
HORAS_TRAB
codEmp nomEmp
EMPLE
numProy numProy lugarProy
PROYEC
-
EJERCICIO :
Una empresa comercializadora posee varias sucursales en diversas ciudades del
pas. Donde cada sucursal es identificada por su cdigo de sucursal.
Cada sucursal tiene su staff de empleados, a los cuales se les reconoce por un
cdigo de empleado en la sucursal , el cual siempre empieza con el nmero 100.
Lo que significa que para distinguir a un empleado de otro es necesario conocer
el cdigo de la sucursal y el cdigo 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
primoAtributos
no primos
Clave primaria
Entonces se pide normalizar el siguiente esquema de relacin :
( Clave candidata )
-
Aqu de hecho estn 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.
SOLUCION :
Datos de sucursal : horaIngre , nomSucursal
Datos de empleado : DNI , sueldo
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 mltiple. Por tanto
horaIngre y nomSucursal
dependen totalmente de la
clave primaria
-
El sueldo de un empleado no depende nicamente del cdigo del
empleado en la sucursal, porque como ya sabemos estos cdigos se
repiten en cada sucursal. Por tanto :
2. Construyendo esquema para el empleado :
{codigoDeSucursal , codigoEnSucursal} sueldo
En consecuencia :
Ya esta en 1FN y en 2FN
codigoDeSucursal codigoEnSucursal DNI sueldo
EMPLEADO
EMPLEADO
codigoDeSucursal horaIngre nomSucursal
SUCURSAL
codigoDeSucursal codigoEnSucursal DNI sueldo