Normalizacin Bases de Datos Instituto Superior de Formacin Tcnica N 179

NORMALIZACIN
La normalizacin es un trmino que deriva de la metodologa que se utiliza para evitar la redundancia de datos y el fcil acceso y actualizacin de estos. Dicha metodologa fue enunciada por Codd. Esta consista en definir un conjunto de normas a las que las llam formas normales. Cada forma normal fue numerada (esto en realidad es una verdad a medias, ya que existe una forma normal que no posee nmero y se llama forma normal de Boyce - Codd) desde la Io hasta la 5o, llamndose Io forma normal, 2o forma normal ... y as hasta la 5o forma normal. Lo importante de esta metodologa es que para que una relacin est en 2o FN (a partir de este momento abreviaremos forma normal como FN) debe anteriormente estar en 1o FN, para estar en 3o FN debe estar antes en 2o FN y por transitividad y lo que dijimos antes, debe tambin estar en 1o FN. As, lo que se garantiza es que para que una relacin est en una determinada forma normal antes debe estar en todas las formas normales que la preceden. Antes de entrar en profundidad en dicho tema, debemos definir algunos conceptos que son fundamentales para su comprensin.

Dependencia funcional
Existe un concepto que es fundamental: el concepto de dependencia funcional. Como su nombre lo indica, est fuertemente ligado a los conceptos matemticos aplicados al concepto de funcin. Hagamos un poco de memoria y remontmonos a nuestro colegio secundario, ms especficamente a la clase de matemticas en donde nos explicaron el concepto de funcin. El profesor/a nos escriba en el pizarrn un ejemplo como el siguiente:
y = 3x + 2

y como acto seguido nos deca muy pedaggicamente que "y" estaba en funcin de "x" o ms explcitamente nos deca que por cada valor diferente de "x" que diramos bamos a obtener un valor diferente de "y". O mejor an, terminaba la afirmacin diciendo que para dos valores iguales de "x" que colocramos en nuestra frmula mgica, ahora bien llamada funcin, bamos a obtener el mismo valor de "y". Con lo cual exista una dependencia funcional entre el valor de "x" y el valor de "y", que nos permita escribir la funcin anterior de la siguiente manera:
f(x) = 3x + 2

Este ejemplo resulta de suma practicidad para entender el concepto de dependencia funcional entre atributos. Supongamos ahora que en vez de nuestra bendita funcin del colegio secundario tenemos una relacin que est compuesta por un conjunto de atributos (si no recuerda estos conceptos o le queda algn tipo de dudas relea los captulos anteriores) y asumamos a nuestros viejos x e y de nuestra vieja funcin como nuestros nuevos x e y atributos de nuestra relacin (quiero aclarar que esta forma de llamarlos x e y es una generalizacin de los atributos, para ser mas explcitos asumamos nuestra relacin PROFESOR, x e y podran ser cualquiera de los atributos que la componan como Legajo, Nombre, Apellido, DNI o Fecha de Ingreso). Ahora bien, se define como dependencia funcional entre el atributo x y el atributo y de una relacin P cualquiera s "para una relacin P el atributo y de P depende funcionalmente del atributo x de P s y solo s un valor de y en P est asociado a cada valor x en P". Adems, se extiende o se puede definir la dependencia funcional de la siguiente manera "para una relacin P el atributo y de P depende funcionalmente del atributo x de P s y solo s, siempre que dos tuplas de P coincidan en su valor de x,

-1-

Normalizacin Bases de Datos Instituto Superior de Formacin Tcnica N 179

entonces es obligatorio que coincidan en su valor de y". En este momento podemos redefinir un viejo concepto como el de "clave primaria" explicado anteriormente. Ahora que ya explicamos el concepto de dependencia funcional, podemos sumergirnos en el tema que nos interesa que es el de normalizacin o mejor dicho las diferentes formas normales. Pero antes de esto asumamos que poseemos el siguiente modelo relacional (Figura 1). A partir del modelo relacional recin visto empezaremos a explicar el proceso de normalizacin o mejor dicho cmo se aplican las diferentes formas normales sobre un modelo relacional (nosotros explicaremos en detalle hasta la 3o FN, ya que en la prctica se llega a esta FN como mximo y comentaremos o explicaremos brevemente la FN de Boyce Codd, la 4o FN y la 5o FN).

