You are viewing documentation for Looker 25.20. Click this link to see the most recent documentation.

explore_source

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

explore_source può anche essere un sottoparametro di test, 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

Visualizza file

view

derived_table

explore_source

Valore predefinito

Nessuno

Accetta

L'identificatore dell'esplorazione da cui viene derivata la tabella derivata nativa, più i parametri secondari che definiscono la tabella derivata nativa.

Definizione

Esistono due modi per creare una tabella derivata, che puoi utilizzare come se fosse una normale tabella nel database: le tabelle derivate native, definite utilizzando i parametri LookML, e le tabelle derivate basate su SQL, definite utilizzando le istruzioni di 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, gli eventuali 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 seguente tabella fornisce informazioni su ciascun 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 parametro secondario `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 applicati a `from_field` nell'esplorazione verranno passati a `to_field` nella sottoquery della tabella derivata nativa. Per un esempio, consulta la sezione Utilizzo di `bind_filters`. Con `bind_filters`, tieni presente quanto segue: Il filtro runtime deve trovarsi 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 della query di esplorazione nella sottoquery della tabella derivata nativa. Per configurare questo parametro, specifica `bind_all_filters: yes` in `explore_source` della tabella derivata nativa. Per un esempio, consulta la sezione Utilizzo di `bind_filters`. Con `bind_all_filters: yes`, tieni presente quanto segue: Il filtro runtime deve trovarsi 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 di Esplora ai campi della tabella derivata nativa. Il parametro `explore_source` può avere il parametro secondario `bind_all_filters` o il parametro secondario `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é in questo passaggio non è presente alcun raggruppamento SQL. 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 iterare e testare la tabella senza 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 vengono eseguite query dagli utenti. Per saperne di più sull'utilizzo delle tabelle derivate in modalità di sviluppo, consulta la pagina della documentazione 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 personalizzato 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 dal valore o dai valori in base ai quali 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`	(Facoltativo) Specifica 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 persistenti, imposta il fuso orario su `"query_timezone"` per utilizzare automaticamente il fuso orario della query attualmente in esecuzione. Se non viene specificato un fuso orario, la query `explore_source` non esegue alcuna conversione del fuso orario, ma utilizza il fuso orario del database. 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 user_90_day_facts tabella derivata nativa:

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
  }
}

Creare filtri per la modalità di sviluppo

Esistono situazioni in cui la tabella derivata nativa che stai creando richiede molto tempo per essere generata, il che può richiedere molto 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 due anni e all'aeroporto di Yucca Valley. Il parametro dev_filters agisce in combinazione con il parametro filters in modo che tutti i filtri vengano applicati alla versione di sviluppo della tabella. Se sia dev_filters che 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 degli 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 terminato lo sviluppo della tabella e prima di eseguire il deployment delle modifiche, puoi impostare come commento il parametro dev_filters e quindi 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 ulteriori dettagli sull'utilizzo delle tabelle di sviluppo in produzione, consulta la pagina della documentazione Tabelle derivate in Looker.
Tieni presente che vale anche la situazione inversa: se hai una tabella derivata nativa con il parametro dev_filters e la esegui 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 modifiche la definizione della tabella e poi esegui una query sulla tabella in modalità di sviluppo, nel qual caso Looker creerà una tabella di sviluppo per rispondere alla query.

Trasferire i filtri in 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 filtri di runtime da un'esplorazione a una sottoquery di una tabella derivata nativa, il filtro di runtime deve trovarsi in una vista 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 dell'esplorazione, non può essere una tabella derivata permanente (PDT).

Uso: `bind_all_filters`

Il modo più semplice per passare i filtri da un'esplorazione a una sottoquery di una 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 nella 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 viene 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 [Analytic Block] – Pivot by Top X – Introducing bind_all_filters: yes.

Uso: `bind_filters`

Il parametro secondario bind_filters di explore_source passa un filtro specifico dalla query Esplora 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 del explore_source sottostante.
from_field specifica il campo dell'Explore da cui ottenere il filtro, se l'utente specifica un filtro in fase di runtime.

In fase di runtime, tutti i filtri applicati a from_field nell'esplorazione verranno passati a 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

Utilizza 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 dai campi in visualizzazioni diverse, unisci prima le diverse visualizzazioni nella stessa esplorazione. Poi utilizza Esplora per explore_source.

Utilizzare le istruzioni `include` per attivare 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'esplorazione in un file di esplorazione separato, come descritto nella documentazione relativa alla creazione di file di esplorazione.

Se crei un file Esplora separato:

Il file di visualizzazione della tabella derivata nativa deve includere il file di Esplora. Ad esempio:
- include: "/explores/order_items.explore.lkml"
Il file di Esplora deve includere i file di visualizzazione necessari. 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"