En esta página, se hace referencia al parámetro
explore_sourceque es un subparámetro dederived_table.
explore_sourcetambién puede ser un subparámetro detest, que se describe en la página de documentación del parámetrotest.
Uso
|
Jerarquía
explore_source |
Valor predeterminado
NingunaAcepta
El identificador de Explorar de la tabla derivada nativa, además de subparámetros que definen la tabla derivada nativa.
|
Definición
Hay dos maneras de crear una tabla derivada, que puede usar como si fuera una tabla normal en su base de datos: tablas derivadas nativas, que se definen mediante parámetros de LookML y tablas derivadas basadas en SQL, que se definen mediante instrucciones de consulta de SQL.
El parámetro explore_source se usa para tablas derivadas nativas. En este parámetro, usted define qué columnas se incluirán en una tabla derivada nativa, cualquier filtro que se aplique a la tabla derivada nativa, si se limitará u ordenará las filas de la tabla derivada nativa y si se convertirán los campos basados en el tiempo de la tabla derivada nativa en una zona horaria diferente.
SUGERENCIA: La manera más fácil de crear una tabla derivada nativa es mediante el uso de Explorar para crear la consulta que desea y, luego, seleccione la opción Obtener LookML en Explorar. Looker generará la tabla derivada LookML para la consulta, que puede copiar en un archivo de vista de su proyecto de LookML. Consulta la página de documentación Crea tablas derivadas nativas para obtener más información.
Define una tabla derivada nativa
Puedes usar una variedad de parámetros en una tabla derivada nativa, muchos de los cuales son opcionales. La sintaxis para definir una tabla derivada nativa se muestra a continuación, seguida de información adicional sobre cada parámetro.
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"
}
Aquí:
| Nombre del parámetro | Descripción | Ejemplo |
|---|---|---|
bind_filters |
Pasa un filtro de la consulta Explore a la subconsulta de la tabla derivada nativa. Para configurar esta función, usa el subparámetro from_field a fin de especificar un campo definido en la vista de tabla derivada nativa o accesible en la pestaña Explorar a la que se une la tabla derivada nativa. En el entorno de ejecución, los filtros de from_field en Explorar se pasarán a to_field en la subconsulta nativa de tabla derivada. Consulta esta sección para ver un ejemplo.
Con bind_filters, ten en cuenta lo siguiente: • El filtro del entorno de ejecución debe estar en una vista unida a la misma Explorar que la tabla derivada nativa. • La tabla derivada nativa no se puede convertir en una tabla derivada persistente (PDT). • El parámetro explore_source puede tener el subparámetro bind_all_filters o el subparámetro bind_filters, pero no ambos.
|
bind_filters: { |
bind_all_filters |
Pasa todos los filtros de la consulta Explorar a la subconsulta de la tabla derivada nativa. Para configurar esto, especifica bind_all_filters: yes en el explore_source de la tabla derivada nativa. Consulta esta sección para ver un ejemplo.
Con bind_all_filters: yes, ten en cuenta lo siguiente: • El filtro del entorno de ejecución debe estar en una vista unida a la misma Explorar que la tabla derivada nativa. • La tabla derivada nativa no se puede realizar en un PDT. • La tabla derivada nativa se puede unir solo en la exploración especificada en el parámetro explore_source de la tabla derivada nativa. Esto se debe a que bind_all_filters necesita asignar los campos filtrados de Explorar a los campos de la tabla derivada nativa.
• El parámetro explore_source puede tener el subparámetro bind_all_filters o el subparámetro bind_filters, pero no ambos.
|
bind_all_filters: yes
|
column |
Especifica una columna para incluir en explore_source. Tiene un subparámetro field. |
column: cust_id { |
derived_column |
Especifica una columna en el explore_source con una expresión en el espacio de nombres de las columnas internas. Las expresiones de SQL agregadas no funcionarán aquí, ya que no hay agrupación de SQL en este paso. Las funciones analíticas de SQL pueden ser muy útiles en este parámetro. Tiene un subparámetro sql. |
derived_column: average_order { |
dev_filters |
ADDED 21.12
Especifica los filtros que Looker aplica solo a las versiones de desarrollo de la tabla derivada. Esto es útil para los desarrolladores de LookML cuando prueban tablas derivadas en el modo de desarrollo. El parámetro dev_filters permite que Looker compile versiones más pequeñas y filtradas de la tabla para que un desarrollador de LookML pueda iterar y probar la tabla sin esperar a que se compile la tabla completa después de cada cambio. Looker aplica dev_filters solo a las versiones de desarrollo de la tabla derivada, no a la versión de producción de la tabla que consultan los usuarios. Consulta la página de documentación Tablas derivadas en Looker para obtener más información sobre cómo trabajar con tablas derivadas en modo de desarrollo y la sección Crea filtros para el modo de desarrollo en esta página a fin de obtener un ejemplo. |
dev_filters: [orders.created_date: "90 days", orders.products: "sweaters"] |
expression_custom_filter |
De manera opcional, especifica una expresión de filtro personalizada en una consulta explore_source. |
expression_custom_filter: |
filters |
De forma opcional, agrega un filtro a una consulta explore_source. Entre corchetes, incluye el nombre del campo para filtrar, con el formato view_name.field_name, seguido de : y los valores en los que se debe filtrar el campo. Los filtros se agregan a la cláusula WHERE del SQL generado por la tabla derivada nativa. |
filters: [products.department: "sweaters"] |
limit |
De manera opcional, especifica el límite de filas de la consulta. | limit: 10
|
sorts |
De manera opcional, especifica un orden para este explore_source. Entre corchetes, incluye el nombre del campo para ordenar, mediante el formato view_name.field_name, seguido de : y asc o desc a fin de indicar si el campo debe ordenarse de forma ascendente o descendente. Para ordenar los datos en varios campos, agregue varios pares de nombre de campo y pares de palabras clave separados por comas. |
sorts: [products.brand: asc, products.name: asc] |
timezone |
Configura la zona horaria para la consulta explore_source. En las tablas derivadas no persistentes, establece la zona horaria en "query_timezone" para usar de forma automática la zona horaria de la consulta en ejecución. Si no se especifica una zona horaria, la consulta explore_source no realizará ninguna conversión de zona horaria. En su lugar, se usará la zona horaria de la base de datos. Consulta la página de valores timezone para obtener una lista de las zonas horarias compatibles.El IDE sugiere automáticamente el valor de zona horaria cuando escribes el parámetro timezone en el IDE. El IDE también muestra la lista de valores de zona horaria admitidos en el panel de ayuda rápida. |
timezone: "America/Los_Angeles" |
Ejemplos
Las siguientes definiciones proporcionan ejemplos básicos de tablas nativas derivadas.
Crea una tabla derivada nativa 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
}
}
Puedes agregar filtros para crear una tabla derivada 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
}
}
Crear filtros para el modo de desarrollo
Hay situaciones en las que la tabla derivada nativa que está creando tarda mucho tiempo, lo que puede llevar mucho tiempo si pruebas muchos cambios en el modo de desarrollo. En estos casos, puedes usar dev_filters para crear versiones de desarrollo más pequeñas de una tabla derivada 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 {}
}
}
...
}
En este ejemplo, se incluye un parámetro dev_filters que filtra los datos para los últimos 90 días y un parámetro filters que filtra los datos para los últimos 2 años y al aeropuerto Yucca Valley. El parámetro dev_filters actúa junto con el parámetro filters para que todos los filtros se apliquen a la versión de desarrollo de la tabla. Si dev_filters y filters especifican filtros para la misma columna, dev_filters tiene prioridad para la versión de desarrollo de la tabla. En este ejemplo, la versión de desarrollo de la tabla filtrará los datos de los últimos 90 días del aeropuerto de Yucca Valley.
Si una tabla derivada nativa tiene el parámetro
dev_filters, la tabla de desarrollo no se puede usar como la versión de producción, ya que la versión de desarrollo tiene un conjunto de datos abreviado. Si este es el caso, después de terminar de desarrollar la tabla y antes de implementar los cambios, puedes comentar el parámetrodev_filtersy, luego, consultar la tabla en modo de desarrollo. Looker compilará una versión completa de la tabla que podrá usar para la producción cuando implemente sus cambios. Consulta la página de documentación Tablas derivadas en Looker para obtener más detalles sobre el uso de tablas de desarrollo en producción.
Ten en cuenta que la situación inversa es verdadera: si tienes una tabla derivada nativa con el parámetrodev_filtersy la consultas en modo de desarrollo, Looker puede usar la tabla de producción para responder tu consulta del modo de desarrollo. Esto es así a menos que cambie la definición de la tabla y luego consulte la tabla en modo de desarrollo, momento en el que Looker compilará una tabla de desarrollo para responder la consulta.
Cómo pasar filtros a una tabla derivada nativa
Cuando incluye una tabla derivada nativa en Explorar, puede tomar filtros de entorno de ejecución de esa herramienta y aplicarlos a la consulta de tabla derivada nativa. Para ello, agrega el parámetro bind_all_filters o bind_filters al explore_source de la tabla derivada nativa.
Cuando se pasan filtros de tiempo de ejecución de Explorar a una subconsulta de una tabla derivada nativa, el filtro del entorno de ejecución debe estar en una vista unida a la misma Explorar que la tabla derivada nativa. Además, debido a que la tabla derivada nativa debe regenerarse en el entorno de ejecución para incorporar los filtros del entorno de ejecución de Explorar, la tabla derivada nativa no puede ser una tabla derivada persistente (PDT).
Usa bind_all_filters
La forma más fácil de pasar filtros de una exploración a una subconsulta de tabla derivada nativa es especificar bind_all_filters: yes en el parámetro explore_source de la tabla derivada nativa. Esto pasará todos los filtros del entorno de ejecución de Explorar a la subconsulta nativa de tabla derivada.
Una tabla derivada nativa con bind_all_filters: yes debe unirse a la misma exploración que se especifica en el parámetro explore_source de la tabla derivada nativa. Si quieres usar la tabla derivada nativa en otro Explorar, usa el parámetro bind_filters, como se describe en esta sección.
A continuación, se muestra la estructura de LookML para una tabla derivada nativa 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} ;;
}
}
En la vista de la tabla derivada nativa anterior, la explore_source es order_items. Este es el LookML para la exploración order_items en el que la tabla derivada nativa se une a la exploración:
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} ;;
}
}
Para ver este ejemplo en acción, consulte el artículo [Analytic Block] – Pivot by Top X – Presentación de bind_all_filters: yes Comunidad.
Usa bind_filters
El subparámetro bind_filters de explore_source pasa un filtro específico de la consulta Explorar a la subconsulta nativa de tabla derivada:
to_fieldes el campo en la tabla derivada nativa a la que se aplica el filtro.to_fielddebe ser un campo delexplore_sourcesubyacente.from_fieldespecifica el campo en Explorar del que se obtendrá el filtro, si el usuario especifica un filtro en el tiempo de ejecución.
En el entorno de ejecución, los filtros de from_field en Explorar se pasarán a to_field en la subconsulta nativa de tabla derivada.
La siguiente imagen de LookML muestra una tabla derivada nativa con bind_filters. Con esta configuración, Looker tomará cualquier filtro aplicado al campo filtered_lookml_dt.filter_date en Explorar y lo aplicará al campo users.created_date en la tabla derivada nativa.
derived_table: {
explore_source: order_items {
bind_filters: {
to_field: users.created_date
from_field: filtered_lookml_dt.filter_date
. . .
}
}
}
Aspectos para tener en cuenta
Usa solo un parámetro explore_source
Cada tabla derivada nativa acepta solo un parámetro explore_source. Los parámetros explore_source posteriores no generarán errores de validación de LookML, pero anularán los parámetros explore_source anteriores.
Para crear columnas a partir de campos en diferentes vistas, primero una las diferentes vistas en la misma exploración. Luego, usa esa pestaña para explore_source.
Usa declaraciones include para habilitar los campos de referencia
Cuando creas una tabla derivada nativa, debes incluir el archivo que contiene la definición de Explorar. La mejor manera de hacerlo es definir la función Explorar en un archivo de Explorar independiente, como se describe en la documentación de cómo crear archivos de Explorar.
Si creas un archivo de Explorar separado, haz lo siguiente:
- El archivo de vista de la tabla derivada nativa debe incluir el archivo de Explorar. Por ejemplo:
include: "/explores/order_items.explore.lkml" - El archivo de Explorar debe incluir los archivos de vista que necesita. Por ejemplo:
include: "/views/order_items.view.lkml"
include: "/views/users.view.lkml" - El modelo debe incluir el archivo de Explorar. Por ejemplo:
include: "/explores/order_items.explore.lkml"