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

explore_source

Auf dieser Seite wird auf den Parameter explore_source verwiesen, der ein Unterparameter von derived_table ist.

explore_source kann auch ein Unterparameter von test sein. Weitere Informationen finden Sie auf der Dokumentationsseite zum Parameter test.

Nutzung

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

Hierarchie

Datei ansehen

view

derived_table

explore_source

Standardwert

Keine

Akzeptiert

Die Kennung des Explores, aus dem die native abgeleitete Tabelle abgeleitet wird, sowie Unterparameter, die die native abgeleitete Tabelle definieren.

Definition

Es gibt zwei Möglichkeiten, eine abgeleitete Tabelle zu erstellen, die Sie wie eine normale Tabelle in Ihrer Datenbank verwenden können: Native abgeleitete Tabellen, die mit LookML-Parametern definiert werden, und SQL-basierte abgeleitete Tabellen, die mit SQL-Abfrageanweisungen definiert werden.

Der Parameter explore_source wird für native abgeleitete Tabellen verwendet. Mit diesem Parameter definieren Sie, welche Spalten in eine native abgeleitete Tabelle aufgenommen werden, welche Filter auf die native abgeleitete Tabelle angewendet werden sollen, ob die Zeilen der nativen abgeleiteten Tabelle begrenzt oder sortiert werden sollen und ob die zeitbasierten Felder der nativen abgeleiteten Tabelle in eine andere Zeitzone konvertiert werden sollen.

Native abgeleitete Tabelle definieren

Sie können eine Vielzahl von Parametern in einer abgeleiteten nativen Tabelle verwenden. Viele davon sind optional. Die Syntax zum Definieren einer nativen abgeleiteten Tabelle lautet so:

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

In der folgenden Tabelle finden Sie Informationen zu den einzelnen Parametern, mit denen Sie eine native abgeleitete Tabelle definieren können:

Parametername	Beschreibung	Beispiel
`bind_filters`	Übergibt einen Filter aus der Explore-Abfrage an die Unterabfrage der nativen abgeleiteten Tabelle. Zur Konfiguration dieses Parameters geben Sie mit dem Unterparameter `from_field` ein Feld aus der Ansicht der nativen abgeleiteten Tabelle an oder ein Feld, auf das in dem Explore zugegriffen werden kann, mit dem die native abgeleitete Tabelle verknüpft ist. Zur Laufzeit werden alle Filter für `from_field` im Explore an `to_field` in der Unterabfrage der nativen abgeleiteten Tabelle übergeben. Ein Beispiel finden Sie im Abschnitt `bind_filters` verwenden. Beachten Sie bei `bind_filters` Folgendes: Der Laufzeitfilter muss sich in einer Ansicht befinden, die mit demselben Explore wie die native abgeleitete Tabelle verknüpft ist. Die native abgeleitete Tabelle kann nicht in eine persistente abgeleitete Tabelle (PAT) umgewandelt werden. • Der Parameter `explore_source` kann entweder den Unterparameter `bind_all_filters` oder den Unterparameter `bind_filters` enthalten, aber nicht beides.	bind_filters: { to_field: users.created_date from_field: user_dt.filter_date }
`bind_all_filters`	Übergibt alle Filter aus der Explore-Abfrage an die Unterabfrage der nativen abgeleiteten Tabelle. Geben Sie zum Einrichten dieses Parameters `bind_all_filters: yes` im `explore_source` der nativen abgeleiteten Tabelle an. Ein Beispiel finden Sie im Abschnitt `bind_filters` verwenden. Beachten Sie bei `bind_all_filters: yes` Folgendes: Der Laufzeitfilter muss sich in einer Ansicht befinden, die mit demselben Explore wie die native abgeleitete Tabelle verknüpft ist. Die native abgeleitete Tabelle kann nicht in eine PDT umgewandelt werden. Die native abgeleitete Tabelle kann nur mit dem Explore verknüpft werden, der im Parameter `explore_source` der nativen abgeleiteten Tabelle angegeben ist. Das liegt daran, dass `bind_all_filters` die gefilterten Felder des Explores den Feldern in der nativen abgeleiteten Tabelle zuordnen muss. Der Parameter `explore_source` kann entweder den Unterparameter `bind_all_filters` oder den Unterparameter `bind_filters` enthalten, aber nicht beides.	`bind_all_filters: yes`
`column`	Gibt eine Spalte an, die in `explore_source` aufgenommen werden soll. Enthält den Unterparameter `field`.	column: cust_id { field: orders.customer_id }
`derived_column`	Gibt eine Spalte im `explore_source` mit einem Ausdruck im Namespace der inneren Spalten an. Aggregierte SQL-Ausdrücke funktionieren an dieser Stelle nicht, da in diesem Schritt keine SQL-Gruppierung durchgeführt wird. SQL-Fensterfunktionen können in diesem Parameter sehr nützlich sein. Enthält den Unterparameter `sql`.	derived_column: average_order { sql: order_amount / item_qty ;; }
`dev_filters`	Added 21.12 Gibt Filter an, die Looker nur auf Entwicklungsversionen der abgeleiteten Tabelle anwendet. Dies ist für LookML-Entwickler nützlich, wenn sie abgeleitete Tabellen im Entwicklermodus testen. Mit dem Parameter `dev_filters` kann Looker kleinere, gefilterte Versionen der Tabelle erstellen, sodass ein LookML-Entwickler die Tabelle iterieren und testen kann, ohne nach jeder Änderung auf die Erstellung der vollständigen Tabelle warten zu müssen. Looker wendet `dev_filters` nur auf die Entwicklungsversionen der abgeleiteten Tabelle an, nicht auf die Produktionsversion der Tabelle, die von Ihren Nutzern abgefragt wird. Weitere Informationen zum Arbeiten mit abgeleiteten Tabellen im Entwicklermodus finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker. Ein Beispiel finden Sie auf dieser Seite im Abschnitt Filter für den Entwicklermodus erstellen.	`dev_filters: [orders.created_date: "90 days", orders.products: "sweaters"]`
`expression_custom_filter`	Gibt optional einen benutzerdefinierten Filterausdruck für eine `explore_source`-Abfrage an.	`expression_custom_filter: ${orders.status} = "pending" ;;`
`filters`	Fügt einer `explore_source`-Abfrage optional einen Filter hinzu. In eckige Klammern setzen. Geben Sie den Feldnamen zum Filtern im Format `view_name.field_name` an, gefolgt von `:` und dem bzw. den Werten, nach denen das Feld gefiltert werden soll. Filter werden der `WHERE`-Klausel des SQL-Codes hinzugefügt, der von der nativen abgeleiteten Tabelle generiert wird.	`filters: [products.department: "sweaters"]`
`limit`	Gibt optional die Zeilenbegrenzung der Abfrage an.	`limit: 10`
`sorts`	Gibt optional eine Sortierung für diesen `explore_source` an. Setzen Sie den Ausdruck in eckige Klammern. Geben Sie den Feldnamen an, nach dem sortiert werden soll, im Format `view_name.field_name`, gefolgt von `:` und `asc` oder `desc`, um anzugeben, ob das Feld aufsteigend oder absteigend sortiert werden soll. Sie können nach mehreren Feldern sortieren, indem Sie mehrere durch Kommas getrennte Paare aus Feldnamen und Schlüsselwörtern hinzufügen.	`sorts: [products.brand: asc, products.name: asc]`
`timezone`	Legt die Zeitzone für die `explore_source`-Abfrage fest. Legen Sie bei nicht persistenten abgeleiteten Tabellen als Zeitzone `"query_timezone"` fest, damit die Zeitzone der aktuell laufenden Abfrage verwendet wird. Wenn keine Zeitzone angegeben ist, findet während der `explore_source`-Abfrage keine Konvertierung der Zeitzone statt. Stattdessen wird die Datenbankzeitzone verwendet. Eine Liste der unterstützten Zeitzonen finden Sie auf der Seite `timezone`-Werte. Die IDE schlägt automatisch den Zeitzonenwert vor, wenn Sie den Parameter `timezone` in die IDE eingeben. Die IDE zeigt die Liste der unterstützten Zeitzonenwerte auch im Soforthilfe-Bereich an.	`timezone: "America/Los_Angeles"`

