explore_source

Questa pagina si riferisce al parametro explore_source, che è un sottoparametro di derived_table.

explore_source può essere anche un sottoparametro di test, come descritto nella pagina della documentazione del parametro test.

Utilizzo

derived_table: customer_order_facts {
  explore_source:  orders {
    column:  customer_id {
      field:  orders.customer_id
    }
    column:  order_amount {
      field:  orders.sale_price
    }
    column:  item_qty {
      field:  orders.number_items
    }
    derived_column:  average_item_price {
      sql:  order_amount / item_qty  ;;
    }
    timezone:  "America/Los_Angeles"
  }
}
Gerarchia
view
derived_table
explore_source
Valore predefinito
Nessuno

Accetta
L'identificatore dell'esplorazione da cui deriva la tabella derivata nativa, oltre ai sottoparametri che definiscono la tabella derivata nativa.

Definizione

Esistono due modi per creare una tabella derivata, che puoi utilizzare come se fosse una tabella normale nel database: le tabelle derivate native, definite utilizzando i parametri LookML, e le tabelle derivate basate su SQL, definite utilizzando le istruzioni delle query SQL.

Il parametro explore_source viene utilizzato per le tabelle derivate native. In questo parametro definisci le colonne da includere in una tabella derivata nativa, i filtri da applicare alla tabella derivata nativa, se limitare o ordinare le righe della tabella derivata nativa e se convertire i campi basati sul tempo della tabella derivata nativa in un fuso orario diverso.

Definizione di una tabella derivata nativa

Puoi utilizzare una serie di parametri in una tabella derivata nativa, molti dei quali sono facoltativi. La sintassi per definire una tabella derivata nativa è la seguente:

explore_source: identifier {
  bind_all_filters: yes
  column: identifier {
    field: field_name
  }
  derived_column: identifier {
    sql: SQL expression ;;
  }
  expression_custom_filter: [custom filter expression]
  filters: [field_name_1: "string", field_name_2: "string", ...]
  limit: number
  sorts: [field_name_1: asc | desc, field_name_2: asc | desc, ...]
  timezone: "string"
}

La tabella seguente fornisce informazioni su ogni parametro che puoi utilizzare per definire una tabella derivata nativa:

Nome parametro Descrizione Esempio
bind_filters Passa un filtro dalla query di esplorazione alla sottoquery della tabella derivata nativa. Per configurare questo parametro, utilizza il sottoparametro from_field per specificare un campo definito nella visualizzazione della tabella derivata nativa o accessibile nell'esplorazione a cui è unita la tabella derivata nativa. In fase di runtime, tutti i filtri sul from_field nell'esplorazione verranno passati al to_field nella sottoquery della tabella derivata nativa. Per un esempio, consulta la sezione Utilizzo bind_filters.

Con bind_filters, tieni presente quanto segue:
  • Il filtro di runtime deve essere in una visualizzazione unita alla stessa esplorazione della tabella derivata nativa.
  • La tabella derivata nativa non può essere trasformata in una tabella derivata permanente (PDT).

• Il parametro explore_source può avere il sottoparametro bind_all_filters o il sottoparametro bind_filters, ma non entrambi. 
bind_filters: {
  to_field: users.created_date
  from_field: user_dt.filter_date
}
bind_all_filters Passa tutti i filtri dalla query di esplorazione alla sottoquery della tabella derivata nativa. Per configurare questo parametro, specifica bind_all_filters: yes nel explore_source della tabella derivata nativa. Per un esempio, consulta la sezione Utilizzo bind_filters.

Con bind_all_filters: yes, tieni presente quanto segue:
  • Il filtro di runtime deve essere in una visualizzazione unita alla stessa esplorazione della tabella derivata nativa.
  • La tabella derivata nativa non può essere trasformata in una PDT.
  • La tabella derivata nativa può essere unita solo all'esplorazione specificata nel parametro explore_source della tabella derivata nativa. Questo perché bind_all_filters deve mappare i campi filtrati dell'esplorazione ai campi della tabella derivata nativa.
  • Il parametro explore_source può avere il sottoparametro bind_all_filters o il sottoparametro bind_filters, ma non entrambi.
 bind_all_filters: yes
