Termes et concepts LookML

Cette page définit les termes et concepts clés suivants, que vous rencontrerez probablement souvent lors du développement de LookML:

Les Looks et les tableaux de bord définis par l'utilisateur ne sont pas décrits sur cette page, car les utilisateurs les créent sans code LookML. Cependant, leurs requêtes reposent sur les éléments LookML sous-jacents abordés sur cette page.

Consultez le glossaire Looker pour obtenir la liste complète des termes et définitions utilisés dans Looker. Pour une présentation complète des paramètres LookML que vous pouvez utiliser dans un projet LookML, consultez la page de référence rapide de LookML.

projet LookML

Dans Looker, un projet est un ensemble de fichiers décrivant les objets, les connexions à la base de données et les éléments de l'interface utilisateur qui serviront à exécuter des requêtes SQL. Au niveau le plus élémentaire, ces fichiers décrivent comment vos tables de base de données sont liées les unes aux autres et comment Looker doit les interpréter. Les fichiers peuvent également inclure des paramètres LookML qui définissent ou modifient les options présentées dans l'interface utilisateur de Looker. Chaque projet LookML se trouve dans son propre dépôt Git pour le contrôle des versions.

Une fois que vous avez connecté Looker à votre base de données, vous pouvez spécifier la connexion à la base de données à utiliser pour votre projet Looker.

Vous pouvez accéder à vos projets depuis le menu Développer de Looker (voir Accéder aux fichiers d'un projet pour en savoir plus et accéder à d'autres options).

Consultez la section Créer un projet LookML pour en savoir plus sur la création d'un projet, ainsi que la section Accéder aux informations relatives à un projet et les modifier pour savoir comment accéder aux projets LookML existants et les modifier.

Composantes d'un projet

Un projet LookML peut contenir des modèles, des vues et des tableaux de bord LookML, chacun étant constitué d'autres éléments LookML.

Comme le montre le schéma, voici quelques-uns des types de fichiers les plus courants dans un projet LookML:

  • Un model contient des informations sur les tables à utiliser et sur la manière dont elles doivent être jointes. C'est ici que vous définirez généralement le modèle, ses explorations et ses jointures.
  • Une vue contient des informations sur la façon d'accéder aux informations de chaque table ou de les calculer pour chaque table (ou pour plusieurs tables jointes). C'est ici que vous définirez généralement la vue, ses dimensions et mesures, ainsi que ses ensembles de champs.
  • Une exploration est souvent définie dans un fichier de modèle, mais vous avez parfois besoin d'un fichier d'exploration distinct pour une table dérivée, ou pour étendre ou affiner une exploration sur plusieurs modèles.
  • Un fichier manifeste peut contenir des instructions pour utiliser des fichiers importés depuis un autre projet ou pour définir les paramètres de localisation de votre projet.

En plus des fichiers de modèle, de vue, d'exploration et des fichiers manifestes, un projet peut contenir d'autres types de fichiers liés à des éléments tels que les tableaux de bord intégrés, la documentation, la localisation, etc. Consultez la page de documentation Fichiers de projet LookML pour en savoir plus sur ces types de fichiers, ainsi que sur les autres types de fichiers que vous pouvez avoir dans votre projet LookML.

Ensemble, ces fichiers constituent un seul projet. Si vous utilisez Git pour le contrôle des versions, chaque projet est généralement sauvegardé par son propre dépôt Git.

Origine des projets et fichiers LookML

La méthode la plus courante pour créer des fichiers LookML consiste à générer un projet LookML à partir de votre base de données. Vous pouvez également créer un projet vide et créer manuellement ses fichiers LookML, ou créer un projet en clonant un dépôt Git existant.

Lorsque vous créez un nouveau projet depuis votre base de données, Looker crée un jeu de fichiers de référence que vous pouvez utiliser comme modèle pour composer le projet :

  • Plusieurs fichiers de vue (un par table de la base de données)
  • Un fichier de model. Le fichier de modèle déclare une exploration pour chaque vue. Chaque déclaration d'exploration inclut une logique join pour joindre toute vue que Looker peut déterminer comme étant liée à l'exploration.

À ce stade, vous pouvez personnaliser le projet en retirant les vues et explorations inutiles et en ajoutant des dimensions et mesures personnalisées.

Principales structures LookML

Comme indiqué dans les parties du schéma d'un projet, un projet contient généralement un ou plusieurs fichiers de modèle, contenant des paramètres qui définissent le modèle, ainsi que ses explorations et jointures. En outre, les projets contiennent généralement un ou plusieurs fichiers de vue, chacun contenant des paramètres qui définissent cette vue, ses champs (y compris les dimensions et les mesures) et des ensembles de champs. Le projet peut également contenir un fichier manifeste, qui vous permet de configurer les paramètres au niveau du projet. Cette section décrit ces principales structures.

Modèle

Un modèle est un portail personnalisé à l'intérieur de la base de données, conçu pour permettre une exploration intuitive des données par des utilisateurs métier spécifiques. Une même connexion de base de données d'un projet LookML peut comporter plusieurs modèles, chacun d'eux pouvant présenter des données différentes d'un utilisateur à l'autre. Par exemple, les commerciaux n'ont pas besoin des mêmes données que les dirigeants de l'entreprise, et vous devrez probablement développer deux modèles pour présenter des vues de la base de données adaptées à chaque utilisateur.

Un modèle spécifie une connexion à une seule base de données. Il définit également les explorations d'un modèle dans son fichier. Par défaut, les explorations sont organisées sous le nom de modèle dans lequel elles sont définies. Vos utilisateurs voient les modèles répertoriés dans le menu Explorer.

Consultez la page de documentation Types de fichiers dans un projet LookML pour en savoir plus sur les fichiers de modèle, y compris sur la structure et la syntaxe générale des fichiers de modèle.

Consultez la page de documentation Paramètres de modèle pour en savoir plus sur les paramètres LookML pouvant être utilisés dans un fichier de modèle.

Afficher

Une déclaration de vue définit une liste de champs (dimensions ou mesures) et leur association à une table sous-jacente ou dérivée. En LookML, une vue fait généralement référence à une table de base de données sous-jacente, mais elle peut également représenter une table dérivée.

Une vue peut être jointe à d'autres vues. La relation entre les vues est généralement définie dans une déclaration Explore (exploration) dans un fichier de modèle.

Par défaut, les noms des vues apparaissent au début des noms des dimensions et des mesures dans le tableau de données de l'exploration. Cette convention d'attribution de noms permet de savoir à quelle vue le champ appartient. Dans l'exemple suivant, les noms de vues Orders (Commandes) et Users (Utilisateurs) sont listés avant les noms des champs de la table de données:

Table de données d'un exemple de requête avec les champs "Date de création des commandes", "Identifiant utilisateur" et "Nombre de commandes" sélectionnés.

Consultez la documentation Types de fichiers dans un projet LookML pour en savoir plus sur les fichiers de vue, y compris sur la structure et la syntaxe générale des fichiers de vue.

Consultez la page de documentation Paramètres de vue pour en savoir plus sur les paramètres LookML pouvant être utilisés dans un fichier de vue.

Explorer

Une exploration est une vue que les utilisateurs peuvent interroger. Vous pouvez considérer l'exploration comme le point de départ d'une requête ou, en termes SQL, comme l'FROM dans une instruction SQL. Toutes les vues ne sont pas des explorations, car elles ne décrivent pas toutes une entité présentant un intérêt. Par exemple, une vue States (États) correspondant à une table de conversion de noms d'États ne justifie pas une exploration, car les utilisateurs professionnels n'ont jamais besoin de l'interroger directement. En revanche, les utilisateurs professionnels souhaitent probablement pouvoir interroger une vue Orders (Commandes). Il est donc judicieux de définir une exploration pour les Orders (Commandes). Consultez la page de documentation Afficher et interagir avec des explorations dans Looker pour en savoir plus sur la manière dont les utilisateurs interagissent avec les explorations pour interroger vos données.

Dans Looker, vos utilisateurs peuvent voir la liste des explorations dans le menu Explore (Explorer). Les explorations sont répertoriées sous les noms des modèles auxquels elles appartiennent.

Par convention, les explorations sont déclarées dans le fichier de modèle avec le paramètre explore. Dans cet exemple de fichier de modèle, l'exploration orders d'une base de données d'e-commerce est définie dans le fichier de modèle. Les vues orders et customers référencées dans la déclaration explore sont définies ailleurs, dans leurs fichiers de vue respectifs.

connection: order_database
include: "filename_pattern"

explore: orders {
  join: customers {
    sql_on: ${orders.customer_id} = ${customers.id} ;;
  }
}

Dans cet exemple, le paramètre connection sert à spécifier la connexion à la base de données du modèle, tandis que le paramètre include permet de spécifier les fichiers que le modèle peut référencer.

Dans cet exemple, la déclaration explore spécifie également les relations de jointure entre les vues. Pour en savoir plus sur les déclarations join, consultez la section sur les jointures de cette page. Consultez la page de documentation Paramètres de jointure pour en savoir plus sur les paramètres LookML pouvant être utilisés avec le paramètre join.

Champs de dimension et de mesure

Les vues contiennent des champs, principalement des dimensions et des mesures, qui sont les éléments de base des requêtes Looker.

Dans Looker, une dimension est un champ pouvant faire partie d'un groupe et utilisable pour filtrer les résultats d'une requête. Il peut s'agir de l'un des éléments suivants:

  • d'un attribut, directement associé à une colonne d'une table sous-jacente ;
  • d'une valeur factuelle ou numérique ;
  • d'une valeur dérivée, calculée à partir des valeurs d'autres champs sur une ligne unique.

Dans Looker, les dimensions apparaissent toujours dans la clause GROUP BY du code SQL généré par Looker.

Par exemple, les dimensions d'une vue Produits peuvent inclure le nom, le modèle, la couleur, le prix, la date de création et la date de fin de vie du produit.

Une mesure est un champ qui utilise une fonction d'agrégation SQL, telle que COUNT, SUM, AVG, MIN ou MAX. Un champ calculé à partir d'autres valeurs de mesure est également une mesure. Les mesures permettent de filtrer des valeurs groupées. Par exemple, les mesures d'une vue Ventes peuvent inclure le nombre total d'articles vendus (un nombre), le prix de vente total (une somme) et le prix de vente moyen (une moyenne).

Le comportement et les valeurs attendues d'un champ dépendent de son type déclaré, tel que string, number ou time. Pour les mesures, les types incluent des fonctions d'agrégation, telles que sum et percent_of_previous. Pour en savoir plus, consultez les sections Types de dimensions et Types de mesures.

Dans Looker, les champs sont listés sur la page Explorer dans le sélecteur de champs, à gauche de la page. Vous pouvez développer une vue du sélecteur de champs pour afficher la liste des champs que vous pouvez interroger à partir de cette vue.

Par convention, les champs sont déclarés dans la vue dont ils font partie, enregistrée dans un fichier de vue. L'exemple suivant illustre plusieurs déclarations de dimension et de mesure. Notez l'utilisation de l'opérateur de substitution ($) pour référencer des champs sans avoir à définir un nom de colonne SQL complet.

Voici quelques exemples de déclarations de dimensions et de mesures :

view: orders {
  dimension: id {
    primary_key: yes
    type: number
    sql: ${TABLE}.id ;;
  }
  dimension: customer_id {
    sql: ${TABLE}.customer_id ;;
  }
  dimension: amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.amount ;;
  }
  dimension_group: created {
    type: time
    timeframes: [date, week]
    sql: ${TABLE}.created_at ;;
  }
  measure: count {
    type: count           # creates sql COUNT(orders.id)
    sql: ${id} ;;
  }
  measure: total_amount {
    type: sum             # creates sql SUM(orders.amount)
    sql: ${amount} ;;
  }
}

Vous pouvez également définir un dimension_group, qui crée simultanément plusieurs dimensions temporelles, et des champs filter, qui peuvent être utilisés dans divers cas d'utilisation avancés, tels que les filtres modélisés.

Consultez la page de documentation Paramètres de champ pour en savoir plus sur la déclaration de champs et sur les différents paramètres pouvant leur être appliqués.