Beispiele

Die folgenden Definitionen enthalten grundlegende Beispiele für native abgeleitete Tabellen.

So erstellen Sie eine native abgeleitete Tabelle vom Typ 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
  }
}

Sie können Filter hinzufügen, um eine native abgeleitete Tabelle für user_90_day_facts zu erstellen:

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

Filter für den Entwicklungsmodus erstellen

Es gibt Situationen, in denen das Generieren der nativen abgeleiteten Tabelle, die Sie gerade erstellen, sehr lange dauert. Wenn Sie viele Änderungen im Entwicklungsmodus testen möchten, kann dies sehr zeitaufwendig sein. In diesen Fällen können Sie mit dev_filters kleinere Entwicklungsversionen einer nativen abgeleiteten Tabelle erstellen:

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

Dieses Beispiel enthält einen dev_filters-Parameter, mit dem die Daten nach den letzten 90 Tagen gefiltert werden, und einen filters-Parameter, mit dem die Daten nach den letzten zwei Jahren und nach dem Yucca Valley Airport gefiltert werden. Der Parameter dev_filters agiert in Kombination mit dem Parameter filters, sodass alle Filter auf die Entwicklungsversion der Tabelle angewendet werden. Wenn sowohl in dev_filters als auch in filters Filter für dieselbe Spalte angegeben sind, haben die dev_filters für die Entwicklungsversion der Tabelle Vorrang. In diesem Beispiel wird die Entwicklungsversion der Tabelle nach den Daten der letzten 90 Tage für den Yucca Valley Airport gefiltert.

Wenn eine native abgeleitete Tabelle den dev_filters-Parameter enthält, kann die Entwicklungstabelle nicht als Produktionsversion verwendet werden, da die Entwicklungsversion einen reduzierten Datensatz enthält. In diesem Fall können Sie nach Abschluss der Tabellenentwicklung und vor Bereitstellung der Änderungen den Parameter dev_filters herauskommentieren und anschließend die Tabelle im Entwicklungsmodus abfragen. Looker erstellt dann eine vollständige Version der Tabelle, die für die Produktion verwendet werden kann, wenn Sie Ihre Änderungen bereitstellen. Weitere Informationen zur Verwendung von Entwicklungstabellen in der Produktion finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.
Das Gegenteil ist ebenfalls der Fall: Wenn Sie eine native abgeleitete Tabelle mit dem Parameter dev_filters haben und sie im Entwicklungsmodus abfragen, kann Looker die Produktionstabelle verwenden, um Ihre Abfrage im Entwicklungsmodus zu beantworten. Diese Aussage ist wahr, es sei denn, Sie ändern die Definition der Tabelle und fragen die Tabelle dann im Entwicklungsmodus ab. In diesem Fall erstellt Looker eine Entwicklungstabelle, um die Abfrage zu beantworten.

Filter an eine native abgeleitete Tabelle übergeben

Wenn Sie eine native abgeleitete Tabelle in ein Explore einfügen, können Sie Laufzeitfilter aus dem Explore übernehmen und auf die Abfrage der nativen abgeleiteten Tabelle anwenden. Dazu fügen Sie entweder den Parameter bind_all_filters oder bind_filters in die explore_source der nativen abgeleiteten Tabelle ein.

Wenn Sie Laufzeitfilter aus einem Explore an eine Unterabfrage der nativen abgeleiteten Tabelle übergeben, muss sich der Laufzeitfilter in einer Ansicht befinden, die mit demselben Explore wie die native abgeleitete Tabelle verbunden ist. Da die native abgeleitete Tabelle zur Laufzeit neu generiert werden muss, um die Laufzeitfilter aus dem Explore zu berücksichtigen, kann sie keine persistente abgeleitete Tabelle (PAT) sein.

