explorar_origem

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

O explore_source também pode ser um subparâmetro de test, descrito na página de documentação do parâmetro test.

Uso

Dados do ISP
Hierarquia
view
derived_table
explore_source
Valor padrão
Nenhuma

Aceita
O identificador de Explorar do qual 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 uma tabela normal no banco de dados: tabelas derivadas nativas, definidas usando parâmetros LookML, e tabelas derivadas baseadas em SQL, definidas com instruções de consulta SQL.

O parâmetro explore_source é usado para tabelas derivadas nativas. Neste parâmetro, você define quais colunas serão incluídas em uma tabela derivada nativa, todos os filtros a serem aplicados à tabela derivada nativa, se quer limitar ou classificar as linhas da tabela derivada nativa e se quer converter os campos baseados em tempo da tabela derivada em um fuso horário diferente.

DICA: a maneira mais fácil de criar uma tabela derivada nativa é usar um Explore para criar a consulta desejada e selecionar a opção Get LookML em Explore. O Looker vai gerar a tabela derivada LookML para a consulta, que pode ser copiada para um arquivo de visualização do seu projeto LookML. Consulte a página Como criar tabelas derivadas nativas para mais detalhes.

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 é mostrada abaixo, seguida de mais informações 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"
}

Em que:

Nome do parâmetro Descrição Exemplo
bind_filters Transmite um filtro da consulta "Explorar" para a subconsulta da tabela derivada nativa. Para configurar isso, use o subparâmetro from_field para especificar um campo definido na visualização da tabela derivada nativa ou acessível em "Explorar" a que a tabela derivada nativa é mesclada. Durante a execução, todos os filtros em from_field na guia "Explorar" serão transmitidos para o to_field na subconsulta da tabela derivada nativa. Consulte esta seção para ver um exemplo.
Com bind_filters, observe o seguinte:
• O filtro de ambiente de execução precisa estar em uma visualização mesclada à mesma tabela que a tabela derivada nativa.
• Não é possível transformar a tabela derivada nativa 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 "Explorar" para a subconsulta da tabela derivada nativa. Para fazer essa configuração, especifique bind_all_filters: yes no explore_source da tabela derivada nativa. Consulte esta seção para ver um exemplo.
Com bind_all_filters: yes, observe o seguinte:
• O filtro de ambiente de execução precisa estar em uma visualização mesclada à mesma tabela que a tabela derivada nativa.
• A tabela derivada nativa não pode ser transformada em uma PDT.
• A tabela derivada nativa pode ser mesclada apenas ao recurso "Explorar" especificado no parâmetro explore_source da tabela nativa. Isso ocorre porque bind_all_filters precisa mapear os campos filtrados da guia Explorar 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 a ser incluída 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 porque não há agrupamento SQL nesta etapa. As funções da 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 ADDED 21.12 Especifica filtros que o Looker aplica somente a versões de desenvolvimento da tabela derivada. Isso é útil para desenvolvedores 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 LookML possa iterar e testar a tabela sem aguardar a criação da tabela completa após cada mudança. O Looker aplica o dev_filters apenas às versões de desenvolvimento da tabela derivada, não à versão de produção da tabela que é consultada pelos seus 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 Como opção, especifica uma expressão de filtro personalizada em uma consulta explore_source. expression_custom_filter:
  ${orders.status} = "pending" ;;
filters Como opção, adiciona um filtro a uma consulta explore_source. Coloque o nome do campo entre colchetes. Use o formato view_name.field_name, seguido por : e os valores em que o campo será filtrado. Os filtros são adicionados à cláusula WHERE do SQL gerado pela tabela derivada nativa. filters: [products.department: "sweaters"]
limit Opcional: especifica o limite da linha da consulta. limit: 10
sorts Opcional: especifica uma classificação para esse explore_source. Coloque o nome do campo entre colchetes. Use o formato view_name.field_name, seguido de : e asc ou desc para indicar se ele precisa ser classificado em ordem crescente ou decrescente. É possível classificar em vários campos adicionando vários pares de nomes de campos e palavras-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 persistentes, defina o fuso horário como "query_timezone" para usar automaticamente o fuso da consulta em execução no momento. Se um fuso horário não for especificado, a consulta explore_source não executará nenhuma conversão de fuso horário, mas usará o fuso horário do banco de dados. Consulte a página de valores de timezone para ver uma lista com os fusos horários aceitos.

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

