From 5f6806ab33fa75432a898694765074274453a30e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mathias=20Gla=CC=88ser?= Date: Fri, 18 Sep 2026 19:33:28 +0200 Subject: [PATCH] Erweitere Marktmanagement-Datenhierarchie --- docs/modules/market_management/README.md | 1 + .../market_management_data_architecture.md | 82 +++++++++++++++++++ .../market_management_requirements.md | 40 +++++++-- 3 files changed, 115 insertions(+), 8 deletions(-) create mode 100644 docs/modules/market_management/data/market_management_data_architecture.md diff --git a/docs/modules/market_management/README.md b/docs/modules/market_management/README.md index 6fc7ddb..9bdd22e 100644 --- a/docs/modules/market_management/README.md +++ b/docs/modules/market_management/README.md @@ -52,6 +52,7 @@ dokumentiert. ## Dokumente - [Anforderungsprofil](requirements/market_management_requirements.md) +- [Datenarchitektur](data/market_management_data_architecture.md) - Prozessdokumente werden unter `processes/main/` und `processes/sub_processes/` angelegt, sobald die fachlichen Prozesse explizit definiert sind. diff --git a/docs/modules/market_management/data/market_management_data_architecture.md b/docs/modules/market_management/data/market_management_data_architecture.md new file mode 100644 index 0000000..af1422c --- /dev/null +++ b/docs/modules/market_management/data/market_management_data_architecture.md @@ -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? diff --git a/docs/modules/market_management/requirements/market_management_requirements.md b/docs/modules/market_management/requirements/market_management_requirements.md index 3f61457..453e9b7 100644 --- a/docs/modules/market_management/requirements/market_management_requirements.md +++ b/docs/modules/market_management/requirements/market_management_requirements.md @@ -16,7 +16,31 @@ Märkten. - Eine eigene Benutzerverwaltung ist zunächst nicht erforderlich. - 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. - 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 entschieden und bleibt offen. -## 4. Marktarten +## 5. Marktarten Erfassbare Marktarten: @@ -38,7 +62,7 @@ Erfassbare Marktarten: Die Marktart wird pro Markt ausgewählt oder ergänzt. -## 5. Stammdaten pro Markt +## 6. Stammdaten pro Markt ### 5.1 Allgemeine Informationen @@ -110,7 +134,7 @@ verbunden werden können. - Link zum Vertragsordner -## 6. Statusverwaltung +## 7. Statusverwaltung 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. -## 7. Bezahlung +## 8. Bezahlung Der Zahlungsstatus wird unabhängig vom allgemeinen Marktstatus gespeichert. @@ -140,7 +164,7 @@ Zusätzliche Zahlungsinformationen: - Bezahlter Betrag - Offener Betrag -## 8. Erlöserfassung +## 9. Erlöserfassung 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. @@ -161,7 +185,7 @@ Automatisch zu berechnen: Die Tageswerte sollen einzeln und als Gesamtergebnis auswertbar sein. -## 9. Marktübersicht +## 10. Marktübersicht Die zentrale Übersicht soll ermöglichen: @@ -188,7 +212,7 @@ Mindestens sichtbar: - Bezahlstatus - Bruttoerlös -## 10. Intelligente Auswertungen +## 11. Intelligente Auswertungen Das System soll später Zusammenhänge, Unterschiede und mögliche Korrelationen zwischen Marktmerkmalen und Ergebnissen sichtbar machen.