TÉRMINO DE NORMALIZACIÓN

La normalización es un término que deriva de la metodología que se utiliza para evitar la redundancia de datos y el fácil acceso y actualización de estos. Dicha metodología fue enunciada por Codd.

Esta consistía 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 número y se llama forma normal de Boyce - Codd) desde la 1° hasta la 5°, llamándose 1 ° forma normal, 2° forma normal, y así hasta la 5° forma normal.

Lo importante de esta metodología es que para que una relación esté en 2° FN (a partir de este momento abreviaremos forma normal como FN) debe anteriormente estar en 1 ° FN, para estar en 3° FN debe estar antes en 2° FN y por transitividad y lo que dijimos antes, debe también estar en 1 ° FN.

Así, lo que se garantiza es que para que una relación esté en una determinada forma normal antes debe estar en todas las formas normales que la preceden.

La l0 FN solicita que se cumplan dos condiciones sobre la relación (entidad o tabla):

Debe existir una clave primaria . Todos los dominios simples contienen únicamente

valores atómicos.

Sobre la existencia de clave primaria a esta altura no hace falta realizar ninguna explicación. Y sobre la 2° condición que dice que "todos los dominios simples contienen únicamente valores atómicos" en criollo o castellano coloquial quiere decir "los atributos de la relación no pueden contener grupos repetitivos o multivalorados".

NroFactura

Codigo-Producto

Descripcion-Pdcto

Precio-Unitario-Pdcto

Canlidad_Vendida_Pdcto

Codigo_Cliente Nombre_Cliente

Fecha_de_Venta

3 2 Martillo 20.4 15 878 JuanPérez 02/03/04

3 5 Clavo 0.8 3110 878 JuanPérez 02103/0

4

3 9 Clavo 120 2 878 JuanPerez 02/03/04

3 15 Destornillad

or 7.5 8 878 JuanPérez 02/03/04

Aclaremos un poco: si miramos nuestra relación veremos que para una venta realizada en una determinada fecha con un número 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 atención observará que los atributos NroFactura, Codigo_Cliente, Nom bre_Cliente, Fecha_de_ Venta se repiten cn la tabla por cada aparición diferente de CòdigoProducto, Cantidad_ Vendida_Prod., Precio_Unitario_Prod. y Descripción_Prod. En realidad estos últimos atributos (los referentes al producto) no están cumpliendo con la segunda condición definida para que una relación se encuentre en lo FN y por ello los atributos correspondientes a la venta y al cliente se repiten en cada tupla, esto es lo que llamamos redundancia de datos.

CÓMO LOGRAR QUE UNA RELACIÓN QUEDE EN 1° FN

Eliminar de la relación original el o los atributos que no posean únicamente valores atómicos (o sea los que son grupos repetitivos).

Seleccionar la clave primaria de la relación original.

Crear una nueva relación que posea los atributos que son grupos repetitivos y fueron eliminados de la relación original.

El atributo que es clave primaria en la relación original será parte o formará parte de la clave primaria de la nueva relación.

Dar un nombre a la nueva relación y definir su clave primaria.

EJEMPLO

Eliminaremos de nuestra relación venta los siguientes atributos: Codigo_PIOduc to, Cantidad_ Vendida_PIod, Precio_Unitario_Prod Y Descripción_Prod.

Seleccionaremos como clave primaria de la relación venta el atributo NroFactura.

Definiremos una nueva relación con los siguientes atributos: Codigo_PIOducto, Cantidad_Vendida_Prod, recio_Unitario_prod Y Descripción_PIod

Agregaremos a la nueva entidad el atributo NroFactura que formará parte de la clave primaria de la nueva entidad.

Definiremos la relación con el nombre DETALLE_VENTA y tomaremos como cla ve primaria de la relación a los atributos NroFactura y Código_Producto.

Como consecuencia de lo anterior nos queda

un modelo relacional como el que se muestra a continuación en la Figura 2.

Venta

CP NroFactura

