EA-RELATIONSHIP-TYPE-CATALOG-001

Katalog der Beziehungstypen der Unternehmensarchitektur#

Übersicht · 2: zweite Ebene · Ziehen/Klicken: navigieren

Grundvertrag#

Eine verbindet genau ein Quellelement mit genau einem Zielelement. Ihre Semantik wird ausschließlich durch eine stabile Relationship-Type-Referenz bestimmt. Freitext, Dateilinks, Linien oder Namensvarianten erzeugen keinen parallelen Typkatalog.

Eine Relationship besitzt mindestens Quelle, Ziel, Typ, Status und Revision. Eine stabile eigene Identität ist erforderlich, wenn sie eigene , Historie, Lifecycle, Governance, Berechtigungen oder direkte Referenzierbarkeit benötigt.

Übernommenes Kernvokabular#

Schlüssel		typische Kardinalität
`contains`	Quelle enthält Ziel	1:n oder n:m
`belongs_to`	Quelle gehört fachlich zu Ziel	n:1 oder n:m
`references`	Quelle verweist auf Ziel	n:m
`defines`	Quelle definiert Ziel	1:n
`classifies_as`	Quelle ist durch Ziel klassifiziert	n:m
`is_of_type`	Quelle besitzt primären Typ Ziel	n:1
`depends_on`	Quelle hängt von Ziel ab	n:m
`uses`	Quelle verwendet Ziel	n:m
`contributes_to`	Quelle trägt zur Realisierung des Ziels bei	n:m
`is_realized_by`	inverse Sicht auf eine Realisierung	n:m
`documents`	Quelle dokumentiert Ziel	n:m
`tests`	Quelle testet Ziel	n:m
`replaces`	Quelle ersetzt Ziel	n:m
	Quelle löst Ziel in einem ausdrücklich bezeichneten Gültigkeitskontext verbindlich ab; das Ziel bleibt historisch referenzierbar	n:m
`derives_from`	Quelle ist fachlich aus Ziel abgeleitet	n:m
`justifies`	Quelle begründet Ziel	n:m
`requires`	Quelle fordert Ziel verbindlich	n:m
`constrains`	Quelle begrenzt Ziel	n:m
`informs`	Quelle liefert Erfahrung, Context oder für Ziel	n:m
`refines`	Quelle präzisiert Ziel	n:m
`conflicts_with`	Quelle steht mit Ziel in fachlichem Konflikt	n:m
`specializes`	Quelle ist eine engere fachliche Spezialisierung von Ziel	n:m
`composed_of`	Quelle besteht fachlich aus Zielen	1:n oder n:m
`projects`	Quelle projiziert Ziel	n:m
`materializes`	Quelle materialisiert Ziel	n:m
`maps_to`	Quelle wird fachlich oder technisch auf Ziel abgebildet	n:m
`owned_by`	Quelle besitzt fachlichen Owner Ziel	n:1 oder n:m
`has_dimension_value`	Quelle verwendet Dimensionswert Ziel	n:m
`has_attribute_definition`	Typ oder Scope erlaubt Attributdefinition Ziel	n:m
`allows_relationship_type`	Typ oder Scope erlaubt Relationship Type Ziel	n:m

Minimale Erweiterungen#

Schlüssel	Bedeutung	Notwendigkeit	Abgrenzung
`valid_during`	Quelle gilt innerhalb des als Ziel referenzierten Zeit- oder Gültigkeitscontexts	Gültigkeit muss als Relationship ausdrückbar sein, ohne sie in Dateinamen oder Freitext zu verstecken	keine bloße zeitliche Reihenfolge
`precedes`	Quelle liegt in der fachlich relevanten zeitlichen Ordnung vor Ziel	zeitliche Abfolge ist von Ableitung und Ablösung verschieden	keine Kausalität, Ableitung oder Ersetzung
`evolves_from`	Quelle ist eine weiterentwickelte Form von Ziel, ohne Ziel zwingend abzulösen	Evolution kann koexistierende Gültigkeitsstände verbinden	`supersedes` bleibt verbindliche Ablösung; `derives_from` bleibt allgemeine Ableitung

Weitere neue Typen sind in SE-0017 nicht begründet.

Namensnormalisierung#

Leerzeichen, Bindestriche, sprachliche Anzeigenamen oder inverse Lesesichten ändern die Semantik nicht. Beispielsweise werden depends on, depends-on und depends_on auf depends_on normalisiert. Eine inverse Sicht ist keine zweite zwingend gespeicherte Wahrheit.

Definition eines Relationship Types#

Jeder Typ besitzt mindestens stabilen technischen Schlüssel, fachliche Beschreibung, Richtung, erlaubte Quell- und Zieltypen, Kardinalität, Zyklusregel, Symmetrie- und Inversenregel, gegebenenfalls belegte Transitivität sowie Lifecycle, Version, Owner und lokalisierbare Anzeigenamen.

Validierung#

Vor dem Speichern werden Existenz von Quelle, Ziel und Typ, zulässige Endpunkttypen, Kardinalität, Zyklusregel, Berechtigung, Revision und Gültigkeit im aktuellen Scope geprüft. Hierarchie entsteht aus typisierten Beziehungen und deren Regeln, nicht aus einer parallelen parent_id-Semantik.