CLAVE PRIMARIA Un atributo ser clave primaria si el resto de los atributos de la relacin que no son clave dependen funcional y nicamente de dicho atributo y no dependen funcionalmente de ningn otro. Algo que es importante tener claro es que el proceso de normalizacin se aplica relacin por relacin (en nuestra implementacin del modelo relacional tabla por tabla). Una cosa que es muy importante al definir los atributos de las relaciones involucradas en el modelo relacional es buscar las propiedades o caractersticas de los datos propios de la entidad o relacin a definir que siempre se cumplen o que trascienden el mbito o espacio temporal y como contrapartida no tendremos en cuenta aquellas propiedades de los datos que son ciertas o se cumplen por algn momento especfico. Por ejemplo, para que esto quede claro con respecto al producto nos interesa registrar en nuestra relacin el cdigo y su precio unitario, pero no nos interesa registrar ni su peso ni su color, ya que ellos podran variar en el transcurso del tiempo y esto no es relevante a la esencia de realizar una venta por como estn definidas las reglas del negocio.

1 Forma Normal
La 1 FN solicita que se cumplan dos condiciones sobre la relacin (entidad o tabla): Debe existir una clave primaria. Todos los dominios simples contienen nicamente valores atmicos.

-2-

Normalizacin Bases de Datos Instituto Superior de Formacin Tcnica N 179

Sobre la existencia de clave primaria a esta altura no hace falta realizar ninguna explicacin. Y sobre la 2o condicin que dice que "todos los dominios simples contienen nicamente valores atmicos" en criollo o castellano coloquial quiere decir "los atributos de la relacin no pueden contener grupos repetitivos o multivalorados". Aclaremos un poco: si miramos nuestra relacin veremos que para una venta realizada en una determinada fecha con un nmero de factura para un mismo cliente, por cada producto que compre el cliente, suceder algo como lo que se ve en la Tabla 1.

Si usted presta atencin observar que los atributos NroFactura, Codigo_Cliente, Nombre_Cliente, Fecha_de_Venta se repiten en la tabla por cada aparicin diferente de Cdigo_Producto, Cantidad_Vendida_Prod., Precio_Unitario_Prod. y Descripcin_Prod. En realidad estos ltimos atributos (los referentes al producto) no estn cumpliendo con la segunda condicin definida para que una relacin se encuentre en Io FN y por ello los atributos correspondientes a la venta y al cliente se repiten en cada tupia, esto es lo que llamamos redundancia de datos. Supongamos que el cliente en cuestin se mudar, usted estara obligado con este esquema de representacin a actualizar los domicilios en todas las tuplas de la relacin venta donde aparezca el cliente en cuestin y por lo que se ve, esto no ser una tarea nada grata. Hasta este momento tampoco definimos el atributo de la relacin venta que ser clave primaria, pero es cantado y queda totalmente claro por todo lo ya explicado que este ser el atributo NroFactura. Cmo se soluciona esto? O mejor dicho, cmo hacemos para que nuestra relacin VENTA quede en I FN?

Teniendo en cuenta el criterio para lograr que nuestra relacin VENTA quede en 1 FN procederemos como se nos indic en el apartado anterior.

-3-

Normalizacin Bases de Datos Instituto Superior de Formacin Tcnica N 179

Como consecuencia de esto nos queda un modelo relacional como el que se muestra a continuacin en la Figura 2.

Ambas relaciones han quedado en Io FN con sus correspondientes claves primarias definidas y se muestra cmo se preservan los datos en ambas tablas sin prdida de informacin con respecto a las tuplas de la entidad venta original.

-4-

Normalizacin Bases de Datos Instituto Superior de Formacin Tcnica N 179

2 Forma Normal
Para que una relacin se encuentre en 2o FN debe satisfacer las siguientes condiciones: Debe estar en 1o FN. Todos los atributos no clave dependen funcionalmente de la clave primaria. En nuestro ejemplo en cuestin la relacin VENTA que estaba en 1o FN tambin se encuentra en 2o FN, pero la relacin DETALLE_VENTA que se encuentra en 1o FN no se encuentra en 2o FN. Observe que el atributo Descripcin_Prod depende funcionalmente del atributo Codigo_Producto que forma parte de la clave primaria de dicha relacin, pero no depende funcionalmente del atributo NroFactura que tambin es uno de los atributos que forman parte de la clave primaria de la relacin. En cambio los atributos Cantidad_Vendida_Prod y Precio_Unitario_Prod dependen funcionalmente de ambos atributos, que forman la clave primaria. Veremos ahora cmo logramos que nuestra relacin DETALLE_VENTA quede en 2o FN.

