Fachlicher Entitäten-Katalog

Status: lebende Liste · wird laufend ergänzt, sobald neue fachliche Typen auftauchen

Dieses Dokument hält die fachlichen Entitätstypen und ihre Beziehungen außerhalb der technischen Spec fest. Es ist Quelle für Diskussion, Schulung und spätere Mappings auf das DDM_ENTITY_TYPE-Modell. Es gilt nicht als Implementierungs-Vorgabe — die technische Wahrheit ist docs/spec/.

Wenn neue Typen oder Beziehungen genannt werden, wird hier zuerst aktualisiert; die Spec folgt nach. Format: Tabellen je Entität / Beziehung.

Bisheriger Stand (V0)

Entitätstypen

Typ	Key (geplant)	Zweck	Wichtige Attribute (Vorschlag)
Owner	owner	Eigentümer / Mandant der Liegenschaft. Extern, gehört nicht zur Holding. Vertragspartner der Holding für ein Modulbündel.	code, name, owner_type, legal_form, tax_id, register_no, mandant_seit
Company	company	Unternehmen / Konzern. Kann Tochter-Unternehmen besitzen (Self-Relation). Holding + Töchter.	code, name, legal_form, tax_id, parent_company_id
Address	address	Postanschrift. Eigene Entität, weil Mehrfachnutzung möglich (Owner, Company-HQ, Property-Standort, ggf. Employee).	street, postal_code, city, country, type (z. B. billing/shipping/site)
Employee	employee	Mitarbeiter eines Unternehmens.	code, first_name, last_name, email, role
Module	module	Buchbares Leistungspaket der Holding. Codeliste-artig: verwaltung, mieterstrom, messdienst, abrechnung, energieberatung, versicherung, mieter_access. Eigenständig buchbar, keine Pflichtmodule.	code, name, primary_subsidiary, description, pricing_default
Offer	offer	Angebot, das ein Unternehmen erbringen kann. Subtyp über Attribut kind ∈ {service, material} (offen, ggf. später als zwei eigenständige Entitätstypen mit gemeinsamer Relation).	code, name, kind, unit, price, module_ref (für welches Modul nutzbar)
Property	property	Liegenschaft / Immobilie, an der Module erbracht werden. Eigentümer-bezogen.	code, name, property_type, area_sqm, year_built, bestandstyp, eigentuemer_id
Case	case	Mandats-Vorgang: Modulbündel für eine Liegenschaft eines Eigentümers konfigurieren und bewerten. Klammert Modulauswahl, Offers, Beteiligte, Status.	code, name, case_type, status, owner_id, module_selection_json, started_at, target_completion_at

Beziehungstypen

Beziehung	From	To	Kardinalität	Delete-Policy (Vorschlag)	Bemerkung
company_has_subsidiary	company	company	1:N (Self)	restrict	Mutter → Tochter. Wurzel-Unternehmen haben kein Parent. Zykluserkennung im Service.
company_employs	company	employee	1:N	restrict	Employee gehört zu genau einem Unternehmen (default). N:M später möglich, falls geteilte Mitarbeiter.
company_provides_offer	company	offer	1:N	restrict	Offers gehören zu einem anbietenden Unternehmen.
company_has_address	company	address	N:M	detach	Eine Firma kann mehrere Adressen haben (HQ, Filialen, Lager). Eine Adresse kann theoretisch von mehreren Firmen geteilt werden.
property_located_at	property	address	1:1	restrict	Jede Liegenschaft hat genau eine Adresse.
property_has_case	property	case	1:N	archive_only	Cases sind audit-relevant (Verträge, Genehmigungen) → werden archiviert, nie gelöscht.
case_uses_offer	case	offer	N:M	detach	Ein Case nutzt mehrere Offers; ein Offer kann in mehreren Cases auftauchen.
case_processed_by	case	company	N:1	restrict	Verarbeitende Tochter / Holding der Workbench. Bei unit_case ist das die jeweils erbringende Tochter.
case_mandated_by	case	owner	N:1	restrict	Mandant / Eigentümer, für den der Case läuft. Pflicht bei case_type=liegenschafts_bewertung, leer bei reinem eigenbestand.
owner_owns_property	owner	property	1:N	restrict	Eigentümer-Beziehung. Eigentümerwechsel = neue Beziehung + neue Periode (nicht Update).
property_booked_module	property	module	N:M	detach	Pro Liegenschaft die aktuell aktiven Module. Beziehungs-Attribute: seit, bis, case_id (Case, der das Modul gebucht hat).
case_selects_module	case	module	N:M	cascade	Ein Case konfiguriert genau die hier gelisteten Module. Beziehungs-Attribut: is_primary (für unit_case: das eine, das die Tochter erbringt).

