Benutzerdefinierte Kalender in Looker verwenden

Bei Dialekten, die diese Funktion unterstützen, können Sie mit der Funktion für benutzerdefinierte Kalender in Looker einen benutzerdefinierten Kalender in Ihrer Datenbank definieren, z. B. einen bestimmten Geschäfts- oder Einzelhandelskalender, und ihn dann auf eine datumsbasierte Dimensionsgruppe in Ihrem LookML-Modell anwenden. Ihre Nutzer können dann Explore-Abfragen mit Ihren benutzerdefinierten Zeiträumen wie custom_week und custom_period erstellen, als wären es Standardzeiträume.

Vorbereitung

Bevor Sie benutzerdefinierte Kalender verwenden, müssen die folgenden Voraussetzungen erfüllt sein:

Benutzerdefinierten Kalender erstellen

Um einen benutzerdefinierten Kalender zu implementieren, müssen Sie die folgenden allgemeinen Schritte ausführen, die in den folgenden Abschnitten beschrieben werden:

  1. Kalendertabelle in der Datenbank erstellen
  2. Benutzerdefinierte Kalenderansicht in LookML definieren
  3. Benutzerdefinierte Dimensionsgruppe für Kalender erstellen

Kalendertabelle in der Datenbank erstellen

Um Daten für benutzerdefinierte Kalender zu berechnen, benötigt Looker eine spezielle Kalendertabelle in Ihrer Datenbank, in der Ihre benutzerdefinierten Zeiträume definiert sind. Die Tabelle muss eine Spalte mit dem Referenzdatum enthalten, in der das Standardkalenderdatum verwendet wird. Looker verknüpft Ihre Kalendertabelle anhand der Spalte mit dem Referenzdatum mit Ihren Datentabellen, z. B. einer Tabelle orders.

Die Spaltennamen in der Kalendertabelle sind flexibel. Wenn Sie die benutzerdefinierte Kalenderansicht in LookML definieren, verwenden Sie den Block calendar_definition, um die Spalten in Ihrer Datenbank den Namen der benutzerdefinierten Standardzeiträume zuzuordnen.

Hier sehen Sie ein Beispiel für ein Tabellenschema für eine Kalendertabelle mit dem Namen fiscal_calendar_table.

Spaltenname Datentyp Beschreibung
reference_date DATE Das Standardkalenderdatum, z. B. „2023-01-01“. Wird für Verknüpfungen verwendet. Sollte ein eindeutiger oder Primärschlüssel sein.
fiscal_year VARCHAR Das Geschäftsjahr, z. B. „GJ2023“.
fiscal_year_num INTEGER Das numerische Geschäftsjahr, z. B. 2023.
fiscal_quarter_of_year VARCHAR Das Geschäftsquartal, z. B. „GQ1“.
fiscal_quarter_of_year_num INTEGER Das numerische Geschäftsquartal, z. B. 1.
fiscal_week_of_year VARCHAR Die Geschäftswoche des Jahres, z. B. „Woche01“, „GW01“.
fiscal_week_of_year_num INTEGER Die numerische Geschäftswoche des Jahres, z. B. 1.
fiscal_period_of_year VARCHAR Ein benutzerdefinierter Zeitraumname, z. B. „Z01“.
fiscal_period_of_year_num INTEGER Der numerische benutzerdefinierte Zeitraum, z. B. 1.
season VARCHAR Ein benutzerdefinierter Saisonname, z. B. „Winter“.
season_num INTEGER Die numerische benutzerdefinierte Saison, z. B. 1.
prev_week_num INTEGER Der Ordninalwert für die Vorwoche, z. B. 52 oder 53. Looker benötigt diesen Wert, um periodenbezogene Messwerte zu berechnen, wenn die aktuelle Woche 1 ist und die Vorwoche in Ihrem Kalender nicht 52. Die Verwendung von prev_week_num ist nur erforderlich, wenn Sie periodenbezogene Messwerte mit benutzerdefinierten Kalendern verwenden möchten und Ihr benutzerdefinierter Kalender nicht 52 Wochen hat.
prev_day_num INTEGER Der Ordninalwert für den Vortag, z. B. 364 oder 371. Looker benötigt diesen Wert, um periodenbezogene Messwerte zu berechnen, wenn der aktuelle Tag 1 ist und der Vortag in Ihrem Kalender nicht 364. Die Verwendung von prev_day_num ist nur erforderlich, wenn Sie periodenbezogene Messwerte mit benutzerdefinierten Kalendern verwenden möchten und Ihr benutzerdefinierter Kalender nicht 364 Tage hat.

