Skript: Datenbanken und SQL mit der Warenautomat-Datenbank
2. Datenbankmodelle
2.1 Vom realen Problem zur Tabelle
Ein Datenbankmodell beschreibt, welche Dinge aus der realen Welt gespeichert werden sollen und wie sie zusammenhängen. Der Weg vom Problem zur Datenbank läuft typischerweise in Schritten:
- Inhaltlichen Ausschnitt festlegen: Was soll das System können (z. B. Bestand je Automat verwalten)?
- Inhaltlichen Ausschnitt festlegen: Was soll das System können (z. B. Bestand je Automat verwalten)?
- Objekte finden: Welche Entitäten gibt es (z. B.
automat,produkt,standort)? - Eigenschaften festlegen: Welche Attribute braucht jede Entität?
- Beziehungen und Kardinalitäten bestimmen: 1:1, 1:n oder m:n.
- Geschäftsregeln festhalten: Pflichtfelder, Eindeutigkeit, zulässige Werte.
- Relational umsetzen: Tabellen, Primärschlüssel, Fremdschlüssel und Constraints definieren.
Erst danach werden die Tabellen technisch mit CREATE TABLE umgesetzt.
2.2 Abstraktion
Beim Modellieren wird nur der relevante Teil der Realität übernommen. Das nennt man Abstraktion: Der Datenbankinhalt ist immer nur ein Ausschnitt der Wirklichkeit.
[!NOTE] Beispiel:
- Für einen Automaten sind
seriennummer,modell,statusundstandort_idwichtig.- Unwichtige Details (z. B. Farbe, Geruch, Kratzer oder interne Kabelverlegung) werden weggelassen.
Gute Abstraktion bedeutet: so einfach wie möglich, aber so genau wie nötig.
2.3 Vorteile eines sauberen Modells
Ein gutes Modell vermeidet doppelte Daten, vereinfacht Abfragen und macht Regeln sichtbar. In der Warenautomat-Datenbank sind produkt, lieferant, automat und standort typische Modellobjekte.
Diese Art der Modellierung nach echten “Dingen” nennt sich semantische Modellierung. Eine Alternative (oder Ergänzung) hierzu ist die Normalisierung.
2.4 Weitere Datenbankmodelle
Das relationale Modell ist sehr verbreitet, aber nicht das einzige Modell:
| Modell | Grundidee | Typische Stärke | Typische Einsatzfelder |
|---|---|---|---|
| Relational | Daten in Tabellen mit festen Spalten und Schlüsseln | Hohe Konsistenz, starke Abfragesprache (SQL) | ERP, Warenwirtschaft, Schul- und Verwaltungssoftware |
| NoSQL (Sammelbegriff) | Flexible Strukturen, je nach Typ Dokument, Key-Value, Wide-Column | Sehr gute horizontale Skalierung, flexible Schemata | Web-Backends, Logs, große verteilte Datenmengen |
| Hierarchisch | Baumstruktur mit Eltern-Kind-Beziehungen | Schnelle Navigation entlang fester Hierarchien | Verzeichnisstrukturen, legacy Systeme |
| Graphen-Datenbank | Knoten und Kanten als Kernmodell | Sehr gut für stark vernetzte Daten | Soziale Netzwerke, Routen, Empfehlungs- und Betrugserkennung |
| Objekt-Datenbank | Persistenz von Objekten inkl. Methoden/Vererbung | Nahe an objektorientierter Programmierung | Spezialanwendungen mit komplexen Objektstrukturen |
Hinweis zu NoSQL: NoSQL bedeutet nicht “kein SQL”, sondern meist “nicht nur relational”. Viele NoSQL-Systeme setzen bewusst andere Prioritäten, z. B. Skalierbarkeit und Schema-Flexibilität.
Querverweise
Übungen zum Kapitel
Übung 1: Nenne zwei Entitäten aus der Warenautomat-Datenbank und beschreibe sie in einem Satz.
Lösung
**Lösung:** `automat` beschreibt einen Verkaufsautomaten. `produkt` beschreibt einen verkaufbaren Artikel mit Preis, Kategorie und Lieferant.Übung 2: Nenne einen Vorteil der Trennung von produkt und lieferant.
Lösung
**Lösung:** Ein Lieferant kann mehrere Produkte liefern, ohne dass seine Daten mehrfach gespeichert werden müssen.Übung 3: Warum ist inventar ein eigenständiges Modellobjekt?