Eine Datumsspalte trägt häufig mehrere Bedeutungen: Der Monatsabschluss folgt dem Gregorianischen Kalender, das Geschäftsjahr beginnt im Juli und der Handel vergleicht Wochen nach dem NRF-4-5-4-Modell. Bislang landete diese Logik oft in Dimensionstabellen, ETL-Jobs oder wiederholten CASE-Ausdrücken. Oracle AI Database 26ai bringt Kalenderfunktionen für Gregorianische, fiskalische und Retail-Perioden direkt in SQL.
1. Perioden eindeutig labeln
Funktionen wie CALENDAR_YEAR, FISCAL_QUARTER oder RETAIL_MONTH liefern Bezeichnungen für die jeweilige Periode. Für ein Geschäftsjahr mit Start am 1. Juli lässt sich die Fiskalperiode beispielsweise so gruppieren:
SELECT
FISCAL_YEAR(order_date, DATE '2025-07-01') AS fiscal_year,
FISCAL_QUARTER(order_date, DATE '2025-07-01') AS fiscal_quarter,
SUM(order_total) AS revenue
FROM orders
GROUP BY
FISCAL_YEAR(order_date, DATE '2025-07-01'),
FISCAL_QUARTER(order_date, DATE '2025-07-01');Das Startdatum kann als Funktionsargument angegeben werden. Alternativ kann die Einstellung CALENDAR_FISCAL_YEAR_START verwendet werden. Für wiederholbare Reports sollte das Geschäftsjahresmodell explizit dokumentiert und in allen Umgebungen einheitlich gesetzt werden.
2. Periodengrenzen als DATE zurückgeben
Wenn ein Report nicht nur ein Label, sondern einen echten Datumsbereich benötigt, liefern Funktionen wie FISCAL_QUARTER_START_DATE und FISCAL_YEAR_END_DATE die Grenzen als DATE-Werte zurück. Das hilft bei Filtern, Densifizierung und beim Aufbau von Zeitreihen.
Die Periodenlabels sind formatierte Zeichenwerte; Datumsgrenzen sind dagegen für Vergleiche und Joins meist die bessere Grundlage. Für APIs sollte deshalb klar sein, ob die Oberfläche eine sprachabhängige Anzeige oder eine stabile Perioden-ID erhält.
3. Retail 4-5-4 und Schaltwochen
Die Retail-Funktionen bilden den NRF-4-5-4-Kalender ab: Monate bestehen aus vier, fünf und vier Wochen. Retail-Jahre starten an einem Sonntag zwischen dem 29. Januar und 4. Februar. In Abständen von fünf bis sechs Jahren kommt eine 53. Woche hinzu.
Für Vergleichsberichte ist wichtig, ob ein Schaltjahr als 53-Wochen-Jahr oder als restated 52-Wochen-Jahr ausgewertet wird. Die Retail-Funktionen akzeptieren dazu den Parameter is_restated. Vorjahresvergleiche sollten beide Varianten fachlich festlegen, damit Planungs- und Finanzberichte dieselbe Periodenlogik verwenden.
4. Perioden verschieben und Position bestimmen
Mit Funktionen wie FISCAL_ADD_MONTHS lässt sich eine Fiskalperiode verschieben; RETAIL_WEEK_OF_MONTH bestimmt die Woche innerhalb eines Retail-Monats. Das ist hilfreich für Vorperiodenvergleiche oder relative Positionen, ohne Kalenderregeln in jeder Abfrage neu zu implementieren.
Beachte dabei, dass eine Fiskalperiode nicht zwingend am ersten Kalendertag eines Monats beginnt. Teste Grenzfälle am Jahreswechsel, am Geschäftsjahresbeginn und in Retail-Schaltwochen. Für Datumsarithmetik sollte stets die passende Kalenderfamilie verwendet werden.
5. Einführungs-Checkliste für Analytics
- Für jede Kennzahl den fachlich maßgeblichen Kalender bestimmen.
- Fiskaljahresstart zentral konfigurieren oder explizit als Parameter führen.
- Retail-Berichte auf normale und restated 53-Wochen-Jahre testen.
- Für Joins und Filter Start-/End-DATE-Funktionen statt Anzeige-Labels einsetzen.
- Zeitzone, DATE-Konvertierungen und NLS_DATE_LANGUAGE in Clientpfaden prüfen.
- Ergebnisse gegen bestehende Zeitdimensionen und freigegebene Finanzreports abgleichen.
Fazit
Die Kalenderfunktionen in Oracle AI Database 26ai vereinfachen Zeitreihenanalysen mit Geschäftsjahren und Retail-Kalendern. Labels, Periodengrenzen und Periodenrechnungen kommen direkt aus SQL und folgen einer konsistenten Kalenderlogik. Die fachliche Definition – besonders für Geschäftsjahresstart und 53. Retail-Woche – bleibt eine bewusste Modellierungsentscheidung.
Weiterführend: Oracles Anleitung zu Kalenderfunktionen, die SQL-Referenz zu CALENDAR, FISCAL und RETAIL und die Referenz zu Periodengrenzen.