Erweitere Marktmanagement-Datenhierarchie

This commit is contained in:
gitea_admin committed 2026-09-18 19:33:28 +02:00
1 parent 9e877ac464
commit 5f6806ab33
3 files changed
+115 -8

No files matched your search

+1
View File
@@ -52,6 +52,7 @@ dokumentiert.
## Dokumente ## Dokumente
- [Anforderungsprofil](requirements/market_management_requirements.md) - [Anforderungsprofil](requirements/market_management_requirements.md)
- [Datenarchitektur](data/market_management_data_architecture.md)
- Prozessdokumente werden unter `processes/main/` und - Prozessdokumente werden unter `processes/main/` und
`processes/sub_processes/` angelegt, sobald die fachlichen Prozesse explizit `processes/sub_processes/` angelegt, sobald die fachlichen Prozesse explizit
definiert sind. definiert sind.
@@ -0,0 +1,82 @@
# market_management_data_architecture
Stand: 2026-09-18
Status: Bestätigtes Datenarchitektur-Zielbild; Feldzuordnung teilweise offen
## 1. Ziel
Das Marktmanagement-Modul muss wiederkehrende Märkte mit mehreren konkreten
Durchführungen und mehreren Tagen je Durchführung ohne redundante Vermischung
der Daten abbilden können.
## 2. Bestätigte Hierarchie
```text
Kategorie ─── Markt 1 ─── n Durchführung 1 ─── n Durchführungstag
```
Für Kategorie und Markt werden beliebig viele Datensätze unterstützt. Ob die
Zuordnung Kategorie–Markt `1:n` oder `n:m` ist, bleibt offen.
### Kategorie
Eine Kategorie ordnet Märkte fachlich. Die konkrete Kategorisierung und die
zulässigen Kategorieattribute sind noch nicht weiter spezifiziert.
### Markt
Ein Markt ist die übergeordnete fachliche Identität, unter der mehrere konkrete
Durchführungen geführt werden können.
### Durchführung
Eine Durchführung ist eine konkrete Ausgabe bzw. Teilnahme an einem Markt. Die
Durchführung kann einen oder mehrere Durchführungstage umfassen.
### Durchführungstag
Ein Durchführungstag ist ein einzelner Tag innerhalb einer konkreten
Durchführung. Tagesbezogene Zeit-, Erlös- und Verkaufsdaten gehören auf diese
Ebene.
## 3. Ownership- und Normalisierungsregeln
- Jede Ebene erhält eine eigene stabile Identität.
- Mehrere Durchführungstage werden nicht als wiederholte Spalten in der
Durchführung gespeichert.
- Mehrere Durchführungen werden nicht als wiederholte Spalten im Markt
gespeichert.
- Tageserlöse und Tagesverkaufszahlen werden nur am Durchführungstag erfasst.
- Aggregierte Werte für Durchführung oder Markt werden aus den untergeordneten
Durchführungstagen abgeleitet oder als klar definierte Auswertung bereitgestellt.
- MCP-Schreiboperationen müssen eindeutig an die betroffene Ebene gebunden sein.
- Fremde Modul- oder DB-Ownership wird durch diese Datenarchitektur nicht
eingeführt.
## 4. Noch offene Feldzuordnung
Die Anforderungen enthalten Felder, deren genaue Ebene noch nicht verbindlich
bestimmt ist. Dazu gehören insbesondere:
- Marktname und Marktart
- Veranstalter- und Kontaktdaten
- Anmeldung und Bestätigung
- Stand, Infrastruktur und Logistik
- Kosten und Zahlungsdaten
- Vertrag und Unterlagen
- Statuswerte
Vor der DB-Implementierung muss für jedes Feld festgelegt werden, ob es zur
Kategorie, zum Markt, zur Durchführung oder zum Durchführungstag gehört. Diese
Entscheidung darf nicht aus der Tabellenbequemlichkeit abgeleitet werden.
## 5. Offene fachliche Fragen
- Ist die Zuordnung Kategorie–Markt `1:n` oder `n:m`?
- Sind Kategorien frei erweiterbar oder gibt es eine verwaltete Liste?
- Ist eine Durchführung immer eine konkrete Teilnahme oder eine allgemeine
Veranstaltungsausgabe?
- Welche Felder gelten dauerhaft für den Markt und welche können sich je
Durchführung ändern?
- Welche Felder gelten für die gesamte Durchführung und welche ausschließlich
für einzelne Durchführungstage?
@@ -16,7 +16,31 @@ Märkten.
- Eine eigene Benutzerverwaltung ist zunächst nicht erforderlich. - Eine eigene Benutzerverwaltung ist zunächst nicht erforderlich.
- Die Anwendung soll übersichtlich und einfach bedienbar sein. - Die Anwendung soll übersichtlich und einfach bedienbar sein.
## 3. Nutzungsberechtigung ## 3. Datenhierarchie
Die Daten müssen mehrstufig abbildbar sein:
```text
Kategorie
└── Markt
└── Durchführung
└── Durchführungstag
```
- Es können beliebig viele Kategorien und Märkte existieren.
- Die genaue Kardinalität der Zuordnung zwischen Kategorien und Märkten ist noch
offen; insbesondere ist noch nicht entschieden, ob ein Markt mehreren
Kategorien gleichzeitig zugeordnet werden darf.
- Ein Markt kann beliebig viele Durchführungen enthalten.
- Eine Durchführung kann beliebig viele Durchführungstage enthalten.
- Erlös- und Verkaufsdaten werden auf Ebene des Durchführungstags erfasst und
auf Ebene der Durchführung sowie des Marktes auswertbar gemacht.
Die genaue Zuordnung aller bestehenden Markt-, Anmelde-, Kosten-, Zahlungs-,
Logistik- und Auswertungsfelder zu Kategorie, Markt, Durchführung oder
Durchführungstag ist noch separat festzulegen.
## 4. Nutzungsberechtigung
- Die Rechte zur Nutzung des Moduls werden an die Benutzeridentität geknüpft. - Die Rechte zur Nutzung des Moduls werden an die Benutzeridentität geknüpft.
- Das Modul soll ohne die restliche Anwendung an weitere Personen verkauft und - Das Modul soll ohne die restliche Anwendung an weitere Personen verkauft und
@@ -24,7 +48,7 @@ Märkten.
- Die Ownership und Ablage der Lizenz-/Entitlement-Daten ist noch nicht - Die Ownership und Ablage der Lizenz-/Entitlement-Daten ist noch nicht
entschieden und bleibt offen. entschieden und bleibt offen.
## 4. Marktarten ## 5. Marktarten
Erfassbare Marktarten: Erfassbare Marktarten:
@@ -38,7 +62,7 @@ Erfassbare Marktarten:
Die Marktart wird pro Markt ausgewählt oder ergänzt. Die Marktart wird pro Markt ausgewählt oder ergänzt.
## 5. Stammdaten pro Markt ## 6. Stammdaten pro Markt
### 5.1 Allgemeine Informationen ### 5.1 Allgemeine Informationen
@@ -110,7 +134,7 @@ verbunden werden können.
- Link zum Vertragsordner - Link zum Vertragsordner
## 6. Statusverwaltung ## 7. Statusverwaltung
Folgende Marktstatus sollen verfügbar sein: Folgende Marktstatus sollen verfügbar sein:
@@ -123,7 +147,7 @@ Folgende Marktstatus sollen verfügbar sein:
Der aktuelle Status ist in der Übersicht sofort erkennbar und manuell änderbar. Der aktuelle Status ist in der Übersicht sofort erkennbar und manuell änderbar.
## 7. Bezahlung ## 8. Bezahlung
Der Zahlungsstatus wird unabhängig vom allgemeinen Marktstatus gespeichert. Der Zahlungsstatus wird unabhängig vom allgemeinen Marktstatus gespeichert.
@@ -140,7 +164,7 @@ Zusätzliche Zahlungsinformationen:
- Bezahlter Betrag - Bezahlter Betrag
- Offener Betrag - Offener Betrag
## 8. Erlöserfassung ## 9. Erlöserfassung
Nach der Durchführung soll der Erlös pro Markt erfasst werden können. Nach der Durchführung soll der Erlös pro Markt erfasst werden können.
Bei mehrtägigen Märkten wird der Erlös je Markttag separat erfasst. Bei mehrtägigen Märkten wird der Erlös je Markttag separat erfasst.
@@ -161,7 +185,7 @@ Automatisch zu berechnen:
Die Tageswerte sollen einzeln und als Gesamtergebnis auswertbar sein. Die Tageswerte sollen einzeln und als Gesamtergebnis auswertbar sein.
## 9. Marktübersicht ## 10. Marktübersicht
Die zentrale Übersicht soll ermöglichen: Die zentrale Übersicht soll ermöglichen:
@@ -188,7 +212,7 @@ Mindestens sichtbar:
- Bezahlstatus - Bezahlstatus
- Bruttoerlös - Bruttoerlös
## 10. Intelligente Auswertungen ## 11. Intelligente Auswertungen
Das System soll später Zusammenhänge, Unterschiede und mögliche Korrelationen Das System soll später Zusammenhänge, Unterschiede und mögliche Korrelationen
zwischen Marktmerkmalen und Ergebnissen sichtbar machen. zwischen Marktmerkmalen und Ergebnissen sichtbar machen.