esplora_sorgente

Questa pagina si riferisce al parametro explore_source, un parametro secondario di derived_table.

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

Utilizzo

Spiegazione

Gerarchia Visualizza file view derived_table explore_source

Valore predefinito Nessuna Accetta L'identificatore della funzionalità Esplora da cui deriva la tabella derivata nativa, più sottoparametri che definiscono la tabella derivata nativa.

Definizione

Esistono due modi per creare una tabella derivata, che puoi usare come se fosse una tabella normale nel tuo database: le tabelle derivate native, definite mediante parametri LookML, e le tabelle derivate basate su SQL, che vengono 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, eventuali filtri da applicare alla tabella derivata nativa, se limitare o ordinare le righe della tabella derivata nativa e se convertire i campi della tabella derivata nativa in un fuso orario diverso.

SUGGERIMENTO: il modo più semplice per creare una tabella nativa nativa è utilizzare la funzione Esplora per creare la query desiderata, quindi selezionare l'opzione Ottieni LookML da Esplora. Looker genererà la tabella LookML derivata per la query, che puoi copiare in un file di vista del tuo progetto LookML. Per informazioni dettagliate, consulta la pagina di documentazione Creazione di tabelle native native.

Definizione di una tabella derivata nativa

In una tabella derivata nativa puoi utilizzare una serie di parametri, molti dei quali facoltativi. Di seguito è riportata la sintassi per definire una tabella nativa derivata, seguita da ulteriori informazioni su ciascun parametro.

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

Dove:

Nome parametro	Descrizione	Esempio
bind_filters	Passa un filtro dalla query Esplora alla sottoquery della tabella derivata nativa. Per configurarlo, utilizza il sottoparametro from_field per specificare un campo definito nella visualizzazione della tabella derivata nativa o accessibile in Esplora a cui viene unita la tabella derivata nativa. In fase di esecuzione, tutti i filtri di from_field in Esplora verranno trasferiti in to_field nella sottoquery di tabella derivata nativa. Per un esempio, consulta questa sezione. Con bind_filters, tieni presente quanto segue: • Il filtro di runtime deve essere in una vista che si unisce 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 Esplora alla sottoquery della tabella derivata nativa. Per configurare questa opzione, specifica bind_all_filters: yes nella explore_source della tabella derivata nativa. Per un esempio, consulta questa sezione. Con bind_all_filters: yes, tieni presente quanto segue: • Il filtro di runtime deve essere in una vista che si unisce 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'Explore specificato nel parametro explore_source della tabella derivata nativa. Questo perché bind_all_filters deve mappare i campi filtrati di Explore (Esplora) ai campi nella tabella nativa derivata. • 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 funzioneranno qui, poiché non è presente alcun raggruppamento SQL in questo passaggio. Le funzioni delle finestre SQL possono essere molto utili in questo parametro. Ha un sottoparametro sql.	derived_column: average_order {   sql: order_amount / item_qty ;; }
dev_filters	AGGIUNTO 21.12 Specifica i filtri che Looker applica solo alle versioni di sviluppo della tabella derivata. Ciò è utile per gli sviluppatori LookML quando testano 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 viene eseguita la query degli utenti. Consulta la pagina della documentazione Tabelle derivate in Looker per ulteriori informazioni sull'utilizzo delle tabelle derivate in modalità di sviluppo 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	Facoltativamente, puoi specificare un'espressione di filtro personalizzata in una query explore_source.	expression_custom_filter:   ${orders.status} = "pending" ;;
filters	Se vuoi, aggiunge un filtro a una query di explore_source. Racchiudi tra parentesi quadre il nome del campo da filtrare, utilizzando il formato view_name.field_name, seguito dal nome : e dai valori in base ai quali il campo deve essere filtrato. I filtri vengono aggiunti alla clausola WHERE dell'SQL generato dalla tabella derivata nativa.	filters: [products.department: "sweaters"]
limit	Facoltativamente, specifica il limite di righe della query.	limit: 10
sorts	Facoltativamente, specifica un ordinamento per questo explore_source. Racchiudi tra parentesi quadre 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 in ordine crescente o decrescente. Puoi ordinare i dati in più campi aggiungendo più coppie di nomi di campo 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 in esecuzione. Se il fuso orario non è specificato, la query explore_source non eseguirà la conversione del fuso orario, bensì utilizzerà il fuso orario del database. Consulta la pagina dei valori timezone per un elenco dei fusi orari supportati. L'IDE suggerisce automaticamente il valore del fuso orario quando digiti il parametro timezone nell'IDE. L'IDE mostra anche l'elenco dei valori di fuso orario supportati nel riquadro della Guida rapida.	timezone: "America/Los_Angeles"

