Pour écrire un code LookML efficace, vous devez pouvoir faire référence à des dimensions, mesures, vues ou tables dérivées existantes, même si elles sont en dehors de la portée actuelle. Vous devez également référencer les colonnes de la table sous-jacente et utiliser les appels de fonction de votre dialecte de base de données pour manipuler ces valeurs.
Opérateur de substitution ($)
L'opérateur de substitution, $, rend le code LookML plus modulaire et facilement réutilisable, ce qui vous permet de faire référence à d'autres vues et tables dérivées, aux colonnes d'une table SQL ou à des dimensions et mesures LookML. Cette méthode présente deux avantages : Premièrement, si vous avez d'ores et déjà construit une dimension ou une mesure très élaborée, vous n'aurez pas à réécrire ce code complexe. Deuxièmement, si vous modifiez une dimension ou une mesure, vous pouvez reporter ces changements sur tous les éléments reposant sur cette dimension ou mesure.
Vous pouvez vous servir de l'opérateur de substitution de plusieurs façons :
${TABLE}.column_name fait référence à une colonne de la table associée à la vue sur laquelle vous travaillez. Exemple :
dimension: customer_id {
type: number
sql: ${TABLE}.customer_id ;;
}
${field_name} fait référence à une dimension ou à une mesure de la vue sur laquelle vous travaillez. Exemple :
measure: total_population {
type: sum
sql: ${population} ;;
}
${view_name.field_name} référence une dimension ou une mesure à partir d'une autre vue. Exemple :
dimension: lifetime_orders {
type: number
sql: ${user_order_facts.lifetime_orders} ;;
}
${view_name.SQL_TABLE_NAME} fait référence à une autre vue ou à une table dérivée. Notez que SQL_TABLE_NAME dans cette référence est une chaîne littérale, qu'il est donc inutile de remplacer. Exemple :
explore: trips {
view_label: "Long Trips"
# This will ensure that we only see trips that are longer than average!
sql_always_where: ${trips.trip_duration}>=(SELECT tripduration FROM ${average_trip_duration.SQL_TABLE_NAME});;
}
${view_name.SQL_TABLE_NAME}ne fonctionne pas avec le paramètresql_triggerutilisé avec les groupes de données.
Portée et appellation
Vous pouvez nommer des explorations, des vues, des champs et des ensembles, ces identifiants Looker étant écrits sans guillemets.
Les champs et ensembles LookML ont des noms complets et des noms abrégés:
- Les noms complets se présentent sous la forme
<view>.<field-name | set-name>. La partie gauche indique la portée, c'est-à-dire la vue contenant le champ ou l'ensemble. La partie droite correspond au nom du champ ou de l'ensemble à proprement parler. - Les noms courts prennent simplement la forme
<field-name | set-name>, sans point de séparation. Looker développe les noms abrégés en noms complets en utilisant la portée dans laquelle ils sont employés.
Vous trouverez ci-dessous un exemple montrant de nombreuses formes de noms et de champs d'application. Ce groupe de champs, quoique peu réaliste, est représentatif des différentes expressions de portée possibles.
view: orders { # "orders" becomes the containing scope
measure: count { # short name, equivalent to orders.count
type: count
}
dimension: customer_id { # short name, equivalent to orders.customer_id
type: number
sql: ${TABLE}.customer_id ;;
}
dimension: customer_address { # short name, equivalent to orders.customer_address
sql: ${customer.address} ;; # full name, references a field defined in the "customer" view
}
set: drill_fields { # short name, equivalent to orders.drill_fields
fields: [
count, # short name, equivalent to orders.count
customer.id # full name, references a field defined in the "customer" view
]
}
}
Dans la déclaration dimension: customer_address, notez que la vue sous-jacente du bloc SQL (customer) est différente de la portée de la vue englobante (orders). Cette distinction peut être utile lorsque vous devez comparer des champs entre deux vues différentes.
Lorsqu'une vue (appelée "vue A") fait référence à un champ défini dans une autre vue (nous l'appellerons "vue B"), gardez à l'esprit les points suivants:
- Le fichier de la vue B doit être inclus dans le même modèle que celui de la vue A à l'aide du paramètre
include. - La vue B doit être jointe à la vue A dans une ou plusieurs explorations. Pour en savoir plus sur les jointures, consultez la page Utiliser des jointures dans LookML.
Dialecte SQL
Looker accepte de nombreux types de bases de données, tels que MySQL, Postgres, Redshift, BigQuery, etc. Chaque base de données accepte un ensemble de fonctionnalités légèrement différent, avec des noms de fonctions différents, appelés dialectes SQL.
LookML est compatible avec tous les dialectes SQL, sans distinction. Toutefois, vous devez inclure des expressions de code SQL (appelées blocs SQL) dans certains paramètres LookML. En effet, avec ces paramètres, Looker transmet directement l'expression SQL à la base de données, de sorte que vous devez utiliser le dialecte SQL correspondant à cette dernière. Par exemple, si vous utilisez une fonction SQL, il doit s'agir d'une fonction prise en charge par votre base de données.
Blocs SQL
Certains paramètres LookML imposent de fournir des expressions SQL brutes afin que Looker puisse comprendre comment extraire des données de la base.
Les paramètres LookML commençant par sql_ attendent une expression SQL d'une certaine forme. Exemples : sql_always_where, sql_on et sql_table_name. sql est le paramètre LookML le plus courant pour les blocs SQL. Il est utilisé dans les définitions des champs de dimension et de mesure afin de spécifier l'expression SQL qui définit la dimension ou la mesure.
Le code spécifié dans un bloc SQL peut être un simple nom de champ ou une instruction de sous-sélection corrélée sophistiquée. Le contenu peut être relativement complexe et répondre à pratiquement tous vos besoins pour exprimer une logique de requête personnalisée en SQL brut. Notez que le code que vous utilisez dans les blocs SQL doit correspondre au dialecte SQL utilisé par la base de données.
Exemples de blocs SQL de dimensions et de mesures
Vous trouverez ci-dessous plusieurs exemples de blocs SQL de dimensions et de mesures. L'opérateur de substitution LookML ($) peut donner l'impression que ces déclarations sql ne ressemblent pas vraiment à du code SQL. Toutefois, une fois la substitution effectuée, la chaîne obtenue est un code purement SQL, que Looker injecte dans la clause SELECT de la requête.
dimension: id {
primary_key: yes
sql: ${TABLE}.id ;; # Specify the primary key, id
}
measure: average_cost {
type: average
value_format: "0.00"
sql: ${order_items.cost} ;; # Specify the field that you want to average
}
dimension: name {
sql: CONCAT(${first_name}, ' ', ${last_name}) ;;
}
dimension: days_in_inventory {
type: int
sql: DATEDIFF(${sold_date}, ${created_date}) ;;
}
Comme illustré dans les deux dimensions ci-dessus, les blocs SQL peuvent utiliser des fonctions prises en charge par la base de données sous-jacente (comme les fonctions MySQL CONCAT et DATEDIFF dans cet exemple).
Exemple de bloc SQL contenant une sous-sélection corrélée
Dans le bloc SQL d'un champ, vous pouvez placer n'importe quelle expression SQL, y compris une sous-sélection corrélée. En voici un exemple :
view: customers {
dimension: id {
primary_key: yes
sql: ${TABLE}.id ;;
}
dimension: first_order_id {
sql: (SELECT MIN(id) FROM orders o WHERE o.customer_id=customers.id) ;;
# correlated subselect to derive the value for "first_order_id"
}
}
Exemple de bloc SQL destiné à des tables dérivées
Les tables dérivées utilisent le bloc SQL pour spécifier la requête déduite de la table. En voici un exemple :
view: user_order_facts {
derived_table: {
sql: # Get the number of orders for each user
SELECT
user_id
, COUNT(*) as lifetime_orders
FROM orders
GROUP BY 1 ;;
}
# later, dimension declarations reference the derived column(s)
dimension: lifetime_orders {
type: number
}
}
Références des types de champs LookML
Lorsque vous référencez un champ LookML existant dans un autre champ, vous pouvez demander à Looker de considérer le champ référencé comme un type de données spécifique. Pour cela, saisissez deux fois deux points (::), suivis du type de données souhaité. Par exemple, si vous référencez la dimension orders.created_date dans un autre champ, vous pouvez utiliser la syntaxe ${orders.created_date::date} pour vous assurer que le champ created_date sera traité comme un champ de date dans le code SQL généré par Looker, plutôt que d'être converti en chaîne.
Le type de données que vous pouvez utiliser dans une référence dépend de celui utilisé dans le champ d'origine que vous référencez actuellement. Par exemple, si vous référencez un champ de chaîne, le seul type de données que vous pourrez spécifier est ::string. Voici la liste complète des références de types de champs autorisés et que vous pouvez utiliser pour chaque type de champ :
- Dans une référence à un champ de chaîne, vous pouvez utiliser
::string. - Dans une référence à un champ numérique, vous pouvez utiliser
::stringet::number. - Dans une référence à un champ de date ou d'heure, vous pouvez utiliser
::string,::dateet::datetime.Les références qui utilisent::stringet::daterenvoient des données dans le fuseau horaire de la requête, tandis que les références qui utilisent::datetimerenvoient des données dans le fuseau horaire de la base de données. - Dans une référence à un champ oui/non, vous pouvez utiliser
::string,::numberet::boolean. Les références de champ utilisant le type::booleanne sont pas disponibles pour les dialectes de base de données qui ne prennent pas en charge le type de données booléen. - Dans une référence à un champ d'emplacement, vous pouvez utiliser
::latitudeet::longitude.
Utilisation des références des types de champs LookML avec les champs de date
Par exemple, supposons que vous ayez une dimension enrollment_month et une dimension graduation_month, toutes deux créées dans des groupes de dimensions de type: time. Dans cet exemple, la dimension enrollment_month est générée par le groupe de dimensions type: time suivant:
dimension_group: enrollment {
type: time
timeframes: [time, date, week, month, year, raw]
sql: ${TABLE}.enrollment_date ;;
}
De même, la dimension graduation_month est créée par le groupe de dimensions type: time suivant:
dimension_group: graduation {
type: time
timeframes: [time, date, week, month, year, raw]
sql: ${TABLE}.graduation_date ;;
}
À l'aide des dimensions enrollment_month et graduation_month, vous pouvez calculer le nombre de mois ou d'années écoulés entre l'inscription d'un étudiant et l'obtention de son diplôme en créant un groupe de dimensions type: duration. Toutefois, certains champs de date étant convertis sous forme de chaînes dans le code SQL généré par Looker, la définition des dimensions enrollment_month et graduation_month comme valeurs pour sql_start et sql_end peut entraîner une erreur.
Pour éviter qu'une erreur se produise lorsque ces champs de date et heure sont convertis sous forme de chaînes, vous pouvez créer un groupe de dimensions type: duration en référençant les périodes raw à partir des groupes de dimensions enrollment et graduation dans les paramètres sql_start et sql_end:
dimension_group: enrolled {
type: duration
intervals: [month, year]
sql_start: ${enrollment_raw} ;;
sql_end: ${graduation_raw} ;;
}
Dans l'interface utilisateur Explorer, cela génère un groupe de dimensions appelé Durée d'inscription, avec des dimensions individuelles Mois d'inscription et Années d'inscription.
Une alternative plus simple à l'utilisation de la période raw dans un groupe de dimensions de type: duration consiste à spécifier le type de référence ::date ou ::datetime pour les champs référencés dans les paramètres sql_start et sql_end.
dimension_group: enrolled {
type: duration
intervals: [month, year]
sql_start: ${enrollment_month::date} ;;
sql_end: ${graduation_month::date} ;;
}
Dans cet exemple, le code LookML crée également un groupe de dimensions Durée enregistrée, mais l'utilisation de la référence ::date permet d'utiliser les dimensions enrollment_month et graduation_month sans utiliser de période raw ni les caster en tant que chaînes avec SQL.
Pour voir un autre exemple d'utilisation des références de type de champ LookML pour créer des groupes de dimensions personnalisés de type: duration, consultez la page de documentation du paramètre dimension_group.
Cette syntaxe n'est pas disponible avec les mesures de
type: list, qui ne peuvent plus être référencées à partir de Looker 6.8.
Constantes LookML
Le paramètre constant vous permet de spécifier une constante que vous pouvez utiliser dans un projet LookML. Avec les constantes LookML, vous pouvez définir une valeur une fois et la référencer à n'importe quel endroit de votre projet qui accepte les chaînes et ainsi, limiter les répétitions dans votre code LookML.
Les constantes doivent être déclarées dans un manifeste de projet et la valeur de la constante doit être une chaîne. Par exemple, vous pouvez définir une constante city avec la valeur "Okayama" comme suit :
constant: city {
value: "Okayama"
}
La constante city peut ensuite être référencée dans l'ensemble de votre projet à l'aide de la syntaxe @{city}. Par exemple, vous pouvez utiliser la constante city avec le paramètre label dans l'exploration users:
explore: users {
label: "@{city} Users"
}
Looker affiche ensuite Utilisateurs Okayama dans le menu Explorer et dans le titre de l'exploration, plutôt que Utilisateurs par défaut.
Pour en savoir plus et découvrir comment utiliser des constantes LookML pour écrire du code réutilisable, consultez la page de documentation du paramètre constant.