Jointures

Dans une déclaration explore, chaque déclaration join spécifie une vue pouvant être jointe dans l'exploration. Lorsqu'un utilisateur crée une requête incluant des champs de plusieurs vues, Looker génère automatiquement une logique de jointure SQL pour présenter correctement la totalité de ces champs.

Voici un exemple de jointure dans une déclaration explore:

# file: ecommercestore.model.lookml

connection: order_database
include: "filename_pattern"   # include all the views

explore: orders {
  join: customers {
    sql_on: ${orders.customer_id} = ${customers.id} ;;
  }
}

Pour en savoir plus, consultez la page de documentation Utiliser des jointures dans LookML.

Fichiers manifestes d'un projet

Votre projet peut contenir un fichier manifeste de projet, qui sera utilisé pour les paramètres au niveau du projet, tels que ceux permettant de spécifier d'autres projets à importer dans le projet actuel, de définir des constantes LookML, de spécifier des paramètres de localisation du modèle et d'ajouter des extensions et des visualisations personnalisées à votre projet.

Chaque projet peut contenir un seul fichier manifeste. Le fichier doit être nommé manifest.lkml et se trouver au niveau racine de votre dépôt Git. Lorsque vous utilisez des dossiers dans l'IDE, assurez-vous que le fichier manifest.lkml est conservé au niveau racine de la structure de répertoires de votre projet.

Pour importer des fichiers LookML d'un autre projet, utilisez le fichier manifeste de celui-ci pour nommer votre projet actuel et indiquer l'emplacement des projets externes, qui peuvent être stockés en local ou à distance. Exemple :

# This project
project_name: "my_project"

# The project to import
local_dependency: {
  project: "my_other_project"
}

remote_dependency: ga_360_block {
  url: "https://github.com/llooker/google_ga360"
  ref: "4be130a28f3776c2bf67a9acc637e65c11231bcc"
}

Après avoir défini les projets externes dans le fichier manifeste du projet, vous pouvez utiliser le paramètre include dans votre fichier de modèle pour ajouter les fichiers de ces projets externes à votre projet actuel. Exemple :

include: "//my_other_project/imported_view.view"
include: "//ga_360_block/*.view"

Pour en savoir plus, consultez la page de documentation Importer des fichiers à partir d'autres projets.

Pour ajouter des éléments de localisation à votre modèle, utilisez le fichier manifeste du projet pour définir des paramètres de localisation par défaut. Exemple :

localization_settings: {
  default_locale: en
  localization_level: permissive
}

La définition de paramètres de localisation par défaut est l'une des étapes de la localisation d'un modèle. Pour en savoir plus, consultez la page de documentation Localiser votre modèle LookML.

Jeux

Dans Looker, un ensemble est une liste qui définit un groupe de champs utilisés ensemble. En règle générale, les ensembles sont utilisés pour spécifier les champs à afficher après qu'un utilisateur a analysé les données en détail. Dans ce cas, les jeux sont spécifiés par champ, de sorte que vous maîtrisez totalement les données qui s'affichent lorsqu'un utilisateur clique sur une valeur dans une table ou un tableau de bord. Les ensembles peuvent également être utilisés comme fonctionnalité de sécurité pour définir des groupes de champs visibles par des utilisateurs spécifiques. L'exemple suivant montre une déclaration d'ensemble dans une vue order_items, définissant des champs qui répertorient les détails pertinents sur un article acheté. Notez que les jeux font référence à des champs d'autres vues en définissant une portée.

set: order_items_stats_set {
  fields: [
    id,  # scope defaults to order_items view
    orders.created_date,  # scope is "orders" view
    orders.id,
    users.name,
    users.history,  # show all products this user has purchased
    products.item_name,
    products.brand,
    products.category,
    total_sale_price
  ]
}

Consultez la page de documentation du paramètre set pour obtenir des informations complètes sur l'utilisation des ensembles.

Drill down

Dans Looker, vous pouvez configurer un champ afin que les utilisateurs puissent afficher le détail des données. L'analyse détaillée fonctionne à la fois dans les tables de résultats de requête et dans les tableaux de bord. La vue détaillée lance une nouvelle requête limitée par la valeur sur laquelle vous cliquez.

