Zusammenfassung

← Zurück: Troubleshooting | ← Zurück zur Übersicht

Dateinamen-Konvention:

Wichtig: Die Dateien sind nach Funktionalität benannt:

Datei	Zweck	Enthält
`datamodelRealEstateChat.py`	Chat-Interface Modelle	`RealEstateQuery`, `RealEstateQueryResult`, `RealEstateChatSession`
`datamodelRealEstate.py`	Real Estate-Datenmodelle	`Projekt`, `Parzelle`, `Dokument`, etc. (allgemein verwendbar)
`interfaceDbRealEstateChatObjects.py`	Chat-Interface Interface	Methoden für Sessions und Queries
`interfaceDbRealEstateObjects.py`	Real Estate CRUD Interface	Methoden für Projekt, Parzelle, etc. (optional)

Hinweis: Das Modell ist allgemein für alle Real Estate-Firmen verwendbar. PEK ist nur ein Beispiel.

Zu erstellende Dateien:

modules/datamodels/datamodelRealEstateChat.py (Chat-Interface Modelle)
- Pydantic-Modelle: RealEstateQuery, RealEstateQueryResult, RealEstateChatSession
- Enums: QueryStatusEnum
modules/datamodels/datamodelRealEstate.py (Real Estate-Datenmodell)
- Pydantic-Modelle: Projekt, Parzelle, Dokument, Kontext, GeoPolylinie, GeoPunkt, Land, Kanton, Gemeinde
- Enums: StatusProzess, DokumentTyp, JaNein, GeoTag
- Siehe ../PEK_datamodel_desc.md für vollständige Spezifikation (PEK ist ein Beispiel, das Modell ist allgemein verwendbar)
modules/interfaces/interfaceDbRealEstateChatObjects.py (Chat-Interface)
- RealEstateChatObjects Klasse für Datenbankzugriff (Chat-Sessions, Queries)
- RealEstateChatAccess Klasse für Zugriffskontrolle
- getInterface() Factory-Funktion
modules/interfaces/interfaceDbRealEstateObjects.py (NEU - für Real Estate-Datenmodell CRUD)
- RealEstateObjects Klasse für CRUD-Operationen auf Real Estate-Entitäten (Projekt, Parzelle, etc.)
- RealEstateAccess Klasse für Zugriffskontrolle
- Methoden für Projekt, Parzelle, Dokument, etc.
- Hinweis: Diese Datei ist für CRUD-Operationen auf die Real Estate-Entitäten. Das Chat-Interface nutzt interfaceDbRealEstateChatObjects.py (siehe Punkt 3).
- Optional: Falls Sie eine separate CRUD-API benötigen (das Chat-Interface kann auch direkt SQL-Queries verwenden)
modules/features/realEstate/mainRealEstate.py
- Feature-Logik-Funktionen: createSession, executeDatabaseQuery, etc.
modules/routes/routeRealEstate.py
- FastAPI Router mit allen Endpunkten für Chat-Interface
modules/routes/routeRealEstateData.py (NEU - für Real Estate-Datenmodell)
- FastAPI Router für CRUD-Operationen auf Real Estate-Entitäten
- Endpunkte für Projekt, Parzelle, Dokument, etc.
- Optional: Falls Sie eine separate CRUD-API benötigen (das Chat-Interface kann auch direkt SQL-Queries verwenden)

Zu modifizierende Dateien:

app.py
- Router-Registrierung für routeRealEstate hinzufügen (Chat-Interface)
- Router-Registrierung für routeRealEstateData hinzufügen (falls CRUD-API gewünscht)
env_dev.env (optional)
- Separate Datenbank-Konfiguration falls gewünscht
- PostGIS-Konfiguration falls geografische Abfragen benötigt werden
modules/features/featuresLifecycle.py (optional)
- Feature-Initialisierung falls benötigt
- Initialisierung von Standard-Daten (z.B. Land "Schweiz", Kantone, Gemeinden)

Datenmodell-Implementierung:

Wichtig: Bevor Sie das Chat-Interface nutzen können, müssen Sie die Real Estate-Datenmodell-Entitäten implementieren:

Erstellen Sie modules/datamodels/datamodelRealEstate.py mit allen Entitäten aus ../PEK_datamodel_desc.md
- Hinweis: PEK ist ein Beispiel für eine Real Estate-Firma, aber das Modell ist allgemein verwendbar für alle Real Estate-Firmen
Beachten Sie die Objektbeziehungen:
- parzellen: list[Parzelle] wird als JSONB gespeichert
- kontextKanton: Kanton wird als String-ID gespeichert (Foreign Key)
Implementieren Sie die Enums entsprechend der Spezifikation
Testen Sie die Tabellenerstellung durch den DatabaseConnector

Nächste Schritte

Real Estate-Datenmodell-Implementierung:
- Erstellen Sie die Pydantic-Modelle für alle Real Estate-Entitäten (Projekt, Parzelle, Dokument, Kontext, GeoPolylinie, GeoPunkt, Land, Kanton, Gemeinde)
- Implementieren Sie die Enums (StatusProzess, DokumentTyp, JaNein, GeoTag)
- Siehe ../PEK_datamodel_desc.md für vollständige Spezifikation (PEK ist ein Beispiel, das Modell ist allgemein verwendbar)
Query-Validierung implementieren: Siehe Sicherheitshinweise
- Besonders wichtig für Real Estate-Datenmodell: Nur SELECT-Statements erlauben
- Whitelist für erlaubte Tabellen (Projekt, Parzelle, etc.)
Natural Language Processing:
- Implementieren Sie NLP für queryType="natural"
- Beispiele: "Zeige mir alle Parzellen in Zürich" → SQL-Query
- Nutzen Sie AI-Modelle zur SQL-Generierung aus natürlicher Sprache
Geografische Abfragen:
- PostGIS-Integration für räumliche Abfragen
- Beispiel: "Zeige alle Parzellen innerhalb eines bestimmten Perimeters"
- Nutzung von GeoPolylinie und GeoPunkt für GIS-Funktionen
Query-History: Erweiterte Historie-Funktionen
- Speichern häufig verwendeter Queries
- Query-Templates für häufige Abfragen (z.B. "Parzellen nach Bauzone")
Export-Funktionen: CSV/Excel-Export von Ergebnissen
- Export von Parzellen-Listen
- Export von Projekt-Übersichten
Caching: Query-Ergebnisse cachen für wiederholte Abfragen
- Besonders für administrative Daten (Land, Kanton, Gemeinde)
Permissions: Erweiterte Berechtigungen für bestimmte Tabellen
- Mandaten-basierte Filterung für Projekte und Parzellen
- Rollen-basierte Zugriffe (z.B. nur Leserechte für bestimmte Benutzer)

Architektur-Zusammenfassung

Dieses Feature folgt dem etablierten Muster des Projekts:

Separation of Concerns: Routes → Features → Interfaces → Connectors
Dependency Injection: Interfaces werden über Factory-Funktionen erstellt
Access Control: Mandaten- und Benutzer-basierte Filterung
Type Safety: Pydantic-Modelle für Validierung
Async Support: Asynchrone Verarbeitung für Skalierbarkeit

Die Implementierung ist modular und erweiterbar. Sie können weitere Funktionen hinzufügen, ohne die bestehende Struktur zu ändern.