Curso BD (05-1) Normalizacion

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

description

Curso BD (05-1) Normalizacion

Transcript of Curso BD (05-1) Normalizacion

  • 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