En esta lección, vamos a abordar la segunda forma normal del modelo relacional, así como sus dos requisitos.
Vamos a trabajar con una tabla que ya cumple con la primera forma normal:
Tabla order_items (artículos del pedido)
| id | first_name (nombre) | last_name (apellido) | address (dirección) | item (artículo) | price (precio) |
|---|---|---|---|---|---|
| 8 | Sergio | Iván | México, Av. Reforma | Plancha | 70,000.00 |
| 2 | Iván | Pérez | Bogotá, Cra. 15 | Cafetera | 2,500,000.00 |
| 7 | Víctor | Sánchez | Lima, Av. Arequipa | Plancha | 500,000.00 |
| 4 | Víctor | Sánchez | Lima, Av. Arequipa | Televisor | 3,300,000.00 |
| 9 | Sergio | Iván | México, Av. Matamoros | Portátil | 10,000,000.00 |
| 6 | Sergio | Iván | México, Av. Matamoros | Portátil | 10,000,000.00 |
Ver en DB Fiddle
Segunda Forma Normal (2NF)
La Segunda Forma Normal tiene dos requisitos principales:
La tabla debe estar en la Primera Forma Normal (1NF). Esto significa que la tabla debe cumplir con las siguientes condiciones:
- Cada celda almacena solo un valor.
- Todos los datos en una columna son del mismo tipo.
- Cada registro es único y se distingue de los demás.
Todos los atributos no clave deben depender completamente de la clave primaria.
- Esto implica que cada atributo no clave debe estar directamente relacionado con la clave primaria, no con una parte de ella.
El primer requisito de la 2NF se ha cumplido si tu tabla ya está en la 1NF. Ahora, el siguiente paso es asegurarnos de que todos los atributos no clave dependan completamente de la clave primaria.
Dependencia de la clave primaria
La dependencia de un atributo de la clave primaria es una situación en la que la clave tiene un valor dependiente de un contexto específico. Supongamos que en la tabla, Serguéi siempre es la misma persona que hace el pedido a diferentes direcciones. En este caso, se puede ver que la dirección está vinculada a un pedido específico. Esto es la dependencia de la clave primaria. Pero el nombre y el apellido del usuario no tiene nada que ver con el pedido. Se relaciona con el usuario en sí.
De acuerdo con la segunda forma, los atributos first_name y last_name deben ser llevados a su propia tabla, que será responsable de los usuarios:
users
| id | first_name | last_name |
|---|---|---|
| 2 | Sergio | Iván |
| 3 | Iván | Pérez |
| 5 | Víctor | Sánchez |
Ver en DB Fiddle
En esta tabla hay solo tres registros porque tenemos tres usuarios únicos. Cada uno de estos usuarios se le asigna una clave primaria.
Ahora tenemos que vincular la tabla order_items con la tabla users. Esto se hace a través de la indicación de las claves primarias en las tablas dependientes:
order_items
| id | user_id | address | item | price |
|---|---|---|---|---|
| 8 | 2 | México, Av. Reforma | Plancha | 70000.00 |
| 2 | 3 | Bogotá, Cra. 15 | Cafetera | 2500000.00 |
| 7 | 5 | Lima, Av. Arequipa | Plancha | 500000.00 |
| 4 | 5 | Lima, Av. Arequipa | Televisor | 3300000.00 |
| 9 | 2 | México, Av. Matamoros | Portátil | 10000000.00 |
| 6 | 2 | México, Av. Matamoros | Portátil | 10000000.00 |
Ver en DB Fiddle
Eliminamos first_name, last_name y agregamos user_id. En este campo se almacenan los identificadores de los usuarios, y el campo en sí se llama clave externa o secundaria.
El mismo proceso debe llevado a cabo con el artículo. Llevar el ítem a su propia tabla:
goods
| id | name |
|---|---|
| 50 | Plancha |
| 30 | Cafetera |
| 20 | Televisor |
| 33 | Portátil |
Ver en DB Fiddle
Ahora vincularemos estos datos con la tabla order_items:
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
Otro ejemplo de clave externa en la tabla del comprador y la ciudad puede mostrarse esquemáticamente así:
Una clave externa no es un enlace directo entre tablas. Cada tabla existe de forma independiente, y la clave externa se utiliza para referenciar un valor que debe coincidir con la clave primaria de otra tabla.
Esto es cómo se ve la sintaxis para definir una clave secundaria:
REFERENCES <nombre de la tabla a la que nos referimos> (<lista de campos en esa tabla a la que nos correspondemos>)
-- Puede haber cualquier cantidad de claves externas: cuantos enlaces, tantas claves.
CREATE TABLE orders (
id bigint PRIMARY KEY,
-- El tipo de clave externa debe ser el mismo,
-- como la primaria en la tabla a la que se refiere el externo.
user_id bigint REFERENCES users (id),
-- demás campos
);
Gracias a la clave externa se garantiza la integridad de los datos. Por ejemplo, es imposible eliminar un registro de la tabla principal si hay enlaces desde claves externas en otra tabla. De esta manera, no puedes accidentalmente enviar la base de datos a un estado inconsistente, donde los datos se refieren a datos que no existen.
Conclusiones
En esta lección, hemos cubierto la segunda forma normal, sus propiedades y su dependencia de la clave externa. Solo queda estudiar la tercera forma y tendrás un entendimiento completo de las formas más comunes en las bases de datos.
Materiales adicionales
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.