Le comportement de cette fonction est différent pour les dimensions et les mesures :

  • Lorsque vous affichez le détail d'une dimension, la nouvelle requête filtre la valeur détaillée. Par exemple, si vous cliquez sur une date spécifique dans une requête de commandes client par date, la nouvelle requête affichera uniquement les commandes passées à cette date.
  • Lorsque l'utilisateur détaille une mesure, la nouvelle requête présente le jeu de données ayant contribué à la mesure. Par exemple, lorsqu'il détaille un nombre, la nouvelle requête présente les lignes utilisées pour calculer ce nombre. Lorsque vous affichez le détail des mesures maximales, minimales et moyennes, l'analyse détaillée affiche toujours toutes les lignes qui ont contribué à cette mesure. Cela signifie que si vous affichez le détail d'une mesure maximale, par exemple, vous affichez toutes les lignes utilisées pour calculer la valeur maximale, et non une seule ligne pour cette valeur.

Les champs à afficher pour la nouvelle requête d'analyse peuvent être définis par un ensemble, ou être définis par le paramètre drill_fields (pour les champs) ou le paramètre drill_fields (pour les vues).

Tables dérivées

Une table dérivée est une requête dont les résultats sont utilisés comme s'il s'agissait d'une table réelle de la base de données. Les tables dérivées sont créées en utilisant le paramètre derived_table dans une déclaration view. Looker accède aux tables dérivées comme s'il s'agissait de tables physiques avec leurs propres colonnes. Une table dérivée est exposée dans sa propre vue, et définit les dimensions et les mesures de la même manière que les vues conventionnelles. Comme n'importe quelle autre vue, celle d'une table dérivée peut faire l'objet de requêtes et être jointe à d'autres vues.

Les tables dérivées peuvent également être définies comme des tables dérivées persistantes (PDT), qui sont écrites dans un schéma entièrement nouveau de votre base de données et générées automatiquement selon la planification que vous spécifiez avec une stratégie de persistance.

Pour en savoir plus, consultez la page de documentation Tables dérivées dans Looker.

Connexion à la base de données

Un autre élément important d'un projet LookML est la connexion à la base de données que Looker utilise pour exécuter des requêtes sur votre base de données. Un administrateur Looker utilise la page des connexions pour configurer les connexions à la base de données, tandis que les développeurs LookML utilisent le paramètre connection dans un fichier de modèle pour spécifier la connexion à utiliser pour le modèle. Si vous générez un projet LookML à partir de votre base de données, Looker renseigne automatiquement le paramètre connection dans le fichier de modèle.

Sensibilité à la casse

LookML est sensible à la casse, vérifiez donc la casse lorsque vous mentionnez des éléments LookML. Looker vous alerte si vous avez fait référence à un élément qui n'existe pas.

Par exemple, supposons que vous ayez une exploration appelée e_flights_pdt et qu'un développeur LookML utilise une casse incorrecte (e_FLIGHTS_pdt) pour la référencer. Dans cet exemple, l'IDE Looker affiche un avertissement indiquant que l'e_FLIGHTS_pdt d'exploration n'existe pas. De plus, l'IDE suggère le nom d'une exploration existante, qui est e_flights_pdt:

Toutefois, si votre projet contient à la fois e_FLIGHTS_pdt et e_flights_pdt, l'IDE Looker ne pourra pas vous corriger. Vous devez donc identifier la version souhaitée. En règle générale, il est recommandé d'utiliser des minuscules pour nommer les objets LookML.

Les noms des dossiers IDE sont également sensibles à la casse. Vous devez vérifier la casse du nom des fichiers dès que vous spécifiez des chemins de fichier. Par exemple, si vous avez un dossier nommé Views, vous devez utiliser la même casse dans le paramètre include. Là encore, l'IDE Looker indiquera une erreur si la casse ne correspond pas à celle d'un dossier existant de votre projet:

L'IDE Looker affiche un avertissement indiquant que l'inclusion ne correspond à aucun fichier.