Codigo_ClienteNombre_ClienteFecha_de_Venta

detalle_venta

CPCP

NroFacturaCodigo_Producto

Descripcion_pdctoPrecio_Unitario_pdctoCantidad_Vendida_Pdcto

Figura 2. Las dos entidades ya en 1° EN con sus atributos claves subrayados.

VENTA

NroFactura Codigo_Cliente Nombre_Cliente Fecha_de_Venta

3 878 Juan Pérez 02/03/04

DETALLE VENTANroFactura Codigo_Product

oDescripcion_Pdcto

Precio_Unitario_Pdcto

Cantidad_Vendida_Pdcto.

3 2 Martillo 20,4 15

3 5 Clavo 0,8 300

3 9 Taladro 120 2

3 15 Destornillador 17.5 8

Tabla 2. Dos entidades ya en 1° FN con sus respectivos valores derivados de las tuplas originales.

Para que una relación se encuentre en 2° FN debe satisfacer las siguientes condiciones:

Debe estar en lº FN. Todos los atributos no clave dependen funcionalmente

de la clave primaria.

En nuestro ejemplo en cuestión la relación VENTA que estaba en·1° FN también se encuentra en 2° FN, pero la relación DETALLE_VENTA que se encuentra en 1 ° FN no se encuentra en 20 FN. Observe que el atributo Descripción_Prod depende funcionalmente del atributo Codigo_Producto que forma parte de la clave primaria de dicha relación, pero no depende funcionalmente del atributo NroFactura que también es uno de los atributos que forman parte de la clave primaria de la relación.

En cambio los atributos Cantidad_ Vendida_Prod y Precio_Unitario_Prod dependen funcionalmente de ambos atributos, que forman la clave primaria. Veremos ahora cómo lugramos que nuestra relación DETALLE_VENTA quede en 2° FN.

COMO LOGRAR QUE UNA RELACIÓN QUEDE EN 2º FN

Eliminar de la relación original el o los atributos que no dependan funcionalmente por completo de la clave primaria.

Crear una nueva relación que posea como atributos el o los atributos eliminados de la relación original.

Agregar a dicha relación el atributo de la clave primaria de la relación original del cual dependían funcionalmente los atributos no claves de la relación original.

El atributo del punto anterior será tomado como clave primaria de la nueva relación.

Darle un nombre a la nueva relación.

EJEMPLO

Sacaremos de la relación DETALLE_VENTA el atributo Descripción_Prod.

Crearemos una nueva relación que contenga el atributo Descripción_Prod.

Agregaremos a dicha relación el atributo Código_Producto.

Definiremos el atributo Código_Producto como clave primaria de dicha relación.

Llamaremos a dicha relación PRODUCTOS.

Venta

CP NroFactura

Codigo_ClienteNombre_ClienteFecha_de_Venta

Con lo cual nos queda un modelo relacional como el que muestra la Figura 3 en 2° FN.  

detalle_venta

CPCP

NroFacturaCodigo_Producto

Precio_Unitario_pdctoCantidad_Vendida_Pdcto

Producto

CP Codigo_Producto

Descripción_Pcdto

Figura 3. Nuestro modelo relacional con las tres relaciones en 2° FN.

VENTA

NroFactura Codigo_Cliente Nombre_Cliente Fecha_de_Venta

3 878 Juan Pérez 02/03/04

NroFactura Codigo_Producto Precio_Unitario_pdcto

Cantidad_Vendida_Pdcto

3 2 20,4 15

3 5 0,8 300

3 9 120 2

3 15 7,5 8

DETALLE_VENTA

Codigo_Producto Descripción_Pdcto

2 Martillo 5 Clavo 9 Taladro

15 Destornillador

PRODUCTOTabla 3. Las tres entidades ya en 2° FN con sus respectivos valores derivados de las tuplas originales.

Para que una relación se encuentre en 3° FN debe cumplir las siguiemes condiciones:

