Normalización de Bases de Datos
•Existen 3 niveles de Normalización que
deben respetarse para poder decir que nuestra Base de Datos, se encuentra
NORMALIZADA, es decir, que cumple con los requisitos naturales para funcionar
óptimamente y no perjudicar las Performance por mala arquitectura.
•Estas 3 reglas de Normalización se las
conoce como las 3
FORMAS NORMALES.
La Primera Forma Normal
•Esta primera Forma Normal, nos lleva a no
repetir datos en nuestras tablas. Los famosos maestro – detalle, deben
aplicarse a la estructura de la tabla. Si nuestra tabla de ventas repite una y
otra vez (por cada venta) , el nombre, el domicilio y otros datos del Cliente,
es que no hemos aplicado esta Normalización. Si tenemos una tabla clientes, en
la tabla ventas, solo debería figurar el código del cliente, para que el resto
de los datos se puedan referenciar automáticamente sin problemas y sin duplicar
información. Lo mismo ocurriría en una tabla de detalle de ventas, si por cada ítem
vendido colocamos el detalle del producto, con su descripción , medidas, etc.
Tendríamos un
desaprovechamiento de espacio y recursos muy grande. Para ello, tendremos
nuestra tabla maestra de Productos y con solo grabar el código de dicho
producto en nuestra tabla de ventas, será suficiente.
La Segunda Forma Normal
•(Si o si debe estar previamente aplicada
la Primera Forma Normal) La Segunda Forma Normal nos habla de que cada
columna de la tabla debe depender de la clave. Esto significa que todo un
registro debe depender únicamente de la clave principal, si tuviéramos alguna
columna que se repite a lo largo de todos los registros, dichos datos deberían
atomizarse en una nueva tabla. Veamos un ejemplo:
•Ahí tenemos un claro problema !!!Acaso no
se busca NO
REPETIR DATOS ?Si toda una venta tendrá el
mismo numero de Cliente y la misma Fecha. Por que no crear una Tabla de MAESTRO DE VENTAS y que contenga esos 2 datos ? Es
evidente que la columna ClienteVenta y FechaVenta se repetirán por cada venta realizada. Es
por ello que proponemos el siguiente esquema
•Y ahora nuestra nueva tabla maestra
•Entonces, nuestra 2da Forma Normal nos
habla de que cada columna de una tabla debe depender de toda la clave y no
constituir un dato único para cada grupo de registros.
La Tercera Forma Normal
• En realidad si nos guiamos en el
ejemplo anterior, ya no quedaría normalización por aplicar y podríamos decir
que nuestro ejemplo cumple con las 3 formas normales, ya que la 3ra Forma
Normal nos habla de que :
•Ninguna Columna puede depender de
una columna que no tenga una clave
•No puede haber datos derivados
•En el 2do ejemplo hemos descubierto
campos que dependían de la clave principal (VentaID) y que podrían incluirse en
una tabla maestra. Pero supongamos un ejemplo donde ciertas columnas no
dependen de la clave principal y si dependen de una columna de nuestra tabla.
•Esto es muy normal encontrar en bases mal
normalizadas. Vemos que los campos DESCRIPCION ,
MEDIDA y PROVEEDOR no dependen de VENTAID y es por ello que no deberían estar
dentro de la tabla de detalle de ventas, ya que dependen de PRODUCTOID. Aquí no
se trata ya de eliminar grupos repetidos de datos (1ra Forma Normal) sino que
ante la inclusión de una clave perteneciente a otra tabla, cualquier campo que
sea subordinado de dicha clave debe estar en otra tabla y no en nuestra tabla
detalle.
Conclusión
•Finalmente si tomamos en cuenta que una
tabla de detalle de venta (item x item) puede contener un volumen de millones
de registros, al haberle aplicado las 3 formas normales nos estaremos ahorrando
varios Gigabytes de tamaño en dicha tabla y por supuesto mejorado notablemente
la performance (desempeño).
Taller
•Crear un sistema de información usando
bases de datos utilizando las 3 formas de normalización para bases de datos.
Para poder empezar a diseñar y crear una base de datos debemos empezar por crear diferentes bases de datos, Vamos a crear una base de datos de ventas, en la cual vamos a poder empezar a entender que es una tabla y como se compone, que campos o estructura de la tabla tendrá de acuerdo al tema o categoría de los datos a almacenar.
- Como se observa en la imagen anterior, diseñamos nuestra base de datos con las siguientes tablas:
- Producto
- Unidad
- Factura
- FacturaDetalle
- Ciudad
- Pais
- Cliente
- Vendedor
- Proveedor
- CuotaVendedor
