methodatlas
Session Builder

Meine Session planen

Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.

Methoden-Session4-8 h initial, dann iterativ in Stunden-SlicesWorkshop oder asyncSchema Diagram

Session: Property Graph Schema Design

Der Plan übersetzt die Methode in einen konkreten moderierten Arbeitsblock. Die Eingaben fließen direkt in Session Brief und Arbeitsartefakt.

Automatisch abgeleitet

Methoden-Session mit 1-6. Der Plan nutzt die vorhandene Methodenlogik und das Runsheet.

Runsheet
Beteiligungslogik
Teamrunde, gemeinsames Arbeiten und Alignment

Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

Ergebnislogik
Artefakt fertigstellen

Die Session arbeitet direkt auf Schema Diagram hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

  1. 1

    Phase 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. Hinweis: Wenn Queries vage bleiben („alle Beziehungen anzeigen“), zurück zur Use-Case-Ebene. Generische Queries führen zu generischen, oft falsch indizierten Schemas.

    FacilitatorSchema Diagram
  2. 2

    Phase 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. Hinweis: 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.

    FacilitatorNode and Relationship Catalog
  3. 3

    Phase 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. Hinweis: 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.

    FacilitatorIndex Plan
  4. 4

    Phase 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. Hinweis: Index ohne Query ist Overhead. Index für Query ohne Constraint ist Risiko. Mindestens jeder Top-10-Query muss einen indexgestützten Startpunkt haben.

    FacilitatorMigration Scripts
  5. 5

    Phase 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. Hinweis: Wenn EXPLAIN AllNodesScan zeigt, fehlt Index oder Query muss umformuliert werden. Niemals ohne Plan-Check in Produktion gehen.

    FacilitatorSample Queries
  6. 6

    Phase 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. Hinweis: Schema im Diagramm ist Kommunikation, Schema in Migration ist Wahrheit. Wer nur Diagramm pflegt, hat ein Schema, das niemand reproduzieren kann.

    OwnerSchema Diagram
  7. 7

    Artefakt veröffentlichen

    10 min

    Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.

    OwnerSchema Diagram
Nutzbares Artefakt

Session Brief

Für Einladung, Board, Ticket, PR-Beschreibung oder Workshop-Notiz.

session-brief.md

Session Brief: Property Graph Schema Design

Ziel

Artefakt: Schema Diagram

Arbeitsfrage

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

Kontext

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.

Setup

  • Format: Methoden-Session
  • Dauer: 4-8 h initial, dann iterativ in Stunden-Slices
  • Modus: Workshop oder async
  • Teilnehmende: 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.
  • Owner: Ein Graph-Modeler (lead)
  • Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
  • Ergebnislogik: Artefakt fertigstellen

Beteiligungslogik

Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

Ergebnislogik

Die Session arbeitet direkt auf Schema Diagram hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

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.

Vorbereitung

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

Agenda

  1. Phase 1: Query-Inventar (45-60 min) Owner: Facilitator Aktion: Alle Use-Case-Queries als konkrete Cypher-/Gremlin-Skizzen formulieren. Pro Query: erwartete Latenz, Häufigkeit, Filterkriterien, Pfadtiefe. Top 10 priorisieren. Hinweis: Wenn Queries vage bleiben („alle Beziehungen anzeigen“), zurück zur Use-Case-Ebene. Generische Queries führen zu generischen, oft falsch indizierten Schemas. Output: Schema Diagram

  2. Phase 2: Knoten und Beziehungen (60-90 min) Owner: Facilitator Aktion: Entitäten als Node Labels identifizieren (Singular, PascalCase). Beziehungen als gerichtete Relationship Types (UPPER_CASE, Verb). Pro Beziehung Kardinalität und Pfadrolle dokumentieren. Hinweis: 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. Output: Node and Relationship Catalog

  3. Phase 3: Properties und Datentypen (45-60 min) Owner: Facilitator Aktion: Pro Node und Relationship Properties auflisten: Name, Typ (string/int/datetime/list), Pflicht/Optional, Default. Zeitliche Gültigkeit, Source, Confidence als separate Properties markieren. Hinweis: 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. Output: Index Plan

  4. Phase 4: Indexe und Constraints (30-45 min) Owner: Facilitator Aktion: 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. Hinweis: Index ohne Query ist Overhead. Index für Query ohne Constraint ist Risiko. Mindestens jeder Top-10-Query muss einen indexgestützten Startpunkt haben. Output: Migration Scripts

  5. Phase 5: Validierung in Sandbox (60-90 min) Owner: Facilitator Aktion: 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. Hinweis: Wenn EXPLAIN AllNodesScan zeigt, fehlt Index oder Query muss umformuliert werden. Niemals ohne Plan-Check in Produktion gehen. Output: Sample Queries

  6. Phase 6: Migrations-Script (30-45 min) Owner: Owner Aktion: Schema in Migrationsdatei festhalten (idempotent, mit Versionsnummer). Sample Queries als Test-Suite. Schema-Diagram exportieren. Beides ins Repo committen. Hinweis: Schema im Diagramm ist Kommunikation, Schema in Migration ist Wahrheit. Wer nur Diagramm pflegt, hat ein Schema, das niemand reproduzieren kann. Output: Schema Diagram

  7. Artefakt veröffentlichen (10 min) Owner: Owner Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen. Output: Schema Diagram

Abschluss

  • Ergebnisartefakt aktualisieren: Schema Diagram
  • Ablageort, Version und Review-Empfänger festlegen.
  • Owner, nächster Schritt und Reviewtermin festlegen.
Nutzbares Artefakt

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

arbeitsartefakt.md

Schema Diagram: Property Graph Schema Design

Arbeitsfrage

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

Kontext

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.

Beteiligte

  • Owner: Ein Graph-Modeler (lead)
  • Teilnehmende: 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.

Input

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.

Vorlage

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.

Fertigstellungscheck

  • Schema Diagram ist vollständig genug für Review:
  • Ablageort:
  • Version / Status:
  • Review durch:
  • Nächster Schritt:

Nächster Schritt

  • Ergebnis prüfen
  • offene Fragen markieren
  • Review oder Entscheidung terminieren
Vorlagenbasis

Property Graph Schema Design Arbeitsvorlage

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

property-graph-schema-design-working-template.md

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.

Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Schema Diagram.
  • 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.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet