Beispielarbeiten · Software & Web-Apps
Datenbank-Design: Schema aus Anforderungen, mit Diagramm und gemessenen Abfragen
Für einen erfundenen Betrieb: aus Anforderungen ein normalisiertes Schema mit Schlüsseln, Fremdschlüsseln, Indizes und Eindeutigkeit. Das Vorher-Schema hat die Standardfehler, das Nachher-Schema läuft mit Demo-Daten, die Umsätze stimmen und der Abfrageplan nutzt die Indizes.
Musterarbeit (Demo), kein Kundenauftrag. Gebaut als Probeaufgabe mit erfundenen Beispieldaten; die Prüfzahlen unten stammen aus dem automatischen Prüflauf und sind nicht geschönt.
Was gebaut wurde
- Primärschlüssel, Fremdschlüssel mit Index, Geld als ganze Cent, Pflichtfelder mit NOT NULL
- Entity-Relationship-Diagramm im Bericht
- Abfragen mit Demo-Daten gemessen, Abfrageplan zeigt die Indizes
- Betrieb erfunden
schema-vorher.sql herunterladen schema-nachher.sql herunterladen
Wie geprüft wurde
Automatischer Prüflauf vom 29.10.2026, aus dem Protokoll (Testdaten erfunden, Zahlen gemessen):
- Demo-Anforderung: Vorher-Schema 12 Befunde, Nachher-Schema 0
- mit Demo-Daten stimmen die Umsaetze, der Abfrageplan nutzt die Indizes, Fremdschluessel und Eindeutigkeit weisen Fehler ab
- 9 Pruefungen
Alle Prüffälle (9 von 9 grün)
- ✓ findet die eingebauten fehler
- ✓ nachher ohne befund
- ✓ gegenprobe tabelle ohne schluessel faellt durch
- ✓ abfragen liefern erwartete zahlen
- ✓ plan nutzt indizes
- ✓ fremdschluessel und eindeutigkeit wirken
- ✓ keine ki floskeln
- ✓ kein versprechen
- ✓ demo gekennzeichnet
Grenzen
Was diese Probe nicht abdeckt, steht hier, damit niemand mehr erwartet:
- Geprueft in SQLite; PostgreSQL und MySQL haben andere Typen und Syntax
- Keine Lastmessung mit Millionen Zeilen
- Bestehende Daten werden erst nach getestetem Migrationsplan und mit Sicherung uebernommen
Der Bericht
# Datenbank-Entwurf - Demo-Betrieb Kornblume (erfunden)
Musterarbeit von GL Tools, kein Kundenauftrag. Gegenstand ist ein Demo-Projekt des erfundenen Betriebs Kornblume, selbst geschrieben, ohne echte Schluessel oder Kundendaten.
Anforderung: Ein Betrieb nimmt Bestellungen auf. Ein Kunde hat viele Bestellungen, eine Bestellung viele Artikel, Preise werden zum Bestellzeitpunkt festgehalten, Kunden sind ueber die E-Mail eindeutig.
## Befunde des Vorher-Schemas (12)
- fremdschluessel nur dem namen nach:bestellung.kunde id
- geld als gleitkommazahl:artikel.preis
- geld als gleitkommazahl:bestellung.preis
- kein primaerschluessel:bestellung
- kunde mail nicht eindeutig
- liste in einer spalte:bestellung.artikel liste
- pflichtfeld ohne not null:artikel.name
- pflichtfeld ohne not null:bestellung.datum
- pflichtfeld ohne not null:bestellung.kunde mail
- pflichtfeld ohne not null:bestellung.kunde name
- pflichtfeld ohne not null:kunde.mail
- pflichtfeld ohne not null:kunde.name
## Befunde des Nachher-Schemas: 0
## Entity-Relationship-Diagramm
```mermaid
erDiagram
kunde ||--o{ bestellung : gibt_auf
bestellung ||--|{ bestellposition : enthaelt
artikel ||--o{ bestellposition : wird_bestellt
```
## Gemessen am Nachher-Schema (SQLite, Demo-Daten)
- Umsatz je Kunde in Cent: {'Demo Eins': 2100, 'Demo Zwei': 900}
- Abfrageplan Bestellungen je Kunde: SEARCH bestellung USING INDEX idx_bestellung_kunde (kunde_id=?)
- Abfrageplan Positionen je Artikel: SEARCH bestellposition USING INDEX idx_position_artikel (artikel_id=?)
- Fremdschluessel weist verwaiste Bestellung ab: ja
- Doppelte E-Mail wird abgewiesen: ja
## Was dieser Entwurf nicht kann
Er gilt fuer SQLite und diese Anforderungen. Bei PostgreSQL oder MySQL aendern sich Typen und Syntax; Datenmengen in der Groessenordnung von Millionen Zeilen brauchen eigene Messungen mit echten Abfragen. Bestehende Daten werden erst nach einem getesteten Migrationsplan uebernommen.So etwas für deinen Betrieb?
Beschreib kurz, was du brauchst. Du bekommst einen Festpreis, bevor ich anfange; ohne dein Ja passiert nichts.