Las uniones te permiten conectar diferentes vistas para que puedas explorar los datos de más de una vista a la vez y ver cómo las diferentes partes de tus datos se relacionan entre sí.
Por ejemplo, tu base de datos podría incluir las tablas order_items
, orders
y users
. Puedes usar uniones para explorar los datos de todas las tablas al mismo tiempo. En esta página, se explican las uniones en LookML, incluidos los parámetros y los patrones de unión específicos.
Las personas que se unen comienzan con una exploración
Las uniones se definen en el archivo del modelo para establecer la relación entre una Exploración y una vista. Las combinaciones conectan una o más vistas a una sola exploración, ya sea directamente o a través de otra vista unida.
Considera dos tablas de base de datos: order_items
y orders
. Después de generar vistas para ambas tablas, declara una o más de ellas en el parámetro explore
del archivo de modelo:
explore: order_items { ... }
Cuando ejecutas una consulta desde order_items
Explorar, order_items
aparece en la cláusula FROM
del SQL generado:
SELECT ...
FROM order_items
Puedes unir información adicional a la exploración de order_items
. Por ejemplo, puedes usar el siguiente código LookML de muestra para unir la vista orders
a la exploración order_items
:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
sql_on: ${order_items.order_id} = ${orders.id} ;;
}
}
El LookML que se mostró antes cumple dos cosas. Primero, puedes ver los campos de orders
y order_items
en el selector de campos:
En segundo lugar, LookML describe cómo unir orders
y order_items
. Ese LookML se traduciría al siguiente SQL:
SELECT ...
FROM order_items
LEFT JOIN orders
ON order_items.order_id = orders.id
Estos parámetros de LookML se describen con más detalle en las siguientes secciones.
Parámetros de unión
Se usan cuatro parámetros principales para la unión: join
, type
, relationship
y sql_on
.
Paso 1: Inicia la exploración
Primero, crea la exploración de order_items
:
explore: order_items { ... }
Paso 2: join
Para unir una tabla, primero debes declarar la tabla en una vista. En este ejemplo, supongamos que orders
es una vista existente en tu modelo.
Luego, usa el parámetro join
para declarar que quieres unir la vista de orders
a la exploración de order_items
:
explore: order_items {
join: orders { ... }
}
Paso 3: type
Considera qué tipo de unión realizar. Looker admite LEFT JOIN
, INNER JOIN
, FULL OUTER JOIN
y CROSS JOIN
. Estos corresponden a los valores del parámetro type
de left_outer
, inner
, full_outer
y cross
.
explore: order_items {
join: orders {
type: left_outer
}
}
El valor predeterminado de type
es left_outer
.
Paso 4: relationship
Define una relación de unión entre la exploración de order_items
y la vista de orders
. Declarar correctamente la relación de una unión es importante para que Looker calcule medidas precisas. La relación se define a partir de la exploración de order_items
a la vista orders
. Las opciones posibles son one_to_one
, many_to_one
, one_to_many
y many_to_many
.
En este ejemplo, puede haber muchos artículos de pedido para un solo pedido. La relación entre la exploración de order_items
y la vista de orders
es many_to_one
:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
}
}
Si no incluyes un parámetro relationship
en tu unión, Looker se establecerá de forma predeterminada como many_to_one
.
Si deseas obtener sugerencias adicionales sobre cómo definir el parámetro relationship
de forma correcta para una unión, consulta Cómo obtener el parámetro relationship
correcto.
Paso 5: sql_on
Declara cómo unir la tabla order_items
y la tabla orders
junto con los parámetros sql_on
o foreign_key
.
El parámetro sql_on
es equivalente a la cláusula ON
en el SQL generado para una consulta. Con este parámetro, puedes declarar qué campos deben coincidir para realizar la unión:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
sql_on: ${order_items.order_id} = ${orders.id} ;;
}
}
También puedes escribir uniones más complejas. Por ejemplo, es posible que desees unir solo los pedidos con id
superior a 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 ;;
}
}
Consulta la documentación de operadores de sustitución para obtener más información sobre la sintaxis ${ ... }
en estos ejemplos.
Paso 6: Prueba
Para probar que esta unión funcione como se espera, ve a la exploración Order Items. Deberías ver campos de order_items
y orders
.
Consulta Prueba los campos en Explorar para obtener más información sobre cómo probar los cambios de LookML en una exploración.
Cómo unirse a través de otra vista
Puedes unir una vista a una exploración a través de otra vista. En el ejemplo de unión de parámetros, uniste orders
a order_items
a través del campo order_id
. También podríamos unir los datos de una vista llamada users
a la exploración order_items
, aunque no compartan un campo común. Para ello, únete a través de la vista orders
.
Usa los parámetros sql_on
o foreign_key
para unir la vista users
con la vista orders
, en lugar de hacerlo con la exploración de order_items
. Para ello, define correctamente el alcance del campo de orders
como orders.user_id
.
Este es un ejemplo en el que se usa el parámetro 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} ;;
}
}
Unirse a una vista más de una vez
Una vista users
contiene datos de compradores y vendedores. Para unir los datos de esta vista en order_items
, pero hacerlo por separado para los compradores y vendedores, puedes unir users
dos veces, con nombres diferentes, usando el parámetro from
.
El parámetro from
te permite especificar qué vista usar en una unión, a la vez que le otorgas un nombre único. Por ejemplo:
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} ;;
}
}
En este caso, solo los datos del comprador se unen como buyers
, mientras que solo los datos del vendedor se unen como sellers
.
Nota: Ahora se debe hacer referencia a la vista users
por sus nombres con alias buyers
y sellers
en la unión.
Limita los campos de una unión
El parámetro fields
te permite especificar qué campos se incorporan de una unión a una exploración. De forma predeterminada, todos los campos de una vista se activan cuando se unen. Sin embargo, es posible que quieras usar solo un subconjunto de campos.
Por ejemplo, cuando orders
se une a order_items
, es posible que quieras usar solo los campos shipping
y tax
a través de la unión:
explore: order_items {
join: orders {
type: left_outer
relationship: many_to_one
sql_on: ${order_items.order_id} = ${orders.id} ;;
fields: [shipping, tax]
}
}
También puedes hacer referencia a un conjunto de campos, como [set_a*]
. Cada conjunto se define dentro de una vista con el parámetro set
. Supongamos que tienes el siguiente conjunto definido en la vista orders
:
set: orders_set {
fields: [created_date, shipping, tax]
}
Puedes elegir transferir solo estos tres campos cuando unes orders
a 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
Looker usa una función llamada “agregaciones simétricas” para calcular agregaciones (como sumas y promedios) de manera correcta, incluso cuando las uniones den como resultado una fanout. Las agregaciones simétricas se describen con más detalle en Explicación de las agregaciones simétricas. El problema de fanout que resuelven los agregados de symmetrid se explica en la publicación de Comunidad The problem of SQL fanouts.
Claves primarias obligatorias
Para que las medidas (agrupaciones) se muestren a través de las combinaciones, debes definir claves primarias en todas las vistas que participan en la combinación.
Para ello, agrega el parámetro primary_key
a la definición del campo de clave primaria en cada vista:
dimension: id {
type: number
primary_key: yes
}
Dialectos de SQL compatibles
Para que Looker admita agregaciones simétricas en tu proyecto de Looker, el dialecto de la base de datos también debe admitirlas. En la siguiente tabla, se muestra qué dialectos admiten agregaciones simétricas en la versión más reciente de Looker:
Dialecto | ¿Es compatible? |
---|---|
Avalancha de Actian | Sí |
Amazon Athena | Sí |
Amazon Aurora MySQL | Sí |
Amazon Redshift | Sí |
Apache Druid | No |
Apache Druid 0.13 y versiones posteriores | No |
Apache Druid 0.18 y versiones posteriores | No |
Apache Hive 2.3 y versiones posteriores | No |
Apache Hive 3.1.2 y versiones posteriores | No |
Apache Spark 3 y versiones posteriores | Sí |
ClickHouse | No |
Cloudera Impala 3.1 y versiones posteriores | Sí |
Cloudera Impala 3.1 y versiones posteriores con controlador nativo | Sí |
Cloudera Impala con controlador nativo | No |
DataVirtuality | Sí |
Databricks | Sí |
Denodo 7 | Sí |
Denodo 8 | Sí |
Dremio | No |
Dremio 11 y versiones posteriores | Sí |
Exasol | Sí |
Firebolt | Sí |
SQL heredado de Google BigQuery | Sí |
SQL estándar de Google BigQuery | Sí |
PostgreSQL en Google Cloud | Sí |
Google Cloud SQL | Sí |
Google Spanner | Sí |
Greenplum | Sí |
HyperSQL | No |
IBM Netezza | Sí |
MariaDB | Sí |
Microsoft Azure PostgreSQL | Sí |
Base de datos de Microsoft Azure SQL | Sí |
Microsoft Azure Synapse Analytics | Sí |
Microsoft SQL Server 2008 y versiones posteriores | Sí |
Microsoft SQL Server 2012 y versiones posteriores | Sí |
Microsoft SQL Server 2016 | Sí |
Microsoft SQL Server 2017 y versiones posteriores | Sí |
MongoBI | No |
MySQL | Sí |
MySQL 8.0.12 y versiones posteriores | Sí |
Oracle | Sí |
Oracle ADWC | Sí |
PostgreSQL 9.5 y versiones posteriores | Sí |
PostgreSQL anterior a 9.5 | Sí |
PrestoDB | Sí |
PrestoSQL | Sí |
SAP HANA 2 y versiones posteriores | Sí |
SingleStore | Sí |
SingleStore 7 y versiones posteriores | Sí |
Snowflake | Sí |
Teradata | Sí |
Trino | Sí |
Vector | Sí |
Vertica | Sí |
Si tu dialecto no admite agregaciones simétricas, ten cuidado cuando ejecutes uniones en Looker, ya que algunos tipos de uniones pueden generar agregaciones inexactas (como sumas y promedios). Este problema y sus soluciones se describen con más detalle en la publicación de Comunidad The problem of SQL fanouts (El problema de los fanouts de SQL).
Más información sobre las uniones
Para obtener más información sobre los parámetros de unión en LookML, consulta la documentación de Referencia de uniones.