Utilizzo
join: view_name { ... }
}
Gerarchia
join |
Valore predefinito
NessunaAccetta
Il nome di una vista esistenteRegole speciali
|
Definizione
join
ti consente di definire la relazione di unione tra un'esplorazione e una vista, in modo da poter combinare i dati di più viste. Puoi partecipare a tutte le visualizzazioni che vuoi per un'esplorazione specifica.
Ricorda che ogni vista è associata a una tabella nel tuo database o a una tabella derivata che hai definito in Looker. Analogamente, poiché una funzionalità Esplora è 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 unione principali
Per definire la relazione di join (la clausola SQL ON
) tra un Explore e una vista, devi usare join
in combinazione con altri parametri.
Devi utilizzare il sql_on
o il parametro foreign_key
per stabilire la clausola SQL di ON
.
Devi inoltre assicurarti di utilizzare le relazioni e i tipi di unione appropriati, anche se i parametri type
e relationship
non sono sempre obbligatori. Se i valori predefiniti di type: left_outer
e relationship: many_to_one
sono adatti al tuo caso d'uso, puoi escludere questi parametri.
Questi parametri chiave e la loro relazione con il linguaggio SQL generato da Looker sono visualizzati qui:
sql_on
sql_on
consente di stabilire una relazione di join scrivendo direttamente la clausola ON
di SQL. Può effettuare le stesse unioni che foreign_key
può fare, ma è più facile da leggere e da capire.
Per ulteriori informazioni, consulta la pagina della documentazione del parametro sql_on
.
foreign_key
foreign_key
ti consente di definire una relazione di unione utilizzando la chiave principale della vista unita e di collegarla a una dimensione in Esplora. Questo pattern è molto comune nella progettazione di database e in questi casi foreign_key
è un modo elegante per esprimere l'unione.
Per una comprensione completa, consulta la pagina della documentazione relativa al parametro foreign_key
.
type
La maggior parte dei join in Looker sono LEFT JOIN
per i motivi illustrati nella sezione Non applicare logica di business, se possibile in questa pagina. Pertanto, se non aggiungi esplicitamente una type
, Looker presumerà che tu voglia una LEFT JOIN
. Tuttavia, se per qualche motivo hai bisogno di un altro tipo di unione, puoi farlo con type
.
Per una spiegazione completa, consulta la pagina della documentazione del parametro type
.
relationship
Nel diagramma qui sopra, relationship
non ha un impatto immediato sull'SQL generato da Looker, ma è fondamentale per il corretto funzionamento di Looker. Se non aggiungi esplicitamente una relationship
Looker presuppone che si tratti di many-to-one
, vale a dire che molte righe di Explore possono avere una riga nella vista unita. Non tutti i join hanno questo tipo di relazione e i join con altri rapporti devono essere dichiarati correttamente.
Per una comprensione completa, consulta la pagina della documentazione relativa al parametro relationship
.
Esempi
Partecipa alla vista denominata customer
per esplorare il nome order
, dove si trova 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
}
}
-
Partecipa alla vista denominata address
per esplorare il nome person
, dove si trova 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
}
}
-
Partecipa alla vista denominata member
per esplorare il nome event
, dove si trova 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
utilizza solo un nome vista, non il nome tabella associato. Spesso il nome e il nome della tabella sono identici, il che può portare alla falsa conclusione che possono essere utilizzati.
Alcuni tipi di misure richiedono aggregati simmetrici
Se non utilizzi aggregati simmetrici, la maggior parte dei tipi di misurazione viene esclusa dalle visualizzazioni unite. Affinché Looker supporti gli aggregati simmetrici nel tuo progetto Looker, anche il dialetto del tuo database deve supportarli. La tabella seguente mostra quali dialetti supportano gli aggregati simmetrici nell'ultima release di Looker:
Senza le aggregazioni simmetriche, unisci relazioni che non sono one-to-one può generare risultati imprecisi nelle funzioni aggregate. Poiché le misure di Looker sono funzioni aggregate, solo le misure di type: count
(come COUNT DISTINCT
) vengono importate dall'unione delle visualizzazioni in Esplora. Se hai una relazione di join one-to-one, 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 funziona in questo modo (per i dialetti che non supportano gli aggregati simmetrici) sono descritti in dettaglio nell'articolo del Centro assistenza Il problema dei fanout SQL.
Aspetti da tenere presenti
Puoi unire la stessa tabella più di una volta utilizzando from
Se una singola tabella contiene tipi di entità diversi, è possibile unire una visualizzazione a un'esplorazione più di una volta. A questo scopo, dovrai utilizzare il parametro from
. Supponiamo che tu avessi una order
Esplora e avessi bisogno di unirci a una visualizzazione person
due volte: una per il cliente e una per il rappresentante dell'assistenza clienti. Ecco cosa puoi fare:
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 nelle join
Quando possibile, l'approccio standard di Looker è di utilizzare LEFT JOIN
. Prendi in considerazione un approccio diverso se ti trovi a fare qualcosa in questo senso:
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 mostra solo gli eventi associati ai membri noti. Tuttavia, il modo migliore per farlo in Looker è utilizzare un LEFT JOIN
per ottenere dati relativi a eventi e membri bloccati insieme, in questo modo:
explore: event {
join: member {
sql_on: ${event.member_id} = ${member.id} ;;
}
}
-
Poi devi creare una dimensione che puoi impostare a yes
o no
, se vuoi esaminare solo gli eventi dei membri, 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 guardare tutti gli eventi o solo gli eventi per i membri che preferiscono. Non li hai obbligati a guardare solo gli eventi riservati agli abbonati tramite l'abbonamento.
Se non usi aggregati simmetrici, evita join che causano fanout
Questa sezione si applica solo ai dialetti del database che non supportano gli aggregati simmetrici. Consulta la discussione degli aggregati simmetrici nella sezione Sfide comuni di questa pagina per determinare se il tuo dialetto supporta gli aggregati simmetrici.
Se il dialetto del database non supporta gli aggregati simmetrici, dovresti evitare join che comportano un fanout. In altre parole, evita generalmente gli join che hanno una relazione one-to-many tra Esplora e Visualizzazione. Aggrega invece i dati della vista in una tabella derivata per stabilire una relazione one-to-one con Explore e poi unisci la tabella derivata in Explore.
Questo importante concetto è spiegato più dettagliatamente nell'articolo del Centro assistenza Il problema dei fan-out SQL.