Aggregation nach Joins: das Fan-Out-Problem in SQL lösen

1. Was das Fan-Out-Problem ist und warum es entsteht

Das Fan-Out-Problem beschreibt eine der häufigsten und zugleich am schwersten zu entdeckenden Fehlerquellen bei Aggregation nach Joins. Es entsteht, sobald eine Zeile der Ausgangstabelle über einen JOIN mit mehreren Zeilen einer verknüpften Tabelle in Beziehung steht und diese Verknüpfung anschließend direkt aggregiert wird, ohne die Vervielfachung vorher zu berücksichtigen. Das Ergebnis sind Summen, die auf den ersten Blick plausibel aussehen, tatsächlich aber ein Vielfaches des korrekten Werts betragen.

Der tückische Kern des Fan-Out-Problems liegt darin, dass die Abfrage selbst keinen Fehler wirft. SQL führt den JOIN syntaktisch korrekt aus, SUM und COUNT rechnen korrekt über die Zeilen, die ihnen vorliegen, nur ist die Anzahl dieser Zeilen durch den JOIN künstlich aufgebläht. Aus Sicht der Datenbank ist alles in Ordnung, aus Sicht der Fachlichkeit ist das Ergebnis jedoch systematisch falsch, oft um genau den Faktor, mit dem eine Zeile vervielfacht wurde.

Dieser Artikel zeigt an einem konkreten Beispiel, wie Fan-Out bei Aggregation nach Joins entsteht, warum die zugrunde liegende Mathematik so tückisch ist, und mit welchen Techniken sich das Problem systematisch vermeiden lässt, von der Vor-Aggregation in Subqueries bis zu Window Functions.

2. Ein konkretes Beispiel: Bestellungen mit Positionen und Zahlungen

Ein klassisches Szenario für das Fan-Out-Problem ist ein Bericht über Bestellungen, der gleichzeitig die Summe aller Bestellpositionen und die Anzahl der Zahlungen pro Bestellung zeigen soll. Eine Bestellung mit drei Positionen und zwei Zahlungen wird durch den JOIN auf beide Tabellen gleichzeitig zu sechs Zeilen, dem kartesischen Produkt aus drei Positionen und zwei Zahlungen. Eine anschließende SUM über den Positionsbetrag zählt diesen Betrag nun sechsmal statt dreimal, weil jede Position mit jeder Zahlung kombiniert wurde.

Das folgende Beispiel zeigt genau diesen Fehler in der Praxis: Die naive Abfrage liefert eine Positionssumme, die exakt doppelt so hoch ist wie der tatsächliche Wert, weil zwei Zahlungszeilen pro Bestellung existieren. Auf den ersten Blick fällt dieser Fehler oft nicht auf, weil die Summe plausibel wirkt, insbesondere wenn niemand die Rohdaten Zeile für Zeile nachrechnet.

-- Fan-out in action: joining two one-to-many relations at once
-- order 100 has 3 line items and 2 payments -> 6 rows after both joins
SELECT
    o.order_id,
    SUM(oi.line_total) AS wrong_item_sum,   -- doubled: counted once per payment row
    COUNT(pay.payment_id) AS payment_count
FROM orders o
JOIN order_items oi ON oi.order_id = o.order_id
JOIN payments pay ON pay.order_id = o.order_id
WHERE o.order_id = 100
GROUP BY o.order_id;

-- Result: wrong_item_sum is exactly double the real item total
-- order_id | wrong_item_sum | payment_count
--      100 |         240.00 |             2   (real item total is 120.00)

3. Warum JOIN Zeilen vervielfacht, bevor aggregiert wird

