Laufende Summen im Dashboard: Beginnt die Kurve wirklich bei null?

Eine laufende Summe beantwortet eine andere Frage als der Betrag eines einzelnen Tages. Legen Sie deshalb fest, ab welchem Ausgangswert addiert wird, wann die Berechnung neu beginnt und ob ein Datumsfilter nur die Anzeige oder auch die Berechnungsgrundlage verändert. Eine sauber gezeichnete Kurve kann sonst eine ganz andere Aussage liefern, als ihre Beschriftung erwarten lässt.

Dieser Beitrag betrifft die Definition einer fortlaufenden Auswertung in einer Geschäfts-App. Er ist weder eine Buchführungsanleitung noch eine Bestätigung, dass ein vorhandener Kontostand fachlich oder rechtlich richtig ist.

Erst die Kennzahl benennen

Stellen Sie sich einen fiktiven Reparaturbetrieb vor, der erledigte Aufträge über das Jahr verfolgen möchte. „An diesem Tag abgeschlossen“ beschreibt die jeweilige Tagesmenge. „Seit Jahresbeginn abgeschlossen“ beschreibt die bis zum betrachteten Tag aufgelaufene Menge. Eine Beschriftung wie „Abschlüsse“ lässt offen, welche der beiden Aussagen gemeint ist.

Meine Empfehlung: Schreiben Sie Bezug und Neustart direkt an die Kennzahl, etwa „Abgeschlossene Aufträge seit Jahresbeginn“. Wenn ein Bericht dagegen einen Bestand aus Zu- und Abgängen entwickelt, benötigt er zusätzlich einen definierten Anfangsbestand. Der Beginn des sichtbaren Diagramms ist nicht automatisch der Beginn der zugrunde liegenden Geschichte.

Vereinbaren Sie außerdem, welches Ereignis zählt. Ein Auftrag kann angelegt, bestätigt, abgeschlossen oder nachträglich korrigiert werden. Eine laufende Summe behebt keine unklare Auswahl dieser Ereignisse. Zunächst muss feststehen, was überhaupt addiert werden soll.

Ein Datumsfilter kann den Ausgangswert verändern

Das Tutorial zu Fensterfunktionen in PostgreSQL 18 erklärt einen wichtigen technischen Unterschied: Fensterfunktionen arbeiten auf den Zeilen, die nach den dort beschriebenen vorgelagerten Filtern und Gruppierungen übrig bleiben. Eine durch WHERE ausgeschlossene Zeile wird von der Fensterfunktion nicht mehr berücksichtigt. Das Tutorial beschreibt auch eine Unterabfrage als Möglichkeit, erst nach einer Fensterberechnung zu filtern.

Für die Beauftragung brauchen Sie deshalb keine bestimmte SQL-Anweisung, sondern eine fachliche Entscheidung:

• Summe innerhalb der Auswahl: Mit Beginn des ausgewählten Zeitraums startet die betrachtete Aufsummierung neu.
• Fortlaufender Wert mit Ausschnitt: Frühere berücksichtigte Vorgänge wirken weiter; der Filter begrenzt nur den sichtbaren Ausschnitt.

Beide Ansichten können sinnvoll sein. Sie dürfen aber nicht denselben Titel tragen und unbemerkt gegeneinander ausgetauscht werden. Soll eine Kurve einen fortlaufenden Bestand zeigen, muss der erste sichtbare Punkt den vereinbarten Ausgangswert berücksichtigen. Soll sie ausschließlich die Bewegung im gewählten Monat zeigen, darf sie keinen vollständigen historischen Bestand behaupten.

Das ist eine Anforderung an die Bedeutung Ihrer Auswertung. Die PostgreSQL-Dokumentation schreibt Ihrem Projekt weder eine dieser Ansichten noch den Einsatz dieser Datenbank vor.

Gleicher Zeitpunkt heißt nicht zwingend einzelner Rechenschritt

Das Tutorial zeigt außerdem, dass ein geordneter Summenlauf nicht automatisch für jede Zeile einen anderen Zwischenwert liefert. Beim dort beschriebenen Standardrahmen werden auch nachfolgende Zeilen einbezogen, deren Sortierwert dem aktuellen entspricht. Im Beispiel erhalten gleiche Gehaltswerte deshalb dieselbe kumulierte Summe.

Übertragen Sie diese technische Möglichkeit nicht ungeprüft auf eine betriebliche Aussage. Wenn Ihre Vorgänge nur nach Datum geordnet sind, können mehrere Ereignisse denselben Sortierwert haben. Vielleicht wünschen Sie bewusst einen gemeinsamen Tagesabschluss. Vielleicht muss dagegen jeder einzelne Vorgang einen nachvollziehbaren Zwischenstand zeigen.

Lassen Sie den Entwickler erklären, wie der gewählte Berechnungsrahmen und die Reihenfolge genau diese Anforderung umsetzen. Bei einer Einzelvorgangsansicht braucht es eine nachvollziehbare Regel für Gleichstände, beispielsweise eine zusätzliche stabile Ereigniskennung. Das ist eine Gestaltungsempfehlung und keine Behauptung, eine zusätzliche Sortierspalte allein löse jede fachliche Frage.

