Reports brauchen oft mehrere Kennzahlen aus derselben Zeilenmenge: Gesamtumsatz, Umsatz im Vertrieb und Anzahl aktiver Datensätze. Vor Oracle AI Database 26ai wurden solche bedingten Aggregationen häufig mit CASE-Ausdrücken, separaten Unterabfragen oder mehreren Joins formuliert. Aggregation Filters bringen dafür die standardnahe Syntax FILTER (WHERE ...) in Oracle SQL.
1. Ein Aggregat gezielt filtern
Mit FILTER wird die Bedingung direkt an COUNT, SUM, AVG, MIN oder MAX geschrieben:
SELECT
COUNT(*) FILTER (WHERE status = 'ACTIVE') AS active_count,
SUM(salary) FILTER (WHERE department = 'SALES') AS sales_total
FROM employees;Die Bedingung entscheidet nur, welche Zeilen in das jeweilige Aggregat eingehen. Dadurch können aktive und inaktive Datensätze sowie verschiedene Fachbereiche in derselben Ergebnismenge gezählt oder summiert werden.
2. Mehrere Kennzahlen ohne Unterabfragen
Besonders hilfreich ist die Syntax, wenn ein Bericht mehrere Zeiträume oder Kategorien nebeneinander zeigen soll:
SELECT
year,
SUM(sales) AS year_sales,
SUM(sales) FILTER (WHERE quarter_no IN (1, 2)) AS first_half,
SUM(sales) FILTER (WHERE quarter_no IN (3, 4)) AS second_half
FROM sales_fact
GROUP BY year
ORDER BY year;Die Abfrage bleibt auf einer fachlichen Ebene lesbar. Ein späterer Leser sieht direkt, welche Kennzahl welche Teilmenge verwendet. Das reduziert die Gefahr, dass getrennte Unterabfragen unterschiedliche Join- oder Zeitfilter erhalten.
3. WHERE und FILTER haben unterschiedliche Aufgaben
Die globale WHERE-Klausel wird vor den Aggregationen angewendet. Ein Aggregation Filter wird danach auf die Zeilen angewendet, die das jeweilige Aggregat erhalten soll. Das macht folgenden Unterschied sichtbar:
SELECT
COUNT(*) AS all_visible,
COUNT(*) FILTER (WHERE status = 'ACTIVE') AS active_count
FROM employees
WHERE region = 'DACH';Beide Kennzahlen betrachten nur die Region DACH. Nur die zweite Kennzahl schränkt zusätzlich auf ACTIVE ein. Wird die Statusbedingung versehentlich in die globale WHERE-Klausel verschoben, verschwindet die Vergleichsgröße für alle anderen Statuswerte.
4. NULL, Joins und Performance prüfen
Wie bei anderen Aggregaten gelten die üblichen NULL-Regeln. COUNT(*) zählt qualifizierte Zeilen, während SUM(spalte) NULL-Werte in der aggregierten Spalte nicht addiert. Wenn ein Bericht für eine leere Teilmenge explizit null oder nullwertige Anzeige erwartet, sollte die Ausgabe mit COALESCE fachlich festgelegt werden.
Bei Joins muss die Zeilenvermehrung vor dem Aggregat geprüft werden. Ein FILTER korrigiert keinen falschen Join. Für große Datenmengen sollten Ausführungsplan, Join-Kardinalität und die Selektivität des globalen WHERE-Filters gemessen werden. Die neue, klarere Schreibweise ist kein Versprechen für einen bestimmten Plan.
5. Praktische Checkliste
- Globale Einschränkungen in WHERE von Kennzahl-spezifischen Bedingungen trennen.
- Mehrere bedingte Aggregate in einer Testabfrage gegeneinander prüfen.
- NULL-Semantik für COUNT, SUM und leere Teilmengen dokumentieren.
- Join-Kardinalität vor jeder Aggregation mit Kontrollzählungen validieren.
- FILTER-Bedingungen nicht mit Subqueries oder Window Functions formulieren.
- Plan, Laufzeit und Ergebniszahlen vor dem Rollout mit den bisherigen Reports vergleichen.
Fazit
Aggregation Filters in Oracle AI Database 26ai machen bedingte Kennzahlen deutlich kompakter und näher an der fachlichen Aussage. Besonders bei Status-, Kategorie- und Zeitvergleichen ersetzen sie viele verschachtelte CASE-Ausdrücke. Wer WHERE-Reihenfolge, NULL-Verhalten und Join-Kardinalität prüft, erhält lesbare und belastbare Analyseabfragen.
Weiterführend: Oracles Anleitung zu Aggregation Filters, die SQL-Referenz zu Aggregate Functions und die SQL-Neuerungen in 26ai.