Entdecken_Quelle

Diese Seite bezieht sich auf den Parameter explore_source, der ein Unterparameter von derived_table ist.

explore_source kann auch ein Unterparameter von test sein. Eine Beschreibung finden Sie auf der Dokumentationsseite für den Parameter test.

Nutzung

Ich bin nicht werbeberechtigt.

Hierarchie Datei ansehen view derived_table explore_source

Standardwert Keine Akzeptiert Die ID der „Erkunden“-Tabelle, aus der die native abgeleitete Tabelle abgeleitet wird, sowie Unterparameter, mit denen die native abgeleitete Tabelle definiert wird.

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 sind.

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

TIPP: Die einfachste Methode zum Erstellen einer nativen abgeleiteten Tabelle ist die Verwendung einer Funktion „Erkunden“. Damit können Sie die gewünschte Abfrage erstellen und dann auf der Seite „Erkunden“ die Option GetML abrufen. Looker generiert die abgeleitete LookLook-Tabelle für die Abfrage, die Sie in eine Ansichtsdatei Ihres LookML-Projekts kopieren können. Weitere Informationen finden Sie auf der Dokumentationsseite Native abgeleitete Tabellen erstellen.

Native abgeleitete Tabelle definieren

Sie können eine Vielzahl von Parametern in einer nativen abgeleiteten Tabelle verwenden, viele davon sind optional. Die Syntax zum Definieren einer nativen abgeleiteten Tabelle wird unten angezeigt, gefolgt von zusätzlichen Informationen zu jedem Parameter.

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

Wobei:

Parametername	Beschreibung	Beispiel
bind_filters	Übergibt einen Filter aus der Abfrage „Erkunden“ in die Unterabfrage der nativen abgeleiteten Tabelle Verwenden Sie den Unterparameter from_field, um ein Feld anzugeben, das in der nativen abgeleiteten Tabellenansicht definiert oder in der Ansicht, mit der die native abgeleitete Tabelle verknüpft ist, zugänglich ist. Während der Laufzeit werden alle Filter für from_field in der Funktion „Erkunden“ in der nativen abgeleiteten Tabellenabfrage an to_field übergeben. In diesem Abschnitt unten finden Sie ein Beispiel. Hinweis für bind_filters: • Der Laufzeitfilter muss sich in einer Ansicht befinden, die mit derselben Ansicht wie die native abgeleitete Tabelle verknüpft 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 bind_filters, aber nicht beides haben.	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 native Unterabfrage der Tabelle. Geben Sie dazu bind_all_filters: yes in der Datei explore_source der nativen abgeleiteten Tabelle an. In diesem Abschnitt unten finden Sie ein Beispiel. Hinweis für bind_all_filters: yes: • Der Laufzeitfilter muss sich in einer Ansicht befinden, die mit derselben Ansicht 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 der Option „Erkunden“ verknüpft werden, die im Parameter explore_source der nativen abgeleiteten Tabelle angegeben ist. Das liegt daran, dass bind_all_filters die gefilterten Felder des explorativen Analysetools den Feldern in der nativen abgeleiteten Tabelle zuordnen muss. • Der Parameter explore_source kann den Unterparameter bind_all_filters oder bind_filters, aber nicht beides haben.	bind_all_filters: yes
column	Gibt eine Spalte an, die in explore_source enthalten sein soll. Hat 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. Hat 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 Entwicklungsmodus 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 auf die vollständige Erstellung nach jeder Änderung 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 zur Verwendung abgeleiteter Tabellen im Entwicklungsmodus finden Sie auf der Seite Abgeleitete Tabellen in Looker. Im Abschnitt Filter für den Entwicklungsmodus erstellen auf dieser Seite finden Sie ein Beispiel.	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. Setzen Sie in den eckigen Klammern den Feldnamen, der 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	Optional: Gibt das Zeilenlimit der Abfrage an.	limit: 10
sorts	Gibt optional eine Sortierung für diese explore_source an. Setzen Sie in den eckigen Klammern den Feldnamen, um die Sortierung vorzunehmen. Verwenden Sie dabei das Format view_name.field_name, gefolgt von : und asc oder desc, um anzugeben, ob das Feld in aufsteigender oder absteigender Reihenfolge sortiert werden soll. Sie können mehrere Felder sortieren, indem Sie mehrere Feldnamen und Keyword-Paare durch Kommas getrennt hinzufügen.	sorts: [products.brand: asc, products.name: asc]
timezone	Legt die Zeitzone für die Abfrage explore_source fest. Legen Sie für nicht persistente abgeleitete Tabellen die Zeitzone auf "query_timezone" fest, um automatisch die Zeitzone der aktuell ausgeführten Abfrage zu verwenden. Wenn keine Zeitzone angegeben ist, führt die Abfrage explore_source keine Konvertierung in die Zeitzone durch, sondern verwendet stattdessen die Zeitzone der Datenbank. Eine Liste der unterstützten Zeitzonen finden Sie auf der Seite zu den timezone-Werten. Die IDE vorschlagt automatisch den Zeitzonenwert, wenn Sie den Parameter timezone in der IDE eingeben. In der IDE wird auch eine Liste der unterstützten Zeitzonenwerte im Schnellhilfe-Bereich angezeigt.	timezone: "America/Los_Angeles"

