Agieren Sie als: Senior Workflow- und Datenmodellierungsarchitekt.

Warum diese Aufgabe wichtig ist: Ein sauberes, normalisiertes Datenmodell ist das Rückgrat jeder formularbasierten Anwendung. Es verhindert Duplikate, ermöglicht Berichte und unterstützt stabile APIs und Automatisierungen.

Wichtige Grenzen:
- Bevorzugen Sie 3NF-ähnliche Normalisierung, es sei denn, explizite Denormalisierung ist für die Leseleistung gerechtfertigt.
- Verwenden Sie klare, geschäftsfreundliche Namen; fügen Sie maschinensichere Bezeichner hinzu.
- Machen Sie Annahmen explizit und listen Sie offene Fragen auf.

Benutzereingaben (unten einfügen):
[Geschäftsziel]
[Primäre Formularfelder]
[Wichtige Stakeholder]
[Beispiele für nachgelagerte Anforderungen: Genehmigungen, Berichte, Dashboards]
[Erwartetes Volumen und Wachstum]

Ziele:
1) Wandeln Sie das Formular in Entitäten, Felder, Datentypen und Einschränkungen um.
2) Kartieren Sie Beziehungen (1–1, 1–viele, viele–viele) und Verknüpfungstabellen.
3) Schlagen Sie Bezeichner, Eindeutigkeitsschlüssel und Auditfelder (created_at, updated_at, created_by) vor.
4) Stellen Sie Beispiel-Datensätze bereit, um Form und Benennung zu validieren.

Analyseablauf:
1) Analysieren Sie die Formularfelder und gruppieren Sie sie nach konzeptioneller Entität.
2) Identifizieren Sie Normalisierungsmöglichkeiten und entfernen Sie wiederholte Gruppen.
3) Definieren Sie Feld-Datentypen, Validierungsbereiche und Enumerationen.
4) Legen Sie Primärschlüssel, natürliche Schlüssel und Fremdschlüssel fest.
5) Dokumentieren Sie Beziehungskardinalität sowie Lösch-/Aktualisierungsverhalten.
6) Fügen Sie bei Bedarf Audit-, Statusfelder und Soft-Delete hinzu.
7) Listen Sie abgeleitete Felder und deren Berechnungsorte auf.
8) Heben Sie Annahmen und unbeantwortete Fragen für Stakeholder hervor.

Erforderliches Ausgabeformat:
- Entitätenliste mit: Name, Beschreibung, Felder[{Name, ID, Typ, Pflichtfeld, Standardwert, Enum, Validierung}], Schlüssel, Beziehungen[{Ziel, Typ, FK, Verhalten}] und Notizen.
- Beispiel-JSON mit 2–3 Datensätzen pro Kernentität.
- Offene Fragen und empfohlene Entscheidungen.

Qualitätskontrollen:
- Benennung ist konsistent und im Singular für Entitäten, snake_case oder camelCase für technische IDs.
- Keine doppelten Felder über Entitäten hinweg ohne Begründung.
- Alle Beziehungen haben klare Eigentümerschaft und Löschverhalten.

Prüfliste:
- Kann dieses Modell die Top-5-Berichtsfragen beantworten?
- Sind Statusfelder und Zeitstempel dort vorhanden, wo Lebenszyklus relevant ist?
- Sind alle Enumerationen geschlossen und dokumentiert?

Abschließende Anweisung: Erstellen Sie zuerst das Modell und die Beispiele. Geben Sie dann eine einleitende Begründung und eine kurze Migrationsnotiz für bestehende Tabellendaten an.