Utilisation de jointures dans LookML

Les jointures vous permettent de connecter différentes vues afin d'explorer les données de plusieurs vues à la fois et de visualiser les relations entre les différentes parties de vos données.

Par exemple, votre base de données peut inclure les tables order_items, orders et users. Il est possible d'utiliser des jointures pour explorer simultanément les données de toutes les tables. Cette page explique comment utiliser la fonction de jointure de LookML, notamment ses paramètres spécifiques et ses modèles de jointure.

Les jointures commencent par une exploration

Les jointures sont définies dans le fichier de modèle pour établir la relation entre une exploration et une vue. Elles relient une ou plusieurs vues d'une exploration, directement ou par le biais d'une autre vue jointe.

Prenons l'exemple de deux tables de base de données : order_items et orders. Après avoir généré des vues pour les deux tables, déclarez l'une ou l'autre, voire les deux, dans le paramètre explore du fichier de modèle :

explore: order_items { ... }

Lorsque vous exécutez une requête à partir de l'exploration order_items, order_items s'affiche dans la clause FROM du code SQL généré :

SELECT ...
FROM order_items

Vous pouvez joindre des informations supplémentaires à l'exploration order_items. Par exemple, vous pouvez utiliser l'exemple de code LookML suivant pour joindre la vue orders à l'exploration order_items :

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
    sql_on: ${order_items.order_id} = ${orders.id} ;;
  }
}

Le code LookML présenté précédemment permet d'effectuer deux actions. Tout d'abord, vous pouvez voir les champs de orders et order_items dans le sélecteur de champs de l'exploration :

Deuxièmement, il décrit comment unir orders et order_items. Converti en SQL, ce code LookML se présenterait comme suit :

SELECT ...
FROM order_items
LEFT JOIN orders
ON order_items.order_id = orders.id

Ces paramètres LookML sont décrits plus en détail dans les sections suivantes.

Conseil de l'équipe de chat : Les utilisateurs s'interrogent le plus souvent sur l'erreur de validation "Champ inconnu ou inaccessible", qui peut être due à une jointure manquante. Pour en savoir plus, consultez Erreur : Champ inconnu ou inaccessible.

Paramètres de jointure

Quatre paramètres principaux sont utilisés pour les jointures : join, type, relationship et sql_on.

Étape n° 1 : Début de l'exploration

Commencez par créer l'exploration order_items :

explore: order_items { ... }

Étape n° 2 : join

Pour joindre une table, vous devez tout d'abord la déclarer dans une vue. Dans cet exemple, supposons que orders soit une vue existante dans votre modèle.

Ensuite, utilisez le paramètre join pour déclarer que vous souhaitez joindre la vue orders à l'exploration order_items :

explore: order_items {
  join: orders { ... }
}

Étape n° 3 : type

Déterminez le type de jointure à effectuer. Looker est compatible avec LEFT JOIN, INNER JOIN, FULL OUTER JOIN et CROSS JOIN. Ces jointures correspondent aux valeurs de paramètre type suivantes : left_outer, inner, full_outer et cross.

explore: order_items {
  join: orders {
    type: left_outer
  }
}

La valeur par défaut de type est left_outer.

Étape n° 4 : relationship

Définissez une relation de jointure entre l'exploration order_items et la vue orders. Il est important de déclarer correctement la relation d'une jointure pour garantir l'exactitude des mesures calculées par Looker. La relation est définie de l'exploration order_items à la vue orders. Les options possibles sont one_to_one, many_to_one, one_to_many et many_to_many.

Dans cet exemple, une seule commande peut contenir plusieurs articles. La relation entre l'exploration order_items et la vue orders est donc many_to_one :

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
  }
}

Si vous n'incluez pas de paramètre relationship dans votre jointure, Looker utilise par défaut many_to_one.

Pour obtenir des conseils supplémentaires sur la définition correcte du paramètre relationship pour une jointure, consultez Définir correctement le paramètre relationship.

Étape n° 5 : sql_on

Déclarez comment joindre les tables order_items et orders à l'aide du paramètre sql_on ou du paramètre foreign_key.

Conseil Nous vous suggérons généralement d'utiliser le paramètre , car il peut effectuer toutes les actions du paramètre , mais il est généralement plus facile à comprendre.

sql_onsql_onforeign_key

Le paramètre sql_on est équivalent à la clause ON dans le code SQL généré pour une requête. Avec ce paramètre, vous pouvez désigner les champs à rapprocher pour effectuer la jointure :

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
    sql_on: ${order_items.order_id} = ${orders.id} ;;
  }
}

Vous pouvez également écrire des jointures plus complexes. Par exemple, vous pouvez joindre uniquement les commandes dont l'id est supérieur à 1 000 :

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
    sql_on: ${order_items.order_id} = ${orders.id} AND ${orders.id} > 1000 ;;
  }
}

Pour en savoir plus sur la syntaxe ${ ... } dans ces exemples, consultez la documentation sur les opérateurs de substitution.

Étape n° 6 : Test

Vérifiez si cette jointure fonctionne comme prévu en sélectionnant l'exploration Commander des articles. Vous devriez voir les champs de order_items et orders.

Pour en savoir plus sur les tests des modifications LookML dans une exploration, consultez Tester les champs dans l'exploration.

