explore_source

Esta página se refere ao parâmetro explore_source, que é um subparâmetro de derived_table.

explore_source também pode ser um subparâmetro de test, descrito na página de documentação do 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"
  }
}
Hierarquia
view
derived_table
explore_source
Valor padrão
Nenhum

Aceita
O identificador da Análise de que a tabela derivada nativa é derivada, além de subparâmetros que definem a tabela derivada nativa.

Definição

Há duas maneiras de criar uma tabela derivada, que pode ser usada como se fosse uma tabela normal no banco de dados: tabelas derivadas nativas, definidas usando parâmetros da LookML, e tabelas derivadas baseadas em SQL, definidas usando instruções de consulta SQL.

O parâmetro explore_source é usado para tabelas derivadas nativas. Nesse parâmetro, você define quais colunas serão incluídas em uma tabela derivada nativa, os filtros que serão aplicados a ela, se as linhas serão limitadas ou classificadas e se os campos baseados em tempo serão convertidos para outro fuso horário.

Como definir uma tabela derivada nativa

É possível usar vários parâmetros em uma tabela derivada nativa, muitos deles opcionais. A sintaxe para definir uma tabela derivada nativa é a seguinte:

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

A tabela a seguir fornece informações sobre cada parâmetro que você pode usar para definir uma tabela derivada nativa:

Nome do parâmetro Descrição Exemplo
bind_filters Transmite um filtro da consulta da Análise para a subconsulta da tabela derivada nativa. Para configurar esse parâmetro, use o subparâmetro from_field para especificar um campo definido na visualização em tabela derivada nativa ou acessível na Análise a que a tabela derivada nativa está associada. No tempo de execução, todos os filtros no from_field da Análise serão transmitidos para o to_field na subconsulta da tabela derivada nativa. Consulte a seção Como usar bind_filters para um exemplo.

Com o bind_filters, observe o seguinte:
  • O filtro de tempo de execução precisa estar em uma visualização unida à mesma Análise que a tabela derivada nativa.
  • A tabela derivada nativa não pode ser transformada em uma tabela derivada persistente (PDT).

• O parâmetro explore_source pode ter o subparâmetro bind_all_filters ou o subparâmetro bind_filters, mas não ambos. 
bind_filters: {
  to_field: users.created_date
  from_field: user_dt.filter_date
}
bind_all_filters Transmite todos os filtros da consulta da Análise para a subconsulta da tabela derivada nativa. Para configurar esse parâmetro, especifique bind_all_filters: yes no explore_source da tabela derivada nativa. Consulte a seção Como usar bind_filters para um exemplo.

Com o bind_all_filters: yes, observe o seguinte:
  • O filtro de tempo de execução precisa estar em uma visualização unida à mesma Análise que a tabela derivada nativa.
  • A tabela derivada nativa não pode ser transformada em uma PDT.
  • A tabela derivada nativa só pode ser unida à Análise especificada no parâmetro explore_source da tabela derivada nativa. Isso ocorre porque bind_all_filters precisa mapear os campos filtrados da análise detalhada para os campos na tabela derivada nativa.
  • O parâmetro explore_source pode ter o subparâmetro bind_all_filters ou o subparâmetro bind_filters, mas não ambos.
 bind_all_filters: yes
