Normalización de Bases de Datos

 

 ¿Qué es la normalización de bases de datos?

Es el proceso de organizar los datos de una base de datos valga la redundancia debemos tener en cuenta la creación de tablas y las reglas que se usan para definir las relaciones, estas reglas son diseñadas para proteger los datos y para que la base de datos sea flexible con el fin de eliminar redundancias y dependencias incoherentes.

 

El proceso de normalización se basa en la descomposición sin pérdida de las tablas que están en una forma normal inferior, obteniéndose una forma normal superior. El proceso de descomposición sin pérdida, significa que se ha de dividir o descomponer la tabla en otras con menor cantidad de atributos sin que haya pérdida de información

                       Dependencia funcional

Una dependencia funcional es una relación entre uno o más atributos. Por ejemplo, si se conoce el valor de DNI (Documento Nacional de Identidad-España) tiene una conexión con Apellido o Nombre.

Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:

FechaDeNacimiento → {\displaystyle \rightarrow } Edad

De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener estas dependencias funcionales para lograr la eficiencia en las tablas. 

     B es funcionalmente dependiente de A.

 

 

 

 

                  Primera forma normal

• Eliminar grupos de repetición en tablas individuales.
• Cree una tabla independiente para cada conjunto de datos relacionados.
• Identifique cada conjunto de datos relacionados con una clave principal.

No use varios campos en una sola tabla para almacenar datos similares. Por ejemplo, para realizar un seguimiento de un elemento de inventario que puede provenir de dos orígenes posibles, un registro de inventario puede contener campos para el código de proveedor 1 y el código de proveedor 2.

 

 

 

 

 

 

                  Segunda forma normal

• Crear tablas independientes para conjuntos de valores que se aplican a varios registros.
• Relacione estas tablas con una clave externa.

Los registros no deben depender de nada que no sea la clave principal de una tabla (una clave compuesta, si es necesario). Por ejemplo, considere la dirección de un cliente en un sistema de contabilidad. La dirección es necesaria para la tabla clientes, pero también las tablas pedidos, envíos, facturas, cuentas a cobrar y colecciones. En lugar de almacenar la dirección del cliente como una entrada independiente en cada una de estas tablas, almacénela en un lugar, ya sea en la tabla customers (clientes) o en una tabla de direcciones independiente.

 

 

 

 

 

Tercera forma normal

• Eliminar los campos que no dependen de la clave.

Los valores de un registro que no forman parte de la clave de ese registro no pertenecen a la tabla. En general, siempre que el contenido de un grupo de campos se aplique a más de un registro de la tabla, considere la posibilidad de colocar dichos campos en una tabla independiente.

Por ejemplo, en una tabla de contratación de empleados, puede incluirse el nombre de la Universidad y la dirección de un candidato. Pero necesita una lista completa de las universidades para los correos de grupo. Si la información de la Universidad se almacena en la tabla candidatos, no hay forma de enumerar universidades sin candidatos actuales. Cree una tabla universidades independiente y vincúlelo a la tabla candidatos con una clave de código de Universidad.

EXCEPCIÓN: cumplir con la tercera forma normal, aunque teóricamente deseable, no siempre es práctico. Si tiene una tabla Customers y desea eliminar todas las dependencias entre campos posibles, debe crear tablas independientes para ciudades, códigos postales, representantes de ventas, clases de clientes y cualquier otro factor que se pueda duplicar en varios registros. En teoría, la normalización merece la pena pursing. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar las capacidades de memoria y de archivos abiertos.

Es posible que sea más factible aplicar la tercera forma normal solo a los datos que cambian con frecuencia. Si se conservan algunos campos dependientes, diseñe la aplicación para exigir al usuario que compruebe todos los campos relacionados cuando se modifique cualquiera de ellos.

 

 

Otras formas de normalización

Hay un cuarto formulario normal, también denominado formulario normal de Boyce Codd (BCNF), y la quinta forma normal, pero rara vez se consideran en un diseño práctico. Si no se tienen en cuenta estas reglas, es posible que el diseño de la base de datos sea inferior al perfecto, pero no debería afectar a la funcionalidad.

 

Normalización de una tabla de ejemplo

En estos pasos se muestra el proceso de normalización de una tabla de alumnos ficticia.

1.  Tabla no normalizada:

	Tabla 1
Compañero #		Asesor	Salón de avanzada	Class1	Class2	Class3
1022		Pérez	412	101-07	143-01	159-02
4123		Saavedra	216	201-01	211-02	214-01

1    Primera forma normal:

 sin grupos de repetición Las tablas solo deben tener dos dimensiones. Como un estudiante tiene varias clases, estas clases deben aparecer en una tabla independiente. Los campos Class1, clase2 y Class3 en los registros anteriores son indicaciones de problemas de diseño.

Las hojas de cálculo suelen usar la tercera dimensión, pero las tablas no deben. Otra forma de analizar este problema es con una relación de uno a varios, no ponga en el lado uno y en el lado varios de la misma tabla. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo extensible (número de clase), como se muestra a continuación:

Tabla 2
Compañero #	Asesor	Salón de avanzada	Tipo #
1022	Pérez	412	101-07
1022	Pérez	412	143-01
1022	Pérez	412	159-02
4123	Saavedra	216	201-01
4123	Saavedra	216	211-02
4123	Saavedra	216	214-01

 

2    Segunda forma normal:

elimine datos redundantes Tenga en cuenta los valores de varias clases # para cada valor de número de alumno de la tabla anterior. La clase # no depende funcionalmente del número de estudiante (clave principal), por lo que esta relación no está en la segunda forma normal.

 

En las dos tablas siguientes se muestra la segunda forma normal:

Deben

Tabla 3
Compañero #	Asesor	Salón de avanzada
1022	Pérez	412
4123	Saavedra	216

Registro

Tabla 4
Compañero #	Tipo #
1022	101-07
1022	143-01
1022	159-02
4123	201-01
4123	211-02
4123	214-01

 

3.Tercera forma normal:

 elimina datos que no dependen de la clave en el último ejemplo, el salón de avanzada (el número de la oficina del Consejero) depende funcionalmente del atributo asesor. La solución consiste en mover el atributo de la tabla Students a la tabla profesores, como se muestra a continuación:

Deben

Tabla 5
Compañero #	Asesor
1022	Pérez
4123	Saavedra

Profesor

Tabla 6
Nombre	Sala	Departamento
Pérez	412	42
Saavedra	216	42