El esquema de «Kotomarket»
Qué aprenderás
- identificar la tabla que necesitas entre las cinco de «Kotomarket»:
users,products,orders,order_items,events - leer un diagrama ER: determinar la cardinalidad de un vínculo (1:N, N:M, 1:1) según dónde está la clave foránea
- descomponer un vínculo «muchos a muchos» mediante una tabla intermedia con dos FK, como
order_itemsconorder_id+product_id - explicar por qué el contenido de un pedido no se puede guardar directamente en
orderscomo una cadena de identificadores
Hoy QUERY deja sobre la mesa principal todo el índice de golpe. Cinco planos luminosos quedan suspendidos en el aire y giran despacio: el mapa del mundo que logró sobrevivir. A su lado parpadea el diario de conservación adjunto a la instantánea, y una de sus líneas está subrayada: «Entrego cinco tablas y el rastro de una sexta. — K.» Cuentas los planos. Exactamente cinco. ¿Dónde está el rastro?
QUERY: No te distraigas con las pistas. Primero aprende estas cinco lo bastante bien como para orientarte de memoria: lo demás te lo mostrará el archivo cuando te considere preparado.
Las cinco tablas de «Kotomarket»
A partir de aquí vamos a trabajar con esta base: una instantánea de una tienda online de 2024. Tómala como el mapa de la tienda: quién entró, qué había en el escaparate, qué compraron y qué hicieron antes de comprar.
| Tabla | Qué guarda |
|---|---|
users | clientes: id, nombre, ciudad y fecha de registro |
products | artículos del escaparate: id, nombre, categoría, precio y stock |
orders | pedidos: id, user_id, fecha, estado e importe |
order_items | contenido de los pedidos: qué producto, cuántas unidades y a qué precio |
events | eventos de comportamiento: vistas, añadidos al carrito y compras |
Los vínculos se leen así: un user → muchos orders; un order → muchos order_items; un product → muchos order_items. Si te pierdes, abre el esquema de la derecha: es como el plano de la sala de ventas.
Asomémonos a la tabla de pedidos: en cada fila hay un user_id, una referencia al cliente. Así es como una tabla se enlaza con otra, y el mapa deja de ser cinco islas separadas.
Kotomarket’s five tables
From here on we’ll be working with this database — a of an online shop from 2024. Hold it like a map of the store: who walked in, what’s on the shelves, what they bought, and what they did before buying.
| Table | What it holds |
|---|---|
users | buyers: id, name, city, and signup date |
products | storefront items: id, name, category, price, and stock |
orders | orders: id, user_id, date, status, and total |
order_items | order contents: which product, how many, and at what price |
events | behavioral events: views, add-to-carts, and purchases |
The links read like this: one user → many orders; one order → many order_items; one product → many order_items. If you get lost, open the schema on the right — it’s like the floor plan of the shop.
Let’s peek into the orders table: every row has a user_id — a reference to a buyer. That’s how one table links to another, and the map stops being five separate islands.
user_id:| id | user_id | status | total_amount |
|---|---|---|---|
| 1 | 18 | paid | 5980.00 |
| 2 | 10 | paid | 19750.00 |
| 3 | 26 | cancelled | 9560.00 |
| 4 | 26 | paid | 15530.00 |
| 5 | 8 | paid | 26710.00 |
| 6 | 37 | paid | 42110.00 |
Cómo leer un diagrama ER
El mapa que ha desplegado QUERY se llama en el sector diagrama ER (entity–relationship): los rectángulos son tablas, las líneas entre ellos son vínculos por claves foráneas. Lo más importante de una línea es su cardinalidad: cuántas filas de un lado pueden corresponder a cuántas del otro.
- 1:N, uno a muchos — el vínculo más frecuente. Un cliente, muchos pedidos. La clave foránea siempre está del lado de los «muchos»:
user_idse guarda enorders, y no al revés. Regla práctica: si has encontrado la FK, has encontrado el lado N. - N:M, muchos a muchos — un pedido tiene muchos productos, y un producto aparece en muchos pedidos. Ese vínculo no se puede representar directamente en una base relacional: no hay una columna donde poner la clave foránea. Se resuelve con una tabla intermedia; en nuestro caso,
order_items. Cada una de sus filas lleva un par de referencias,order_id+product_id, y convierte un único vínculo N:M en dos vínculos 1:N. Además, el propio vínculo gana atributos: la cantidad de unidades y el precio en el momento de la compra. - 1:1, uno a uno — aparece menos: por ejemplo, cuando los campos pesados o privados se sacan a una tabla aparte con la misma clave.
-- La resolución N:M en acción: pares «pedido — producto» de order_items
SELECT order_id, product_id, quantity
FROM order_items
LIMIT 6;
Trampa habitual: guardar el contenido de un pedido directamente en orders, como una cadena '7,12,3' o un array de identificadores. Esos datos no se pueden proteger con una clave foránea, ni contar bien, ni unir con el escaparate sin acrobacias. Si ves un vínculo «muchos a muchos», crea una tabla intermedia con dos claves foráneas, como order_items.
Interview question
Pregunta de entrevista: ¿cómo se implementa un vínculo «muchos a muchos» en una base relacional?
Buena respuesta: mediante una tabla intermedia con dos claves foráneas hacia las tablas que se vinculan, como order_items con order_id y product_id: convierte un N:M en dos vínculos 1:N. Además, en ella se guardan los atributos del propio vínculo: la cantidad y el precio en el momento de la compra. La clave primaria de esa tabla puede ser compuesta por las dos FK o bien un id subrogado.