Revista Tecnología

Bases de datos: Segunda forma normal

Publicado el 23 octubre 2014 por Alexander171294 @std_io
En ésta entrada hablaremos sobre la segunda forma normal en el proceso de normalización de bases de datos. Puedes leer la Primera forma normal, si no la haz leído te recomiendo hacerlo.
Bases de datos: Segunda forma normalContinuamos entonces con el hilo de bases de datos haciendo referencia al proceso de normalización, algo que es casi fundamental a la hora de diseñar una base de datos es tener en cuenta el tema de normalización.
La segunda forma normal hace referencia a la dependencia funcional absoluta, sobre todo cuando haya más de una clave primaria, habíamos visto que para estar en 1FN era necesario que todos los campos sean directamente dependientes de la clave primaria.
Primero, una tabla está en 2FN si y solo si la misma se encuentra en 1FN y cumple con el siguiente requisito:
los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben depender únicamente de la clave principal).
Esto quiere decir, que si tienes dos claves primarias, es necesario que cada campo de la tabla que no sea clave primaria dependa de todas las claves primarias, si un campo solo depende de una o algunas (pero no todas) las claves primarias ese campo es erróneo.
Imaginemos una tabla con los siguientes campos:
id_proyecto dni_empleado horas_trabajadas nombre_empleado
(donde dni_empleado e id_proyecto son claves primarias)
como podrán apreciar, las horas trabajadas en el proyecto son dependientes del id del proyecto y del dni del empleado, no podemos saber las horas trabajadas únicamente teniendo el id_proyecto o el dni_empleado, ya que no podremos saber con uno solo de esos cuantas horas trabajó en ese proyecto, por lo que ese campo es correcto, depende de todas las claves primarias de la tabla y no tiene dependencias parciales, pero veamos el campo nombre_empleado, el mismo es erróneo, ya que depende del dni_empleado pero no tiene ninguna dependencia con id_proyecto (no tiene nada que ver el nombre de un empleado con el id de un proyecto) de modo que ese campo no debe estar en esa tabla para que esa tabla esté en 2FN, ya que tiene dependencias parciales.
Un saludo para todos los lectores y espero les haya gustado la explicación breve y simple de 2FN, sigan pendiente del blog para ver las siguientes formas normales.

Volver a la Portada de Logo Paperblog