dimension_group

Utilisation

view: view_name {
  dimension_group:  field_name { ... }
}
Hiérarchie
view
dimension_group
Acceptation
Identifiant Looker (qui servira de première partie du nom de chaque dimension créée par le groupe de dimensions)

Règles spéciales
  • type peut être time ou duration.
  • Généralement utilisé avec un paramètre timeframes ou intervals
  • Utilisez un paramètre datatype si le groupe de dimensions n'est pas basé sur un champ de date et d'heure.
  • Pour les groupes de dimensions type: time, utilisez un paramètre convert_tz si vous souhaitez empêcher la conversion automatique du fuseau horaire.

Définition

Le paramètre dimension_group permet de créer un ensemble de dimensions temporelles ou de durée en une seule fois. Vous définissez le groupe de dimensions, qui crée un ensemble de dimensions individuelles pour différents intervalles ou périodes. Par exemple, vous pouvez spécifier un groupe de dimensions type: time basé sur une colonne de code temporel. Le groupe de dimensions créera les dimensions correspondantes pour exprimer les données en fonction de l'heure, de la date, de la semaine, de l'heure, du trimestre et de l'année.

La forme et la fonction du groupe de dimensions varient en fonction de la valeur type du groupe de dimensions :

Groupes de dimensions de type "Durée"

type: duration est utilisé conjointement avec dimension_group pour calculer un ensemble de dimensions de durée basées sur des intervalles.

La forme d'un groupe de dimensions de type: duration est la suivante :

dimension_group: dimension_group_name {
  type: duration
  sql_start: SQL expression ;;  # often this is a single database column
  sql_end: SQL expression ;;  # often this is a single database column
  intervals: [interval, interval, …] # see following explanation for valid intervals
}

Pour les groupes de dimensions de type: duration :

  • Les paramètres sql_start et sql_end fournissent des expressions SQL définissant l'heure de début et l'heure de fin de la durée. Pour en savoir plus, consultez la section Définir le début et la fin d'une durée sur cette page.

  • Le paramètre intervals spécifie une ou plusieurs unités d'intervalle à utiliser pour mesurer la différence de temps. Les choix possibles sont listés dans la section Options d'intervalle de cette page.

  • Les valeurs de durée sont arrondies à l'entier inférieur le plus proche.

  • Le paramètre datatype est facultatif. Si votre groupe de dimensions n'est pas basé sur une date et heure, vous pouvez spécifier un format epoch, timestamp, date ou yyyymmdd. Pour les groupes de dimensions type: duration, le paramètre datatype s'applique à la fois aux paramètres sql_start et sql_end. Assurez-vous donc que sql_start et sql_end sont tous deux du type de données spécifié. Le paramètre datatype est décrit plus en détail dans la section Spécifier la base de données datatype de cette page.

Bien qu'ils ne soient pas listés ici, de nombreux paramètres au niveau du champ peuvent également être utilisés avec les groupes de dimensions.

Par exemple, si vous avez des colonnes pour enrollment_date et graduation_date, vous pouvez créer un groupe de dimensions de durée pour voir combien de temps les élèves ont passé à l'école, calculé en intervalles de semaines et d'années :

dimension_group: enrolled {
  type: duration
  intervals: [week, year]
  sql_start: ${TABLE}.enrollment_date ;;
  sql_end: ${TABLE}.graduation_date ;;
}

Dans l'interface utilisateur Explorer, cela générerait un groupe de dimensions appelé Durée d'inscription, avec des dimensions individuelles appelées Semaines d'inscription et Années d'inscription.

Options d'intervalle

Le paramètre intervals indique au groupe de dimensions les unités d'intervalle à utiliser pour mesurer la différence de temps entre les heures sql_start et sql_end. Le paramètre intervals n'est compatible qu'avec les groupes de dimensions type: duration.

Si intervals n'est pas inclus, le groupe de dimensions inclut tous les intervalles possibles.

Les options du paramètre intervals sont les suivantes :

