# RoggioApp - Datenarchitektur & Normalisierung

## 1. Die Grundphilosophie (Single Source of Truth)
*   **Keine Redundanz:** Keine doppelte Datenhaltung und (noch wichtiger) keine doppelte Dateneingabe.
*   **Ableitung statt Hardcoding (Computed Values):**
    *   Die Fläche einer Wohnung wird *nicht* als eigenes Feld in der Datenbank eingetragen. Sie wird berechnet (Summe der Flächen aller Räume, die zur Wohnung gehören).
    *   Die Schlafplatzkapazität einer Einheit wird *nicht* als Zahl eingetragen. Sie ergibt sich aus: `Einheit -> hat Räume (Kategorie: Schlafzimmer) -> hat Betten -> Bett hat Schlafplätze (1 oder 2) = Summe X`.

## 2. Granularität & Hierarchie
Alles im physischen Raum ist eine "Unit" (Einheit), die zueinander in Beziehung steht und strikt kategorisiert sein muss.

**Beispiel-Hierarchie für Kapazitäten:**
1.  **Unit: Wohnung** (z.B. Haus A, Wohnung 1)
2.  --> besteht aus **Unit: Raum** (z.B. Zimmer 1, Kategorie: Schlafzimmer)
3.  ----> enthält **Inventar/Unit: Bett** (Kategorie: Doppelbett, Kapazität: 2 Personen)
4.  --> besteht aus **Unit: Raum** (z.B. Zimmer 2, Kategorie: Schlafzimmer)
5.  ----> enthält **Inventar/Unit: Bett** (Kategorie: Einzelbett, Kapazität: 1 Person)

*Ergebnis:* Das System weiß automatisch, dass die Wohnung 3 Schlafplätze hat. Wenn ein Einzelbett ins Zimmer gestellt wird, erhöht sich die Kapazität der Wohnung automatisch auf 4, ohne dass jemand das Datenfeld "Wohnung_MaxPax" ändern muss.

## Claras Architektonische Ableitung
Diese Anforderung schreit nach einem strikten, relationalen Baum-Modell (Tree/Graph) in PostgreSQL.
*   *Vorteil:* Absolute Konsistenz. Es gibt keine Widersprüche (z.B. "Wohnung hat 5 Betten, aber im System steht Kapazität 2").
*   *Herausforderung (auf die wir achten müssen):* Solche "Bottom-Up"-Berechnungen (Summen aus der Tiefe der Datenbank holen) können in SQL sehr komplex (viele JOINs) werden, wenn man z.B. nur schnell filtern will: "Zeig mir alle Wohnungen für 4 Personen". 
*   *Lösungansatz:* Wir nutzen das normalisierte Modell für die *Struktur*, aber arbeiten beim Abfragen vielleicht mit Datenbank-Views (Materialized Views) oder Prisma-Computed-Fields, damit das Frontend nicht endlos rechnen muss.