NORMALIZACIN Una base de datos tiene que ser diseada antes de que pueda ser creada y usada.

El diseo debe ajustarse a estndares que permitan ahorro de memoria, acceso rpido, fcil mantenimiento, portabilidad, facilidad de futuros mejoramientos, buen desempeo y eficiencia de costos, entre otros. El diseo lgico final de una base de datos debe ser tal que equilibre un desempeo ptimo junto con la integridad de la informacin. Esto puede ser logrado a travs de un proceso conocido como ormali!acin. "a base de datos debe estar en un estado de #$orma completamente normali!ada#. INTRODUCCIN DEFINICIN DE NORMALIZACION ormali!acin es una serie de reglas que involucra anlisis y transformacin de las estructuras de los datos en relaciones que e%hiban propiedades &nicas de consistencia, m'nima redundancia y m%ima estabilidad. "a necesidad para normali!ar puede ser mejor comprendida al mencionar las distintas anomal'as o desventajas de los datos ( ()*+",-+.(/. 0onsideremos la tabla en la figura 1. "a tabla contiene todos los detalles de los empleados de una compa'a, y los detalles del .epartamento al que pertenecen.

$,2U)+ 1 + primera vista, parece conveniente almacenar todos los detalles en una sola tabla. 3ero ciertas anomal'as se pueden manifestar durante la insercin, actuali!acin y borrado de datos. "a normali!acin provee un mtodo de remover todas estas indeseables anomal'as haciendo la base de datos ms confiable y estable. Anomala de insercin (INSERT /uponga que un nuevo .epartamento ha sido creado, el cual no tiene empleados todav'a, por lo tanto, en nuestra tabla original, los datos correspondientes al empelado estar'an vac'os 4nulos5, y solo tendr'amos la informacin del .epartamento6 0olumnas #num.ept# y #desc.ept#. Anomala de Ac!"ali#acin (U$DATE /uponga que el n&mero del .epartamento de #/istemas# ha sido cambiado a +789:. Esto involucra tener que cambiar el numero del departamento para todos los empleados que pertene!can al departamento de #/istemas#, lo cual representa tiempo y recursos de sistema adicionales. Anomala de %orrado (DELETE /i todos los empleados en el .epartamento de #$inan!as# abandonan la compa'a, todos los registros de estos tendr'an que ser borrados. ;echo as', los detalles del .epartamento #$inan!as# se perder'an. "os datos en la tabla entonces no representan una informacin correcta sobre el estado de la compa'a, y por lo tanto se pierde la integridad de los datos. $RO$IEDADES DE UNA &ASE DE DATOS DES$U'S DE LA NORMALIZACION

8 de <

Una base de datos normali!ada debe representar las siguientes propiedades6

"os requerimientos para almacenamiento de datos se minimi!an, dado que el proceso de normali!acin sistemticamente elimina la duplicacin de los datos. .esde que los datos son almacenados en el m'nimo n&mero de lugares, las posibilidades de inconsistencias en la informacin son reducidas al m'nimo. "as estructuras normali!adas son ptimas para efectuar actuali!aciones de los datos. .ado que los datos e%isten en el m'nimo n&mero de lugares, una operacin de actuali!acin 4U3.+=E5 necesitar acceder a una m'nima cantidad de datos.

$ROCEDIMIENTOS DE NORMALIZACION El proceso de normali!acin involucra bsicamente tres pasos. .espus de cada paso, la base de datos se convierte en formas llamadas #formas normales#. 2eneralmente, la #tercera forma normal# es el estado que debe alcan!ar una base de datos para que se diga que est totalmente normali!ada. "a cuarta y la quinta forma normal tambin e%isten, pero no son usadas en el diseo de una base de datos. + continuacin, consideremos un pequeo ejercicio acerca de un .ocumento de (rden de 0ompra, el cual trataremos de convertirlo a una forma normali!ada. 3ero antes e%plicaremos unas pequeas reglas6 $ro(iedades de "na relacin Un tabla debe satisfacer ciertos criterios previos antes de calificar para convertirse en una relacin. Cla)e *nica 0ada registro tiene que tener una llave &nica que lo identifique. 0ualquier atributo puede ser una llave, pero en lo posible trataremos de elegir como llave &nica al atributo que tenga una longitud menor y fija, como por ejemplo un numero de ,.. /i un atributo es insuficiente para identificar un registro de manera &nica, entonces mas de un atributo puede conformar la llave &nica. En tal caso, el n&mero de atributos que conformen una llave debe ser el m'nimo necesario y suficiente.

No d"(licados o debe haber nunca dos columnas o filas totalmente idnticas. /i dos filas son totalmente idnticas, entonces hacen falta algunos atributos que las haga diferentes y distinguibles. Ejemplo6 .os registros de discos compactos en una tienda ser'an idnticos si son dos copias del &ltimo lbum de /ha>ira, si no fuera porque cada disco compacto tiene un numero cdigo que los hace diferentes. Insi+ni,icancia del orden "a secuencia en la cual los atributos son escritos no debe importar. 3odemos escribir el ,. del empleado de primero, o el nombre y el apellido de primero, y esto no afectar las relaciones que estable!camos con otras tablas. 3or otro lado, los registros deben ser totalmente independiente de su secuencia o posicin en la base de datos 4dependencia posicional5. Esto significa que si intentamos identificar un registro por su posicin dentro de la tabla, estaremos creando una llave invlida. Forma no-normali#ada "os datos, en su forma elemental, no estn normali!ados. 3or lo tanto, lo primero con lo que debemos comen!ar es con los datos elementales o bsicos que conformarn el diccionario de datos. El diccionario de datos es creado a partir de los documentos o diagramas de flujo de la compa'a. /e deben listar los

? de <

elementos uno debajo del otro. +s', obtendremos la forma no@normali!ada para el ejercicio de +). 4+nlisis )elacional de .atos5, con el cual deberemos obtener al final distintos grupos de elementos. *as tarde, dichos grupos se combinarn con los grupos de otros documentos al cual tambien se les ha hecho el anlisis +)., y se establecern relaciones entre ellos. E.ERCICIO 0onsideremos el documento ().E proveedor de discos compactos. .E 0(*3)+ de la figura, usado para colocar una orden de pedido al

FORMA UNF (UNNORMALIZED FORM O NO-NORMALIZADA ().@ ( 6 &mero de (rden de 0ompra ().@.+=E 6 $echa de la (rden de 0ompra 3)(A@ (6 umero del 3roveedor 3)(A@ +*E6 ombre del 3roveedor 3)(A@.,)6 .ireccin del 3roveedor 3)(A@ ,=6 ,= o 0dula del 3roveedor 0(.,2(6 0digo del 0. o Blbum =,=U"(6 =itulo del 0. o Blbum 0+ = 6 0antidad de 0.s a pedir A)@U ,=6 Aalor unitario del 0. o Blbum ,ncluso las formas no normali!adas deben tener una llave. En el ejemplo de arriba, podemos deducir que ().@ ( es la llave. "as llaves usualmente son subrayadas durante el anlisis +)..

1 de <

$RIMERA FORMA NORMAL (/FN Re+la /0 Se(arar el +r"(o re(e!i!i)o1 En la lista de arriba, los 'tems despus de $RO2-NIT son repetitivos, esto quiere decir, que para una misma orden aparecen varias veces, dado que en una misma orden se pueden encargar varias categor'as, o varios t'tulos de la misma categor'a. "os grupos repetitivos deben ser separados de la U $ y ser escritos como un grupo independiente con su respectiva llave. Este grupo debe relacionarse con el grupo no repetitivo enla!ando la llave del grupo no repetitivo junto con la llave del repetitivo. .e esta manera tenemos6 Grupo NO Repetitivo ().@ ( ().@.+=E 3)(A@ ( 3)(A@ +*E 3)(A@.,) 3)(A@ ,= Grupo Repetitivo 0(.,2( =,=U"( 0+ = A)@U ,=

El grupo repetitivo tiene a 0(.,2( como llave. /in embargo, esta llave no es &nica, dado que se puede repetir en otros n&meros de orden. ecesita ser combinada con la llave del primer grupo. +l combinar el campo ().@ ( junto con el campo 0(.,2( para el segundo grupo, podemos deducir que esta combinacin puede actuar como llave &nica, ya que no puede haber una misma orden que tenga ? cdigos iguales. 3or lo tanto, despus de aplicar la primera forma normal, obtenemos estos grupos6 GRUPO 1 ().@ ( ().@.+=E 3)(A@ ( 3)(A@ +*E 3)(A@.,) 3)(A@ ,= SE3UNDA FORMA NORMAL (4FN Re+la 40 Se(arar de(endencias de las lla)es com("es!as0 /olo aquellos grupos de datos que tengan llaves combinadas son anali!ados. 4llaves que tengan mas de un campo o atributo para lograr unicidad5. 3or lo tanto, para la segunda forma normal, nos concentraremos solo en el grupo ?, el cual tiene una llave compuesta. En el grupo? , cualquier atributo que no dependa enteramente de la llave compuesta 4es decir, que no dependa de todos los atributos de la llave a la ve! sino de solo uno de ellos5 es separado del grupo principal, y es aislado en un grupo independiente junto con el atributo de la llave inicial del cual s' es dependiente. Aeamos el proceso para que haya mayor claridad6 +l anali!ar el grupo ?, encontramos que el campo =,=U"( depende enteramente del campo 0(.,2(, y no de la llave compuesta. "legamos a esta conclusin deduciendo que el t'tulo del 0. esta asociado a un &nico cdigo, por lo cual podr'amos pensar que 0(.,2( y =,=U"( son campos redundantes ya que con cualquiera de ellos podemos identificar al elemento, pero pensemos en que el diseo no nos permite deshacernos de ninguno de los campos, ya que las instrucciones nos obligan a usar y almacenar =(.+ la informacin disponible en el diccionario de datos. 3or ello, lo que s' podemos hacer, aplicando la segunda forma normal, es aislar un tercer grupo, que tenga a 0(.,2( como llave, y =,=U"( como campo de la tabla. ,gua sucede con el campo A)@U ,=. Este campo GRUPO 2 ORD-NO CODI3O =,=U"( 0+ = A)@U ,=

C de <

esta asociado e%clusivamente al campo 0(.,2(. Esto es, cada =itulo de 0. con un cdigo determinado, debe corresponder a un valor de evnta que se establece una sola ve! por cada elemento. .e esta manera, si en algun momento necesitamos alterar el valor unitario de un 0., solo debemos hacerlo en la tabla del grupo 1, una &nica ve! por elemento. En conclusin, despus de aplicar la segunda forma normal, obtenemos estos grupos6 GRUPO 1 ().@ ( ().@.+=E 3)(A@ ( 3)(A@ +*E 3)(A@.,) 3)(A@ ,= GRUPO 2 ORD-NO CODI3O 0+ = GRUPO 3 CODI3O =,=U"( A)@U ,=

En este nivel, ya nos podemos imaginar mentalmente la utilidad de separar el diccionario de datos en distintos grupos. ,maginmonos que queremos ingresar D9 ordenes al sistema, y en todas est incluido el 0. de Euanes, cuyo cdigo es 8D?9. El t'tulo asociado al cdigo 8D?9 es #$'jate bien#. /i no e%istiera el grupo 1, para cada una de las ordenes estar'amos ingresando no solo D9 veces el cdigo 8D?9, sino que tambin nos toca digitar D9 veces el te%to #$'jate bienF. 0onsideramos que esto &ltimo es un trabajo que se puede ahorrar al aplicar la segunda forma normal, ya que si dejamos una tabla separada para 0(.,2( y =,=U"(, al ingresar las ordenes solo nos toca digitar D9 veces el cdigo 8D?9 en la tabla del grupo ? 4cada ve! asociado a un n&mero de orden distinto y &nico5, y U + sola ve! el mismo cdigo en la tabla 1, con lo cual el te%to #$'jate bien# solo tendr'a que ser digitado una sola vez por ende. En el evento en que se nos pida consultar el titulo del 0. en un registro de la tabla ?, simplemente usaremos el valor del campo 0(.,2( de dicho registro para trasladar la consulta a la tabla 1, quien nos devolver la informacin buscada del =itulo. /i han logrado entender la justificacin de la normali!acin con el ejemplo anterior, tenemos ya un gran terreno ganado en el proceso de aprender a disear bases de datos. TERCERA FORMA NORMAL (5FN Re+la 50 E6aminar las in!erde(endencias en!re los cam(os o a!ri%"!os 7"e no son lla)es0 =odos los campos o atributos en cada grupo que no sean llaves, deben ser e%aminados para chequear que no e%istan interdependencias entre ellos. /i se encuentran algunas, tales dependencias deben ser separadas en distintos grupos cuya llave debe ser el campo del cual son dependientes, dejando este campo llave tambin en el grupo original. /i anali!amos el grupo 8, encontramos que los campos 3)(A@ +*E, 3)(A@.,) y 3)(A@ ,= son enteramente dependientes del campo 3)(A@ (. .el grupo ? ya sacamos las interdependencias durante la segunda forma normal, y el grupo tres es precisamente el resultado de esa separacin en la segunda forma normal, por lo tanto lo ignoramos en esta etapa. os concentramos solo en el grupo 8. +l separar en un grupo la informacin del proveedor, dejando un cuarto grupo con esta informacin, obtenemos la tercera forma normal, la cual queda de la siguiente manera6

GRUPO 1 ().@ ( ().@.+=E 3)(A@ (

GRUPO 2 ().@ ( 0(.,2( 0+ =

GRUPO 3 0(.,2( =,=U"( A)@U ,=

GRUPO 4 $RO2-NO 3)(A@ +*E 3)(A@.,) 3)(A@ ,=

D de <

RESUMEN DE LA NORMALIZACION

U $ @ $()*+ ( ()*+",-+.+ 8 $ @ 3),*E)+ $()*+ ()*+" ? $ @ /E2U .+ $()*+ ()*+" 1 $ @ =E)0E)+ $()*+ ()*+"

.iccionario de datos /eparar el grupo repetitivo /eparar dependencias de llaves compuestas /eparar dependencias de los campos no llaves

RE3LAS NO ESCRITAS $ARA UN &UEN DISE8O DE &ASE DE DATOS *antener los datos bien diferenciados 4p.ej., el primero y el &ltimo de los nombres van separados5. +cercar unas columnas a otras posteriormente sobre la marcha es, en general, bastante fcil, pero separarlas no 3rimero, definir la clave primaria. Utili!ar un nombre descriptivo 4E*3"E+.(G,., no slo ,.5. El uso de nombres descriptivos permite que los nuevos usuarios tengan alguna oportunidad de adivinar lo que es cada una de las columnas 4p.ej., utili!ar 0UE =+G7+ 0( en lugar de 0=705. /iempre que sea posible, utili!ar una sola columna para la clave primariaH las claves primarias de ms de una columna son adecuadas para las interrelaciones de muchos a muchos. Utili!ar tablas de referencia en lugar de almacenar valores de gran longitud. Emplear claves de tipo numrico siempre que sea posible Evitar las claves autonumricas 4salvo en las tablas de referencia5. o incluir dos columnas cuyos valores estn entrela!ados 4p.ej., el nombre del .epartamento y el ,. de .epartamento5, salvo que una de las columnas sea la clave primaria de la tabla. Evitar utili!ar varias tablas con estructuras similares para representar pequeas variaciones de la misma entidad 4p.ej., poner las Universidades de +tlntico y las de 0undinamarca en distintas tablas5. 3lanear con antelacin la transferencia de datos a una base de datos distinta. 3or ejemplo, puede que nos interese mover algunos datos de (racle a .7$, o de *icrosoft +ccess a (racle. Esto es6 I Evitar poner en los nombres de las columnas caracteres que no sean may&sculas 4+@-5, n&meros 49@J5 o el subrayado 4G5. 0ualquier otro caracter puede no ser aceptado por la base de datos. +lgunos sistemas de bases de datos son sensibles al uso de may&sculas y min&sculas en los nombres de las columnas, otros no. I 3rocurar que los nombres de las columnas sean relativamente cortos. 0ada tipo de base de datos soporta un n&mero distinto de caracteres 4p.ej., 19 en el caso de (racle, KC para *icrosoft +ccess o 89 si es .7$5. ,ntentar que los nombres de las columnas var'en en los primeros caracteres y no en los &ltimos, con el fin de evitar que se duplique alguno de los nombres por error al cortarlos para abreviar durante el proceso de conversin 4p.ej., utili!ar 0("8 y 0("?, en lugar de (*7)EG0("U* +G"+)2+G8 L (*7)EG0("U* +G"+)2+G?5. Observar que el poner nombres cortos a las columnas puede ser incompatible con procurar que sean descriptivos para los nuevos usuarios. Comprobar que se est realizando una buena combinacin. Es importante recordar que stas son reglas no escritas, basadas &nicamente en la e%periencia, M no leyes absolutasN /e pueden romper las reglas si es necesario, pero justificando la decisin.

K de <

ACTI2IDAD No0/ En la siguiente $+0=U)+ .E 0(*3)+ AE =+, usted debe anali!ar toda la informacin disponible y debe crear el .,00,( +),( .E .+=(/. Una ve! tenga el .iccionario de .atos, haga un anlisis +). y ejecute el proceso de normali!acin, hasta llegar a la =ercera $orma ormal. + vuelta de correo, el estudiante deber hacer llegar al tutor un &nico documento en Oord, con todos los pasos del anlisis, de cada forma normal, con la respectiva justificacin detallada de cada uno de los pasos que condu!can al resultado final.

< de <