System-Step 5 von 9
Graphschema für die Umsetzung spezifizieren
Aus dem fachlichen Graphfragment eine technische Vorgabe für Labels, Beziehungstypen, Pflichtfelder und Belege ableiten.
Was du mitnimmst
Aus dem fachlichen Graphfragment wird eine Umsetzungsspezifikation, wenn Labels, Beziehungstypen, Pflichtfelder und Belege eindeutig benannt sind.
Systemziel
Was hier geklärt wird
Du spezifizierst, wie Knoten, Kanten, Pflichtfelder und Belege in der Umsetzung aussehen.
Kontext
Die Architekturfrage
Die Architekturfrage lautet: Wie muss das Graphschema aussehen, damit Ingestion, Abfrage und Quellenbezug dieselbe Struktur verwenden?
Für den Mini-Use-Case bedeutet das: Projekt, System, Team, Richtlinie und Pflicht bekommen technische Knotenlabels. Die fachlichen Beziehungen bekommen stabile, einheitliche Beziehungstypen: USED_BY (System → Projekt), OWNED_BY (Projekt → Team) und DEFINES_OBLIGATION_FOR (Richtlinie → System). Jede wichtige Beziehung bekommt eine Referenz auf Quelle, Abschnitt, Version und Gültigkeit.
Zusätzlich legst du Eindeutigkeitsregeln fest: Ein System wie CRM braucht eine stabile ID. Ein Projekt wie Projekt Alpha braucht ebenfalls eine stabile ID. Dadurch kann die Ingestion denselben Knoten wiederfinden, statt Dubletten zu erzeugen.
Prinzip
Architekturprinzip
Übersetze fachliche Beziehungen in eine technische Schreibform.
Der Graph Builder braucht eine klare Vorgabe: Welches Objekt wird ein Knoten? Welche Beziehung wird eine Kante? Welche Eigenschaften müssen gesetzt werden? Wo hängt der Beleg?
Diese Spezifikation verbindet Phase 2 mit der Implementierung. Das fachliche Modell bleibt verständlich, und die technische Umsetzung bekommt eindeutige Namen, Pflichtfelder und Belegverweise.
Systementwicklung
Systembaustein
| Entwurfsentscheidung | Beispiel | Wofür es gebraucht wird |
|---|---|---|
| Knotenlabel | System, Projekt, Team, Richtlinie, Pflicht | Graph Builder schreibt in klare Zielklassen |
| Beziehungstyp | USED_BY, OWNED_BY, DEFINES_OBLIGATION_FOR | Queries können stabile Pfade abfragen |
| Pflichtfelder | id, name, source_ref, valid_from | Knoten und Kanten bleiben wiederauffindbar |
| Belegreferenz | source_ref, section_ref, statement_id | Antworten können Quellen nennen |
| Eindeutigkeitsregel | System.id ist eindeutig | Ingestion erzeugt keine Dubletten |
Der Systembaustein ist eine Graphschema-Spezifikation. Sie sagt dem Umsetzungsteam, welche Labels, Beziehungstypen, Eigenschaften und Belegverweise der Graph Builder schreiben muss.
graph-schema.cyphercypher
CREATE CONSTRAINT system_id IF NOT EXISTS
FOR (s:System) REQUIRE s.id IS UNIQUE;
CREATE CONSTRAINT project_id IF NOT EXISTS
FOR (p:Project) REQUIRE p.id IS UNIQUE;
// Beziehungstyp: (:System)-[:USED_BY {source_ref, valid_from}]->(:Project)Abwägen
Trade-off
Was wird einfacher, was schwieriger?
Die Entscheidung: Du spezifizierst das Graphschema vor dem ersten vollständigen Import.
Die Konsequenz: Der Aufbau wird langsamer, weil Labels, Beziehungstypen, Pflichtfelder und Eindeutigkeitsregeln zuerst festgelegt werden. Dafür schreiben Parser, Extractor und Graph Builder später in dieselbe Struktur.
Ein schneller Start ohne Schema erzeugt rasch viele Knoten und Kanten. Die spätere Abfrage wird dadurch schwieriger, wenn dieselbe Beziehung unterschiedlich benannt wird oder Belege an verschiedenen Stellen liegen.
Fehlerbild
Typischer Baufehler
Worauf du achten musst
Die typische Falle: Der erste Graph Builder schreibt die Beziehung so, wie sie gerade aus der Quelle kommt. Einmal heißt sie "uses", einmal "nutzt", einmal "depends_on".
Das funktioniert in der Demo, bis eine Query alle Projekte zu CRM finden soll. Dann muss die Abfrage mehrere Schreibweisen kennen oder übersieht einen Teil des Graphen.
Lege die Schreibform fest: Beziehungstyp, Richtung, Pflichtfelder und Belegreferenz. Dann können Ingestion und Query dieselbe Struktur nutzen.
Prüfen
Woran du es erkennst
Prüfpunkt
Du erkennst eine brauchbare Graphschema-Spezifikation daran, dass ein Entwickler daraus eine Schreiboperation und eine Query ableiten kann.
Üben
Mini-Aufgabe
Nutze den Mini-Use-Case: In einem Abschnitt steht "Projekt Alpha nutzt CRM". Formuliere die technische Schreibform für Knoten, Kante und Beleg.
Musterlösung
- 1Projekt Alpha wird als Knoten mit Label Projekt und stabiler ID geschrieben.
- 2CRM wird als Knoten mit Label System und stabiler ID geschrieben.
- 3Die Kante lautet USED_BY und führt von CRM zu Projekt Alpha.
- 4Die Kante trägt eine Belegreferenz auf Quelle, Abschnitt, Version und Gültigkeit.
So kann die Ingestion die Beziehung schreiben und die Query später denselben Pfad zuverlässig finden.
Reflektieren
Selbsttest
1.Was ist ein Knotenlabel?
Ein Knotenlabel ist die technische Klasse eines Knotens, etwa System, Projekt, Team, Richtlinie oder Pflicht.
2.Was ist ein Beziehungstyp?
Ein Beziehungstyp ist der stabile technische Name einer Kante, etwa USED_BY oder OWNED_BY.
3.Warum braucht eine Kante einen Beleg?
Der Beleg zeigt, aus welcher Quelle, welchem Abschnitt und welcher Version die Beziehung stammt.
Kernaussage
Aus dem fachlichen Graphfragment wird eine Umsetzungsspezifikation, wenn Labels, Beziehungstypen, Pflichtfelder und Belege eindeutig benannt sind.