de (para junções)

Esta página se refere ao parâmetro from, que faz parte de uma junção.

from também pode ser usado como parte de uma análise detalhada, conforme descrito na página de documentação do parâmetro from (para análises detalhadas).

Uso


explore: view_name {
  join: join_name {
    from: view_name_2
  }
}
Hierarquia
from
Valor padrão
Uma visualização com o mesmo nome da junção

Aceita
O nome de uma visualização atual

Definição

from especifica o view a ser usado em uma junção. Se from for omitido, o Looker vai presumir que o nome da visualização subjacente é o mesmo que o nome da junção.

Normalmente, from é usado apenas se você quer que a junção e os campos dela tenham um nome diferente da visualização subjacente. Para deixar isso mais claro, considere um exemplo em que uma dimensão chamada order_value foi criada em uma visualização chamada underlying_view:

  • Normalmente, esse campo aparece como VALOR DO PEDIDO DA VISÃO SUBJACENTE na interface da Análise e é referenciado em LookML com ${underlying_view.order_value}.
  • Se a LookML na seção Uso fosse aplicada a este exemplo, o campo apareceria como NOVO NOME DO ALIAS Valor do pedido e seria referenciado como ${new_alias_name.order_value}.

Essa técnica é particularmente útil quando a mesma visualização precisa ser unida a uma análise detalhada de várias maneiras diferentes.

Exemplos

Junte a visualização person à análise order, mas chame-a de customer:

explore: order {
  join: customer {
    from: person
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Junte a visualização person à Análise order duas vezes: uma como customer e outra como representative:

explore: order {
  join: customer {
    from: person
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
  join: representative {
    from: person
    sql_on: ${order.representative_id} = ${representative.id} ;;
  }
}

Informações importantes

from muda a forma como os campos são referenciados em uma análise detalhada

Como observado anteriormente, o uso de from tem um impacto importante na forma como os campos são referenciados. Isso pode causar alguns desafios quando um view é usado em muitos lugares diferentes. Por exemplo,

explore: order {
  join: customer {
    from: person
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
}

Aqui, person está sendo unido a order, mas está sendo chamado de customer. Portanto, se você precisasse referenciar um campo de customer em order, usaria ${customer.field_name}. Se, em uma segunda análise detalhada, você unir person a order novamente, mas não renomear para customer, a referência ${customer.field_name} não vai funcionar nessa segunda análise. A abordagem geral para esse problema é excluir o campo problemático da segunda análise detalhada usando fields. Ele será parecido com:

explore: the_second_explore {
  fields: [ALL_FIELDS*, -person.problem_field]
  join: person {
    sql_on: ${the_second_explore.some_field} = ${person.some_field} ;;
  }
}

O from é usado com mais frequência para unir a mesma tabela mais de uma vez a uma análise.

Nos casos em que uma única tabela contém diferentes tipos de entidades, é possível unir uma visualização a uma análise detalhada mais de uma vez. Suponha que você tenha uma análise detalhada do order e precise associar uma visualização do person a ela duas vezes: uma para o cliente e outra para o representante de atendimento ao cliente. Você pode fazer algo assim:

explore: order {
  join: customer {
    from: person
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
  join: representative {
    from: person
    sql_on: ${order.representative_id} = ${representative.id} ;;
  }
}

O SQL que o Looker geraria com base nesse LookML é:

SELECT    ...
FROM      order
LEFT JOIN person AS customer
ON        customer.id = order.customer_id
LEFT JOIN person AS representative
ON        representative.id = order.representative_id