Beispiele

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

Erstellen Sie eine user_order_facts-native abgeleitete Tabelle:

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 user_90_day_facts-native abgeleitete Tabelle 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 die Erstellung der nativen abgeleiteten Tabelle lange dauert. Dies kann zeitaufwendig sein, wenn Sie viele Änderungen im Entwicklungsmodus testen. 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 auf die letzten 90 Tage gefiltert werden, und einen filters-Parameter, mit dem die Daten zu den letzten zwei Jahren und zum Yucca Valley Airport gefiltert werden. Der Parameter dev_filters arbeitet in Verbindung mit dem Parameter filters, damit alle Filter auf die Entwicklungsversion der Tabelle angewendet werden. Wenn sowohl dev_filters als auch filters Filter für dieselbe Spalte angeben, hat 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 hat, kann die Entwicklungstabelle nicht als Produktionsversion verwendet werden, da die Entwicklungsversion ein abgekürztes Dataset hat. Ist dies der Fall, können Sie den Parameter dev_filters auskommentieren und die Tabelle im Entwicklungsmodus abfragen, nachdem Sie die Tabelle erstellt haben und bevor Sie die Änderungen bereitstellen. 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.

Hinweis: Die umgekehrte Situation ist wahr: Wenn Sie eine native abgeleitete Tabelle mit dem Parameter dev_filters haben und diese im Entwicklungsmodus abfragen, kann Looker die Produktionstabelle verwenden, um Ihre Abfrage für den Entwicklungsmodus zu beantworten. Dies gilt nur, wenn Sie die Definition der Tabelle ändern und dann die Tabelle im Entwicklungsmodus abfragen. Dann wird in Looker eine Entwicklungstabelle zur Beantwortung der Abfrage erstellt.

Filter an eine native abgeleitete Tabelle übergeben

Wenn Sie eine native abgeleitete Tabelle in einen „Erkunden“ einbeziehen, können Sie Laufzeitfilter aus der Funktion „Erkunden“ verwenden und auf die Abfrage der nativen abgeleiteten Tabelle anwenden. Dazu fügen Sie den Parameter bind_all_filters oder bind_filters in die explore_source der nativen abgeleiteten Tabelle ein.

Wenn Sie Laufzeitfilter von einem Explore an eine native abgeleitete Tabellen-Unterabfrage übergeben, muss sich der Laufzeitfilter in einer Ansicht befinden, die mit derselben Explore-Tabelle verknüpft ist. Da die native abgeleitete Tabelle außerdem zur Laufzeit neu generiert werden muss, um die Laufzeitfilter aus dem Tab „Erkunden“ einzubinden, kann die native abgeleitete Tabelle keine persistente abgeleitete Tabelle (PDT) sein.

