Principios de la Segunda Forma Normal (2NF)

Una tabla está en segunda forma normal si:

1. Ya está en la primera forma normal (1NF).
2. Cada columna que no es clave depende de toda la clave primaria, no solo de una parte de la clave.

Si la clave primaria está compuesta por varios campos (clave compuesta), entonces ningún atributo que no sea clave (columna) debe depender solo de una parte de esa clave. O sea, la 2NF elimina las dependencias parciales.

Ejemplo de violación de la 2NF

Supón que tienes una tabla student_courses (Estudiantes y Cursos), que guarda info sobre estudiantes, sus cursos y profesores:

• student_id y course_id juntos forman la clave primaria compuesta.
• Pero fíjate en las columnas course_name y instructor_name. Dependen solo de course_id, no de todo el par (student_id, course_id).

¡Ahí está la dependencia parcial! course_name y instructor_name dependen solo de una parte de la clave compuesta (course_id). Eso rompe los principios de la 2NF.

Llevar la tabla a 2NF

La misión es eliminar la dependencia parcial, dividiendo la tabla en dos. Así quitamos la redundancia y mejoramos la consistencia de los datos.

Separamos la info de los cursos en una tabla aparte courses:

La tabla principal queda así:

Ahora cada columna depende de toda la clave primaria. Hemos separado los datos para que todo esté lógicamente relacionado y eliminado la violación de la 2NF.

La magia de eliminar la redundancia

Fíjate en la tabla antes de normalizar. En la columna instructor_name se repite el nombre "Lin". ¿Cuántas veces podría repetirse eso en una base real con miles de registros? Al separar las tablas, eliminamos la redundancia y reducimos el riesgo de errores, como typos ("Lin" vs "Ling").

Ejemplo de la vida real

Imagina que llevas el control de pedidos de productos. Tienes la siguiente tabla order_items (pedidos y productos), donde order_id y item_id forman la clave primaria:

Como ves, los precios y nombres de los productos se repiten. Eso es señal de que se está violando la 2NF, porque item_name y price dependen solo de item_id.

Para llevar la tabla a 2NF, creamos la tabla items:

Y cambiamos la tabla order_items, dejando solo los identificadores de pedido y producto:

Ahora los datos están limpios como código después de un code review — cero redundancia.

¡Ejercicio práctico: prueba tú mismo!

Supón que tienes una tabla employee_projects, que contiene info sobre empleados, sus proyectos y los managers de los proyectos:

Intenta:

1. Encontrar las dependencias que rompen la 2NF.
2. Dividir la tabla en dos, eliminando la violación.

¿Por qué es importante cumplir la 2NF?

¿Por qué molestarse en cumplir la segunda forma normal (2NF)? Fácil: para que los datos no se dupliquen y no haya líos. Cuando eliminas dependencias parciales, las tablas quedan más limpias — sin info repetida, como el mismo nombre de profe en cada fila. Eso ahorra espacio y evita inconsistencias: cambias el nombre en un sitio y todo está actualizado.

Además, hacer queries a una base así es más fácil: cuando la estructura es lógica y los datos no están repartidos por mil filas, filtrar y agrupar va más rápido y seguro. Sí, hay que pagar el precio de queries SQL un poco más complejas con JOINs, porque hay más tablas. Pero mejor un JOIN que cien filas con los mismos apellidos. En la mayoría de los casos, la normalización merece la pena.

Integración con proyectos reales

Saber de 2NF te sirve para:

• Diseñar bases de datos: evitando el caos en las tablas.
• En entrevistas: muchas veces te piden explicar o llevar tablas a forma normal.
• En el curro real: cuando te toque optimizar una base existente, partiendo tablas "monolíticas" en otras normalizadas.

La segunda forma normal (2NF) ayuda a eliminar dependencias parciales en una tabla donde la clave primaria es compuesta. Separamos las tablas en bloques lógicos para que cada columna dependa solo de toda la clave, no de una parte. Así mejora la calidad de la base, se elimina la redundancia y se gana flexibilidad. ¿Listo para la tercera forma normal? ¡Vamos allá!