Uso
explore: view_name_1 {
join: view_name_2 {
sql_on: ${view_name_1.id} = ${view_name_2.id} ;;
}
}
|
Hierarquia
sql_on |
Valor padrão
Nenhum
Aceita
Uma cláusula SQL ON
Regras especiais
sql_on, sql_foreign_key e foreign_key não podem ser usados ao mesmo tempo no mesmo join.
|
Definição
sql_on estabelece uma relação de junção entre uma visualização e a análise detalhada dela com base em uma cláusula SQL ON que você fornece.
Para o LookML, a ordem das condições em sql_on não importa. Portanto, sql_on: ${order.user_id} = ${user.id} ;; e sql_on: ${user.id} = ${order.user_id} ;; são equivalentes. É possível colocar as condições em qualquer ordem, a menos que a ordem seja relevante para o dialeto SQL do seu banco de dados.
Uma visualização pode ser combinada diretamente com uma análise usando sql_on ou por uma segunda visualização que já está combinada com essa análise.
Um exemplo do primeiro caso, em que uma visualização é unida diretamente à análise detalhada, tem esta aparência:
explore: order {
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
O SQL que o Looker geraria com base nesse LookML é:
SELECT ...
FROM order
LEFT JOIN customer
ON order.customer_id = customer.id
No segundo caso, uma visualização é unida a uma Análise por uma visualização intermediária que já está unida a essa Análise. Por exemplo:
explore: order_items {
join: order {
sql_on: ${order_items.order_id} = ${order.id} ;;
}
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Aqui, customer não pode ser unido diretamente a order_items. Em vez disso, ele precisa ser unido usando order. O SQL que o Looker geraria com base nesse LookML é:
SELECT ...
FROM order_items
LEFT JOIN order
ON order_items.order_id = order.id
LEFT JOIN customer
ON order.customer_id = customer.id
Para que isso funcione corretamente, basta usar os nomes de visualização corretos nas referências de campo. Como customer precisa se unir a um campo em order, fazemos referência a ${order.customer_id}.
Em alguns modelos mais antigos, talvez você veja campos referenciados com a sintaxe
view_name.native_column_name. Embora isso ainda funcione, usar a sintaxe${view_name.looker_dimension_name}tem uma vantagem importante: você evita a necessidade do parâmetrorequired_joins. Esse conceito é explicado em mais detalhes na seção Userequired_joinsquando a sintaxe${view_name.looker_dimension_name}não puder ser usada nesta página.
Junções condicionais
Também é possível permitir que a entrada do usuário seja usada em sql_on. Embora haja vários motivos para fazer isso, otimizar a velocidade da consulta em bancos de dados MPP (como o Redshift) é um caso de uso importante, conforme descrito na postagem da comunidade Condições em cláusulas JOIN.
Para adicionar a entrada do usuário à condição de junção, primeiro crie um filtro para ela. Esses tipos de filtros são descritos em mais detalhes na página Filtros com modelo. A forma básica é:
view: view_name {
filter: filter_name {
type: number | datetime | date | string
}
}
Depois de adicionar um filtro para coletar a entrada do usuário, use-o no parâmetro sql_on desta forma:
{% condition view_name.filter_name %} view_name.dimension_name {% endcondition %}
Exemplo:
explore: order {
join: customer {
sql_on:
${order.customer_id} = ${customer.id} AND
{% condition customer.creation_date_filter %} customer.created_at {% endcondition %} ;;
}
}
Isso seria interpretado como: defina customer.created_at igual ao valor de customer.creation_date_filter.
Usar variáveis do Liquid _in_query, _is_selected e _is_filtered
As variáveis do Liquid _in_query, _is_selected e _is_filtered podem ser úteis quando usadas com o parâmetro sql_on. Eles permitem modificar as relações de junção com base nos campos que um usuário selecionou para a consulta. Exemplo:
explore: dates {
join: dynamic_order_counts {
sql_on:
${dynamic_order_counts.period} =
{% if dates.reporting_date._in_query %}
${dates.date_string}
{% elsif dates.reporting_week._in_query %}
${dates.week_string}
{% else %}
${dates.month_string}
{% endif %} ;;
}
}
Exemplos
Faça a junção da visualização chamada customer à análise chamada order combinando a dimensão customer_id de order com a dimensão id de customer:
explore: order {
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Faça a junção da visualização chamada customer à Análise chamada order_items usando a visualização order. Correlacione a dimensão customer_id de order com a dimensão id de customer. Correlacione a dimensão order_id de order_items com a dimensão id de order. Isso seria especificado da seguinte forma:
explore: order_items {
join: order {
sql_on: ${order_items.order_id} = ${order.id} ;;
}
join: customer {
sql_on: ${order.customer_id} = ${customer.id} ;;
}
}
Junte as visualizações chamadas order e inventory_items à Análise chamada order_items. Correlacione a dimensão inventory_id de order_items com a dimensão id de inventory_item. Correlacione a dimensão order_id de order_items com a dimensão id de order. Isso seria especificado da seguinte forma:
explore: order_items {
join: order {
sql_on: ${order_items.order_id} = ${order.id} ;;
}
join: inventory_item {
sql_on: ${order_items.inventory_id} = ${inventory_item.id} ;;
}
}
Informações importantes
Usar required_joins quando a sintaxe ${view_name.looker_dimension_name} não puder ser usada
Ao referenciar campos em sql_on usando a sintaxe ${view_name.looker_dimension_name}, não é necessário se preocupar em usar required_joins.
No entanto, alguns modelos mais antigos ainda usam a sintaxe view_name.native_column_name. Há também alguns casos em que não é possível usar a sintaxe ${view_name.looker_dimension_name}, como quando você quer aplicar SQL personalizado.
Nesses casos, talvez seja necessário usar required_joins. Elas são discutidas em mais detalhes na página de documentação do parâmetro required_joins.