Termes et concepts LookML

Cette page définit les termes et concepts de base suivants, que vous rencontrerez probablement souvent lors du développement 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 utiliser LookML. Cependant, leurs requêtes reposent sur les éléments LookML sous-jacents qui sont abordés sur cette page.

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

Pour en savoir plus sur les différences entre les termes et concepts similaires dans Looker et Data Studio, consultez la page de documentation Termes et concepts communs à Looker et Data Studio.

Projet LookML

Dans Looker, un projet est un ensemble de fichiers qui décrivent les objets, les connexions de base de données et les éléments d'interface utilisateur qui seront utilisés pour exécuter des requêtes SQL. Au niveau le plus élémentaire, ces fichiers décrivent la relation entre les tables de votre base de données et la manière dont 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 référentiel 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 de base de données à utiliser pour votre projet Looker.

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

Pour savoir comment créer un projet, consultez la page de documentation Générer un modèle. Pour savoir comment accéder à des projets LookML existants et les modifier, consultez la page de documentation Accéder aux informations sur le projet 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 composé d'autres éléments LookML.

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

  • Un modèle contient des informations sur les tables à utiliser et sur la manière dont elles doivent être jointes. En principe, c'est à ce niveau que vous définissez le modèle, ses explorations et ses jointures.
  • Une vue contient des informations sur la manière d'accéder à des informations ou de les calculer à partir de chaque table (ou de plusieurs tables jointes). C'est généralement à ce niveau que vous définissez la vue et ses dimensions, mesures et 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 dans plusieurs modèles.
  • Un fichier manifeste peut contenir des instructions pour utiliser des fichiers importés d'un autre projet ou pour les paramètres de localisation de votre projet.

Outre les fichiers de modèle, de vue, d'exploration et manifeste, 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. 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, consultez la page de documentation Fichiers de projets LookML.

Tous ces fichiers constituent un projet. Si vous utilisez Git pour le contrôle des versions, chaque projet est généralement sauvegardé par son propre référentiel 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.

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 fichier pour chaque table de la base de données.
  • Un fichier de modèle. Le fichier de modèle déclare une exploration par 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 illustré dans le diagramme des composantes d'un projet, un projet contient généralement un ou plusieurs fichiers de modèle, qui contiennent des paramètres définissant un modèle, ses explorations et ses jointures. En outre, les projets comportent généralement un ou plusieurs fichiers de vue, contenant chacun des paramètres qui définissent la vue, ses champs (y compris les dimensions et les mesures) et des jeux 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, Chaque modèle peut présenter des données différentes à différents utilisateurs. 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. Un développeur définit également les explorations d'un modèle dans le fichier de modèle. Par défaut, les explorations sont organisées sous le nom du modèle dans lequel elles sont définies. Vos utilisateurs voient les modèles listés dans le menu Exploration.

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

Pour en savoir plus sur les paramètres LookML qui peuvent être utilisés dans un fichier de modèle, consultez la page de documentation Paramètres de modèle.

Afficher

Une déclaration de vue définit une liste de champs (dimensions ou mesures) et leur liaison avec une table sous-jacente ou une table dérivée. Dans LookML, les vues renvoient généralement à une table de base de données sous-jacente, mais peuvent aussi représenter une table dérivée.

Une vue peut être jointe à d'autres vues. La relation entre les vues est habituellement définie dans le cadre d'une déclaration d'exploration, dans un fichier de modèle.

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

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

Pour en savoir plus sur les fichiers de vue, y compris sur leur structure et leur syntaxe générale, consultez la page de documentation Types de fichiers dans un projet LookML.

Pour en savoir plus sur les paramètres LookML qui peuvent être utilisés dans un fichier d'affichage, consultez la page de documentation Paramètres de vue.

Explorer

Une exploration est une vue que les utilisateurs peuvent interroger. Vous pouvez considérer l'exploration comme un point de départ pour une requête ou, en termes SQL, comme le FROM d'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) qui correspond à un tableau de conversion pour les noms d'état ne justifie pas une exploration, car les utilisateurs métier n'ont jamais besoin de l'interroger directement. En revanche, les utilisateurs métier souhaitent probablement interroger une vue Orders (Commandes). Il est donc judicieux de définir une exploration pour Orders. Pour savoir comment les utilisateurs interagissent avec les explorations pour interroger vos données, consultez la page de documentation Afficher les explorations et interagir avec elles dans Looker.

Dans Looker, les explorations sont présentées aux utilisateurs dans le menu Exploration. Les explorations sont listé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 explore paramètre. Dans l'exemple suivant d'un fichier de modèle, l'exploration orders pour 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 connection paramètre est utilisé pour spécifier la connexion de base de données pour le modèle, et le include paramètre est utilisé pour spécifier les fichiers que le modèle pourra référencer.

La déclaration explore de cet exemple 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. Pour en savoir plus sur les paramètres LookML qui peuvent être utilisés avec le paramètre join, consultez la page de documentation Paramètres de jointure.

Champs de dimension et de mesure

