NORMALIZACIÓN

El proceso de normalización de bases de datos consiste en 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.
• Evitar 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.

Primera forma normal (1FN):

“Una relación está en primera forma normal (1FN) si los valores para cada atributo de la relación son atómicos”.

Una tabla está en Primera Forma Normal sólo si

• Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.
• La tabla contiene una clave primaria
• La tabla no contiene atributos nulos

Ejemplo:

1. En una tienda de ropa se venden prendas en distintos tamaños. Para almacenar la información de estos artículos, se diseñó el siguiente esquema: Prenda (id, descripción, marca, tallas). El atributo “tallas” se almacenan los distintos tamaños que tiene cada prenda. P/E (3424, “camisa”, “Levis”, “ch, mediana, grande”). Aplica la FN1 para eliminar la inconsistencia de esta tabla.

Prenda
id	descripción	marca	tallas
3424	Camisa	Levis	Ch
3424	Camisa	Levis	mediana
3424	Camisa	Levis	grande

Segunda forma normal (2FN):

“Una relación está en segunda a normal si está en la 1ª FN y todos los atributos no clave dependen de la clave completa y no sólo de una parte de esta”.

Este paso sólo se aplica a relaciones que tienen claves compuestas, es decir, que están formadas por mas de un atributo.

Ejemplo:

1. El siguiente esquema se utiliza para almacenar los cursos en los que está inscrito un alumno: Cursos (Curso, id_alumno, Nombre_alumno, Apellidos_alumno, Teléfono). Aplica la FN2 para eliminar las dependencias parciales.

cursos
Curso	id_alumno	Nombre_alumno	Apellidos_alumno	Teléfono

Alumno
id_alumno	Nombre_alumno	Apellidos_alumno	Teléfono

cursos
Curso	id_alumno

Tercera forma normal (3FN):

"Una relación está en tercera forma normal si todos los atributos de la relación dependen funcionalmente sólo de la clave, y no de ningún otro atributo".

Ejemplo:

1. Observa la siguiente tabla: Artículo (Artículo, proveedor, tel_proveedor). Cada artículo sólo puede ser vendido por un proveedor. Aplica la FN3 para evitar la redundancia de la información.

Articulo
Articulo	Proveedor	Tel_proveedor

Articulo
Articulo	Proveedor

Proveedor
Proveedor	Tel_proveedor

Forma Normal de Boyce-Codd (FNBC)

Es una forma normal utilizada en la normalización de bases de datos. Es una versión ligeramente más fuerte de la Tercera forma normal (3FN).

“La forma normal de Boyce-Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata”.

Ejemplo:

1. Observa el siguiente esquema: Artículos (id_proveedor, RFC, id_artículo). El esquema anterior se hizo para almacenar a los proveedores con sus artículos, pudiendo un proveedor vender varios artículos. Aplica la FNBC para evitar inconsistencia en la información.

Artículos
Id_proveedor	RFC	Id_articulo

Artículos
Id_proveedor	Id_articulo

proveedor
Id_proveedor	RFC

Tabla de Contenidos de normalización:

Forma normal	Qué se debe cumplir para estar en esta FN	Pasos a seguir para que un diseño esté en esta FN	Observaciones adicionales
1FN	“Una relación está en primera forma normal (1FN) si los valores para cada atributo de la relación son atómicos”.	Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos. La tabla contiene una clave primaria La tabla no contiene atributos nulos
2FN	“Una relación está en segunda a normal si está en la 1ª FN y todos los atributos no clave dependen de la clave completa y no sólo de una parte de esta”.	Este paso sólo se aplica a relaciones que tienen claves compuestas, es decir, que están formadas por mas de un atributo.	Un alternativa 2NF a este diseño representaría la misma información en dos tablas:
3FN	"Una relación está en tercera forma normal si todos los atributos de la relación dependen funcionalmente sólo de la clave, y no de ningún otro atributo".	La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo, Año} vía el atributo no primario Ganador.	Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos. Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la BCNF
FNBC ó BCFN	es más rigurosa que la 3NF en que no permite ninguna dependencia funcional en la cual el conjunto determinante de atributos no sea una clave candidato (o superconjunto de eso).	Cualquier tabla que sea insuficiente en FNBC será vulnerable a inconsistencias lógicas. En la tabla de arriba podía ser representada una combinación inconsistente de ID Tutor y Número de seguro social del tutor.	corregir el problema sería una simple cuestión de usar solo un esquema de identificación para los tutores: o el ID, o el número del seguro social, pero no ambos.