I - 2013

Normalizacin

Fundamentos y Diseo de Base de Datos

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 Normalizacin. La base de datos debe estar en un estado de "Forma completamente normalizada". INTRODUCCIN

DEFINICIN DE NORMALIZACION Normalizacin es una serie de reglas que involucra anlisis y transformacin de las estructuras de los datos en relaciones que exhiban propiedades nicas de consistencia, mnima redundancia y mxima estabilidad. La necesidad para normalizar puede ser mejor comprendida al mencionar las distintas anomalas o desventajas de los datos NO NORMALIZADOS. Consideremos la tabla en la figura 3. La tabla contiene todos los detalles de los empleados de una compaa, y los detalles del Departamento al que pertenecen.

Figura 3

A primera vista, parece conveniente almacenar todos los detalles en una sola tabla. Pero ciertas anomalas se pueden manifestar durante la insercin, actualizacin y borrado de datos. La normalizacin provee un mtodo de remover todas estas indeseables anomalas haciendo la base de datos ms confiable y estable. Anomala de insercin (INSERT) Suponga que un nuevo Departamento ha sido creado, el cual no tiene empleados todava, por lo tanto, en nuestra tabla original, los datos correspondientes al empelado estaran vacos (nulos), y solo tendramos la informacin del Departamento: Columnas "numDept" y "descDept". Anomala de Actualizacin (UPDATE) Suponga que el nmero del Departamento de "Sistemas" ha sido cambiado a AB108. Esto involucra tener que cambiar el nmero del departamento para todos los empleados que pertenezcan al departamento de "Sistemas", lo cual representa tiempo y recursos de sistema adicionales. Anomala de borrado (DELETE) Si todos los empleados en el Departamento de "Finanzas" abandonan la compaa, todos los registros de estos tendran que ser borrados. Hecho as, los detalles del Departamento "Finanzas" se perderan. Los datos en la tabla entonces no representan una informacin correcta sobre el estado de la compaa, y por lo tanto se pierde la integridad de los datos.
Ing. Harvey Michael Gamboa Pea
1 de 7

Universidad de Pamplona Ext. Villa Rosario

I - 2013

Normalizacin

Fundamentos y Diseo de Base de Datos

PROPIEDADES DE UNA BASE DE DATOS DESPUS DE LA NORMALIZACION Una base de datos normalizada debe representar las siguientes propiedades: Los requerimientos para almacenamiento de datos se minimizan, dado que el proceso de normalizacin sistemticamente elimina la duplicacin de los datos. Desde que los datos son almacenados en el mnimo nmero de lugares, las posibilidades de inconsistencias en la informacin son reducidas al mnimo. Las estructuras normalizadas son ptimas para efectuar actualizaciones de los datos. Dado que los datos existen en el mnimo nmero de lugares, una operacin de actualizacin (UPDATE) necesitar acceder a una mnima cantidad de datos. PROCEDIMIENTOS DE NORMALIZACION El proceso de normalizacin involucra bsicamente tres pasos. Despus de cada paso, la base de datos se convierte en formas llamadas "formas normales". Generalmente, la "tercera forma normal" es el estado que debe alcanzar una base de datos para que se diga que est totalmente normalizada. La cuarta y la quinta forma normal tambin existen, pero no son usadas en el diseo de una base de datos. A continuacin, consideremos un pequeo ejercicio acerca de un Documento de Orden de Compra, el cual trataremos de convertirlo a una forma normalizada. Pero antes explicaremos unas pequeas reglas: Propiedades de una relacin Una tabla debe satisfacer ciertos criterios previos antes de calificar para convertirse en una relacin. Clave nica Cada registro tiene que tener una llave nica que lo identifique. Cualquier 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 ID. Si un atributo es insuficiente para identificar un registro de manera nica, entonces ms de un atributo puede conformar la llave nica. En tal caso, el nmero de atributos que conformen una llave debe ser el mnimo necesario y suficiente. No duplicados No debe haber nunca dos columnas o filas totalmente idnticas. Si dos filas son totalmente idnticas, entonces hacen falta algunos atributos que las haga diferentes y distinguibles. Ejemplo: Dos registros de discos compactos en una tienda seran idnticos si son dos copias del ltimo lbum de Shakira, si no fuera porque cada disco compacto tiene un nmero cdigo que los hace diferentes. Insignificancia del orden La secuencia en la cual los atributos son escritos no debe importar. Podemos escribir el ID del empleado de primero, o el nombre y el apellido de primero, y esto no afectar las relaciones que establezcamos con otras tablas. Por otro lado, los registros deben ser totalmente independientes de su secuencia o posicin en la base de datos (dependencia posicional). Esto significa que si intentamos identificar un registro por su posicin dentro de la tabla, estaremos creando una llave invlida. Forma no-normalizada Los datos, en su forma elemental, no estn normalizados. Por lo tanto, lo primero con lo que debemos comenzar 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 compaa. Se deben listar los elementos uno debajo del otro. As, obtendremos la forma no-normalizada para el ejercicio de ARD (Anlisis Relacional de Datos), con el cual deberemos obtener al final distintos grupos de elementos. Mas tarde, dichos

