Skip to main content

Cómo convertir una base de datos a una tercera forma normal (3NF)

Base de datos #13 | Normalización (1FN, 2FN y 3FN) (Abril 2025)

Base de datos #13 | Normalización (1FN, 2FN y 3FN) (Abril 2025)
Anonim

La tercera forma normal (3NF) es un principio de base de datos que respalda la integridad de los datos al basarse en los principios de normalización de la base de datos proporcionados por la Primera forma normal (1NF) y la Segunda forma normal (2NF).

Requisitos de la tercera forma normal

Hay dos requisitos básicos para que una base de datos esté en la tercera forma normal:

  • La base de datos ya debe cumplir con los requisitos de 1NF y 2NF.
  • Todas las columnas de la base de datos deben depender de la clave principal, lo que significa que el valor de cualquier columna puede derivarse únicamente de la clave principal.

Sobre la dependencia de la clave primaria

Exploremos más a fondo lo que queremos decir con el hecho de que todas las columnas deben depender de la clave principal.

Si el valor de una columna puede derivarse tanto de la clave principal como de otra columna en la tabla, viola 3NF. Considere una tabla de empleados con estas columnas:

  • ID de empleado
  • Nombre de pila
  • Apellido

¿Tanto el Apellido como el Nombre dependen solo del valor de EmployeeID? Bueno, ¿podría el apellido depender del nombre? No, porque nada inherente en Apellido sugiere el valor de Nombre. ¿Podría el primer nombre depender del apellido? No otra vez, porque lo mismo es cierto: cualquiera que sea un Apellido, no puede proporcionar una pista sobre el valor de Nombre. Por lo tanto, esta tabla es compatible con 3NF.

Pero considere esta tabla de vehículos:

  • ID del vehículo
  • Fabricante
  • Modelo

El fabricante y el modelo podrían derivar de VehicleID, pero el modelo también podría derivar del fabricante porque un modelo de vehículo está fabricado solo por un fabricante en particular. Este diseño de tabla no es compatible con 3NF y, por lo tanto, podría dar como resultado anomalías en los datos. Por ejemplo, puede actualizar el fabricante sin actualizar el modelo, introduciendo inexactitudes.

Para que sea compatible, deberíamos mover la columna dependiente adicional a otra tabla y hacer referencia a ella con una clave externa. Esto daría lugar a dos tablas:

Tabla de vehículos

En la tabla a continuación, el ModelID es una clave foránea para el Modelos mesa:

  • ID del vehículo
  • Fabricante
  • ID de modelo

Tabla de modelos

Esta nueva tabla mapea modelos a fabricantes. Si desea actualizar cualquier información del vehículo específica para un modelo, lo haría en esta tabla, en lugar de en la tabla Vehículos.

  • ID de modelo
  • Fabricante
  • Modelo

Campos derivados en el modelo 3NF

Una tabla puede contener un campo derivado, uno que se calcula basándose en otras columnas de la tabla. Por ejemplo, considere esta tabla de órdenes de widgets:

  • Número de orden
  • Número de cliente
  • Precio unitario
  • Cantidad
  • Total

El total rompe con el cumplimiento de 3NF porque se puede derivar multiplicando el precio unitario por la cantidad, en lugar de depender totalmente de la clave principal. Debemos eliminarlo de la tabla para cumplir con la tercera forma normal.

De hecho, como se deriva, es mejor no almacenarlo en la base de datos.

Simplemente podemos calcularlo "sobre la marcha" al realizar consultas de base de datos. Por ejemplo, podríamos haber utilizado esta consulta anteriormente para recuperar números de orden y totales:

SELECCIONE Número de pedido, Total de órdenes de widgets

Ahora podemos utilizar la siguiente consulta:

SELECCIONE OrderNumber, UnitPrice * Cantidad COMO total DE WidgetOrders

Para lograr los mismos resultados sin violar las reglas de normalización.