Le unioni ti consentono di collegare visualizzazioni diverse in modo da poter esplorare i dati di più visualizzazioni contemporaneamente e vedere in che modo parti diverse dei dati sono correlate tra loro.
Ad esempio, il 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 unione.
Le unioni iniziano con un'esplorazione
Le unioni sono definite nel file del modello per stabilire la relazione tra un'esplorazione e una visualizzazione. Le unioni collegano una o più viste a una singola esplorazione, direttamente o tramite un'altra vista unita.
Prendi in considerazione due tabelle di database: order_items e orders. Dopo aver generato le viste per entrambe le tabelle, dichiarane una o più nel parametro explore del file del modello:
explore: order_items { ... }
Quando esegui una query dall'esplorazione order_items, order_items viene visualizzato nella clausola FROM dell'SQL generato:
SELECT ...
FROM order_items
Puoi unire ulteriori informazioni all'esplorazione order_items. Ad esempio, puoi utilizzare il seguente codice LookML di esempio per unire la visualizzazione orders all'esplorazione order_items:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
sql_on: ${order_items.order_id} = ${orders.id} ;;
}
}
Il codice LookML mostrato in precedenza consente di ottenere due risultati. Innanzitutto, puoi vedere i campi di orders e order_items nel selettore campi Esplora:
In secondo luogo, il LookML descrive come unire orders e order_items. Questo codice LookML si traduce nel codice SQL seguente:
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.
Parametri di join
Per eseguire l'unione vengono utilizzati quattro parametri principali: join, type, relationship e sql_on.
Passaggio 1: avvio dell'esplorazione
Per prima cosa, crea l'esplorazione order_items:
explore: order_items { ... }
Passaggio 2: join
Per unire una tabella, devi prima dichiararla in una vista. In questo esempio, supponiamo che orders sia una visualizzazione esistente nel modello.
Quindi, utilizza il parametro join per dichiarare che vuoi unire la visualizzazione orders all'esplorazione order_items:
explore: order_items {
join: orders { ... }
}
Passaggio 3: type
Valuta il tipo di join da eseguire. Looker supporta LEFT JOIN, INNER JOIN, FULL OUTER JOIN e CROSS JOIN. Questi corrispondono 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.
Passaggio 4: relationship
Definisci una relazione di join tra l'esplorazione order_items e la vista orders. Dichiarare correttamente la relazione di un join è importante affinché Looker possa calcolare misure accurate. La relazione viene definita da esplorazione order_items alla vista orders. Le opzioni possibili sono one_to_one, many_to_one, one_to_many e many_to_many.
In questo esempio, possono esserci più articoli per un singolo ordine. La relazione tra l'esplorazione order_items e la vista orders è many_to_one:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
}
}
Se non includi un parametro relationship nella join, per impostazione predefinita Looker utilizza many_to_one.
Per ulteriori suggerimenti su come definire correttamente il parametro relationship per un join, consulta l'articolo Come usare correttamente il parametro relationship.
Passaggio 5: sql_on
Dichiara come unire la tabella order_items e la tabella orders insieme al parametro sql_on o foreign_key.
Il parametro sql_on è equivalente alla clausola ON nel codice SQL generato per una query. Con questo parametro, puoi dichiarare i campi da abbinare 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 partecipare solo agli ordini con id maggiore 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 ;;
}
}
Per saperne di più sulla sintassi di ${ ... } in questi esempi, consulta la documentazione sugli operatori di sostituzione.
Passaggio 6: test
Verifica che questa unione funzioni come previsto andando all'esplorazione Ordina articoli. Dovresti vedere i campi di order_items e orders.
Per saperne di più su come testare le modifiche LookML in un'esplorazione, consulta Test dei campi nell'esplorazione.
Partecipazione tramite un'altra visualizzazione
Puoi unire una visualizzazione a un'esplorazione tramite un'altra visualizzazione. Nell'esempio di parametri di join, hai unito orders a order_items tramite il campo order_id. Potremmo anche unire i dati di una visualizzazione denominata users all'esplorazione order_items, anche se non condividono un campo comune. Puoi farlo unendo tramite la vista orders.
Utilizza il parametro sql_on o il parametro foreign_key per unire la vista users alla vista orders anziché all'esplorazione order_items. Per farlo, definisci correttamente l'ambito del campo da orders come orders.user_id.
Di seguito è riportato un esempio di utilizzo del parametro 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 sia per gli acquirenti che per i venditori. Per unire i dati di questa vista in order_items, ma farlo separatamente per acquirenti e venditori, puoi unire users due volte, con nomi diversi, utilizzando il parametro from.
Il parametro from consente di specificare la vista da utilizzare in un join, assegnandogli un nome univoco. Ad esempio:
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 dell'acquirente vengono uniti come buyers, mentre solo i dati del venditore vengono uniti come sellers.
Nota: ora alla vista users deve essere fatto riferimento con i nomi degli alias buyers e sellers nella join.
Limitare i campi di un join
Il parametro fields consente di specificare quali campi vengono trasferiti da un join a un'esplorazione. Per impostazione predefinita, tutti i campi di una visualizzazione vengono importati durante l'unione. Tuttavia, potresti voler importare solo un sottoinsieme di campi.
Ad esempio, quando orders viene unito a order_items, potresti voler includere solo i campi shipping e tax nella combinazione:
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 viene definito all'interno di una vista utilizzando il parametro set. Supponi di avere definito il seguente insieme nella vista orders:
set: orders_set {
fields: [created_date, shipping, tax]
}
Quando unisci orders a order_items, puoi scegliere di importare solo questi tre campi:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
sql_on: ${order_items.order_id} = ${orders.id} ;;
fields: [orders_set*]
}
}
Dati aggregati simmetrici
Looker utilizza una funzionalità chiamata "aggregati simmetrici" per calcolare correttamente le aggregazioni (come somme e medie), anche quando i join generano un fan-out. Gli aggregati simmetrici sono descritti in modo più dettagliato in Informazioni sugli aggregati simmetrici. Il problema del fanout risolto dai fanout simmetrici viene spiegato nel post della scheda Community The problem of SQL fanouts (Il problema dei fanout SQL).
Chiavi primarie obbligatorie
Per fare in modo che le misure (aggregazioni) vengano visualizzate tramite i join, devi definire le chiavi principali in tutte le visualizzazioni coinvolte nel join.
Per farlo, aggiungi il parametro primary_key alla definizione del campo della chiave primaria in ogni vista:
dimension: id {
type: number
primary_key: yes
}
Dialetti SQL supportati
Affinché Looker supporti gli aggregati simmetrici nel progetto, anche il dialetto del database deve supportarli. La tabella seguente mostra quali dialetti supportano gli aggregati simmetrici nell'ultima release di Looker:
| Dialetto | Supportato? |
|---|---|
| Valanga Actia | Sì |
| Amazon Athena | Sì |
| Amazon Aurora MySQL | Sì |
| Amazon Redshift | Sì |
| Apache Druid | No |
| Apache Druid 0.13 o versioni successive | No |
| Apache Druid 0.18 o versioni successive | No |
| Apache Hive 2.3 e versioni successive | No |
| Apache Hive 3.1.2 o versioni successive | No |
| Apache Spark 3 e versioni successive | Sì |
| ClickHouse | No |
| Cloudera Impala 3.1 e versioni successive | Sì |
| Cloudera Impala 3.1 e versioni successive con driver nativo | Sì |
| Cloudera Impala con driver nativo | No |
| DataVirtuality | Sì |
| Databricks | Sì |
| Denodo 7 | Sì |
| Denodo 8 | Sì |
| Dremio | No |
| Dremio 11+ | Sì |
| Exasol | Sì |
| Fulmine | Sì |
| SQL precedente di Google BigQuery | Sì |
| SQL standard di Google BigQuery | Sì |
| Google Cloud PostgreSQL | Sì |
| Google Cloud SQL | Sì |
| Google Spanner | Sì |
| Greenplum | Sì |
| HyperSQL | No |
| Netezza di IBM | Sì |
| MariaDB | Sì |
| PostgreSQL Microsoft Azure | Sì |
| Database SQL di Microsoft Azure | Sì |
| Microsoft Azure Synapse Analytics | Sì |
| Microsoft SQL Server 2008 e versioni successive | Sì |
| Microsoft SQL Server 2012 o versioni successive | Sì |
| Microsoft SQL Server 2016 | Sì |
| Microsoft SQL Server 2017 e versioni successive | Sì |
| MongoBI | No |
| MySQL | Sì |
| MySQL 8.0.12 e versioni successive | Sì |
| Oracle | Sì |
| Oracle ADWC | Sì |
| PostgreSQL 9.5 e versioni successive | Sì |
| PostgreSQL pre-9.5 | Sì |
| PrestoDB | Sì |
| PrestoSQL | Sì |
| SAP HANA 2 e versioni successive | Sì |
| SingleStore | Sì |
| SingleStore 7 e versioni successive | Sì |
| Snowflake | Sì |
| Teradata | Sì |
| Trino | Sì |
| Vettoriale | Sì |
| Vertica | Sì |
Se il tuo dialetto non supporta gli aggregati simmetrici, fai attenzione quando esegui i join in Looker, poiché alcuni tipi di join possono comportare aggregazioni imprecise (come somme e medie). Questo problema e le relative soluzioni alternative sono descritti in modo molto dettagliato nel post della scheda Community Il problema dei fanout SQL.
Scopri di più sui join
Per saperne di più sui parametri di join in LookML, consulta la documentazione di riferimento sui join.