Types de dimensions, de filtres et de paramètres

Cette page fait référence au paramètre type qui fait partie d'une dimension ou d'un filtre.

type peut également être utilisé dans une mesure, décrite sur la page de documentation Types de mesures.

type peut également être utilisé dans un groupe de dimensions, comme décrit sur la page de documentation sur les paramètres dimension_group.

Utilisation

view_name {
dimension: field_name {
type: field_type
}
}

Hiérarchie Afficher le fichier view Type de champ type

Types de champs possibles Dimension, Filtre, Paramètre Valeur par défaut string Acceptation Une dimension, un filtre ou un type de paramètre

Cette page contient des informations supplémentaires sur les différents types pouvant être attribués à un dimension, à filter ou à parameter. Une dimension, un filtre ou un paramètre ne peuvent avoir qu'un seul type, qui est string par défaut si aucun type n'est spécifié.

Certains types sont associés à des paramètres qui sont décrits dans la section appropriée.

Définitions de types

D = Dimension

DG = groupe de dimensions

F = Filtre

P = paramètre

Type	Description	Types de champs valides
bin	ADDED 21.14 Pour les champs qui regroupent des valeurs numériques en plusieurs plages	J
date	Pour les champs contenant des dates	D F P
date_time	Pour les champs contenant des dates et des heures	D F P
distance	Pour les champs qui calculent la distance du tracé le plus direct ("à vol d'oiseau") entre deux dimensions type: location	J
duration	Utilisé avec un dimension_group pour créer plusieurs dimensions basées sur la durée à partir d'une seule colonne de tableau. Pour en savoir plus sur les groupes de dimensions, consultez la page de documentation sur les paramètres dimension_group.	DG
location	Pour les champs basés sur la latitude et la longitude, qui seront utilisés dans les visualisations	J
number	Pour les champs contenant des chiffres	D F P
string	Pour les champs contenant des lettres ou des caractères spéciaux	D F P
tier	Pour les champs qui regroupent des valeurs numériques en plusieurs plages	J
time	Utilisé avec un dimension_group pour créer plusieurs dimensions temporelles à partir d'une seule colonne de tableau. Pour en savoir plus sur les groupes de dimensions, consultez la page de documentation sur les paramètres dimension_group.	DG
unquoted	Pour les champs parameter dont les valeurs seront insérées directement dans SQL et ne doivent donc pas être placées entre guillemets (comme c'est le cas avec type: string).
yesno	Pour les champs indiquant si une information est vraie ou fausse	D F P
zipcode	Pour les champs qui contiennent un code postal et qui seront utilisés dans les visualisations	J
Types d'heures et de dates individuels	Alternative rarement utilisée à la type: time pour créer des dimensions uniques basées sur le temps	D F
Types de durées individuelles	Une alternative rarement utilisée à la type: duration pour créer des dimensions à heure unique qui calculent les différences de temps	J
int	REMOVED 5.4 Remplacer par type: number	J

bin

type: bin est un alias pour type: tier. Les deux types peuvent être utilisés de manière interchangeable.

type: bin est utilisé avec le paramètre bins pour séparer une dimension numérique en un ensemble de plages de nombres. Par exemple, vous pouvez répartir une variable d'âge dans différentes tranches d'âge. Vous pouvez modifier l'affichage des bins dans l'interface utilisateur de Looker à l'aide du paramètre style.

Le schéma d'utilisation est le suivant:

view_name {
dimension: field_name {
type: bin
bins: [numeric_value, numeric_value, ... ]
style: interval
sql: ${my_field_name};
;
;

Le paramètre sql des dimensions type: bin peut utiliser n'importe quelle expression SQL valide générant un nombre ou un entier.

L'exemple d'âge ci-dessus peut se présenter comme suit:

dimension: age_bin {
  type: bin
  bins: [0, 10, 20, 30, 40, 50, 60, 70, 80, 90]
  style: interval
  sql: ${age} ;;
}

La manière dont cela apparaîtra dans l'interface utilisateur de Looker est décrite dans la section style du paramètre type: tier de cette page.

Le type bin est un alias pour type: tier. Les deux types peuvent être utilisés de manière interchangeable, et le comportement est le même pour les deux:

• Le sous-paramètre style permet de personnaliser l'apparence des bins dans l'interface utilisateur de Looker.
• Dimensions of type: bin ne peut pas être utilisé dans les filtres personnalisés.
• L'utilisation de type: bin en association avec le remplissage de dimension peut entraîner des buckets de niveau inattendus.

distance

type: distance permet de calculer la distance entre le chemin le plus direct ("à vol d'oiseau") entre deux dimensions type: location.

Le paramètre sql des dimensions type: distance est exclu. Vous devez plutôt faire référence à une dimension type: location dans les paramètres start_location_field et end_location_field.

L'utilisation est la suivante:

view_name :

; champ : field_name

L'unité de distance est déterminée par le paramètre units, qui peut prendre les valeurs suivantes:

• feet
• kilometers
• meters
• miles
• nautical_miles
• yards

Par exemple, vous pouvez calculer la distance parcourue par un client pour récupérer une location, comme ceci:

dimension: distance_to_pickup {
  type: distance
  start_location_field: customer.home_location
  end_location_field: rental.pickup_location
  units: miles
}

La distance calculée est le tracé le plus direct entre les deux points, pas nécessairement la distance parcourue par la route.

N'utilisez pas la syntaxe ${view_name.field_name} dans les paramètres start_location_field et end_location_field. Utilisez plutôt le nom de la vue et le nom du champ, par exemple view_name.field_name.

duration

type: duration est utilisé avec un dimension_group pour créer un ensemble de différences de temps calculées entre des dimensions et/ou des expressions SQL.

type: duration ne fonctionne qu'avec un dimension_group et ne fonctionne pas avec un dimension standard. Vous pouvez toutefois spécifier des dimensions basées sur la durée, comme expliqué dans cette section ci-dessous.

Pour en savoir plus sur les groupes de dimensions avec type: duration, consultez la page de documentation sur les paramètres dimension_group.

location

type: location est utilisé avec les paramètres sql_latitude et sql_longitude pour créer des coordonnées que vous souhaitez représenter sur une visualisation Map ou Static Map (points) (utilisez un champ d'état ou de pays pour Static Map (Regions)), ou que vous souhaitez utiliser dans un calcul type: distance.

Le schéma d'utilisation est le suivant:

view_name :

dimension: field_name

Le paramètre sql des dimensions type: location est exclu. Vous devez à la place fournir toute expression SQL valide qui entraîne une latitude ou une longitude décimale aux paramètres sql_latitude et sql_longitude. Il s'agit généralement de références aux champs LookML qui contiennent des informations de latitude ou de longitude, mais il peut s'agir de valeurs statiques si vous souhaitez indiquer l'emplacement de votre siège social ou d'autres éléments sur ces lignes.

Par exemple, vous pouvez créer une dimension store_location comme suit:

dimension: store_location {
  type: location
  sql_latitude: ${store_latitude} ;;
  sql_longitude: ${store_longitude} ;;
}

Si vous ne souhaitez pas représenter graphiquement les lieux ni calculer les distances, vous pouvez utiliser un type plus simple tel que type: number. Lorsque vous affichez un établissement dans un tableau, celui-ci affiche la valeur de votre base de données et génère automatiquement un lien vers cet établissement dans Google Maps:

Dialectes de base de données compatibles avec location

Pour que Looker soit compatible avec type: location dans votre projet Looker, le dialecte de votre base de données doit également être compatible. Le tableau suivant présente les dialectes compatibles avec type: location dans la dernière version de Looker:

number

type: number est utilisé avec des nombres ou des entiers.

Le paramètre sql des dimensions type: number peut utiliser n'importe quelle expression SQL valide générant un nombre ou un entier.

Vous pouvez mettre en forme les champs type: number à l'aide des paramètres value_format ou value_format_name.

Par exemple, le modèle LookML suivant crée un champ appelé profit basé sur les champs revenue et cost, puis l'affiche au format monétaire (1 234,56 $):

dimension: profit {
  type: number
  sql: ${revenue} - ${cost} ;;
  value_format_name: usd
}

Une dimension ne peut effectuer des opérations arithmétiques que sur d'autres dimensions, et non sur des mesures. En outre, les dimensions type: number ne fournissent pas de suggestions aux utilisateurs, même si vous les utilisez pour afficher des ID.

string

type: string est généralement utilisé avec des champs contenant des lettres ou des caractères spéciaux. Il peut également être utilisé avec des champs numériques. Toutefois, Looker offre de meilleures fonctionnalités pour gérer les nombres si vous utilisez type: number à la place.

Le paramètre sql des dimensions type: string peut utiliser n'importe quelle expression SQL valide.

Par exemple, le LookML suivant crée le champ full_name en combinant un champ appelé first_name et last_name :

dimension: full_name {
  type: string
  sql: CONCAT(${first_name}, ' ', ${last_name}) ;;
}

Dans cet exemple, type: string peut être omis, car string est la valeur par défaut pour type.

tier

Vous pouvez utiliser type: bin comme alias pour type: tier. Les deux types peuvent être utilisés de manière interchangeable.

type: tier est utilisé avec le paramètre tiers pour séparer une dimension numérique en un ensemble de plages de nombres. Par exemple, vous pouvez classer une dimension "Âge" en différentes tranches d'âge. Vous pouvez modifier l'apparence des niveaux dans l'interface utilisateur de Looker à l'aide du paramètre style.

Le schéma d'utilisation est le suivant:

view_name {
dimension: field_name {
type: tier
niveaux: [numeric_value, numeric_value, ... ]
style : interval
sql : ${my_field_name};

Le paramètre sql des dimensions type: tier peut utiliser n'importe quelle expression SQL valide générant un nombre ou un entier.

L'exemple d'âge ci-dessus peut se présenter comme suit:

dimension: age_tier {
  type: tier
  tiers: [0, 10, 20, 30, 40, 50, 60, 70, 80]
  style: classic # the default value, could be excluded
  sql: ${age} ;;
}

La manière dont cela apparaîtra dans l'interface utilisateur de Looker est décrite dans la section style de cette page.

Les dimensions de type: tier ne peuvent pas être utilisées dans les filtres personnalisés.

style

Le paramètre style vous permet de modifier l'apparence des niveaux dans l'interface utilisateur de Looker. Bien que les exemples ci-dessous ne présentent pas cette hypothèse, si les données contiennent des nombres négatifs, il existe un niveau de départ qui inclut tous les nombres compris entre l'infini négatif et 0. Quatre valeurs sont possibles:

• classic (valeur par défaut)
• interval
• integer
• relational

classic

style: classic est la valeur par défaut et ressemble à ceci:

• Vous pouvez interpréter cette notation de niveau comme suit:
• T02 [10,20) est la plage comprise entre 10 et 20, mais pas plus
• T09 [80,inf) est la plage (comprise entre 80 et l'infini)

interval

style: interval est semblable à style: classic, mais il n'est pas précédé des libellés TXX. Il ressemble à:

integer

style: integer doit être utilisé avec des valeurs entières discrètes (comme l'âge). Si vous essayez d'utiliser des nombres non entiers pour définir les niveaux, vous recevrez un message d'erreur. Ce style se présente comme suit:

relational

Il est préférable d'utiliser style: relational avec des nombres continus (dollars, par exemple) et ressemble à ceci:

Vous pouvez également appliquer un style aux niveaux avec value_format. Exemple :

dimension: amount_tier {
  type: tier
  tiers: [0, 10, 20, 30, 40, 50, 60, 70, 80]
  style: integer
  sql: ${amount} ;;
  value_format: "$#,##0"
}

Dans cet exemple, des étiquettes de niveau telles que $10 to $19, $20 to $29, etc. sont générées.

Éléments à prendre en compte

L'utilisation de tier en association avec le remplissage de dimension peut entraîner des buckets de niveau inattendus.

Par exemple, la dimension Tranche d'âge de la dimension type: tier affiche les buckets de niveau Inférieur à 0 et 0 – 9 lorsque le remplissage de dimension est activé, bien que les données n'incluent pas les valeurs d'âge pour ces segments:

Lorsque le remplissage de dimension est désactivé pour la tranche d'âge, les segments reflètent plus précisément les valeurs d'âge disponibles dans les données:

Vous pouvez activer ou désactiver le remplissage de dimension en passant la souris sur le nom de la dimension dans l'onglet "Explorer", en cliquant sur l'icône en forme de roue dentée au niveau du champ, puis en sélectionnant Supprimer les valeurs renseignées par niveau ou Remplir les valeurs de niveau manquantes pour l'activer.

time

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 "Date", "Semaine" et "Mois" basée sur une seule colonne d'horodatage.

type: time ne fonctionne qu'avec un dimension_group et ne fonctionne pas avec un dimension standard. Toutefois, vous pouvez spécifier des dimensions temporelles individuelles, comme expliqué dans cette section ci-dessous.

Pour en savoir plus sur les groupes de dimensions, consultez la page de documentation sur les paramètres dimension_group. Vous y trouverez également des informations sur les paramètres timeframes, convert_tz et datatype, ainsi que sur les problèmes courants et les mises en garde à prendre en compte lorsque vous utilisez des données temporelles.

unquoted

type: unquoted n'est utilisé qu'avec les champs parameter. Le type unquoted est semblable à type: string, sauf que lorsque la valeur de parameter est insérée dans la variable liquide, elle n'est pas placée entre guillemets. Cela est utile lorsque vous insérez des valeurs dans SQL, telles que des noms de colonnes ou de tables, qui ne peuvent pas être placées entre guillemets pour fonctionner correctement.

L'insertion de valeurs sans guillemets directement dans SQL peut entraîner des actions SQL indésirables. Pour résoudre ce problème, les valeurs de paramètre de type: unquoted sont limitées aux caractères A à Z et 0 à 9 (sans espaces ni autres caractères spéciaux).

À titre d'exemple, le LookML suivant crée une parameter appelée table_name qui produira une valeur sans guillemets:

parameter: table_name {
  type: unquoted
}

yesno

type: yesno crée un champ qui indique si une information est vraie ou fausse. Les valeurs Yes et No s'affichent dans l'interface utilisateur Explorer.

Le paramètre sql d'une dimension type: yesno utilise une expression SQL valide qui renvoie TRUE ou FALSE. Si la condition renvoie TRUE, Yes s'affiche pour l'utilisateur, sinon No s'affiche.

L'expression SQL pour les dimensions type: yesno ne peut pas inclure d'agrégations. Cela signifie qu'il ne peut pas contenir d'agrégations SQL ni de références à des mesures LookML. Si vous souhaitez créer un champ yesno incluant une agrégation SQL ou faisant référence à une mesure LookML, utilisez une mesure avec type: yesno, et non une dimension.

Par exemple, le LookML suivant crée un champ qui indique si une commande a été payée ou non, en fonction du champ status:

dimension: is_order_paid {
  type: yesno
  sql: ${status} = 'paid' ;;
}

Pour référencer un champ type: yesno dans un autre, traitez le champ type: yesno comme une valeur booléenne (en d'autres termes, comme s'il s'agissait déjà d'une valeur "true" ou "false"). Exemple :

dimension: is_big_order {
  type: yesno
  sql: ${order_size} = 'big' ;;
}
# This is correct
measure: total_boxes_needed {
  type: number
  sql: SUM(CASE WHEN ${is_big_order} THEN 2 ELSE 1 END) ;;
}
# This is NOT correct
measure: total_boxes_needed {
  type: number
  sql: SUM(CASE WHEN ${is_big_order} = 'Yes' THEN 2 ELSE 1 END) ;;
}

Si vous utilisez type: yesno avec des données temporelles, la dimension renvoie yes si la date et l'heure ont une valeur, et no dans le cas contraire.

zipcode

type: zipcode est utilisé avec les dimensions de code postal que vous souhaitez représenter sur une visualisation de carte statique (points) (utilisez un champ d'état ou de pays pour carte statique (régions)). Toute dimension de type: zipcode se voit automatiquement attribuer la valeur map_layer_name (us_zipcode_tabulation_areas). Si vous ne souhaitez pas tracer les codes postaux, vous pouvez utiliser un type plus simple tel que type: number.

Le paramètre sql pour les dimensions type: zipcode peut utiliser n'importe quelle expression SQL valide générant un code postal américain à cinq chiffres.

Afin de filtrer sur une dimension de code postal, certains dialectes de base de données exigent que le champ de base de données référencé par la dimension de code postal soit un champ de type varchar ou chaîne, et non un champ de type entier.

Exemple :

dimension: zip {
  type: zipcode
  sql: ${TABLE}.zipcode ;;
}

Types d'heure et de date spécifiques

En général, les dates sont traitées comme des dimension_group qui utilisent type: time.

Vous pouvez créer un champ dimension ou filter pour chaque période que vous souhaitez inclure, au lieu de tous les générer dans une seule dimension_group. Cette méthode est généralement à éviter, sauf si vous avez déjà précalculé des colonnes de temps dans votre base de données ou si vous souhaitez modifier la convention d'attribution de noms de période de Looker (par exemple, avoir un champ nommé created_date_of_purchase au lieu de created_date).

De nombreux types individuels basés sur la date et l'heure sont listés ci-dessous.

Par exemple, pour cette définition dimension_group:

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

Vous pouvez l'utiliser comme équivalent logique:

dimension: created_week {
  type: date_week
  sql: ${TABLE}.created_at ;;
}
dimension: created_month {
  type: date_month
  sql: ${TABLE}.created_at ;;
}
dimension: created_year {
  type: date_year
  sql: ${TABLE}.created_at ;;
}

Types disponibles en fonction de l'heure

Les types suivants sont utilisés dans le paramètre type d'une dimension individuelle pour créer des champs basés sur l'heure ou la date. N'utilisez pas ces types avec le paramètre timeframe, décrit sur la page de documentation dimension_group.

Tous les types de date et d'heure nécessitent un horodatage en entrée de votre base de données.

Types spéciaux

Type	Description	Exemple de résultat
date_raw	La valeur brute de votre base de données, sans conversion ni conversion de fuseau horaire, ne s'affiche pas sur la page "Explorer" (cette opération n'est généralement pas nécessaire, sauf dans les jointures ou les comparaisons de temps).	2014-09-03 17:15:00 +0000

Types d'heure

Type	Description	Exemple de résultat
date_time	Date et heure du champ sous-jacent (certains dialectes SQL sont aussi précis que votre base de données, d'autres en secondes).	2014-09-03 17:15:00
date_time_of_day	Heure de la journée	17:15
date_hour	Date et heure tronquées à l'heure la plus proche	2014-09-03 17
date_hour_of_day	Entier de l'heure du champ sous-jacent	17
date_hourX	Fractionne chaque jour en intervalles avec le nombre d'heures spécifié. Explications requises (voir ci-dessous).	Voir ci-dessous
date_minute	Date et heure tronquées à la minute la plus proche	2014-09-03 17:15
date_minuteX	Fractionne chaque heure en intervalles avec le nombre de minutes spécifié. Explications requises (voir ci-dessous).	Voir ci-dessous
date_second	Date et heure tronquées à la seconde la plus proche	2014-09-03 17:15:00
date_millisecond	Date/heure tronquée à la milliseconde la plus proche (pour plus d'informations sur la compatibilité du dialecte, consultez la section Prise en charge des dialectes exprimées en millisecondes et en microsecondes)	2014-09-03 17:15:00.000
date_millisecondX	Fractionne chaque seconde en intervalles de 30 secondes (voir la section Compatibilité avec les dialectes pour les millisecondes et les microsecondes pour plus d'informations sur la compatibilité du dialecte).	2014-09-01 01:00:00.250
date_microsecond	Date/heure tronquée à la microseconde près (consultez la section Prise en charge des dialectes millisecondes, microsecondes pour plus d'informations sur la prise en charge du dialecte)	2014-09-03 17:15:00.000000

Types de date

Type	Description	Exemple de résultat
date	Date du champ sous-jacent	2017-09-03
date_date	SUPPRIMÉE 4.6 Remplacer par date

Types de semaine

Type	Description	Exemple de résultat
date_week	Date de la semaine commençant le lundi de la date/heure sous-jacente	2017-09-01
date_day_of_week	Jour de la semaine seul	Wednesday
date_day_of_week_index	Indice du jour de la semaine (0 = lundi, 6 = dimanche)	2

Veuillez noter que les types date_week, date_day_of_week et date_day_of_week_index dépendent de la valeur de week_start_day, définie par défaut sur Monday.

Types de mois

Type	Description	Exemple de résultat
date_month	Année et mois de la date/heure sous-jacente	2017-09
date_month_num	Nombre entier du mois sous forme de date et d'heure sous-jacente	9
date_month_name	Nom du mois	September
date_day_of_month	Jour du mois	3
date_fiscal_month_num	Nombre entier du mois sous forme de date et d'heure sous-jacente	9

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

Types de trimestres

Type	Description	Exemple de résultat
date_quarter	Année et trimestre de la date/heure sous-jacente	2017-Q3
date_quarter_of_year	Trimestre de l'année précédé d'un "Q"	Q3
date_fiscal_quarter	Année et trimestre fiscal de la date/heure sous-jacente	2017-Q3
date_fiscal_quarter_of_year	Trimestre de l'année fiscale précédé d'un "Q"	Q3

Pour utiliser les types date_fiscal_quarter et date_fiscal_quarter_of_year, le paramètre fiscal_month_offset doit être défini dans le modèle.

Types d'années

Type	Description	Exemple de résultat
date_year	Année (entier) de la date sous-jacente	2017
date_day_of_year	Jour de l'année	143
date_week_of_year	Semaine de l'année en nombre	17
date_fiscal_year	Année entière sous forme de nombre entier (date et heure sous-jacente)	2017

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

Utiliser un fichier de cookie (date_hourX)

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

Chaque jour, ces données seront réparties par intervalles avec le nombre d'heures spécifié. Par exemple, date_hour6 divisera chaque jour en segments de 6 heures, qui se présenteront 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 dont la propriété time est définie sur 2014-09-01 08:03:17 présente une valeur date_hour6 égale à 2014-09-01 06:00:00.

Utiliser un fichier de cookie (date_minuteX)

Dans date_minuteX, X est remplacé par 2, 3, 5, 10, 15 ou 30.

Chaque heure sera divisée en intervalles avec le nombre de minutes spécifié. Par exemple, date_minute15 divisera chaque heure en segments de 15 minutes, qui se présenteront 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 dont la propriété time est définie sur 2014-09-01 01:17:35 possède une valeur date_minute15 égale à 2014-09-01 01:15:00.

Fuseaux horaires et convert_tz

En général, les calculs temporels (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 à l'esprit les fuseaux horaires lors de l'écriture de LookML.

Looker comporte différents paramètres de fuseau horaire qui convertissent les données temporelles d'un fuseau horaire à un autre. Looker convertit les fuseaux horaires par défaut. 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 sur le paramètre convert_tz.

Dialecte en millisecondes et en microsecondes

Looker accepte la précision à la microseconde près. Cependant, certaines bases de données n'acceptent cette précision qu'à la seconde près. Si une base de données rencontre un type de temps plus précis qu'elle ne peut l'accepter, elle est arrondie à la seconde près.

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

Dans la dernière version de Looker, les dialectes suivants sont compatibles avec les microsecondes :

Types de durées individuelles

En règle générale, les durées sont traitées comme un dimension_group qui utilise type: duration.

Il est possible de créer une dimension pour chaque durée que vous souhaitez inclure, au lieu de toutes les générer dans une seule dimension_group. Cette méthode est généralement évitée, sauf si vous souhaitez modifier la convention d'attribution de noms de délai de Looker (par exemple, avoir un champ nommé Number of Days to Delivery au lieu de Duration to Delivery.)

Plusieurs types de durées sont listés ci-dessous.

Lorsque vous utilisez un type de durée pour une dimension, vous devez également inclure les paramètres sql_start et sql_end afin de fournir les heures de début et de fin pour calculer le décalage.

Les paramètres sql_start et sql_end peuvent utiliser n'importe quelle expression SQL valide contenant des données au format horodatage, date/heure, date, époque ou aaaammjj. Les champs sql_start et sql_end peuvent correspondre à l'un des éléments suivants:

• Référence à une période raw à partir d'un groupe de dimensions type: time existant.
• Référence à une dimension type: date_raw.
• Une expression SQL qui est un horodatage, comme une référence à une colonne SQL qui est un horodatage
• Expression SQL qui extrait une heure de votre base de données en utilisant l'expression appropriée pour votre dialecte.

Par exemple, pour cette définition dimension_group:

dimension_group: to_delivery {
  type: duration
  intervals: [day, hour]
  sql_start: ${created_raw} ;;
  sql_end: ${delivered_raw};;
}

Vous pouvez utiliser ces paramètres dimension comme équivalent logique:

dimension: number_of_days_to_delivery {
  type: duration_day
  sql_start: ${created_raw} ;;
  sql_end: ${delivered_raw};;
}

dimension: number_of_hours_to_delivery {
  type: duration_hour
  sql_start: ${created_raw} ;;
  sql_end: ${delivered_raw};;
}

Dans l'interface utilisateur Explorer, cela crée des dimensions appelées Nombre de jours avant la livraison et Nombre d'heures avant la livraison.

Types de durées disponibles

Les types suivants sont utilisés dans le paramètre type d'une dimension individuelle pour créer des champs basés sur la durée. N'utilisez pas ces types avec le paramètre intervals, décrit sur la page de documentation dimension_group.

Tous les types de durée individuels nécessitent un horodatage en entrée de votre base de données.

Type	Description	Exemple de résultat
duration_day	Calcule un décalage horaire en jours	9 days
duration_hour	Calcule un décalage horaire en heures	171 hours
duration_minute	Calcule un décalage horaire en minutes	10,305 minutes
duration_month	Calcule un décalage horaire en mois	3 months
duration_quarter	Calcule un décalage horaire au cours du trimestre de l'année	2 quarters
duration_second	Calcule un décalage horaire en secondes	606,770 seconds
duration_week	Calcule un décalage horaire en semaines	6 weeks
duration_year	Calcule un décalage horaire en années	2 years