Ahora que sabemos cmo lograr que una relacin se encuentre en 2o FN aplicaremos dicha tcnica sobre la relacin DETALLE_VENTA.

Con lo cual nos queda un modelo relaciona! como el que muestra la Figura 3 en 2o FN.

-5-

Normalizacin Bases de Datos Instituto Superior de Formacin Tcnica N 179

Nuestras tres relaciones VENTA, DETALLE_VENTA y PRODUCTO han quedado en 2o FN y adems se muestran los valores de cada tabla en 2o FN, con los valores derivados de la tupias originales de la tabla venta del inicio, sin prdida de informacin de estos, pero como observar, sin redundancia, gracias a la normalizacin.

3 Forma Normal
Para que una relacin se encuentre en 3o FN debe cumplir las siguientes condiciones:

-6-

Normalizacin Bases de Datos Instituto Superior de Formacin Tcnica N 179

Debe estar en 2o FN. Si todos los atributos no claves dependen de manera no transitiva de la clave primaria. En nuestro ejemplo, las relaciones DETALLE_VENTA y PRODUCTOS satisfacen ambas condiciones, pero no sucede lo mismo con nuestra relacin VENTA, ya que los atributos Nombre_Cliente y Domicilio_Cliente dependen funcionalmente del atributo Codigo_Cliente que no es un atributo clave y no dependen funcionalmente del atributo NroFactura que es la clave primaria. As que veremos cmo nuestra relacin VENTA puede quedar en 3o FN.

Ahora que ya sabemos cmo lograr que una relacin est en 3o FN apliquemos dichos conocimientos sobre la relacin VENTA.

-7-

Normalizacin Bases de Datos Instituto Superior de Formacin Tcnica N 179

Con lo cual nos queda un modelo relacional como el que muestra la Tabla 4 en 3 FN.

Nuestras cuatro relaciones (VENTA, DETALLE_VENTA, CLIENTES y PRODUCTOS) se encuentran ya en la 3o Forma Normal.

Forma Normal de Boyce Codd

Muchas veces la 3o FN no satisface totalmente los criterios de normalizacin en los casos que nuestra relacin posee ms de una clave candidata, en nuestro ejemplo eso no suceda con ninguna de nuestras relaciones, o esas claves candidatas son claves compuestas y adems existe la posibilidad que entre esas claves candidatas compartan algn atributo en comn. Para solucionar esta falencia que presentaba la 3o FN se defini con posterioridad la Forma Normal de Boyce/Codd. Dicha forma normal se enuncia de la siguiente manera: Una relacin se encuentra en la forma normal de Boyce Codd s y solo s un determinante es una clave candidata. Pero no profundizaremos ms en este tema pues l est fuera de los alcances de este libro.

4 Forma Normal
La 4o FN se aplica para dependencias multivaluadas. Una relacin se encuentra en 4o FN si cumple las siguientes condiciones: Se encuentra en la forma normal de Boyce Codd. Y todas las dependencias multivaluadas de dicha relacin son por defecto dependencias funcionales.

-8-

Normalizacin Bases de Datos Instituto Superior de Formacin Tcnica N 179

5 Forma Normal
Una relacin se encuentra en 5o FN si se satisface que toda dependencia de reunin es consecuencia de las claves candidatas de la relacin. Una relacin satisface la dependencia de reunin s y solo s dicha relacin es igual a la reunin de sus proyecciones, donde cada proyeccin es un subconjunto del conjunto de atributos de la relacin. Muchas veces cuando se descompone la relacin en dos proyecciones de esta sucede el efecto no deseado de prdida de informacin, pero se lo puede evitar si dicha relacin se descompone en ms de dos proyecciones. Al suceder esto lo que garantiza la 5o FN es que con la reunin de una determinada manera de dichas proyecciones se puede reconstruir la relacin y evitar la prdida de informacin de ella.

INTEGRIDAD DEL MODELO DE DATOS