bind_all_filters verwenden

Die einfachste Methode zum Übergeben von Filtern von einer Untersuchung an eine native abgeleitete Tabellenunterabfrage besteht darin, bind_all_filters: yes im Parameter explore_source der nativen abgeleiteten Tabelle anzugeben. Dadurch werden alle Laufzeitfilter des Typs „Erkunden“ an die Unterabfrage der nativen abgeleiteten Tabelle übergeben.

Eine native abgeleitete Tabelle mit bind_all_filters: yes muss mit derselben Abfrage verbunden werden, die im Parameter explore_source der nativen abgeleiteten Tabelle angegeben ist. Wenn Sie die native abgeleitete Tabelle in einer anderen Erkundung verwenden möchten, verwenden Sie stattdessen den Parameter bind_filters, wie in diesem Abschnitt beschrieben.

Hier ist die LookML 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 oben ist explore_source order_items. Hier sehen Sie die LookML für die order_items-Erkundungssitzung, mit der die native abgeleitete Tabelle mit der Funktion „Erkunden“ 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 dafür ist der Community-Artikel [Analytic Block] – Pivot by Top X – Introducing bind_all_filters: yes.

bind_filters verwenden

Der Unterparameter bind_filters von explore_source übergibt einen bestimmten Filter aus der Abfrageabfrage an die native abgeleitete Tabellenunterabfrage:

• to_field ist das Feld in der nativen abgeleiteten Tabelle, auf die der Filter angewendet wird. to_field muss ein Feld aus der zugrunde liegenden explore_source sein.
• from_field gibt das Feld in „Erkunden“ an, von dem der Filter abgerufen werden soll, wenn der Nutzer zur Laufzeit einen Filter angibt.

Während der Laufzeit werden alle Filter für from_field in der Funktion „Erkunden“ in der nativen abgeleiteten Tabellenabfrage an to_field übergeben.

Die folgende LookML-Tabelle zeigt eine native abgeleitete Tabelle mit bind_filters. Bei dieser Einrichtung wendet Looker jeden Filter an, der auf das Feld filtered_lookml_dt.filter_date im Feld „Erkunden“ angewendet wird, und wendet den Filter 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

Jede native abgeleitete Tabelle akzeptiert nur einen explore_source-Parameter. Die nachfolgenden explore_source-Parameter lösen keine LookML-Validierungsfehler aus, sondern überschreiben die vorherigen explore_source-Parameter.

Wenn Sie Spalten aus Feldern in verschiedenen Ansichten erstellen möchten, müssen Sie die verschiedenen Ansichten in derselben Ansicht miteinander kombinieren. Danach kannst du die Funktion „Entdecken“ für explore_source nutzen.

Verwenden Sie include-Anweisungen, um Referenzfelder zu aktivieren

Wenn Sie eine native abgeleitete Tabelle erstellen, müssen Sie die Datei enthalten, die die Definition von „Erkunden“ enthält. Die beste Methode hierfür ist, die Funktion „Erkunden“ in einer separaten Datei „Entdecken“ zu definieren, wie in der Dokumentation zum Erstellen von Dateien mit der Funktion „Erkunden“ beschrieben.

Wenn Sie eine separate „Erkunden“-Datei erstellen:

• Die Ansichtsdatei der nativen abgeleiteten Tabelle sollte die Datei „Erkunden“ enthalten. Beispiel:
  include: "/explores/order_items.explore.lkml"
• Die Datei „Entdecken“ sollte die erforderlichen Dateien enthalten. Beispiel:
  include: "/views/order_items.view.lkml"
include: "/views/users.view.lkml"
• Das Modell sollte die Datei „Erkunden“ enthalten. Beispiel:
  include: "/explores/order_items.explore.lkml"