FallenBirdyForm/ER_Diagramm.md

ER-Diagramm - Django FBF Datenbank

Übersicht der Datenbankstruktur

erDiagram
    User ||--o{ FallenBird : creates
    User ||--o{ Costs : creates
    User ||--o{ Emailadress : creates
    
    Bird ||--o{ FallenBird : "is type of"
    Bird ||--o{ BirdEmail : "has emails for"
    
    Circumstance ||--o{ FallenBird : "describes finding"
    BirdStatus ||--o{ FallenBird : "has status"
    Aviary ||--o{ FallenBird : "houses"
    
    FallenBird ||--o{ Costs : "has costs"
    
    ContactTag ||--o{ Contact : "categorizes"
    
    Emailadress ||--o{ BirdEmail : "used for birds"
    
    User {
        int id PK
        string username
        string email
        string first_name
        string last_name
        datetime date_joined
        boolean is_active
        boolean is_staff
        boolean is_superuser
    }
    
    FallenBird {
        uuid id PK
        string bird_identifier
        uuid bird_id FK
        string age
        string sex
        date date_found
        string place
        datetime created
        datetime updated
        uuid find_circumstances_id FK
        string diagnostic_finding
        int user_id FK
        int status_id FK
        uuid aviary_id FK
        string sent_to
        text comment
        text finder
    }
    
    Bird {
        bigint id PK
        string name UK
        richtext description
    }
    
    BirdStatus {
        bigint id PK
        string description UK
    }
    
    Circumstance {
        bigint id PK
        string description
    }
    
    Aviary {
        uuid id PK
        string description UK
        string condition
        date last_ward_round
        string comment
    }
    
    Costs {
        uuid id PK
        uuid id_bird_id FK
        decimal costs
        date created
        string comment
        int user_id FK
    }
    
    Contact {
        uuid id PK
        string name
        string phone
        string email
        string address
        string comment
        uuid tag_id_id FK
    }
    
    ContactTag {
        uuid id PK
        string tag
    }
    
    Emailadress {
        int id PK
        string email_address
        datetime created_at
        datetime updated_at
        int user_id FK
    }
    
    BirdEmail {
        int id PK
        int bird_id FK
        int email_id FK
    }

Tabellenbeschreibungen

Kern-Entitäten

FallenBird (Patienten)

• Zweck: Zentrale Entität für gefundene/verletzte Vögel
• Primärschlüssel: UUID
• Beziehungen:
  • Gehört zu einem Bird (Vogelart)
  • Hat einen BirdStatus (Status)
  • Wird von einem User erstellt
  • Kann in einer Aviary (Voliere) untergebracht sein
  • Hat Circumstance (Fundumstände)
  • Kann Costs (Kosten) haben

Bird (Vogelarten)

• Zweck: Katalog der verschiedenen Vogelarten
• Primärschlüssel: BigInt
• Eindeutig: Name
• Beziehungen: Hat viele FallenBird Instanzen

Aviary (Volieren)

• Zweck: Unterbringungsplätze für die Vögel
• Primärschlüssel: UUID
• Status: Offen, Geschlossen, Gesperrt
• Beziehungen: Kann mehrere FallenBird beherbergen

Referenz-Tabellen

BirdStatus (Patientenstatus)

• Zweck: Status-Katalog (z.B. "In Behandlung", "Freigelassen", "Verstorben")
• Primärschlüssel: BigInt

Circumstance (Fundumstände)

• Zweck: Katalog der Fundumstände (z.B. "Verletzt gefunden", "Aus Nest gefallen")
• Primärschlüssel: BigInt

Kosten-Management

Costs (Kosten)

• Zweck: Kostenerfassung pro Patient
• Primärschlüssel: UUID
• Beziehungen: Gehört zu einem FallenBird und wird von einem User erstellt

Kontakt-Management

Contact (Kontakte)

• Zweck: Kontaktdaten (Finder, Tierärzte, etc.)
• Primärschlüssel: UUID
• Beziehungen: Kann mit ContactTag kategorisiert werden

ContactTag (Kontakt-Tags)

• Zweck: Kategorisierung von Kontakten
• Primärschlüssel: UUID

E-Mail-System

Emailadress (E-Mail-Adressen)

• Zweck: Verwaltung von E-Mail-Adressen
• Primärschlüssel: BigInt
• Beziehungen: Gehört zu einem User

BirdEmail (Vogel-E-Mail-Verknüpfung)

• Zweck: Many-to-Many Beziehung zwischen Vögeln und E-Mail-Adressen
• Primärschlüssel: BigInt

Datenbank-Design-Prinzipien

Primärschlüssel-Strategien

• UUID: Für Geschäftsobjekte (FallenBird, Aviary, Contact, ContactTag, Costs)
• BigInt: Für Referenzdaten (Bird, BirdStatus, Circumstance) und E-Mail-System

Beziehungstypen

• 1:N: Die meisten Beziehungen (User zu FallenBird, Bird zu FallenBird, etc.)
• M:N: Bird ↔ Emailadress über BirdEmail
• Optional: FallenBird.aviary (kann NULL sein)

Besondere Eigenschaften

• Soft References: Costs.id_bird mit SET_NULL für Datenschutz
• Audit Trail: created/updated Felder in wichtigen Tabellen
• Rich Text: Bird.description für formatierte Beschreibungen
• JSON/Array Fields: Potentiell für Kosten-Historie (siehe costs_default() Funktion)

Geschäftslogik-Unterstützung

Das Schema unterstützt folgende Geschäftsprozesse:

1. Patientenaufnahme: FallenBird → Bird, Circumstance, User
2. Unterbringung: FallenBird → Aviary
3. Statusverfolgung: FallenBird → BirdStatus
4. Kostenverfolgung: FallenBird → Costs
5. Kontaktverwaltung: Contact → ContactTag
6. E-Mail-Benachrichtigungen: Bird → BirdEmail → Emailadress