column Specifica una colonna da includere in explore_source. Ha un sottoparametro field. 
column: cust_id {
  field: orders.customer_id
}
derived_column Specifica una colonna in explore_source con un'espressione nello spazio dei nomi delle colonne interne. Le espressioni SQL aggregate non funzionano qui, poiché non esiste un raggruppamento SQL in questo passaggio. Le funzioni finestra SQL possono essere molto utili in questo parametro. Ha un sottoparametro sql. 
derived_column: average_order {
  sql: order_amount / item_qty ;;
}
dev_filters Aggiunto nella versione 21.12 Specifica i filtri che Looker applica solo alle versioni di sviluppo della tabella derivata. È utile per gli sviluppatori LookML quando testano le tabelle derivate in modalità di sviluppo. Il parametro dev_filters consente a Looker di creare versioni più piccole e filtrate della tabella, in modo che uno sviluppatore LookML possa eseguire l'iterazione e testare la tabella senza dover attendere la creazione della tabella completa dopo ogni modifica. Looker applica dev_filters solo alle versioni di sviluppo della tabella derivata, non alla versione di produzione della tabella su cui eseguono query gli utenti. Per ulteriori informazioni sull'utilizzo delle tabelle derivate in modalità di sviluppo, consulta la pagina della documentazione dedicata alle tabelle derivate in Looker e la sezione Creazione di filtri per la modalità di sviluppo in questa pagina per un esempio. dev_filters: [orders.created_date: "90 days", orders.products: "sweaters"]
expression_custom_filter Specifica facoltativamente un'espressione di filtro personalizzata in una query explore_source. expression_custom_filter: ${orders.status} = "pending" ;;
filters Aggiunge facoltativamente un filtro a una query explore_source. Racchiudi tra parentesi quadre; includi il nome del campo da filtrare, utilizzando il formato view_name.field_name, seguito da : e dai valori su cui filtrare il campo. I filtri vengono aggiunti alla clausola WHERE dell'SQL generato dalla tabella derivata nativa. filters: [products.department: "sweaters"]
limit Specifica facoltativamente il limite di righe della query. limit: 10
sorts Specifica facoltativamente un ordinamento per questo explore_source. Racchiudi tra parentesi quadre; includi il nome del campo da ordinare, utilizzando il formato view_name.field_name, seguito da : e asc o desc per indicare se il campo deve essere ordinato in ordine crescente o decrescente. Puoi ordinare in base a più campi aggiungendo più coppie di nomi di campi e parole chiave separate da virgole. sorts: [products.brand: asc, products.name: asc]
timezone Imposta il fuso orario per la query explore_source. Per le tabelle derivate non permanenti, imposta il fuso orario su "query_timezone" per utilizzare automaticamente il fuso orario della query in esecuzione. Se non viene specificato un fuso orario, la query explore_source non eseguirà alcuna conversione del fuso orario, ma utilizzerà il fuso orario del database invece. Per un elenco dei fusi orari supportati, consulta la pagina dei valori timezone.

L'IDE suggerisce automaticamente il valore del fuso orario quando digiti il parametro timezone nell'IDE. L'IDE mostra anche l'elenco dei valori dei fusi orari supportati nel riquadro Guida rapida.		 timezone: "America/Los_Angeles"

Esempi

Le seguenti definizioni forniscono esempi di base di tabelle derivate native.

Crea una tabella derivata nativa user_order_facts:

view: user_order_facts {
  derived_table: {
    explore_source: order_items {
      column: user_id {
        field: order_items.user_id
      }
      column: lifetime_number_of_orders {
        field: order_items.order_count
      }
      column: lifetime_customer_value {
        field: order_items.total_revenue
      }
    }
  }
  # Define the view's fields as desired
  dimension: user_id {
    hidden: yes
  }
  dimension: lifetime_number_of_orders {
    type: number
  }
  dimension: lifetime_customer_value {
    type: number
  }
}

Puoi aggiungere filtri per creare una tabella derivata nativa user_90_day_facts:

