Normalización de Bases de Datos
¿Qué es?
Es el proceso de organizar los datos de una base de datos. Incluyendo la creación de tablas y el establecimiento de relaciones entre ellas según reglas diseñadas tanto para proteger los datos como para hacer que la base de datos sea más flexible eliminando la redundancia y las dependencias incoherentes.
Redundancias
Los datos que son redundantes tienden a desperdiciar espacio de disco que a su vez crean problemas de mantenimiento. Convierten ciertas acciones ineficientes pues por poner un ejemplo al cambiar un dato y este existe en mas de un lugar es necesario cambiarlo de la misma forma una serie de veces en todas sus ubicaciones.
Dependencia Incoherente
Aunque es intuitivo para un usuario mirar en la tabla Clientes para buscar la dirección de un cliente en particular, puede no tener sentido mirar allí el salario del empleado que llama a ese cliente. El salario del empleado está relacionado con el empleado, o depende de él, y por lo tanto se debería pasar a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso porque la ruta para encontrar los datos puede no estar o estar interrumpida.
Existen reglas en la normalización de una base de datos a las que se les denomina "forma normal", es decir, si la primer regla es cumplida se dice que está en "primera forma norma", si se cumple la segunda está en "segunda forma normal" y así sucesivamente. Hay varios niveles de normalización, sin embargo, es la tercer forma normal la considerada el máximo nivel necesario en gran parte de las aplicaciones.
Al
igual que con otras muchas reglas y especificaciones formales, en los
escenarios reales no siempre se cumplen los estándares de forma perfecta. En general, la normalización requiere tablas adicionales y algunos clientes consideran éste un trabajo considerable.
Si decide infringir una de las tres primeras reglas de la
normalización, asegúrese de que su aplicación se anticipa a los
problemas que puedan aparecer, como la existencia de datos redundantes y
de dependencias incoherentes. (Support Microsoft, 2016)
Uno de los parámetros que mide la calidad de una base de datos es la forma normal en la que se encuentra su diseño. Esta forma normal puede alcanzarse cumpliendo ciertas restricciones que impone cada forma normal al conjunto de atributos de un diseño. El proceso de obligar a los atributos de un diseño a cumplir ciertas formas normales se llama NORMALIZACIÓN.
Como se fue sugiriendo anteriormente lo que pretenden lograr son dos objetivos.
1.- Almacenar en la base de datos cada hecho solo una vez, reduciendo el espacio de almacenamiento.
2.- Que los hechos distintos se almacenen en sitios distintos. Esto evita ciertas anomalías a la hora de operar con los datos.
Primera Forma Normal (1FN)
Una tabla está en Primera Forma Normal si:
Todos los atributos son «atómicos». Por ejemplo, en el campo teléfono no tenemos varios teléfonos.
La tabla contiene una clave primaria única. Por ejemplo el NIF para personas, la matrícula para vehículos o un simple id auto-incremental. Si no tiene clave, no es 1FN.
La clave primaria no contiene atributos nulos. No podemos tener filas para las que no haya clave (por ejemplo, personas sin NIF o vehículos sin matrícula).
No debe existir variación en el número de columnas. Si algunas filas tienen 8 columnas y otras 3, pues no estamos en 1FN.
Los campos no clave deben identificarse por la clave. Es decir, que los campos no clave dependen funcionalmente de la clave. Esto es prácticamente lo mismo que decir que existe clave primaria.
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. Por ejemplo, si en la columna 1 tenemos el primer apellido y en la columna 2 tenemos el segundo, pues no estamos en 1FN. Igualmente si en la tercera fila tenemos el tercer mejor expediente y en la quinta fila el quinto, no estamos en 1FN.
Segunda Forma Normal (2FN)
Una tabla está en 2FN si además de estar en 1FN cumple que los atributos no clave depende de TODA la clave principal.
Por ejemplo, si tenemos una tabla con Personas, identificadas por su NIF y recogemos su empresa y dirección de trabajo, la clave sería NIF-Empresa. Pero nos encontraremos con que una misma persona puede trabajar en varias empresas. Y vemos que la dirección de trabajo no depende de TODA la clave primaria, sino solo de la empresa. Por lo tanto, no estamos en 2FN.
Tercera Forma Normal (3FN)
Una tabla está en 3FN si además de estar en 2FN no existe ninguna dependencia transitiva entre los atributos que no son clave.
Supongamos que tenemos una tabla de ganadores de torneos de tenis. En ella figura el nombre del torneo, el año, el nombre del ganador y su nacionalidad. La clave sería Torneo-Año. Pues esta tabla no está en 3FN porque el atributo nacionalidad, que no es de la clave, depende del nombre del ganador (también depende de la clave). Digamos que nacionalidad aporta información sobre el ganador, pero no sobre la clave. Es una dependencia transitiva porque nacionalidad depende de ganador que a su vez depende de Torneo-Año.
FN de Boyce-Codd
Es una Forma Normal ligeramente más estricta que la 3FN. En concreto requiere esté en 3FN y que que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata
Es muy difícil que una tabla que está en 3FN no esté en FNBC, pero podemos «lograrlo» eligiendo mal las claves de nuestras tablas. Por ejemplo, si tenemos una tabla con id_Trabajador, id_Departamento, id_Responsable, donde el id_Responsable es la persona responsable del trabajador. La clave sería, si cada trabajador puede trabajar en varios departamentos y tener distintos responsables (id_Trabajador, id_Departamento, id_Responsable). Pero si resulta que cada responsable lo es de un único departamento, entonces id_Responsable dependería de id_Departamento, lo que convierte a id_Responsable en «determinante» (atributo que depende de otro atributo), pero no es clave candidata.
Este problema se solucionaría creando otra tabla (id_Departamento, id_Responsable) y eliminando id_Responsable de la entidad anterior.
Otras Formas Normales
Hay todavía más formas normales: 4FN, 5FN, Forma Normal de Dominio/Clave (DKFN) y FN6 cuyo aplicación en el mundo real es meramente teórica, ya que en modelos reales no son aplicables y pueden generar mayores dificultades que beneficios.
A manera de conocimiento básico las formas normales 4 y 5 se ocupan del análisis de las dependencias entre atributos multivaluados, la forma normal FNDK (Forma Normal Dominio Clave) trata acerca de las restricciones y los dominios de los atributos y por último la FN6 se refiere a las consideraciones que se deben tratar o tomar en cuenta con las bases de datos temporales.
Videos de Interés:
Conceptos / Ejemplo Normalización (1FN, 2FN ,3FN):
Ejemplo Normalización (1FN, 2FN ,3FN) Excel:
Nota: Si se deseas encontrar un ejemplo hecha por nosotros te invitamos a revisar nuestro portafolio de evidencias
Referencias:
Barbero, M. J. (2015, 7 noviembre). Formas Normales (1FN, 2FN, 3FN y FNBC) | El Blog de 19E37. Recuperado de http://19e37.com/blog/formas-normales-1fn-2fn-3fn/
No hay comentarios:
Publicar un comentario