En este momento es bueno hacer algunos comentarios o complementar ciertos conceptos ya explicados en captulos anteriores antes de seguir adelante. Por ejemplo, en todas nuestras diferentes definiciones de clave primaria que dimos a o .os largo del libro aplicando los diferentes conceptos aprendidos, siempre hablamos que eran atributos nicos o que el resto de los atributos no clave dependan funcionalmente de ella, pero hay algo que no mencionamos: que las claves primarias no pueden contener el valor nulo o null como valor vlido. Ya que una clave primaria no ruede ser indefinida. Con lo cual la primera condicin de integridad que debe cumplir un modelo relaciona! es que la clave primaria no puede contener valores nulos. Est claro por qu no puede aceptar valores nulos una clave primaria, pero por si rueda algn tipo de duda se lo paso a explicar. Una clave primaria, como dijimos antes es el atributo o conjunto de atributos que nos permite identificar unvocamente a cada tupla de la relacin y como contrapartida, el valor nulo en un atributo indica la indefinicin o desconocimiento de su valor, por ende poco podra servir como clave primaria un atributo o conjunto de atributos con valor desconocido. Esto adems est relacionado con el concepto de que el modelo relacional, como ya dijimos anteriormente es una simulacin o representacin del mundo real, por ende es muy poco probable que en el mundo real existan elementos indefinidos o no identificables sin ambigedad. .Ahora existe otro concepto subyacente al de clave primaria, del cual no hemos hablado todava y es el de clave fornea o clave externa o clave ajena (en realidad son todas formas diferentes de llamar lo mismo) el cual implica lo siguiente: una clave externa es un atributo o conjuntos de atributos de una relacin P cuyos valores deben coincidir con el valor o los valores de los atributos que componen la clave primaria de alguna relacin K. Una aclaracin que cae de maduro y por deduccin a esta altura de nuestros conocimientos, es que los valores de la clave fornea y los valores de la clave primaria asociada con esa clave fornea pertenecen al mismo dominio. Es ms, si ambas claves son compuestas, el dominio de cada atributo que compone ambas claves es el mismo. Para entender el concepto de clave fornea daremos un ejemplo que aclarar la situacin. Retomemos el modelo relacional de la Figura 4. Si nos fijamos en l con atencin, el atributo Codigo_Cliente de la relacin VENTA es una clave fornea de la clave primaria Codigo_Cliente de la relacin CLIENTE. Ahora expondremos la 2o condicin de integridad del modelo relacional que es la condicin de integridad referencial. La condicin de integridad referencial lo que pide es que no existan en el modelo relacional valores para las claves forneas sin coincidencia con los valores de las claves primarias asociadas a ella.

-9-

Normalizacin Bases de Datos Instituto Superior de Formacin Tcnica N 179

Veamos con un ejemplo qu es lo que nos est pidiendo la 2o condicin. Volvamos a nuestro ejemplo de la Figura 3 con nuestras relaciones VENTA y CLIENTE. El modelo no podra tener registrada una venta para un cliente inexistente, ya que eso no cumplira la condicin de integridad referencial y fjese que lgico que es esto. En la vida real solo es vlido realizar una venta a un cliente existente y no tendra sentido generar una venta a un cliente inexistente a no ser que se deseara realizar una estafa o maniobra fraudulenta y no es la idea permitir que esto suceda. Sin embargo, es factible tener registrado a uno o mas clientes y que ellos no me hagan ninguna compra. Este tipo de consistencia de la informacin es de lo que se ocupa la integridad referencial y todos los motores de datos de la actualidad permiten definirla, aunque no la definen automticamente.

Veremos ahora el diagrama de nuestro modelo de ventas con las restricciones de integridad referencial aplicadas. La punta de la flecha indica una cardinalidad de 1 y la lnea continua donde termina la flecha indica muchos (quiero aclarar que esta es una de las tantas formas de indicar la cardinalidad, aunque no es la nica, igualmente lo nico que cambia es su representacin grfica, pero el concepto es el mismo). Quiere decir que esto se leera o dira de la siguiente manera visto de la relacin CLIENTE "Un cliente tiene muchas ventas" o dicho de otra manera visto desde la relacin VENTA "Muchas ventas son de un cliente". Lo mismo se podra hacer con VENTA y DETALLE_VENTA, parados en VENTA diramos "Una venta posee muchos detalles de venta" y parados en DETALLE_VENTA diramos "Muchos detalles de venta pertenecen a una venta" y lo mismo entre PRODUCTO y DETALLEJVENTA; parados en PRODUCTO diramos "Un producto puede existir en muchos detalles de venta" y parados en DETALLE_VENTA diramos "Muchos detalles de venta contienen un producto."

- 10 -