Ing. Harvey Michael Gamboa Pea

2 de 7

Universidad de Pamplona Ext. Villa Rosario

I - 2013

Normalizacin

Fundamentos y Diseo de Base de Datos

grupos se combinarn con los grupos de otros documentos al cual tambin se les ha hecho el anlisis ARD, y se establecern relaciones entre ellos. EJERCICIO Consideremos el documento ORDEN DE COMPRA de la figura, usado para colocar una orden de pedido al proveedor de discos compactos.

FORMA UNF (UNNORMALIZED FORM) O NO-NORMALIZADA ORD-NO : Nmero de Orden de Compra ORD-DATE : Fecha de la Orden de Compra PROV-NO: Numero del Proveedor PROV-NAME: Nombre del Proveedor PROV-DIR: Direccin del Proveedor PROV-NIT: NIT o Cdula del Proveedor CODIGO: Cdigo del CD o lbum TITULO: Titulo del CD o lbum CANT: Cantidad de CDs a pedir VR-UNIT: Valor unitario del CD o lbum Incluso las formas no normalizadas deben tener una llave. En el ejemplo de arriba, podemos deducir que ORD-NO es la llave. Las llaves usualmente son subrayadas durante el anlisis ARD.

Ing. Harvey Michael Gamboa Pea

3 de 7

Universidad de Pamplona Ext. Villa Rosario

I - 2013

Normalizacin

Fundamentos y Diseo de Base de Datos

PRIMERA FORMA NORMAL (1FN) Regla 1. Separar el grupo repetitivo: En la lista de arriba, los tems despus de PROV-NIT son repetitivos, esto quiere decir, que para una misma orden aparecen varias veces, dado que en una misma orden se pueden encargar varias categoras, o varios ttulos de la misma categora. Los grupos repetitivos deben ser separados de la UNF y ser escritos como un grupo independiente con su respectiva llave. Este grupo debe relacionarse con el grupo no repetitivo enlazando la llave del grupo no repetitivo junto con la llave del repetitivo. De esta manera tenemos: Grupo NO Repetitivo ORD-NO ORD-DATE PROV-NO PROV-NAME PROV-DIR PROV-NIT Grupo Repetitivo ORD-NO CODIGO TITULO CANT VR-UNIT

El grupo repetitivo tiene a CODIGO como llave. Sin embargo, esta llave no es nica, dado que se puede repetir en otros nmeros de orden. Necesita ser combinada con la llave del primer grupo. Al combinar el campo ORD-NO junto con el campo CODIGO para el segundo grupo, podemos deducir que esta combinacin puede actuar como llave nica, ya que no puede haber una misma orden que tenga 2 cdigos iguales. Por lo tanto, despus de aplicar la primera forma normal, obtenemos estos grupos: GRUPO 1 ORD-NO ORD-DATE PROV-NO PROV-NAME PROV-DIR PROV-NIT GRUPO 2 ORD-NO CODIGO TITULO CANT VR-UNIT

