Uso
explore: explore_name {
join: view_name { ... }
}
|
Jerarquía
join |
Valor predeterminado
Ninguno
Acepta
El nombre de una vista existente
Reglas especiales
|
Definición
join te permite definir la relación de unión entre una exploración y una vista, de modo que puedas combinar datos de varias vistas. Puedes unir tantas vistas como quieras para cualquier exploración determinada.
Recuerda que cada vista está asociada con una tabla en tu base de datos o una tabla derivada que definiste en Looker. Del mismo modo, como una exploración está asociada con 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 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 una exploración y una vista, deberás usar join en combinación con otros parámetros.
Es obligatorio que uses el parámetro sql_on o el parámetro foreign_key para establecer la cláusula ON de SQL.
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 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. - El parámetro
sql_ony el parámetroforeign_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 directamente la cláusula ON de SQL. 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 conectándola 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 obtener una comprensión completa, 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 un type de forma explícita, 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 un relationship de forma explícita, Looker interpretará la relación como many-to-one, lo que significa que muchas filas en la exploración 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 obtener una comprensión completa, consulta la página de documentación del parámetro relationship.
Ejemplos
Une la vista llamada customer a la exploración llamada 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 a la exploración llamada 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 a la exploración llamada 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 vista y no nombres de tablas subyacentes
El parámetro join solo toma un nombre de vista, no el nombre de la tabla asociada con 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 agregaciones simétricas
Si no usas agregaciones simétricas, la mayoría de los tipos de medidas se excluyen de las vistas unidas. Para que Looker admita agregaciones simétricas en tu proyecto de Looker, el dialecto de tu base de datos también debe admitirlas. 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 crear resultados inexactos en las funciones agregadas. Como las medidas de Looker son funciones agregadas, 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
}
}
Los motivos por los que Looker funciona de esta manera (para los dialectos que no admiten agregaciones simétricas) se explican con más detalle en la publicación de Comunidad El problema de las expansiones de SQL.
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 from parámetro. Supongamos que tienes una exploración order y necesitas unir una vista 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 la unión es usar un LEFT JOIN siempre que sea posible. Considera un enfoque diferente si te encuentras haciendo algo como 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 exploración 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 datos de eventos y datos de miembros juntos, de la siguiente manera:
explore: event {
join: member {
sql_on: ${event.member_id} = ${member.id} ;;
}
}
Luego, crearías una dimensión que podrías configurar como yes o no, si solo quisieras ver los eventos de los 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 los miembros, según lo deseen. No los obligaste a ver solo los eventos de los miembros a través de la unión.
Si no usas agregaciones simétricas, evita las uniones que causan expansiones
Esta sección solo se aplica a los dialectos de bases de datos que no admiten agregaciones simétricas. Consulta el debate sobre las agregaciones simétricas en la sección Desafíos habituales de esta página para determinar si tu dialecto admite agregaciones simétricas.
Si el dialecto de tu base de datos no admite agregaciones simétricas, debes evitar las uniones que generen una expansión. En otras palabras, por lo 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 de 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 expansiones de SQL.