view: user_90_day_facts {
  derived_table: {
    explore_source: order_items {
      column: user_id {
        field: order_items.user_id
      }
      column: number_of_orders_90_day {
        field: order_items.order_count
      }
      column: customer_value_90_day {
        field: order_items.total_revenue
      }
      filters: [order_items.created_date: "90 days"]
    }
  }
  # Add define view's fields as desired
  dimension: user_id {
    hidden: yes
  }
  dimension: number_of_orders_90_day {
    type: number
  }
  dimension: customer_value_90_day {
    type: number
  }
}

Creazione di filtri per la modalità di sviluppo

In alcune situazioni, la tabella derivata nativa che stai creando richiede molto tempo per essere generata, il che può essere dispendioso in termini di tempo se stai testando molte modifiche in modalità di sviluppo. In questi casi, puoi utilizzare dev_filters per creare versioni di sviluppo più piccole di una tabella derivata nativa:

view: e_faa_pdt {
  derived_table: {
  ...
    datagroup_trigger: e_faa_shared_datagroup
    explore_source: flights {
      dev_filters: [flights.event_date: "90 days"]
      filters: [flights.event_date: "2 years", flights.airport_name: "Yucca Valley Airport"]
      column: id {}
      column: airport_name {}
      column: event_date {}
    }
  }
...
}

Questo esempio include un parametro dev_filters che filtra i dati in base agli ultimi 90 giorni e un parametro filters che filtra i dati in base agli ultimi 2 anni e all'aeroporto di Yucca Valley. Il parametro dev_filters funziona in combinazione con il parametro filters, in modo che tutti i filtri vengano applicati alla versione di sviluppo della tabella. Se sia dev_filters sia filters specificano filtri per la stessa colonna, dev_filters ha la precedenza per la versione di sviluppo della tabella. In questo esempio, la versione di sviluppo della tabella filtrerà i dati in base agli ultimi 90 giorni per l'aeroporto di Yucca Valley.

Se una tabella derivata nativa ha il parametro dev_filters, la tabella di sviluppo non può essere utilizzata come versione di produzione, poiché la versione di sviluppo ha un set di dati abbreviato. In questo caso, dopo aver completato lo sviluppo della tabella e prima di eseguire il deployment delle modifiche, puoi aggiungere un commento al parametro dev_filters e poi eseguire una query sulla tabella in modalità di sviluppo. Looker creerà quindi una versione completa della tabella che potrà essere utilizzata per la produzione quando esegui il deployment delle modifiche. Per maggiori dettagli sull'utilizzo delle tabelle di sviluppo in produzione, consulta la pagina della documentazione dedicata alle tabelle derivate in Looker.

Tieni presente che la situazione opposta è vera: se hai una tabella derivata nativa con il parametro dev_filters ed esegui una query in modalità di sviluppo, Looker può utilizzare la tabella di produzione per rispondere alla query in modalità di sviluppo. Questa affermazione è vera a meno che tu non modifica la definizione della tabella e quindi esegui una query sulla tabella in modalità di sviluppo, a quel punto Looker creerà una tabella di sviluppo per rispondere alla query.

Passaggio di filtri a una tabella derivata nativa

Quando includi una tabella derivata nativa in un'esplorazione, puoi prendere i filtri di runtime dall'esplorazione e applicarli alla query della tabella derivata nativa. Per farlo, aggiungi il parametro bind_all_filters o bind_filters a explore_source della tabella derivata nativa.

Quando passi i filtri di runtime da un'esplorazione a una sottoquery della tabella derivata nativa, il filtro di runtime deve essere in una visualizzazione unita alla stessa esplorazione della tabella derivata nativa. Inoltre, poiché la tabella derivata nativa deve essere rigenerata in fase di runtime per incorporare i filtri di runtime dall'esplorazione, la tabella derivata nativa non può essere una tabella derivata permanente (PDT).

Utilizzo di bind_all_filters

Il modo più semplice per passare i filtri da un'esplorazione a una sottoquery della tabella derivata nativa è specificare bind_all_filters: yes nel parametro explore_source della tabella derivata nativa. In questo modo, tutti i filtri di runtime di un'esplorazione verranno passati alla sottoquery della tabella derivata nativa.

