- Tercera forma normal (3NF)
- Dependencia de las columnas de la clave primaria, pero no entre sí
- Conclusiones
En esta lección, analizaremos la tercera forma normal (3NF) del modelo relacional y sus requisitos.
Trabajaremos con la estructura actual:
users
| id | first_name | last_name |
|---|---|---|
| 2 | Sergio | Iván |
| 3 | Iván | Pérez |
| 5 | Víctor | Sánchez |
goods
| id | name |
|---|---|
| 50 | Plancha |
| 30 | Cafetera |
| 20 | Televisor |
| 33 | Portátil |
order_items
| id | user_id | address | good_id | price |
|---|---|---|---|---|
| 8 | 2 | México, Av. Reforma | 50 | 70000.00 |
| 2 | 3 | Bogotá, Cra. 15 | 30 | 2500000.00 |
| 7 | 5 | Lima, Av. Arequipa | 50 | 500000.00 |
| 4 | 5 | Lima, Av. Arequipa | 20 | 3300000.00 |
| 9 | 2 | México, Av. Matamoros | 33 | 10000000.00 |
| 6 | 2 | México, Av. Matamoros | 33 | 10000000.00 |
Ver en DB Fiddle
Tercera forma normal (3NF)
Para que una tabla esté en la tercera forma normal (3NF), debe cumplir con dos condiciones:
- Estar en la segunda forma normal (2NF).
- Todas las columnas no clave deben depender únicamente de la clave primaria, y no deben depender entre sí.
La tabla ya está en segunda forma normal (2NF), porque:
- Cumple con los requisitos de la primera forma normal (1NF).
- Todos los atributos que no son clave dependen completamente de la clave primaria.
Ahora, vamos a enfocarnos en el segundo requisito: asegurarnos de que las columnas no clave dependan únicamente de la clave primaria y no unas de otras.
Dependencia de las columnas de la clave primaria, pero no entre sí
El costo del pedido depende del precio del producto. A su vez, el precio del producto depende del propio producto, es decir, del good_id. Para llevar la tabla a la tercera forma, debemos llevar el precio al producto:
goods
| id | name | price |
|---|---|---|
| 50 | Plancha | 70000.00 |
| 30 | Cafetera | 2500000.00 |
| 20 | Televisor | 3300000.00 |
| 33 | Portátil | 10000000.00 |
Nuestra tabla adquiere este aspecto:
order_items
| id | user_id | address | good_id |
|---|---|---|---|
| 8 | 2 | México, Av. Reforma | 50 |
| 2 | 3 | Bogotá, Cra. 15 | 30 |
| 7 | 5 | Lima, Av. Arequipa | 50 |
| 4 | 5 | Lima, Av. Arequipa | 20 |
| 9 | 2 | México, Av. Matamoros | 33 |
| 6 | 2 | México, Av. Matamoros | 33 |
Ver en DB Fiddle
Por un lado, hemos realizado la mayor parte de la normalización necesaria, por otro, la nueva estructura tiene un gran inconveniente. El precio del producto es algo que puede cambiar, pero el costo de la compra que hicimos en el pasado, no. Cuando el precio de un producto cambia, el costo de todas las compras realizadas que incluían ese producto también cambia. Desde el punto de vista de la contabilidad y el historial de compras, esto es inaceptable.
Esto significa que el precio del producto debe ser copiado en la tabla order_items. Pero también se necesita en la tabla goods. Primero que nada, para exhibir en el sitio web.
La dirección también depende del usuario, pero de una manera más compleja. Un usuario puede tener varias direcciones. Teniendo en cuenta todo lo que hemos hablado de las formas normales, no podemos transferir las direcciones a la tabla de usuarios. No podemos almacenar varios valores en una columna y no podemos duplicar registros, ya que se violaría la unicidad de la clave primaria.
La solución correcta es tener una tabla propia para las direcciones. En ella, la dirección estará asociada con el usuario y en lugar del campo address en la tabla de pedidos, aparecerá el campo user_address_id.
Conclusiones
En esta lección, hemos estudiado la tercera forma normal. Ahora tus conocimientos sobre las formas en el modelo relacional son suficientes para trabajar con las tareas más comunes en las bases de datos.
Para acceder completo a curso necesitas un plan básico
El plan básico te dará acceso completo a todos los cursos, ejercicios y lecciones de Códica, proyectos y acceso de por vida a la teoría de las lecciones completadas. La suscripción se puede cancelar en cualquier momento.
