agrupamento

Uso

explore: explore_name {
  join: view_name { ... }
}

Hierarquia Arquivo de modelo explore join

Valor padrão Nenhum Aceita O nome de uma visualização atual Regras especiais Esse parâmetro aceita um nome de visualização, não o nome da tabela subjacente da visualização (embora sejam frequentemente idênticos). Se o dialeto não for compatível com symmetric_aggregates, a maioria dos tipos de métrica será excluída das visualizações unidas. É possível unir a mesma visualização mais de uma vez usando from

Definição

Com join, é possível definir a relação de junção entre uma Análise e uma vista para combinar dados de várias vistas. Você pode participar de quantas vistas quiser em qualquer Análise.

Cada visualização está associada a uma tabela no banco de dados ou a uma tabela derivada definida no Looker. Da mesma forma, como uma Análise está associada a uma visualização, ela também está conectada a uma tabela de algum tipo.

A tabela associada à Análise é colocada na cláusula FROM do SQL gerado pelo Looker. As tabelas associadas a visualizações unidas são colocadas na cláusula JOIN do SQL gerado pelo Looker.

Principais parâmetros de junção

Para definir a relação de junção (a cláusula SQL ON) entre uma análise detalhada e uma visualização, use join em combinação com outros parâmetros.

É necessário usar o parâmetro sql_on ou foreign_key para estabelecer a cláusula ON do SQL.

Também é necessário usar tipos e relações de junção adequados, embora os parâmetros type e relationship nem sempre sejam explicitamente obrigatórios. Se os valores padrão de type: left_outer e relationship: many_to_one forem adequados para seu caso de uso, esses parâmetros poderão ser excluídos.

Esses parâmetros principais e a relação deles com o SQL gerado pelo Looker podem ser resumidos da seguinte maneira:

• O parâmetro explore determina a tabela na cláusula FROM da consulta SQL gerada.
• Cada parâmetro join determina uma cláusula JOIN da consulta SQL gerada.
  • O parâmetro type determina o tipo de junção SQL.
  • Os parâmetros sql_on e foreign_key determinam a cláusula ON da consulta SQL gerada.

sql_on

Com sql_on, é possível estabelecer uma relação de junção escrevendo a cláusula ON do SQL diretamente. Ele pode realizar as mesmas junções que o foreign_key, mas é mais fácil de ler e entender.

Consulte a página de documentação de parâmetros do sql_on para mais informações.

foreign_key

Com o foreign_key, é possível estabelecer uma relação de junção usando a chave primária da visualização unida e conectando-a a uma dimensão na Análise. Esse padrão é muito comum no design de banco de dados, e foreign_key é uma maneira elegante de expressar a junção nesses casos.

Para entender tudo, consulte a página de documentação do parâmetro foreign_key.

type

A maioria das junções no Looker é LEFT JOIN pelos motivos discutidos na seção Não aplique lógica de negócios em junções, se possível nesta página. Portanto, se você não adicionar explicitamente um type, o Looker vai presumir que você quer um LEFT JOIN. No entanto, se você precisar de outro tipo de junção por algum motivo, use type.

Para uma explicação completa, consulte a página de documentação do parâmetro type.

relationship

relationship não tem um impacto direto no SQL gerado pelo Looker, mas é essencial para o funcionamento adequado do Looker. Se você não adicionar explicitamente um relationship, o Looker vai interpretar a relação como many-to-one, o que significa que muitas linhas na Análise podem ter uma linha na visualização unida. Nem todas as junções têm esse tipo de relação, e as que têm outros tipos precisam ser declaradas corretamente.

Para entender tudo, consulte a página de documentação do parâmetro relationship.

Exemplos

Faça a junção da visualização chamada customer à análise detalhada chamada order em que a relação de junção é

FROM order LEFT JOIN customer ON order.customer_id = customer.id:

explore: order {
  join: customer {
    foreign_key: customer_id
    relationship: many_to_one # Could be excluded since many_to_one is the default
    type: left_outer          # Could be excluded since left_outer is the default
  }
}

Faça a junção da visualização chamada address à análise detalhada chamada person em que a relação de junção é