column Especifica uma coluna para incluir no explore_source. Tem um subparâmetro field. 
column: cust_id {
  field: orders.customer_id
}
derived_column Especifica uma coluna no explore_source com uma expressão no namespace das colunas internas. As expressões SQL agregadas não funcionam aqui, já que não há agrupamento SQL nesta etapa. As funções de janela SQL podem ser muito úteis nesse parâmetro. Tem um subparâmetro sql. 
derived_column: average_order {
  sql: order_amount / item_qty ;;
}
dev_filters Adicionado na versão 21.12 Especifica filtros que o Looker aplica apenas às versões de desenvolvimento da tabela derivada. Isso é útil para desenvolvedores do LookML quando eles testam tabelas derivadas no Modo de desenvolvimento. O parâmetro dev_filters permite que o Looker crie versões menores e filtradas da tabela para que um desenvolvedor do LookML possa iterar e testar a tabela sem esperar que ela seja criada por completo após cada mudança. O Looker aplica o dev_filters somente às versões de desenvolvimento da tabela derivada, não à versão de produção da tabela consultada pelos usuários. Consulte a página de documentação Tabelas derivadas no Looker para mais informações sobre como trabalhar com tabelas derivadas no modo de desenvolvimento e a seção Como criar filtros para o modo de desenvolvimento nesta página para ver um exemplo. dev_filters: [orders.created_date: "90 days", orders.products: "sweaters"]
expression_custom_filter Especifica opcionalmente uma expressão de filtro personalizada em uma consulta explore_source. expression_custom_filter: ${orders.status} = "pending" ;;
filters Adiciona um filtro a uma consulta explore_source (opcional). Coloque entre colchetes e inclua o nome do campo a ser filtrado, usando o formato view_name.field_name, seguido por : e os valores em que o campo deve ser filtrado. Os filtros são adicionados à cláusula WHERE do SQL gerado pela tabela derivada nativa. filters: [products.department: "sweaters"]
limit Especifica o limite de linhas da consulta (opcional). limit: 10
sorts Especifica uma classificação para este explore_source (opcional). Coloque entre colchetes e inclua o nome do campo para classificação, usando o formato view_name.field_name, seguido por : e asc ou desc para indicar se o campo deve ser classificado em ordem crescente ou decrescente. É possível classificar por vários campos adicionando vários pares de nome de campo e palavra-chave separados por vírgulas. sorts: [products.brand: asc, products.name: asc]
timezone Define o fuso horário da consulta explore_source. Para tabelas derivadas não permanentes, defina o fuso horário como "query_timezone" para usar automaticamente o fuso horário da consulta em execução. Se um fuso horário não for especificado, a consulta explore_source não vai realizar nenhuma conversão de fuso horário, mas vai usar o fuso horário do banco de dados. Consulte a página de valores de timezone para ver uma lista dos fusos horários aceitos.

O ambiente de desenvolvimento integrado sugere automaticamente o valor do fuso horário quando você digita o parâmetro timezone no ambiente. O IDE também mostra a lista de valores de fuso horário compatíveis no painel de Ajuda rápida.		 timezone: "America/Los_Angeles"

Exemplos

As definições a seguir fornecem exemplos básicos de tabelas derivadas nativas.

Crie uma tabela 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
  }
}

É possível adicionar filtros para criar uma tabela 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
  }
}

Como criar filtros para o modo de desenvolvimento

Há situações em que a tabela derivada nativa que você está criando leva muito tempo para ser gerada, o que pode ser demorado se você estiver testando muitas mudanças no Modo de Desenvolvimento. Para esses casos, use dev_filters para criar versões de desenvolvimento menores de uma tabela 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 {}
    }
  }
...
}

Este exemplo inclui um parâmetro dev_filters que filtra os dados dos últimos 90 dias e um parâmetro filters que filtra os dados dos últimos dois anos e do Aeroporto de Yucca Valley. O parâmetro dev_filters funciona em conjunto com o parâmetro filters para que todos os filtros sejam aplicados à versão de desenvolvimento da tabela. Se dev_filters e filters especificarem filtros para a mesma coluna, dev_filters terá precedência na versão de desenvolvimento da tabela. Neste exemplo, a versão de desenvolvimento da tabela vai filtrar os dados dos últimos 90 dias para o Aeroporto de Yucca Valley.

Se uma tabela derivada nativa tiver o parâmetro dev_filters, a tabela de desenvolvimento não poderá ser usada como a versão de produção, já que a versão de desenvolvimento tem um conjunto de dados abreviado. Se for esse o caso, depois de terminar de desenvolver a tabela e antes de implantar as mudanças, comente o parâmetro dev_filters e consulte a tabela no modo de desenvolvimento. Em seguida, o Looker vai criar uma versão completa da tabela que pode ser usada para produção quando você implanta as mudanças. Consulte a página de documentação Tabelas derivadas no Looker para mais detalhes sobre o uso de tabelas de desenvolvimento em produção.

A situação inversa também é verdadeira: se você tiver uma tabela derivada nativa com o parâmetro dev_filters e fizer uma consulta no modo de desenvolvimento, o Looker poderá usar a tabela de produção para responder à consulta do modo de desenvolvimento. Essa declaração é verdadeira, a menos que você mude a definição da tabela e depois consulte a tabela no modo de desenvolvimento. Nesse caso, o Looker vai criar uma tabela de desenvolvimento para responder à consulta.

Como transmitir filtros para uma tabela derivada nativa

Ao incluir uma tabela derivada nativa em uma Análise, é possível usar filtros de tempo de execução da Análise e aplicá-los à consulta da tabela derivada nativa. Para fazer isso, adicione o parâmetro bind_all_filters ou bind_filters ao explore_source da tabela derivada nativa.

Ao transmitir filtros de tempo de execução de uma Análise para uma subconsulta de tabela derivada nativa, o filtro de tempo de execução precisa estar em uma visualização unida à mesma Análise que a tabela derivada nativa. Além disso, como a tabela derivada nativa precisa ser regenerada no tempo de execução para incorporar os filtros de tempo de execução da Análise, ela não pode ser uma tabela derivada persistente (TDP).

Como usar o bind_all_filters

A maneira mais fácil de transmitir filtros de uma análise para uma subconsulta de tabela derivada nativa é especificar bind_all_filters: yes no parâmetro explore_source da tabela derivada nativa. Isso vai transmitir todos os filtros de tempo de execução de uma Análise para a subconsulta da tabela derivada nativa.

Uma tabela derivada nativa com bind_all_filters: yes precisa ser unida à mesma Análise especificada no parâmetro explore_source da tabela derivada nativa. Se você quiser usar a tabela derivada nativa em outra Análise, use o parâmetro bind_filters, conforme descrito na seção Como usar bind_filters.

Este é o LookML de uma tabela derivada nativa com 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} ;;
  }
}

Na visualização da tabela derivada nativa, o explore_source é order_items. A seguir, confira o LookML da Análise order_items em que a tabela derivada nativa é unida à Análise:

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 esse exemplo em ação, confira a postagem na comunidade [Bloco de análise] – Pivô pelos X principais – Apresentação do bind_all_filters: yes.

Como usar o bind_filters

O subparâmetro bind_filters de explore_source transmite um filtro específico da consulta da Análise para a subconsulta da tabela derivada nativa:

  • O to_field é o campo na tabela derivada nativa a que o filtro é aplicado. O to_field precisa ser um campo do explore_source subjacente.
  • O from_field especifica o campo na Análise de onde o filtro será extraído, caso o usuário especifique um filtro no tempo de execução.

No tempo de execução, todos os filtros no from_field da Análise serão transmitidos para o to_field na subconsulta da tabela derivada nativa.

O LookML a seguir mostra uma tabela derivada nativa com bind_filters. Com essa configuração, o Looker vai usar qualquer filtro aplicado ao campo filtered_lookml_dt.filter_date na Análise e aplicar ao campo users.created_date na tabela derivada nativa.

derived_table: {
  explore_source: order_items {
    bind_filters: {
      to_field: users.created_date
      from_field: filtered_lookml_dt.filter_date
    . . .
    }
  }
}

Informações importantes

Usar apenas um parâmetro explore_source

Cada tabela derivada nativa aceita apenas um parâmetro explore_source. Os parâmetros explore_source subsequentes não vão gerar erros de validação do LookML, mas vão substituir os parâmetros explore_source anteriores.

Para criar colunas com base em campos de visualizações diferentes, primeiro junte as visualizações na mesma análise. Em seguida, use essa análise detalhada para explore_source.

Use instruções include para ativar campos de referência

Ao criar uma tabela derivada nativa, é necessário incluir o arquivo que contém a definição da análise. A melhor maneira de fazer isso é definir a Análise em um arquivo separado, conforme descrito na documentação sobre Como criar arquivos de Análise.

Se você criar um arquivo de análise detalhada separado:

  • O arquivo de visualização da tabela derivada nativa precisa incluir o arquivo da análise detalhada. Por exemplo:
    • include: "/explores/order_items.explore.lkml"
  • O arquivo da análise detalhada precisa incluir os arquivos de visualização necessários. Por exemplo:
    • include: "/views/order_items.view.lkml"
    • include: "/views/users.view.lkml"
  • O modelo precisa incluir o arquivo da Análise. Por exemplo:
    • include: "/explores/order_items.explore.lkml"