Intervalle Description Exemple de résultat
day Calcule une différence de temps en jours. 9 days
hour Calcule une différence de temps en heures. 171 hours
minute Calcule une différence de temps en minutes. 10305 minutes
month Calcule une différence de temps en mois. 3 months
quarter Calcule une différence de temps en trimestres. 2 quarters
second Calcule une différence de temps en secondes. 606770 seconds
week Calcule une différence de temps en semaines. 6 weeks
year Calcule une différence de temps en années. 2 years

Définir le début et la fin d'une durée

Pour les groupes de dimensions type: duration, les paramètres sql_start et sql_end fournissent les informations de début et de fin utilisées pour calculer une différence de temps. Ces champs peuvent accepter toute expression SQL valide contenant des données au format timestamp, datetime, date, epoch ou yyyymmdd. Les champs sql_start et sql_end peuvent avoir l'une des valeurs suivantes :

  • Référence à une période raw à partir d'un groupe de dimensions existant de type: time
  • Référence à une dimension de type: date_raw
  • Expression SQL qui est un code temporel, par exemple une référence à une colonne SQL qui est un code temporel
  • Expression SQL qui extrait une heure de votre base de données, en utilisant l'expression appropriée pour votre dialecte
  • Référence de champ LookML utilisant la référence de type de champ ::datetime ou ::date

Par exemple, supposons que vous disposiez d'une dimension nommée faa_event_date_raw contenant des informations de date et heure :

dimension: faa_event_date_raw {
  type: date_raw
  sql: ${TABLE}.event_date ;;
}

Vous pouvez créer un groupe de dimensions type: duration qui calcule le temps écoulé depuis la date de l'événement FAA. Pour ce faire, vous pouvez utiliser la dimension faa_event_date_raw comme heure de début du calcul, puis utiliser l'expression SQL de votre dialecte pour l'heure actuelle comme heure de fin du calcul. Voici un exemple pour une base de données MySQL :

dimension_group: since_event {
  type: duration
  intervals: [hour, day]
  sql_start: ${faa_event_date_raw} ;;
  sql_end: CURRENT_TIMESTAMP();;
}

Dans l'interface utilisateur Explorer, cela générerait un groupe de dimensions appelé Durée depuis l'événement, avec des dimensions individuelles appelées Heures depuis l'événement et Jours depuis l'événement.

Référencer des intervalles à partir d'un autre champ LookML

Pour référencer une valeur interval dans un dimension_group de type: duration, utilisez la syntaxe ${interval_fieldname}, en utilisant la version au pluriel de la valeur interval. Par exemple, dans l'exemple LookML suivant, la mesure average_days_since_event utilise ${days_since_event} pour faire référence à l'intervalle day dans le groupe de dimensions since_event :


dimension_group: since_event {
  type: duration
  intervals: [hour, day, week, month, quarter, year]
  sql_start: ${faa_event_date_raw} ;;
  sql_end: CURRENT_TIMESTAMP();;
}

measure: average_days_since_event {
  type: average
  sql: ${days_since_event} ;;
}

Utiliser les références des types de champs LookML avec les champs de durée

Pour créer un champ de durée personnalisé, vous pouvez spécifier un type de référence ::date ou ::datetime pour les dimensions référencées dans les paramètres sql_start et sql_end d'un groupe de dimensions de type: duration. La syntaxe view_name.field_name::type, décrite sur la page de documentation Intégrer SQL et faire référence aux objets LookML, vous permet de créer une version ::date ou ::datetime d'un champ sans caster les références à ces dimensions en chaînes.

Par exemple, supposons que vous disposiez d'un groupe de dimensions created de type: time avec des périodes time, date, week, month et raw, définies comme suit :


dimension_group: created {
  type: time
  timeframes: [time, date, week, month, raw]
  sql: ${TABLE}.created_at ;;
}

À l'aide des dimensions created_month et created_time, vous pouvez créer un groupe de dimensions type: duration qui calcule le temps écoulé entre une date du champ created_date et le premier jour du mois au cours duquel cette date s'est produite, en semaines, jours et heures :


dimension_group: since_first_of_month {
  type: duration
  intervals: [week, day, hour]
  sql_start: ${created_month::datetime} ;;
  sql_end: ${created_time::datetime} ;;
}

