Normalizacion

26
Dis e ño de B ase de MCE. Jesús Carlos Sánchez 1 DISEÑO Y NORMALIZACIÓN DE LAS BASES DE DATOS. Concepto de Normalización. Normalización : Normalización es el proceso de convertir una relación (Tabla) en otras de forma tal que se cumplan ciertas restricciones. El proceso de normalización consiste básicamente en obtener un conjunto de tablas, dichas tablas se obtendrán utilizando proyecciones de la tabla original. Una característica fundamental de dichas proyecciones es que deben ser sin perdida ni ganancia, esto se refiere a que debe ser posible deducir de las tablas proyectadas la información original, ni más ni menos. Formas Normales: Dentro de la literatura se han definido diversas formas normales, pero las más difundidas se ilustran en la siguiente figura: Universo de relaciones Normalizadas y no Normalizadas 1FN 2 FN 3 FN FNBC 4 FN FN/PR (5FN) Primera, Segunda y Tercera Formas Normales.

description

como normalizar bases de datos hasta la 3 forma normal

Transcript of Normalizacion

Microsoft Word - Unidad 5.doc

DISEO Y NORMALIZACIN DE LAS BASES DE DATOS.Concepto de Normalizacin.Normalizacin:Normalizacin es el proceso de convertir una relacin (Tabla) en otras de forma tal que se cumplan ciertas restricciones.El proceso de normalizacin consiste bsicamente en obtener un conjunto de tablas, dichas tablas se obtendrn utilizando proyecciones de la tabla original. Una caracterstica fundamental de dichas proyecciones es que deben ser sin perdida ni ganancia, esto se refiere a que debe ser posible deducir de las tablas proyectadas la informacin original, ni ms ni menos.Formas Normales:Dentro de la literatura se han definido diversas formas normales, pero las ms difundidas se ilustran en la siguiente figura:Universo de relaciones Normalizadas y no Normalizadas1FN2 FN3 FNFNBC4 FNFN/PR (5FN)Primera, Segunda y Tercera Formas Normales.Primera Forma Normal (1FN)Una relacin esta en primera forma normal (1FN) sii (lase si solo si) todos los dominios base de los campos tienen valores atmicos. Es decir, un campo solo tiene un valor y no un conjunto de valores.Tomemos como ejemplo el caso de una relacin para llevar la informacin de materias y calificaciones de alumnos, un posible diseo seria el siguiente:MATRICULACALIFS

331678CB-001 10, MA-001 9

337890FS-001 7, HD-002 8

337777CB-002 7, CS-056 8

446789MA-031 7, CB-072 8, HD-002 9

Observando la relacin anterior nos damos cuenta que el dominio del campo MATRICULA si cumple la caracterstica de tener valores atmicos, pero el campo CALIFS tiene el problema de que el dominio utilizado proporciona un conjunto de valores, es decir, no esta en 1FN. Por lo tanto, se deduce que toda relacin normalizada se encuentra en 1FN.Un posible mejor diseo seria entonces:MATRICULACLAVECALIF

331678CB-00110

331678MA-0019

337890FS-0017

337890HD-0028

337777CB-0027

337777CS-0568

446789MA-0317

446789CV-0728

446789HD-0029

Revisando esta relacin observamos que todos los dominios de los campos proporcionan valores atmicos, es decir, ninguno de los campos tiene un conjunto de valores; por lo tanto esta relacin ya esta en 1FN.Segunda Forma Normal (2FN)Una relacin est en segunda forma normal sii est en 1FN y adems cumple la condicin de que cada atributo no-llave depende de la llave primaria.La llave primaria es el conjunto mnimo de atributos que cumplen la caracterstica de unicidad y que se escogi para ser la llave. Si existe ms de un conjunto mnimo de atributos que cumplen la unicidad, al conjunto escogido como llave se le llama llave primaria y a los dems conjuntos se les llama llaves candidato.Supongamos que tenemos una relacin que permite llevar la informacin de los proveedores de una empresa junto con las partes y la cantidad en la que son suministradas:NUM_PROVNOM_PROVCIUDADESTATUSNO_PARTECANTIDAD

S1JUANACAPULCO2P110

S1JUANACAPULCO2P210

S2PEDROMERIDA4P1200

S2PEDROMERIDA4P310

S2PEDROMERIDA4P5300

S3ANATIJUANA5P3200

S3ANATIJUANA5P410

S3ANATIJUANA5P5300

