¿Qué es la Segunda Forma Normal (2FN)?

Cuando se trabaja con bases de datos, es común encontrarse con problemas como datos redundantes y actualizaciones inconsistentes. La segunda forma normal es un paso de normalización de bases de datos que se basa en la primera forma normal (1NF) para crear tablas más limpias y eficientes.

Entender la 2NF es crítico para cualquiera que trabaje en el diseño de bases de datos o en la gestión de datos, y sienta las bases para formas de normalización superiores como la tercera forma normal (3NF). En este artículo, exploraremos cómo funciona la 2NF y cómo transformar tablas para cumplir con los requisitos de la 2NF, con ejemplos prácticos. También hablaremos sobre los beneficios y desventajas de la 2NF, y los casos de uso para los que es más adecuada.

Entendiendo la Segunda Forma Normal

La segunda forma normal es un paso de normalización de bases de datos centrado en eliminar dependencias parciales. Fue introducida por Edgar F. Codd, el pionero de las bases de datos relacionales, como parte de su trabajo sobre normalización.

Antes de que una tabla pueda estar en 2NF, debe cumplir con las reglas de la primera forma normal:

  • Atomicidad: Cada celda debe contener un solo valor (sin grupos repetidos o arreglos).
  • Filas únicas: La tabla debe tener una clave primaria clara.

La 2NF va un paso más allá con una regla adicional: eliminar dependencias parciales.

Una dependencia parcial ocurre cuando un atributo no primo (columna que no es parte de ninguna clave candidata) depende solo de una parte de una clave compuesta en lugar de toda la clave. La regla de 2NF asegura que todos los atributos no primos dependen de toda la clave primaria, no solo de una parte de ella. Dejar dependencias parciales en una tabla significa que datos redundantes pueden infiltrarse en la base de datos, lo que lleva a ineficiencias y posibles inconsistencias durante actualizaciones o eliminaciones.

La teoría por sí sola puede ser un poco seca, así que veamos un ejemplo práctico.

A continuación se muestra una tabla de Inscripción de Cursos de estudiantes de Datacamp.

Student ID Course ID Course Name Instructor Name
1001 201 Fundamentos de SQL Ken Smith
1002 202 Introducción a Python Merlin O’Donnell
1001 202 Introducción a Python Merlin O’Donnell

Aquí, la clave primaria es el compuesto de ID del Estudiante y ID del Curso. Sin embargo, los atributos no primos Nombre del Curso y Costo del Curso dependen solo de ID del Curso, no de la clave completa. Esto viola la 2NF.

Pasos para descomponer tablas para lograr la 2NF

Para asegurarse de que una tabla cumple con las reglas de la 2NF, es necesario:

  1. Identificar Todas las Claves Candidatas: Determinar los conjuntos mínimos de atributos que identifican de forma única las filas en la tabla. Estas son tus claves candidatas.
  2. Determinar Dependencias Funcionales: Identificar todas las dependencias funcionales en la tabla. Específicamente, buscar dependencias donde los atributos no primos (aquellos que no son parte de ninguna clave candidata) dependen solo de una parte de una clave compuesta.
  3. Eliminar Dependencias Parciales: Para cada dependencia parcial:
    • Mueve los atributos dependientes a una nueva tabla junto con la parte de la clave de la que dependen.
    • Asegúrate de que la nueva tabla tenga una clave primaria única.
  4. Repite Hasta Que No Queden Dependencias Parciales: Confirma que cada atributo no primo en todas las tablas dependa completamente de su respectiva clave primaria.

Ejemplos de Segunda Forma Normal en la Práctica

Ahora veamos dos ejemplos.

Ejemplo 1: Tabla de inscripción de cursos

Anteriormente, vimos la siguiente tabla de inscripción de cursos:

Student ID Course ID Course Name Instructor Name
1001 201 Fundamentos de SQL Ken Smith
1002 202 Introducción a Python Merlin O’Donnell
1001 202 Introducción a Python Merlin O’Donnell

Sigamos los pasos que describimos en la sección anterior.

1. Identificar nuestra clave candidata.

En este caso, la clave candidata es una clave compuesta de ID de Estudiante y ID de Curso. Esta combinación única identifica cada fila en la tabla.

2. Determinar nuestras dependencias funcionales

Nombre del Curso y Nombre del Instructor dependen de ID del Curso, no de la clave compuesta completa (ID del Estudiante, ID del Curso). Esta es una dependencia parcial porque estos atributos dependen solo de parte de la clave compuesta.

3. Eliminar dependencias parciales