SEGUNDA FORMA NORMAL (2FN) Regla 2. Separar dependencias de las llaves compuestas. Solo aquellos grupos de datos que tengan llaves combinadas son analizados. (Llaves que tengan ms de un campo o atributo para lograr unicidad). Por lo tanto, para la segunda forma normal, nos concentraremos solo en el grupo 2, el cual tiene una llave compuesta. En el grupo2, cualquier atributo que no dependa enteramente de la llave compuesta (es decir, que no dependa de todos los atributos de la llave a la vez sino de solo uno de ellos) 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. Veamos el proceso para que haya mayor claridad: Al analizar el grupo 2, encontramos que el campo TITULO depende enteramente del campo CODIGO, y no de la llave compuesta. Llegamos a esta conclusin deduciendo que el ttulo del CD esta asociado a un nico cdigo, por lo cual podramos pensar que CODIGO y TITULO 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 TODA la informacin disponible en el diccionario de datos.

Ing. Harvey Michael Gamboa Pea

4 de 7

Universidad de Pamplona Ext. Villa Rosario

I - 2013

Normalizacin

Fundamentos y Diseo de Base de Datos

Por ello, lo que s podemos hacer, aplicando la segunda forma normal, es aislar un tercer grupo, que tenga a CODIGO como llave, y TITULO como campo de la tabla. Igual sucede con el campo VR-UNIT. Este campo esta asociado exclusivamente al campo CODIGO. Esto es, cada Titulo de CD con un cdigo determinado, debe corresponder a un valor de venta que se establece una sola vez por cada elemento. De esta manera, si en algn momento necesitamos alterar el valor unitario de un CD, solo debemos hacerlo en la tabla del grupo 3, una nica vez por elemento. En conclusin, despus de aplicar la segunda forma normal, obtenemos estos grupos: GRUPO 1 ORD-NO ORD-DATE PROV-NO PROV-NAME PROV-DIR PROV-NIT GRUPO 2 ORD-NO CODIGO CANT GRUPO 3 CODIGO TITULO VR-UNIT

En este nivel, ya nos podemos imaginar mentalmente la utilidad de separar el diccionario de datos en distintos grupos. Imaginmonos que queremos ingresar 50 rdenes al sistema, y en todas est incluido el CD de Juanes, cuyo cdigo es 1520. El ttulo asociado al cdigo 1520 es "Fjate bien". Si no existiera el grupo 3, para cada una de las ordenes estaramos ingresando no solo 50 veces el cdigo 1520, sino que tambin nos toca digitar 50 veces el texto "Fjate bien. Consideramos que esto ltimo es un trabajo que se puede ahorrar al aplicar la segunda forma normal, ya que si dejamos una tabla separada para CODIGO y TITULO, al ingresar las ordenes solo nos toca digitar 50 veces el cdigo 1520 en la tabla del grupo 2 (cada vez asociado a un nmero de orden distinto y nico), y UNA sola vez el mismo cdigo en la tabla 3, con lo cual el texto "Fjate bien" solo tendra que ser digitado una sola vez por ende. En el evento en que se nos pida consultar el titulo del CD en un registro de la tabla 2, simplemente usaremos el valor del campo CODIGO de dicho registro para trasladar la consulta a la tabla 3, quien nos devolver la informacin buscada del Titulo. Si han logrado entender la justificacin de la normalizacin con el ejemplo anterior, tenemos ya un gran terreno ganado en el proceso de aprender a disear bases de datos. TERCERA FORMA NORMAL (3FN) Regla 3. Examinar las interdependencias entre los campos o atributos que no son llaves. Todos los campos o atributos en cada grupo que no sean llaves, deben ser examinados para chequear que no existan interdependencias entre ellos. Si 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. Si analizamos el grupo 1, encontramos que los campos PROV-NAME, PROV-DIR y PROV-NIT son enteramente dependientes del campo PROV-NO. Del grupo 2 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. Nos concentramos solo en el grupo 1. Al 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 manera: GRUPO 1 ORD-NO ORD-DATE PROV-NO GRUPO 2 ORD-NO CODIGO CANT GRUPO 3 CODIGO TITULO VR-UNIT GRUPO 4 PROV-NO PROV-NAME PROV-DIR PROV-NIT

