Lernen Sie eine praktische Methode, um User Stories, Entitäten und Workflows in ein klares Datenbankschema zu überführen — und wie KI helfen kann, Lücken und Regeln zu prüfen.
Ein Datenbankschema ist der Plan dafür, wie Ihre App Dinge erinnert. Praktisch ist es:
Wenn das Schema die echte Arbeit abbildet, spiegelt es wider, was Menschen tatsächlich tun — erstellen, prüfen, genehmigen, planen, zuweisen, stornieren — und nicht nur das, was auf einem Whiteboard ordentlich aussieht.
User Stories und Akzeptanzkriterien beschreiben reale Bedürfnisse in klarer Sprache: wer was tut und was „fertig“ bedeutet. Wenn Sie diese als Ausgangspunkt nutzen, übersieht das Schema seltener wichtige Details (z. B. „wir müssen verfolgen, wer die Rückerstattung genehmigt hat“ oder „eine Buchung kann mehrfach verschoben werden").
Vom Story‑Ausgangspunkt aus bleiben Sie auch ehrlich bezüglich Umfang: Wenn etwas nicht in den Stories (oder dem Workflow) steht, behandeln Sie es als optional statt stillschweigend ein kompliziertes Modell „für alle Fälle“ zu bauen.
KI kann Ihnen helfen, schneller voranzukommen, indem sie:
KI kann nicht zuverlässig:
Behandeln Sie KI als starken Assistenten, nicht als Entscheidungsträger.
Wenn Sie diesen Assistenten in echte Geschwindigkeit verwandeln wollen, kann eine Vibe‑Coding‑Plattform wie Koder.ai Ihnen helfen, schneller von Schema‑Entscheidungen zu einer funktionierenden React + Go + PostgreSQL App zu kommen — und dabei bleiben Sie in Kontrolle über Modell, Constraints und Migrationen.
Schema‑Design ist ein Loop: Entwurf → Test gegen Stories → fehlende Daten finden → verfeinern. Ziel ist nicht ein perfektes erstes Ergebnis; Ziel ist ein Modell, das Sie jeder User Story zuordnen können und zuversichtlich sagen: „Ja, wir können alles speichern, was dieser Workflow braucht — und wir können erklären, warum jede Tabelle existiert."
Bevor Sie Anforderungen in Tabellen verwandeln, klären Sie, was Sie modellieren. Ein gutes Schema beginnt selten bei null — es beginnt mit konkreter Arbeit und dem Beweis, den Sie später brauchen (Screens, Outputs und Randfälle).
User Stories sind die Überschrift, aber allein nicht genug. Sammeln Sie:
Wenn Sie KI nutzen, halten diese Inputs das Modell geerdet. KI kann Entitäten und Felder schnell vorschlagen, benötigt aber reale Artefakte, um nicht eine Struktur zu erfinden, die nicht zu Ihrem Produkt passt.
Akzeptanzkriterien enthalten oft die wichtigsten Datenbankregeln, selbst wenn sie Daten nicht explizit erwähnen. Achten Sie auf Formulierungen wie:
Vage Stories („Als Nutzer kann ich Projekte verwalten") verbergen oft mehrere Entitäten und Workflows. Eine weitere Lücke sind fehlende Randfälle wie Stornierungen, Wiederholungen, Teilrückerstattungen oder Neuzuweisungen.
Bevor Sie an Tabellen oder Diagramme denken, lesen Sie die User Stories und markieren Sie die Nomen. In der Anforderungsanalyse deuten Nomen meist auf die „Dinge“ hin, die Ihr System merken muss — diese werden oft zu Entitäten im Schema.
Ein schnelles Gedankenmodell: Nomen → Entitäten, während Verben → Aktionen/Workflows. Wenn eine Story sagt „Ein Manager weist einem Techniker einen Auftrag zu“, sind die wahrscheinlichen Entitäten manager, technician und job — und „weist zu“ deutet auf eine Beziehung hin, die Sie später modellieren.
Nicht jedes Nomen braucht eine eigene Tabelle. Ein Nomen ist ein starker Entitätskandidat, wenn es:
Wenn ein Nomen nur einmal auftaucht oder nur etwas anderes beschreibt („rote Taste“, „Freitag“), ist es vielleicht keine Entität.
Ein häufiger Fehler ist, jedes Detail in eine Tabelle zu verwandeln. Faustregel:
Zwei klassische Beispiele:
Address wahrscheinlich eine eigene Entität. Wenn Sie nur eine einzelne Postadresse benötigen und nie wiederverwenden, kann sie ein Attribut bleiben.KI kann die Entitätenfindung beschleunigen, indem sie Stories scannt und eine Entitätsliste nach Themen (Personen, Arbeitselemente, Dokumente, Orte) zurückgibt. Ein nützlicher Prompt ist: „Extrahiere Nomen, die Daten darstellen, die wir speichern müssen, und gruppiere Duplikate/Synonyme."
Behandeln Sie die Ausgabe als Startpunkt, nicht als fertige Antwort. Stellen Sie Folgefragen wie:
Ziel von Schritt 1 ist eine kurze, saubere Liste von Entitäten, die Sie durch direkte Story‑Belege verteidigen können.
Haben Sie die Entitäten benannt (z. B. Order, Customer, Ticket), ist der nächste Schritt, die Details zu erfassen, die Sie später brauchen. In einer Datenbank sind diese Details Felder (auch Attribute genannt) — die Erinnerungen, die Ihr System nicht vergessen darf.
Beginnen Sie mit der User Story und lesen Sie die Akzeptanzkriterien als Checkliste dessen, was gespeichert werden muss.
Wenn eine Anforderung sagt „Nutzer können Bestellungen nach Lieferdatum filtern“, dann ist delivery_date kein optionales Feld — es muss existieren (oder zuverlässig aus anderen gespeicherten Daten abgeleitet werden). Wenn es heißt „Zeige, wer die Anfrage genehmigt hat und wann“, brauchen Sie wahrscheinlich approved_by und approved_at.
Ein praktischer Test: Braucht jemand diesen Wert, um etwas anzuzeigen, zu suchen, zu sortieren, zu auditieren oder zu berechnen? Wenn ja, gehört er wahrscheinlich als Feld in die Datenbank.
Viele Stories enthalten Wörter wie „Status“, „Typ“ oder „Priorität“. Behandeln Sie diese als kontrollierte Vokabulare — eine begrenzte Menge erlaubter Werte.
Wenn die Menge klein und stabil ist, reicht oft ein Enum‑Feld. Wenn sie wachsen kann, Labels benötigt oder Berechtigungen erfordert (z. B. adminverwaltete Kategorien), nutzen Sie eine separate Lookup‑Tabelle (z. B. status_codes) und speichern eine Referenz.
So werden aus Stories verlässliche Felder — durchsuchbar, reportbar und schwer falsch einzugeben.
Haben Sie die Entitäten (User, Order, Invoice, Comment usw.) und deren Felder entworfen, verbinden Sie sie. Beziehungen sind die Ebene „wie diese Dinge interagieren“, die Ihre Stories implizieren.
One‑to‑one (1:1) bedeutet „ein Ding hat genau ein anderes".
User ↔ Profile (oft lassen sich diese zusammenführen, sofern kein Trennungsgrund besteht).One‑to‑many (1:N) bedeutet „ein Ding kann viele eines anderen haben." Das ist am häufigsten.
User → Order (speichern Sie user_id auf Order).Many‑to‑many (M:N) bedeutet „viele Dinge können mit vielen Dingen verbunden sein." Das benötigt eine zusätzliche Tabelle.
Datenbanken können keine sauberen „Listen von Produkt‑IDs“ in einer Spalte von Order speichern, ohne später Probleme zu bekommen. Stattdessen erstellen Sie eine Join‑Tabelle, die die Beziehung selbst repräsentiert.
Beispiel:
OrderProductOrderItem (Join‑Tabelle)OrderItem enthält typischerweise:
order_idproduct_idquantity, unit_price, discountBeachten Sie, wie Details aus der Story („quantity“) oft auf der Beziehung gehören, nicht auf einer der beiden Entitäten.
Stories sagen oft, ob eine Verbindung obligatorisch oder manchmal fehlen kann.
Order braucht ein user_id (nicht leer zulassen).phone kann leer sein.shipping_address_id kann bei digitalen Bestellungen leer sein.Ein schneller Check: Wenn die Story impliziert, dass der Datensatz nicht ohne den Link erstellt werden kann, behandeln Sie ihn als erforderlich. Bei Formulierungen wie „kann“ oder mit Ausnahmen behandeln Sie ihn als optional.
Wenn Sie eine Story lesen, schreiben Sie sie als einfache Paarung um:
User 1:N CommentComment N:1 UserMachen Sie das für jede Interaktion in Ihren Stories. Am Ende haben Sie ein verbundenes Modell, das zeigt, wie die Arbeit wirklich abläuft — bevor Sie ein ER‑Tool öffnen.
User Stories sagen, was Leute wollen. Workflows zeigen, wie Arbeit tatsächlich fließt, Schritt für Schritt. Einen Workflow in Daten zu übersetzen ist einer der schnellsten Wege, „wir haben vergessen zu speichern“‑Probleme zu entdecken — bevor Sie bauen.
Schreiben Sie den Workflow als Abfolge von Aktionen und Zustandswechseln. Zum Beispiel:
Diese fettgedruckten Wörter werden oft ein status‑Feld (oder eine kleine „state“‑Tabelle) mit klaren erlaubten Werten.
Wenn Sie jeden Schritt durchgehen, fragen Sie: „Was müssten wir später wissen?“ Workflows decken oft Felder auf wie:
submitted_at, approved_at, completed_atcreated_by, assigned_to, approved_byrejection_reason, approval_notesequence für mehrstufige ProzesseWenn Ihr Workflow Warten, Eskalation oder Übergaben enthält, brauchen Sie meist mindestens einen Zeitstempel und ein Feld „wer hat es jetzt".
Manche Workflow‑Schritte sind nicht nur Felder — sie sind eigene Datenstrukturen:
Geben Sie KI sowohl: (1) die User Stories und Akzeptanzkriterien als auch (2) die Workflow‑Schritte. Bitten Sie sie, jeden Schritt aufzulisten und die benötigten Daten für jeden Schritt zu identifizieren (State, Actor, Timestamps, Outputs) und dann jede Anforderung hervorzuheben, die durch die aktuellen Felder/Tabellen nicht abgedeckt ist.
In Plattformen wie Koder.ai wird diese „Gap Check“ praktisch, weil Sie schnell iterieren können: Schema‑Annahmen anpassen, Scaffolding neu erzeugen und ohne langen Umweg weiterarbeiten.
Beim Überführen von Stories in Tabellen legen Sie nicht nur Felder fest — Sie entscheiden auch, wie Daten über die Zeit identifizierbar und konsistent bleiben.
Ein Primärschlüssel identifiziert eindeutig einen Datensatz — denken Sie an die permanente ID‑Karte der Zeile.
Warum jede Zeile eine braucht: Stories implizieren Updates, Referenzen und Historie. Wenn eine Story sagt „Support kann eine Bestellung ansehen und eine Rückerstattung ausstellen“, brauchen Sie eine stabile Möglichkeit, die Bestellung zu referenzieren — auch wenn der Kunde seine E‑Mail ändert, die Adresse editiert wird oder der Bestellstatus wechselt.
In der Praxis ist das meist ein internes id (Nummer oder UUID), das nie ändert.
Ein Fremdschlüssel ist, wie eine Tabelle sicher auf eine andere zeigt. Wenn orders.customer_id auf customers.id referenziert, kann die Datenbank erzwingen, dass jede Bestellung zu einem echten Kunden gehört.
Das passt zu Stories wie „Als Nutzer sehe ich meine Rechnungen.“ Die Rechnung hängt an einem Kunden (und oft an einer Bestellung oder Subscription).
User Stories enthalten oft versteckte Eindeutigkeitsanforderungen:
Diese Regeln verhindern verwirrende Duplikate, die später als „Datenfehler" auftauchen.
Indizes beschleunigen Abfragen wie „Finde Kunde per E‑Mail" oder „liste Bestellungen nach Kunde". Beginnen Sie mit Indizes, die Ihren häufigsten Abfragen und Eindeutigkeitsregeln entsprechen.
Was Sie aufschieben sollten: schwere Indizierung für seltene Reports oder spekulative Filter. Notieren Sie solche Bedürfnisse in Stories, validieren Sie erst das Schema und optimieren Sie dann auf Basis realer Nutzung und langsamer Abfragen.
Normalization hat ein einfaches Ziel: widersprüchliche Duplikate verhindern. Wenn dieselbe Tatsache an zwei Orten gespeichert werden kann, wird sie früher oder später auseinanderlaufen (zwei Schreibweisen, zwei Preise, zwei „aktuelle“ Adressen). Ein normalisiertes Schema speichert jede Tatsache einmal und referenziert sie.
1) Auf wiederholte Gruppen achten
Wenn Sie Muster wie „Phone1, Phone2, Phone3" oder „ItemA, ItemB, ItemC" sehen, ist das ein Signal für eine separate Tabelle (z. B. CustomerPhones, OrderItems). Wiederholte Gruppen erschweren Suche, Validierung und Skalierung.
2) Keine Namens‑/Detailkopien in mehreren Tabellen
Wenn CustomerName in Orders, Invoices und Shipments auftaucht, haben Sie mehrere Wahrheitsquellen geschaffen. Halten Sie Kundendetails in Customers und speichern Sie nur customer_id andernorts.
3) Mehrere Spalten für dasselbe vermeiden
Spalten wie billing_address, shipping_address, home_address sind ok, wenn sie wirklich unterschiedliche Konzepte darstellen. Wenn Sie jedoch „viele Adressen mit Typ“ modellieren, nutzen Sie eine Addresses‑Tabelle mit einem type‑Feld.
4) Lookups von Freitext trennen
Wenn Nutzer aus einer bekannten Menge wählen (Status, Kategorie, Rolle), modellieren Sie es konsistent: entweder als restriktiertes Enum oder als Lookup‑Tabelle. Das verhindert „Pending" vs „pending" vs „PENDING".
5) Prüfen, dass jedes Nicht‑ID Feld von der richtigen Entität abhängt
Ein hilfreicher Bauchtest: Wenn eine Spalte etwas anderes als die Haupteinheit der Tabelle beschreibt, gehört sie wahrscheinlich woanders hin. Beispiel: Orders sollten nicht product_price speichern, es sei denn, es ist ein historischer Snapshot (Preis zum Zeitpunkt der Bestellung).
Manchmal speichern Sie Duplikate bewusst:
Wichtig ist, dass es bewusst geschieht: dokumentieren Sie, welches Feld die Quelle der Wahrheit ist und wie Kopien aktualisiert werden.
KI kann verdächtige Duplikationen (wiederholte Spalten, ähnliche Feldnamen, inkonsistente Statusfelder) markieren und Aufteilungen in Tabellen vorschlagen. Menschen entscheiden jedoch über Trade‑Offs — Einfachheit vs. Flexibilität vs. Performance — basierend darauf, wie das Produkt tatsächlich genutzt wird.
Eine nützliche Regel: Speichern Sie Fakten, die Sie später nicht zuverlässig rekonstruieren können; berechnen Sie alles andere.
Gespeicherte Daten sind die Quelle der Wahrheit: Einzelne Line‑Items, Zeitstempel, Statusänderungen, wer was getan hat. Berechnete (abgeleitete) Daten entstehen aus diesen Fakten: Summen, Zähler, Flags wie „ist überfällig“ und Rollups wie „aktueller Bestand".
Wenn sich zwei Werte aus denselben Fakten berechnen lassen, bevorzugen Sie, die Fakten zu speichern und den Rest zu berechnen. Sonst riskieren Sie Widersprüche.
Abgeleitete Werte ändern sich, wenn ihre Eingaben sich ändern. Wenn Sie sowohl Eingaben als auch das Ergebnis speichern, müssen beide über alle Workflows und Randfälle synchron gehalten werden (Edits, Rückerstattungen, Teillieferungen, rückdatierte Änderungen). Ein verpasstes Update und die DB erzählt unterschiedliche Geschichten.
Beispiel: order_total speichern und gleichzeitig order_items halten. Wenn jemand die Menge ändert oder einen Rabatt anwendet und das Total nicht korrekt aktualisiert wird, sieht Finance eine Zahl, der Warenkorb eine andere.
Workflows zeigen, wann Sie historische Wahrheit und nicht nur „aktuelle Wahrheit“ brauchen. Wenn Nutzer wissen müssen, wie ein Wert damals war, speichern Sie einen Snapshot.
Für eine Bestellung speichern Sie möglicherweise:
order_total beim Checkout (Snapshot), weil Steuern, Rabatte und Preisregeln sich später ändern könnenFür Inventar wird der „Bestand“ oft aus Bewegungen berechnet (Wareneingang, Verkauf, Korrekturen). Wenn Sie eine Auditspur brauchen, speichern Sie die Bewegungen und optional periodische Snapshots für Reporting‑Performance.
Für Login‑Tracking speichern Sie last_login_at als Fakt (Ereignis). „Ist aktiv in den letzten 30 Tagen?“ bleibt berechnet.
Nutzen wir eine vertraute Support‑Ticket App. Wir gehen von fünf User Stories zu einem einfachen ER‑Modell (Entitäten + Felder + Beziehungen) und prüfen es gegen einen Workflow.
Daraus ergeben sich Kernentitäten:
Vorher (häufiger Fehler): Ticket hat assignee_id, aber wir haben vergessen, sicherzustellen, dass nur Agents als Assignees möglich sind.
Nachher: KI markiert das und Sie fügen eine praktische Regel hinzu: assignee muss ein User mit role = "agent" sein (implementierbar per Applikationsvalidierung oder DB‑Constraint/Policy, je nach Stack). Das verhindert „zugewiesen an Kunde“-Daten, die Berichte später kaputtmachen.
Ein Schema ist erst „fertig“, wenn jede User Story mit Daten beantwortet werden kann, die Sie zuverlässig speichern und abfragen können. Der einfachste Validierungsschritt ist: Nehmen Sie jede Story und fragen Sie: „Können wir diese Frage aus der Datenbank zuverlässig für jeden Fall beantworten?“ Wenn die Antwort „vielleicht" ist, hat Ihr Modell eine Lücke.
Formulieren Sie jede Story als eine oder mehrere Testfragen — Dinge, die ein Report, Screen oder API stellen würde. Beispiele:
Wenn Sie eine Story nicht als klare Frage ausdrücken können, ist die Story unklar. Wenn sie sich ausdrücken lässt — aber nicht mit Ihrem Schema beantwortet werden kann — fehlen Feld, Beziehung, Status/Ereignis oder Constraint.
Erstellen Sie einen kleinen Datensatz (5–20 Zeilen pro Schlüsseltabelle) mit normalen und schwierigen Fällen (Duplikate, fehlende Werte, Stornierungen). Spielen Sie dann die Stories mit diesen Daten durch. Sie sehen schnell Probleme wie „wir können nicht sagen, welche Adresse zum Zeitpunkt des Kaufs verwendet wurde“ oder „wir haben keinen Ort, um zu speichern, wer die Änderung genehmigt hat".
Bitten Sie KI, Validierungsfragen pro Story zu erzeugen (inkl. Randfälle und Löschszenarien) und aufzuzählen, welche Daten nötig wären, um sie zu beantworten. Vergleichen Sie diese Liste mit Ihrem Schema: jede Abweichung ist eine konkrete Maßnahme, kein vages Gefühl, dass „etwas nicht stimmt".
KI kann das Datenmodellieren beschleunigen, erhöht aber auch das Risiko, sensible Informationen zu leaken oder falsche Annahmen festzuschreiben. Behandeln Sie sie wie einen sehr schnellen Assistenten: nützlich, aber mit Leitplanken.
Teilen Sie Inputs, die realistisch genug zum Modellieren sind, aber sanitisiert genug, um sicher zu sein:
invoice_total: 129.50, status: "paid")Vermeiden Sie alles, was Personen identifiziert oder vertrauliche Abläufe offenlegt:
Wenn Sie Realismus brauchen, generieren Sie synthetische Beispiele, die Formate und Bereiche nachahmen — kopieren Sie nie Produktionsrows.
Schemas scheitern meist, weil „alle angenommen" etwas unterschiedlich verstanden haben. Führen Sie neben Ihrem ER‑Modell (oder im selben Repo) ein kurzes Entscheidungsprotokoll:
So wird KI‑Output zum Teamwissen statt zum Einzelstück.
Ihr Schema wird mit neuen Stories wachsen. Schützen Sie es durch:
Wenn Sie Plattformen wie Koder.ai nutzen, nutzen Sie Guardrails wie Snapshots und Rollback beim Iterieren an Schema‑Änderungen und exportieren Sie den Source Code, wenn Sie tiefere Anpassungen oder traditionelle Reviews brauchen.
Beginnen Sie mit den Stories und markieren Sie die Nomen, die Dinge repräsentieren, die Ihr System merken muss (z. B. Ticket, User, Category).
Erhöhen Sie ein Nomen zur Entität, wenn es:
Behalten Sie eine kurze Liste, die Sie mit konkreten Story‑Sätzen begründen können.
Verwenden Sie den Test „Attribut vs. Entität":
customer.phone_number).Ein einfacher Hinweis: Wenn Sie jemals „viele davon“ brauchen, benötigen Sie wahrscheinlich eine eigene Tabelle.
Behandeln Sie Akzeptanzkriterien als eine Checkliste für die Speicherung. Wenn eine Anforderung sagt, dass etwas gefiltert/angezeigt/gespeichert/geprüft werden muss, müssen Sie es speichern (oder zuverlässig ableiten).
Beispiele:
approved_by, approved_atFormulieren Sie Storys als Beziehungssätze:
customer_id auf orders)order_items hinzu)Wenn die Beziehung selbst Daten hat (z. B. Menge, Preis, Rolle), gehören diese Daten auf die Join‑Tabelle.
Modellieren Sie M:N mit einer Join‑Tabelle, die beide Fremdschlüssel und ggf. beziehungs‑spezifische Felder speichert.
Typisches Muster:
ordersGehen Sie den Workflow Schritt für Schritt durch und fragen Sie: „Was müssten wir später beweisen können?“
Häufige Ergänzungen:
submitted_at, closed_atBeginnen Sie mit:
id)orders.customer_id → customers.id)Fügen Sie dann Indizes für die häufigsten Abfragen hinzu (z. B. , , ). Spekulative Indizes können Sie nach realer Nutzungsanalyse ergänzen.
Führen Sie einen schnellen Konsistenzcheck durch:
Phone1/Phone2), splitten Sie in eine Kindtabelle.Denormalisieren Sie erst mit klarer Begründung (Performance, Reporting, Audit‑Snapshots) und dokumentieren Sie, was die Quelle der Wahrheit ist.
Speichern Sie Fakten, die sich nicht zuverlässig rekonstruieren lassen; berechnen Sie alles andere.
Gut zu speichern:
Gut zu berechnen:
Wenn Sie abgeleitete Werte speichern (z. B. ), legen Sie fest, wie die Synchronisation erfolgt und testen Sie Randfälle (Rückerstattungen, Änderungen, Teillieferungen).
Nutzen Sie KI für Entwürfe, prüfen Sie aber gegen Ihre Artefakte.
Praktische Prompts:
Schutzmaßnahmen:
delivery_dateemailproductsorder_items mit order_id, product_id, quantity, unit_priceVermeiden Sie, eine Liste von IDs in einer einzigen Spalte zu speichern — Abfragen, Updates und Integrität werden sonst schwer handhabbar.
created_by, assigned_to, closed_byrejection_reasonWenn Sie wissen müssen „wer was wann geändert hat“, fügen Sie besser eine Ereignis-/Audit‑Tabelle hinzu, statt ein Feld zu überschreiben.
emailcustomer_idstatus + created_atorder_total