Schema „Kotomarket”
What you'll learn
- să găsești tabelul potrivit printre cele cinci din „Kotomarket”:
users,products,orders,order_items,events - să citești o diagramă ER: să determini cardinalitatea legăturii (1:N, N:M, 1:1) după locul în care se află cheia externă
- să descompui o legătură „mulți la mulți” printr-un tabel intermediar cu două FK — precum
order_itemscuorder_id+product_id - să explici de ce conținutul unei comenzi nu trebuie păstrat ca un șir de id-uri direct în
orders
Astăzi, QUERY aduce pe masa principală tot inventarul deodată. Cinci planuri luminoase plutesc în aer și se rotesc încet — harta lumii care a supraviețuit. Alături pâlpâie jurnalul de conservare atașat copiei, iar o linie din el este subliniată: „Predau cinci tabele și urma celui de-al șaselea. — K.” Numeri planurile. Exact cinci. Unde e urma?
QUERY: Nu te lăsa distras de urme. Învață mai întâi aceste cinci tabele atât de bine încât să-ți găsești drumul cu ochii închiși. Restul ți-l va arăta arhiva singură, când te va socoti pregătit.
Cele cinci tabele „Kotomarket”
Mai departe vom lucra cu această bază — o copie de arhivă a unui magazin online din 2024. Gândește-te la ea ca la harta magazinului: cine a intrat, ce era pe raft, ce s-a cumpărat și ce acțiuni au avut loc înainte de cumpărare.
| Tabel | Ce păstrează |
|---|---|
users | cumpărătorii: id, nume, oraș și data înregistrării |
products | produsele de pe raft: id, denumire, categorie, preț și stoc |
orders | comenzile: id, user_id, dată, status și sumă |
order_items | conținutul comenzilor: ce produs, câte bucăți și la ce preț |
events | evenimentele comportamentale: vizualizări, adăugări în coș și cumpărături |
Legăturile se citesc așa: un user → multe orders; un order → multe order_items; un product → multe order_items. Dacă te rătăcești, deschide schema din dreapta: e ca planul sălii de vânzare.
Să aruncăm o privire în tabelul comenzilor: în fiecare rând există user_id — o referință către cumpărător. Așa se leagă un tabel de altul, iar harta încetează să mai fie cinci insule 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 |
Cum se citește o diagramă ER
Harta desfășurată de QUERY se numește în industrie diagramă ER (entity–relationship): dreptunghiurile sunt tabele, liniile dintre ele sunt legături prin chei externe. Cel mai important lucru de pe o linie este cardinalitatea: câte rânduri dintr-o parte corespund câtor rânduri din cealaltă.
- 1:N, unu-la-mulți — cea mai frecventă legătură. Un cumpărător — multe comenzi. Cheia externă stă mereu pe partea „celor mulți”:
user_idse păstrează înorders, nu invers. Regula de citire e simplă: ai găsit FK — ai găsit partea N. - N:M, mulți-la-mulți — o comandă are multe produse, iar un produs apare în multe comenzi. O astfel de legătură nu poate fi exprimată direct într-o bază relațională: nu ai unde să pui cheia externă. Ea se descompune printr-un tabel intermediar — la noi, acesta este
order_items. Fiecare rând al lui poartă o pereche de referințeorder_id+product_idși transformă o singură legătură N:M în două legături 1:N. În plus, relația însăși primește atribute — numărul de bucăți și prețul din momentul cumpărării. - 1:1, unu-la-unu — se întâlnește mai rar: de exemplu, câmpurile voluminoase sau sensibile se mută într-un tabel separat, cu aceeași cheie.
-- Desfacerea N:M în acțiune: perechile „comandă — produs” din order_items
SELECT order_id, product_id, quantity
FROM order_items
LIMIT 6;
Capcană: să păstrezi conținutul comenzii direct în orders — ca un șir '7,12,3' sau un tablou de identificatori. Astfel de date nu pot fi protejate de o cheie externă, numărate corect sau îmbinate cu raftul fără acrobații. Când vezi o legătură „mulți la mulți”, creează un tabel intermediar cu două chei externe, precum order_items.
Interview question
Întrebare de interviu: cum se implementează într-o bază relațională o legătură „mulți la mulți”?
Răspuns puternic: printr-un tabel intermediar cu două chei externe către tabelele legate — precum order_items cu order_id și product_id: el transformă N:M în două legături 1:N. În același tabel se păstrează și atributele relației — cantitatea, prețul din momentul cumpărării. Cheia primară a unui astfel de tabel este fie compusă din cele două FK, fie un id surogat.