Examples

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

Crie uma tabela derivada nativa de 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 caso você esteja testando muitas mudanças no modo de desenvolvimento. Nesses 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 {}
    }
  }
...
}

Esse exemplo inclui um parâmetro dev_filters que filtra os dados para os últimos 90 dias e um parâmetro filters que filtra os dados para os últimos dois anos e para o Aeroporto de Yucca Valley. O parâmetro dev_filters atua 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, a dev_filters terá precedência para a 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 Vales de Yucca.

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, porque a versão de desenvolvimento tem um conjunto de dados abreviado. Se esse for o caso, depois de concluir o desenvolvimento da 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 criará uma versão completa da tabela que poderá ser usada na produção quando você implantar as alterações. Consulte a página de documentação Tabelas derivadas no Looker para mais detalhes sobre o uso de tabelas de desenvolvimento na produção.

A situação inversa é verdadeira: se você tiver uma tabela derivada nativa com o parâmetro dev_filters e consultar no modo de desenvolvimento, o Looker poderá usar a tabela de produção para responder à consulta do modo de desenvolvimento. Isso deve ser feito a menos que você mude a definição da tabela e a consulte no modo de desenvolvimento. Nesse momento, o Looker criará uma tabela de desenvolvimento para responder à consulta.

Como transmitir filtros para uma tabela derivada nativa

Ao incluir uma tabela derivada nativa em um recurso Explorar, é possível usar filtros de tempo de execução em Explorar e aplicá-los à consulta de tabela derivada nativa. Para 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 exploração para uma subconsulta de tabela derivada nativa, o filtro de tempo de execução precisa estar em uma visualização mesclada à mesma tabela que a tabela derivada nativa. Além disso, como a tabela derivada nativa precisa ser gerada novamente durante a execução para incorporar os filtros de ambiente de execução na guia Explorar, a tabela derivada nativa não pode ser uma tabela derivada persistente (PDT, na sigla em inglês).

Como usar o bind_all_filters

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

Uma tabela derivada nativa com bind_all_filters: yes precisa ser unida ao mesmo recurso Explorar que é especificado no parâmetro explore_source da tabela derivada nativa. Se você quiser usar a tabela derivada nativa em uma exploração diferente, use o parâmetro bind_filters, conforme descrito nesta seção.

Veja 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 acima, o explore_source é order_items. Este é o LookML de order_items Explore onde a tabela derivada nativa é mesclada em Explorar:

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 o artigo da comunidade [Analytic Block] – Pivot by Top X – Introdução bind_all_filters: yes.

Como usar o bind_filters

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

  • to_field é o campo na tabela derivada nativa em que o filtro é aplicado. O to_field precisa ser um campo do explore_source subjacente.
  • O from_field especifica o campo em "Explorar" para acessar o filtro se o usuário especificar um durante a execução.

Durante a execução, todos os filtros em from_field na guia "Explorar" serão transmitidos para o to_field na subconsulta da tabela derivada nativa.

O LookML abaixo mostra uma tabela derivada nativa com bind_filters. Com essa configuração, o Looker usará qualquer filtro aplicado ao campo filtered_lookml_dt.filter_date em "Explorar" e o 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
    . . .
    }
  }
}

Considerações

Use 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 várias visualizações, primeiro reúna cada uma na mesma guia "Explorar". Em seguida, use a opção Explorar para explore_source.

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

Ao criar uma tabela derivada nativa, você precisa incluir o arquivo que contém a definição de Explorar. A melhor maneira de fazer isso é definir a exploração em um arquivo separado "Explorar", conforme descrito na documentação de Como criar arquivos de exploração.

Se você criar um arquivo "Explorar" separado:

  • O arquivo de visualização da tabela derivada nativa precisa incluir o arquivo "Explorar". Por exemplo:
    include: "/explores/order_items.explore.lkml"
  • O arquivo "Explorar" 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 "Explorar". Por exemplo:
    include: "/explores/order_items.explore.lkml"