Um Aggregation nach Joins korrekt zu beherrschen, muss man die Reihenfolge verstehen, in der eine SQL-Abfrage tatsächlich verarbeitet wird. Zuerst wertet die Datenbank sämtliche FROM- und JOIN-Klauseln aus und erzeugt daraus eine gemeinsame, unter Umständen stark vergrößerte Zwischenmenge. Erst danach greifen WHERE, GROUP BY und die Aggregatfunktionen auf diese bereits vervielfachte Zeilenmenge zu. Die Aggregatfunktion sieht also nie die ursprünglichen, unverbundenen Zeilen, sondern ausschließlich das Ergebnis des kartesischen Produkts aus allen beteiligten Joins.

Bei einem einzelnen JOIN auf eine 1:n-Beziehung ist das Verhalten meist noch intuitiv nachvollziehbar, weil die Vervielfachung der Anzahl der verknüpften Zeilen entspricht. Kritisch wird es, sobald zwei oder mehr unabhängige 1:n-Beziehungen gleichzeitig gejoint werden, wie im Beispiel aus Abschnitt zwei. Die Vervielfachungsfaktoren der einzelnen Joins multiplizieren sich dann miteinander, statt sich zu addieren, was bei drei Positionen und zwei Zahlungen exakt die sechs Zeilen aus dem Beispiel erklärt.

4. Lösung: Vor-Aggregation in Subqueries vor dem Join

Die robusteste Lösung für das Fan-Out-Problem bei Aggregation nach Joins ist, jede 1:n-Beziehung zuerst separat auf Ebene der Bestellung vorzuaggregieren, bevor überhaupt ein JOIN zwischen den Ergebnissen stattfindet. Statt die Rohtabellen direkt zu verknüpfen, wird für jede Beziehung eine eigene Subquery oder Common Table Expression geschrieben, die bereits auf Bestellungsebene aggregiert vorliegt. Erst diese bereits aggregierten Zwischenergebnisse werden anschließend über den Bestellschlüssel zusammengeführt.

Der entscheidende Vorteil dieser Technik: Da jede Subquery unabhängig von den anderen aggregiert, kann keine Vervielfachung durch eine andere Beziehung mehr auftreten. Der finale JOIN zwischen den bereits aggregierten Zwischenergebnissen findet auf 1:1-Basis über den Bestellschlüssel statt, und ein 1:1-JOIN vervielfacht per Definition keine Zeilen. Diese Technik ist die Standardlösung für Aggregation nach Joins in produktivem Reporting-Code.

-- Correct fan-out-free aggregation: pre-aggregate each relation separately
WITH item_totals AS (
    SELECT order_id, SUM(line_total) AS item_sum
    FROM order_items
    GROUP BY order_id
),
payment_counts AS (
    SELECT order_id, COUNT(payment_id) AS payment_count
    FROM payments
    GROUP BY order_id
)
SELECT
    o.order_id,
    it.item_sum,
    pc.payment_count
FROM orders o
JOIN item_totals it ON it.order_id = o.order_id
JOIN payment_counts pc ON pc.order_id = o.order_id
WHERE o.order_id = 100;

-- Result: item_sum is now correct, no multiplication by payment rows
-- order_id | item_sum | payment_count
--      100 |   120.00 |             2

5. COUNT(DISTINCT ...) als Notlösung und ihre Grenzen

Eine schnellere, aber deutlich begrenztere Reaktion auf das Fan-Out-Problem ist COUNT(DISTINCT ...) bei Zählungen. Statt alle vervielfachten Zeilen zu zählen, zählt COUNT(DISTINCT o.order_id) nur die eindeutigen Bestellungen, unabhängig davon, wie oft sie durch den JOIN vervielfacht wurden. Diese Technik funktioniert zuverlässig für reine Zählungen, versagt aber vollständig bei SUM, weil sich Beträge nicht wie Identifikatoren deduplizieren lassen: SUM(DISTINCT betrag) würde fälschlicherweise auch tatsächlich identische, aber legitim unterschiedliche Beträge zusammenfassen.