Cardinalitäts-Constraints in unserem DDM_RELATION_TYPE-Modell sind aktuell nicht hart erzwungen (siehe OP-13a) — Service-Layer setzt sie durch.

Offene Punkte am Katalog

1. Offer-Subtypen: Diskriminator-Attribut (kind) vs. eigene Entitätstypen service / material mit gemeinsamer Relation. Diskriminator ist einfacher in V1, Trennung könnte später nötig werden, wenn Service- und Material-spezifische Attributsätze stark divergieren.
2. Address-Verwendung: Soll Employee ebenfalls eine Adresse tragen können? Geteilte Adresse mit Company oder dediziert?
3. Case-Status-Workflow: Welche Status sind erlaubt? (draft/approved/active/closed …) — erst zu klären, dann in entity_status oder als Custom-Attribut modellieren.
4. Property-Detail: Welche Property-Typen (Wohngebäude, Gewerbe, Mischnutzung, Grundstück) und welche Pflicht-Attribute?
5. Bewirtschaftung nach Renovierung: gehört das in den Case (Status-Phase) oder in eine zweite Entität operation_period?
6. Eigentümer der Property: separate Beziehung property_owned_by → company? → geklärt: owner ist eigene Entität (kein company), Beziehung owner_owns_property (1:n).
7. Module als Entität vs. Codeliste: V1-Empfehlung — Module als eigener entity_type mit Pricing/Konditionen-Attributen; Modul-Auswahl pro Case als case_selects_module-Relation. Alternative: nur als enum_set an case.module_selection. Diskussion offen, Eintrag in 80-open-questions/ sobald nötig.
8. Modulwechsel-Audit: Wenn ein Eigentümer ein Modul nachbucht oder kündigt — entsteht ein neuer Case, oder wird der bestehende Case erweitert? Empfehlung: neuer Folge-Case (siehe UC-01 Schritt 13), ursprünglicher Case unverändert im Archiv.
9. Eigenbestand vs. Mandat: bestandstyp an property ist ausreichend; eine eigene Entität ist nicht nötig. Aggregation (UC-02) muss bei eigenbestand die Eigentümer-Sicht der Holding-Sicht eliminieren.

Wachstum

Wenn neue Typen aufkommen (z. B. tenant_party, contract, cost_center, inspection):

1. Neue Zeile in der Entitätstypen-Tabelle.
2. Beziehung in der Beziehungstypen-Tabelle dokumentieren (mit Kardinalität + Delete-Policy).
3. Diskussion / offene Fragen in „Offene Punkte am Katalog” sammeln, bis die Modellierung steht.
4. Erst danach das technische DDM_ENTITY_TYPE-Seed in der Spec ergänzen (Schema und Konventionen).

Mapping in das technische Modell

Jede Zeile in „Entitätstypen” wird beim Migrate als DDM_ENTITY_TYPE (per-tenant, siehe OP-28a) angelegt; die Pflicht-/Vorschlagsattribute als DDM_ENTITY_TYPE_ATTRIBUTE. Beziehungen werden als DDM_RELATION_TYPE mit from_entity_type_id / to_entity_type_id angelegt.

Bidirektionalität (z. B. „Property hat Case” + „Case betrifft Property”) wird per Service-Layer als zwei DDM_ENTITY_RELATION-Zeilen geschrieben (Lese-Pfad-optimiert, siehe OP-13).