Les jointures vous permettent de lier différentes vues afin d'explorer les données de plusieurs vues en même temps et de voir comment les différentes parties de vos données sont liées les unes aux autres.
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 apparaît dans la clause FROM de l'instruction SQL générée:
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 a deux fonctions. Premièrement, vous pouvez voir les champs de orders et order_items dans le sélecteur de champs d'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.
Paramètres de jointure
Quatre principaux paramètres sont utilisés pour la 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 soit une vue existante de votre modèle.
Utilisez ensuite 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
Déterminez le 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 que Looker puisse calculer des mesures précises. La relation est définie à partir de l'exploration order_items jusqu'à la vue orders. Les options possibles sont one_to_one, many_to_one, one_to_many et many_to_many.
Dans cet exemple, une commande peut comporter de nombreux 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 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 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.
sql_on
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 ne joindre que les commandes dont 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 Articles de commande. Vous devriez voir les champs de order_items et de orders.
Pour en savoir plus sur les tests des modifications LookML dans une exploration, consultez Tester les champs de 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 associé orders à order_items via le 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-vous à 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éfinissez correctement le champ 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 à la fois 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 de l'acheteur sont jointes en tant que buyers, tandis que seules les données du vendeur 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 ne récupérer que 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 faire référence à un ensemble de champs, comme [set_a*]. Chaque ensemble est défini au sein d'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 ne retenir que ces trois champs lors de la jointure de 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. Pour en savoir plus sur les agrégations symétriques, consultez Comprendre les agrégations symétriques. Le problème de fanout résolu par les agrégations symétriques est expliqué dans le post de la communauté The problem of SQL fanouts (Le problème des fanouts 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 de chaque vue:
dimension: id {
type: number
primary_key: yes
}
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 compatibles avec les agrégations symétriques dans la dernière version de Looker:
| Dialecte | Compatibilité |
|---|---|
| Actian Avalanche | Oui |
| Amazon Athena | Oui |
| Amazon Aurora MySQL | Oui |
| Amazon Redshift | Oui |
| Apache Druid | Non |
| Apache Druid 0.13 ou version ultérieure | Non |
| Apache Druid 0.18 ou version ultérieure | Non |
| Apache Hive 2.3 ou version ultérieure | Non |
| Apache Hive 3.1.2 ou version ultérieure | 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 ou version ultérieure | Oui |
| Exasol | Oui |
| Flèche de feu | Oui |
| Google BigQuery Legacy SQL | Oui |
| SQL standard de Google BigQuery | Oui |
| Google Cloud PostgreSQL | Oui |
| Google Cloud SQL | Oui |
| Google Spanner | Oui |
| Greenplum | Oui |
| HyperSQL | Non |
| IBM Netezza | Oui |
| MariaDB | Oui |
| Microsoft Azure PostgreSQL | Oui |
| Microsoft Azure SQL Database | 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 ou version ultérieure | Oui |
| Oracle | Oui |
| Oracle ADWC | Oui |
| PostgreSQL 9.5 ou version ultérieure | Oui |
| PostgreSQL version antérieure à 9.5 | Oui |
| PrestoDB | Oui |
| PrestoSQL | Oui |
| SAP HANA 2 ou version ultérieure | 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 les solutions de contournement sont décrits en détail dans le post de la communauté The problem of SQL fanouts (Le problème des fanouts SQL).
En savoir plus sur les jointures
Pour en savoir plus sur les paramètres de jointure de LookML, consultez la documentation Join reference (Référence sur les jointures).