Jointure via une autre vue

Vous pouvez joindre une vue à une exploration par le biais d'une autre vue. Dans l'exemple de paramètres de jointure , vous avez joint orders à order_items à l'aide du champ order_id. Vous pouvez aussi joindre les données d'une vue appelée users à l'exploration order_items, même si elles n'ont aucun champ en commun. Pour ce faire, joignez-les via la vue orders.

Utilisez le paramètre sql_on ou le paramètre foreign_key pour joindre la vue users à la vue orders, au lieu de l'exploration order_items. Pour ce faire, délimitez correctement le champ de orders en tant que orders.user_id.

Voici un exemple utilisant le paramètre sql_on :

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
    sql_on: ${order_items.order_id} = ${orders.id} ;;
  }
  join: users {
    type: left_outer
    relationship: many_to_one
    sql_on: ${orders.user_id} = ${users.id} ;;
  }
}

Jointures multiples d'une vue

Une vue users contient des données pour les acheteurs et les vendeurs. Pour joindre les données de cette vue à order_items, mais séparément pour les acheteurs et les vendeurs, vous pouvez joindre users deux fois, avec des noms différents, à l'aide du paramètre from.

Le paramètre from permet de désigner la vue à utiliser dans une jointure, tout en donnant à la jointure un nom unique. Exemple :

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
    sql_on: ${order_items.order_id} = ${orders.id} ;;
  }
  join: buyers {
    from: users
    type: left_outer
    relationship: many_to_one
    sql_on: ${orders.buyer_id} = ${buyers.id} ;;
  }
  join: sellers {
    from: users
    type: left_outer
    relationship: many_to_one
    sql_on: ${orders.seller_id} = ${sellers.id} ;;
  }
}

Dans ce cas, seules les données des acheteurs sont jointes en tant que buyers, tandis que seules les données des vendeurs sont jointes en tant que sellers.

Remarque : La vue users doit désormais être référencée par ses noms d'alias buyers et sellers dans la jointure.

Limitation des champs d'une jointure

Le paramètre fields vous permet de spécifier les champs à insérer dans une exploration à partir d'une jointure. Par défaut, en cas de jointure, tous les champs d'une vue sont pris en compte. Il arrive toutefois qu'un sous-ensemble de champs soit suffisant.

Par exemple, lorsque orders est joint à order_items, vous pouvez n'insérer que les champs shipping et tax dans la jointure :

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
    sql_on: ${order_items.order_id} = ${orders.id} ;;
    fields: [shipping, tax]
  }
}

Vous pouvez également référencer un ensemble de champs, tel que [set_a*]. Chaque ensemble est défini dans une vue à l'aide du set paramètre. Supposons que l'ensemble suivant soit défini dans la vue orders :

set: orders_set {
  fields: [created_date, shipping, tax]
}

Vous pouvez choisir de n'insérer que ces trois champs lorsque vous joignez orders à order_items :

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
    sql_on: ${order_items.order_id} = ${orders.id} ;;
    fields: [orders_set*]
  }
}

Agrégations symétriques

Looker utilise une fonctionnalité appelée "agrégations symétriques" pour calculer correctement des agrégations (des sommes et des moyennes, par exemple), même lorsque les jointures se soldent par une sortance. Les agrégations symétriques sont décrites plus en détail dans Comprendre les agrégations symétriques. Le problème de sortance que les agrégations symétriques permettent de résoudre est expliqué dans l'article de la communauté Le problème des sortances SQL.

Clés primaires requises

Pour que les mesures (agrégations) soient conservées dans une jointure, vous devez définir des clés primaires dans toutes les vues impliquées dans la jointure.

Faites cela en ajoutant le primary_key paramètre dans la définition du champ de clé primaire de chaque vue :

dimension: id {
  type: number
  primary_key: yes
}

Remarque : Pour traiter correctement les mesures jointes, Looker compte su vous pour définir une clé primaire avec des valeurs non NULLES parfaitement uniques. Si vos données ne contiennent aucune clé primaire, vérifiez si la concaténation de plusieurs champs permettrait d'obtenir une clé primaire de valeurs non NULL parfaitement uniques. Si votre clé primaire n'est pas unique ou contient des valeurs NULL et si votre requête comprend des données révélant ce problème, Looker renvoie une erreur, comme décrit sur la page Bonnes pratiques : Erreur : Valeur non unique/clé primaire (ou sql_distinct_key), dépassement de capacité ou collision de valeurs lors du calcul de la somme.

Dialectes SQL pris en charge

Pour que Looker prenne en charge les agrégations symétriques dans votre projet, votre dialecte de base de données doit également les prendre en charge. Le tableau suivant répertorie les dialectes prenant en charge les agrégations symétriques 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 AlloyDB for PostgreSQL
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

Si votre dialecte ne reconnaît pas les agrégations symétriques, soyez attentif lors de l'exécution de jointures dans Looker, car certains types de jointures peuvent se solder par des agrégations (sommes, moyennes, etc.) inexactes. Ce problème et les solutions correspondantes sont décrits en détail dans l'article de la communauté Le problème des sortances SQL.

En savoir plus sur les jointures

Pour en savoir plus sur les paramètres de jointure de LookML, consultez la documentation de référence sur les jointures.