Diese Einschränkung macht COUNT(DISTINCT ...) zu einer Notlösung, die nur für einen Teil des Fan-Out-Problems taugt. Sobald eine Abfrage sowohl Zählungen als auch Summen über mehrere 1:n-Beziehungen benötigt, wie im Beispiel aus Abschnitt zwei, reicht COUNT(DISTINCT ...) allein nicht aus. Für SUM bleibt die Vor-Aggregation in Subqueries aus Abschnitt vier die einzige durchgängig korrekte Lösung, unabhängig von der Anzahl der beteiligten Beziehungen.

-- COUNT(DISTINCT ...) fixes counting, but NOT sums, in a fan-out join
SELECT
    o.order_id,
    COUNT(DISTINCT oi.item_id) AS correct_item_count,  -- works: counts distinct rows
    SUM(oi.line_total) AS still_wrong_sum               -- still multiplied by payments
FROM orders o
JOIN order_items oi ON oi.order_id = o.order_id
JOIN payments pay ON pay.order_id = o.order_id
GROUP BY o.order_id;

6. Mehrere 1:n-Beziehungen gleichzeitig: das doppelte Fan-Out

Sobald eine Abfrage bei Aggregation nach Joins mehr als zwei unabhängige 1:n-Beziehungen gleichzeitig verknüpft, wächst die Zeilenvervielfachung multiplikativ statt additiv. Drei Positionen, zwei Zahlungen und vier Kommentare zu derselben Bestellung erzeugen nach allen drei JOINs vierundzwanzig Zeilen, das Produkt aus drei mal zwei mal vier. Jede weitere unabhängige Beziehung, die naiv mitgejoint wird, verschärft das Problem exponentiell statt linear.

Genau dieser multiplikative Effekt macht das Fan-Out-Problem bei komplexeren Reports so gefährlich: Fehler, die bei zwei Beziehungen noch als moderate Abweichung auffallen könnten, werden bei drei oder vier gleichzeitig gejointen Beziehungen schnell um Größenordnungen zu hoch, ohne dass ein offensichtlicher Fehler in der Abfrage erkennbar wäre. Die Vor-Aggregation aus Abschnitt vier skaliert dagegen unabhängig von der Anzahl der Beziehungen linear, weil jede Beziehung separat und unabhängig von den anderen aggregiert wird.

-- Triple fan-out: 3 items x 2 payments x 4 comments = 24 rows per order
SELECT o.order_id, SUM(oi.line_total) AS wildly_wrong_sum
FROM orders o
JOIN order_items oi ON oi.order_id = o.order_id
JOIN payments pay ON pay.order_id = o.order_id
JOIN order_comments c ON c.order_id = o.order_id
GROUP BY o.order_id;
-- item_sum would now be 8x too high (3 items x [2 payments x 4 comments])

-- Correct: pre-aggregate all three relations independently, then join once
WITH item_totals AS (
    SELECT order_id, SUM(line_total) AS item_sum FROM order_items GROUP BY order_id
),
payment_counts AS (
    SELECT order_id, COUNT(*) AS payment_count FROM payments GROUP BY order_id
),
comment_counts AS (
    SELECT order_id, COUNT(*) AS comment_count FROM order_comments GROUP BY order_id
)
SELECT o.order_id, it.item_sum, pc.payment_count, cc.comment_count
FROM orders o
JOIN item_totals it ON it.order_id = o.order_id
JOIN payment_counts pc ON pc.order_id = o.order_id
JOIN comment_counts cc ON cc.order_id = o.order_id;

7. Window Functions als Alternative zur Vor-Aggregation

Neben Subqueries bieten Window Functions eine elegante Alternative, um Aggregation nach Joins ohne Fan-Out zu berechnen, insbesondere wenn Detailzeilen zusätzlich zur Aggregation erhalten bleiben sollen. Statt vorab zu aggregieren und dann zu joinen, berechnet man die Summe direkt mit SUM(...) OVER (PARTITION BY order_id) auf der bereits gejointen, vervielfachten Zeilenmenge, aber bewusst nur auf einer der beteiligten Detailtabellen, nicht auf mehreren gleichzeitig.

