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 pouvoir 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 ($)
Avec l'opérateur de substitution $, le code LookML est 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 connecté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 dans la vue sur laquelle vous travaillez. Exemple :
measure: total_population {
type: sum
sql: ${population} ;;
}
${view_name.field_name} fait référence à une dimension ou une mesure 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 table dérivée. À noter que dans cette référence, SQL_TABLE_NAME 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.
Chaque champ ou ensemble LookML possède un nom complet et un nom abrégé :
- Le nom complet se présente 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. - Le nom abrégé se présente sous 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.
Voici un exemple illustrant plusieurs formes de nom et de portée. 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 pour comparer les champs de deux vues distinctes.
Lorsqu'une vue (que nous appellerons "vue A") fait référence à un champ défini dans une autre vue (que nous appellerons "vue B"), vous devez tenir compte de plusieurs éléments :
- Le fichier de la vue B doit être inclus dans le même modèle que la vue A à l'aide du
includeparamètre. - La vue B doit être jointe à la vue A dans une ou plusieurs explorations. Pour en savoir plus sur les jointures, consultez la page Travailler avec JOINS dans LookML.
Dialecte SQL
Looker prend en charge de nombreux types de bases de données, tels que MySQL, Postgres, Redshift et BigQuery. Chaque base de données supporte un ensemble de caractéristiques légèrement différent, avec des noms de fonction distincts, réunies sous l'appellation de dialecte SQL.
LookML est compatible avec tous les dialectes SQL, sans distinction. Toutefois, dans certains paramètres LookML, vous devez inclure des expressions de code SQL (appelées blocs SQL). 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_ nécessitent une expression SQL, qu'elle qu'en soit la forme. Exemples : sql_always_where, sql_on et sql_table_name. Le paramètre LookML de bloc SQL le plus courant est sql pour les définitions de champs de dimension et de mesure. Il indique l'expression SQL définissant 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. Avec l'opérateur de substitution LookML ($), ces déclarations sql ne ressemblent pas vraiment à du code SQL. Toutefois, une fois la substitution effectuée, la chaîne résultante est du code SQL pur, 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 figurant 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 instruction 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 avec un autre champ, vous pouvez utiliser la syntaxe ${orders.created_date::date} pour vous assurer que le champ created_date sera considéré comme un champ de date, et non comme une chaîne, dans l'expression SQL que Looker va générer.
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 pouvez 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 utilisant::stringet::daterenvoient des données dans le fuseau horaire de la requête, tandis que les références utilisant::datetimerenvoient des données dans le fuseau horaire de la base de données. - Dans une référence à un champ yesno, vous pouvez utiliser
::string,::numberet::boolean. Les références de champs utilisant le type::booleanne sont pas disponibles pour les dialectes de bases de données ne prenant pas en charge le type de données booléen. - Dans une référence à un champ de localisation, vous pouvez utiliser
::latitudeet::longitude.
Utilisation des références des types de champs LookML avec les champs de date
Supposons, par exemple, 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 suivant de type: time :
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 suivant de type: time :
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 et l'obtention du diplôme d'un étudiant en créant un groupe de dimensions de type: duration. Toutefois, certains champs de date étant considérés comme des chaînes dans l'expression SQL que Looker aura générée, si vous configurez les dimensions enrollment_month et graduation_month en tant que valeurs pour sql_start et sql_end, une erreur va alors s'afficher.
Pour éviter cela, vous pouvez créer un groupe de dimensions type: duration, en référençant les périodes raw 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 d'Exploration, cela génère un groupe de dimensions appelé Duration Enrolled (Durée d'inscription), avec les dimensions individuelles Months Enrolled (Mois d'inscription) et Years Enrolled (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} ;;
}
Le code LookML de cet exemple crée également un groupe de dimensions Duration Enrolled (Durée d'inscription), 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 convertir en chaînes avec SQL.
Pour consulter un autre exemple d'utilisation des références de types de champs LookML pour créer des groupes de dimensions personnalisés de type: duration, consultez la page de la documentation portant sur le paramètre dimension_group.
Cette syntaxe n'est pas disponible avec les mesures de
type: list, qui ne peuvent pas être référencées dans la version 6.8 de Looker.
Constantes LookML
Le paramètre constant vous permet de préciser 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 fichier 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 alors Okayama Users (Utilisateurs d'Okayama) dans le menu Explore (Explorer) et dans le titre de l'exploration, au lieu de la valeur par défaut Users (Utilisateurs).
Pour en savoir plus sur les constantes LookML et consulter des exemples d'utilisation, lisez la page de la documentation portant sur le paramètre constant.