Hier einige Beispielzeilen aus der Tabelle fiscal_calendar_table:

reference_date fiscal_year fiscal_year_num fiscal_period fiscal_period_num prev_week_num prev_day_num
2023-12-25 FY2024 2024 P01 1 51 358
2023-12-26 FY2024 2024 P01 1 51 359
2024-01-01 FY2024 2024 P02 2 52 364
2024-01-02 FY2024 2024 P02 2 52 1

Benutzerdefinierte Kalenderansicht in LookML definieren

Nachdem Sie eine Kalendertabelle in Ihrer Datenbank erstellt haben, müssen Sie eine LookML-Ansicht erstellen, um die Datenbank-Kalendertabelle zu modellieren.

Die benutzerdefinierte Kalenderansichtsdatei muss Folgendes enthalten:

  • Den sql_table_name Parameter, der auf die benutzerdefinierte Kalendertabelle in Ihrer Datenbank verweist.
  • Den calendar_definition Block, um die Spalten Ihrer Tabelle den benutzerdefinierten Zeitraumtypen von Looker zuzuordnen.
  • dimension -Parameter, um die Spalten der benutzerdefinierten Kalendertabelle in Ihrer Datenbank zu modellieren.

Hier sehen Sie eine Beispielansichtsdatei mit dem Namen fiscal_calendar.view.lkml, die die Beispiel-fiscal_calendar_table modelliert:

view: fiscal_calendar {
  sql_table_name: fiscal_calendar_table ;;
  calendar_definition: {
    reference_date: reference_date
    timeframe_mapping: {
      custom_year: fiscal_year
      custom_quarter: fiscal_quarter_of_year
      custom_date: fiscal_date
      custom_week: fiscal_week_of_year
      custom_period: fiscal_period_of_year
      custom_season: season
    }
    timeframe_ordinal_mapping: {
      custom_year: fiscal_year_num
      custom_quarter: fiscal_quarter_of_year_num
      custom_date: fiscal_date_num
      custom_week: fiscal_week_of_year_num
      custom_period: fiscal_period_of_year_num
      custom_season: season_num
    }
    previous_ordinal_mapping: {
      custom_week: prev_week_num
      custom_date: prev_day_num
    }
  }

  dimension: reference_date {
    type: date
    primary_key: yes
    sql: ${TABLE}.reference_date ;; # Assuming column name is reference_date
  }

  dimension: fiscal_date {
  type: string
  sql: FORMAT_TIMESTAMP('%Y-%m-%d', ${TABLE}.reference_date) ;;
}

  dimension: fiscal_year {
    type: string
    sql: ${TABLE}.fiscal_year ;;
  }

  dimension: fiscal_year_num {
    type: number
    sql: ${TABLE}.fiscal_year_num ;;
  }

  # ... other dimensions for quarters, weeks, periods, seasons, etc. ...

  # Example placeholder dimensions for unused timeframes
  dimension: season {
    type: string
    sql: 'N/A' ;;
    hidden: yes
  }
  dimension: season_num {
    type: number
    sql: 0 ;;
    hidden: yes
  }
}

Weitere Informationen zu den calendar_definition-Parametern finden Sie auf der calendar_definition-Parameterseite.

Benutzerdefinierte Dimensionsgruppe für Kalender erstellen

Nachdem Sie eine Kalendertabelle in Ihrer Datenbank erstellt und die Datenbank-Kalendertabelle in LookML modelliert haben, können Sie eine Dimensionsgruppe vom Typ type: custom_calendar erstellen, die auf der benutzerdefinierten Kalenderansicht basiert.