Dans l'interface utilisateur Explorer, cela crée un groupe de dimensions appelé Durée depuis le début du mois, avec les dimensions individuelles Semaines depuis le début du mois, Jours depuis le début du mois et Heures depuis le début du mois. Spécifier le type de référence ::datetime pour les champs référencés dans les paramètres sql_start et sql_end permet de traiter les dimensions created_month et created_time comme des codes temporels dans le code SQL généré.

Par exemple, supposons qu'un utilisateur sélectionne les dimensions Date de création et Jours depuis le début du mois dans le sélecteur de champ. Si l'une des valeurs renvoyées pour Date de création est 2019-03-10, la valeur renvoyée pour Jours depuis le début du mois sera 9 jours.

Groupes de dimensions de type "Heure"

type: time est utilisé conjointement avec dimension_group et le paramètre timeframes pour créer un ensemble de dimensions temporelles. Par exemple, vous pouvez facilement créer une dimension de date, de semaine et de mois à partir d'une seule colonne d'horodatage.

La forme d'un groupe de dimensions de type: time est la suivante :

dimension_group: dimension_group_name {
  type: time
  timeframes: [timeframe, timeframe, …] # see following explanation for valid timeframes
  sql: SQL expression ;;  # often this is a single database column
  datatype: epoch| timestamp | datetime | date | yyyymmdd # defaults to datetime
  convert_tz: yes | no   # defaults to yes
}

Pour les groupes de dimensions de type: time :

  • Le paramètre timeframes est facultatif, mais il est rarement ignoré. Il spécifie un ou plusieurs intervalles de temps qui doivent être générés par le groupe de dimensions. Si timeframes n'est pas inclus, toutes les options de période seront ajoutées au groupe de dimensions. Les choix possibles sont listés dans la section Options de période de cette page.

  • Le paramètre sql pour les groupes de dimensions type: time peut accepter toute expression SQL valide contenant des données au format timestamp, datetime, date, epoch ou yyyymmdd.

  • Le paramètre datatype est facultatif. Si votre groupe de dimensions n'est pas basé sur une date et heure, vous pouvez spécifier un format epoch, code temporel, date ou yyyymmdd. Pour en savoir plus, consultez la section Spécifier la base de données datatype sur cette page.

  • Le paramètre convert_tz est facultatif et vous permet d'empêcher la conversion automatique du fuseau horaire. Elle est décrite plus en détail dans la section Conversions de fuseaux horaires et convert_tz de cette page.

Bien qu'ils ne soient pas listés ici, de nombreux paramètres au niveau du champ peuvent également être utilisés avec les groupes de dimensions.

Par exemple, supposons que vous disposiez d'une colonne nommée created_at contenant des informations de date et d'heure. Vous souhaitez créer une dimension de date, de semaine et de mois basée sur cette date et heure. Vous pouvez utiliser :

dimension_group: created {
  type: time
  timeframes: [date, week, month]
  sql: ${TABLE}.created_at ;;
}

Dans l'interface utilisateur Explorer, cela générerait trois dimensions nommées Date de création, Semaine de création et Mois de création. Notez comment le nom dimension_group est combiné aux périodes pour générer les noms de dimensions.

Options de période

Le paramètre timeframes n'est compatible qu'avec les groupes de dimensions type: time. Pour les groupes de dimensions type: duration, utilisez plutôt le paramètre intervals.

Le paramètre timeframes indique au groupe de dimensions les dimensions qu'il doit produire. Il inclut les options suivantes :

Périodes spéciales

Délai Description Exemple de résultat
raw Valeur brute de votre base de données, sans conversion de type ni de fuseau horaire. raw n'est accessible que dans LookML et n'apparaît pas sur la page "Explorer". Contrairement à la plupart des autres périodes qui renvoient une chaîne formatée, la période raw renvoie un code temporel. Il est principalement utilisé pour effectuer des opérations de date sur un champ. 2014-09-03 17:15:00 +0000
yesno Dimension yesno qui renvoie "Oui" si la date et l'heure ont une valeur, et "Non" dans le cas contraire. Contrairement aux autres périodes, lorsque vous faites référence à une dimension de période yesno à partir d'un autre champ, n'incluez pas la période dans la référence. Par exemple, pour faire référence à une période yesno dans dimension_group: created, utilisez la syntaxe ${created} et non ${created_yesno}. Yes

