Uso
explore: explore_name {
join: view_name { ... }
}
|
Jerarquía
join |
Valor predeterminado
Ninguno
Acepta
Nombre de una vista existente
Reglas especiales
|
Definición
join te permite definir la relación de unión entre una Explorar y una vista, de modo que puedas combinar datos de varias vistas. Puedes unirte a tantas vistas como quieras para cualquier Explore determinado.
Recuerda que cada vista está asociada a una tabla de tu base de datos o a una tabla derivada que definiste en Looker. Del mismo modo, dado que una exploración está asociada a una vista, también está conectada a una tabla de algún tipo.
La tabla asociada con la exploración se coloca en la cláusula FROM del SQL que genera Looker. Las tablas asociadas con las vistas unidas se colocan en la cláusula JOIN del código SQL que genera Looker.
Parámetros de unión principales
Para definir la relación de unión (la cláusula ON de SQL) entre un Explore y una vista, deberás usar join en combinación con otros parámetros.
Debes usar el parámetro sql_on o el parámetro foreign_key para establecer la cláusula SQL ON.
También deberás asegurarte de usar los tipos y las relaciones de unión adecuados, aunque los parámetros type y relationship no siempre son obligatorios de forma explícita. Si sus valores predeterminados de type: left_outer y relationship: many_to_one son adecuados para tu caso de uso, se pueden excluir estos parámetros.
Estos parámetros clave y su relación con el código SQL que genera Looker se pueden resumir de la siguiente manera:
- El parámetro
exploredetermina la tabla en la cláusulaFROMde la consulta en SQL generada. - Cada parámetro
joindetermina una cláusulaJOINde la consulta en SQL generada.- El parámetro
typedetermina el tipo de unión de SQL. - Los parámetros
sql_onyforeign_keydeterminan la cláusulaONde la consulta en SQL generada.
- El parámetro
sql_on
sql_on te permite establecer una relación de unión escribiendo la cláusula ON de SQL directamente. Puede realizar las mismas uniones que foreign_key, pero es más fácil de leer y comprender.
Consulta la página de documentación del parámetro sql_on para obtener más información.
foreign_key
foreign_key te permite establecer una relación de unión con la clave primaria de la vista unida y conectarla con una dimensión en la Exploración. Este patrón es muy común en el diseño de bases de datos, y foreign_key es una forma elegante de expresar la unión en estos casos.
Para comprenderlo por completo, consulta la página de documentación del parámetro foreign_key.
type
La mayoría de las uniones en Looker son LEFT JOIN por los motivos que se explican en la sección No apliques lógica empresarial en las uniones si es posible de esta página. Por lo tanto, si no agregas explícitamente un type, Looker supondrá que quieres un LEFT JOIN. Sin embargo, si necesitas otro tipo de unión por algún motivo, puedes hacerlo con type.
Para obtener una explicación completa, consulta la página de documentación del parámetro type.
relationship
relationship no tiene un impacto directo en el SQL que genera Looker, pero es fundamental para el funcionamiento adecuado de Looker. Si no agregas explícitamente un relationship, Looker interpretará la relación como many-to-one, lo que significa que muchas filas en el Explorar pueden tener una fila en la vista unida. No todas las uniones tienen este tipo de relación, y las uniones con otras relaciones deben declararse correctamente.
Para comprenderlo por completo, consulta la página de documentación del parámetro relationship.
Ejemplos
Une la vista llamada customer al Explorar llamado order, donde la relación de unión es
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
}
}
Une la vista llamada address al Explorar llamado person, donde la relación de unión es
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
}
}
Une la vista llamada member al Explorar llamado event, donde la relación de unión es
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
}
}
Desafíos habituales
join debe usar nombres de vistas y no nombres de tablas subyacentes.
El parámetro join solo toma un nombre de vista, no el nombre de la tabla asociada a esa vista. A menudo, el nombre de la vista y el nombre de la tabla son idénticos, lo que puede llevar a la conclusión falsa de que se pueden usar nombres de tablas.
Algunos tipos de medidas requieren agregados simétricos
Si no usas agregados simétricos, la mayoría de los tipos de medidas se excluyen de las vistas combinadas. Para que Looker admita los agregados simétricos en tu proyecto de Looker, tu dialecto de base de datos también debe admitirlos. En la siguiente tabla, se muestran los dialectos que admiten agregaciones simétricas en la versión más reciente de Looker:
| Dialecto | ¿Es compatible? |
|---|---|
| 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 |
Sin agregaciones simétricas, las relaciones de unión que no son de uno a uno pueden generar resultados inexactos en las funciones de agregación. Dado que las medidas de Looker son funciones de agregación, solo las medidas de type: count (como COUNT DISTINCT) se transfieren de las vistas unidas a la Exploración. Si tienes una relación de unión de uno a uno, puedes usar el parámetro relationship para forzar la inclusión de los otros tipos de medidas, de la siguiente manera:
explore: person {
join: dna {
sql_on: ${person.dna_id} = ${dna.id} ;;
relationship: one_to_one
}
}
En la publicación de Comunidad El problema de las ramificaciones de SQL, se analizan con más detalle los motivos por los que Looker funciona de esta manera (para los dialectos que no admiten agregaciones simétricas).
Información importante
Puedes unir la misma tabla más de una vez con from
En los casos en que una sola tabla contiene diferentes tipos de entidades, es posible unir una vista a una Exploración más de una vez. Para ello, deberás usar el parámetro from. Supongamos que tienes una exploración de order y necesitas unir una vista de person a ella dos veces: una para el cliente y otra para el representante de atención al cliente. Podrías hacer algo como lo siguiente:
explore: order {
join: customer {
from: person
sql_on: ${order.customer_id} = ${customer.id} ;;
}
join: representative {
from: person
sql_on: ${order.representative_id} = ${representative.id} ;;
}
}
No apliques lógica empresarial en las uniones si es posible
El enfoque estándar de Looker para unir tablas es usar un LEFT JOIN siempre que sea posible. Considera un enfoque diferente si te encuentras haciendo algo similar a lo siguiente:
explore: member_event {
from: event
always_join: [member]
join: member {
sql_on: ${member_event.member_id} = ${member.id} ;;
type: inner
}
}
En este ejemplo, creamos una función Explorar que solo analiza los eventos asociados con miembros conocidos. Sin embargo, la forma preferida de ejecutar esto en Looker sería usar un LEFT JOIN para obtener los datos de eventos y los datos de miembros unidos, de la siguiente manera:
explore: event {
join: member {
sql_on: ${event.member_id} = ${member.id} ;;
}
}
Luego, crearías una dimensión que podrías establecer en yes o no si solo quisieras observar los eventos de miembros, de la siguiente manera:
dimension: is_member_event {
type: yesno
sql: ${member.id} IS NOT NULL ;;
}
Este enfoque es preferible porque les brinda a los usuarios la flexibilidad de ver todos los eventos o solo los eventos de miembros, según lo deseen. No los obligaste a mirar solo los eventos de miembros a través de la unión.
Si no usas agregados simétricos, evita las uniones que causen fanouts
Esta sección solo se aplica a los dialectos de bases de datos que no admiten agregados simétricos. Consulta el análisis de las agregaciones simétricas en la sección Desafíos comunes de esta página para determinar si tu dialecto admite agregaciones simétricas.
Si tu dialecto de base de datos no admite agregaciones simétricas, debes evitar las uniones que generen una expansión. En otras palabras, en general, se deben evitar las uniones que tienen una relación de uno a varios entre la exploración y la vista. En su lugar, agrega los datos de la vista en una tabla derivada para establecer una relación uno a uno con la exploración y, luego, une esa tabla derivada a la exploración.
Este importante concepto se explica con más detalle en la publicación de Comunidad El problema de las ramificaciones de SQL.