Das Schema von «Kotomarket»
What you'll learn
- unter den fünf Tabellen von «Kotomarket» die richtige finden:
users,products,orders,order_items,events - ein ER-Diagramm lesen und die Kardinalität einer Beziehung (1:N, N:M, 1:1) daran erkennen, wo der Fremdschlüssel liegt
- eine Viele-zu-viele-Beziehung über eine Zwischentabelle mit zwei FKs auflösen — wie
order_itemsmitorder_id+product_id - erklären, warum man den Inhalt einer Bestellung nicht einfach als id-Zeichenkette direkt in
ordersspeichern sollte
Heute legt QUERY das ganze Verzeichnis auf einmal auf den Haupttisch. Fünf leuchtende Ebenen hängen in der Luft und drehen sich langsam — eine Karte der erhaltenen Welt. Daneben flackert das Konservierungsjournal des Schnappschusses, eine Zeile ist unterstrichen: „Übergebe fünf Tabellen und die Spur einer sechsten. — K.“ Du zählst die Ebenen. Genau fünf. Wo ist die Spur?
QUERY: Lass dich von Spuren nicht ablenken. Lerne erst diese fünf so gut, dass du dich mit geschlossenen Augen zurechtfindest — den Rest zeigt dir das Archiv selbst, wenn du bereit bist.
Die fünf Tabellen von «Kotomarket»
Von hier an arbeiten wir mit dieser Datenbank: dem Schnappschuss eines Onlineshops aus dem Jahr 2024. Betrachte sie wie eine Karte des Ladens: wer hereinkam, was im Schaufenster lag, was gekauft wurde und welche Handlungen vor dem Kauf stattfanden.
| Tabelle | Was sie speichert |
|---|---|
users | Käufer: id, Name, Stadt und Anmeldedatum |
products | Waren des Schaufensters: id, Name, Kategorie, Preis und Bestand |
orders | Bestellungen: id, user_id, Datum, Status und Summe |
order_items | Inhalt der Bestellungen: welches Produkt, wie viele Stück und zu welchem Preis |
events | Verhaltensereignisse: Ansichten, Hinzufügen in den Warenkorb und Käufe |
Die Verbindungen liest man so: ein user → viele orders; ein order → viele order_items; ein product → viele order_items. Wenn du dich verläufst, öffne das Schema rechts — es ist wie der Grundriss des Verkaufsraums.
Wirf einen Blick in die Bestelltabelle: In jeder Zeile steht user_id — ein Verweis auf den Käufer. So verbindet sich eine Tabelle mit einer anderen, und die Karte besteht nicht mehr aus fünf einzelnen Inseln.
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 |
Wie man ein ER-Diagramm liest
Die Karte, die QUERY entfaltet hat, nennt man in der Branche ein ER-Diagramm (entity–relationship): Rechtecke sind Tabellen, die Linien dazwischen sind Beziehungen über Fremdschlüssel. Entscheidend an einer Linie ist die Kardinalität: Wie viele Zeilen auf der einen Seite passen zu wie vielen Zeilen auf der anderen?
- 1:N, eins-zu-vielen — die häufigste Beziehung. Ein Käufer — viele Bestellungen. Der Fremdschlüssel liegt immer auf der Seite der „vielen“:
user_idwird inordersgespeichert, nicht umgekehrt. Das ist die Leseregel: Hast du den FK gefunden, hast du die N-Seite gefunden. - N:M, viele-zu-vielen — in einer Bestellung stecken viele Produkte, und ein Produkt kann in vielen Bestellungen vorkommen. Direkt lässt sich eine solche Beziehung in einer relationalen Datenbank nicht ausdrücken: Für einen einzelnen Fremdschlüssel gibt es keinen passenden Platz. Man löst sie über eine Zwischentabelle auf — bei uns
order_items. Jede Zeile trägt ein Verweispaarorder_id+product_idund macht aus einer N:M-Beziehung zwei 1:N-Beziehungen. Bonus: Die Beziehung selbst bekommt Attribute — die Stückzahl und den Preis zum Zeitpunkt des Kaufs. - 1:1, eins-zu-eins — kommt seltener vor. Zum Beispiel lagert man schwere oder private Felder in eine separate Tabelle mit demselben Schlüssel aus.
-- Rozplątanie N:M w działaniu: pary „zamówienie — towar” z order_items
SELECT order_id, product_id, quantity
FROM order_items
LIMIT 6;
Stolperfalle: den Inhalt einer Bestellung direkt in orders speichern — als Zeichenkette '7,12,3' oder als Array von Bezeichnern. Solche Daten lassen sich nicht mit einem Fremdschlüssel schützen, nicht sauber zählen und nicht ohne Verrenkungen mit dem Schaufenster verknüpfen. Wenn du eine Viele-zu-viele-Beziehung siehst, lege eine Zwischentabelle mit zwei Fremdschlüsseln an, wie order_items.
Interview question
Frage aus dem Vorstellungsgespräch: Wie bildet man in einer relationalen Datenbank eine Viele-zu-viele-Beziehung ab?
Starke Antwort: über eine Zwischentabelle mit zwei Fremdschlüsseln auf die Tabellen, die verbunden werden — wie order_items mit order_id und product_id. Sie macht aus N:M zwei 1:N-Beziehungen. Gleichzeitig kann man darin Attribute der Beziehung selbst speichern, etwa Stückzahl und Preis zum Zeitpunkt des Kaufs. Der Primärschlüssel einer solchen Tabelle ist entweder aus den zwei FKs zusammengesetzt oder eine Surrogat-id.