Utilisation
explore: explore_name {
join: view_name { ... }
}
|
Hiérarchie
join |
Valeur par défaut
Aucun
Acceptation
Nom d'une vue existante
Règles spéciales
|
Définition
join vous permet de définir la relation de jointure entre une exploration et une vue, afin de pouvoir combiner les données de plusieurs vues. Vous pouvez joindre autant de vues que vous le souhaitez pour une exploration donnée.
Rappelez-vous que chaque vue est associée à une table de votre base de données ou à une table dérivée que vous avez définie dans Looker. De même, puisqu'une exploration est associée à une vue, elle est également connectée à une table d'un certain type.
La table associée à l'exploration est placée dans la clause FROM du code SQL généré par Looker. Les tables associées aux vues jointes sont placées dans la clause JOIN du code SQL généré par Looker.
Principaux paramètres de jointure
Pour définir la relation de jointure (clause SQL ON) entre une exploration et une vue, vous devez utiliser join en combinaison avec d'autres paramètres.
Vous devez utiliser soit le paramètre sql_on soit le paramètre foreign_key pour établir la clause SQL ON.
Vous devrez également vous assurer d'utiliser les types de jointure et les relations appropriés, bien que les paramètres type et relationship ne soient pas toujours explicitement requis. Si leurs valeurs par défaut (type: left_outer et relationship: many_to_one) conviennent à votre cas d'utilisation, vous pouvez exclure ces paramètres.
Ces paramètres clés et leur relation avec le code SQL généré par Looker peuvent être résumés comme suit :
- Le paramètre
exploredétermine la table dans la clauseFROMde la requête SQL générée. - Chaque paramètre
joindétermine une clauseJOINde la requête SQL générée.- Le paramètre
typedétermine le type de jointure SQL. - Les paramètres
sql_onetforeign_keydéterminent la clauseONde la requête SQL générée.
- Le paramètre
sql_on
sql_on vous permet d'établir une relation de jointure en écrivant directement la clause SQL ON. Il peut effectuer les mêmes jointures que foreign_key, mais il est plus facile à lire et à comprendre.
Pour en savoir plus, consultez la page de documentation sur le paramètre sql_on.
foreign_key
foreign_key vous permet d'établir une relation de jointure à l'aide de la clé primaire de la vue jointe et de la connecter à une dimension dans l'exploration. Ce modèle est très courant dans la conception de bases de données, et foreign_key est une façon élégante d'exprimer la jointure dans ces cas.
Pour en savoir plus, consultez la page de documentation sur le paramètre foreign_key.
type
La plupart des jointures dans Looker sont LEFT JOIN pour les raisons évoquées dans la section Ne pas appliquer de logique métier dans les jointures si possible de cette page. Par conséquent, si vous n'ajoutez pas explicitement de type, Looker supposera que vous souhaitez un LEFT JOIN. Toutefois, si vous avez besoin d'un autre type de jointure pour une raison quelconque, vous pouvez le faire avec type.
Pour obtenir une explication complète, consultez la page de documentation sur le paramètre type.
relationship
relationship n'a pas d'impact direct sur le code SQL généré par Looker, mais il est essentiel au bon fonctionnement de Looker. Si vous n'ajoutez pas explicitement de relationship, Looker interprétera la relation comme many-to-one, ce qui signifie que plusieurs lignes de l'exploration peuvent correspondre à une ligne de la vue jointe. Toutes les jointures n'ont pas ce type de relation. Les jointures avec d'autres relations doivent être déclarées correctement.
Pour en savoir plus, consultez la page de documentation sur le paramètre relationship.
Exemples
Joignez la vue nommée customer à l'exploration nommée order où la relation de jointure est
FROM order LEFT JOIN customer ON order.customer_id = customer.id :
explore: order {
join: customer {
foreign_key: customer_id
relationship: many_to_one # Could be excluded since many_to_one is the default
type: left_outer # Could be excluded since left_outer is the default
}
}
Joignez la vue nommée address à l'exploration nommée person où la relation de jointure est
FROM person LEFT JOIN address ON person.id = address.person_id
AND address.type = 'permanent' :
explore: person {
join: address {
sql_on: ${person.id} = ${address.person_id} AND ${address.type} = 'permanent' ;;
relationship: one_to_many
type: left_outer # Could be excluded since left_outer is the default
}
}
Joignez la vue nommée member à l'exploration nommée event où la relation de jointure est
FROM event INNER JOIN member ON member.id = event.member_id :
explore: event {
join: member {
sql_on: ${event.member_id} = ${member.id} ;;
relationship: many_to_one # Could be excluded since many_to_one is the default
type: inner
}
}
Difficultés courantes
join doit utiliser des noms de vues et non des noms de tables sous-jacentes.
Le paramètre join n'accepte qu'un nom de vue, et non le nom de la table associée à cette vue. Souvent, le nom de la vue et le nom de la table sont identiques, ce qui peut conduire à la conclusion erronée que les noms de table peuvent être utilisés.
Certains types de mesures nécessitent des agrégations symétriques
Si vous n'utilisez pas d'agrégats symétriques, la plupart des types de mesures sont exclus des vues jointes. 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 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 |
Sans agrégats symétriques, les relations de jointure qui ne sont pas de type un-à-un peuvent générer des résultats inexacts dans les fonctions d'agrégation. Étant donné que les mesures Looker sont des fonctions d'agrégation, seules les mesures de type: count (en tant que COUNT DISTINCT) sont importées des vues jointes dans l'onglet "Explorer". Si vous avez une relation de jointure un-à-un, vous pouvez utiliser le paramètre relationship pour forcer l'inclusion des autres types de mesures, comme ceci :
explore: person {
join: dna {
sql_on: ${person.dna_id} = ${dna.id} ;;
relationship: one_to_one
}
}
Les raisons pour lesquelles Looker fonctionne de cette manière (pour les dialectes qui ne prennent pas en charge les agrégations symétriques) sont abordées plus en détail dans l'article de la communauté Le problème des fan-out SQL.
Bon à savoir
Vous pouvez joindre la même table plusieurs fois à l'aide de from.
Dans les cas où une même table contient différents types d'entités, il est possible de joindre une vue à une exploration plusieurs fois. Pour ce faire, vous devez utiliser le paramètre from. Supposons que vous ayez une exploration order et que vous deviez y joindre une vue person deux fois : une fois pour le client et une fois pour le représentant du service client. L'instruction pourrait se présenter comme suit :
explore: order {
join: customer {
from: person
sql_on: ${order.customer_id} = ${customer.id} ;;
}
join: representative {
from: person
sql_on: ${order.representative_id} = ${representative.id} ;;
}
}
Évitez d'appliquer une logique métier dans les jointures si possible
L'approche standard de Looker pour les jointures consiste à utiliser un LEFT JOIN dans la mesure du possible. Envisagez une autre approche si vous vous trouvez dans l'une des situations suivantes :
explore: member_event {
from: event
always_join: [member]
join: member {
sql_on: ${member_event.member_id} = ${member.id} ;;
type: inner
}
}
Dans cet exemple, nous avons créé une exploration qui n'examine que les événements associés aux membres connus. Toutefois, la méthode recommandée pour exécuter cette opération dans Looker consiste à utiliser un LEFT JOIN pour associer les données d'événement et les données de membre, comme ceci :
explore: event {
join: member {
sql_on: ${event.member_id} = ${member.id} ;;
}
}
Vous pouvez ensuite créer une dimension que vous pouvez définir sur yes ou no si vous ne souhaitez examiner que les événements des membres, comme ceci :
dimension: is_member_event {
type: yesno
sql: ${member.id} IS NOT NULL ;;
}
Cette approche est préférable, car elle permet aux utilisateurs de consulter tous les événements ou uniquement les événements des membres, selon leurs besoins. Vous ne les avez pas forcés à ne regarder que les événements des membres via la jointure.
Si vous n'utilisez pas d'agrégats symétriques, évitez les jointures qui provoquent des expansions
Cette section ne s'applique qu'aux dialectes de base de données qui n'acceptent pas les agrégats symétriques. Consultez la section Défis courants de cette page pour déterminer si votre dialecte est compatible avec les agrégations symétriques.
Si votre dialecte de base de données ne prend pas en charge les agrégations symétriques, vous devez éviter les jointures qui entraînent un fan-out. En d'autres termes, il est généralement préférable d'éviter les jointures qui présentent une relation de type un à plusieurs entre l'exploration et la vue. Au lieu de cela, agrégez les données de la vue dans une table dérivée afin d'établir une relation un-à-un avec l'exploration, puis joignez cette table dérivée à l'exploration.
Ce concept important est expliqué plus en détail dans le post de la communauté Le problème des fan-out SQL.