Necesitamos mover los atributos que dependen solo de parte de la clave (Nombre del Curso y Nombre del Instructor) a una nueva tabla que se base únicamente en ID del Curso.

Después de la descomposición, nuestras nuevas tablas se ven así:

Tabla de inscripción de cursos

Student ID Course ID
1001 201
1002 202
1001 202

Tabla de detalles del curso

Course ID Course Name Instructor Name
201 Fundamentos de SQL Ken Smith
202 Introducción a Python Merlin O’Donnell

Si deseas ponerte manos a la obra y crear tus propias bases de datos, echa un vistazo a nuestro curso de PostgresQL. Si eres un poco más avanzado, podrías probar esta Introducción a la Modelización de Datos en Snowflake, que abarca ideas como la modelización entidad-relación y dimensional.

Ejemplo 2: Tabla de pedidos

Comenzaremos con esta tabla de Pedidos. ¡Intenta seguir los pasos que mencionamos anteriormente y descompone esta tabla por ti mismo!

Order ID Product ID Order Date Product Name Supplier Name
1 201 2024-11-01 Laptop TechSupply
1 202 2024-11-01 Mouse TechSupply
2 201 2024-11-02 Laptop TechSupply
3 203 2024-11-03 Keyboard KeyMasters

1. Identificar nuestra clave candidata

El ID de pedido y ID de producto en combinación identifican de manera única cada fila, haciendo que (ID de pedido, ID de producto) sea una clave candidata compuesta. Ninguna columna única puede identificar filas de manera única porque:

  • ID de orden por sí solo no es único, ya que varios productos pueden formar parte de la misma orden.
  • ID de producto por sí solo no es único, ya que el mismo producto puede aparecer en diferentes órdenes.

Esto significa que (ID de Pedido, ID de Producto) también es nuestra clave primaria.

2. Determinar nuestras dependencias funcionales.

Fecha de Pedidodepende deID de Pedido(no del conjunto completo de claves). Esto es una dependencia parcial.

Nombre del Producto y Nombre del Proveedor dependen de ID del Producto (no del conjunto de claves completo). Estas también son dependencias parciales.

3. Eliminar dependencias parciales

Necesitamos dividir la tabla en tablas más pequeñas, cada una abordando una dependencia lógica.

Primero, crearemos una tabla para la información de pedido, que contiene información específica sobre ID de Pedido.

Tabla de Pedidos

Order ID Order Date
1 2024-11-01
2 2024-11-02
3 2024-11-03

Luego, creamos una tabla que contiene información específica sobre ID de Producto.

Tabla de Pedidos

Product ID Product Name Supplier Name
201 Laptop TechSupply
202 Ratón TechSupply
203 Teclado KeyMasters

La tabla original ahora se reduce solo a la clave compuesta y las relaciones entre pedidos y productos.

Order ID Product ID
1 201
1 202
2 201
3 203

Ahora, nuestra base de datos está en 2NF porque 1) se han eliminado todas las dependencias parciales, y 2) los atributos no primarios dependen completamente de sus respectivas claves primarias.

Cuándo Implementar la Segunda Forma Normal

Entonces, ¿por qué deberías refactorizar tu base de datos a 2NF? ¿Es suficiente por sí sola o deberías dar un paso más y aspirar a 3NF?

Beneficios y limitaciones de la segunda forma normal

La segunda forma normal ofrece varias ventajas, lo que la convierte en un paso útil en el proceso de normalización de bases de datos:

  • Mayor integridad de datos: Al eliminar dependencias parciales, 2NF minimiza las anomalías de inserción, actualización y eliminación, lo que conduce a una base de datos más confiable.
  • Reducción de redundancia: 2NF disminuye la repetición de datos, optimizando el uso del almacenamiento y simplificando el mantenimiento de datos.
  • Estructura de datos mejorada: Sienta las bases para una mayor normalización, como la progresión a la tercera forma normal, al crear un diseño de base de datos más limpio y eficiente.

Pero también tiene algunas limitaciones:

  • Mayor complejidad: Descomponer tablas para cumplir con la 2NF puede hacer que el proceso de diseño sea más complejo, especialmente al tratar con claves compuestas y dependencias.
  • Joins adicionales:Dividir tablas puede requerir más joins en consultas, lo que potencialmente afectaría el rendimiento en sistemas con grandes conjuntos de datos o consultas complejas – más detalles a continuación.
  • Redundancia residual: Si bien la 2NF reduce las dependencias parciales, no aborda las dependencias transitivas, dejando cierta redundancia hasta que se aborde en la 3NF.

Consideraciones de rendimiento con la segunda forma normal