Les vues contiennent des champs, essentiellement des dimensions et des mesures, qui sont les composantes fondamentales 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 :

  • Un attribut, directement associé à une colonne d'une table sous-jacente
  • Une valeur factuelle ou numérique
  • 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 Products (Produits) pourraient être le nom du produit, le modèle du produit, la couleur du produit, le prix du produit, la date de création du produit 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 Sales (Ventes) pourraient inclure la totalité des 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 pages consacrées aux types de dimensions et aux types de mesures.

Dans Looker, les champs sont listés sur la page Exploration dans le sélecteur de champs situé à gauche de la page. Vous pouvez développer une vue dans le sélecteur de champs pour afficher la liste des champs qui peuvent être interrogés à 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 que l'utilisation de l'opérateur de substitution ($) permet de faire référence à des champs sans fournir de 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 plusieurs dimensions liées au temps à la fois, et des champs filter, qui présentent divers cas d'utilisation avancés, tels que les filtres basés sur des modèles.

Pour en savoir plus sur la déclaration de champs et les différents paramètres qui peuvent leur être appliqués, consultez la page de documentation Paramètres de champ.

Jointures

Dans le cadre d'une déclaration explore, chaque déclaration join spécifie une vue qui peut être jointe à 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, qui est 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 les 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. Il doit être nommé manifest.lkml et être situé à la racine de votre répertoire Git. Lorsque vous utilisez des dossiers dans l'IDE, assurez-vous que le fichier manifest.lkml est conservé à la racine de la structure de répertoire de votre projet.

Pour importer des fichiers LookML d'un autre projet, utilisez le fichier manifeste du projet 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ésigné les projets externes dans le fichier manifeste du projet, vous pouvez vous servir du include paramètre de votre fichier de modèle pour ajouter des 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 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 Localisation de votre modèle LookML.

Sets

Dans Looker, un set est une liste qui définit un groupe de champs utilisés ensemble. Les sets sont généralement utilisés pour désigner les champs à afficher lorsqu'un utilisateur détaille des données. Les sets d'analyse sont spécifiés champ 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 sets peuvent également faire office de fonction de sécurité, pour définir des groupes de champs visibles par certains utilisateurs. L'exemple suivant montre une déclaration de set dans une vue order_items, qui définit des champs listant les détails pertinents concernant un article acheté. Notez que les sets 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
  ]
}

Pour en savoir plus sur leur utilisation, lisez la page de documentation Paramètre set.

Drill down

Dans Looker, vous pouvez configurer un champ afin que les utilisateurs puissent approfondir les données. Cette fonction est à la fois compatible avec les tables de résultats de requête et les tableaux de bord. Elle lance une nouvelle requête limitée par la valeur sur laquelle vous cliquez.

Le comportement d'analyse est différent pour les dimensions et les mesures :

  • Lorsque vous détaillez une dimension, la nouvelle requête filtre sur 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 n'affichera les commandes que pour cette date spécifique.
  • Lorsque l'utilisateur détaille une mesure, la nouvelle requête présente l'ensemble 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. Si la mesure détaillée est une valeur maximale, minimale ou moyenne, toutes les lignes ayant contribué à la mesure apparaissent. Cela signifie que le détail d'une mesure maximale, par exemple, affiche toutes les lignes qui ont été utilisées pour calculer la valeur maximale, et non pas une seule ligne pour la valeur maximale.

Les champs à afficher pour la nouvelle requête de détail peuvent être définis par un set, ou par le drill_fields paramètre (pour les champs) ou le drill_fields paramètre (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 dans la base de données. Les tables dérivées sont créées à l'aide du derived_table paramètre dans une view déclaration. Looker accède aux tables dérivées comme s'il s'agissait de tables physiques avec leurs propres colonnes. Elle est présentée, via le paramètre `derived_table`, dans une vue spécifique dont les dimensions et mesures sont définies de la même manière que celles des autres vues. 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 des tables dérivées écrites dans un schéma brouillon de votre base de données et régénérées automatiquement selon la fréquence 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 à une base de données

La connexion de base de données que Looker utilise pour exécuter les requêtes constitue un autre aspect important des projets LookML. Un administrateur Looker utilise la page Connexions pour configurer les connexions de base de données, et 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 remplit 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 avertit 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 faire référence à cette exploration. Dans cet exemple, l'IDE Looker affiche un avertissement indiquant que l'exploration e_FLIGHTS_pdt n'existe pas. En outre, l'IDE suggère le nom d'une exploration existante, e_flights_pdt :

Cependant, si votre projet contenait à la fois e_FLIGHTS_pdt et e_flights_pdt, l'IDE Looker ne pourrait pas vous corriger, vous devriez donc être certain de la version que vous souhaitiez utiliser. Nous recommandons généralement d'utiliser des minuscules pour nommer des objets LookML.

Les noms de dossiers de l'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 include paramètre. Une fois de plus, l'IDE Looker indique une erreur si la casse ne correspond pas au dossier existant de votre projet :

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