Diese Seite bezieht sich auf den Parameter
explore_source
, der ein Unterparameter vonderived_table
ist.
explore_source
kann auch ein Unterparameter vontest
sein. Eine Beschreibung finden Sie auf der Dokumentationsseite für den Parametertest
.
Nutzung
Hierarchie
explore_source |
Standardwert
KeineAkzeptiert
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: { |
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 { |
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 { |
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: |
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 Parameterdev_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 Parameterdev_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 liegendenexplore_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"