Descomponer tablas para eliminar dependencias parciales puede impactar directamente en el rendimiento de la base de datos. Por un lado, alcanzar la 2NF reduce la redundancia de datos y mejora la consistencia, lo que lleva a menos anomalías durante las operaciones de inserción, actualización o eliminación. Por otro lado, la normalización puede aumentar el número de tablas, lo que significa que se requieren uniones adicionales al recuperar datos relacionados. Esto podría afectar el rendimiento de las consultas en conjuntos de datos grandes.

Para asegurarte de que tu base de datos normalizada siga siendo eficiente, asegúrate de seguir estas mejores prácticas:

  • Indexación: Utiliza índices para acelerar las uniones entre tablas descompuestas.
  • Optimización de consultas:Optimice las consultas para minimizar el costo de joins adicionales.
  • Enfoque híbrido:Combine la normalización con la denormalización en áreas donde el rendimiento es importante, como en las tablas de reportes.
  • Monitoreo regular:Evalue continuamente el rendimiento de su base de datos con herramientas de perfilado para detectar posibles problemas.

¿Es la 2NF solo un paso transicional para lograr la tercera forma normal?

En la mayoría de los casos, los diseñadores de bases de datos buscan alcanzar la tercera forma normal debido a su capacidad para reducir aún más la redundancia y mejorar la integridad general de los datos. Sin embargo, lograr la 3NF a menudo implica trabajo adicional, como crear más tablas y relaciones, lo que puede introducir complejidad y compromisos de rendimiento en la ejecución de consultas.

Existen casos en los que el uso de la segunda forma normal por sí sola puede ser suficiente. Si la simplicidad y la implementación rápida son prioridades, como en proyectos a pequeña escala, prototipos o situaciones donde la redundancia de datos es mínima, la 2NF puede ser suficiente. Por ejemplo, en sistemas donde todos los atributos ya dependen completamente de una clave primaria simple, lograr la 2NF podría cumplir el objetivo principal de reducir la dependencia parcial, sin necesidad de una normalización adicional.

Avanzando más allá de la segunda forma normal: hacia la tercera forma normal

Si deseas normalizar aún más tu base de datos, puedes seguir refactorizando tus tablas para alcanzar la tercera forma normal.

3NF se basa en 2NF al abordar las dependencias transitivas – situaciones en las que atributos que no son clave dependen de otros atributos que tampoco son clave en lugar de la clave primaria. Esta progresión garantiza que cada atributo dependa directamente de la clave primaria y de nada más.

Por ejemplo, en una tabla que registra las inscripciones a cursos:

  • 2NF: Asegura que atributos como el nombre del curso y el nombre del estudiante dependan completamente de sus respectivas claves primarias (por ejemplo, ID de Estudiante y ID de Curso). Esto elimina las dependencias parciales, donde los atributos que no son clave dependen solo de parte de la clave compuesta.
  • 3NF: Garantiza que atributos como los detalles del instructor o la información del departamento se almacenen en tablas separadas, eliminando dependencias transitivas.

3NF es ideal para sistemas más complejos donde la integridad de los datos y la eficiencia son primordiales, especialmente a medida que aumenta el volumen de datos. Consulta nuestro artículo ¿Qué es la tercera forma normal? si deseas aprender más sobre 3NF y su forma más restrictiva, BCNF.

Conclusion

La segunda forma normal es un paso esencial en la normalización de bases de datos, sirviendo de puente entre 1NF y formas superiores como 3NF. Al eliminar dependencias parciales, 2NF reduce la redundancia y mejora la confiabilidad de tus datos. Aunque puede agregar cierta complejidad, los beneficios de mejorar la integridad de los datos y simplificar el mantenimiento lo convierten en una parte crítica del diseño efectivo de bases de datos.

Si estás listo para llevar tus habilidades más lejos, explora nuestro curso de Diseño de Bases de Datos para profundizar tu comprensión de las técnicas de normalización y sus aplicaciones prácticas. También puedes validar tus habilidades en SQL y gestión de bases de datos y demostrar tu experiencia a posibles empleadores con nuestra Certificación de Asociado SQL!

Por último, quiero decir que si eres un tomador de decisiones en un negocio y sabes que tienes trabajo por hacer en la creación de bases de datos más limpias y eficientes, considera solicitar una demostración de DataCamp para Empresas. Podemos ayudar a transformar las capacidades de tu equipo para que puedas crear sistemas de bases de datos escalables que impulsen la eficiencia y la innovación empresarial. Incluso podemos crear rutas de aprendizaje personalizadas y trayectorias a medida.

Source:
https://www.datacamp.com/tutorial/second-normal-form