Zwei Adressen für eine Kundin
Nordwind Rad hat anfangs alles in eine einzige Tabelle geschrieben: Kundin, Adresse, Produkt, Preis. Das ging schnell.
Jetzt meldet der Support: Anna Becker bekommt Rechnungen an zwei verschiedene E-Mail-Adressen. Niemand weiß, welche stimmt. Der Fehler liegt nicht im Programm, sondern im Aufbau der Tabelle.
Am Ende dieser Lektion
Notiz
Ich kann Daten so auf Tabellen verteilen, dass jede Angabe nur einmal gespeichert ist.
Schlüsselwörter
| Begriff | Was er bedeutet |
|---|---|
| Duplikat | dieselbe Angabe, mehrfach gespeichert |
| Widerspruch | zwei Kopien derselben Angabe, die nicht übereinstimmen |
| Entität | eine Sache, über die Daten gespeichert werden, zum Beispiel ein Kunde |
| Normalisierung | Daten so aufteilen, dass jede Angabe einmal vorkommt |
| NoSQL | Datenbanken, die oft Dokumente statt verbundener Tabellen speichern |
Die Zellen, die Lernende ausfüllen, bleiben in dieser Vorschau leer.
Eine Sammeltabelle wiederholt Angaben
Zuerst stand alles in einer Tabelle verkaeufe: Kundin, E-Mail, Produkt, Preis.
Anna hat dreimal gekauft. Ihr Name und ihre Adresse stehen deshalb dreimal da. Jede Kopie ist ein Duplikat. Wird nur eine von drei Kopien geändert, entsteht ein Widerspruch. Starten Sie den nächsten Block und sehen Sie ihn.
Probieren Sie es: den Widerspruch finden
-- Wie viele verschiedene E-Mail-Adressen hat Anna Becker?
SELECT kunde, email, COUNT(*) AS zeilen
FROM verkaeufe
GROUP BY kunde, email;
-- Eine Person, zwei Adressen: Welche stimmt?
Eine Tabelle für jede Sache
Die Lösung heißt aufteilen. Sie suchen die Entitäten: hier Kunden, Produkte und Verkäufe.
Jede Entität bekommt eine eigene Tabelle mit eigenem Primärschlüssel. Annas Adresse steht einmal in kunden. Der Preis des Helms steht einmal in produkte. Ein Verkauf behält nur zwei Fremdschlüssel. Das nennt man Normalisierung.
Probieren Sie es: nur eine Zeile ändern
-- Anna ändert ihre Adresse: Es ist nur eine Zeile zu ändern.
UPDATE kunden SET email = '[email protected]' WHERE id = 1;
-- Die Verkäufe holen Name, Adresse und Preis durch Joins.
SELECT verkaeufe.id, kunden.name, kunden.email, produkte.name, produkte.preis
FROM verkaeufe
JOIN kunden ON verkaeufe.kunden_id = kunden.id
JOIN produkte ON verkaeufe.produkt_id = produkte.id;
Ein Beispiel: vorher und nachher
| Frage | Eine Sammeltabelle | Drei Tabellen |
|---|---|---|
| Zeilen, die bei Annas neuer Adresse zu ändern sind | 3 | 1 |
| Wie oft der Preis des Helms gespeichert ist | 2 | 1 |
| Joins für einen vollständigen Verkauf | 0 | 2 |
| Zwei Adressen für eine Person möglich? | Ja | Nein |
Die Zellen, die Lernende ausfüllen, bleiben in dieser Vorschau leer.
Ein häufiger Fehler
Warnung
Viele glauben, man müsse so stark wie möglich aufteilen. Das stimmt nicht. Teilen Sie auf, wenn sich eine Angabe wiederholt und ändern kann, wie eine E-Mail-Adresse. Jede weitere Tabelle bedeutet einen Join mehr bei jedem Lesen. Gut ist die Aufteilung, die jede Angabe einmal speichert, nicht mehr.
Wann eine NoSQL-Datenbank passt
NoSQL-Datenbanken speichern oft Dokumente statt verbundener Tabellen. Ein Dokument fasst zusammen, was man gemeinsam liest, etwa die Karte eines Produkts.
Das passt, wenn jede Karte andere Felder hat oder man immer alles auf einmal liest. Für Kunden, Bestellungen und Geld, die verbunden sind und sich oft ändern, bleibt eine Datenbank mit Tabellen die übliche Wahl.
Probieren Sie es: eine Produktkarte als Dokument
# Ein Dokument: alles, was man zusammen liest, an einem Ort.
karte = {
"name": "Lastenrad Nordwind",
"preis": 2490,
"eigenschaften": {"traglast_kg": 80, "antrieb": "elektrisch"},
"farben": ["gruen", "grau"],
}
print(karte["name"], "kostet", karte["preis"], "Euro")
print("Farben:", karte["farben"])
# Ein Schloss hat keine Traglast: Seine Karte hätte andere Felder.