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 entender como as 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 detalhada

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 no 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

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 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 é 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 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 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 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

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

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

Participar por outra visualização

É possível unir uma visualização a uma análise detalhada usando 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 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 unir as visualizações users e orders, em vez de usar o recurso Detalhar 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} ;;
  }
}

Entrar em uma visualização mais de uma vez

Uma visualização users contém dados de compradores e vendedores. Para unir os 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 escolher trazer apenas estes 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 do 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 exclusiva (ou sql_distinct_key), estouro ou conflito de valor 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	Sim
Amazon Athena	Sim
Amazon Aurora MySQL	Sim
Amazon Redshift	Sim
Amazon Redshift 2.1+	Sim
Amazon Redshift Serverless 2.1+	Sim
Apache Druid	Não
Apache Druid 0.13+	Não
Apache Druid 0.18+	Não
Apache Hive 2.3+	Não
Apache Hive 3.1.2+	Não
Apache Spark 3+	Sim
ClickHouse	Não
Cloudera Impala 3.1+	Sim
Cloudera Impala 3.1+ with Native Driver	Sim
Cloudera Impala with Native Driver	Não
DataVirtuality	Sim
Databricks	Sim
Denodo 7	Sim
Denodo 8 & 9	Sim
Dremio	Não
Dremio 11+	Sim
Exasol	Sim
Google BigQuery Legacy SQL	Sim
Google BigQuery Standard SQL	Sim
Google Cloud PostgreSQL	Sim
Google Cloud SQL	Sim
Google Spanner	Sim
Greenplum	Sim
HyperSQL	Não
IBM Netezza	Sim
MariaDB	Sim
Microsoft Azure PostgreSQL	Sim
Microsoft Azure SQL Database	Sim
Microsoft Azure Synapse Analytics	Sim
Microsoft SQL Server 2008+	Sim
Microsoft SQL Server 2012+	Sim
Microsoft SQL Server 2016	Sim
Microsoft SQL Server 2017+	Sim
MongoBI	Não
MySQL	Sim
MySQL 8.0.12+	Sim
Oracle	Sim
Oracle ADWC	Sim
PostgreSQL 9.5+	Sim
PostgreSQL pre-9.5	Sim
PrestoDB	Sim
PrestoSQL	Sim
SAP HANA	Sim
SAP HANA 2+	Sim
SingleStore	Sim
SingleStore 7+	Sim
Snowflake	Sim
Teradata	Sim
Trino	Sim
Vector	Sim
Vertica	Sim

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 na LookML, consulte a documentação de referência de junção.