`bind_all_filters` verwenden

Am einfachsten übergeben Sie Filter aus einem Explore an eine Unterabfrage der nativen abgeleiteten Tabelle, indem Sie im Parameter explore_source der nativen abgeleiteten Tabelle bind_all_filters: yes angeben. Dadurch werden alle Laufzeitfilter eines Explores an die Unterabfrage der nativen abgeleiteten Tabelle übergeben.

Eine native abgeleitete Tabelle mit bind_all_filters: yes muss mit demselben Explore verknüpft werden, das im Parameter explore_source der nativen abgeleiteten Tabelle angegeben ist. Wenn Sie die native abgeleitete Tabelle in einem anderen Explore verwenden möchten, verwenden Sie stattdessen den Parameter bind_filters, wie im Abschnitt bind_filters verwenden beschrieben.

Hier ist der LookML-Code für eine native abgeleitete Tabelle mit 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} ;;
  }
}

In der Ansicht der nativen abgeleiteten Tabelle ist explore_source gleich order_items. Im Folgenden sehen Sie den LookML-Code für das order_items-Explore, in dem die native abgeleitete Tabelle mit dem Explore verknüpft wird:

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

Ein Beispiel für die Verwendung dieses Blocks finden Sie im Community-Beitrag [Analytic Block] – Pivot by Top X – Introducing bind_all_filters: yes.

`bind_filters` verwenden

Mit dem Unterparameter bind_filters von explore_source wird ein bestimmter Filter aus der Explore-Abfrage an die Unterabfrage der nativen abgeleiteten Tabelle übergeben:

to_field ist das Feld in der nativen abgeleiteten Tabelle, auf das der Filter angewendet wird. to_field muss ein Feld aus der zugrunde liegenden explore_source sein.
Mit from_field wird das Feld im Explore angegeben, aus dem der Filter abgerufen werden soll, wenn zur Laufzeit ein Filter angegeben wird.

Zur Laufzeit werden alle Filter für from_field im Explore an to_field in der Unterabfrage der nativen abgeleiteten Tabelle übergeben.

Im folgenden LookML-Code sehen Sie eine native abgeleitete Tabelle mit bind_filters. Bei dieser Einrichtung übernimmt Looker alle Filter, die auf das Feld filtered_lookml_dt.filter_date im Explore angewendet werden, und wendet sie auf das Feld users.created_date in der nativen abgeleiteten Tabelle an.

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

Wichtige Punkte

Nur einen `explore_source`-Parameter verwenden

Für jede abgeleitete Tabelle mit nativen Daten ist nur ein explore_source-Parameter zulässig. Nachfolgende explore_source-Parameter führen nicht zu LookML-Validierungsfehlern, überschreiben aber vorherige explore_source-Parameter.

Wenn Sie Spalten aus Feldern in verschiedenen Ansichten erstellen möchten, müssen Sie die verschiedenen Ansichten zuerst im selben Explore zusammenführen. Verwenden Sie dann diesen Explore für explore_source.

`include`-Anweisungen verwenden, um Verweise auf Felder zu ermöglichen

Beim Erstellen einer nativen abgeleiteten Tabelle müssen Sie die Datei, die die Definition des Explores enthält, einbinden. Dazu definieren Sie am besten das Explore in einer gesonderten Explore-Datei, wie in der Dokumentation unter Explore-Dateien erstellen beschrieben.

Wenn Sie eine separate Explore-Datei erstellen:

Die Ansichtsdatei der nativen abgeleiteten Tabelle sollte die Explore-Datei enthalten. Beispiel:
- include: "/explores/order_items.explore.lkml"
Die Explore-Datei sollte die benötigten Ansichtsdateien enthalten. Beispiel:
- include: "/views/order_items.view.lkml"
- include: "/views/users.view.lkml"
Das Modell sollte die Explore-Datei enthalten. Beispiel:
- include: "/explores/order_items.explore.lkml"