Com as mesclagens, você conecta diferentes vistas. Assim, é possível explorar os dados de mais de uma visualização ao mesmo tempo e entender como diferentes partes dos dados se relacionam entre si.
Por exemplo, seu banco de dados pode incluir as tabelas order_items
, orders
e users
. É possível usar mesclagens para explorar dados de todas as tabelas ao mesmo tempo. Nesta página, explicamos as funções JOIN no LookML, incluindo parâmetros e padrões de mesclagem específicos.
As mesclagens começam com um Explore
As mesclagens são definidas no arquivo modelo para estabelecer a relação entre uma Análise e uma visualização. As mesclagens conectam uma ou mais visualizações a um único Explore, seja diretamente ou por outra visualização combinada.
Vamos considerar 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 da Análise order_items
, order_items
aparece na cláusula FROM
do SQL gerado:
SELECT ...
FROM order_items
Você pode agregar outras informações ao Explore order_items
. Por exemplo, é possível usar o exemplo do LookML a seguir para unir a visualização orders
à Análise order_items
:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
sql_on: ${order_items.order_id} = ${orders.id} ;;
}
}
O LookML acima realiza duas tarefas. Primeiro, é possível ver os campos de orders
e order_items
na UI:
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 em mais detalhes nas próximas seções. Consulte a página de referência do parâmetro join
para saber mais sobre como esse LookML é convertido em SQL.
Dica para a 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 mesclagem ausente. Consulte a página de práticas recomendadas sobre este erro para mais informações.
Parâmetros de mesclagem
Quatro parâmetros principais são usados para a mesclagem: join
, type
, relationship
e sql_on
.
Etapa 1: iniciar o Explore
Primeiro, crie a Análise order_items
:
explore: order_items { ... }
Etapa 2: join
Para mesclar uma tabela, primeiro é necessário declará-la em uma visualização. Neste exemplo, orders
é uma visualização existente no modelo.
Em seguida, use o parâmetro join
para declarar que você quer unir a visualização orders
a order_items
:
explore: order_items {
join: orders { ... }
}
Etapa 3: type
Considere quais type
de mesclagem executar. 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
e geralmente o tipo de mesclagem mais usado.
Etapa 4: relationship
Defina uma mesclagem relationship
entre order_items
e orders
. Declarar corretamente o relationship
de uma mesclagem é importante para que o Looker calcule medidas precisas. A relação é definida no Explore 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 muitas order_items
para uma única order
. A relação de order_items
para orders
é many_to_one
:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
}
}
Se você não incluir um relationship
na mesclagem, o Looker usará many_to_one
como padrão.
Para mais dicas sobre como definir o parâmetro relationship
corretamente para uma mesclagem, consulte a página de práticas recomendadas Acertar o parâmetro relationship
.
Etapa 5: sql_on
Declare como mesclar essas duas tabelas com o parâmetro sql_on
ou foreign_key
. Geralmente, sugerimos o sql_on
porque ele pode fazer tudo o que o foreign_key
faz, mas geralmente é mais fácil de entender.
sql_on
é equivalente à cláusula ON
no SQL gerado para uma consulta. Com esse parâmetro, podemos declarar quais campos precisam ser correspondentes 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 mesclagens mais complexas. Por exemplo, talvez você queira unir somente 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 ;;
}
}
Confira os operadores de substituição para saber mais sobre a sintaxe ${ ... }
nesses exemplos.
Etapa 6: testes
Para testar se essa mesclagem está funcionando conforme o esperado, acesse a Análise em Itens do pedido. Você verá os campos de order_items
e orders
.
Consulte Desenvolvimento de modelos para saber mais sobre como testar alterações no LookML.
Como participar usando outra visualização
Você pode mesclar uma visualização a uma Análise usando outra visualização. No exemplo acima, você uniu orders
a order_items
usando o campo order_id
. Também podemos mesclar os dados de uma visualização chamada users
ao Explore order_items
, mesmo que eles não compartilhem um campo comum. Isso pode ser feito pela mesclagem pela visualização orders
.
Use sql_on
ou foreign_key
para mesclar users
a orders
em vez de order_items
. Para fazer isso, defina o escopo do campo de orders
como orders.user_id
corretamente.
Confira um exemplo que usa 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} ;;
}
}
Participar de 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 em order_items
, mas fazer isso separadamente para compradores e vendedores, é possível agrupar users
duas vezes, com nomes diferentes, usando o parâmetro from
.
O parâmetro from
permite especificar qual visualização usar em uma mesclagem, além de atribuir um nome exclusivo a ela. 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, somente os dados do comprador são combinados como buyers
, enquanto apenas os dados do vendedor são combinados como sellers
.
Observação: a visualização users
agora precisa ser referenciada pelos nomes com alias buyers
e sellers
na junção.
Como limitar campos de uma mesclagem
O parâmetro fields
permite especificar quais campos são trazidos de uma mesclagem para uma Análise. Por padrão, todos os campos de uma visualização são trazidos quando mesclados. No entanto, talvez você queira trazer apenas um subconjunto de campos.
Por exemplo, quando orders
é associado a order_items
, é possível trazer apenas os campos shipping
e tax
pela mesclagem:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
sql_on: ${order_items.order_id} = ${orders.id} ;;
fields: [shipping, tax]
}
}
Você também pode fazer referência a 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 trazer apenas estes três campos ao mesclar orders
com 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*]
}
}
Agregados simétricos
O Looker usa um recurso chamado "agregações simétricas" para calcular agregações (como somas e médias) corretamente, mesmo quando mesclagens resultam em uma fanout. Os agregados simétricos são descritos com mais detalhes na página de práticas recomendadas Noções básicas sobre agregações simétricas. O problema de fanout que eles resolvem é explicado na postagem na Comunidade O problema de fanouts de SQL.
Chaves primárias obrigatórias
Para que as medidas (agregações) cheguem por meio de mesclagens, você precisa 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 da chave primária em cada visualização:
dimension: id {
type: number
primary_key: yes
}
Para processar corretamente medidas unidas, o Looker precisa que você especifique uma chave primária com valores totalmente exclusivos e diferentes de NULL. 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 NULL. Se a chave primária não for exclusiva ou tiver valores NULL e a consulta incluir dados que revelam esses problemas, o Looker vai retornar um erro conforme descrito na página de práticas recomendadas Erro: valor não exclusivo/chave primária (ou sql_distinct_key), estouro de valor ou colisão ao calcular soma.
Dialetos SQL compatíveis
Para que o Looker ofereça suporte a agregações simétricas no seu projeto, o dialeto do seu banco de dados também precisa dar suporte a eles. A tabela a seguir mostra quais dialetos são compatíveis com agregados simétricos na versão mais recente do Looker:
Dialeto | Compatível? |
---|---|
Avalanche | Sim |
Amazon Athena | Sim |
MySQL do Amazon Aurora | Sim |
Amazon Redshift | Sim |
Apache Druid | No |
Apache Druid 0.13 ou superior | No |
Apache Druid 0.18 ou superior | No |
Apache Hive 2.3 ou superior | No |
Apache Hive 3.1.2 ou superior | No |
Apache Spark 3 ou mais recente | Sim |
ClickHouse | No |
Cloudera Impala 3.1 ou mais recente | Sim |
Cloudera Impala 3.1+ com driver nativo | Sim |
Cloudera Impala com driver nativo | No |
DataVirtuality | Sim |
Databricks | Sim |
Denodo 7 | Sim |
Denodo 8 | Sim |
Dremio | No |
Dremio 11 ou mais recente | Sim |
Exasol | Sim |
Fio de fogo | Sim |
SQL legado do Google BigQuery | Sim |
SQL padrão do Google BigQuery | Sim |
PostgreSQL no Google Cloud | Sim |
Google Cloud SQL | Sim |
Google Spanner | Sim |
Verde ameixa | Sim |
HyperSQL | No |
IBM Netezza | Sim |
MariaDB | Sim |
PostgreSQL do Microsoft Azure | Sim |
Banco de dados SQL do Microsoft Azure | Sim |
Análise do Microsoft Azure Synapse | Sim |
Microsoft SQL Server 2008 ou mais recente | Sim |
Microsoft SQL Server 2012 ou mais recente | Sim |
Microsoft SQL Server 2016 | Sim |
Microsoft SQL Server 2017 ou mais recente | Sim |
MongoBI | No |
MySQL | Sim |
MySQL 8.0.12 ou superior | Sim |
Oracle | Sim |
ADWC do Oracle | Sim |
PostgreSQL 9.5 ou mais recente | Sim |
PostgreSQL anterior à versão 9.5 | Sim |
PrestoDB | Sim |
PrestoSQL | Sim |
SAP HANA | Sim |
SAP HANA 2 ou posterior | Sim |
SingleStore | Sim |
SingleStore 7 ou mais recente | Sim |
Snowflake | Sim |
Teradata | Sim |
Trino | Sim |
Vetor | Sim |
Vertica | Sim |
Se o dialeto não oferecer suporte a agregações simétricas, tenha cuidado ao executar mesclagens no Looker, porque alguns tipos de mesclagens 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 na Comunidade O problema de fanouts de SQL.
Saiba mais sobre mesclagens
Para saber mais sobre os parâmetros de mesclagem no LookML, consulte a documentação de referência de mesclagem.