Normalización 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.

Terminología Relación = tabla Registro = registro, o tupla Atributo = columna o campo Clave = llave o código de identificación Clave Candidata = superclave mínima Clave Primaria = clave candidata elegida Clave Externa = clave ajena o clave foránea Clave Alternativa = clave secundaria Dependencia Multivaluada = dependencia multivalor

PRIMERA FORMA NORMAL Una tabla está en Primera Forma Normal si: Todos los atributos son atómicos. Un atributo es atómico 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 variación en el número 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 fácilmente un número variable de proveedores. En su lugar, coloque toda la información de los proveedores en una tabla independiente denominada Proveedores y después vincule el inventario a los proveedores con el número de elemento como clave, o los proveedores al inventario con el código 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 tuviéramos 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 /12/ /12/ /12/ /12/ /12/

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 repetirán por cada venta realizada. Es por ello que proponemos el siguiente esquema. VentaIDItemID ProductoId Cantidad

Y ahora nuestra nueva tabla maestra VentaId FechaVenta ClienteVenta 101/12/ /12/ 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 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 : 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.

VentaIDItemID ProductoID Cantidad Descripcion Medida Proveedor Impresora HP LJ cm Scanner HP A cm Mouse HP Wireless – 1 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. Aqui no se trata ya de eliminar grupos repedidos 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.

Bibliografía: tos#Formas_normales tos#Formas_normales datos-las-3-formas-normales/ datos-las-3-formas-normales/ s s