Beziehungen zwischen Fachobjekten

Status: Entwurf

Wer hängt an wem? Welche Kardinalitäten? Welche Löschregeln?

Hauptbeziehungen

Die vollständigen Beziehungen mit allen Kardinalitäten und Unterstrukturen (Gebäude → Wohneinheit → Zähler, Mietvertrag, PV-Anlage → Speicher usw.) sind in der Detailtabelle unten und in den jeweiligen Fachobjekt-Dokumenten beschrieben.

Übersicht der Relationstypen

(Gemappt auf relation_type der Spec — siehe ../70-mapping-to-spec/02-relationen-zu-relation-types.md)

Relation	Quelle (from)	Ziel (to)	Kardinalität	Delete-Policy	Bemerkung
holding_has_subsidiary	Holding	Tochtergesellschaft	1:n	restrict	Tochter darf nicht Holding-los werden
subsidiary_has_subfirm	Tochtergesellschaft	Sub-Firma	1:n	restrict
subsidiary_provides_service	Tochtergesellschaft	Dienstleistung	1:n	detach	Dienstleistung kann ohne Tochter sein
subsidiary_provides_module	Tochtergesellschaft	Modul	1:n	restrict	jedes Modul hat genau eine primäre Tochter (z. B. AHI ↔ verwaltung); inverse Sicht von Modul.primary_subsidiary
owner_owns_property	Eigentümer	Liegenschaft	1:n	restrict	Eigentümer-Beziehung. Eigentümerwechsel: neue Beziehung mit neuer Periode, alte als historisch markieren
property_booked_module	Liegenschaft	Modul	n:m	detach	aktuell aktive Module pro Liegenschaft. Beziehungs-Attribute: seit, bis, case_id (Case, durch den das Modul gebucht wurde)
case_mandated_by	Case	Eigentümer	n:1	restrict	Mandant des Cases. Pflicht bei case_type=liegenschafts_bewertung/unit_case; leer bei reinem eigenbestand
case_selects_module	Case	Modul	n:m	cascade	Modul-Konfiguration des Cases. Beziehungs-Attribut: is_primary (bei unit_case markiert das eine Modul, das die Tochter erbringt)
liegenschaft_has_building	Liegenschaft	Gebäude	1:n	cascade	Gebäude ohne Liegenschaft sinnlos
building_has_unit	Gebäude	Wohneinheit	1:n	cascade
building_has_pv	Gebäude	PV-Anlage	1:n	restrict	PV bleibt eigenständig auswertbar
pv_has_storage	PV-Anlage	Speicher	1:0..1	detach
unit_has_meter	Wohneinheit	Zähler	1:n	detach
pv_has_meter	PV-Anlage	Zähler	1:n	detach
unit_has_rent_contract	Wohneinheit	Mietvertrag	1:0..1	restrict	Aktiver Mietvertrag — nur einer aktiv
unit_has_tenant_power	Wohneinheit	Mieterstrom-Vertrag	1:0..1	restrict
unit_has_tenant_access	Wohneinheit	Mieter-Access-Vertrag	1:0..1	restrict	perspektivisch (Modul mieter_access)
subsidiary_responsible_for_property	Tochtergesellschaft	Liegenschaft	n:m	detach	mehrere Töchter aktiv pro Liegenschaft
provider_offers_service	Provider	Dienstleistung	n:m	detach	gleiche Dienstleistung mehrere Anbieter
provider_offers_material	Provider	Material	n:m	detach
service_uses_material	Dienstleistung	Material	n:m	detach
case_targets_property	Case	Liegenschaft	1:1	restrict
case_belongs_to_subsidiary	Case	Tochtergesellschaft	n:1	restrict	bei unit_case
case_uses_model	Case	Modell	n:1	restrict
case_aggregates_unit_case	Case (holding_case)	Case (unit_case)	1:n	restrict	Aggregations-Bezug
case_has_scenario	Case	Szenario	1:n	cascade
case_has_demand	Case	Bedarfsposition	1:n	cascade
demand_targets_gewerk	Bedarfsposition	Gewerk	n:1	restrict
demand_assigns_service	Bedarfsposition	Dienstleistung	n:0..1	detach	optional — kann auch nur Gewerk sein
demand_assigns_material	Bedarfsposition	Material	n:0..n	detach	mehrere Materialien je Bedarf
demand_assigns_provider	Bedarfsposition	Provider	n:0..1	detach
contract_between	Vertrag	Provider × Empfänger	siehe unten	restrict

Vertrag — n-äre Beziehung

Ein Vertrag hat mindestens drei strukturelle Beteiligte:

• Provider (Anbieter, intern oder extern)
• Empfänger / Kunde (Holding / Tochter / Liegenschaft / Wohneinheit / Mieter)
• Vertragsgegenstand (Liegenschaft / Wohneinheit / PV-Anlage / Material-Lieferung / Dienstleistung)

Im Datenmodell der Spec wird das aufgelöst über mehrere binäre Relationen (relation_type ist im aktuellen Spec-Stand binär — siehe docs/spec/90-governance/03-open-questions.md OP-13a für n-äre Relationen). Pragma: Vertrag selbst ist eine Entity, die FK-/Relations-Felder zu den Beteiligten trägt.

internal_to_holding als Aggregations-Hinweis

Verträge zwischen zwei Töchtern derselben Holding bekommen internal_to_holding=true. Der Aggregator (UC-02) eliminiert solche Posten in der Holding-Sicht.

Verwandte Dokumente

• 02-objects-liegenschaft.md ff. — Detail je Objekt
• ../70-mapping-to-spec/02-relationen-zu-relation-types.md — Mapping
• docs/spec/90-governance/03-open-questions.md OP-13a — Kardinalitäts-Constraints