Auch die Sortierung der sichtbaren Tabelle verdient Aufmerksamkeit. PostgreSQL weist ausdrücklich darauf hin, dass die Reihenfolge innerhalb der Fensterberechnung nicht mit der Ausgabereihenfolge übereinstimmen muss. Eine absteigend angezeigte Liste darf deshalb nicht suggerieren, sie sei zwangsläufig von oben nach unten in derselben Richtung berechnet worden.

Wo beginnt eine neue Folge?

Eine gemeinsame Kurve über mehrere Standorte ist etwas anderes als getrennte laufende Summen je Standort. Laut Tutorial teilt PARTITION BY die Zeilen in Gruppen auf, innerhalb derer die jeweilige Fensterfunktion berechnet wird. Ohne diese Aufteilung gibt es eine gemeinsame Partition.

Schreiben Sie fachlich auf, welche Trennung gewünscht ist: je Standort, Projekt, Produktgruppe oder eine Gesamtfolge für die berechtigte Auswahl. Legen Sie zusätzlich fest, ob ein neues Kalenderjahr tatsächlich einen Neustart bedeutet. Nicht jeder Bericht mit einem Jahresfilter soll seine Vorgeschichte vergessen.

Bei einer Summe aus Geldbeträgen gehören auch Währung und fachliche Umrechnungsregel ins Konzept. Unvereinbare Einheiten werden nicht dadurch addierbar, dass sie in einer Zeitreihe stehen. Dieser Hinweis ist eine Anforderung an Ihre Kennzahl, keine durch das Datenbanktutorial geprüfte Finanzregel.

Korrekturen und Lücken dürfen nicht wie gewöhnliche Tage aussehen

Entscheiden Sie, was eine verspätet erfasste oder rückgängig gemachte Buchung für frühere Punkte bedeutet. Wird die historische Kurve neu berechnet, oder zeigt der Bericht den damals bekannten Stand? Beides verlangt eine verständliche Erklärung. Ein nachträglich geänderter Wert soll nicht wie eine unerklärliche Bewegung im laufenden Betrieb wirken.

Ebenso wenig bedeutet eine fehlende Beobachtung automatisch null Bewegung. Ein Tag ohne Ereignis, ein Tag ohne verfügbare Daten und ein fehlgeschlagener Abruf sind unterschiedliche Zustände. Halten Sie fest, ob ein Wert fortgeschrieben werden darf und wie eine tatsächliche Lücke sichtbar bleibt. Diese Regeln sind Projektvorschläge; das zitierte Tutorial liefert dafür keine vollständige Berichtslösung.

Eine nachvollziehbare Folge abnehmen

Verwenden Sie für Ihre Akzeptanzkriterien wenige ungefährliche Beispieldatensätze mit bekanntem Ausgangswert. Lassen Sie die erwarteten Zwischenstände vor der Umsetzung fachlich bestätigen. Eine Prüfung könnte Folgendes enthalten:

1. Die Beschriftung unterscheidet Tagesbewegung, Zeitraumssumme und fortlaufenden Wert.
2. Ein engerer Datumsfilter behandelt frühere Ereignisse nach der vereinbarten Regel.
3. Mehrere Ereignisse am selben Tag ergeben entweder einen gemeinsamen Tagesstand oder die ausdrücklich geforderten Einzelzwischenstände.
4. Eine andere Anzeigesortierung verändert nicht versehentlich die definierte Berechnung.
5. Ein Wechsel der Gruppe und der vereinbarte Neustart bilden getrennte Folgen korrekt ab.
6. Eine Korrektur und eine echte Datenlücke erhalten ihre jeweils vereinbarte Behandlung.
7. Tabelle, Diagramm und zugängliche Erläuterung beschreiben dieselbe Kennzahl.

Diese Fälle sind ein Vorschlag für die Abnahme, keine hier ausgeführte Datenbank- oder Browserprüfung. Vereinbaren Sie die erwarteten Ergebnisse ausdrücklich, statt eine optisch plausible Linie als Nachweis zu akzeptieren.

Häufige Fragen

Muss eine laufende Summe immer steigen?

Nicht grundsätzlich. Das hängt davon ab, welche Werte in Ihrer fachlichen Definition einfließen. Eine ausschließlich positive Ereigniszählung ist etwas anderes als eine Folge mit Abgängen oder Korrekturen. Benennen Sie die Kennzahl, bevor Sie aus ihrer Richtung Schlüsse ziehen.

Sollte der erste sichtbare Wert null sein?

Nur wenn das zur vereinbarten Bedeutung passt. Bei einer neu beginnenden Zeitraumsauswertung kann das sinnvoll sein. Bei einem Ausschnitt aus einer fortlaufenden Bestandsentwicklung kann dadurch die Vorgeschichte verschwinden. Sichtbarer Beginn und Berechnungsbeginn müssen getrennt festgelegt werden.

Reicht der Wunsch nach einer kumulierten Kurve im Briefing?

Nein. Bringen Sie Ausgangswert, Ereignisdefinition, Filterverhalten und Neustartregel in ein Gespräch über Ihre Reporting-App mit. Dann lässt sich eine überprüfbare Kennzahl beauftragen statt nur eine Diagrammform.

Die Quellenprüfung dieses Beitrags bezieht sich auf das PostgreSQL-18-Tutorial, gelesen am 26. Oktober 2026. Es belegt die beschriebenen Fenster-, Filter-, Sortier- und Gruppierungsmechanismen. Die fachlichen Berichtsregeln und Abnahmevorschläge müssen für Ihr eigenes Projekt vereinbart werden.