Run SheetKnowledge ModelingOntology / Knowledge Graph Modeling

Property Graph Schema Design

KomplexitätMedium

Zeit4-8 h initial, dann iterativ

Teilnehmende1-6

FormatBoth

MaturityEstablished

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenCompetency Questions

Mindestens 10 must-have-Queries als konkrete Pfade oder Aggregate liegen vor, an denen Node-, Relationship- und Index-Entscheidungen ausgerichtet werden.

Ohne: Ohne diese Queries wird das Schema generisch, Indexe fehlen an den heißen Pfaden, Performance bleibt unkalkulierbar.

Vorbereitung

Was vor Start vorliegen muss

Materialien

Whiteboard oder Diagramm-Tool (arrows.app, drawio, Cypher Workbench); Sandbox-DB (Neo4j Aura Free, Memgraph, Neptune Local); Beispieldaten-CSVs; Migrations-Tool (Liquibase Graph, Neo4j Migrations); Issue-Tracker.

Personen / Rollen

Ein Graph-Modeler (lead); ein bis zwei Engineers, die Queries später schreiben; ein Domain Expert für Begriffe und Kardinalitäten; ein Data-Source-Owner für Beispieldaten.

Vorabinfos

Use Cases und Query-Patterns; geschätzte Datenmengen (Knoten, Relationships, Wachstum); SLA für Latenz und Durchsatz; gewählter Graph Store; Quellsysteme und ETL-Lage.

Zeitbedarf

4-8 h initial, dann iterativ in Stunden-Slices

Setup

Sandbox-DB einsatzbereit. Beispieldaten in CSV. Top 10 Queries als Pseudocode-Cypher vorbereitet. Whiteboard mit Spalten: Use Case, Query, Node, Relationship, Property, Index.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche Node Labels, Relationship Types, Properties und Indexe ergeben ein Schema, das die priorisierten Queries performant beantwortet und mit dem Datenwachstum mitwächst?

Ablauf

Marker: Phase

Schritt	Dauer	Aktion	Hinweis
1Phase 1: Query-Inventar	45-60 min	Alle Use-Case-Queries als konkrete Cypher-/Gremlin-Skizzen formulieren. Pro Query: erwartete Latenz, Häufigkeit, Filterkriterien, Pfadtiefe. Top 10 priorisieren.	Wenn Queries vage bleiben („alle Beziehungen anzeigen“), zurück zur Use-Case-Ebene. Generische Queries führen zu generischen, oft falsch indizierten Schemas.
2Phase 2: Knoten und Beziehungen	60-90 min	Entitäten als Node Labels identifizieren (Singular, PascalCase). Beziehungen als gerichtete Relationship Types (UPPER_CASE, Verb). Pro Beziehung Kardinalität und Pfadrolle dokumentieren.	Wenn ein Attribut viele unique Werte hat und Filtern wichtig ist (z. B. Tags), kann es eigener Node werden statt Property. Reine Property-Filter auf Cardinality > 10k werden ohne Index langsam.
3Phase 3: Properties und Datentypen	45-60 min	Pro Node und Relationship Properties auflisten: Name, Typ (string/int/datetime/list), Pflicht/Optional, Default. Zeitliche Gültigkeit, Source, Confidence als separate Properties markieren.	Properties auf Relationships sind mächtig (z. B. weight, validFrom), aber unindiziert in vielen Engines. Wer auf Relationship-Property filtert, sollte Engine-Doku prüfen.
4Phase 4: Indexe und Constraints	30-45 min	Pro Top-Query den Startpunkt im Graph identifizieren. Indexe darauf setzen (unique constraints für IDs, range indexes für Filter, fulltext für Suche). Constraints für Datenintegrität dokumentieren.	Index ohne Query ist Overhead. Index für Query ohne Constraint ist Risiko. Mindestens jeder Top-10-Query muss einen indexgestützten Startpunkt haben.
5Phase 5: Validierung in Sandbox	60-90 min	Schema in Sandbox-DB anlegen (CREATE CONSTRAINT, CREATE INDEX). Beispieldaten importieren. Top-10-Queries laufen lassen, EXPLAIN/PROFILE prüfen. Latenz und Plan-Quality dokumentieren.	Wenn EXPLAIN AllNodesScan zeigt, fehlt Index oder Query muss umformuliert werden. Niemals ohne Plan-Check in Produktion gehen.
6Phase 6: Migrations-Script	30-45 min	Schema in Migrationsdatei festhalten (idempotent, mit Versionsnummer). Sample Queries als Test-Suite. Schema-Diagram exportieren. Beides ins Repo committen.	Schema im Diagramm ist Kommunikation, Schema in Migration ist Wahrheit. Wer nur Diagramm pflegt, hat ein Schema, das niemand reproduzieren kann.

