Les jointures vous permettent de connecter différentes vues. Vous pouvez ainsi explorer les données de plusieurs vues à la fois et observer 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. Les jointures relient une ou plusieurs vues à 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 une ou plusieurs d'entre elles sous le paramètre explore
dans le 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
. 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 remplit deux fonctions. Tout d'abord, vous pouvez voir les champs de orders
et order_items
dans le sélecteur de champs:
Ensuite, le code LookML décrit 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.
Paramètres de jointure
Quatre paramètres principaux sont utilisés pour 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 déclarer la table 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 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 des paramètres 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 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 comporter 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 Bien définir le paramètre relationship
.
Étape 5: sql_on
Déclarez comment joindre les tables order_items
et orders
avec le paramètre sql_on
ou foreign_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é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 souhaiter 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 ;;
}
}
Pour en savoir plus sur la syntaxe ${ ... }
de ces exemples, consultez la documentation sur les opérateurs de substitution.
Étape n° 6 : Test
Vérifiez que cette jointure fonctionne comme prévu en accédant à l'exploration Order Items. Les champs order_items
et orders
doivent s'afficher.
Pour en savoir plus sur le test des modifications LookML dans une exploration, consultez la section Modification et validation de LookML.
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
via le champ order_id
. Nous pouvons également envisager de 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, effectuez une jointure via la vue orders
.
Utilisez le paramètre sql_on
ou foreign_key
pour joindre la vue users
à la vue orders
, au lieu de l'exploration order_items
. Pour ce faire, définissez correctement la portée du champ à partir 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 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 des acheteurs sont associées 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 désignée par ses alias buyers
et sellers
dans la jointure.
Limitation des champs d'une jointure
Le paramètre fields
permet de spécifier les champs à importer 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'importer que les champs shipping
et tax
:
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, comme [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'inclure 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 sur la page Comprendre les agrégations symétriques. Le problème de distribution ramifié que les agrégats symmetrides résolvent est expliqué dans le post de la communauté 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 dans 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 indique les dialectes prenant en charge les agrégations symétriques dans la dernière version de Looker:
Dialecte | Compatibilité |
---|---|
Avalanche d'Actian | 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 et versions ultérieures | Non |
Apache Spark 3 et versions ultérieures | Oui |
ClickHouse | Non |
Cloudera Impala 3.1+ | Oui |
Cloudera Impala 3.1+ avec pilote natif | Oui |
Cloudera Impala avec Native Driver | Non |
DataVirtuality | Oui |
Databricks | Oui |
Denodo 7 | Oui |
Denodo 8 | Oui |
Dremio | Non |
Dremio 11 et versions ultérieures | Oui |
Exasol | Oui |
Feu | Oui |
Ancien SQL de Google BigQuery | Oui |
SQL standard 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 |
Base de données Microsoft Azure SQL | Oui |
Microsoft Azure Synapse Analytics | Oui |
Microsoft SQL Server 2008 et versions ultérieures | Oui |
Microsoft SQL Server 2012 et versions ultérieures | Oui |
Microsoft SQL Server 2016 | Oui |
Microsoft SQL Server 2017 et versions ultérieures | Oui |
MongoBI | Non |
MySQL | Oui |
MySQL 8.0.12 et versions ultérieures | Oui |
Oracle | Oui |
Oracle ADWC | Oui |
PostgreSQL 9.5 et versions ultérieures | Oui |
PostgreSQL version antérieure à 9.5 | Oui |
PrestoDB | Oui |
PrestoSQL | Oui |
SAP HANA 2 et versions ultérieures | Oui |
SingleStore | Oui |
SingleStore 7 et versions ultérieures | 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 de la communauté Le problème des fanouts SQL.
En savoir plus sur les jointures
Pour en savoir plus sur les paramètres de jointure dans LookML, consultez la documentation de référence sur les jointures.