Meine Session planen

# 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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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.

# 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