Artefakt

Was am Ende rauskommt

Form

Repo-Verzeichnis mit Schema-Diagramm (arrows.app-Export, PNG, JSON), Node-and-Relationship-Catalog (Markdown-Tabelle), Migrations-Script (idempotent), Beispieldaten-Loader, Sample-Queries-Suite und Index-Plan mit Begründung.

Tool-Alternativen

arrows.app für Diagramme (JSON-Export)
Cypher-Workbench (Neo4j) mit Schema-Designer
drawio mit Property-Graph-Stencils
Liquibase Graph oder Neo4j Migrations für Versionierung

Versionierung / Ownership

Migrations-Files nummeriert (V001__init.cypher, V002__add_team.cypher). Diagramm-JSON neben dem Code. Schema-Version in DB als (:SchemaMeta {version: '1.2.0'}) gespeichert. Breaking Changes als Major-Increment.

canvas

Property Graph Schema Design Arbeitsvorlage

Kompakte Arbeitsvorlage für Property Graph Schema Design mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

# Property Graph Schema Design Canvas

## Kontext

Wofür wird die Methode eingesetzt?

## Kernfrage

Welche Frage soll am Ende beantwortet sein?

## Input

Welche Daten, Beobachtungen oder Materialien liegen vor?

## Arbeitsfläche

- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:

## Ergebnisartefakte
- Schema Diagram:
- Node and Relationship Catalog:
- Index Plan:
- Migration Scripts:
- Sample Queries:

## Offene Fragen

- ...

## Nächster Schritt

Owner, Datum, Erfolgssignal.

Beispielausgabe

Konkret gefülltes Szenario

property-graph-schema-design-beispiel.md

markdown

## Property Graph Schema — Service Dependency Graph (v0.4, 18.05.2026)

**Top-Queries** (Auszug):
- Q1: Direkte Downstream-Abhängigkeiten eines Service. Latenzziel < 50 ms.
- Q2: Transitive Abhängigkeiten bis Tiefe 3. < 200 ms.
- Q5: Alle Services eines Teams mit ihrem DB-Cluster. < 100 ms.

**Nodes**:
- `Service {name (unique), tier, status, createdAt}`
- `Team {name (unique), email}`
- `Database {name (unique), type, region}`

**Relationships**:
- `(Service)-[:DEPENDS_ON {weight, since}]->(Service)`
- `(Team)-[:OWNS]->(Service)`
- `(Service)-[:USES]->(Database)`

**Indexe**:
- UNIQUE CONSTRAINT auf Service.name, Team.name, Database.name
- RANGE INDEX auf Service.tier (Q3 nutzt)

**Plan-Check Q2** (Tiefe 3): NodeIndexSeek + VarLengthExpand, 45 ms bei 12k Knoten / 38k Edges. OK.

**Migration**: V004__add_database.cypher. Schema-Version in DB auf 0.4 aktualisiert.

Was tun

Tooling wie Liquibase Graph oder Neo4j Migrations einsetzen. Idempotente Cypher-Files mit Versionsnummer. CI rollt Migration in Test- und Staging-DB.

Abbruchkriterien

Done-Signale, in unter einer Minute prüfbar

Keine konkreten Query-Pattern formulierbar, Schema-Design wäre Spekulation.

Datenmengen so klein (< 10k Knoten) und einfach, dass relationales Schema effizienter wäre.

Keine Sandbox-DB verfügbar, Plan-Check nicht durchführbar.

Datenmodell ist stark strukturiert und gleichförmig, RDF/SHACL würde Constraints und Reasoning besser abbilden.

Engine-Wahl ist nicht getroffen, Index- und Property-Modell hängt zu stark von Engine ab.

Quellsysteme oder ETL fehlen, Beispieldaten lassen sich nicht beschaffen, Validierung unmöglich.

Run Sheet durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.

Zum Steckbrief Weitere Methoden