S4RENEDF1P1200

S5PATRICIAREYNOSA2P110

S5PATRICIAREYNOSA2P4200

S6RENATAOAXACA2P510

Considerando que la llave primaria es NUM_PROV, NUM_PARTE, tendramos las siguientes relaciones de dependencia entre los campos no llave y los campos de la llave candidato:NOM_PROVNUM_PROV

CIUDADESTATUSNUM_PARTE

CANTIDADDe la figura anterior podemos deducir que:Los atributos NOM_PROV, CIUDAD y ESTATUS dependen de NUM_PROV, mientras que el atributo CANTIDAD depende de NUM_PROV + NUM_PARTE.De lo anterior podemos concluir que la relacin no est en 2NF (pero si est en 1FN) debido a que no todos los campos llave dependen de la llave primaria, pues existen dependencias de otros atributos no-llave como lo es el atributo NUM_PARTE del cual depende el valor de CANTIDAD, dicho de otro modo, la CANTIDAD depende de NUM_PARTE.Para normalizar esta relacin es necesario realizar una proyeccin dando como resultado una tabla con los atributos que se muestran a continuacin a la cual podramos denominar Tabla S.NUM_PROVNOM_PROVCIUDADESTATUS

S1JUANACAPULCO2

S2PEDROMERIDA4

S3ANATIJUANA5

S4RENEDF1

S5PATRICIAREYNOSA2

S6RENATAOAXACA2

NOM_PROVNUM_PROV

CIUDADESTATUSAdems obtendremos una tabla ms denominada tabla SP la cual se muestra a continuacin:NUM_PROVNUM_PARTE

CANTIDADAs pues podemos concluir que: Dado que en las dos tablas obtenidas los atributos no-llave dependen solo del atributo llave, ambas tablas se encuentran en la 2FN.Tercera Forma Normal (3FN):Una relacin esta en 3FN sii esta en 2FN y adems se cumple que todos los atributos de la relacin no dependen transitivamente de la llave primaria.Es decir no se da la situacin de que un campo dependa de la llave y otro dependa del primero.Tomando como ejemplo la tabla siguiente:NUM_PROVNOM_PROVCIUDADESTADO

S1JUANACAPULCO2

S2PEDROMERIDA4

S3ANAMERIDA4

S4RENEACAPULCO2

S5PATRICIAREYNOSA6

S6RENATAREYNOSA6

Haciendo un anlisis de los atributos de la relacin anterior, podemos observar que el atributo ESTADO depende realmente de CIUDAD y no directamente del NUM_PROV, es decir se tiene la siguiente relacin de dependencia: ms claramente;NOM_PROVNUM_PROV

CIUDAD

NUM_PROV

NOM_PROVESTADO

CIUDAD ESTADOPara poder normalizar la relacin anterior es necesario realizar dos proyecciones y las tablas resultantes serian:NUM_PROVNOM_PROVCIUDAD

S1JUANACAPULCO

S2PEDROMERIDA

S3ANAMERIDA

S4RENEACAPULCO

S5PATRICIAREYNOSA

S6RENATAREYNOSA

Forma Normal Boyce-CodeForma Normal de Boyce-Codd (FNBC)Para ilustrar la necesidad de una forma normal adicional daremos un ejemplo:Supongamos que deseamos llevar la informacin de qu materias lleva cada alumno y qu profesor se las imparte. Se sabe adems de que:1. Un alumno lleva una o ms materias.2. Un profesor imparte slo una materia.3. Una materia puede ser impartida por uno o ms profesores.4. En una materia puede haber inscritos uno o ms alumnos.Un posible diseo sera (considerando que ya se definieron previamente los atributos de cada entidad):MATR , NOM_ALU, CARR

NEMP , NOMBRE, GRADOALUMNOS

PROFESORESMATR, NEMP , CLAVEGRUPOSCLAVE, NOM_MATERIA,MATERIASPero como un profesor slo imparte una materia no es posible que un alumno lleve dos o ms materias con el mismo profesor, de donde concluimos que no se requiere que la llave primaria de la relacin GRUPOS sea MATR+NEMP+CLAVE sino solamente MATR+CLAVE MATR+NEMP. Es decir que tenemos dos llaves candidato.De tal forma que dos mejores diseos serian:MATR , NOM_ALU, CARR

NEMP , NOMBRE, GRADOALUMNOS

PROFESORESMATR, NEMP , CLAVEGRUPOS

MATRNEMP

