¿Qué es Normalización?
Las bases de datos relaciones suelen normalizarse para lo siguiente:
Evitar la redundancia de datos,disminuir problemas de actualización de los datos en las tablas y proteger la integridad de los datos.
A cada regla se de denomina "Forma Normal".
 |
| Diagrama de inclusión de todas las formas normales. |
Nota: Las tres primeras formas normales son suficientes para cubrir las necesidades de la mayoría de las bases de datos, estas fueron creadas por científico informático Edgar Frank Codd.
La cuarta y quinta forma normal se ocupa más que todo de la representación de las relaciones muchos a muchos y uno muchos entre los atributos.
En la siguiente tabla se resumen las distintas formas normales, indicando sus creadores y el año en que se propusieron.
La cuarta y quinta forma normal se ocupa más que todo de la representación de las relaciones muchos a muchos y uno muchos entre los atributos.
En la siguiente tabla se resumen las distintas formas normales, indicando sus creadores y el año en que se propusieron.
1.Primera forma normal:
Una tabla esta en esta forma si y solo si:
- Todos sus tributos son atómicos.
-La clave contiene una clave primaria.
-La clave primaria no contiene atributos nulos.
-No debe existir variación en el numero de columnas.
-Los campos no claves 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.
-Una tabla no puede tener múltiples valores en cada columna.
¿Dependencia funcional?
No es más que la dependencia que tiene un atributo de la clave principal, se accedería a él por medio del campo clave.
Un ejemplo de la primera forma normal:
En lugar de hacer campos para proveedores en una sola tabla, se hace otra tabla con el campo proveedor y así se podrán colocar varios registros para los proveedores (Tabla de en medio). Se sustituye la tabla superior de la izquierda por la inferior.
2.Segunda forma normal:
Una tabla en 1FN está en 2FN si y solo sí ninguno de sus atributos no-principales son funcionalmente dependientes en una parte (Subconjunto propio) de una clave primaria (Un atributo no-principal es uno que no pertenece a ninguna clave primaria).
Ejemplo:
Pensando en la dirección de un cliente en un sistema de contabilidad, la dirección se necesita para la tabla Clientes pero para las tablas Pedidos, Factura, y Cuentas a cobrar también, en lugar de almacenar la dirección del cliente como tal en cada tabla, se almacenará en un único lugar , ya sea en la tabla Clientes o en una tabla de Direcciones indenpendiente.
3.Tercera forma normal:
Una tabla está en 3FN si y solo sí las tres condiciones siguientes se cumplen:
-La tabla está en la segunda forma normal.
-Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave primaria.
-Es una relación que no incluye ningún atributo clave.
Ejemplo:
4.Cuarta forma normal:
En esta se asegura de que las dependencias miltivaluadas independientes están correctas y eficientemente representadas en un diseño de Base de datos. La 4FN es el siguiente nivel de normalización después de la forma normal de Boyce-Codd (BCNF).
Una tabla está en 4FN si y solo sí está en tercera forma normal o en BCNF (Cualquiera de ambas) y no posee dependencias miltivaluadas no triviales.
Ejemplo:
5. Quinta forma normal:
Es un nivel de normalización diseñado para reducir la redundancia en las bases de datos relacionales que guardan multi-valores aislando semanticamente relaciones múltiples relacionadas. Una tabla se dice que está en 5FN si y solo sí esta en 4FN y cada dependencia de unión (JOIN) en ella es implicada por las claves candidatas.
Es raro encontrar 5FN después de la 4FN
Por lo general se da en los siguientes casos:
-Hay muchos atributos en las tablas después de la 4FN.
-La tabla contendrá demasiados datos después de la 4FN.
Ejemplo:
Para el caso de una tabla que posee una gran cantidad de atributos:
En este caso tenemos una empresa donde se guardan los datos personales, familiares, profesionales y clínicos de cada empleado en una única tabla llamada Empleados. Si esta tabla está ya en 4FN, se puede partir en las tablas empleados-personal, empleados-familia, empleados-profesional, empleados-clínicos; de este modo, la velocidad de acceso y la gestión de datos por cada departamento de la empresa se simplifica, al no tenerse que crear ningún tipo de restricción sobre determinados atributos que no han de ser vistos por el personal que no los necesite.
Ejemplo:
Pensando en la dirección de un cliente en un sistema de contabilidad, la dirección se necesita para la tabla Clientes pero para las tablas Pedidos, Factura, y Cuentas a cobrar también, en lugar de almacenar la dirección del cliente como tal en cada tabla, se almacenará en un único lugar , ya sea en la tabla Clientes o en una tabla de Direcciones indenpendiente.
3.Tercera forma normal:
Una tabla está en 3FN si y solo sí las tres condiciones siguientes se cumplen:
-La tabla está en la segunda forma normal.
-Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave primaria.
-Es una relación que no incluye ningún atributo clave.
Ejemplo:
(N_Torneo) ---> (#_Año, N_Ganador, D_Nacimiento_Ganador).
Con la 3FN quedaría así:
Esta es una versión ligeramente más fuerte que la 3FN, esta requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata, en una tabla en 3FN, todos los atributos dependen de una clave, de una clave completa y de ninguna otra cosa.
Una tabla esta en FNBC si y solo sí está en 3FN y cada dependencia funcional no trivial tiene una clave candidata como determinante.
Ejemplo:
Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la FNBC. Un ejemplo de tal tabla es (teniendo en cuenta que cada estudiante puede tener más de un tutor):
El propósito de la tabla es mostrar qué tutores están asignados a qué estudiantes. Las claves candidatas de la tabla son:
- {ID Tutor, ID Estudiante}
- {Número de seguro social del tutor, ID Estudiante}
4.Cuarta forma normal:
En esta se asegura de que las dependencias miltivaluadas independientes están correctas y eficientemente representadas en un diseño de Base de datos. La 4FN es el siguiente nivel de normalización después de la forma normal de Boyce-Codd (BCNF).
Una tabla está en 4FN si y solo sí está en tercera forma normal o en BCNF (Cualquiera de ambas) y no posee dependencias miltivaluadas no triviales.
Ejemplo:
(C_Alumno)----->(N_Alumno,N_curso)
La clave anterior muestra a la clave primaria y a sus dos atributos, de los cuales Alumno lleva más de un curso por lo que, por lo que esta tabla no estaría optimizando el proceso.
Se tendría que realizar la separación de las tablas y el usar la dependencia multivalor, considerando que la cantidad de cursos que se puede tener es de 3.
Quedaría de la siguiente manera:
(C_Alumno)---->(N_Alumno)
(C_Alumno)--->(N_Curso1,N_Curso2,N_Curso3)
5. Quinta forma normal:
Es un nivel de normalización diseñado para reducir la redundancia en las bases de datos relacionales que guardan multi-valores aislando semanticamente relaciones múltiples relacionadas. Una tabla se dice que está en 5FN si y solo sí esta en 4FN y cada dependencia de unión (JOIN) en ella es implicada por las claves candidatas.
Es raro encontrar 5FN después de la 4FN
Por lo general se da en los siguientes casos:
-Hay muchos atributos en las tablas después de la 4FN.
-La tabla contendrá demasiados datos después de la 4FN.
Ejemplo:
Para el caso de una tabla que posee una gran cantidad de atributos:
En este caso tenemos una empresa donde se guardan los datos personales, familiares, profesionales y clínicos de cada empleado en una única tabla llamada Empleados. Si esta tabla está ya en 4FN, se puede partir en las tablas empleados-personal, empleados-familia, empleados-profesional, empleados-clínicos; de este modo, la velocidad de acceso y la gestión de datos por cada departamento de la empresa se simplifica, al no tenerse que crear ningún tipo de restricción sobre determinados atributos que no han de ser vistos por el personal que no los necesite.
Nos esforzamos estableciendo una arquitectura base capaz de atender los requisitos no funcionales del sistema. Nos preocupamos por implementar de la mejor forma posible la lógica que define los procesos de negocio. Dedicamos mucho tiempo a diseñar interfaces de usuario amigables, intuitivas y fluidas. ¿Por qué pasar de puntillas por el modelo de datos?.
Un mal diseño del modelo de datos compromete la estabilidad de la aplicación, genera problemas de rendimiento, dificulta la escalabilidad, limita la flexibilidad y aumenta el riesgo de, por una parte, perder datos y, por otra, tener redundancia de los mismos. Vamos, vale la pena intentar hacerlo bien, ¿no?
Un mal diseño del modelo de datos compromete la estabilidad de la aplicación, genera problemas de rendimiento, dificulta la escalabilidad, limita la flexibilidad y aumenta el riesgo de, por una parte, perder datos y, por otra, tener redundancia de los mismos. Vamos, vale la pena intentar hacerlo bien, ¿no?
No hay comentarios:
Publicar un comentario