Hier sehen Sie beispielsweise eine Ansichtsdatei mit dem Namen orders.view.lkml, in der eine benutzerdefinierte Dimensionsgruppe für Kalender definiert ist.

include: "/views/fiscal_calendar.view"

view: orders {
  sql_table_name: public.orders ;;

  dimension_group: created {
    type: custom_calendar

    # Optional list of allowed timeframes
    custom_timeframes: [
      custom_date,
      custom_week,
      custom_year
    ]
    sql: ${TABLE}.created_at ;;
    based_on_calendar: fiscal_calendar  # This links to your calendar view
  }
}

Mit diesem LookML-Code erstellt Looker automatisch eine neue Gruppe benutzerdefinierter Zeiträume für die Dimensionsgruppe created, z. B. „Erstellt – benutzerdefiniertes Jahr“ und „Erstellt – benutzerdefinierte Woche“. Nutzer können diese Felder dann für Analysen, Berichte und Filter verwenden.

Weitere Informationen zum Erstellen einer Dimensionsgruppe für benutzerdefinierte Kalender finden Sie auf der dimension_group Dokumentationsseite.

Wichtige Punkte

Beachten Sie die folgenden Einschränkungen bei benutzerdefinierten Kalendern:

  • Gefilterte Messwerte: Benutzerdefinierte Kalender werden für gefilterte Messwerte nicht unterstützt. Sie können in der filters-Parameter eines Messwerts nicht auf eine benutzerdefinierte Kalenderdimension verweisen.
  • Erweiterte Filter: Benutzerdefinierte Kalender werden in erweiterten Filtern nicht unterstützt. Sie können in Looker-Filterausdrücken nicht auf eine benutzerdefinierte Kalenderdimension verweisen.
  • Symmetrische Aggregate: In einigen komplexen Join-Szenarien werden symmetrische Aggregate für Abfragen mit benutzerdefinierten Kalenderdimensionen möglicherweise nicht vollständig unterstützt.
  • Dimensionsfüllung:Looker kann fehlende Daten für benutzerdefinierte Kalenderdimensionen nicht mit Dimensionsfüllung ergänzen.
  • Filterung über Kalendergrenzen hinaus:Wenn ein Filter auf einen benutzerdefinierten Zeitraum angewendet wird, der zu einem Datum führt, das nicht im Kalender enthalten ist, werden möglicherweise unerwartete Ergebnisse zurückgegeben. Das liegt an der Ordninalarithmetik, die zur Berechnung des Beginns eines Zeitraums verwendet wird.
  • OR Filter: OR Filter werden für Abfragen mit benutzerdefinierten Kalendern nicht unterstützt.
  • Verhalten bei der Zeitzonenkonvertierung:Looker berücksichtigt die vorhandene Semantik für die Zeitzonenkonvertierung. Wenn die Zeitzone der Datenbank und die Zeitzone der Abfrage übereinstimmen, wird keine Zeitzonenkonvertierung angewendet. Wenn sie nicht übereinstimmen, wendet Looker die Zeitzonenkonvertierung an. Sie können dieses Verhalten überschreiben, indem Sie convert_tz: no für Ihre benutzerdefinierte Kalenderdimensionsgruppe angeben.
  • Standardmäßige Sortierung:Looker wendet eine Standardsortierung auf das erste Datumsfeld an, wenn benutzerdefinierte Kalenderfelder ausgewählt werden. Der Nutzer kann dann eine andere Datensortierung angeben.
  • Benutzerdefinierte Kalenderfilter:Benutzerdefinierte Kalenderdimensionen unterstützen bestimmte Filteroptionen, z. B. in den letzten 3 benutzerdefinierten Jahren oder ist dieser benutzerdefinierte Zeitraum. Weitere Informationen finden Sie im Abschnitt Benutzerdefinierte Kalenderfilter auf der Dokumentationsseite Daten filtern und begrenzen.

Unterstützte Datenbankdialekte für benutzerdefinierte Kalender

In der folgenden Tabelle ist zu sehen, welche Dialekte benutzerdefinierte Kalender in der aktuellen Version von Looker unterstützen:

Dialekt Unterstützt?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica