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

explore_source

En esta página, se hace referencia al parámetro explore_source, que es un subparámetro de derived_table.

explore_source también puede ser un subparámetro de test, que se describe en la página de documentación del parámetro test.

Uso

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

Jerarquía

Ver archivo

view

derived_table

explore_source

Valor predeterminado

Ninguno

Acepta

Es el identificador de la exploración de la que se deriva la tabla derivada nativa, además de los subparámetros que definen la tabla derivada nativa.

Definición

Existen dos formas de crear una tabla derivada, que puedes usar como si fuera una tabla normal en tu base de datos: las tablas derivadas nativas, que se definen con parámetros de LookML, y las tablas derivadas basadas en SQL, que se definen con instrucciones de consulta en SQL.

El parámetro explore_source se usa para las tablas derivadas nativas. En este parámetro, defines qué columnas se incluirán en una tabla derivada nativa, qué filtros se aplicarán a la tabla derivada nativa, si se limitarán o ordenarán las filas de la tabla derivada nativa y si se convertirán los campos basados en el tiempo de la tabla derivada nativa a una zona horaria diferente.

Cómo definir 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 es la siguiente:

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

En la siguiente tabla, se proporciona información sobre cada parámetro que puedes usar para definir una tabla derivada nativa:

Nombre del parámetro	Descripción	Ejemplo
`bind_filters`	Pasa un filtro de la consulta de exploración a la subconsulta de la tabla derivada nativa. Para configurar este parámetro, usa el parámetro secundario `from_field` para especificar un campo definido en la vista de tabla derivada nativa o accesible en la Exploración a la que se une la tabla derivada nativa. En el tiempo de ejecución, cualquier filtro en el `from_field` de la exploración se pasará al `to_field` en la subconsulta de la tabla derivada nativa. Consulta la sección Usa `bind_filters` para ver un ejemplo. Con `bind_filters`, ten en cuenta lo siguiente: El filtro de tiempo de ejecución debe estar en una vista unida a la misma exploración 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: { to_field: users.created_date from_field: user_dt.filter_date }
`bind_all_filters`	Pasa todos los filtros de la consulta de exploración a la subconsulta de la tabla derivada nativa. Para configurar este parámetro, especifica `bind_all_filters: yes` en el `explore_source` de la tabla derivada nativa. Consulta la sección Usa `bind_filters` para ver un ejemplo. Con `bind_all_filters: yes`, ten en cuenta lo siguiente: El filtro de tiempo de ejecución debe estar en una vista unida a la misma exploración que la tabla derivada nativa. La tabla derivada nativa no se puede convertir en un PDT. La tabla derivada nativa solo se puede unir a 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 la Exploración a los campos de la tabla derivada nativa. El parámetro `explore_source` puede tener el parámetro secundario `bind_all_filters` o el parámetro secundario `bind_filters`, pero no ambos.	`bind_all_filters: yes`
`column`	Especifica una columna para incluir en `explore_source`. Tiene un parámetro secundario `field`.	column: cust_id { field: orders.customer_id }
`derived_column`	Especifica una columna en `explore_source` con una expresión en el espacio de nombres de las columnas internas. Las expresiones SQL de agregación no funcionarán aquí, ya que no hay agrupamiento de SQL en este paso. Las funciones analíticas de SQL pueden ser muy útiles en este parámetro. Tiene un parámetro secundario `sql`.	derived_column: average_order { sql: order_amount / item_qty ;; }
`dev_filters`	Se agregó en la versión 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 cree 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 tus 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 el modo de desarrollo y la sección Cómo crear filtros para el modo de desarrollo en esta página para ver 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 búsqueda de `explore_source`.	`expression_custom_filter: ${orders.status} = "pending" ;;`
`filters`	Agrega de forma opcional un filtro a una consulta de `explore_source`. Incluye el nombre del campo que se filtrará entre corchetes, con el formato `view_name.field_name`, seguido de `:` y los valores por 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`	Opcionalmente, especifica el límite de filas de la consulta.	`limit: 10`
`sorts`	De manera opcional, especifica una ordenación para este `explore_source`. Se debe incluir entre corchetes el nombre del campo por el que se ordenará, con el formato `view_name.field_name`, seguido de `:` y `asc` o `desc` para indicar si el campo se debe ordenar de forma ascendente o descendente. Puedes ordenar por varios campos agregando varios pares de nombres de campo y palabras clave separados por comas.	`sorts: [products.brand: asc, products.name: asc]`
`timezone`	Establece la zona horaria para la búsqueda de `explore_source`. En el caso de las tablas derivadas no persistentes, establece la zona horaria en `"query_timezone"` para usar automáticamente la zona horaria de la consulta que se está ejecutando. Si no se especifica una zona horaria, la consulta de `explore_source` no realizará ninguna conversión de zona horaria, sino que usará la zona horaria de la base de datos. Consulta la página de valores de `timezone` para obtener una lista de las zonas horarias admitidas. El IDE sugiere automáticamente el valor de la 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 derivadas nativas.

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

Cómo crear filtros para el modo de desarrollo

Hay situaciones en las que la tabla derivada nativa que creas tarda mucho en generarse, 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 incluyen un parámetro dev_filters que filtra los datos de los últimos 90 días y un parámetro filters que filtra los datos de los últimos 2 años y del aeropuerto de Yucca Valley. El parámetro dev_filters actúa en conjunto 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 tendrá 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 para el 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 que termines de desarrollar la tabla y antes de implementar los cambios, puedes comentar el parámetro dev_filters y, luego, consultar la tabla en el modo de desarrollo. Luego, Looker compilará una versión completa de la tabla que se puede usar para la producción cuando implementes los 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 también es verdadera: Si tienes una tabla derivada nativa con el parámetro dev_filters y la consultas en el modo de desarrollo, Looker puede usar la tabla de producción para responder tu consulta del modo de desarrollo. Esta afirmación es verdadera, a menos que cambies la definición de la tabla y, luego, la consultes en el modo de desarrollo, en cuyo caso Looker compilará una tabla de desarrollo para responder la consulta.

Cómo pasar filtros a una tabla derivada nativa

Cuando incluyes una tabla derivada nativa en una exploración, puedes tomar filtros de tiempo de ejecución de la exploración y aplicarlos a la consulta de la 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 del entorno de ejecución de una exploración a una subconsulta de tabla derivada nativa, el filtro del entorno de ejecución debe estar en una vista unida a la misma exploración que la tabla derivada nativa. Además, debido a que la tabla derivada nativa debe regenerarse en el tiempo de ejecución para incorporar los filtros de tiempo de ejecución de la exploración, no puede ser una tabla derivada persistente (PDT).

Usa `bind_all_filters`

La forma más sencilla 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 una exploración a la subconsulta de la tabla derivada nativa.

Se debe unir una tabla derivada nativa con bind_all_filters: yes al mismo Explorar que se especifica en el parámetro explore_source de la tabla derivada nativa. Si deseas usar la tabla derivada nativa en otra exploración, usa el parámetro bind_filters, como se describe en la sección Uso de bind_filters.

Aquí se muestra el LookML de 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, el explore_source es order_items. A continuación, se muestra el código LookML de la exploración order_items en la que se une la tabla derivada nativa 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, consulta la publicación de Comunidad [Bloque analítico] – Tabla dinámica por los X principales – Presentamos bind_all_filters: yes.

Usa `bind_filters`

El subparámetro bind_filters de explore_source pasa un filtro específico de la consulta de exploración a la subconsulta de la tabla derivada nativa:

El elemento to_field es el campo de la tabla derivada nativa al que se aplica el filtro. El to_field debe ser un campo del explore_source subyacente.
El elemento from_field especifica el campo de la exploración del que se obtendrá el filtro, si el usuario especifica un filtro en el entorno de ejecución.

En el tiempo de ejecución, cualquier filtro en el from_field de la exploración se pasará al to_field en la subconsulta de la tabla derivada nativa.

El siguiente código LookML muestra una tabla derivada nativa con bind_filters. Con esta configuración, Looker tomará cualquier filtro que se aplique al campo filtered_lookml_dt.filter_date en la exploración 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 une las diferentes vistas en la misma exploración. Luego, usa esa exploración para explore_source.

Usa instrucciones `include` para habilitar la referencia a campos

Cuando creas una tabla derivada nativa, debes incluir el archivo que contiene la definición de la exploración. La mejor manera de hacerlo es definir la exploración en un archivo de exploración independiente, como se describe en la documentación para Crear archivos de exploración.

Si creas un archivo de exploración independiente, haz lo siguiente:

El archivo de vista de la tabla derivada nativa debe incluir el archivo del Explorador. Por ejemplo:
- include: "/explores/order_items.explore.lkml"
El archivo de Explore 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 la exploración. Por ejemplo:
- include: "/explores/order_items.explore.lkml"