Las formas normales son conjuntos de criterios que utilizamos para «normalizar» (es decir, mejorar la estructura) de las bases de datos.
Vamos a repasar las tres primeras formas normales.
1FN – Primera Forma Normal
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 autoincremental. 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 RFC o vehículos sin matrícula).
No debe existir diferencia 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.
2FN – Segunda Forma Normal
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.
3FN – Tercera Forma Normal
Una tabla está en 3FN si además de estar en 2FN no existe ninguna dependencia transitiva entre los atributos que no son clave.
Vamos a explicarlo. Como dijo Bill Kent
, «todo atributo no clave debe proporcionar información sobre la clave, sobre toda la clave y nada más que la clave… con la ayuda de Codd».
Bueno, en serio, 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 FN 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. O dicho de otra forma: una tabla está en FNBC si está en 3FN y los únicos determinantes (atributo que depende de otro atributo) son claves candidatas.
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 idTrabajador, idDepartamento, idResponsable, donde el idResponsable es la persona responsable del trabajador. La clave sería, si cada trabajador puede trabajar en varios departamentos y tener distintos responsables (idTrabajador, idDepartamento, idResponsable). Pero si resulta que cada responsable lo es de un único departamento, entonces idResponsable dependería de idDepartamento, lo que convierte a idResponsable en «determinante» (atributo que depende de otro atributo), pero no es clave candidata.
Este problema se solucionaría creando otra tabla (idDepartamento, idResponsable) y eliminando idResponsable de la entidad anterior.
Otras Formas Normales
Hay todavía más formas normales: 4FN, 5FN y Forma Normal de Dominio/Clave (DKFN).
Comentarios
Publicar un comentario