lunes, 21 de diciembre de 2015

Tercera Forma Normal (3FN)

 En realidad si nos guiamos en el ejemplo de esta nota, ya no quedaria normalización por aplicar y podriamos decir que nuestro ejemplo cumple con las 3 formas normales, ya que la 3ra Forma Normal nos habla de que :
  1. Ninguna Columna puede depender de una columna que no tenga una clave
  2. No puede haber datos derivados
En el 2do ejemplo hemos descubierto campos que dependian de la clave principal (VentaID) y que podrian 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.
 VentaIDItemID ProductoID Cantidad Descripcion Medida Proveedor 
 13455 12 Impresora HP LJ8000 122cm 
 12455 34 Scanner HP A3555 33cm 
 215444 21 Mouse HP Wireless – 
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 deberian estar dentro de la tabla de detalle de ventas, ya que dependen de PRODUCTOID.Aqui no se trata ya de eliminar grupos repedidos de datos (1ra Forma Normal) sino que ante la inclusion 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.
Linkografia: 
  https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3-formas-normales/
 Segunda Forma Normal (2FN)

 (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 tuvieramos alguna columna que se repite a lo largo de todos los registros, dichos datos deberian atomizarse en una nueva tabla.Veamos un ejemplo
 VentaIDItemID FechaVenta ClienteVenta ProductoId Cantidad 
1 01/12/20072334 10 
 01/12/200723333
 01/12/2007266643 34 
 01/12/200721 
 1 02/12/20073566 
Ahi 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 columnaClienteVenta y FechaVenta se repetirán por cada venta realizada.Es por ello que proponemos el siguiente esquema 
 VentaIDItemID ProductoId Cantidad 
12334 10 
3333
66643 34 
21 
 13566 
Y ahora nuestra nueva tabla maestra
VentaId FechaVenta ClienteVenta 
101/12/2007 2
02/12/2007 
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 unico para cada grupo de registros.
Linkografia:
https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3-formas-normales/
Primera Forma Normal (1FN)





 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 deberia figurar el codigo del cliente, para que el resto de los datos se puedan referenciar automaticamente sin problemas y sin duplicar información.Lo mismo ocurriria en una tabla de detalle de ventas, si por cada item vendido colocamos el detalle del producto, con su descripción , medidas, etc…Tendriamos 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.

Linkografia:
https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3-formas-normales/

Normalización de bases de datos

El proceso de normalización de bases de datos consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.
Las bases de datos relacionales se normalizan para:
  • Evitar la redundancia de los datos.
  • Disminuir problemas de actualización de los datos en las tablas.
  • Proteger la integridad de los datos.
En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:
  • Cada tabla debe tener su nombre único.
  • No puede haber dos filas iguales. No se permiten los duplicados.
  • Todos los datos en una columna deben ser del mismo tipo.
Linkografia:
                   https://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos