CASO PRÁCTICO NORMALIZACIÓN

NORMALIZACIÓN CASO PRÁCTICO

La NORMALIZACIÓN es un conjunto de reglas que sirven para ayudar a desarrollar un esquema de BD que minimice los problemas de lógica y redundancia. Vamos analizar la siguiente tabla: (Ver diapositiva siguiente)        

db6081ac-fdff-4e8a-bd79-a3f9057dcc0d (image/png)

Pie de foto: : Formas normales

NORMALIZACIÓN CASO PRÁCTICO

Ordenes (binary/octet-stream)

Pie de foto: : Tabla Factura

Analizando tabla Factura

En ésta tabla se guarda información referente a una FACTURA. -El primer paso es identificar qué ENTIDADES U OBJETOS de la realidad podemos detectar. Por ejemplo, en la tabla se guarda información de tres principales objetos: - FACTURA: Número de Factura, Fecha, Clientes, Información de los productos. Aquí también podemos guardar el STATUS de la factura, ya que ésta puede ser: Abierta, Cerrada, Cancelada. - CLIENTES: Número de cliente, dirección, cédula del cliente, ciudad, teléfono. - PRODUCTOS: Categoría, código, Descripción, valor unitario, precio, línea de producto. - Proveedor: Nombre del proveedor al que se compran los productos.

PRIMERA FORMA NORMAL (1FN)

Establece que: "las celdas de la tabla deben tener un solo valor (deben ser valores atómicos) y no se permiten ni grupos ni arreglos repetidos como valores. Las columnas repetidas deben  colocarse en tablas separadas." Por lo tanto en la tabla debemos detectar: ¿CUÁLES DATOS O GRUPOS SON LOS QUE SE REPITEN? En la tabla observamos que los datos del CLIENTE SE REPITEN EN VARIAS TUPLAS O RENGLONES, puesto que  la regla de negocio dice: "Un cliente puede comprar uno o muchos productos (1:N)". Pero, los datos como Nombre, y Estado, provocan que haya redundancia (duplicación) de datos. También, se duplican los datos de Id_Orden, Fecha, y los datos del producto como son el nombre del producto,  Nombre de Proveedor, línea de producto. Esto se ocasiona por la regla de negocio del cliente. Por lo tanto la regla indica que se tendrán que colocar en tablas separada estos datos. Pero, debemos dejar el (los) atributo (s) que relacionen dichas tablas, ya que se convierten en una Entidad fuerte y débil. (sig)

PRIMERA FORMA NORMAL

Primer Forma (binary/octet-stream)

Pie de foto: : Tabla factura se dividió en dos partes: Una donde se guarden los datos de la factura que no se repitan y otra donde se guarde la lista de productos.

SEGUNDA FORMA NORMAL (2FN)

¿Que establece la segunda forma normal? -La tabla DEBE ESTAR EN PRIMERA FORMA NORMAL.-Se tienen que identificar las dependencias funcionales . Es decir, las columnas que  DEPENDAN FUNCIONALMENTE DE LA LLAVE PRIMARIA.- Y, se deben ELIMINAR los atributos que no dependan funcionalmente de la llave primaria. - Para aplicar la segunda forma normal SE DEBE IDENTIFICAR LA LLAVE PRIMARIA DE LAS TABLAS.PERO ENTONCES ¿QUÉ ES UNA DEPENDENCIA FUNCIONAL?Es una relación entre uno o más atributos. VEAMOS EL EJEMPLO (sig. diapositiva)  

SEGUNDA FORMA NORMAL

Factura 2 Fn (binary/octet-stream)

Detalle Fact 2 Fn (binary/octet-stream)

Pie de foto: : ¿Qué atributos dependen de la llave primaria?

Pie de foto: : ¿Qué atributos dependen de la llave primaria?

SEGUNDA FORMA NORMAL

Tabal Clientes (binary/octet-stream)

Tabla Detalle Factura (binary/octet-stream)

Pie de foto: : Así quedarían las tablas en SEGUNDA FORMA NORMAL (2FN)

Pie de foto: : Así queda la tabla Factura hasta segunda forma normal

TERCERA FORMA NORMAL (3FN)