CLAVECLAVE, NOM_MATERIA,MATERIASNOTA: La flecha de NEMP a CLAVE en ambos casos, indica que el profesor determina la materia, puesto que solo imparte una.MATR , NOM_ALU, CARR

NEMP , NOMBRE, GRADOALUMNOS

PROFESORESMATR, NEMP , CLAVE

MATR

NEMPGRUPOS

CLAVECLAVE, NOM_MATERIA, DESCRIPCIONMATERIASEn cualquiera de los dos casos podemos observar que la relacin GRUPOS est en 3FN porque todos los campos no-llave no dependen transitivamente de la llave primaria. Pero an as la relacin tiene ciertas anomalas.Por ejemplo: si solo se tiene a un alumno inscrito en una materia impartida por un profesor, al dar de baja a dicho alumno, se pierde la informacin de que materia imparte dicho profesor.Para evitar este tipo de anomalas se ha definido la FNBC que dice:Una relacin est en FNBC sii cada determinante es una llave candidato.Un Determinante es cualquier atributo o conjunto de atributos del cul otro atributo es dependiente funcionalmente en forma completa.Analizando el diagrama de dependencias y las llaves candidato tenemos lo siguiente:Las llaves candidato son:MATR+CLAVE MATR+NEMPLos determinantes son: MATR+CLAVE MATR+NEMPNEMP (Puesto que determina la CLAVE)De donde concluimos que la relacin GRUPOS no est en FNBC. Para poner aGRUPOS en FNBC tenemos que analizar sus posibles proyecciones:PROYECCIONCOMENTARIO

GRUPOS[MATR,CLAVE]Se pierde la informacin de que profesor le da clase s un alumno, puesto hay varios profesores para una materia

GRUPOS[MATR,NEMP]OK, pero se requiere adicionalmente la proyeccion GRUPOS [NEMP,CLAVE]para tener la informacion original.

GRUPOS[NEMP,CLAVE]OK, pero se requiere adicionalmente la proyeccion GRUPOS [MATR,NEMP]para recuperar la informacin original.

As concluimos que la relacin grupos debe descomponerse en las proyecciones: GRUPO[MATR,NEMP] y GRUPOS[NEMP,CLAVE], teniendo as el diseo de la base de datos de la siguiente manera:MATR , NOM_ALU, CARR

NEMP , NOMBRE, GRADOALUMNOS

PROFESORESMATR, NEMP

NEMP , CLAVEALU_PROF

PROF_MATCLAVE, NOM_MATERIA,MATERIASDe lo anterior podemos observar que ALU_PROF ya est en FNBC (es toda llave) y que PROF_MAT ya est en FNBC puesto que solo existe un determinante (que es NEMP). Adicionalmente se puede verificar que la anomala de perder informacin de que materia da un profesor al borrar al nico alumno que estaba inscrito se ha evitado.Nota: Generalmente se cumple que una relacin no est en FNBC si las llaves candidato se traslapan.MATR , NOM_ALU, CARR

NEMP , NOMBRE, GRADOALUMNOS

PROFESORESMATR, NEMP

NEMP , CLAVEALU_PROF

