Datenbank & Datenmodell - Dxme98/Dokumentation GitHub Wiki

🗄️ Datenbank & Datenmodell

Das Projekt nutzt PostgreSQL als robuste und skalierbare relationale Datenbank.

Alle Schema-Änderungen werden über Flyway verwaltet. Dieses Migrations-Tool versioniert die Datenbank-Struktur als Code und stellt bei jedem Start der Anwendung sicher, dass das Schema in jeder Umgebung 100% konsistent ist.

Entity Relationship Diagram (ERD)

Das folgende Diagramm visualisiert das Datenmodell von TaskTrackr, zur Übersicht wurde nicht jedes Feld der Entities modelliert. Eine Analyse der modularen Struktur (erkennbar an den Farben) und der Design-Entscheidungen folgt direkt unter dem Diagramm.

Hinweis: Für eine hochauflösende Ansicht bitte auf das Diagramm klicken.

Analyse des Datenmodells

Die farbliche Trennung des Diagramms spiegelt die modulare Architektur der Anwendung wider:

• 🟥 Rot (Project Management): Das universelle Kernmodul. Es verwaltet alle übergreifenden Funktionen, die für jeden Projekttyp gelten (Mitglieder, dynamische Rollen, Berechtigungen, Einladungen).

• 🟩 Grün / 🟦 Blau (Spezial-Module): Diese Module sind über eine 1:0..1-Beziehung (optional) an das Kernprojekt gebunden. Ein Projekt kann entweder ein ScrumDetails (grün) oder ein BasicDetails (blau) sein, aber niemals beides.

• ** Vorteil (Erweiterbarkeit):** Dieses Design garantiert eine saubere Trennung der Geschäftslogik (Hohe Kohäsion). Neue Projekttypen (z.B. "Kanban") können jederzeit als neues, unabhängiges Modul hinzugefügt werden, ohne bestehenden Code zu beeinträchtigen.

Design-Prinzipien: Integrität & Performance

Über das modulare Design hinaus erzwingt die Datenbank selbst aktiv die Geschäftsregeln:

• Strikte Datenintegrität:

  • Native PostgreSQL ENUM-Typen: Verwendung von native ENUM-Typen (z.B. task_priority), um strikte Typsicherheit direkt auf Datenbankebene zu garantieren.
  • UNIQUE-Constraints: Verhindern doppelte Daten (z.B. bei project_roles oder Einladungen).
  • ON DELETE-Strategien: Bewusster Einsatz von CASCADE (z.B. project_member) und SET NULL (z.B. creator_id), um die Datenkonsistenz bei Löschvorgängen präzise zu steuern.

• Performance:

  • Indizierung: Gezielte CREATE INDEX-Befehle optimieren häufige Abfragen (z.B. das Suchen von Einladungen nach receiver_id und status).