136 lines
6.5 KiB
Markdown
136 lines
6.5 KiB
Markdown
# Zusammenfassung
|
|
|
|
[← Zurück: Troubleshooting](12-troubleshooting.md) | [← Zurück zur Übersicht](README.md)
|
|
|
|
## 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:
|
|
|
|
1. **`modules/datamodels/datamodelRealEstateChat.py`** (Chat-Interface Modelle)
|
|
- Pydantic-Modelle: `RealEstateQuery`, `RealEstateQueryResult`, `RealEstateChatSession`
|
|
- Enums: `QueryStatusEnum`
|
|
|
|
2. **`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)
|
|
|
|
3. **`modules/interfaces/interfaceDbRealEstateChatObjects.py`** (Chat-Interface)
|
|
- `RealEstateChatObjects` Klasse für Datenbankzugriff (Chat-Sessions, Queries)
|
|
- `RealEstateChatAccess` Klasse für Zugriffskontrolle
|
|
- `getInterface()` Factory-Funktion
|
|
|
|
4. **`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)
|
|
|
|
5. **`modules/features/realEstate/mainRealEstate.py`**
|
|
- Feature-Logik-Funktionen: `createSession`, `executeDatabaseQuery`, etc.
|
|
|
|
6. **`modules/routes/routeRealEstate.py`**
|
|
- FastAPI Router mit allen Endpunkten für Chat-Interface
|
|
|
|
7. **`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:
|
|
|
|
1. **`app.py`**
|
|
- Router-Registrierung für `routeRealEstate` hinzufügen (Chat-Interface)
|
|
- Router-Registrierung für `routeRealEstateData` hinzufügen (falls CRUD-API gewünscht)
|
|
|
|
2. **`env_dev.env`** (optional)
|
|
- Separate Datenbank-Konfiguration falls gewünscht
|
|
- PostGIS-Konfiguration falls geografische Abfragen benötigt werden
|
|
|
|
3. **`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:
|
|
|
|
1. **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
|
|
2. **Beachten Sie die Objektbeziehungen**:
|
|
- `parzellen: list[Parzelle]` wird als JSONB gespeichert
|
|
- `kontextKanton: Kanton` wird als String-ID gespeichert (Foreign Key)
|
|
3. **Implementieren Sie die Enums** entsprechend der Spezifikation
|
|
4. **Testen Sie die Tabellenerstellung** durch den DatabaseConnector
|
|
|
|
---
|
|
|
|
## Nächste Schritte
|
|
|
|
1. **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)
|
|
|
|
2. **Query-Validierung implementieren**: Siehe [Sicherheitshinweise](10-security.md)
|
|
- Besonders wichtig für Real Estate-Datenmodell: Nur SELECT-Statements erlauben
|
|
- Whitelist für erlaubte Tabellen (Projekt, Parzelle, etc.)
|
|
|
|
3. **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
|
|
|
|
4. **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
|
|
|
|
5. **Query-History**: Erweiterte Historie-Funktionen
|
|
- Speichern häufig verwendeter Queries
|
|
- Query-Templates für häufige Abfragen (z.B. "Parzellen nach Bauzone")
|
|
|
|
6. **Export-Funktionen**: CSV/Excel-Export von Ergebnissen
|
|
- Export von Parzellen-Listen
|
|
- Export von Projekt-Übersichten
|
|
|
|
7. **Caching**: Query-Ergebnisse cachen für wiederholte Abfragen
|
|
- Besonders für administrative Daten (Land, Kanton, Gemeinde)
|
|
|
|
8. **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.
|
|
|
|
---
|
|
|
|
[← Zurück: Troubleshooting](12-troubleshooting.md) | [← Zurück zur Übersicht](README.md)
|
|
|
|
|
|
|