Le unioni ti consentono di collegare diverse visualizzazioni in modo da poter esplorare i dati di più visualizzazioni contemporaneamente e vedere come si relazionano tra loro le diverse parti dei dati.
Ad esempio, il database potrebbe includere le tabelle order_items, orders e users. Puoi utilizzare le unioni per esplorare i dati di tutte le tabelle contemporaneamente. Questa pagina descrive le unioni in LookML, inclusi parametri di unione e pattern di unione specifici.
I join iniziano con un'esplorazione
Le unioni sono definite nel file del modello per stabilire la relazione tra un'esplorazione e una vista. Le unioni collegano una o più viste a una singola esplorazione, direttamente o tramite un'altra vista unita.
Considera due tabelle del 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 da order_items Esplora, 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 vista 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 svolge due funzioni. Innanzitutto, puoi visualizzare i campi di orders e order_items nel selettore dei campi di Esplora:
In secondo luogo, LookML descrive come unire orders e order_items. Il codice 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.
Parametri di join
Per l'unione vengono utilizzati quattro parametri principali: join, type, relationship e sql_on.
Passaggio 1: avvia l'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 unione da eseguire. Looker supporta LEFT JOIN, INNER JOIN, FULL OUTER JOIN e CROSS JOIN. Questi corrispondono ai valori del 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 visualizzazione orders. Dichiarare correttamente la relazione di un join è importante per consentire a Looker di calcolare misure accurate. La relazione è definita da order_items Esplora a orders. Le opzioni possibili sono one_to_one, many_to_one, one_to_many e many_to_many.
In questo esempio, possono esserci molti elementi dell'ordine per un singolo ordine. La relazione dall'esplorazione order_items alla visualizzazione orders è many_to_one:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
}
}
Se non includi un parametro relationship nel join, Looker utilizza many_to_one come valore predefinito.
Per ulteriori suggerimenti su come definire correttamente il parametro relationship per un'unione, consulta la sezione Definire correttamente il parametro relationship.
Passaggio 5: sql_on
Dichiara come unire la tabella order_items e la tabella orders con il parametro sql_on o il parametro foreign_key.
Il parametro sql_on è equivalente alla clausola ON nella query SQL generata. Con questo parametro, puoi 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 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 ${ ... } in questi esempi, consulta la documentazione sugli operatori di sostituzione.
Passaggio 6: test
Verifica che questo join funzioni come previsto andando all'esplorazione Elementi ordine. Dovresti visualizzare i campi di order_items e orders.
Consulta Testare i campi nell'esplorazione per scoprire di più su come testare le modifiche di LookML in un'esplorazione.
Partecipare tramite un'altra visualizzazione
Puoi unire una visualizzazione a un'esplorazione tramite un'altra visualizzazione. Nell'esempio di parametri di unione, hai unito orders a order_items tramite il campo order_id. Potremmo anche voler unire i dati di una visualizzazione chiamata users all'esplorazione order_items, anche se non condividono un campo comune. Puoi farlo unendoti tramite la visualizzazione orders.
Utilizza il parametro sql_on o il parametro foreign_key per unire la visualizzazione users alla visualizzazione orders, anziché all'esplorazione order_items. Per farlo, definisci correttamente l'ambito del campo da orders come orders.user_id.
Ecco 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} ;;
}
}
Partecipazione a una visualizzazione più di una volta
Una visualizzazione users contiene i dati sia degli acquirenti sia dei venditori. Per unire i dati di questa visualizzazione in order_items, ma separatamente per acquirenti e venditori, puoi unire users due volte, con nomi diversi, utilizzando il parametro from.
Il parametro from ti consente di specificare quale vista utilizzare in un'unione, assegnando al contempo un nome univoco all'unione. 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, vengono uniti solo i dati dell'acquirente come buyers, mentre vengono uniti solo i dati del venditore come sellers.
Nota: ora è necessario fare riferimento alla visualizzazione users con i nomi alias buyers e sellers nel join.
Limitare i campi di un join
Il parametro fields consente di specificare quali campi vengono importati da un'unione in un'esplorazione. Per impostazione predefinita, tutti i campi di una visualizzazione vengono importati quando vengono uniti. Tuttavia, potresti voler importare solo un sottoinsieme di campi.
Ad esempio, quando orders viene unito a order_items, potresti voler includere nell'unione solo i campi shipping e tax:
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 all'interno di una vista utilizzando il parametro set. Supponiamo che nella visualizzazione orders sia definito il seguente set:
set: orders_set {
fields: [created_date, shipping, tax]
}
Puoi scegliere di trasferire solo questi tre campi quando colleghi orders a 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 comportano un fanout. Gli aggregati simmetrici sono descritti in modo più dettagliato in Informazioni sugli aggregati simmetrici. Il problema di fanout che risolvono gli aggregati simmetrici è spiegato nel post della community Il problema dei fanout SQL.
Chiavi primarie obbligatorie
Per visualizzare le misure (aggregazioni) tramite i join, devi definire le chiavi primarie in tutte le visualizzazioni coinvolte nel join.
Per farlo, aggiungi il parametro primary_key alla definizione del campo della chiave primaria in ogni visualizzazione:
dimension: id {
type: number
primary_key: yes
}
Dialetti SQL supportati
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 | Supportato? |
|---|---|
| Actian Avalanche | Sì |
| Amazon Athena | Sì |
| Amazon Aurora MySQL | Sì |
| Amazon Redshift | Sì |
| Amazon Redshift 2.1+ | Sì |
| Amazon Redshift Serverless 2.1+ | Sì |
| Apache Druid | No |
| Apache Druid 0.13+ | No |
| Apache Druid 0.18+ | No |
| Apache Hive 2.3+ | No |
| Apache Hive 3.1.2+ | No |
| Apache Spark 3+ | Sì |
| ClickHouse | No |
| Cloudera Impala 3.1+ | Sì |
| Cloudera Impala 3.1+ with Native Driver | Sì |
| Cloudera Impala with Native Driver | No |
| DataVirtuality | Sì |
| Databricks | Sì |
| Denodo 7 | Sì |
| Denodo 8 & 9 | Sì |
| Dremio | No |
| Dremio 11+ | Sì |
| Exasol | Sì |
| Firebolt | Sì |
| Google BigQuery Legacy SQL | Sì |
| Google BigQuery Standard SQL | Sì |
| Google Cloud PostgreSQL | Sì |
| Google Cloud SQL | Sì |
| Google Spanner | Sì |
| Greenplum | Sì |
| HyperSQL | No |
| IBM Netezza | Sì |
| MariaDB | Sì |
| Microsoft Azure PostgreSQL | Sì |
| Microsoft Azure SQL Database | Sì |
| Microsoft Azure Synapse Analytics | Sì |
| Microsoft SQL Server 2008+ | Sì |
| Microsoft SQL Server 2012+ | Sì |
| Microsoft SQL Server 2016 | Sì |
| Microsoft SQL Server 2017+ | Sì |
| MongoBI | No |
| MySQL | Sì |
| MySQL 8.0.12+ | Sì |
| Oracle | Sì |
| Oracle ADWC | Sì |
| PostgreSQL 9.5+ | Sì |
| PostgreSQL pre-9.5 | Sì |
| PrestoDB | Sì |
| PrestoSQL | Sì |
| SAP HANA | Sì |
| SAP HANA 2+ | Sì |
| SingleStore | Sì |
| SingleStore 7+ | Sì |
| Snowflake | Sì |
| Teradata | Sì |
| Trino | Sì |
| Vector | 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 generare aggregazioni imprecise (come somme e medie). Questo problema e le relative soluzioni alternative sono descritti in dettaglio nel post della community The problem of SQL fanouts.
Scopri di più sui join
Per scoprire di più sui parametri di join in LookML, consulta la documentazione di riferimento al join.