Como trabalhar com junções no LookML

As junções permitem conectar visualizações diferentes para que você possa analisar dados de mais de uma visualização ao mesmo tempo e ver como as diferentes partes dos dados se relacionam.

Por exemplo, seu banco de dados pode incluir as tabelas order_items, orders e users. É possível usar junções para analisar dados de todas as tabelas ao mesmo tempo. Esta página explica as junções no LookML, incluindo parâmetros de junção específicos e padrões de junção.

As junções começam com uma análise detalhada

As junções são definidas no arquivo modelo para estabelecer a relação entre uma Análise e uma visualização. As junções conectam uma ou mais visualizações a uma única análise detalhada, diretamente ou por outra visualização unida.

Considere duas tabelas de banco de dados: order_items e orders. Depois de gerar visualizações para as duas tabelas, declare uma ou mais delas no parâmetro explore do arquivo de modelo:

explore: order_items { ... }

Quando você executa uma consulta na análise detalhada order_items, order_items aparece na cláusula FROM do SQL gerado:

SELECT ...
FROM order_items

É possível unir mais informações à análise detalhada order_items. Por exemplo, você pode usar o seguinte exemplo de LookML para unir a visualização orders à análise detalhada order_items:

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
    sql_on: ${order_items.order_id} = ${orders.id} ;;
  }
}

O LookML mostrado anteriormente realiza duas ações. Primeiro, é possível ver campos de orders e order_items no seletor de campos da análise detalhada:

Em segundo lugar, o LookML descreve como unir orders e order_items. Esse LookML seria convertido no seguinte SQL:

SELECT ...
FROM order_items
LEFT JOIN orders
ON order_items.order_id = orders.id

Esses parâmetros do LookML são descritos com mais detalhes nas seções a seguir.

Dica da equipe de chat:os usuários perguntam mais sobre o erro de validação "Campo desconhecido ou inacessível", que pode ser causado por uma junção ausente. Consulte Erro: campo desconhecido ou inacessível para mais informações.

Parâmetros de junção

Quatro parâmetros principais são usados para junção: join, type, relationship e sql_on.

Etapa 1: iniciar a análise detalhada

Primeiro, crie a análise detalhada order_items:

explore: order_items { ... }

Etapa 2: join

Para unir uma tabela, primeiro declare a tabela em uma visualização. Neste exemplo, suponha que orders seja uma visualização já existente no seu modelo.

Em seguida, use o parâmetro join para declarar que você quer unir a visualização orders à análise detalhada order_items:

explore: order_items {
  join: orders { ... }
}

Etapa 3: type

Considere qual tipo de junção realizar. O Looker oferece suporte a LEFT JOIN, INNER JOIN, FULL OUTER JOIN e CROSS JOIN. Eles correspondem aos valores de parâmetro type de left_outer, inner, full_outer e cross.

explore: order_items {
  join: orders {
    type: left_outer
  }
}

O valor padrão de type é left_outer.

Etapa 4: relationship

Defina uma relação de junção entre a análise detalhada order_items e a visualização orders. Declarar corretamente a relação de uma junção é importante para que o Looker calcule medidas precisas. A relação é definida da análise detalhada order_items para a visualização orders. As opções possíveis são one_to_one, many_to_one, one_to_many e many_to_many.

Neste exemplo, pode haver muitos itens de pedido para um único pedido. A relação da análise detalhada order_items com a visualização orders é many_to_one:

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
  }
}

Se você não incluir um parâmetro relationship na junção, o Looker vai usar many_to_one como padrão.

Para mais dicas sobre como definir o parâmetro relationship corretamente para uma junção, consulte Como definir o parâmetro relationship corretamente.

Etapa 5: sql_on

Declare como unir as tabelas order_items e orders com o parâmetro sql_on ou foreign_key.

**Dica**: geralmente sugerimos o uso do parâmetro sql_on, porque ele pode fazer tudo o que o parâmetro foreign_key faz, mas o parâ4metro sql_on geralmente é mais fácil de entender.

O parâmetro sql_on é equivalente à cláusula ON no SQL gerado para uma consulta. Com esse parâmetro, é possível declarar quais campos precisam ser correspondidos para realizar a junção:

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
    sql_on: ${order_items.order_id} = ${orders.id} ;;
  }
}

Também é possível escrever junções mais complexas. Por exemplo, talvez você queira unir apenas pedidos com id maior que 1.000:

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
    sql_on: ${order_items.order_id} = ${orders.id} AND ${orders.id} > 1000 ;;
  }
}

Consulte a documentação dos operadores de substituição para saber mais sobre a sintaxe ${ ... } nesses exemplos.

Etapa 6: testes

Teste se essa junção está funcionando conforme o esperado acessando a análise detalhada Itens do pedido. Você vai encontrar campos de order_items e orders.

Consulte Testar os campos na análise detalhada para saber mais sobre como testar mudanças do LookML em uma análise detalhada.

Unir por outra visualização