Debe estar en 20 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 relación VENTA, ya que los atributos Nombre_Cliente y Domicilio_Cliente dependen funcionalmenre 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 cómo nuestra relación VENTA puede quedar en 30 FN.

COMO LOGRAR QUE UNA RELACIÓN QUEDE EN 3º FN

Eliminar de la relación original los atributos no claves que dependen de manera no transitiva de la clave primaria.

Venta

CP NroFactura

Codigo_ClienteNombre_ClienteFecha_de_Venta

detalle_venta

CPCP

NroFacturaCodigo_Producto

Precio_Unitario_pdctoCantidad_Vendida_Pdcto

Producto

CP Codigo_Producto

Descripción_Pcdto

Cliente

CP Codigo_Cliente

Nombre_Cliente

Crear una nueva relación que contenga como atributos el o los atributos eliminados de la relación original.

Copiar el atributo no clave de la relación original del cual dependian transitivamente los atributos no claves eliminados de dicha relación.

Definir el atributo del punto anterior como clave primaria de la nueva relación.

Darle un nombre a la nueva relación.

EJEMPLO Eliminaremos de la relación VENTA los atributos

denominados Nombre_Cliente y Domicilio_Cliente. Crearemos a continuación una relación nueva con

los atributos Nombre_Cliente y Domicilio_Cliente. Copiaremos el atributo Codigo_Cliente a esta

nueva relación. Definiremos al atributo Codigo_Cliente como clave

primaria de esta relación. Daremos el nombre CLIENTES a la nueva

relación.

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

VENTA

NroFactura Codigo_Cliente Nombre_Cliente Fecha_de_Venta

3 878 Juan Pérez 02/03/04

NroFactura Codigo_Producto Precio_Unitario_pdcto

Cantidad_Vendida_Pdcto

3 2 20,4 15

3 5 0,8 300

3 9 120 2

3 15 7,5 8

DETALLE_VENTA

Codigo_Producto Descripción_Pdcto

2 Martillo 5 Clavo 9 Taladro

15 Destornillador

PRODUCTOCodigo_Cliente Nombre_CLient

e

878 Juan Pérez

CLIENTE

Tabla 4. Nuestro modelo relacional con cuatro tablas. todas ellas en 3' FN.

FORMA NORMAL DE BOYCE CODD

Muchas veces la 3º FN no satisface totalmente los criterios de normalización en los casos que nuestra relación posee más de una clave candidata.

En nuestro ejemplo eso no sucedía con ninguna de nuestras relaciones, o esas claves candidatas son claves compuestas y además existe la posibilidad que entre esas claves candidatas compartan algún atributo en común.

Para solucionar esta falencia que presentaba la 3° FN se definió con posterioridad la Forma Normal de Boyce/Codd.

Dicha forma normal se enuncia de la siguiente manera:

Una relación se encuentra en la forma normal de Boyce Codd sí y solo sí un determinante es una clave candidata. Pero no profundizaremos más en este tema pues él está fuera de los alcances de este libro.

La 4º FN se aplica para dependencias multivaluadas. Una relación se encuentra en 4º FN si cumple las siguientes condiciones:

Se encuentra en la forma normal de Boyce Codd. y

Todas las dependencias multivaluadas de dicha relación son por defecto dependencias funcionales.

Una relación se encuentra en 5° FN si se satisface que toda dependencia de reunión es consecuencia de las claves candidatas de la relación.

Una relación satisface la dependencia de reunión sí y solo sí dicha relación es igual a la reunión de sus proyecciones, donde cada proyección es un subconjunto del conjunto de arributos de la relación. Muchas veces cuando se descompone la relación en dos proyecciones de esta sucede el efecto no deseado de pérdida de formacion pero se puede evitar si dicha relación se descompone en más de dos proyecciones. Al suceder esto lo que garantiza la 5° FN es que con la reunión de una determinada manera de dichas proyecciones se puede reconstruir la relación y evitar la pérdida de información de ella.

INTEGRIDAD DEL MODELO DE DATOS

