Drei Datenaggregationsfehler in BI-Systemen

Warum BI-Systeme lügen: Drei fatale Fehler bei der Datenaggregation

Metriken in BI-Tools zeigen oft eine trügerische Präzision. In der Praxis entstehen systematische Verzerrungen, sobald die Daten von Rohtransaktionen zu voraggregierten Marts übergehen – manchmal um Zehnerprozentsätze. Das ist kein Bug; es ist ein architektonischer Kompromiss zwischen Geschwindigkeit und Genauigkeit. Lassen Sie uns drei zentrale mathematische Fallen aufschlüsseln, die Analytics für Entscheidungsfindung gefährlich machen.

Fehler Eins: Durchschnitt von Durchschnitten – Eine mathematische Katastrophe

Durchschnittlicher Bonwert, durchschnittliche Anfragebearbeitungszeit, durchschnittliche Bestellkosten – diese Metriken sind nicht additiv. Man kann bereits gemittelte Werte nicht einfach mitteln. Klassisches Beispiel: Ein BI-System nimmt die durchschnittlichen Bonwerte pro Filiale für Januar, Februar und März, addiert sie und teilt durch drei, um den Quartalswert zu erhalten. Die Formel sieht so aus:

SELECT 
    region_name,
    EXTRACT(QUARTER FROM year_month) AS quarter,
    AVG(avg_receipt_amount) AS total_average_check
FROM dwh.store_monthly_aggregated
WHERE EXTRACT(QUARTER FROM year_month) = 1
GROUP BY region_name, EXTRACT(QUARTER FROM year_month);

Das Problem ist, dass A/B + C/D ≠ (A+B)/(C+D). Ein Hypermarkt mit 10.000 Bons pro Tag erhält im Rechnen dasselbe Gewicht wie ein Kiosk mit 50 Bons. Ein Monat mit Spitzenumsatz wird gleichgesetzt mit einem "toten". In realen Daten führt das zu Abweichungen von -6 % bis +7 %. Im Einzelhandel, wo jeder Prozentpunkt mehr im durchschnittlichen Bonwert Millionen Euro bedeutet, sind solche Verzerrungen inakzeptabel. Am schlimmsten: Wenn eine zufällige Übereinstimmung der Nenner das korrekte Ergebnis liefert, wird der Fehler im DWH als "richtig" zementiert.

Fehler Zwei: Count Distinct bei wechselndem Filterkontext

Das Zählen eindeutiger Objekte – Kunden, Bons, Produkte – bricht zusammen, wenn sich das Detailniveau ändert. Stellen Sie sich drei Transaktionen vor:

• Bon #101 | Lebensmittel
• Bon #101 | Getränke
• Bon #102 | Getränke

Reale Anzahl eindeutiger Bons – 2. Aber wenn die Daten voraggregiert nach Kategorien sind:

• Lebensmittel: 1 Bon (#101)
• Getränke: 2 Bons (#101, #102)

Dann führt das Einrücken der Hierarchie in Power BI oder einem SQL-Engine zu einer einfachen Summe: 1 + 2 = 3. Die Eindeutigkeit geht verloren. Das System hat Bon #101 doppelt gezählt. Dieser Fehler verzerrt sofort den durchschnittlichen Bonwert, die Konversion, den Kundenlebenszeitwert – alles, was von der Anzahl eindeutiger Entitäten abhängt. Der Nutzer merkt nicht einmal, dass er die Ansicht geändert hat – und landet bei falschen Zahlen.

Fehler Drei: Semi-additive Maße und starre Kalender

Bestandsstände, Kontostände, Anzahl aktiver Nutzer – das sind Momentaufnahme-Metriken. Sie können über Räume (Filialen, Regionen) summiert werden, aber nicht über die Zeit. Um das zu umgehen, verwenden Entwickler Funktionen wie LASTNONBLANK in DAX oder NonEmpty in MDX:

Balance on konets perioda = 
CALCULATE (SUM('Inventory'[Balance]),
    LASTNONBLANK ('Calendar'[Date], 
        CALCULATE(SUM('Inventory'[Balance]))
    ))

Das erzeugt drei Probleme:

• Performance: Der Engine iteriert bei jeder Filteränderung über alle Daten in der Hierarchie. Bei großen Volumen – Einfrieren.
• Fehler in der Praxis: Wenn am 30. die Kasse die Daten nicht überträgt, zeigt das System am 31. Nullbestand. Waren im Wert von Hunderttausenden Euro "verschwinden".
• Code-Komplexität: Der Nutzer muss Entwickler sein. Bei mehreren Geschäfts kalendern werden Formeln unlesbar und brüchig.

Was zählt

• Aggregation tötet Genauigkeit. Die Vor-Komprimierung von Daten für Geschwindigkeit ist ein Kompromiss, der oft implizit akzeptiert wird, ohne die Konsequenzen zu verstehen.
• Nicht-additive Metriken brauchen Rohdaten. Jede Mittlung, Median, eindeutige Zählung – muss on the fly aus dem vollen Datensatz berechnet werden.
• Momentaufnahme-Metriken vertragen keine starren Zeitgrenzen. Das System muss flexibel den aktuellen Wert finden, nicht blind dem Kalender folgen.
• BI-Nutzer sollten kein DAX/MDX schreiben. Die Architektur sollte Komplexität verstecken, nicht auf den Analysten abladen.
• Neue Plattformen verzichten auf Voraggregierungen. Dynamisches Verknüpfen von Rohquellen on the fly ist der einzige Weg zu mathematisch präzisen Analytics.

Paradigmenwechsel: Analytics ohne Kompromisse

Klassische BI-Systeme basieren auf einer Illusion: Wir können alles vorab berechnen, was das Geschäft braucht. In der Realität ändern sich die Fragen des Geschäfts ständig. Statt DAX-Arbeitsumgehungen zu schreiben, arbeiten moderne Plattformen direkt mit Rohdaten. Beispiel: Die Berechnung der "Lagerdeckung" – das Verhältnis von Bestand zu Umsatz – kann zwei verschiedene Quellen kombinieren: Milliarden Bestandszeilen und Milliarden Bonzeilen. Statt eines starren Marts im DWH zu bauen, verknüpft das System die Quellen dynamisch bei jedem Nutzerklick und berechnet die Metrik mit mathematischer Präzision neu. Der Kern selbst bestimmt Zeitfenster, findet aktuelle Bestandsstände und lädt nur die notwendigen Daten ins Gedächtnis. Das ist nicht "schneller"; es ist "korrekt". Als Bankmanager erstmals die echte Anfragebearbeitungszeit sahen – ohne Verzerrungen durch Mittlung von Mittlungen – stellten sie die richtigen Fragen. Die Einzelhandelskette will nicht mehr Sinn für eine 5-Millionen-Zeilen-Grenze opfern. Analytics sollte eine RAW-Datei sein, kein JPEG. Nur so bleiben Details und die Möglichkeit, Erkenntnisse zu schärfen, erhalten. Die Technologie existiert – jetzt ist es Zeit, unsere mentale Architektur umzudenken.

— Editorial Team