FROM person LEFT JOIN address ON person.id = address.person_id AND address.type = 'permanent':

explore: person {
  join: address {
    sql_on: ${person.id} = ${address.person_id} AND ${address.type} = 'permanent' ;;
    relationship: one_to_many
    type: left_outer # Could be excluded since left_outer is the default
  }
}

Faça a junção da visualização chamada member à análise detalhada chamada event em que a relação de junção é

FROM event INNER JOIN member ON member.id = event.member_id:

explore: event {
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
    relationship: many_to_one # Could be excluded since many_to_one is the default
    type: inner
  }
}

Desafios comuns

join precisa usar nomes de visualização, não nomes de tabelas subjacentes

O parâmetro join usa apenas um nome de visualização, não o nome da tabela associada a ela. Muitas vezes, o nome da visualização e da tabela são idênticos, o que pode levar à conclusão errada de que os nomes de tabela podem ser usados.

Alguns tipos de medidas exigem agregações simétricas

Se você não estiver usando agregações simétricas, a maioria dos tipos de métricas será excluída das visualizações unidas. Para que o Looker ofereça suporte a agregações simétricas no seu projeto do Looker, o dialeto do banco de dados também precisa oferecer suporte a elas. 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

Sem agregações simétricas, as relações de junção que não são de um para um podem criar resultados imprecisos em funções de agregação. Como as medidas do Looker são funções de agregação, apenas as medidas de type: count (como COUNT DISTINCT) são trazidas das visualizações unidas para a Análise. Se você tiver uma relação de junção individual, use o parâmetro relationship para forçar a inclusão dos outros tipos de métrica, assim:

explore: person {
  join: dna {
    sql_on: ${person.dna_id} = ${dna.id} ;;
    relationship: one_to_one
  }
}

Os motivos para o Looker funcionar dessa forma (para dialetos que não oferecem suporte a agregações simétricas) são discutidos em mais detalhes na postagem da comunidade O problema de fanouts do SQL.

Informações importantes

É possível unir a mesma tabela mais de uma vez usando from

Quando uma única tabela contém diferentes tipos de entidades, é possível unir uma visualização a uma análise detalhada mais de uma vez. Para isso, use o parâmetro from. 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} ;;
  }
}

Não aplique lógica de negócios em junções, se possível

A abordagem padrão do Looker para junção é usar um LEFT JOIN sempre que possível. Considere uma abordagem diferente se você estiver fazendo algo parecido com isto:

explore: member_event {
  from: event
  always_join: [member]
  join: member {
    sql_on: ${member_event.member_id} = ${member.id} ;;
    type: inner
  }
}

Neste exemplo, criamos uma análise detalhada que só considera eventos associados a membros conhecidos. No entanto, a maneira preferida de executar isso no Looker seria usar um LEFT JOIN para reunir dados de eventos e de membros, assim:

explore: event {
  join: member {
    sql_on: ${event.member_id} = ${member.id} ;;
  }
}

Em seguida, crie uma dimensão que possa ser definida como yes ou no se você quiser analisar apenas eventos de membros, como este:

dimension: is_member_event {
  type: yesno
  sql: ${member.id} IS NOT NULL ;;
}

Essa abordagem é preferível porque dá aos usuários a flexibilidade de analisar todos os eventos ou apenas os de membros, conforme desejarem. Você não os forçou a olhar apenas para eventos de membros usando a junção.

Se não estiver usando agregações simétricas, evite junções que causem fanouts

Esta seção só se aplica a dialetos de banco de dados que não são compatíveis com agregações simétricas. Consulte a discussão sobre agregações simétricas na seção Desafios comuns desta página para determinar se seu dialeto é compatível com elas.

Se o dialeto do seu banco de dados não for compatível com agregações simétricas, evite junções que resultem em um fanout. Em outras palavras, geralmente é melhor evitar junções que têm uma relação de um para muitos entre a análise e a visualização. Em vez disso, agregue os dados da visualização em uma tabela derivada para estabelecer uma relação individual com a Análise e, em seguida, junte essa tabela derivada à Análise.

Esse conceito importante é explicado na postagem da comunidade O problema dos fanouts do SQL.