Périodes

Délai Description Exemple de résultat
time Date et heure du champ sous-jacent (certains dialectes SQL affichent la précision de votre base de données, tandis que d'autres n'affichent que les secondes) 2014-09-03 17:15:00
time_of_day Heure de la journée 17:15
hour Date et heure tronquées à l'heure la plus proche 2014-09-03 17
hour_of_day Heure entière de la journée du champ sous-jacent 17
hourX Divise chaque jour en intervalles du nombre d'heures spécifié. Consultez Utiliser hourX.
minute Date et heure tronquées à la minute la plus proche 2014-09-03 17:15
minuteX Divise chaque heure en intervalles du nombre de minutes spécifié. Consultez Utiliser minuteX.
second Date et heure tronquées à la seconde la plus proche 2014-09-03 17:15:00
millisecond Date et heure tronquées à la milliseconde la plus proche (pour en savoir plus sur la compatibilité des dialectes, consultez la section Compatibilité des dialectes pour les millisecondes et les microsecondes sur cette page). 2014-09-03 17:15:00.000
millisecondX Divise chaque seconde en intervalles avec le nombre de millisecondes spécifié (pour en savoir plus sur la compatibilité des dialectes, consultez la section Compatibilité des dialectes pour les millisecondes et les microsecondes sur cette page). Consultez Utiliser millisecondX.
microsecond Date et heure tronquées à la microseconde la plus proche (pour en savoir plus sur la compatibilité des dialectes, consultez la section Compatibilité des dialectes pour les millisecondes et les microsecondes sur cette page). 2014-09-03 17:15:00.000000

Périodes

Délai Description Exemple de résultat
date Date du champ sous-jacent 2017-09-03

Périodes hebdomadaires

Délai Description Exemple de résultat
week Date de la semaine commençant un lundi de la date et heure sous-jacentes 2017-09-01
day_of_week Jour de la semaine seul Wednesday
day_of_week_index Index du jour de la semaine (0 = lundi, 6 = dimanche) 2

Périodes mensuelles

Délai Description Exemple de résultat
month Année et mois de la date et heure sous-jacentes 2014-09
month_num Nombre entier du mois de la date et heure sous-jacentes 9
fiscal_month_num Nombre entier du mois fiscal de la date et heure sous-jacentes 6
month_name Nom du mois September
day_of_month Jour du mois 3

Pour utiliser les périodes fiscal_month_num, le paramètre fiscal_month_offset doit être défini dans le modèle.

Périodes trimestrielles

Délai Description Exemple de résultat
quarter Année et trimestre de la date et heure sous-jacentes 2017-Q3
fiscal_quarter Année et trimestre fiscaux de la valeur datetime sous-jacente 2017-Q3
quarter_of_year Trimestre de l'année précédé d'un "T" Q3
fiscal_quarter_of_year Trimestre fiscal de l'année précédé d'un "T" Q3

Pour utiliser les périodes fiscal_quarter et fiscal_quarter_of_year, le paramètre fiscal_month_offset doit être défini dans le modèle.

Périodes annuelles

Délai Description Exemple de résultat
year Année entière de la date et heure sous-jacentes 2017
fiscal_year Année fiscale (nombre entier) de la date et heure sous-jacentes FY2017
day_of_year Jour de l'année 143
week_of_year Semaine de l'année sous forme de nombre 17

Pour utiliser le délai fiscal_year, le paramètre fiscal_month_offset doit être défini dans le modèle.

Utiliser hourX

Dans hourX, X est remplacé par 2, 3, 4, 6, 8 ou 12.

Chaque jour sera divisé en intervalles du nombre d'heures spécifié. Par exemple, hour6 divisera chaque jour en segments de six heures, qui s'afficheront comme suit :

  • 2014-09-01 00:00:00
  • 2014-09-01 06:00:00
  • 2014-09-01 12:00:00
  • 2014-09-01 18:00:00

Par exemple, une ligne avec un time de 2014-09-01 08:03:17 aurait un hour6 de 2014-09-01 06:00:00.

Utiliser minuteX

Dans minuteX, X est remplacé par 2, 3, 4, 5, 6, 10, 12, 15, 20 ou 30.