Esempi

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

Crea una tabella nativa derivata da 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
  }
}

Creare filtri per la modalità di sviluppo

A volte, la generazione della tabella derivata nativa che crei richiede molto tempo, il che può richiedere molto tempo se esegui il test di molte modifiche nella 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 in base 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 dev_filters e 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 filtra i dati relativi agli ultimi 90 giorni per l'Aeroporto di Yucca Valley.

Se la tabella nativa derivata 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 commentare il parametro dev_filters e poi eseguire una query sulla tabella in modalità di sviluppo. Looker creerà quindi una versione completa della tabella che può 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 la situazione opposta è vera: se hai una tabella nativa derivata con il parametro dev_filters e ne esegui una in modalità di sviluppo, Looker può utilizzare la tabella di produzione per rispondere alla query in modalità di sviluppo. Ciò è vero, a meno che non modifichi la definizione della tabella e poi la query in modalità Development (Sviluppo). A quel punto, 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 utilizzare i filtri di runtime di Esplora e applicarli alla query della tabella derivata nativa. A tale scopo, aggiungi il parametro bind_all_filters o bind_filters a explore_source della tabella derivata nativa.

Quando trasmetti i filtri di runtime da Esplora a una sottoquery di tabella derivata nativa, il filtro di runtime deve essere in una vista che si unisce alla stessa esplorazione della tabella derivata nativa. Inoltre, poiché la tabella nativa nativa deve essere rigenerata in fase di esecuzione per incorporare i filtri di runtime da Esplora, la tabella derivata nativa non può essere una tabella derivata permanente (PDT).

Uso: bind_all_filters

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

Una tabella derivata nativa con bind_all_filters: yes deve essere inclusa nella stessa esplorazione specificata nel parametro explore_source della tabella derivata nativa. Se vuoi utilizzare la tabella derivata nativa in un'altra funzione Esplora, utilizza il parametro bind_filters, come descritto in questa sezione.

Ecco il LookML di una tabella nativa derivata 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 sopra, explore_source è order_items. Ecco il LookML per l'esplorazione order_items in cui la tabella nativa derivata 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 l'articolo della community [Analytic Block] – Pivot by Top X – Presentazione bind_all_filters: yes.

Uso: bind_filters

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

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

In fase di esecuzione, tutti i filtri di from_field in Esplora verranno trasferiti in to_field nella sottoquery di tabella derivata nativa.

La tabella LookML seguente mostra una tabella derivata nativa con bind_filters. Con questa configurazione, Looker prenderà qualsiasi filtro applicato al campo filtered_lookml_dt.filter_date in Explore (Esplora) e lo applicherà al campo users.created_date nella tabella nativa derivata.

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 comporteranno errori di convalida di LookML, ma sostituiranno i parametri explore_source precedenti.

Per creare colonne dai campi in visualizzazioni diverse, devi prima unire le diverse visualizzazioni nella stessa esplorazione. Utilizza quindi Esplora per explore_source.

Utilizza le istruzioni include per abilitare i campi di riferimento

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

Se crei un file Esplora separato:

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