Diese Technik funktioniert zuverlässig, solange nur eine der beteiligten 1:n-Beziehungen mit einer Window Function summiert wird, während weitere Beziehungen separat über COUNT(DISTINCT ...) oder eigene Window Functions auf ihrer jeweiligen Schlüsselspalte behandelt werden. Bei mehreren gleichzeitig zu aggregierenden 1:n-Beziehungen bleibt jedoch die Vor-Aggregation in Subqueries die klarere und wartbarere Lösung, weil sie das Fan-Out-Problem strukturell ausschließt, statt es durch geschickte Fensterdefinitionen zu umschiffen.

8. Fan-Out-Fehler erkennen: Prüfsummen und Testdaten

Weil das Fan-Out-Problem keinen SQL-Fehler auslöst, hilft nur systematisches Gegenprüfen, um es in bestehenden Reports zu entdecken. Eine wirksame Technik ist, dieselbe Kennzahl einmal über die naive, gejointe Abfrage und einmal über eine unabhängige, garantiert korrekte Einzelabfrage auf nur einer Tabelle zu berechnen und beide Werte zu vergleichen. Weichen sie voneinander ab, deutet das fast immer auf Fan-Out bei einer der beteiligten Aggregation nach Joins hin.

Für neue Reports lohnt sich zusätzlich ein gezielter Testdatensatz, in dem mindestens eine Bestellung bewusst mehrere Positionen und mehrere Zahlungen gleichzeitig besitzt. Nur mit solchen Testdaten wird das Fan-Out-Problem überhaupt sichtbar, weil es bei Bestellungen mit jeweils genau einer Position und genau einer Zahlung gar nicht auftritt und der Fehler unentdeckt bliebe, obwohl die Abfrage bei realen, komplexeren Bestellungen falsche Werte liefert.

9. Lösungsansätze für Aggregation nach Joins im Vergleich

Die folgende Übersicht ordnet die vorgestellten Techniken nach Zuverlässigkeit und Einsatzgebiet ein, um bei zukünftigen Reports von Anfang an die richtige Wahl zu treffen und das Fan-Out-Problem gar nicht erst entstehen zu lassen.

Wer Reports von Anfang an mit vorab aggregierten Subqueries statt naiven Mehrfach-Joins aufbaut, muss das Fan-Out-Problem später nicht mehr mühsam aus historisch gewachsenem Code herausrechnen. Diese Disziplin zahlt sich besonders bei Kennzahlen aus, die für Geschäftsentscheidungen herangezogen werden.

10. Zusammenfassung

Das Fan-Out-Problem entsteht, weil ein JOIN Zeilen vervielfacht, bevor Aggregatfunktionen überhaupt zu rechnen beginnen. Bei einer einzelnen 1:n-Beziehung ist die Vervielfachung meist noch offensichtlich, bei mehreren gleichzeitig gejointen Beziehungen multiplizieren sich die Faktoren jedoch, und Summen werden ohne erkennbaren Fehler in der Abfrage systematisch zu hoch. Aggregation nach Joins ist deshalb nie trivial, sobald mehr als eine 1:n-Beziehung im Spiel ist.

Die zuverlässigste Lösung ist, jede Beziehung zunächst separat in einer eigenen Subquery zu aggregieren und die bereits verdichteten Zwischenergebnisse anschließend über 1:1-Joins zusammenzuführen. COUNT(DISTINCT ...) hilft nur bei reinen Zählungen, Window Functions eignen sich für einzelne Beziehungen mit Detailerhalt. Systematisches Gegenprüfen mit Testdaten, die bewusst mehrere Zeilen pro Beziehung enthalten, deckt Fan-Out-Fehler in bestehendem Code zuverlässig auf.

11. FAQ: Fan-Out-Problem bei Aggregation nach Joins