Una tabella derivata nativa con bind_all_filters: yes deve essere unita alla stessa esplorazione specificata nel parametro explore_source della tabella derivata nativa. Se vuoi utilizzare la tabella derivata nativa in un'esplorazione diversa, utilizza il parametro bind_filters, come descritto nella sezione Utilizzo di bind_filters.

Ecco il codice LookML per una tabella derivata nativa con bind_all_filters: yes:


view: top_10_simple_item_names {
  view_label: "Top 10s"
  derived_table: {
    explore_source: order_items {
      column: total_sale_price {
        field: order_items.total_sale_price
      }
      column: item_name {
        field: products.item_name
      }
      derived_column: rank {
        sql: RANK() OVER (ORDER BY total_sale_price DESC) ;;
      }
      bind_all_filters: yes
      sorts: [order_items.total_sale_price: desc]
      timezone: "query_timezone"
      limit: 10
    }
  }
  dimension: item_name {
    group_label: "Simple Example"
  }
  dimension: rank {
    type: number
    group_label: "Simple Example"
  }
  dimension: item_name_ranked {
    group_label: "Simple Example"
    order_by_field: rank
    type: string
    sql: ${rank} || ') ' || ${item_name} ;;
  }
}

Nella visualizzazione della tabella derivata nativa, explore_source è order_items. Di seguito è riportato il codice LookML per l'esplorazione order_items in cui la tabella derivata nativa è unita all'esplorazione:

explore: order_items {
  ...
  join: top_10_simple_item_names {
    type: inner
    relationship: many_to_one
    sql_on: ${products.item_name} = ${top_10_simple_item_names.item_name} ;;
  }
}

Per vedere questo esempio in azione, consulta il post della community [Blocco analitico] - Pivot per i primi X - Introduzione a bind_all_filters: yes.

Utilizzo di bind_filters

Il sottoparametro bind_filters di explore_source passa un filtro specifico dalla query di esplorazione alla sottoquery della tabella derivata nativa:

  • to_field è il campo della tabella derivata nativa a cui viene applicato il filtro. to_field deve essere un campo di explore_source sottostante.
  • from_field specifica il campo dell'esplorazione da cui ottenere il filtro, se l'utente specifica un filtro in fase di runtime.

In fase di runtime, tutti i filtri sul from_field nell'esplorazione verranno passati al to_field nella sottoquery della tabella derivata nativa.

Il seguente codice LookML mostra una tabella derivata nativa con bind_filters. Con questa configurazione, Looker prenderà qualsiasi filtro applicato al campo filtered_lookml_dt.filter_date nell'esplorazione e lo applicherà al campo users.created_date nella tabella derivata nativa.

derived_table: {
  explore_source: order_items {
    bind_filters: {
      to_field: users.created_date
      from_field: filtered_lookml_dt.filter_date
    . . .
    }
  }
}

Aspetti da considerare

Utilizzare un solo parametro explore_source

Ogni tabella derivata nativa accetta un solo parametro explore_source. I parametri explore_source successivi non genereranno errori di convalida LookML, ma sostituiranno i parametri explore_source precedenti.

Per creare colonne da campi in visualizzazioni diverse, unisci prima le diverse visualizzazioni nella stessa esplorazione. Poi utilizza questa esplorazione per explore_source.

Utilizzare le istruzioni include per abilitare i campi di riferimento

Quando crei una tabella derivata nativa, devi includere il file contenente la definizione dell'esplorazione. Il modo migliore per farlo è definire l'Explore in un file Explore separato, come descritto nella documentazione relativa alla creazione di file Explore.

Se crei un file Explore separato:

  • Il file di vista della tabella derivata nativa deve includere il file dell'esplorazione. Ad esempio:
    • include: "/explores/order_items.explore.lkml"
  • Il file dell'esplorazione deve includere i file di visualizzazione di cui ha bisogno. Ad esempio:
    • include: "/views/order_items.view.lkml"
    • include: "/views/users.view.lkml"
  • Il modello deve includere il file dell'esplorazione. Ad esempio:
    • include: "/explores/order_items.explore.lkml"