join

Utilizzo

Explore: Explore_name {
join: view_name { ... }
}

Gerarchia File modello explore join

Valore predefinito Nessuna Accetta Il nome di una vista esistente Regole speciali Questo parametro accetta un nome di vista, non il nome della tabella sottostante la vista (anche se spesso sono identiche) Se il tuo dialetto non supporta symmetric_aggregates, la maggior parte dei tipi di misurazione viene esclusa dalle visualizzazioni unite Puoi unire la stessa visualizzazione più di una volta utilizzando from

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.