Utilisation de jointures dans LookML

Les jointures vous permettent d'associer différentes vues. Vous pouvez ainsi explorer les données de plusieurs vues en même temps et voir les relations entre 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 à une même 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-en une ou plusieurs sous 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 apparaît 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. Vous pouvez, par exemple, 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 illustré précédemment remplit deux fonctions. Tout d'abord, vous pouvez voir les champs de orders et de order_items dans le sélecteur de champs des explorations:

Le code LookML décrit ensuite comment joindre 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 à l'équipe Chat:Les utilisateurs posent le plus de questions sur l'erreur de validation "Champ inconnu ou inaccessible", qui peut être due à une jointure manquante. Pour en savoir plus, consultez la section Erreur: Champ inconnu ou inaccessible.

Paramètres de jointure

Quatre paramètres principaux permettent d'effectuer une jointure: 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 2: join

Pour joindre une table, vous devez d'abord la déclarer dans une vue. Dans cet exemple, supposons que orders est une vue existante de 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 3: type

Réfléchissez au type de jointure à effectuer. Looker est compatible avec LEFT JOIN, INNER JOIN, FULL OUTER JOIN et CROSS JOIN. Elles correspondent aux valeurs de paramètre type de 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 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 permettre à Looker de calculer des mesures précises. La relation est définie entre l'exploration order_items et la vue orders. Les options possibles sont one_to_one, many_to_one, one_to_many et many_to_many.

Dans cet exemple, une même commande peut contenir plusieurs articles. La relation entre l'exploration order_items et la vue orders est 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 est défini par défaut sur many_to_one.

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

Étape 5: sql_on

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

Conseil :Nous recommandons généralement d'utiliser le paramètre sql_on, car il peut faire tout ce que le paramètre foreign_key peut faire, mais le paramètre sql_on est généralement plus facile à comprendre.

Le paramètre sql_on est équivalent à la clause ON du code SQL généré pour une requête. Ce paramètre vous permet de déclarer les champs à mettre en correspondance 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 choisir de joindre uniquement les commandes dont la valeur id est supérieure à 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 ;;
  }
}

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

Étape n° 6 : Test

Vérifiez que cette jointure fonctionne comme prévu en accédant à l'exploration Order Items. Vous devriez voir les champs de order_items et de orders.

Reportez-vous à la section Modifier et valider du code LookML pour en savoir plus sur le test des modifications LookML dans une exploration.

Jointure via une autre vue

Vous pouvez joindre une vue à une exploration par le biais d'une autre vue. Dans l'exemple précédent, vous avez joint orders à order_items via le champ order_id. Nous pouvons également joindre les données d'une vue appelée users à l'exploration order_items, même si elles ne partagent pas de champ commun. Pour ce faire, vous pouvez joindre via la vue orders.

Utilisez le paramètre sql_on ou foreign_key pour joindre la vue users à la vue orders, plutôt qu'à l'exploration order_items. Pour ce faire, définissez correctement le champ d'application de orders sur 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 dans 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 vous permet de spécifier la vue à utiliser dans une jointure, tout en attribuant un nom unique à la jointure. 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 sur les acheteurs sont associées en tant que buyers, tandis que seules les données sur les vendeurs sont associées sous la forme sellers.

Remarque: La vue users doit désormais être désignée par ses alias buyers et sellers dans la jointure.

Limitation des champs d'une jointure

Le paramètre fields vous permet de spécifier les champs importés 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 souhaiterez peut-être récupérer uniquement les champs shipping et tax via 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 paramètre set. 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'afficher 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 les agrégations (comme les sommes et les moyennes), même lorsque les jointures entraînent une distribution ramifiée. Les agrégations symétriques sont décrites plus en détail dans Comprendre les agrégations symétriques. Le problème de distribution ramifiée que résout les agrégations symétriques est expliqué dans le post destiné à la communauté Le problème des fan-outs 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.

Pour ce faire, ajoutez le paramètre primary_key à la définition du champ de clé primaire dans chaque vue:

dimension: id {
  type: number
  primary_key: yes
}

Remarque :Pour gérer correctement les mesures jointes, Looker nécessite de spécifier une clé primaire dans laquelle les valeurs sont entièrement uniques et non nulles. Si vos données ne contiennent pas de clé primaire, demandez-vous si la concaténation de plusieurs champs donnerait une clé primaire avec des valeurs non nulles complètement uniques. Si votre clé primaire n'est pas unique ou contient des valeurs NULL et que votre requête inclut des données qui révèlent ces problèmes, Looker renvoie une erreur comme décrit sur la page des bonnes pratiques Erreur: valeur non unique/clé primaire (ou sql_distinct_key), dépassement de valeur ou collision 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 présente les dialectes prenant en charge les agrégations symétriques dans la dernière version de Looker:

Dialecte	Compatible ?
Actian Avalanche	Oui
Amazon Athena	Oui
Amazon Aurora MySQL	Oui
Amazon Redshift	Oui
Apache Druid	Non
Apache Druid 0.13 et versions ultérieures	Non
Apache Druid 0.18 et versions ultérieures	Non
Apache Hive 2.3 et versions ultérieures	Non
Apache Hive 3.1.2+	Non
Apache Spark 3 ou version ultérieure	Oui
ClickHouse	Non
Cloudera Impala 3.1 ou version ultérieure	Oui
Cloudera Impala 3.1 ou version ultérieure avec pilote natif	Oui
Cloudera Impala avec pilote natif	Non
DataVirtuality	Oui
Databricks	Oui
Denodo 7	Oui
Denodo 8	Oui
Dremio	Non
Dremio 11 et versions ultérieures	Oui
Exasol	Oui
Boulon	Oui
Ancien SQL de Google BigQuery	Oui
SQL standard Google BigQuery	Oui
Google Cloud PostgreSQL	Oui
Google Cloud SQL	Oui
Google Spanner	Oui
Prune	Oui
HyperSQL	Non
IBM Netezza	Oui
MariaDB	Oui
Microsoft Azure PostgreSQL	Oui
Base de données Microsoft Azure SQL	Oui
Microsoft Azure Synapse Analytics	Oui
Microsoft SQL Server 2008 ou version ultérieure	Oui
Microsoft SQL Server 2012 ou version ultérieure	Oui
Microsoft SQL Server 2016	Oui
Microsoft SQL Server 2017 ou version ultérieure	Oui
MongoBI	Non
MySQL	Oui
MySQL 8.0.12 et versions ultérieures	Oui
Oracle	Oui
Oracle ADWC	Oui
PostgreSQL 9.5 ou version ultérieure	Oui
PostgreSQL antérieur à la version 9.5	Oui
PrestoDB	Oui
PrestoSQL	Oui
SAP HANA 2+	Oui
SingleStore	Oui
SingleStore 7+	Oui
Snowflake	Oui
Teradata	Oui
Trino	Oui
Vecteur	Oui
Vertica	Oui

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 ses solutions sont décrits en détail dans le post destiné à la communauté intitulé Le problème des fan-outs SQL.

En savoir plus sur les jointures

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