Cette page fait référence au paramètre
typequi fait partie d'une mesure.
typepeut également être utilisé dans une dimension ou un filtre, comme décrit sur la page de documentation Types de dimensions, de filtres et de paramètres.
typepeut également être utilisé dans un groupe de dimensions, comme décrit sur la page de documentation du paramètredimension_group.
Utilisation
view: view_name {
measure: field_name {
type: measure_field_type
}
}
|
Hiérarchie
type |
Types de champs possibles
Mesure
Acceptation
Un type de mesure
|
Cette page fournit des informations sur les différents types pouvant être attribués à une mesure. Une mesure ne peut avoir qu'un seul type. Si aucun type n'est spécifié, la valeur par défaut est string.
Certains types de mesures sont associés à des paramètres, qui sont décrits dans la section appropriée.
Catégories de types de mesures
Chaque type de mesure appartient à l'une des catégories suivantes. Ces catégories déterminent si le type de mesure effectue des agrégations, le type de champs auxquels le type de mesure peut faire référence et si vous pouvez filtrer le type de mesure à l'aide du paramètre filters :
- Mesures agrégées : les types de mesures agrégées effectuent des agrégations, comme
sumetaverage. Les mesures agrégées ne peuvent faire référence qu'à des dimensions, et non à d'autres mesures. Il s'agit du seul type de mesure qui fonctionne avec le paramètrefilters. - Mesures non agrégées : comme leur nom l'indique, les mesures non agrégées sont des types de mesures qui n'effectuent pas d'agrégations, comme
numberetyesno. Ces types de mesures effectuent des transformations de base et, puisqu'ils n'effectuent pas d'agrégations, ne peuvent faire référence qu'à des mesures agrégées ou à des dimensions agrégées précédemment. Vous ne pouvez pas utiliser le paramètrefiltersavec ces types de mesures. - Mesures post-SQL : il s'agit de types de mesures spéciaux qui effectuent des calculs spécifiques une fois que Looker a généré le code SQL de la requête. Ils ne peuvent faire référence qu'à des mesures ou dimensions numériques. Vous ne pouvez pas utiliser le paramètre
filtersavec ces types de mesures.
Liste des définitions de type
| Type | Catégorie | Description |
|---|---|---|
average |
Agréger | Génère une moyenne des valeurs d'une colonne. |
average_distinct |
Agréger | Génère correctement une moyenne des valeurs lorsque vous utilisez des données dénormalisées. Pour obtenir une description complète, consultez la section average_distinct. |
count |
Agréger | Génère un nombre de lignes. |
count_distinct |
Agréger | Génère un nombre de valeurs uniques dans une colonne. |
date |
Non agrégé | Pour les mesures contenant des dates |
list |
Agréger | Génère une liste des valeurs uniques d'une colonne. |
max |
Agréger | Génère la valeur maximale d'une colonne. |
median |
Agréger | Génère la médiane (valeur médiane) des valeurs d'une colonne. |
median_distinct |
Agréger | Génère correctement une médiane (valeur médiane) des valeurs lorsqu'une jointure provoque une expansion. Pour obtenir une description complète, consultez la section median_distinct. |
min |
Agréger | Génère la valeur minimale d'une colonne. |
number |
Non agrégé | Pour les mesures contenant des nombres |
percent_of_previous |
Post-SQL | Génère la différence en pourcentage entre les lignes affichées |
percent_of_total |
Post-SQL | Génère le pourcentage du total pour chaque ligne affichée. |
percentile |
Agréger | Génère la valeur au centile spécifié dans une colonne. |
percentile_distinct |
Agréger | Génère correctement la valeur au centile spécifié lorsqu'une jointure provoque une expansion. Pour obtenir une description complète, consultez la section percentile_distinct. |
running_total |
Post-SQL | Génère le total cumulé pour chaque ligne affichée. |
period_over_period |
Agréger | Fait référence à une agrégation d'une période antérieure |
string |
Non agrégé | Pour les mesures qui contiennent des lettres ou des caractères spéciaux (comme la fonction GROUP_CONCAT de MySQL) |
sum |
Agréger | Génère la somme des valeurs d'une colonne. |
sum_distinct |
Agréger | Génère correctement une somme de valeurs lorsque des données dénormalisées sont utilisées.Pour obtenir une description complète, consultez la section sum_distinct. |
yesno |
Non agrégé | Pour les champs qui indiquent si une information est vraie ou fausse |
int |
Non agrégé |
Supprimé 5.4
Remplacé par type: number |
average
type: average calcule la moyenne des valeurs d'un champ donné. Elle est semblable à la fonction AVG de SQL. Toutefois, contrairement au SQL brut, Looker calculera correctement les moyennes, même si les jointures de votre requête contiennent des sortances.
Le paramètre sql pour les mesures type: average peut accepter n'importe quelle expression SQL valide qui génère une colonne de tableau numérique, une dimension LookML ou une combinaison de dimensions LookML.
Les champs type: average peuvent être mis en forme à l'aide des paramètres value_format ou value_format_name.
Par exemple, le code LookML suivant crée un champ appelé avg_order en calculant la moyenne de la dimension sales_price, puis l'affiche au format monétaire (1 234,56 €) :
measure: avg_order {
type: average
sql: ${sales_price} ;;
value_format_name: usd
}
average_distinct
type: average_distinct est à utiliser avec des ensembles de données dénormalisés. Elle calcule la moyenne des valeurs non répétées d'un champ donné, en fonction des valeurs uniques définies par le paramètre sql_distinct_key.
Il s'agit d'un concept avancé qui peut être expliqué plus clairement à l'aide d'un exemple. Prenons l'exemple d'une table dénormalisée comme celle-ci :
| ID de l'article commandé | ID de commande | Expédition de la commande |
|---|---|---|
| 1 | 1 | 10.00 |
| 2 | 1 | 10.00 |
| 3 | 2 | 20,00 |
| 4 | 2 | 20,00 |
| 5 | 2 | 20,00 |
Dans ce cas, vous pouvez voir qu'il existe plusieurs lignes pour chaque commande. Par conséquent, si vous ajoutez une mesure type: average de base pour la colonne order_shipping, vous obtiendrez une valeur de 16,00, même si la moyenne réelle est de 15,00.
# Will NOT calculate the correct average
measure: avg_shipping {
type: average
sql: ${order_shipping} ;;
}
Pour obtenir un résultat précis, vous pouvez définir pour Looker la façon dont il doit identifier chaque entité unique (dans ce cas, chaque commande unique) à l'aide du paramètre sql_distinct_key. Cette formule calculera le montant correct de 15,00 :
# Will calculate the correct average
measure: avg_shipping {
type: average_distinct
sql_distinct_key: ${order_id} ;;
sql: ${order_shipping} ;;
}
Chaque valeur unique de sql_distinct_key ne doit avoir qu'une seule valeur correspondante dans sql. En d'autres termes, l'exemple précédent fonctionne, car chaque ligne avec une valeur order_id de 1 a la même valeur order_shipping de 10,00, et chaque ligne avec une valeur order_id de 2 a la même valeur order_shipping de 20,00.
Les champs type: average_distinct peuvent être mis en forme à l'aide des paramètres value_format ou value_format_name.
count
type: count effectue un décompte des tables, semblable à la fonction COUNT de SQL. Toutefois, contrairement au SQL brut, Looker calculera correctement les nombres, même si les jointures de votre requête contiennent des sortances.
Les mesures type: count effectuent des décomptes de tables basés sur la clé primaire de la table. Elles ne sont donc pas compatibles avec le paramètre sql.type: count
Si vous souhaitez effectuer un décompte de table sur un champ autre que la clé primaire de la table, utilisez une mesure type: count_distinct. Si vous ne souhaitez pas utiliser count_distinct, vous pouvez utiliser une mesure de type: number (pour en savoir plus, consultez le post de la communauté Comment compter une clé non primaire).
Par exemple, le code LookML suivant crée un champ number_of_products :
view: products {
measure: number_of_products {
type: count
drill_fields: [product_details*] # optional
}
}
Il est très courant de fournir un paramètre drill_fields (pour les champs) lors de la définition d'une mesure type: count, afin que les utilisateurs puissent voir les enregistrements individuels qui composent un décompte lorsqu'ils cliquent dessus.
Lorsque vous utilisez une mesure de
type: countdans une exploration, les libellés de visualisation indiquent le nom de la vue plutôt que le mot "Nombre". Pour éviter toute confusion, nous vous recommandons de mettre le nom de votre vue au pluriel, de sélectionner Afficher le nom complet du champ sous Série dans les paramètres de visualisation ou d'utiliser unview_labelavec une version au pluriel du nom de votre vue.
Vous pouvez ajouter un filtre à une mesure de type: count à l'aide du paramètre filters.
count_distinct
type: count_distinct calcule le nombre de valeurs distinctes dans un champ donné. Il utilise la fonction COUNT DISTINCT de SQL.
Le paramètre sql pour les mesures type: count_distinct peut accepter n'importe quelle expression SQL valide qui génère une colonne de tableau, une dimension LookML ou une combinaison de dimensions LookML.
Par exemple, le LookML suivant crée un champ number_of_unique_customers qui comptabilise le nombre d'ID client uniques :
measure: number_of_unique_customers {
type: count_distinct
sql: ${customer_id} ;;
}
Vous pouvez ajouter un filtre à une mesure de type: count_distinct à l'aide du paramètre filters.
date
type: date est utilisé avec les champs contenant des dates.
Le paramètre sql des mesures type: date peut prendre n'importe quelle expression SQL valide qui génère une date. En pratique, ce type est rarement utilisé, car la plupart des fonctions d'agrégation SQL ne renvoient pas de dates. Une exception courante est un MIN ou un MAX d'une dimension de date.
Créer une mesure de date maximale ou minimale avec type: date
Si vous souhaitez créer une mesure de date maximale ou minimale, vous pouvez penser à utiliser une mesure de type: max ou de type: min. Toutefois, ces types de mesures ne sont compatibles qu'avec les champs numériques. Vous pouvez plutôt capturer une date maximale ou minimale en définissant une mesure de type: date et en encapsulant le champ de date référencé dans le paramètre sql dans une fonction MIN() ou MAX().
Supposons que vous disposiez d'un groupe de dimensions de type: time, appelé updated :
dimension_group: updated {
type: time
timeframes: [time, date, week, month, raw]
sql: ${TABLE}.updated_at ;;
}
Vous pouvez créer une mesure type: date pour capturer la date maximale de ce groupe de dimensions comme suit :
measure: last_updated_date {
type: date
sql: MAX(${updated_raw}) ;;
convert_tz: no
}
Dans cet exemple, au lieu d'utiliser une mesure de type: max pour créer la mesure last_updated_date, la fonction MAX() est appliquée dans le paramètre sql. La mesure last_updated_date a également le paramètre convert_tz défini sur no pour éviter une double conversion du fuseau horaire dans la mesure, car la conversion du fuseau horaire a déjà eu lieu dans la définition du groupe de dimensions updated. Pour en savoir plus, consultez la documentation sur le paramètre convert_tz.
Dans l'exemple LookML pour la mesure last_updated_date, type: date peut être omis et la valeur sera traitée comme une chaîne, car string est la valeur par défaut pour type. Toutefois, vous bénéficierez d'une meilleure capacité de filtrage pour les utilisateurs si vous utilisez type: date.
Vous remarquerez peut-être également que la définition de la mesure last_updated_date fait référence à la période ${updated_raw} au lieu de la période ${updated_date}. Comme la valeur renvoyée par ${updated_date} est une chaîne, il est nécessaire d'utiliser ${updated_raw} pour faire référence à la valeur de date réelle.
Vous pouvez également utiliser le paramètre datatype avec type: date pour améliorer les performances des requêtes en spécifiant le type de données de date utilisé par la table de votre base de données.
Créer une mesure max ou min pour une colonne datetime
Le calcul du maximum pour une colonne type: datetime est légèrement différent. Dans ce cas, vous souhaitez créer une mesure sans déclarer le type, comme ceci :
measure: last_updated_datetime {
sql: MAX(${TABLE}.datetime_string_field) ;;
}
list
type: list crée une liste des valeurs distinctes dans un champ donné. Elle est semblable à la fonction GROUP_CONCAT de MySQL.
Vous n'avez pas besoin d'inclure un paramètre sql pour les mesures type: list. À la place, vous pouvez utiliser le paramètre list_field pour spécifier la dimension à partir de laquelle vous souhaitez créer des listes.
Voici comment l'utiliser :
view: view_name {
measure: field_name {
type: list
list_field: my_field_name
}
}
Par exemple, le code LookML suivant crée une mesure name_list basée sur la dimension name :
measure: name_list {
type: list
list_field: name
}
Remarques concernant list :
- Le type de mesure
listn'est pas compatible avec le filtrage. Vous ne pouvez pas utiliser le paramètrefilterssur une mesuretype: list. - Le type de mesure
listne peut pas être référencé à l'aide de l'opérateur de substitution ($). Vous ne pouvez pas utiliser la syntaxe${}pour faire référence à une mesuretype: list.
Dialectes de base de données compatibles avec list
Pour que Looker prenne en charge type: list dans votre projet Looker, votre dialecte de base de données doit également le prendre en charge. Le tableau suivant indique les dialectes qui prennent en charge type: list dans la dernière version de Looker :
| 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 |
max
type: max trouve la valeur la plus élevée dans un champ donné. Il utilise la fonction MAX de SQL.
Le paramètre sql pour les mesures de type: max peut prendre n'importe quelle expression SQL valide qui génère une colonne de tableau numérique, une dimension LookML ou une combinaison de dimensions LookML.
Étant donné que les mesures de type: max ne sont compatibles qu'avec les champs numériques, vous ne pouvez pas utiliser une mesure de type: max pour trouver une date maximale. Vous pouvez plutôt utiliser la fonction MAX() dans le paramètre sql d'une mesure type: date pour capturer une date maximale, comme indiqué précédemment dans les exemples de la section date.
Les champs type: max peuvent être mis en forme à l'aide des paramètres value_format ou value_format_name.
Par exemple, le code LookML suivant crée un champ appelé largest_order en examinant la dimension sales_price, puis l'affiche au format monétaire (1 234,56 €) :
measure: largest_order {
type: max
sql: ${sales_price} ;;
value_format_name: usd
}
Vous ne pouvez pas utiliser les mesures type: max pour les chaînes ou les dates, mais vous pouvez ajouter manuellement la fonction MAX pour créer un tel champ, comme ceci :
measure: latest_name_in_alphabet {
type: string
sql: MAX(${name}) ;;
}
median
type: median renvoie la valeur médiane des valeurs d'un champ donné. Cela est particulièrement utile lorsque les données comportent quelques valeurs aberrantes très élevées ou très faibles qui fausseraient une moyenne de base (moyenne arithmétique) des données.
Prenons l'exemple d'un tableau comme celui-ci :
| ID de l'article commandé | Coût | Première moitié ? |
|---|---|---|
| 2 | 10.00 | |
| 4 | 10.00 | |
| 3 | 20,00 | Valeur du point médian |
| 1 | 80,00 | |
| 5 | 90,00 |
Le tableau est trié par coût, mais cela n'a aucune incidence sur le résultat. Alors que le type average renverrait 42 (en additionnant toutes les valeurs et en divisant par 5), le type median renverrait la valeur médiane : 20,00.
S'il existe un nombre pair de valeurs, la valeur médiane est calculée en prenant la moyenne des deux valeurs les plus proches du point médian. Prenons l'exemple d'un tableau comme celui-ci, avec un nombre pair de lignes :
| ID de l'article commandé | Coût | Première moitié ? |
|---|---|---|
| 2 | 10 | |
| 3 | 20 | Le plus proche avant le point médian |
| 1 | 80 | Le plus proche après le point médian |
| 4 | 90 |
La valeur médiane (valeur du milieu) est (20 + 80)/2 = 50.
La médiane est également égale à la valeur du 50e centile.
Le paramètre sql pour les mesures type: median peut accepter n'importe quelle expression SQL valide qui génère une colonne de tableau numérique, une dimension LookML ou une combinaison de dimensions LookML.
Les champs type: median peuvent être mis en forme à l'aide des paramètres value_format ou value_format_name.
Exemple
Par exemple, le code LookML suivant crée un champ appelé median_order en calculant la moyenne de la dimension sales_price, puis l'affiche au format monétaire (1 234,56 €) :
measure: median_order {
type: median
sql: ${sales_price} ;;
value_format_name: usd
}
Éléments à prendre en compte pour median
Si vous utilisez median pour un champ impliqué dans une expansion, Looker tentera d'utiliser median_distinct à la place. Toutefois, medium_distinct n'est compatible qu'avec certains dialectes. Si median_distinct n'est pas disponible pour votre dialecte, Looker renvoie une erreur. Étant donné que median peut être considéré comme le 50e centile, l'erreur indique que le dialecte n'accepte pas les centiles distincts.
Dialectes de base de données compatibles avec median
Pour que Looker prenne en charge le type median dans votre projet, votre dialecte de base de données doit également le prendre en charge. Le tableau suivant indique les dialectes qui prennent en charge le type median dans la dernière version de Looker :
| 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 |
Lorsqu'une requête implique une distribution, Looker tente de convertir median en median_distinct. Cette opération ne fonctionne que dans les variantes régionales qui acceptent median_distinct.
median_distinct
Utilisez type: median_distinct lorsque votre jointure implique une expansion. Elle calcule la moyenne des valeurs non répétées d'un champ donné, en fonction des valeurs uniques définies par le paramètre sql_distinct_key. Si la mesure ne comporte pas de paramètre sql_distinct_key, Looker tente d'utiliser le champ primary_key.
Prenons l'exemple d'une requête qui joint les tables "Order Item" et "Order" :
| ID de l'article commandé | ID de commande | Expédition de la commande |
|---|---|---|
| 1 | 1 | 10 |
| 2 | 1 | 10 |
| 3 | 2 | 20 |
| 4 | 3 | 50 |
| 5 | 3 | 50 |
| 6 | 3 | 50 |
Dans cette situation, vous pouvez voir qu'il existe plusieurs lignes pour chaque commande. Cette requête impliquait une expansion, car chaque commande correspond à plusieurs éléments de commande. median_distinct en tient compte et trouve la médiane entre les valeurs distinctes 10, 20 et 50, ce qui donne une valeur de 20.
Pour obtenir un résultat précis, vous pouvez définir pour Looker la façon dont il doit identifier chaque entité unique (dans ce cas, chaque commande unique) à l'aide du paramètre sql_distinct_key. Le montant correct sera calculé :
measure: median_shipping {
type: median_distinct
sql_distinct_key: ${order_id} ;;
sql: ${order_shipping} ;;
}
Chaque valeur unique de sql_distinct_key ne doit avoir qu'une seule valeur correspondante dans le paramètre sql de la mesure. En d'autres termes, l'exemple précédent fonctionne, car chaque ligne avec un order_id de 1 a le même order_shipping de 10, et chaque ligne avec un order_id de 2 a le même order_shipping de 20.
Les champs type: median_distinct peuvent être mis en forme à l'aide des paramètres value_format ou value_format_name.
Éléments à prendre en compte pour median_distinct
Le type de mesure medium_distinct n'est accepté que pour certains dialectes. Si median_distinct n'est pas disponible pour le dialecte, Looker renvoie une erreur. Étant donné que median peut être considéré comme le 50e centile, l'erreur indique que le dialecte n'accepte pas les centiles distincts.
Dialectes de base de données compatibles avec median_distinct
Pour que Looker prenne en charge le type median_distinct dans votre projet, votre dialecte de base de données doit également le prendre en charge. Le tableau suivant indique les dialectes qui prennent en charge le type median_distinct dans la dernière version de Looker :
| 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 |
min
type: min trouve la plus petite valeur dans un champ donné. Il utilise la fonction MIN de SQL.
Le paramètre sql pour les mesures de type: min peut prendre n'importe quelle expression SQL valide qui génère une colonne de tableau numérique, une dimension LookML ou une combinaison de dimensions LookML.
Étant donné que les mesures de type: min ne sont compatibles qu'avec les champs numériques, vous ne pouvez pas utiliser une mesure de type: min pour trouver une date minimale. Vous pouvez utiliser la fonction MIN() dans le paramètre sql d'une mesure type: date pour capturer un minimum, tout comme vous pouvez utiliser la fonction MAX() avec une mesure type: date pour capturer une date maximale. Cela a été montré précédemment sur cette page dans la section date, qui inclut des exemples d'utilisation de la fonction MAX() dans le paramètre sql pour trouver une date maximale.
Les champs type: min peuvent être mis en forme à l'aide des paramètres value_format ou value_format_name.
Par exemple, le code LookML suivant crée un champ appelé smallest_order en examinant la dimension sales_price, puis l'affiche au format monétaire (1 234,56 €) :
measure: smallest_order {
type: min
sql: ${sales_price} ;;
value_format_name: usd
}
Vous ne pouvez pas utiliser les mesures type: min pour les chaînes ou les dates, mais vous pouvez ajouter manuellement la fonction MIN pour créer un tel champ, comme ceci :
measure: earliest_name_in_alphabet {
type: string
sql: MIN(${name}) ;;
}
number
type: number est utilisé avec des nombres ou des entiers. Une mesure de type: number n'effectue aucune agrégation et est destinée à effectuer des transformations de base sur d'autres mesures. Si vous définissez une mesure basée sur une autre mesure, la nouvelle mesure doit être de type type: number pour éviter les erreurs d'agrégation imbriquée.
Le paramètre sql pour les mesures type: number peut prendre n'importe quelle expression SQL valide qui génère un nombre ou un entier.
Les champs type: number peuvent être mis en forme à l'aide des paramètres value_format ou value_format_name.
Par exemple, le code LookML suivant crée une mesure appelée total_gross_margin_percentage basée sur les mesures agrégées total_sale_price et total_gross_margin, puis l'affiche au format pourcentage avec deux décimales (12,34 %) :
measure: total_sale_price {
type: sum
value_format_name: usd
sql: ${sale_price} ;;
}
measure: total_gross_margin {
type: sum
value_format_name: usd
sql: ${gross_margin} ;;
}
measure: total_gross_margin_percentage {
type: number
value_format_name: percent_2
sql: ${total_gross_margin}/ NULLIF(${total_sale_price},0) ;;
}
Cet exemple utilise également la fonction SQL NULLIF() pour éviter les erreurs de division par zéro.
Éléments à prendre en compte pour type: number
Voici plusieurs points importants à retenir lorsque vous utilisez des mesures type: number :
- Une mesure de
type: numberne peut effectuer des opérations arithmétiques que sur d'autres mesures, et non sur d'autres dimensions. - Les agrégations symétriques de Looker ne protègent pas les fonctions d'agrégation dans le code SQL d'une mesure
type: numberlorsqu'elles sont calculées sur une jointure. - Le paramètre
filtersne peut pas être utilisé avec les mesurestype: number, mais la documentationfiltersexplique comment contourner ce problème. - Les mesures
type: numberne fournissent pas de suggestions aux utilisateurs.
percent_of_previous
type: percent_of_previous calcule la différence en pourcentage entre une cellule et la cellule précédente de sa colonne.
Le paramètre sql des mesures type: percent_of_previous doit faire référence à une autre mesure numérique.
Les champs type: percent_of_previous peuvent être mis en forme à l'aide des paramètres value_format ou value_format_name. Toutefois, les formats de pourcentage du paramètre value_format_name ne fonctionnent pas avec les mesures type: percent_of_previous. Ces formats de pourcentage multiplient les valeurs par 100, ce qui fausse les résultats du calcul du pourcentage par rapport à la période précédente.
Cet exemple de code LookML crée une mesure count_growth basée sur la mesure count :
measure: count_growth {
type: percent_of_previous
sql: ${count} ;;
}
Notez que les valeurs percent_of_previous dépendent de l'ordre de tri. Si vous modifiez le tri, vous devez réexécuter la requête pour recalculer les valeurs percent_of_previous. Lorsqu'une requête est pivotée, percent_of_previous s'exécute sur la ligne au lieu de la colonne. Vous ne pouvez pas modifier ce comportement.
De plus, les mesures percent_of_previous sont calculées après que les données ont été renvoyées par votre base de données. Cela signifie que vous ne devez pas faire référence à une mesure percent_of_previous dans une autre mesure. En effet, comme elles peuvent être calculées à des moments différents, vous risquez d'obtenir des résultats inexacts. Cela signifie également que les mesures percent_of_previous ne peuvent pas être filtrées.
L'analyse de période à période (PoP) est une application de ce type de mesure. Il s'agit d'un modèle d'analyse qui mesure un élément dans le présent et le compare à la même mesure au cours d'une période comparable dans le passé. Pour en savoir plus sur la comparaison de périodes, consultez les articles de la communauté Looker How to do Period-over-Period Analysis (Comment effectuer une analyse de période à période) et Methods for Period Over Period (PoP) Analysis in Looker (Méthodes d'analyse de période à période dans Looker).
percent_of_total
type: percent_of_total calcule la part d'une cellule dans le total de la colonne. Le pourcentage est calculé par rapport au total des lignes renvoyées par votre requête, et non par rapport au total de toutes les lignes possibles. Toutefois, si les données renvoyées par votre requête dépassent une limite de lignes, les valeurs du champ apparaîtront comme nulles, car le pourcentage du total nécessite des résultats complets.
Le paramètre sql des mesures type: percent_of_total doit faire référence à une autre mesure numérique.
Les champs type: percent_of_total peuvent être mis en forme à l'aide des paramètres value_format ou value_format_name. Toutefois, les formats de pourcentage du paramètre value_format_name ne fonctionnent pas avec les mesures type: percent_of_total. Ces formats de pourcentage multiplient les valeurs par 100, ce qui fausse les résultats d'un calcul percent_of_total.
Cet exemple de code LookML crée une mesure percent_of_total_gross_margin basée sur la mesure total_gross_margin :
measure: percent_of_total_gross_margin {
type: percent_of_total
sql: ${total_gross_margin} ;;
}
Lorsqu'une requête est pivotée, percent_of_total s'exécute sur la ligne au lieu de la colonne. Si ce n'est pas ce que vous souhaitez, ajoutez direction: "column" à la définition de la mesure.
De plus, les mesures percent_of_total sont calculées après que les données ont été renvoyées par votre base de données. Cela signifie que vous ne devez pas faire référence à une mesure percent_of_total dans une autre mesure. En effet, comme elles peuvent être calculées à des moments différents, vous risquez d'obtenir des résultats inexacts. Cela signifie également que les mesures percent_of_total ne peuvent pas être filtrées.
percentile
type: percentile renvoie la valeur au centile spécifié des valeurs d'un champ donné. Par exemple, si vous spécifiez le 75e centile, la fonction renvoie la valeur supérieure à 75 % des autres valeurs de l'ensemble de données.
Pour identifier la valeur à renvoyer, Looker calcule le nombre total de valeurs de données et multiplie le centile spécifié par le nombre total de valeurs de données. Quelle que soit la façon dont les données sont réellement triées, Looker identifie l'ordre relatif des valeurs de données par ordre croissant. La valeur de données renvoyée par Looker dépend du fait que le calcul génère ou non un entier, comme indiqué dans les deux sections suivantes.
Si la valeur calculée n'est pas un entier
Looker arrondit la valeur calculée à l'entier supérieur et l'utilise pour identifier la valeur de données à renvoyer. Dans cet exemple de 19 notes de test, le 75e centile est identifié par 19 * 0,75 = 14,25, ce qui signifie que 75 % des valeurs se trouvent dans les 14 premières valeurs de données, en dessous de la 15e position. Looker renvoie donc la 15e valeur de données (87) comme étant supérieure à 75 % des valeurs de données.
Si la valeur calculée est un nombre entier
Dans ce cas légèrement plus complexe, Looker renvoie une moyenne de la valeur de données à cette position et de la valeur de données suivante. Pour comprendre cela, prenons l'exemple d'un ensemble de 20 notes de test : le 75e centile serait identifié par 20 * 0, 75 = 15, ce qui signifie que la valeur de données à la 15e position fait partie du 75e centile. Nous devons renvoyer une valeur supérieure à 75 % des valeurs de données. En renvoyant la moyenne des valeurs à la 15e position (82) et à la 16e position (87), Looker garantit que 75 %. Cette moyenne (84,5) n'existe pas dans l'ensemble des valeurs de données, mais elle serait supérieure à 75 % des valeurs de données.
Paramètres obligatoires et facultatifs
Utilisez le mot clé percentile: pour spécifier la valeur fractionnaire, c'est-à-dire le pourcentage de données qui doit être inférieur à la valeur renvoyée. Par exemple, utilisez percentile: 75 pour spécifier la valeur au 75e centile dans l'ordre des données, ou percentile: 10 pour renvoyer la valeur au 10e centile. Si vous souhaitez trouver la valeur au 50e centile, vous pouvez spécifier percentile: 50 ou simplement utiliser le type median.
Le paramètre sql pour les mesures type: percentile peut accepter n'importe quelle expression SQL valide qui génère une colonne de tableau numérique, une dimension LookML ou une combinaison de dimensions LookML.
Les champs type: percentile peuvent être mis en forme à l'aide des paramètres value_format ou value_format_name.
Exemple
Par exemple, le code LookML suivant crée un champ appelé test_scores_75th_percentile qui renvoie la valeur au 75e centile dans la dimension test_scores :
measure: test_scores_75th_percentile {
type: percentile
percentile: 75
sql: ${TABLE}.test_scores ;;
}
Éléments à prendre en compte pour percentile
Si vous utilisez percentile pour un champ impliqué dans une distribution, Looker tentera d'utiliser percentile_distinct à la place. Si percentile_distinct n'est pas disponible pour le dialecte, Looker renvoie une erreur. Pour en savoir plus, consultez les dialectes compatibles pour percentile_distinct.
Dialectes de base de données compatibles avec percentile
Pour que Looker prenne en charge le type percentile dans votre projet, votre dialecte de base de données doit également le prendre en charge. Le tableau suivant indique les dialectes qui prennent en charge le type percentile dans la dernière version de Looker :
| 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 |
percentile_distinct
type: percentile_distinct est une forme spécialisée de centile et doit être utilisé lorsque votre jointure implique une expansion. Il utilise les valeurs non répétées d'un champ donné, en fonction des valeurs uniques définies par le paramètre sql_distinct_key. Si la mesure ne comporte pas de paramètre sql_distinct_key, Looker tente d'utiliser le champ primary_key.
Prenons l'exemple d'une requête qui joint les tables "Order Item" et "Order" :
| ID de l'article commandé | ID de commande | Expédition de la commande |
|---|---|---|
| 1 | 1 | 10 |
| 2 | 1 | 10 |
| 3 | 2 | 20 |
| 4 | 3 | 50 |
| 5 | 3 | 50 |
| 6 | 3 | 50 |
| 7 | 4 | 70 |
| 8 | 4 | 70 |
| 9 | 5 | 110 |
| 10 | 5 | 110 |
Dans cette situation, vous pouvez voir qu'il existe plusieurs lignes pour chaque commande. Cette requête impliquait une expansion, car chaque commande correspond à plusieurs éléments de commande. percentile_distinct en tient compte et trouve la valeur du centile à l'aide des valeurs distinctes 10, 20, 50, 70 et 110. Le 25e centile renvoie la deuxième valeur distincte, soit 20, tandis que le 80e centile renvoie la moyenne des quatrième et cinquième valeurs distinctes, soit 90.
Paramètres obligatoires et facultatifs
Utilisez le mot clé percentile: pour spécifier la valeur fractionnaire. Par exemple, utilisez percentile: 75 pour spécifier la valeur au 75e centile dans l'ordre des données, ou percentile: 10 pour renvoyer la valeur au 10e centile. Si vous essayez de trouver la valeur au 50e centile, vous pouvez utiliser le type median_distinct à la place.
Pour obtenir un résultat précis, spécifiez comment Looker doit identifier chaque entité unique (dans ce cas, chaque commande unique) à l'aide du paramètre sql_distinct_key.
Voici un exemple d'utilisation de percentile_distinct pour renvoyer la valeur au 90e centile :
measure: order_shipping_90th_percentile {
type: percentile_distinct
percentile: 90
sql_distinct_key: ${order_id} ;;
sql: ${order_shipping} ;;
}
Chaque valeur unique de sql_distinct_key ne doit avoir qu'une seule valeur correspondante dans le paramètre sql de la mesure. En d'autres termes, l'exemple précédent fonctionne, car chaque ligne avec une valeur order_id de 1 a la même valeur order_shipping de 10, et chaque ligne avec une valeur order_id de 2 a la même valeur order_shipping de 20.
Les champs type: percentile_distinct peuvent être mis en forme à l'aide des paramètres value_format ou value_format_name.
Éléments à prendre en compte pour percentile_distinct
Si percentile_distinct n'est pas disponible pour le dialecte, Looker renvoie une erreur. Pour en savoir plus, consultez les dialectes compatibles pour percentile_distinct.
Dialectes de base de données compatibles avec percentile_distinct
Pour que Looker prenne en charge le type percentile_distinct dans votre projet, votre dialecte de base de données doit également le prendre en charge. Le tableau suivant indique les dialectes qui prennent en charge le type percentile_distinct dans la dernière version de Looker :
| 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 |
period_over_period
Pour les dialectes compatibles avec les mesures de variation par période, vous pouvez créer une mesure LookML de type: period_over_period pour créer une mesure de variation par période. Une mesure "période sur période" fait référence à une agrégation d'une période antérieure.
Voici un exemple de mesure de PdP qui fournit le nombre de commandes du mois précédent :
measure: orders_last_month {
type: period_over_period
based_on: orders.count
based_on_time: orders.created_month
period: month
kind: previous
}
Les mesures avec type: period_over_period doivent également comporter les sous-paramètres suivants :
Pour en savoir plus et obtenir des exemples, consultez Mesures de période à période dans Looker.
running_total
type: running_total calcule la somme cumulée des cellules d'une colonne. Il ne peut pas être utilisé pour calculer des sommes sur une ligne, sauf si la ligne est issue d'un tableau croisé dynamique.
Le paramètre sql des mesures type: running_total doit faire référence à une autre mesure numérique.
Les champs type: running_total peuvent être mis en forme à l'aide des paramètres value_format ou value_format_name.
L'exemple LookML suivant crée une mesure cumulative_total_revenue basée sur la mesure total_sale_price :
measure: cumulative_total_revenue {
type: running_total
sql: ${total_sale_price} ;;
value_format_name: usd
}
Notez que les valeurs running_total dépendent de l'ordre de tri. Si vous modifiez le tri, vous devez réexécuter la requête pour recalculer les valeurs running_total. Lorsqu'une requête est pivotée, running_total s'exécute sur la ligne au lieu de la colonne. Si ce n'est pas ce que vous souhaitez, ajoutez direction: "column" à la définition de la mesure.
De plus, les mesures running_total sont calculées après que les données ont été renvoyées par votre base de données. Cela signifie que vous ne devez pas faire référence à une mesure running_total dans une autre mesure. En effet, comme elles peuvent être calculées à des moments différents, vous risquez d'obtenir des résultats inexacts. Cela signifie également que les mesures running_total ne peuvent pas être filtrées.
string
type: string est utilisé avec les champs contenant des lettres ou des caractères spéciaux.
Le paramètre sql pour les mesures type: string peut accepter n'importe quelle expression SQL valide qui génère une chaîne. En pratique, ce type est rarement utilisé, car la plupart des fonctions d'agrégation SQL ne renvoient pas de chaînes. Une exception courante est la fonction GROUP_CONCAT de MySQL, bien que Looker fournisse type: list pour ce cas d'utilisation.
Par exemple, le LookML suivant crée un champ category_list en combinant les valeurs uniques d'un champ appelé category :
measure: category_list {
type: string
sql: GROUP_CONCAT(${category}) ;;
}
Dans cet exemple, type: string peut être omis, car string est la valeur par défaut de type.
sum
type: sum additionne les valeurs d'un champ donné. Elle est semblable à la fonction SUM de SQL. Toutefois, contrairement au SQL brut, Looker calculera correctement les sommes, même si les jointures de votre requête contiennent des sortances.
Le paramètre sql pour les mesures type: sum peut accepter n'importe quelle expression SQL valide qui génère une colonne de tableau numérique, une dimension LookML ou une combinaison de dimensions LookML.
Les champs type: sum peuvent être mis en forme à l'aide des paramètres value_format ou value_format_name.
Par exemple, le LookML suivant crée un champ appelé total_revenue en additionnant la dimension sales_price, puis l'affiche au format monétaire (1 234,56 $) :
measure: total_revenue {
type: sum
sql: ${sales_price} ;;
value_format_name: usd
}
sum_distinct
type: sum_distinct est à utiliser avec des ensembles de données dénormalisés. Elle additionne les valeurs non répétées d'un champ donné, en fonction des valeurs uniques définies par le paramètre sql_distinct_key.
Il s'agit d'un concept avancé qui peut être expliqué plus clairement à l'aide d'un exemple. Prenons l'exemple d'une table dénormalisée comme celle-ci :
| ID de l'article commandé | ID de commande | Expédition de la commande |
|---|---|---|
| 1 | 1 | 10.00 |
| 2 | 1 | 10.00 |
| 3 | 2 | 20,00 |
| 4 | 2 | 20,00 |
| 5 | 2 | 20,00 |
Dans ce cas, vous pouvez voir qu'il existe plusieurs lignes pour chaque commande. Par conséquent, si vous avez ajouté une mesure type: sum pour la colonne order_shipping, vous obtiendrez un total de 80,00, même si le montant total des frais de port collectés est en réalité de 30,00.
# Will NOT calculate the correct shipping amount
measure: total_shipping {
type: sum
sql: ${order_shipping} ;;
}
Pour obtenir un résultat précis, vous pouvez définir pour Looker la façon dont il doit identifier chaque entité unique (dans ce cas, chaque commande unique) à l'aide du paramètre sql_distinct_key. Cette formule permettra de calculer le montant correct de 30,00 :
# Will calculate the correct shipping amount
measure: total_shipping {
type: sum_distinct
sql_distinct_key: ${order_id} ;;
sql: ${order_shipping} ;;
}
Chaque valeur unique de sql_distinct_key ne doit avoir qu'une seule valeur correspondante dans sql. En d'autres termes, l'exemple précédent fonctionne, car chaque ligne avec une valeur order_id de 1 a la même valeur order_shipping de 10,00, et chaque ligne avec une valeur order_id de 2 a la même valeur order_shipping de 20,00.
Les champs type: sum_distinct peuvent être mis en forme à l'aide des paramètres value_format ou value_format_name.
yesno
type: yesno crée un champ qui indique si une valeur est vraie ou fausse. Les valeurs Oui et Non s'affichent dans l'interface utilisateur Explorer.
Le paramètre sql d'une mesure type: yesno accepte une expression SQL valide qui renvoie TRUE ou FALSE. Si la condition renvoie TRUE, la réponse Oui s'affiche pour l'utilisateur. Sinon, la réponse Non s'affiche.
L'expression SQL pour les mesures type: yesno ne doit inclure que des agrégations, c'est-à-dire des agrégations SQL ou des références à des mesures LookML. Si vous souhaitez créer un champ yesno qui inclut une référence à une dimension LookML ou une expression SQL qui n'est pas une agrégation, utilisez une dimension avec type: yesno, et non une mesure.
Comme pour les mesures avec type: number, une mesure avec type: yesno n'effectue aucune agrégation. Elle fait simplement référence à d'autres agrégations.
Par exemple, l'exemple de mesure total_sale_price suivant correspond à la somme du prix de vente total des articles d'une commande. Une deuxième mesure appelée is_large_total est type: yesno. La mesure is_large_total comporte un paramètre sql qui évalue si la valeur total_sale_price est supérieure à 1 000 $.
measure: total_sale_price {
type: sum
value_format_name: usd
sql: ${sale_price} ;;
drill_fields: [detail*]
}
measure: is_large_total {
description: "Is order total over $1000?"
type: yesno
sql: ${total_sale_price} > 1000 ;;
}
Si vous souhaitez faire référence à un champ type: yesno dans un autre champ, vous devez traiter le champ type: yesno comme un champ booléen (c'est-à-dire comme s'il contenait déjà une valeur "true" ou "false"). Exemple :
measure: is_large_total {
description: "Is order total over $1000?"
type: yesno
sql: ${total_sale_price} > 1000 ;;
}
# This is correct:
measure: reward_points {
type: number
sql: CASE WHEN ${is_large_total} THEN 200 ELSE 100 END ;;
}
# This is NOT correct:
measure: reward_points {
type: number
sql: CASE WHEN ${is_large_total} = 'Yes' THEN 200 ELSE 100 END ;;
}