Normalizacin

Consiste en designar y aplicar una serie de reglas a las

relaciones obtenidas tras el paso del modelo entidadrelacin al modelo relacional.
Las bases de datos relacionales se normalizan para:
Evitar la redundancia de los datos.
Disminuir problemas de actualizacin de los datos en las tablas.
Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una

relacin, aunque para que una tabla sea considerada como
una relacin 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.

Terminologa
Relacin =tabla
Registro =registro, otupla
Atributo =columnao campo
Clave = llave o cdigo de identificacin
Clave Candidata = superclave mnima
Clave Primaria = clave candidata elegida
Clave Externa = clave ajena o clave fornea
Clave Alternativa = clave secundaria
Dependencia Multivaluada = dependencia multivalor

PRIMERA FORMA NORMAL

Una tabla est en Primera Forma Normal si:
Todos los atributos son atmicos. Un atributo es atmico si los elementos del
dominio son simples e indivisibles.
La tabla contiene una clave primaria nica.
La clave primaria no contiene atributos nulos.
No debe existir variacin en el nmero de columnas.
Los Campos no clave deben identificarse por la clave (Dependencia Funcional)
Debe Existir una independencia del orden tanto de las filas como de las columnas, es
decir, si los datos cambian de orden no deben cambiar sus significados
Esta forma normal elimina los valores repetidos dentro de una Base de Datos.

Ejemplo
Qu ocurre cuando se agrega un tercer proveedor? Agregar un
campo no es la respuesta, requiere modificaciones en las tablas
y el programa, y no admite fcilmente un nmero variable de
proveedores. En su lugar, coloque toda la informacin de los
proveedores en una tabla independiente denominada
Proveedores y despus vincule el inventario a los proveedores
con el nmero de elemento como clave, o los proveedores al
inventario con el cdigo de proveedor como clave.

SEGUNDA 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 tuviramos alguna
columna que se repite a lo largo de todos los registros, dichos datos
deberian atomizarse en una nueva tabla. Veamos un ejemplo
VentaID

ItemID

FechaVenta

ClienteVenta

ProductoId

Cantidad

01/12/2007

2334

10

01/12/2007

3333

01/12/2007

66643

34

01/12/2007

21

02/12/2007

3566

 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
columna ClienteVenta y FechaVenta se repetirn por cada venta
realizada. Es por ello que proponemos el siguiente esquema.
VentaID

ItemID

ProductoId

Cantidad

2334

10

3333

66643

34

21

3566

Y ahora nuestra nueva tabla maestra

VentaId

FechaVenta

ClienteVenta

01/12/2007

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.

TERCERA FORMA NORMAL

En realidad si nos guiamos en el ejemplo de esta nota, ya no quedaria
normalizacin por aplicar y podriamos 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 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.

VentaID

ItemID

ProductoID

Cantidad

Descripcion

Medida

Proveedor

3455

12

Impresora HP LJ8000

122cm

2455

34

Scanner HP A3555

33cm

5444

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 deberan 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 inclusin 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.

Bibliografa:
https://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de
_bases_de_datos#Formas_normales
http://www.monografias.com/trabajos5/norbad/norbad.s
html
https://cvva.wordpress.com/2007/12/04/normalizacion-d
e-bases-de-datos-las-3-formas-normales/
https://support.microsoft.com/es-ec/kb/283878
http://www.ecured.cu/Normalizaci%C3%B3n_de_una_bas
e_de_datos