É possível unir uma visualização a uma análise detalhada por outra visualização. No exemplo de parâmetros de junção, você uniu orders a order_items usando o campo order_id. Também podemos unir os dados de uma visualização chamada users à análise detalhada order_items, mesmo que eles não compartilhem um campo comum. Isso pode ser feito unindo por a visualização orders.

Use o parâmetro sql_on ou o parâmetro foreign_key para unir a visualização users à visualização orders, em vez da análise detalhada order_items. Para isso, defina corretamente o escopo do campo de orders como orders.user_id.

Confira um exemplo usando o parâmetro sql_on:

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
    sql_on: ${order_items.order_id} = ${orders.id} ;;
  }
  join: users {
    type: left_outer
    relationship: many_to_one
    sql_on: ${orders.user_id} = ${users.id} ;;
  }
}

Unir uma visualização mais de uma vez

Uma visualização users contém dados de compradores e vendedores. Para unir dados dessa visualização a order_items, mas fazer isso separadamente para compradores e vendedores, você pode unir users duas vezes, com nomes diferentes, usando o from parâmetro.

O parâmetro from permite especificar qual visualização usar em uma junção, ao mesmo tempo em que atribui um nome exclusivo à junção. Por exemplo:

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
    sql_on: ${order_items.order_id} = ${orders.id} ;;
  }
  join: buyers {
    from: users
    type: left_outer
    relationship: many_to_one
    sql_on: ${orders.buyer_id} = ${buyers.id} ;;
  }
  join: sellers {
    from: users
    type: left_outer
    relationship: many_to_one
    sql_on: ${orders.seller_id} = ${sellers.id} ;;
  }
}

Nesse caso, apenas os dados do comprador são unidos como buyers, enquanto apenas os dados do vendedor são unidos como sellers.

Observação: a visualização users agora precisa ser referenciada pelos nomes de alias buyers e sellers na junção.

Limitar campos de uma junção

O fields parâmetro permite especificar quais campos são extraídos de uma junção para uma análise detalhada. Por padrão, todos os campos de uma visualização são extraídos quando unidos. No entanto, talvez você queira extrair apenas um subconjunto de campos.

Por exemplo, quando orders é unido a order_items, talvez você queira extrair apenas os campos shipping e tax da junção:

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
    sql_on: ${order_items.order_id} = ${orders.id} ;;
    fields: [shipping, tax]
  }
}

Também é possível referenciar um conjunto de campos, como [set_a*]. Cada conjunto é definido em uma visualização usando o set parâmetro. Suponha que você tenha o seguinte conjunto definido na visualização orders:

set: orders_set {
  fields: [created_date, shipping, tax]
}

É possível extrair apenas esses três campos ao unir orders a order_items:

explore: order_items {
  join: orders {
    type: left_outer
    relationship: many_to_one
    sql_on: ${order_items.order_id} = ${orders.id} ;;
    fields: [orders_set*]
  }
}

Conjuntos simétricos

O Looker usa um recurso chamado "conjuntos simétricos" para calcular agregações (como somas e médias) corretamente, mesmo quando as junções resultam em um fanout. Os conjuntos simétricos são descritos com mais detalhes em Noções básicas sobre conjuntos simétricos. O problema de fanout que os conjuntos simétricos resolvem é explicado na postagem da comunidade O problema de fanouts SQL.

Chaves primárias obrigatórias

Para que as medidas (agregações) sejam extraídas das junções, é necessário definir chaves primárias em todas as visualizações envolvidas na junção.

Para fazer isso, adicione o primary_key parâmetro à definição do campo de chave primária em cada visualização:

dimension: id {
  type: number
  primary_key: yes
}

Observação: para processar corretamente as medidas unidas, o Looker depende da especificação de uma chave primária em que os valores sejam completamente exclusivos e não nulos. Se os dados não contiverem uma chave primária, considere se a concatenação de vários campos resultaria em uma chave primária de valores completamente exclusivos e não nulos. Se a chave primária não for exclusiva ou contiver valores nulos e a consulta incluir dados que revelem esses problemas, o Looker vai retornar um erro conforme descrito na página Práticas recomendadas para erro: valor/chave primária não exclusiva (ou sql_distinct_key), estouro de valor ou colisão ao calcular a soma.

Dialetos SQL compatíveis

Para que o Looker ofereça suporte a conjuntos simétricos no seu projeto do Looker, o dialeto do banco de dados também precisa oferecer suporte a eles. A tabela a seguir mostra quais dialetos oferecem suporte a conjuntos simétricos na versão mais recente do Looker:

Dialeto	Compatível?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

Se o dialeto não oferecer suporte a conjuntos simétricos, tenha cuidado ao executar junções no Looker, já que alguns tipos de junções podem resultar em agregações imprecisas (como somas e médias). Esse problema e as soluções alternativas são descritos em detalhes na postagem da comunidade O problema de fanouts SQL.

Saiba mais sobre junções

Para saber mais sobre os parâmetros de junção no LookML, consulte a documentação de referência de junção.