Uso
explore: explore_name {
join: view_name { ... }
}
|
Hierarquia
join |
Valor padrão
Nenhum
Aceita
O nome de uma visualização atual
Regras especiais
|
Definição
Com join, é possível definir a relação de mesclagem entre uma Análise e uma visualização para combinar dados de várias visualizações. Você pode mesclar quantas visualizações quiser em uma Análise.
Lembre-se de que cada visualização está associada a uma tabela no banco de dados ou a uma tabela derivada que você definiu no Looker. Da mesma forma, como uma Análise está associada a uma visualização, ela também está conectada a uma tabela.
A tabela associada à Análise é colocada na cláusula FROM do SQL gerado pelo Looker. As tabelas associadas a visualizações mescladas são colocadas na cláusula JOIN do SQL gerado pelo Looker.
Principais parâmetros de mesclagem
Para definir a relação de mesclagem (a cláusula ON do SQL) entre uma Análise e uma visualização, use join em combinação com outros parâmetros.
É obrigatório usar o parâmetro sql_on ou foreign_key para estabelecer a cláusula ON do SQL.
Também é preciso garantir que você esteja usando os tipos de mesclagem e as relações adequadas, embora os parâmetros type e relationship nem sempre sejam explicitamente necessá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 forma:
- O parâmetro
exploredetermina a tabela na cláusulaFROMda consulta SQL gerada. - Cada parâmetro
joindetermina uma cláusulaJOINda consulta SQL gerada.- O parâmetro
typedetermina o tipo de junção SQL. - Os parâmetros
sql_oneforeign_keydeterminam a cláusulaONda consulta SQL gerada.
- O parâmetro
sql_on
Com sql_on, é possível estabelecer uma relação de mesclagem escrevendo a cláusula SQL ON diretamente. Ela pode realizar as mesmas mesclagens que foreign_key, mas é mais fácil de ler e entender.
Consulte a página de documentação do parâmetro sql_on para mais informações.
foreign_key
O foreign_key permite estabelecer uma relação de mesclagem usando a chave primária da visualização mesclada e conectando-a a uma dimensão na Análise. Esse padrão é muito comum no design de bancos de dados, e o foreign_key é uma maneira elegante de expressar a mesclagem nesses casos.
Para entender melhor, consulte a página de documentação do parâmetro foreign_key.
type
A maioria das mesclagens no Looker é LEFT JOIN pelos motivos discutidos na seção Não aplique lógica de negócios em mesclagens, 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 mesclagem 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 que o Looker gera, mas é fundamental 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 mesclada. Nem todas as mesclagens têm esse tipo de relação, e as mesclagens com outras relações precisam ser declaradas corretamente.
Para entender melhor, consulte a página de documentação do parâmetro relationship.
Exemplos
Unir a visualização chamada customer à Análise chamada order em que a relação de mesclagem é
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
}
}
Unir a visualização chamada address à Análise chamada person em que a relação de mesclagem é
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
}
}
Unir a visualização chamada member à Análise chamada event em que a relação de mesclagem é
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 aceita apenas um nome de visualização, não o nome da tabela associada a ela. Muitas vezes, o nome da visualização e o nome da tabela são idênticos, o que pode levar à conclusão falsa de que os nomes das tabelas podem ser usados.
Alguns tipos de medições exigem conjuntos simétricos
Se você não estiver usando conjuntos simétricos, a maioria dos tipos de medição será excluída das visualizações mescladas. Para que o Looker seja compatível com conjuntos simétricos no seu projeto do Looker, o dialeto do banco de dados também precisa ser compatível com eles. A tabela a seguir mostra quais dialetos são compatíveis com 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 | |
| ClickHouse 26+ | |
| 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+ | |
| Dremio 26+ with Arrow Flight SQL | |
| 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 |
Sem conjuntos simétricos, as relações de mesclagem 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 mescladas para a Análise. Se você tiver uma relação de mesclagem de um para um, use o parâmetro relationship para forçar a inclusão dos outros tipos de medição, desta forma:
explore: person {
join: dna {
sql_on: ${person.dna_id} = ${dna.id} ;;
relationship: one_to_one
}
}
Os motivos pelos quais o Looker funciona dessa maneira (para dialetos que não são compatíveis com conjuntos simétricos) são discutidos em mais detalhes na postagem na Comunidade O problema dos fanouts de SQL.
Informações importantes
É possível mesclar a mesma tabela mais de uma vez usando from.
Nos casos em que uma única tabela contém diferentes tipos de entidades, é possível unir uma visualização a uma Descoberta avançada mais de uma vez. Para isso, use o parâmetro from. Suponha que você tenha uma Análise order e precise mesclar uma visualização person 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 mesclagens, se possível
A abordagem padrão do Looker para mesclagem é usar um LEFT JOIN sempre que possível. Considere uma abordagem diferente se você estiver fazendo algo como:
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 que apenas analisa eventos associados a membros conhecidos. No entanto, a melhor maneira de fazer isso no Looker é usar um LEFT JOIN para combinar os dados de eventos e de membros, assim:
explore: event {
join: member {
sql_on: ${event.member_id} = ${member.id} ;;
}
}
Em seguida, você criaria uma dimensão que poderia ser definida como yes ou no, se quisesse analisar apenas eventos de membros, como este:
dimension: is_member_event {
type: yesno
sql: ${member.id} IS NOT NULL ;;
}
Essa abordagem é preferível porque oferece aos usuários a flexibilidade de analisar todos os eventos ou apenas os eventos de membros, conforme desejarem. Você não os forçou a analisar apenas os eventos de membros usando a mesclagem.
Se não estiver usando conjuntos simétricos, evite junções que causem divergências
Esta seção se aplica apenas a dialetos de banco de dados que não são compatíveis com conjuntos simétricos. Consulte a discussão sobre conjuntos simétricos na seção Desafios comuns nesta página para determinar se o dialeto é compatível com conjuntos simétricos.
Se o dialeto do seu banco de dados não for compatível com conjuntos simétricos, evite mesclagens que resultem em uma divergência. Em outras palavras, as mesclagens que têm uma relação de um para muitos entre a Análise e a visualização geralmente devem ser evitadas. Em vez disso, agregue os dados da visualização em uma tabela derivada para estabelecer uma relação de um para um com a Análise e, em seguida, mescle essa tabela derivada à Análise.
Esse conceito importante é explicado em mais detalhes no post da comunidade The problem of SQL fanouts (em inglês).