PROF_MATCLAVE, NOM_MATERIA,MATERIASDe lo anterior podemos observar que ALU_PROF ya est en FNBC (es toda llave) y que PROF_MAT ya est en FNBC puesto que solo existe un determinante (que es NEMP). Adicionalmente se puede verificar que la anomala de perder informacin de que materia da un profesor al borrar al nico alumno que estaba inscrito se ha evitado.Nota: Generalmente se cumple que una relacin no est en FNBC si las llaves candidato se traslapan.Cuarta Forma Normal.Existen algunas relaciones que a pesar de estar en FNBC presenta cierto grado de redundancia. Lo cual a su vez tiene como consecuencia que tengamos anomalas al realizar altas y cambios.Para ilustrar esto, consideraremos que en una universidad se desea llevar el control de materias, profesores y libros de texto.Se tienen las siguientes reglas del negocio: Una materia puede ser impartida por uno o ms profesores. Una materia tiene asociados uno o ms libros de texto. Un profesor puede impartir una o ms materias Un profesor al impartir una materia usa todos los libros de texto de esa materia. Un libro de texto puede ser utilizado en una o ms materias.De este modo un posible diseo sera:Analizando en detalle la relacin GRUPOS nos podemos dar cuenta que requiere que todos los atributos sean la llave, puesto que: Un mismo libro se puede repetir para diferentes combinaciones de profesor y materia. Un mismo profesor se puede repetir para diferentes combinaciones de materias y libros. Una misma materia se puede repetir para diferentes combinaciones de profesor y libro.En este sentido al ser todos los atributos la LLAVE ya est en FNBC pero tiene algunos problemas: Al dar de alta a un nuevo profesor para una materia tenemos el problema de dar de alta tantos registros como libros haya para la materia. Al dar de alta un libro para una materia, se tienen que dar de alta tantos registros como profesores haya para la materia.La FNBC no nos ayuda a corregir estos problemas, por lo que se requiere una forma normal adicional:Una relacin esta en Cuarta Forma Normal (4FN) sii al tener dependencias multivaluadas de la forma A-->>B todas las dependencias funcionales dependen de A. Es decir todas las dependencias multivaluadas son dependencias funcionales.Para el caso de la relacin analizada tenemos: CLAVE -->> NEMPCLAVE -->> LIBROPara este caso un mejor diseo separara las dependencias multivaluadas dando:Quinta Forma Normal (PJ/NF 5FN)Dentro del proceso de normalizacin presentado, se ha visto que se realizan proyecciones sin prdida y sin ganancia. Normalmente se tiene que una relacin es descompuesta en dos de sus proyecciones y al realizar el JOIN de dichas proyecciones se recupera la tabla original. Existen algunas relaciones en las cuales el realizar dos proyecciones de la tabla original no es suficiente para tener una descomposicin sin perdida ni ganancia.Tomemos el caso de PROVEEDORES, PARTES y PROYECTOS en donde se tiene que: Un proveedor puede suministrar diferentes partes a diferentes proyectos. Una parte puede ser usada por diferentes proyectos y suministrada por diferentes proveedores. Un proyecto puede usar diferentes partes las cuales pueden ser suministradas por diferentes proveedoresEn este sentido un posible diseo sera:Al analizar la relacin SPJ podemos ver que se requiere que toda sea llave y una posible descomposicin sera:SP (SNO, PNO) y PJ(PNO,JNO) Considerando que el contenido de SPJ es:SNOPNOJNO

S1P1J2

S1P2J1

S2P1J1

S1P1J1

Entonces SP sera:SNOPNO

S1P1

S1P2

S2P1

y PJ sera:PNOJNO

P1J2

P2J1

P1J1

Al realizar el join de SP con PJ produce:SNOPNOJNO

S1P1J2

S1P1J1

S1P2J1

S2P1J2

S1P1J1

De donde se concluye que se tiene un registro adicional que es S2, P1, J2.Para poder tomar proyecciones sin prdida ni ganancia de la tabla SPJ es necesario tomar 3 proyecciones, y realizar joins entre ellos. La proyeccin que hace falta es: SJ(SNO, JNO)Que al realizar el join de ((SP JOIN PJ) JOIN SJ) produce la tabla original eliminando la ganancia obtenida.De lo anterior concluimos que: SI, Sx Py aparece en SPY Py, Jw aparece en PJ Y Sx, Jw aparece en SJEntonces: Aparece Sx, Py, Jw en SPJ.En este sentido se define la dependencia al join (JD) de la siguiente forma: Una relacin satisface una JD sii la relacin original se produce por la juntura de las proyecciones indicadas en JDSi la relacin R consta de campos A, B, C satisface la dependencia JD(AB, AC)sii R se produce de AB JOIN ACCorolario: Esto implica que:A-->>B y A-->>C es decir que JD es mas general que las dependencias multivaluadas, o que las dependencias multivaluadas son un caso especial de las dependencias a la juntura (JD).De este modo la definicin de la 5FN es:Una relacin esta en 5FN sii cada dependencia a la juntura es una consecuencia de sus llaves candidato. Es decir si se pueden deducir las dependencias de la juntura directamente de sus llaves candidatos.Para el caso de SPJ se satisface JD(SP, PJ, SJ) pero esto no puede serdeducido de la llave candidato (SNO, PNO, JNO) por lo que no esta en 5FN. Pero las relaciones SP, PJ, SJ si estn en 5FN.Comprobacin de la 5 forma normal

NUM_PROVNUM_PARTECANTIDADS1P110S1P210S2P1200S2P310S2P5300S3P3200S3P410S3P5300S4P1200S5P110S5P4200S6P510

CIUDADESTADOACAPULCO2MERIDA4REYNOSA6