Lo schema di Kotomarket
What you'll learn
- a trovare la tabella giusta tra le cinque di Kotomarket:
users,products,orders,order_items,events - a leggere un diagramma ER: a determinare la cardinalità di un collegamento (1:N, N:M, 1:1) in base a dove si trova la chiave esterna
- a realizzare un collegamento «molti a molti» tramite una tabella intermedia con due FK, come
order_itemsconorder_id+product_id - a spiegare perché il contenuto di un ordine non va conservato come stringa di id direttamente in
orders
Oggi QUERY porta sul tavolo principale l'intero inventario in una volta sola. Cinque piani luminosi restano sospesi in aria e ruotano lentamente: la mappa del mondo sopravvissuto. Accanto tremola il registro di conservazione allegato allo , con una riga sottolineata: «Consegno cinque tabelle e la traccia di una sesta. — K.» Conti i piani. Esattamente cinque. Dov'è la traccia?
QUERY: Non distrarti con le tracce. Prima impara queste cinque tanto bene da trovare la strada a occhi chiusi. Il resto l'archivio te lo mostrerà da sé, quando ti riterrà pronto.
Le cinque tabelle di Kotomarket
D'ora in poi lavoreremo con questo database: uno snapshot di un negozio online del 2024. Tienilo come la mappa del negozio: chi è entrato, che cosa c'è in vetrina, che cosa è stato comprato e quali azioni sono avvenute prima dell'acquisto.
| Tabella | Cosa conserva |
|---|---|
users | i clienti: id, nome, città e data di registrazione |
products | gli articoli in vetrina: id, nome, categoria, prezzo e giacenza |
orders | gli ordini: id, user_id, data, stato e importo |
order_items | il contenuto degli ordini: quale prodotto, in quante unità e a quale prezzo |
events | gli eventi comportamentali: visualizzazioni, aggiunte al carrello e acquisti |
I collegamenti si leggono così: un user → molti orders; un order → molti order_items; un product → molti order_items. Se ti perdi, apri lo schema sulla destra: è come la pianta del reparto vendite.
Diamo un'occhiata alla tabella degli ordini: in ogni riga c'è un user_id, cioè un riferimento al cliente. Così una tabella si collega a un'altra, e la mappa smette di essere composta da cinque isole separate.
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 |
Come leggere un diagramma ER
La mappa che QUERY ha dispiegato si chiama, nell'industria, diagramma ER (entity–relationship): i rettangoli sono le tabelle, le linee tra loro sono i collegamenti tramite chiavi esterne. La cosa più importante su una linea è la cardinalità: quante righe da un lato corrispondono a quante righe dall'altro.
- 1:N, uno-a-molti — il collegamento più frequente. Un cliente, molti ordini. La chiave esterna sta sempre sul lato dei «molti»:
user_idè conservato inorders, non il contrario. Questa è la regola di lettura: trovata la FK, trovato il lato N. - N:M, molti-a-molti — un ordine contiene molti prodotti, e un prodotto compare in molti ordini. Un collegamento del genere in un database relazionale non si può esprimere direttamente: non c'è un posto naturale dove mettere la chiave esterna. Lo si realizza tramite una tabella intermedia: da noi è
order_items. Ogni sua riga porta una coppia di riferimentiorder_id+product_ide trasforma un unico collegamento N:M in due collegamenti 1:N. In più, il collegamento stesso ottiene attributi propri: il numero di unità e il prezzo al momento dell'acquisto. - 1:1, uno-a-uno — si incontra più di rado: per esempio, campi pesanti o riservati vengono spostati in una tabella separata con la stessa chiave.
-- Lo sviluppo N:M in azione: le coppie «ordine — prodotto» da order_items
SELECT order_id, product_id, quantity
FROM order_items
LIMIT 6;
Trappola: conservare il contenuto di un ordine direttamente in orders, per esempio come stringa '7,12,3' o array di identificatori. Dati del genere non si possono proteggere con una chiave esterna, contare correttamente o unire alla vetrina senza acrobazie. Quando vedi un collegamento «molti a molti», crea una tabella intermedia con due chiavi esterne, come order_items.
Interview question
Domanda da colloquio: come si realizza in un database relazionale un collegamento «molti a molti»?
Risposta efficace: tramite una tabella intermedia con due chiavi esterne verso le tabelle da collegare, come order_items con order_id e product_id: trasforma N:M in due collegamenti 1:N. Nella stessa tabella si conservano anche gli attributi del collegamento, per esempio la quantità e il prezzo al momento dell'acquisto. La chiave primaria di una tabella simile può essere composta dalle due FK oppure essere un id surrogato.