En este momento es bueno hacer algunos comentarios o complementar ciertos conceptos ya explicados en capítulos anteriores antes de seguir adelante.

Por ejemplo, en todas nuestras diferentes definiciones de clave primaria que dimos a los largo del libro aplicando los diferentes conceptos aprendidos, siempre hablamos que eran atributos únicos o que el resto de los atributos no clave dependían funcionalmente de ella, pero hay algo que no mencionamos: que las claves primarias no pueden contener el valor nulo o null como valor válido. Ya que una clave primaria no puede ser indefinida. Con lo cual la primera condición de integridad que debe cumplir un modelo relacional 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 queda algún 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 unívocamente a cada tupla de la relación y como contrapartida, el valor nulo en un atributo indica la indefinición o desconocimiento de su valor, por ende poco podría servir como clave primaria un atributo o conjunto de arributos con valor desconocido.

Esto además está relacionado con el concepto de que el modelo relacional, como ya dijimos anteriormente es una simulación o representación del mundo real, por ende es muy poco probable que en el mundo real existan elementos indefinidos o no identificables sin ambiguedad.

Ahora existe otro concepto subyacente al de clave

primaria, del cual no hemos hablado todavía y es el de clave foránea 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 relación P cuyos valores deben coincidir con el valor o los valores de los arributos que componen la clave primaria de alguna relación K.

Una aclaración que cae de maduro y por deducción a esta altura de nuestros conocimientos, es que los valores de la clave foránea y los valores de la clave primaria asociada con esa clave foránea pertenecen al mismo dominio. Es más, si ambas claves son compuestas, el dominio de cada atributo que compone ambas claves es el mismo. Para entender el concepto de clave foránea daremos un ejemplo que aclarará la situación.

Retornemos el modelo relacional de la Figura 4. Si nos fijamos en él con atención, el atributo Codigo_Cliente de la relación VENTA es una clave foránea de la clave primaria Codigo_Cliente de la relación CLIENTE.

Ahora expondremos la 2° condición de integridad del modelo relacional que es la condición de integridad referencial.

La condición de integridad referencial lo que pide es que no existan en el modelo relacional valores para las claves foráneas sin coincidencia con los valores de las claves primarias asociadas a ella.

Veamos con un ejemplo qué es lo que nos está pidiendo la 2° condición.

Volvamos a nuestro ejemplo de la Figura 3 con nuestras relaciones VENTA y CLIENTE. El modelo no podría tener registrada una venta para un cliente inexistente, ya que eso no cumpliría la condición de integridad referencial y fíjese que lógico que es esto. En la vida real solo es válido realizar una venta a un cliente existente y no tendría 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.

Venta

CP NroFactura

Codigo_ClienteNombre_ClienteFecha_de_Venta

detalle_venta

CPCP

NroFacturaCodigo_Producto

Precio_Unitario_pdctoCantidad_Vendida_Pdcto

Producto

CP Codigo_Producto

Descripción_Pcdto

Cliente

CP Codigo_Cliente

Nombre_Cliente

Figura 4. Modelo relacional normalizado y con la integridad

referencial definida.

Veremos ahora el diagrama de nuestro modelo de

ventas con las restricciones de integridad referencial aplicadas. La suma de la flecha indica una cardinalidad de 1 y la línea 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 representación gráfica, pero el concepto es el mismo).

Quiere decir que esto se leería o diría de la siguiente manera visto de la relación CLIENTE "Un cliente tiene muchas ventas" o dicho de otra manera visto desde la relación VENTA "Muchas ventas son de un clienre".

Lo mismo se podría hacer con VENTA y DETALLE_VENTA,

parados en VENTA diríamos "Una venta posee muchos detalles de venta" y parados en DETALLE_VENTA diríamos "Muchos detalles de venta pertenecen a una venta" y lo mismo entre PRODUCTO Y DETALLE_VENTA; parados en PRODUCTO diríamos "Un producto puede existir en muchos detalles de venta" y parados en DETALLE_VENTA diríamos "Muchos detalles de venta contienen un producto."