Clara Zetkin
2.2 KiB
Executable File
2.2 KiB
Executable File
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:
- Unit: Wohnung (z.B. Haus A, Wohnung 1)
- --> besteht aus Unit: Raum (z.B. Zimmer 1, Kategorie: Schlafzimmer)
- ----> enthält Inventar/Unit: Bett (Kategorie: Doppelbett, Kapazität: 2 Personen)
- --> besteht aus Unit: Raum (z.B. Zimmer 2, Kategorie: Schlafzimmer)
- ----> 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.