Utilizzo
explore: explore_name {
join: view_name { ... }
}
|
Gerarchia
join |
Valore predefinito
Nessuno
Accetta
Il nome di una vista esistente
Regole speciali
|
Definizione
join consente di definire la relazione di join tra un'esplorazione e una vista, in modo da poter combinare i dati di più viste. Puoi unire tutte le viste che vuoi per una determinata esplorazione.
Ricorda che ogni vista è associata a una tabella nel tuo database o a una tabella derivata che hai definito in Looker. Analogamente, poiché un'esplorazione è associata a una vista, è anche collegata a una tabella di qualche tipo.
La tabella associata all'esplorazione viene inserita nella clausola FROM dell'SQL generato da Looker. Le tabelle associate alle viste unite vengono inserite nella clausola JOIN dell'SQL generato da Looker.
Parametri di join principali
Per definire la relazione di join (la clausola SQL ON) tra un'esplorazione e una vista, devi utilizzare join in combinazione con altri parametri.
È necessario utilizzare il parametro sql_on o il parametro foreign_key per stabilire la clausola SQL ON.
Dovrai anche assicurarti di utilizzare i tipi di join e le relazioni appropriati, anche se i parametri type e relationship non sono sempre richiesti esplicitamente. Se i valori predefiniti type: left_outer e relationship: many_to_one sono appropriati per il tuo caso d'uso, questi parametri possono essere esclusi.
Questi parametri chiave e la loro relazione con l'SQL generato da Looker possono essere riassunti come segue:
- Il parametro
exploredetermina la tabella nella clausolaFROMdella query SQL generata. - Ogni parametro
joindetermina una clausolaJOINdella query SQL generata.- Il parametro
typedetermina il tipo di join SQL. - I parametri
sql_oneforeign_keydeterminano la clausolaONdella query SQL generata.
- Il parametro
sql_on
sql_on consente di stabilire una relazione di join scrivendo direttamente la clausola SQL ON. Può eseguire gli stessi join di foreign_key, ma è più facile da leggere e comprendere.
Per saperne di più, consulta la pagina della documentazione del parametro sql_on.
foreign_key
foreign_key consente di stabilire una relazione di join utilizzando la chiave primaria della vista unita e collegandola a una dimensione nell'esplorazione. Questo pattern è molto comune nella progettazione di database e foreign_key è un modo elegante per esprimere il join in questi casi.
Per una comprensione completa, consulta la pagina della documentazione del parametro foreign_key.
type
La maggior parte dei join in Looker è di tipo LEFT JOIN per i motivi discussi nella sezione Se possibile, non applicare la logica di business nei join di questa pagina. Pertanto, se non aggiungi esplicitamente un type, Looker presuppone che tu voglia un LEFT JOIN. Tuttavia, se per qualche motivo hai bisogno di un altro tipo di join, puoi utilizzare type.
Per una spiegazione completa, consulta la pagina della documentazione del parametro type.
relationship
relationship non ha un impatto diretto sull'SQL generato da Looker, ma è fondamentale per il corretto funzionamento di Looker. Se non aggiungi esplicitamente un relationship, Looker interpreterà la relazione come many-to-one, il che significa che molte righe nell'esplorazione possono avere una riga nella vista unita. Non tutti i join hanno questo tipo di relazione e i join con altre relazioni devono essere dichiarati correttamente.
Per una comprensione completa, consulta la pagina della documentazione del parametro relationship.
Esempi
Unisci la vista denominata customer all'esplorazione denominata order in cui la relazione di join è
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
}
}
Unisci la vista denominata address all'esplorazione denominata person in cui la relazione di join è
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
}
}
Unisci la vista denominata member all'esplorazione denominata event in cui la relazione di join è
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
}
}
Sfide comuni
join deve utilizzare i nomi delle viste e non i nomi delle tabelle sottostanti
Il parametro join accetta solo un nome di visualizzazione, non il nome della tabella associata a quella visualizzazione. Spesso il nome della vista e quello della tabella sono identici, il che potrebbe portare alla conclusione errata che è possibile utilizzare i nomi delle tabelle.
Alcuni tipi di misure richiedono aggregati simmetrici
Se non utilizzi gli aggregati simmetrici, la maggior parte dei tipi di misure viene esclusa dalle viste unite. Affinché Looker supporti gli aggregati simmetrici nel tuo progetto Looker, anche il dialetto del database deve supportarli. La tabella seguente mostra quali dialetti supportano gli aggregati simmetrici nell'ultima release di Looker:
| Dialetto | Supportata? |
|---|---|
| Actian Avalanche | |
| Amazon Athena | |
| Amazon Aurora MySQL | |
| Amazon Redshift | |
| Amazon Redshift 2.1+ | |
| Amazon Redshift Serverless 2.1+ | |
| Apache Druid | |
| Apache Druid 0.13.x - 0.17.x | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| ClickHouse 26+ | |
| 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+ | |
| Dremio 26+ with Arrow Flight SQL | |
| 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 | |
| MongoSQL | |
| 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 |
Senza aggregati simmetrici, le relazioni di join che non sono uno a uno possono generare risultati imprecisi nelle funzioni di aggregazione. Poiché le misure di Looker sono funzioni di aggregazione, solo le misure di type: count (come COUNT DISTINCT) vengono trasferite dalle visualizzazioni unite all'esplorazione. Se hai una relazione di join uno a uno, puoi utilizzare il parametro relationship per forzare l'inclusione degli altri tipi di misura, in questo modo:
explore: person {
join: dna {
sql_on: ${person.dna_id} = ${dna.id} ;;
relationship: one_to_one
}
}
I motivi per cui Looker funziona in questo modo (per i dialetti che non supportano gli aggregati simmetrici) sono discussi in maggiore dettaglio nel post per la community Il problema dei fanout SQL.
Cose da sapere
Puoi unire la stessa tabella più di una volta utilizzando from
Nei casi in cui una singola tabella contiene diversi tipi di entità, è possibile unire una vista a un'esplorazione più di una volta. Per farlo, dovrai utilizzare il parametro from. Supponiamo che tu abbia un'esplorazione order e debba unire una vista person due volte: una per il cliente e una per il rappresentante dell'assistenza clienti. Potresti fare qualcosa del genere:
explore: order {
join: customer {
from: person
sql_on: ${order.customer_id} = ${customer.id} ;;
}
join: representative {
from: person
sql_on: ${order.representative_id} = ${representative.id} ;;
}
}
Se possibile, non applicare la logica di business nei join
L'approccio standard di Looker per i join consiste nell'utilizzare un LEFT JOIN ogni volta che è possibile. Valuta un approccio diverso se ti ritrovi a fare qualcosa di simile:
explore: member_event {
from: event
always_join: [member]
join: member {
sql_on: ${member_event.member_id} = ${member.id} ;;
type: inner
}
}
In questo esempio abbiamo creato un'esplorazione che esamina solo gli eventi associati ai membri noti. Tuttavia, il modo migliore per eseguire questa operazione in Looker è utilizzare un LEFT JOIN per unire i dati sugli eventi e i dati sui membri, in questo modo:
explore: event {
join: member {
sql_on: ${event.member_id} = ${member.id} ;;
}
}
Poi, creeresti una dimensione che potresti impostare su yes o no, se volessi esaminare solo gli eventi degli abbonati, in questo modo:
dimension: is_member_event {
type: yesno
sql: ${member.id} IS NOT NULL ;;
}
Questo approccio è preferibile perché offre agli utenti la flessibilità di visualizzare tutti gli eventi o solo quelli dei membri, a seconda delle loro preferenze. Non hai imposto di esaminare solo gli eventi dei membri tramite il join.
Se non utilizzi gli aggregati simmetrici, evita i join che causano fanout
Questa sezione si applica solo ai dialetti di database che non supportano gli aggregati simmetrici. Consulta la discussione sugli aggregati simmetrici nella sezione Problemi comuni di questa pagina per determinare se il tuo dialetto supporta gli aggregati simmetrici.
Se il dialetto del tuo database non supporta gli aggregati simmetrici, devi evitare i join che generano un fanout. In altre parole, in genere è consigliabile evitare i join che hanno una relazione one-to-many tra l'esplorazione e la vista. Invece, aggrega i dati della vista in una tabella derivata per stabilire una relazione uno a uno con l'esplorazione, quindi unisci la tabella derivata all'esplorazione.
Questo importante concetto è spiegato in dettaglio nel post per la community The problem of SQL fanouts.