SQL für Analysten: fünf Muster, die sich fast immer lohnen

Muster 1: Filtern und Eingrenzen mit WHERE

Fast jede Analyse beginnt mit einer Eingrenzung. Du möchtest nicht immer alle Daten betrachten, sondern nur einen relevanten Ausschnitt: bestimmte Zeiträume, Kundengruppen, Produkte, Regionen oder Statuswerte.

Das WHERE-Muster ist deshalb eines der wichtigsten SQL-Grundmuster. Es sorgt dafür, dass du nur die Zeilen analysierst, die wirklich zur Fragestellung passen.

SELECT
  customer_id,
  order_date,
  revenue
FROM orders
WHERE order_date >= '2026-01-01'
  AND status = 'completed';

• Nutze WHERE, um irrelevante Daten früh auszuschließen.
• Filtere Zeiträume bewusst und eindeutig.
• Achte bei Textwerten auf genaue Schreibweisen.
• Vermeide zu komplexe Filter ohne Zwischentest.
• Prüfe immer, ob dein Filter die erwartete Datenmenge liefert.

Gute Filter sind die Grundlage jeder sauberen Analyse. Wer zu breit startet, verliert schnell den Überblick.

Muster 2: Gruppieren und Kennzahlen bilden mit GROUP BY

Analyst:innen arbeiten selten nur mit Einzelzeilen. Meist geht es darum, Zusammenfassungen zu erstellen: Umsatz pro Monat, Kund:innen pro Segment, Bestellungen pro Produkt oder Conversion Rate pro Kampagne.

GROUP BY ist das zentrale Muster, um aus vielen Datenpunkten verständliche Kennzahlen zu erzeugen.

SELECT
  DATE_TRUNC('month', order_date) AS month,
  COUNT(*) AS orders,
  SUM(revenue) AS total_revenue,
  AVG(revenue) AS avg_order_value
FROM orders
WHERE status = 'completed'
GROUP BY DATE_TRUNC('month', order_date)
ORDER BY month;

Hinweis: Die genaue Datumsfunktion kann je nach Datenbank leicht abweichen.

• Nutze COUNT, SUM, AVG, MIN und MAX für erste Kennzahlen.
• Gruppiere nach der Ebene, auf der du entscheiden möchtest.
• Achte darauf, dass jede nicht aggregierte Spalte im GROUP BY steht.
• Verwende ORDER BY, damit Trends leichter lesbar sind.
• Prüfe Aggregationen mit kleinen Beispieldaten.

GROUP BY verwandelt Rohdaten in Kennzahlen. Damit wird aus einer Tabelle eine Entscheidungsgrundlage.

Muster 3: Bedingungen abbilden mit CASE WHEN

In echten Analysen sind Daten selten perfekt vorbereitet. Häufig müssen Werte kategorisiert, Regeln formuliert oder neue Logiken erstellt werden. Genau dafür ist CASE WHEN besonders nützlich.

Mit CASE WHEN kannst du aus vorhandenen Daten neue analytische Kategorien ableiten, zum Beispiel Kundensegmente, Umsatzklassen oder Risikostufen.

SELECT
  customer_id,
  revenue,
  CASE
    WHEN revenue >= 1000 THEN 'high value'
    WHEN revenue >= 250 THEN 'medium value'
    ELSE 'low value'
  END AS customer_value_segment
FROM customer_revenue;

• Nutze CASE WHEN für Kategorien und Regeln.
• Formuliere Bedingungen in sinnvoller Reihenfolge.
• Achte darauf, dass jede Zeile in eine Kategorie fällt.
• Nutze ELSE, um unerwartete Fälle sichtbar zu machen.
• Dokumentiere komplexe Business-Logik im Query oder in der Beschreibung.

CASE WHEN macht SQL analytisch stärker, weil du Fachlogik direkt in deine Abfragen übersetzen kannst.

Muster 4: Tabellen sinnvoll verbinden mit JOIN

Viele wichtige Analysefragen lassen sich nicht mit einer einzigen Tabelle beantworten. Kundendaten liegen in einer Tabelle, Bestellungen in einer anderen, Produkte oder Kampagnen wieder woanders.

JOINs helfen dir, diese Informationen zusammenzuführen. Dabei ist nicht nur wichtig, dass der JOIN technisch funktioniert. Entscheidend ist, ob die Verbindung fachlich korrekt ist.

SELECT
  c.customer_id,
  c.country,
  COUNT(o.order_id) AS orders,
  SUM(o.revenue) AS total_revenue
FROM customers c
LEFT JOIN orders o
  ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.country;

• Prüfe immer den Join-Key.
• Verstehe den Unterschied zwischen INNER JOIN und LEFT JOIN.
• Achte auf Duplikate durch 1:n-Beziehungen.
• Teste nach einem JOIN die Anzahl der Zeilen.
• Nutze Aliase, damit Queries lesbarer bleiben.

JOINs sind mächtig, aber fehleranfällig. Ein falscher JOIN kann Kennzahlen stark verzerren.

Muster 5: Analysen strukturieren mit CTEs

Je komplexer eine Analyse wird, desto wichtiger ist Lesbarkeit. Lange verschachtelte SQL-Abfragen sind schwer zu prüfen und noch schwerer zu erklären.

CTEs, also Common Table Expressions, helfen dir, eine Analyse in logische Schritte aufzuteilen. Dadurch wird SQL verständlicher, testbarer und wartbarer.

WITH monthly_revenue AS (
  SELECT
    DATE_TRUNC('month', order_date) AS month,
    SUM(revenue) AS total_revenue
  FROM orders
  WHERE status = 'completed'
  GROUP BY DATE_TRUNC('month', order_date)
),
revenue_growth AS (
  SELECT
    month,
    total_revenue,
    LAG(total_revenue) OVER (ORDER BY month) AS previous_month_revenue
  FROM monthly_revenue
)
SELECT
  month,
  total_revenue,
  previous_month_revenue,
  total_revenue - previous_month_revenue AS revenue_change
FROM revenue_growth;

• Nutze CTEs, um komplexe Abfragen in Schritte zu zerlegen.
• Benenne CTEs nach ihrer fachlichen Funktion.
• Teste jede Zwischenstufe einzeln.
• Vermeide unnötig tiefe Verschachtelungen.
• Nutze CTEs besonders bei Reports, wiederkehrenden Analysen und Datenvalidierung.

CTEs machen SQL nicht nur sauberer. Sie machen deine Analyse für andere nachvollziehbar.

Bonus: Fensterfunktionen für Vergleiche über Zeilen hinweg

Sobald du Trends, Rankings oder Vorperiodenvergleiche analysieren möchtest, reichen klassische Aggregationen oft nicht mehr aus.

Fensterfunktionen wie ROW_NUMBER, RANK, LAG oder SUM OVER helfen dir, Werte über Zeilen hinweg zu vergleichen, ohne die Detailstruktur deiner Daten vollständig zu verlieren.

SELECT
  customer_id,
  order_date,
  revenue,
  ROW_NUMBER() OVER (
    PARTITION BY customer_id
    ORDER BY order_date
  ) AS order_number
FROM orders;

• Nutze ROW_NUMBER für Reihenfolgen und erste Ereignisse.
• Nutze RANK für Top-N-Analysen.
• Nutze LAG für Vergleiche mit vorherigen Werten.
• Nutze SUM OVER für laufende Summen.
• Achte auf PARTITION BY und ORDER BY, weil sie die Logik bestimmen.

Fensterfunktionen sind ein nächster großer Schritt, wenn du SQL nicht nur für Abfragen, sondern für echte Analysen nutzen möchtest.