La tercer forma normal  establece:  -La tabla debe estar en primera y segunda forma normal. - Establece que en una relación  se deberán eliminar las dependencias transitivas. ¿Pero qué es una dependencia transitiva? Es la relación indirecta que hay entre un atributo  y una llave primaria. Aquí, se debe analizar si hay atributos que dependen indirectamente de la llave primaria. Veamos un ejemplo con la tabla ARTÍCULOS (Ve la siguiente diapositiva)   

TERCERA FORMA NORMAL

Hasta ahorita tenemos las siguientes tablas: Factura  y Detalle de factura, ya normalizadas hasta la 2FN.  También, separamos los datos de clientes y artículos, y se colocan en sus tablas correspondientes. Las tablas Factura, detalle de factura y clientes ya estarían normalizadas puesto que: no hay grupos repetidos y todas las columnas dependen funcionalmente de la llave primaria y son necesarias en las tablas. Pero ¿qué pasa con la tabla Artículos?

Tablas Normalización1 (binary/octet-stream)

TERCERA FORMA NORMAL

Supongamos que tenemos la siguiente tabla de artículos donde la llave primaria es NUMART. ¿Cumple con la primer forma normal? No. Puesto que hay grupos repetidos. Esto es por que la regla de negocio dicta: "Un proveedor puede surtir muchos artículos".  ¿Cumple con la segunda forma normal? No, ya que no está en primer forma normal y además, los datos del nombre del proveedor y el nombre de línea de producto NO DEPENDEN DE LA LLAVE PRIMARIA (NumArt). ¿Cumple con la tercer forma normal? No. Ya que el proveedor depende indirectamente de las llave primaria ID_ORDEN de la Factura donde originalmente se encontraban estos datos.

Tabla Articulo (binary/octet-stream)

Pie de foto: : ¿Qué pasa con la tabla ARTÍCULOS?

TERCER FORMA NORMAL.

Proveedores3fn (binary/octet-stream)

En la tercer forma normal, se deben eliminar POR COMPLETO los atributos transitivos, entonces, analicemos el caso del proveedor: 1. Un proveedor, depende de la existencia de un artículo, ya que para que pueda existir un proveedor en el proceso, debe existir un artículo el cual va a surtir. 2. Un artículo para que se pueda vender, debe ser facturado (vendido).  3. Entonces un PROVEEDOR, depende TRANSITIVAMENTE (indirectamente) de la existencia de una FACTURA. Ya que para que pueda existir un proveedor en la tabla, depende de que el artículo se siga vendiendo, de lo contrario, dicho proveedor se daría de baja. Entonces, se elimina TOTALMENTE  de la tabla de Artículos y se separan los datos del proveedor en una tabla. En otra, SE GUARDAN LOS DATOS DE LA RELACIÓN Artículos-Proveedor, que contienen las llaves PRIMARIAS de artículos y del proveedor. 

¿Cómo quedan las tablas normalizadas?

Tablas Finales (binary/octet-stream)

¡¡NOTAS IMPORTANTES!!

1. El análisis de las tres FORMAS NORMALES se deberá hacer para cada tabla que tengamos en el ESQUEMA DE BASE DE DATOS. Y también, las tablas nuevas que van surgiendo, se deben analizar si cumplen con las reglas de normalización. PERO... 2. NO NECESARIAMENTE SE TIENEN QUE APLICAR TODAS LAS REGLAS DE NORMALIZACIÓN. Puede ser que una tabla desde su estructura original, ya se encuentre normalizada. Así que, mientras se cumplan las tres reglas en una tabla, SE PUEDE DEJAR TAL COMO ESTÁ. 3. Recuerda que para cada tabla, debes TENER EN CUENTA CUÁL ES SU LLAVE PRIMARIA (PK), ya que todos los atributos que la relacionan dependen funcionalmente de ella y tu puedas identifcarlo. 4. Para que tengas un panorama general de cómo normalizar las tablas, es recomendable hacer una PRUEBA DE ESCRITORIO. Esto es, llenar las tablas con datos reales o ficticios, con el fin de que veas cómo se están guardando los datos, y así, puedas observar si es necesario aplicar las reglas de normalización.