Ing. Harvey Michael Gamboa Pea

5 de 7

Universidad de Pamplona Ext. Villa Rosario

I - 2013

Normalizacin

Fundamentos y Diseo de Base de Datos

RESUMEN DE LA NORMALIZACION UNF - FORMA NO NORMALIZADA 1NF - PRIMERA FORMA NORMAL 2NF - SEGUNDA FORMA NORMAL 3NF - TERCERA FORMA NORMAL Diccionario de datos Separar el grupo repetitivo Separar dependencias de llaves compuestas Separar dependencias de los campos no llaves

REGLAS NO ESCRITAS PARA UN BUEN DISEO DE BASE DE DATOS Mantener los datos bien diferenciados (p.ej., el primero y el ltimo de los nombres van separados). Acercar unas columnas a otras posteriormente sobre la marcha es, en general, bastante fcil, pero separarlas no Primero, definir la clave primaria. Utilizar un nombre descriptivo (EMPLEADO_ID, no slo ID). El uso de nombres descriptivos permite que los nuevos usuarios tengan alguna oportunidad de adivinar lo que es cada una de las columnas (p.ej., utilizar CUENTA_BANCO en lugar de CTBC). Siempre que sea posible, utilizar una sola columna para la clave primaria; las claves primarias de ms de una columna son adecuadas para las interrelaciones de muchos a muchos. Utilizar tablas de referencia en lugar de almacenar valores de gran longitud. Emplear claves de tipo numrico siempre que sea posible Evitar las claves auto numricas o serializables (salvo en las tablas de referencia). No incluir dos columnas cuyos valores estn entrelazados (p.ej., el nombre del Departamento y el ID de Departamento), salvo que una de las columnas sea la clave primaria de la tabla. Evitar utilizar varias tablas con estructuras similares para representar pequeas variaciones de la misma entidad (p.ej., poner las Universidades de Atlntico y las de Cundinamarca en distintas tablas). Planear con antelacin la transferencia de datos a una base de datos distinta. Por ejemplo, puede que nos interese mover algunos datos de Oracle a DBF, o de Microsoft Access a Oracle. Esto es: Evitar poner en los nombres de las columnas caracteres que no sean maysculas (A-Z), nmeros (0-9) o el subrayado (_). Cualquier otro caracter puede no ser aceptado por la base de datos. Algunos sistemas de bases de datos son sensibles al uso de maysculas y minsculas en los nombres de las columnas, otros no. Procurar que los nombres de las columnas sean relativamente cortos. Cada tipo de base de datos soporta un nmero distinto de caracteres (p.ej., 30 en el caso de Oracle, 64 para Microsoft Access o 10 si es DBF). Intentar que los nombres de las columnas varen 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 (p.ej., utilizar COL1 y COL2, en lugar de NOMBRE_COLUMNA_LARGA_1 Y NOMBRE_COLUMNA_LARGA_2).

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 experiencia, no leyes absolutas! Se pueden romper las reglas si es necesario, pero justificando la decisin.

Ing. Harvey Michael Gamboa Pea

6 de 7

Universidad de Pamplona Ext. Villa Rosario

I - 2013

Normalizacin

Fundamentos y Diseo de Base de Datos

ACTIVIDAD No.1 En la siguiente FACTURA DE COMPRA VENTA, usted debe analizar toda la informacin disponible y debe crear el DICCIONARIO DE DATOS. Una vez tenga el Diccionario de Datos, haga un anlisis ARD y ejecute el proceso de normalizacin, hasta llegar a la Tercera Forma Normal. A vuelta de correo, el estudiante deber hacer llegar al tutor un nico documento en Word, con todos los pasos del anlisis, de cada forma normal, con la respectiva justificacin detallada de cada uno de los pasos que conduzcan al resultado final.

Ing. Harvey Michael Gamboa Pea

7 de 7

Universidad de Pamplona Ext. Villa Rosario