Mapping: Fachobjekte

Status: Entwurf

Wie werden die Fachobjekte aus 30-domain/ auf entity_type-Einträge der generischen MDM-Spec (docs/spec/30-domain-model/01-entity-type.md) abgebildet?

Konvention

entity_type.key ist lowercase, snake_case, eindeutig je Tenant. (Spec-Format: ^[a-z][a-z0-9_]*$.)
Strukturelle Felder (code, name, status) bleiben relational; Fachattribute liegen in attributes jsonb, validiert via entity_type_attribute.
Datentypen enum / multi_enum referenzieren enum_set (Codelisten), reference / multi_reference referenzieren relation_type.

Mapping-Tabelle

Fachobjekt	`entity_type.key`	Gehört zu	Bemerkung
Holding	`holding`	Organisation	typisch Singleton in Instanz
Tochtergesellschaft	`subsidiary`	Organisation
Sub-Firma	`subfirm`	Organisation	optional, selten
Externer Provider	`external_provider`	Organisation
Eigentümer (Mandant)	`owner`	Organisation	extern, Vertragspartner für Mandate. Zwingend für Mandats-Cases.
Person	`person`	Organisation	natürliche Person
Modul	`module`	Leistung	buchbares Leistungspaket (`verwaltung`, `mieterstrom`, `messdienst`, `abrechnung`, `energieberatung`, `versicherung`, `mieter_access`). Eigene Entität, weil Pricing-Konditionen + primäre Tochter modelliert werden müssen. Alternative (Codeliste) siehe Pragmatik unten.
Liegenschaft	`property`	Liegenschaft	Hauptbezugsobjekt
Gebäude	`building`	Liegenschaft
Wohneinheit	`unit`	Liegenschaft
Zähler	`meter`	Liegenschaft
Gewerk	`trade`	Leistung	Stammdatum
Bedarfsposition	`demand`	Leistung	hängt am Case
Dienstleistung	`service`	Leistung	Katalog
Material	`material`	Leistung	Katalog
Vertragsmuster	`contract_template`	Leistung
Vertrag (konkret)	`contract`	Leistung
PV-Anlage	`pv_system`	Energie
Speicher	`battery_storage`	Energie
Mieterstrom-Vertrag	`tenant_power_contract`	Energie	Spezialisierung von `contract` — als eigener `entity_type` modelliert (eigene Pflichtfelder)
Mieter-Access-Vertrag	`tenant_access_contract`	Kommunikation	perspektivisch (Modul `mieter_access`); analog zu `tenant_power_contract`
Tarif	`tariff`	Energie / Kommunikation
Case	`case`	Case-Welt
Dossier	`case_dossier`	Case-Welt	1:1 zu `case`, oder via Aggregations-Beziehung
Szenario	`scenario`	Case-Welt
Annahme	`assumption`	Case-Welt	optional eigener Typ
Snapshot	`snapshot`	Case-Welt
Modell	`model`	Modell	Berechnungslogik-Container
ModellVersion	`model_version`	Modell	mit `model` über Relation `version_of`
Parameter	`model_parameter`	Modell	optional eigener Typ
Formel	`model_formula`	Modell	optional eigener Typ
Constraint	`model_constraint`	Modell	optional eigener Typ
Testfall	`model_test_case`	Modell
Anhang / Dokument	`attachment`	Querschnitt	siehe Spec OP-40

Pragmatische Reduktion für V1

Nicht alle Sub-Typen müssen in V1 eigene entity_types sein. Pragmatik:

V1-Strategie	Begründung
`model_parameter`, `model_formula`, `model_constraint`, `model_test_case` als JSONB-Felder am `model`	reduziert Komplexität, ausreichend für Editor
`assumption` als JSONB-Feld am `scenario`	Annahmen sind eng am Szenario gebunden
`snapshot` als JSONB-Blob am `case`	Snapshots sind unveränderlich, kein eigener Lifecycle
`case_dossier` als 1:1 mit `case` mergen	erspart sinnlose Joins
`module` als eigener `entity_type` (V1-Empfehlung)	Pricing pro Modul + Verknüpfung zur primären Tochter + spätere Modul-spezifische Reports rechtfertigen den eigenen Typ. Alternative (`module_key` rein als `enum_set` an `case.module_selection`) ist nur für Prototypen sinnvoll.

Sub-Typen werden erst dann zu eigenen entity_types, wenn:

eigene Suchindizes nötig sind
eigene Permissions je Datensatz erforderlich
eigene Lifecycle-Status existieren
der Bestand pro Case > ~50 Datensätze wird

Codelisten (`enum_set`) — Auszug

`enum_set.key`	Werte (Beispiele)	Verwendet in
`subsidiary_category`	`bau`, `verwaltung`, `energie`, `versicherung`, `kommunikation`	`subsidiary.kategorie`
`trade_kind`	`dach`, `fassade`, `heizung`, `elektrik`, `pv`, `speicher`, …	`trade.kategorie`
`heating_type`	`gas`, `oel`, `waermepumpe`, `fernwaerme`, `pellet`	`building.heizungstyp`
`energy_class`	`aplus`, `a`, `b`, `c`, `d`, `e`, `f`, `g`, `h`	`building.energieausweis_klasse`
`roof_form`	`sattel`, `flach`, `pult`, `walm`, `mansarde`	`building.dachform`
`roof_orientation`	`n`, `no`, `o`, `so`, `s`, `sw`, `w`, `nw`	`building.dachausrichtung`
`meter_medium`	`strom`, `waerme`, `wasser`, `gas`	`meter.medium`
`meter_kind`	`verbrauch`, `erzeugung`, `summen`	`meter.typ`
`contract_type`	`mietvertrag`, `mieterstrom`, `wartung`, `lieferung`, `versicherung`, `dienstleistung`	`contract.vertragstyp`
`pricing_model`	`pauschal`, `pro_einheit`, `aufwand`, `mischpreis`	`service.preis_modell`
`pv_remuneration_model`	`eeg_einspeisung`, `mieterstrom`, `eigenverbrauch`, `mix`	`pv_system.vergütungsmodell`
`case_type`	`liegenschafts_bewertung`, `unit_case`, `holding_case`, `sanierungs_planung`, `mieterstrom_pruefung`, `mieter_access_pruefung`, `renditerechner`, `portfolio_optimierung`	`case.case_type`
`module_key`	`verwaltung`, `mieterstrom`, `messdienst`, `abrechnung`, `energieberatung`, `versicherung`, `mieter_access`	`module.code`, `case.module_selection_json[]`, Beziehungs-Attribut `case_selects_module.module_key`
`bestandstyp`	`mandat`, `eigenbestand`	`property.bestandstyp`
`owner_type`	`privatperson`, `weg`, `wohnungsgesellschaft`, `institutioneller_investor`, `sonstige_juristische_person`	`owner.owner_type`
`eigentumsform`	`volleigentum`, `weg`, `pacht`, `erbbaurecht`	`property.eigentumsform`
`case_status`	`draft`, `daten`, `analyse`, `entscheidung`, `freigabe`, `aktiv`, `archiv`, `cancelled`	`case.status`
`model_status`	`draft`, `review`, `released`, `produktiv`, `deprecated`, `archived`	`model.status`
`scenario_kind`	`best`, `worst`, `realistisch`, `variante`	`scenario.kategorie`
`provider_kind`	`intern`, `extern`	über Relation aufgelöst, ggf. redundantes Feld

Mapping: Fachobjekte

Konvention

Mapping-Tabelle

Pragmatische Reduktion für V1

Codelisten (enum_set) — Auszug

Verwandte Dokumente

Codelisten (`enum_set`) — Auszug