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 le unioni per esplorare contemporaneamente i dati di tutte le tabelle. Questa pagina spiega le unioni in LookML, inclusi parametri di unione e pattern di unione specifici.
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 di campi di esplorazione:
In secondo luogo, il codice 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 maggiore dettaglio nelle sezioni seguenti.
Parametri di join
Per 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 del parametro type 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. È importante dichiarare correttamente la relazione di un join per consentire a Looker di calcolare misure accurate. La relazione è definita da Esplora order_items a orders. Le opzioni possibili sono one_to_one, many_to_one, one_to_many e many_to_many.
In questo esempio, possono essere presenti molti articoli per un singolo ordine. La relazione tra l'esplorazione order_items e la visualizzazione orders è many_to_one:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
}
}
Se non includi un parametro relationship nella join, il valore predefinito di Looker è many_to_one.
Per ulteriori suggerimenti su come definire correttamente il parametro relationship per un join, 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 con il parametro foreign_key.
sql_on
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 unioni più complesse. 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 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 scoprire di più su come testare le modifiche a LookML in un'esplorazione, consulta Testare i 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 visualizzazione 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.
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 dati sia per gli acquirenti sia per i venditori. Per unire i dati di questa visualizzazione a 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 la visualizzazione da utilizzare in un join, assegnando al join 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'unione
Il parametro fields ti consente di specificare quali campi vengono importati da un'unione in 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. Supponiamo che nella visualizzazione orders sia definito il seguente insieme:
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*]
}
}
Aggregati simmetrici
Looker utilizza una funzionalità chiamata "aggregate simmetriche" per calcolare correttamente le aggregazioni (come somme e medie), anche quando le unioni generano un fanout. Gli aggregati simmetrici sono descritti in modo più dettagliato in Informazioni sugli aggregati simmetrici. Il problema di fanout risolto dagli aggregati symmetrid è spiegato nel post della scheda Community 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.
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 progetto, anche il dialetto del database deve supportarli. La tabella seguente mostra i dialetti che supportano gli aggregati simmetrici nell'ultima release di Looker:
| Dialetto | Supportato? |
|---|---|
| Actian Avalanche | Sì |
| Amazon Athena | Sì |
| Amazon Aurora MySQL | Sì |
| Amazon Redshift | Sì |
| Apache Druid | No |
| Apache Druid 0.13 e versioni successive | No |
| Apache Druid 0.18 o versioni successive | No |
| Apache Hive 2.3 e versioni successive | No |
| Apache Hive 3.1.2 e 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ì |
| PostgreSQL di Google Cloud | Sì |
| Google Cloud SQL | Sì |
| Google Spanner | Sì |
| Greenplum | Sì |
| HyperSQL | No |
| IBM Netezza | Sì |
| MariaDB | Sì |
| Microsoft Azure PostgreSQL | Sì |
| Database SQL di Microsoft Azure | Sì |
| Microsoft Azure Synapse Analytics | Sì |
| Microsoft SQL Server 2008 e versioni successive | Sì |
| Microsoft SQL Server 2012 e 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 precedente alla versione 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 le unioni in Looker, poiché alcuni tipi di unioni 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ù sulle unioni
Per scoprire di più sui parametri di join in LookML, consulta la documentazione di riferimento sui join.