Como trabalhar com junções no LookML

Com as junções, é possível conectar diferentes visualizações para analisar dados de mais de uma visualização ao mesmo tempo e ver como diferentes partes dos dados se relacionam.

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

As junções começam com uma Análise

As junções são definidas no arquivo de 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, 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 order_items, order_items aparece na cláusula FROM do SQL gerado:

SELECT ...
FROM order_items

Você pode adicionar mais informações à análise detalhada order_items. Por exemplo, é possível 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} ;;
  }
}

A LookML mostrada anteriormente realiza duas coisas. Primeiro, você pode ver campos de orders e order_items no Seletor de campos de análise detalhada:

Em segundo lugar, a LookML descreve como unir orders e order_items. Essa LookML seria convertida no seguinte SQL:

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

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

Dica da equipe do 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 fazer isso, primeiro declare a tabela em uma visualização. Neste exemplo, suponha que orders seja uma visualização existente no seu modelo.

Em seguida, use o parâmetro join para declarar que você quer mesclar 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 é compatível com 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 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 para um único pedido. A relação da Análise 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 sua junção, o Looker vai usar many_to_one por padrão.

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

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 usar o parâmetro sql_on, já que ele pode fazer tudo o que o parâmetro foreign_key faz, mas é mais fácil de entender.

sql_on

O parâmetro sql_on é equivalente à cláusula ON no SQL gerado para uma consulta. Com esse parâmetro, é possível declarar quais campos devem 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} ;;
  }
}

Você também pode 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 sobre operadores de substituição para saber mais sobre a sintaxe ${ ... } nesses exemplos.

Etapa 6: teste

Para testar se essa junção está funcionando conforme o esperado, acesse a análise Itens do pedido. Você vai ver campos de order_items e orders.

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

Participar por outra visualização

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

Use o parâmetro sql_on ou foreign_key para mesclar a visualização users à visualização orders, em vez de à análise detalhada order_items. Faça isso definindo 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} ;;
  }
}

Entrar em uma visualização mais de uma vez

Uma visualização users contém dados de compradores e vendedores. Para unir dados dessa visualização ao order_items, mas separadamente para compradores e vendedores, é possível unir users duas vezes, com nomes diferentes, usando o parâmetro from.

O parâmetro from permite especificar qual visualização usar em uma junção, além de dar a ela um nome exclusivo. 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: agora, a visualização users precisa ser referenciada pelos nomes de alias buyers e sellers na junção.

Como limitar campos de uma junção

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

Por exemplo, quando orders é combinado com order_items, talvez você queira trazer apenas os campos shipping e tax pela 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 parâmetro set. Suponha que você tenha o seguinte conjunto definido na visualização orders:

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

Você pode optar por trazer apenas esses três campos ao unir orders e 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*]
  }
}

Agregações simétricas

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

Chaves primárias obrigatórias

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

Para fazer isso, adicione o parâmetro primary_key à 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 com valores completamente exclusivos e não nulos. Se os dados não tiverem 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 NULL e a consulta incluir dados que revelem esses problemas, o Looker vai retornar um erro, conforme descrito na página de práticas recomendadas Erro: valor/chave primária não exclusivo (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 agregações simétricas no seu projeto, o dialeto do banco de dados também precisa oferecer. A tabela a seguir mostra quais dialetos são compatíveis com agregações simétricas 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+
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 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
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 for compatível com agregações simétricas, tenha cuidado ao executar junções no Looker, já que alguns tipos 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 dos fanouts de SQL.

Saiba mais sobre junções

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