explore_source

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

explore_source kann auch ein Unterparameter von test sein, wie auf der Dokumentationsseite zum Parameter test beschrieben.

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
view
derived_table
explore_source
Standardwert
Keine

Akzeptiert
Die ID 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 explore_source Parameter wird für native abgeleitete Tabellen verwendet. In 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.

Eine native abgeleitete Tabelle definieren

In einer nativen abgeleiteten Tabelle können Sie eine Vielzahl von Parametern verwenden, von denen viele optional sind. Die Syntax zum Definieren einer nativen abgeleiteten Tabelle sieht so aus:

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

Die folgende Tabelle enthält 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 das from_field im Explore an das 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 verbunden ist.
  • Die native abgeleitete Tabelle kann nicht in eine persistente abgeleitete Tabelle (PDT) umgewandelt werden.

• Der Parameter explore_source kann den Unterparameter bind_all_filters oder den Unterparameter bind_filters enthalten, aber nicht beide. 
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 zur Konfiguration dieses Parameters bind_all_filters: yes in der 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 verbunden ist.
  • Die native abgeleitete Tabelle kann nicht in eine PDT umgewandelt werden.
  • Die native abgeleitete Tabelle kann nur mit dem Explore verknüpft werden, das 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 den Unterparameter bind_all_filters oder den Unterparameter bind_filters enthalten, aber nicht beide.
 bind_all_filters: yes
column Gibt eine Spalte an, die in die explore_source aufgenommen werden soll. Hat einen Unterparameter field. 
column: cust_id {
  field: orders.customer_id
}
derived_column Gibt eine Spalte in der 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. Hat einen Unterparameter sql. 
derived_column: average_order {
  sql: order_amount / item_qty ;;
}
dev_filters Hinzugefügt in Version 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 Entwicklungsmodus testen. Mit dem Parameter dev_filters kann Looker kleinere, gefilterte Versionen der Tabelle erstellen, sodass ein LookML-Entwickler die Tabelle wiederholen und testen kann, ohne nach jeder Änderung warten zu müssen, bis die vollständige Tabelle erstellt wurde. Looker wendet die 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 Entwicklungsmodus finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker. Ein Beispiel finden Sie im Abschnitt Filter für den Entwicklungsmodus erstellen auf dieser Seite. dev_filters: [orders.created_date: "90 days", orders.products: "sweaters"]
expression_custom_filter Gibt optional einen benutzerdefinierten Filterausdruck in einer explore_source-Abfrage an. expression_custom_filter: ${orders.status} = "pending" ;;
filters Fügt optional einen Filter zu einer explore_source-Abfrage hinzu. In eckige Klammern setzen. Geben Sie den Feldnamen an, nach dem gefiltert werden soll, im Format view_name.field_name, gefolgt von : und 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 bei der Abfrage an. limit: 10
sorts Gibt optional eine Sortierung für diese explore_source an. In eckige Klammern setzen. 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 Feldnamen- und Schlüsselwortpaare durch Kommas getrennt 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 die Option "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 den Zeitzonenwert automatisch vor, wenn Sie den timezone Parameter in die IDE eingeben. Die Liste der unterstützten Zeitzonenwerte wird auch im Bereich „Schnellhilfe“ der IDE angezeigt.		 timezone: "America/Los_Angeles"

Beispiele

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

Native abgeleitete Tabelle user_order_facts erstellen:

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 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, der die Daten auf die letzten 90 Tage filtert, und einen filters Parameter, der die Daten auf die letzten zwei Jahre und auf den Yucca Valley Airport filtert. Der dev_filters Parameter agiert in Kombination mit dem filters Parameter, sodass alle Filter auf die Entwicklungsversion der Tabelle angewendet werden. Wenn sowohl dev_filters als auch filters Filter für dieselbe Spalte angeben, 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 Parameter dev_filters 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.

Beachten Sie, dass die umgekehrte Situation gilt: 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 gilt, es sei denn, Sie ändern die Definition der Tabelle und fragen sie 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. Fügen Sie dazu entweder den Parameter bind_all_filters oder den Parameter bind_filters zur explore_source der nativen abgeleiteten Tabelle hinzu.

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 übernehmen, kann die native abgeleitete Tabelle keine persistente abgeleitete Tabelle (PDT) 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 bind_filters Parameter, 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 die explore_source order_items. Im Folgenden sehen Sie den LookML-Code für das Explore order_items, in dem die native abgeleitete Tabelle mit dem Explore verknüpft ist:

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 finden Sie im [Analytic Block] – Pivot by Top X – Introducing bind_all_filters: yes Community-Beitrag.

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 das from_field im Explore an das to_field in der Unterabfrage der nativen abgeleiteten Tabelle übergeben.

Der folgende LookML-Code zeigt eine native abgeleitete Tabelle mit bind_filters. Bei dieser Konfiguration ü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 Parameter explore_source verwenden

Jede native abgeleitete Tabelle akzeptiert nur einen Parameter explore_source. Nachfolgende Parameter explore_source führen nicht zu LookML-Validierungsfehlern, überschreiben aber vorherige Parameter explore_source.

Wenn Sie Spalten aus Feldern in verschiedenen Ansichten erstellen möchten, verknüpfen Sie zuerst die verschiedenen Ansichten im selben Explore. Verwenden Sie dann dieses 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 mit der Definition des Explores einfügen. Dazu definieren Sie am besten das Explore in einer gesonderten Explore-Datei, wie in der Dokumentation zum Erstellen von Explore-Dateien beschrieben.

Wenn Sie eine separate Explore-Datei erstellen, gilt Folgendes:

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