Chaque heure sera divisée en intervalles de la durée spécifiée. Par exemple, minute15 divisera chaque heure en segments de 15 minutes, qui s'afficheront comme suit :

  • 2014-09-01 01:00:00
  • 2014-09-01 01:15:00
  • 2014-09-01 01:30:00
  • 2014-09-01 01:45:00

Par exemple, une ligne avec un time de 2014-09-01 01:17:35 aurait un minute15 de 2014-09-01 01:15:00.

Utiliser millisecondX

Dans millisecondX, X est remplacé par 2, 4, 5, 8, 10, 20, 25, 40, 50, 100, 125, 200, 250 ou 500.

Chaque seconde sera divisée en intervalles avec le nombre de millisecondes spécifié. Par exemple, millisecond250 divisera chaque seconde en segments de 250 millisecondes, qui s'afficheront comme suit :

  • 2014-09-01 01:00:00.000
  • 2014-09-01 01:00:00.250
  • 2014-09-01 01:00:00.500
  • 2014-09-01 01:00:00.750

Par exemple, une ligne avec un time de 2014-09-01 01:00:00.333 aurait un millisecond250 de 2014-09-01 01:00:00.250.

Conversions de fuseaux horaires et convert_tz

En général, les calculs de temps (différences, durées, etc.) ne fonctionnent correctement que lorsque vous effectuez des opérations sur des valeurs temporelles qui sont toutes converties dans le même fuseau horaire. Il est donc important de garder les fuseaux horaires à l'esprit lorsque vous écrivez du code LookML.

Looker propose différents paramètres de fuseau horaire qui convertissent les données temporelles entre différents fuseaux horaires. Looker effectue la conversion du fuseau horaire par défaut. Le paramètre convert_tz est accepté pour les groupes de dimensions type: time. Si vous ne souhaitez pas que Looker effectue une conversion de fuseau horaire pour une dimension ou un groupe de dimensions spécifique, vous pouvez utiliser le paramètre convert_tz décrit sur la page de documentation du paramètre convert_tz.

Prise en charge des dialectes pour les millisecondes et les microsecondes

Looker accepte une précision des périodes jusqu'à la microseconde. Toutefois, certaines bases de données n'acceptent qu'une précision à la seconde. Si une base de données rencontre un intervalle de temps plus précis que ce qu'elle peut prendre en charge, elle l'arrondit à la seconde supérieure.

Dans la dernière version de Looker, les dialectes suivants acceptent les millisecondes :

Dialecte Compatibilité
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13+
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 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

Dans la dernière version de Looker, les dialectes suivants acceptent les microsecondes :

Dialecte Compatibilité
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13+
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 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

Spécifier la base de données datatype

Le paramètre datatype vous permet de spécifier le type de données temporelles de la table de votre base de données que vous fournissez au groupe de dimensions. Cela peut améliorer les performances des requêtes.

Pour les groupes de dimensions type: time, le paramètre datatype s'applique au paramètre sql du groupe de dimensions.

Pour les groupes de dimensions type: duration, le paramètre datatype s'applique à la fois aux paramètres sql_start et sql_end. Assurez-vous donc que sql_start et sql_end sont tous deux du type de données spécifié.

