unir

Uso

explore: explore_name {
join: view_name { ... }
}

Jerarquía Archivo del modelo explore join

Valor predeterminado Ninguna Acepta El nombre de una vista existente Reglas especiales Este parámetro acepta el nombre de una vista, no el de la tabla subyacente de la vista (aunque suelen ser idénticos). Si tu dialecto no admite symmetric_aggregates, la mayoría de los tipos de medición se excluyen de las vistas unidas Puedes unirte a la misma vista más de una vez con from

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 todas las vistas que quieras para una exploración determinada.

Recuerde que cada vista está asociada con una tabla en su base de datos o con una tabla derivada que haya definido en Looker. Del mismo modo, como Explorar está asociado con una vista, también se conecta a una tabla de algún tipo.

La tabla asociada con Explorar 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 necesario que uses el parámetro sql_on o foreign_key para establecer la cláusula ON de SQL.

También deberás asegurarte de usar las relaciones y los tipos de unión adecuados, aunque no siempre se requieren explícitamente los parámetros type y relationship. Si los valores predeterminados de type: left_outer y relationship: many_to_one son apropiados 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 muestran aquí:

sql_on

sql_on te permite establecer una relación de unión mediante la escritura directa de 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 le permite establecer una relación de unión mediante la clave primaria de la vista unida y conectarla con una dimensión en Explorar. 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 comprender todo, 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 analizan en la sección No aplicar la lógica empresarial en las uniones si es posible en esta página. Por lo tanto, si no agregas un type de forma explícita, Looker supondrá que deseas 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

En el diagrama anterior, 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 supondrá que es many-to-one, lo que significa que muchas filas en Explorar pueden tener una fila en la vista unida. No todas las uniones tienen este tipo de relación, y aquellas con otras relaciones deben declararse correctamente.

Para comprender todo, consulta la página de documentación del parámetro relationship.

Ejemplos

Únete a la vista llamada customer en la pestaña Explorar llamada order, donde está la relación de unión

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
  }
}

-

Únete a la vista llamada address en la pestaña Explorar llamada person, donde está la relación de unión

FROM person LEFT JOIN address ON person.id = address.person_idAND 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
  }
}

-

Únete a la vista llamada member en la pestaña Explorar llamada event, donde está la relación de unión

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 tabla asociado 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.

Algunos tipos de medidas requieren agregaciones simétricas

Si no usas agregados simétricos, la mayoría de los tipos de medición se excluyen de las vistas unidas. Para que Looker admita agregaciones simétricas en tu proyecto de Looker, tu dialecto de 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:

Sin las agregaciones simétricas, las relaciones de unión que no son uno a uno pueden crear resultados imprecisos en funciones agregadas. Dado que las mediciones de Looker son funciones agregadas, solo las medidas de type: count (como COUNT DISTINCT) se extraen de las vistas unidas a Explorar. Si tienes una relación de unión uno a uno, puedes usar el parámetro relationship para forzar la inclusión de los otros tipos de medición, como se muestra a continuación:

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 analizan con más detalle en el artículo El problema de las distribuciones de SQL del Centro de ayuda.

Qué debes saber

Puedes unirte a la misma tabla más de una vez con from

En los casos en los 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 dos veces: una para el cliente y una para el representante de servicio al cliente. Puedes hacer algo como esto:

explore: order {
  join: customer {
    from: person
    sql_on: ${order.customer_id} = ${customer.id} ;;
  }
  join: representative {
    from: person
    sql_on: ${order.representative_id} = ${representative.id} ;;
  }
}

Si es posible, no aplique la lógica empresarial en las uniones.

El enfoque estándar de Looker para unirse es usar un LEFT JOIN siempre que sea posible. Considere un enfoque diferente si tiene que hacer 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 un objeto Explorar que solo analiza los eventos asociados con los 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, deberías crear una dimensión que puedas establecer en yes o no, si solo deseas ver los eventos de los miembros, de la siguiente manera:

dimension: is_member_event {
  type: yesno
  sql: ${member.id} IS NOT NULL ;;
}

-

Se prefiere este enfoque porque brinda a los usuarios la flexibilidad de mirar todos los eventos o solo los eventos de los miembros, según lo deseen. No los obligó a consultar solo los eventos de los miembros a través de la unión.

Si no usas agregados simétricos, evita las uniones que causan fanouts.

Esta sección solo se aplica a los dialectos de la base de datos que no admiten agregaciones simétricas. Consulta la discusión de agregaciones simétricas en la sección Desafíos comunes 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 dan como resultado una distribución. En otras palabras, se deben evitar las uniones con una relación de uno a varios entre Explorar y la vista. En su lugar, agregue los datos de la vista en una tabla derivada a fin de establecer una relación uno a uno con Explorar y, luego, una esa tabla derivada a Explorar.

Este concepto importante se explica con más detalle en el artículo El problema de las distribuciones de SQL del Centro de ayuda.