I join ti consentono di collegare diverse viste in modo da poter esplorare i dati da più di una vista contemporaneamente e vedere come parti diverse dei tuoi dati sono correlate tra loro.
Ad esempio, il tuo database potrebbe includere le tabelle order_items
, orders
e users
. Puoi utilizzare i join per esplorare i dati di tutte le tabelle contemporaneamente. Questa pagina spiega i join in LookML, inclusi i parametri di join specifici e i pattern di join.
I join iniziano con un'esplorazione
I join sono definiti nel file modello per stabilire la relazione tra un'esplorazione e una vista. I join collegano una o più viste a una singola esplorazione, direttamente o tramite un'altra visualizzazione combinata.
Prendiamo in considerazione due tabelle di database: order_items
e orders
. Dopo aver generato viste per entrambe le tabelle, dichiarane una o più con il parametro explore
nel file modello:
explore: order_items { ... }
Quando esegui una query da order_items
Esplora, order_items
viene visualizzato nella clausola FROM
dell'SQL generato:
SELECT ...
FROM order_items
Puoi partecipare a informazioni aggiuntive nella nostra esplorazione di order_items
. Ad esempio, per aggiungere dati relativi a orders
di cui fa parte order_item
, puoi eseguire questa operazione:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
sql_on: ${order_items.order_id} = ${orders.id} ;;
}
}
Il LookML precedente realizza due operazioni. Innanzitutto, puoi visualizzare i campi sia di orders
che di order_items
nell'interfaccia utente:
In secondo luogo, il codice LookML descrive come unire orders
e order_items
. Tale LookML si tradurrebbe nel seguente SQL:
SELECT ...
FROM order_items
LEFT JOIN orders
ON order_items.order_id = orders.id
Questi parametri LookML sono descritti in modo più dettagliato nelle sezioni seguenti. Consulta la pagina di riferimento del parametro join
per scoprire di più su come questo codice LookML viene convertito in SQL.
Suggerimento per il team di Chat: gli utenti chiedono di più sull'errore di convalida, "Campo sconosciuto o inaccessibile", che può essere causato da un join mancante. Per ulteriori informazioni, consulta la pagina sulle best practice per questo errore.
Parametri di join
Per l'unione vengono utilizzati quattro parametri principali: join
, type
, relationship
e sql_on
.
Passaggio 1: avvia l'esplorazione
Innanzitutto, crea l'esplorazione di order_items
:
explore: order_items { ... }
Passaggio 2: join
Per unire una tabella, devi prima dichiararla in una vista. In questo esempio, orders
è una visualizzazione esistente nel nostro modello.
Quindi, utilizza il parametro join
per dichiarare che vuoi unire la vista orders
a order_items
:
explore: order_items {
join: orders { ... }
}
Passaggio 3: type
Valuta quale type
di join eseguire. Looker supporta LEFT JOIN
, INNER JOIN
, FULL OUTER JOIN
e CROSS JOIN
. Corrispondeno ai valori parametro type
di left_outer
, inner
, full_outer
e cross
.
explore: order_items {
join: orders {
type: left_outer
}
}
Il valore predefinito di type
è left_outer
e in genere è il tipo di unione più utilizzato.
Passaggio 4: relationship
Definisci un join relationship
tra order_items
e orders
. Per calcolare in modo accurato le misurazioni, è importante dichiarare correttamente l'elemento relationship
di un join. La relazione viene definita dalla visualizzazione order_items
Esplora alla visualizzazione orders
. Le opzioni possibili sono one_to_one
, many_to_one
, one_to_many
e many_to_many
.
In questo esempio possono esserci molti order_items
per un singolo order
. La relazione da order_items
a orders
è many_to_one
:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
}
}
Se non includi relationship
nell'unione, Looker utilizza come valore predefinito many_to_one
.
Per ulteriori suggerimenti sulla definizione corretta del parametro relationship
per un join, consulta la pagina Best practice per il parametro relationship
.
Passaggio 5: sql_on
Dichiara come unire queste due tabelle utilizzando il parametro sql_on
o foreign_key
. In genere consigliamo sql_on
poiché può fare tutto ciò che foreign_key
può fare, ma in genere è più facile da capire.
sql_on
è equivalente alla clausola ON
nell'SQL generato per una query. Con questo parametro, possiamo dichiarare quali campi devono essere abbinati per eseguire l'unione:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
sql_on: ${order_items.order_id} = ${orders.id} ;;
}
}
Puoi anche scrivere join più complessi. Ad esempio, potresti voler unire solo gli ordini con id
maggiori di 1000:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
sql_on: ${order_items.order_id} = ${orders.id} AND ${orders.id} > 1000 ;;
}
}
Consulta gli operatori di sostituzione per scoprire di più sulla sintassi di ${ ... }
in questi esempi.
Passaggio 6: test
Verifica che questa unione funzioni come previsto accedendo a Esplora articoli nella sezione Esplora. Dovresti visualizzare i campi sia di order_items
che di orders
.
Per ulteriori informazioni sul test delle modifiche LookML, consulta Sviluppo del modello.
Partecipazione da un'altra visualizzazione
Puoi unire una visualizzazione a un'esplorazione tramite un'altra visualizzazione. Nell'esempio precedente, hai eseguito la registrazione da orders
a order_items
tramite il campo order_id
. Possiamo anche unire i dati da una vista denominata users
all'esplorazione di order_items
, anche se non condividono un campo comune. A questo scopo, partecipa tramite alla visualizzazione orders
.
Utilizza sql_on
o foreign_key
per unire users
a orders
anziché order_items
. Per farlo, definisci correttamente il campo di orders
come orders.user_id
.
Ecco un esempio di utilizzo di 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} ;;
}
}
Partecipare a una visualizzazione più di una volta
Una vista users
contiene dati relativi sia agli acquirenti che ai venditori. Per unire i dati di questa visualizzazione a order_items
, ma puoi farlo separatamente per acquirenti e venditori, puoi unire due volte users
con nomi diversi, utilizzando il parametro from
.
Il parametro from
consente di specificare la vista da utilizzare in un join, assegnandogli un nome univoco. Ecco alcuni esempi:
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} ;;
}
}
In questo caso, solo i dati degli acquirenti vengono uniti come buyers
, mentre solo i dati dei venditori vengono uniti come sellers
.
Nota: la visualizzazione users
deve ora essere indicata con i nomi alias buyers
e sellers
nel join.
Limitazione dei campi da un join
Il parametro fields
ti consente di specificare quali campi vengono trasferiti da un join a un'esplorazione. Per impostazione predefinita, tutti i campi di una vista vengono importati quando vi unisci. Tuttavia, potresti voler importare solo un sottoinsieme di campi.
Ad esempio, quando orders
è unito a order_items
, potresti voler trasferire solo i campi shipping
e tax
tramite l'unione:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
sql_on: ${order_items.order_id} = ${orders.id} ;;
fields: [shipping, tax]
}
}
Puoi anche fare riferimento a un insieme di campi, ad esempio [set_a*]
. Ogni insieme è definito in una vista utilizzando il parametro set
. Supponiamo di avere definito il seguente insieme nella vista orders
:
set: orders_set {
fields: [created_date, shipping, tax]
}
Puoi scegliere di trasferire solo questi tre campi quando entri in orders
in 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*]
}
}
Aggregati simmetrici
Looker utilizza una funzionalità chiamata "aggregazioni simmetriche" per calcolare correttamente le aggregazioni (come somme e medie), anche quando i join generano un fanout. Gli aggregati simmetrici sono descritti in modo più dettagliato nella pagina Informazioni sulle aggregazioni simmetriche e il problema di fan-out che soddisfano sono illustrati nel post della community Il problema dei fan-out SQL.
Chiavi principali necessarie
Per applicare le misure (aggregazioni) ai join, devi definire le chiavi primarie in tutte le viste coinvolte nel join.
A tale scopo, aggiungi il parametro primary_key
alla definizione del campo della chiave primaria in ogni vista:
dimension: id {
type: number
primary_key: yes
}
Per gestire correttamente le misure unite, Looker si affida a te specificando una chiave primaria in cui i valori sono completamente univoci, non NULL. Se i dati non contengono una chiave primaria, valuta se la concatenazione di più campi genera una chiave primaria di valori non NULL univoci. Se la chiave primaria non è univoca o contiene valori NULL e la query include dati che rivelano tali problemi, Looker restituisce un errore come descritto nella pagina delle best practice relative a Errore: valore non univoco/chiave primaria (o sql_distinct_key), overflow del valore o collisione durante il calcolo della somma.
Dialetti SQL supportati
Affinché Looker supporti i dati aggregati simmetrici nel tuo progetto Looker, anche il dialetto del tuo database deve supportarli. La seguente tabella mostra quali dialetti supportano gli aggregati simmetrici nell'ultima release di Looker:
Se il tuo dialetto non supporta gli aggregati simmetrici, fai attenzione quando esegui i join in Looker, poiché alcuni tipi di join possono causare aggregazioni imprecise (come somme e medie). Questo problema e le relative soluzioni alternative sono descritti in dettaglio nel post della scheda Il problema dei fan-out SQL.
Scopri di più sui join
Per scoprire di più sui parametri di join in LookML, consulta la documentazione unione dei riferimenti.