Le paramètre datatype accepte les valeurs suivantes :

  • epoch : champ d'époque SQL (c'est-à-dire un entier représentant le nombre de secondes depuis l'époque Unix).
  • date : champ de date SQL (c'est-à-dire un champ qui ne contient pas d'informations sur l'heure de la journée).
  • datetime : champ SQL datetime.
  • timestamp : champ d'horodatage SQL.
  • yyyymmdd : champ SQL contenant un entier représentant une date au format AAAAMMJJ.

La valeur par défaut de datatype est timestamp.

Exemples

Supposons que vous disposiez d'une colonne nommée created_at contenant des informations de date et d'heure. Vous souhaitez créer une dimension de date, de semaine et de mois basée sur cette date et heure. Vous pouvez utiliser :

dimension_group: created {
  type: time
  timeframes: [date, week, month]
  sql: ${TABLE}.created_at ;;
}

-

Dans l'interface utilisateur Explorer, cela générerait trois dimensions nommées Date de création, Semaine de création et Mois de création. Notez comment le nom dimension_group est combiné aux périodes pour générer les noms de dimensions.

Éléments à prendre en compte

Les groupes de dimensions doivent être référencés par leurs dimensions individuelles.

Étant donné qu'un groupe de dimensions représente un groupe de dimensions, et non une seule dimension, vous ne pouvez pas y faire référence directement dans LookML. Vous devrez plutôt vous référer aux dimensions qu'il crée.

Prenons l'exemple du groupe de dimensions suivant :

dimension_group: created {
  type: time
  timeframes: [date, week, month]
  sql: ${TABLE}.created_at ;;
}

Pour faire référence à l'une de ces dimensions dans un autre champ LookML, utilisez la référence ${created_date}, ${created_week} ou ${created_month}. Si vous essayez d'utiliser uniquement ${created}, Looker ne saura pas à quelle période vous faites référence et une erreur se produira.

Pour la même raison, vous ne devez pas utiliser le paramètre primary_key sur un groupe de dimensions si vous spécifiez plusieurs timeframe.

Conseil de l'équipe de chat : Nous sommes souvent interrogés sur l'erreur de validation qui peut se produire si vous utilisez primary_key sur un dimension_group avec plusieurs timeframe. Pour en savoir plus, consultez le post sur les périodes et les groupes de dimensions dans Looker sur le forum de la communauté.

Données d'horodatage incluant des informations sur le fuseau horaire

Certains dialectes de base de données proposent des options d'horodatage qui incluent des informations sur le fuseau horaire. Cela vous permet de stocker des données d'horodatage dans un seul champ pouvant comporter plusieurs fuseaux horaires. Une ligne de données peut être stockée en UTC, une autre en heure de l'Est. Par exemple, consultez la documentation sur les codes temporels TIMESTAMP_LTZ, TIMESTAMP_NTZ, TIMESTAMP_TZ de Snowflake pour en savoir plus sur les options de code temporel du dialecte Snowflake.

Dans ce cas, des erreurs peuvent se produire lorsque Looker effectue des conversions de fuseaux horaires. Pour éviter cela, dans le paramètre sql de la dimension, vous devez caster explicitement les données de code temporel vers un type de code temporel qui n'effectue pas de conversion de fuseau horaire. Par exemple, dans le dialecte Snowflake, vous pouvez utiliser la fonction TO_TIMESTAMP pour caster les données de code temporel.

Vous pouvez créer des dimensions temporelles ou de durée individuelles.

Vous pouvez créer une dimension pour chaque période ou durée que vous souhaitez inclure, au lieu de les générer toutes dans un seul dimension_group. En général, vous pouvez éviter de créer des dimensions individuelles, sauf si vous souhaitez modifier la convention de dénomination des périodes de Looker ou si vous avez déjà précalculé des colonnes temporelles dans votre base de données. Pour en savoir plus, consultez la page de documentation Types de dimensions, de filtres et de paramètres.

Vous pouvez modifier le premier jour de la semaine.

Par défaut, les semaines dans Looker commencent le lundi. Vous pouvez modifier cette valeur à l'aide du paramètre week_start_day au niveau du modèle.

N'oubliez pas que week_start_day ne fonctionne pas avec la période week_of_year, car celle-ci est basée sur la norme ISO, qui utilise des semaines commençant le lundi.

Les filtres et champs personnalisés ne sont pas compatibles avec toutes les périodes

Les périodes day_of_week, fiscal_quarter_of_year, millisecond, millisecondX, microsecond, month_name, quarter_of_year et time_of_day ne sont pas compatibles avec les filtres personnalisés ni les champs personnalisés.

Les intervalles de mois, de trimestre et d'année ne comptent que les périodes complètes.

L'intervalle month d'un groupe de dimensions duration ne considère qu'un mois comme écoulé si le jour de fin est supérieur ou égal au jour de début. Exemple :

  • La différence en mois entre le 26 septembre et le 25 octobre de la même année est de 0.
  • La différence en mois entre le 26 septembre et le 26 octobre de la même année est de 1.

Les intervalles quarter et year suivent la même logique.